0. 들어가며
TCP프로토콜은 OSI 4계층, IP프로토콜은 3계층에 위치합니다. 그리고 HTTP 프토토콜은 7계층에 속하지만, TCP/IP에 의존적인 프토콜입니다. 그렇다면 HTTP 프로토콜과 TCP프로토콜은 어떤 차이가 있을지 알아보도록 하겠습니다.
1. TCP/IP
흔히 TCP/IP 라고 묶어서 부르지만, 각각 다른 프로토콜입니다.
하나씩 간단히 보도록 하겠습니다.
IP 프로토콜
IP프로토콜은 지정한 IP주소에 데이터를 패킷 이라는 통신 단위로 전달하는 역할을 합니다.
단, 목적지까지 패킷의 순서와 도착을 보장하지 않습니다. 그리고 연결과 관련된 상태 정보도 유지하지 않습니다.
그리고 IP 패킷은 헤더와 데이터필드로 나뉘게 됩니다.
데이터 필드는 상위 계층에서 전달된 PDU가 삽입되며, 헤더필드는 패킷을 목적지까지 전송하기 위해 필요한 데이터가 포함됩니다.
헤더의 데이터는
IP프로토콜의 버전, 헤더의 길이, 패킷의 우선순위(서비스타입), 전체 길이, 조립및 분해를 위한 식별자, 단편화 여부를 나타내는 플래그, 단편화된 패킷의 순서 정보인 단편화 오프셋, 패킷이 노드상에 무한정 돌아다닐 수 없도록 경우할 수 있는 홉수를 제한하는 TTL, 어떤 상위 프로토콜과 관련되는지 나타내는 프로토콜, 오류발생을 검사하는 헤더 체크섬, 송/수신자 IP 주소로 이루어져 있습니다.
TCP 프로토콜
TCP 프로토콜은 위의 IP 프로토콜을 보완하기 위해 등장한 프로토콜입니다.
첫번째로는 IP프로토콜의 오류를 처리할 상위 프로토콜의 필요성이 있었습니다.
IP프로토콜에서 오류가 발생하면 ICMP1에서 알려주긴 하지만, 처리는 IP프로토콜의 상위 계층에서 진행해야 하기 때문에 해당 문제를 처리해야할 상위 계층의 프로토콜이 필요했죠.(TCP, UDP)
두번째로는 신뢰할 수 있는 데이터 전송방법이 필요했습니다.
초기엔 IP 프로토콜의 비신뢰성과 비연결성을 통해 간단하고 효율적인 데이터 송신이 가능했지만,
인터넷이 발전을 거듭함에 따라 네트워크로 송수신되는 데이터들도 복잡, 고도화됨에 따라 연결이 보장된 신뢰성 있는 통신이 필요하게 되었습니다. IP프로토콜만 존재했다면 현재의 온라인 결제 시스템과 같이 신뢰성이 필요한 서비스들은 서비스가 불가능 했겠죠?
이를 위해서 3-way handshake를 통해 송수진자간 연결을 확인하고 데이터를 정장적으로 받았는지를 확인입니다.
이에 더해 흐름제어를 위해 한번에 보낼 데이터의 양을 조절하는 Window size, 혼잡제어를 위해 연결 초기엔 낮게보내지만 양을 점점 늘리며 적합한 송출량을 확인하는 Slow start등의 특징을 가지게 되었습니다.
자세한 내용은 글이 너무 길어지니 생략하도록 하겠습니다.
2. HTTP
HyperText Transfer Protocol을 줄여서 http라고 칭하는데요,
HTML과 가은 문서를 전송하기 위핸 7계층 프로토콜입니다.
WWW(World Wide Web)의 통신 프로토콜 역할을 하기 위해 만들어 졌고, http를 통해 브라우저와 웹 서버에서 요청과 응답을 주고받을 수 있습니다.
http 이전의 통신 프로토콜들은 동적 콘텐츠의 생성과 전달이 어려워 상호작용이 제한된 정적 콘텐츠들이 대다수였으며, 텍스트 기반 콘텐츠에 중점을 두고 설계되어 이미지, 오디오, 비디오 등의 멀티미디어 데이터를 효율적으로 처리할 수가 없었습니다.
이를 극복하기 위해 http는 HyperText라는 개념으로 멀티미디어 데이터의 하이퍼링크를 통해 텍스트 콘텐츠와 멀티미디어 리소스를 유기적으로 연결하였고, request-response 모델을 통해 브라우저와 웹서버 사이 효과적인 상호작용을 가능케 함으로써, 양방향 통신과 동적 콘텐츠들의 제공이 손쉽게 가능토록 해주었습니다.
3. TCP/IP와 HTTP
http2에서는 위에 서술한대로 다양한 요구사항을 충족시키기 위해 신뢰성이 장점인 tcp를 기반으로 메세지를 송신하게 되었습니다.
즉, http는 메세지의 형식을 정의하고, 해당 메세지를 tcp/ip 프로토콜을 통해 송신합니다. 7계층부터 패킷이 생성되는 것이죠.
위에 첨부한 TCP 세그먼트의 data에 http message가 포함되게 되는 것입니다.
평문으로 작성된 http 메세지는 송신시 4계층을 거치며 byte array로 변환되게 되고, 반대로 수신시에는 7계층에서 byte array -> 문자열로 변환되게 됩니다.
http는 tcp를 통해 메세지를 송수신 한다고 했죠?
그런데, http의 특징중 stateless, Connectionless라는 특성은 연결지향적인 tcp/ip와는 거리가 먼 개념으로 보일 수 있습니다.
겉보기에만 그렇고, 동작하는 방식을 알아봐야 알 수 있습니다.
stateless, Connectionless 두가지 특성에 대해 좀 더 자세히 서술해 보도록 하겠습니다.
Connectionless
connectionless라고 해서 connection을 하지 않는게 아니라, 단발적으로 유지합니다.
connection을 연결해 요청을 하고, 응답을 받으면 connection을 끊습니다.
7계층의 관점에서 보자면 http는 비연결적인 특징을 지니나 4계층의 관점에서는 연결지향적이라고 할 수 있겠습니다.
서버-클라이연트간 connection의 비용도 존재할텐데, 왜 연결을 유지하지않고 단발적으로 끊을까요?
http의 request-response 모델은 각각의 요청이 독립적이므로 연결을 유지할 필요가 없습니다.
그리고 클라이언트가 필요할 때만 conection을 맺고 요청을 보냄으로써, connection pool을 절약해 다수의 클라이언트에게 서비스를 제공하기에 용이해지기 때문입니다.
하지만, 현재는 웹 초창기와 달리 웹을 통해 전달해야 하는 콘텐츠들이 늘어나며 tcp 연결의 재사용이 필요하게 되었습니다.
또한 인터넷의 대중화로 물리적으로 먼 거리의 server-client의 연결은 connection만으로도 상당한 시간이 걸리게 되었죠.
이에 나온 기술이 Persistent Connection(혹은 keep-alive, conneciton reuse)입니다.
http 메세지에 Connection: keep-alive 헤더를 추가해 tcp연결을 http응답이후 끊지 않고 계속 사용하겠다는 의미입니다.
이를 통해 tcp connection 횟루를 줄여 cpu 및 메모리 자원을 절약하고 네트워크의 혼잡 및 지연의 수를 줄일 수 있게 되었습니다.
하지만, tcp 연결이 늘어나면 결국 서버의 자원이 고갈되어 많은 클라이언트의 접속에 대처할 수 없게 되므로 서버의 가용성을 고려해 어디서 사용해야할지에 대해 고민이 필요하게 됩니다.
이를 극복하기 위해 http/2버전에서 더욱 발전하여 multiplexing라는 기능이 추가되었습니다.
기존엔 하나의 connection에서 하나의 request만을 전송했었는데요,
multiplexing 기술은 하나의 connection에서 다수의 request를 보내는 기술입니다.
즉, 단일 tcp연결이지만, 각각 고유 식별자가 할당된 스트림 통해 요청을 병렬로 동시에 전송합니다.
요청이 동시에 여러개를 보냄으로써 대기시간이 단축하고 서버의 리소스를 효율적으로 사용해 오버헤드를 최소화 할 수 있게 되었습니다.
Stateless
Connectionless특성에 의해 생긴 http의 특징입니다.
서버-클라이언트는 연결을 유지하지 않고 단발적으로 요청-응답을 하게 되므로, 매 요청이 서로 독립적이기 때문이죠.
이 특성은 서버가 클라이언트의 상태를 유지할 필요가 없어 부담이 줄고 확장성은 향상되게 됩니다.
하지만 때때로는 회원 로그인과 같은 기능에서 상태 유지가 요구되기도 하는데요, 이를 위해 나온 개념이 쿠키, 세션, 토큰의 매커니즘입니다.
정리해 보자면, Http는 TCP기반으로 동작하므로 3-way handshake와 같은 연결 방법이나, 특성들을 모두 지니고 있습니다.
http는 메세지의 형식을 정의하고, 해당 메세지를 tcp/ip 프로토콜을 통해 송신합니다.
4. http/3와 UDP
결국 신뢰성 확보를 위한 3-way handshake라는 특성에 의해 TCP표준을 지키며 더이상의 성능향상은 어려워졌습니다.
서버-클라이언트간 물리적 거리가 멀어질수록 레이턴시가 급격히 늘어나게 되는 문제점과, 패킷을 순서대로 처리하는 특성때문에 중간에 패킷이 소실되면 이후 패킷을 처리할 수 없는 Head of line Blocking문제 또한 치명적이였습니다.
이러한 문제를 극복하기 위해 http/3는 TCP대신 UDP를 선택해 TCP의 한계를 극복하고자 하였는데요,
이 내용은 다음 포스팅을 기대해 주세요!
- 1) ICMP : 네트워크 통신 문제를 진단하는데 사용하는 네트워크 계층 프로토콜 [본문으로]