[HTTP] 신뢰할 수 있는 TCP/IP와 해당 프로토콜을 통해 전송되는 HTTP 메세지
DNS, Domain Name System
리소스를 제공하는 서버에 접근하기 위해서는 ip주소를 알아야 한다.
이런 ip주소는 기억하기 어렵고, 변경될 수 있다. 때문에 ip주소 대신 도메인주소을 사용할 수도 있다.
도메인을 사서 DNS서버에 ip주소와 함께 등록해놓고, 도메인명으로 서버에 접근하려고 할 때, DNS서버를 거치게 된다.
해당 DNS 서버에서 도메인명에 매핑되는 ip주소를 반환하면, 해당 ip주소를 가지고 목적지 서버에 접근할 수 있다.
인터넷 프로토콜, IP
복잡한 인터넷 망에서 지정한 ip주소에 데이터를 전달할 때까지 수많은 노드들을 거친다.
보내야 하는 데이터가 일정 용량이상이면 데이터를 나눠서 보내는데, 이 때의 통신단위는 ip패킷 (package + bucket)이다.
해당 패킷에는 출발지ip주소, 목적지ip주소가 담겨있다.
클라이언트 패킷을 받은 서버는 똑같이 출발지ip주소와 목적지ip주소가 담긴 서버패킷을 클라이언트에게 보낸다.
하지만, 🐖 ip 프로토콜만으로는 안전하고 정확한 데이터 통신을 보장할 수 없다.
- 비연결성
- 만약, 서버가 서비스불능 상태여도, 클라이언트는 확인하는 과정 없이 패킷을 보낸다.
- 비신뢰성
- 중간에 패킷이 사라지거나 패킷이 순서대로 도착하지 않아도 이를 검증하는 과정이 없다.
- 프로그램 구분x
- 같은 ip를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 때, 이 애플리케이션을 구분할 방법이 없다.
이런 검증과 구분을 고려해서 TCP (Transmission Control Protocol, 전송제어 프로토콜)가 나왔다.
TCP/IP
(1) TCP는 연결지향 프로토콜이다. - TCP 3way handshake (가상연결)
SYN: 접속요청 ACK: 요청수락
| 연결신호 | 전송 방향 |
|---|---|
| SYN | Client -> Server |
| SYN + ACK | Server -> Client |
| ACK + 데이터 | Client -> Client |
TCP는 다짜고짜 전송할 데이터를 보내는 것이 아닌 연결을 확인하는 과정을 거친다.
TCP 3way handshake는 개념적으로는 연결되었다는 것을 증명할 뿐이다.
실제로 연결된 것이 아니다.
클라이언트에서 서버로 접속요청을 하고, 서버에서 요청을 수락함과 동시에
반대로도 접속요청을 하고, 다시 클라이언트에서 서버로 요청수락을 보낸다면 연결이 된것으로 본다.
※ 클라이언트에서 서버로 ACK와 전송할 데이터를 같이 보냄으로써 최적화되어 있다.
(2) TCP는 데이터 전달을 보증한다. - 검증을 위한 정보를 패킷에 같이 넣어보낸다.
때문에 패킷이 누락되면 알 수 있고,
순서가 바껴 도착했다면, 바뀐 패킷부터 다시 전송한다.
(3) TCP 헤더에는 출발지 포트번호와 목적지 포트 번호가 담겨있다. - 같은 ip 내 프로세스 구분
포트번호를 통해 어떤 애플리케이션을 위한 데이터 통신인지를 구분한다.
IP의 한계를 보완한 TCP/IP는 기본적으로 연결되면, 그 연결을 유지한다.
연결을 유지한다는 것은 서버 자원을 지속적으로 소모한다는 것을 의미한다.
0 ~ 65536까지 할당 가능
0 ~ 1023 : 잘알려진 포트, 포트를 설정할 때 사용하지 않는 것이 좋다.
20, 21 : FTP
23 : TELNET
80 : HTTP
443 : HTTPS
예제: 채팅프로그램의 데이터 통신 과정
| 인터넷 프로토콜 스택의 4계층 | |
|---|---|
| 애플리케이션 계층 | HTTP, FTP |
| 전송 계층 | TCP, UDP |
| 인터넷 계층 | IP |
| 네트워크 인터페이스 계층 | - |
애플리케이션 계층의 채팅프로그램에서 데이터를 전송하면,
데이터가 해당 계층의 SOCKET 라이브러리를 통해 전송계층으로 전송된다.
해당 데이터는 전송계층에서 TCP 정보가 생성되고,
아래 계층인 인터넷 계층에서 IP 패킷이 생성된다. TCP/IP 패킷
네트워크 인터페이스 계층의 LAN 드라이버, LAN 장비 안의 LAN카드에 등록된 MAC주소를 통해 인터넷 망으로 데이터가 전달되고, (인터넷으로 나가기 전 Ehternet frame 정보가 포함되어 나간다.)
여러 노드를 거쳐 목적지IP주소까지 전송된다.
TCP/IP 패킷은 IP패킷 + TCP segment + 전송데이터로 구성되어 있다.
IP패킷에는 출발지/목적지 ip주소가 담겨있고,
TCP segment에는 전송제어정보, 순서정보, 검증정보와 출발지/목적지 포트번호 들어있다.
- 🍍 UDP (User Datagram Protocol)
- 기능이 딱히 없고, 단순하고 빠르다.
ip와 거의 같고, 여기에 포트정보와 검증 정도만 추가되었다.
HTTP 메세지
HTTP (HyperText Transfer Protocol), 해당 프로토콜은 기본적으로 클라이언트-서버 구조를 가진다.
클라이언트는 ui와 사용성에 집중하고, 비즈니스 로직이나 데이터는 서버에 보관한다.
그리고 서버의 데이터가 필요할 때, 클라이언트는 서버에 HTTP 요청 메세지를 보내고 응답을 대기하면 서버는 요청에 대한 HTTP 응답메세지를 만들어서 응답한다.
이러한 구조는 클라이언트, 서벅 각각이 독립적으로 진화할 수 있다.
HTTP는 🔌무상태(Stateless) 프로토콜이다.
즉, 서버가 클라이언트의 상태를 보존하지 않는다.
그만크 클라이언트가 HTTP 요청 메세지를 보낼 때 추가 데이터를 보내야 하지만
이렇게 하므로써 🏆 서버 확장성(Scale-out)이 높아진다. 또한, 무상태는 중간에 응답하는 서버가 바껴도 상관없다. 때문에 무상태는 계속 서버를 증설해도 상관없다.
- ☄️ 무상태(Stateless)의 한계 - 클라이언트의 상태를 유지해야 하는 경우
- 로그인한 사용자의 경우, 로그인 했다는 상태를 서버에 유지해야 한다.
일반적으로 🍪 브라우저 쿠키와 🧫 서버 세션을 이용해서 상태유지를 하는데,
상태유지(Stateful)는 최소한만 사용해야 한다.
무상태의 반대개념으로, 서버가 클라이언트의 이전 상태를 보존하는 것을 말한다.
이러면 한번 클라이언트에 응답하는 서버가 같게 유지되어야 한다.
HTTP는 기본적으로 연결을 유지하지 않는 모델이다. connectless
서버와 연결을 유지하지 않으면 최소한의 자원만을 사용할 수 있다.
하지만 이런 방식은 각각의 리소스(html, css, image …)를 얻기 위해
🐖 다수의 TCP/IP 연결을 맺고 끊어야한다. 3way handshake
때문에 지금은 HTTP 지속연결(Persistent Connections)로 문제를 해결한다.
즉, 왠만한 html 등의 리소스를 다 받을 때까지는 연결을 유지한다.
** 🍪 HTTP 메세지 구조 **
| start-line | 시작라인 (request-line / status-line) |
| ex. GET /search?q=hello&hl=ko HTTP/1.1 | |
| ex. HTTP/1.1 200 OK | |
| header | 헤더 (HTTP 전송에 필요한 부가 정보) |
| ex. Host: www.googole.com | |
| empty line | 공백라인 CRLF |
| message body | 본문 (실제 전송할 데이터) |
| byte로 표현할 수 있는 모든 데이터 전송 가능 |