[Network] HTTP 프로토콜 버전 이해 - HTTP/1.0, HTTP/1.1, HTTP/2.0, HTTP/3.0, and QUIC

HTTP 간단한 설명

HTTP( Hypertext Transfer Protocol)로 웹에서 클라이언트와 서버 간 통신을 위한 프로토콜입니다.

HTTP를 이용한 데이터 전달은 TCP 세션 기반으로 이루어집니다. (Application 계층에 속함)

---

HTTP/1.0

HTML 문서만 날리는 HTTP/0.9와 다르게 다양한 파일(css, image)을 받을 수 있게 되었습니다.

 

세부 설명

1. 매번 새로운 연결로 성능 저하
   • 하나의 데이터를 받을 때마다 서버 측에서 연결을 끊습니다.
   • 요청마다 TCP 세션을 맺어야 합니다.
2. 서버 부하 비용 상승
   • RTT 증가 : 패킷이 목적지에 도달하고, 다시 출발지로 돌아오기까지 걸리는 시간입니다. (패킷 왕복 시간)
3. HTTP 1.0은 기본적으로 Connection 당 하나의 요청을 처리합니다.
   • 동시 전송은 불가능하고 하나의 요청에 대한 응답이 온 후 다음 요청을 처리할 수 있습니다.

HTTP/1.1

HTTP 1.0과 차이점은 "TCP 세션을 지속적으로 유지할 수 있는가" 입니다.

 

세부 설명

1. Persistent Connection
   • 지정한 timeout 동안 커넥션을 닫지 않는 방식입니다.
   • Persistent 기능을 이용하여 한 개의 TCP 세션을 통해 여러 개의 콘텐츠 요청을 보낼 수 있습니다.
   • 이를 통해 1.0에서 발생한 TCP 세션 처리 부하를 줄일 수 있습니다.
2. Pipelining
   • 하나의 Connection에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 단축합니다.
   • HTTP/1.1은 동시에 요청을 보내고 이에 대해 응답을 처리할 수 있어 응답 속도가 빨라졌습니다.
3. Host Header
   • Host Header에 추가를 통해 Virtual 호스팅이 가능합니다.

 

단점

• HTTP Pipelining
  - HTTP 1.0의 Network Latency를 개선하기 위해 Pipelining이 도입되었지만, 구현하기 힘들며, HOL Blocking이 발생합니다.

• HOL(Head of Line) Blocking
  - 어떤 요청에 병목이 생겨서 전체 latency가 증가하는 것을 의미합니다.
  - TCP를 사용하는 통신에서 패킷은 무조건 정확한 순서대로 처리되어야 합니다. 수신 측은 송신 측과 주고 받은 시퀀스 번호를 참고하여 패킷을 재조립해야 하기 때문입니다.
  - 따라서, 중간에 패킷이 손실될 경우 완전한 데이터로 재조립하기 어렵기 때문에 송신 측은 해당 패킷이 제대로 전달되지 않았을 경우 재전송 해야 합니다.

• 무거운 Header
  - Client-Server 간 수 많은 http 요청이 발생할 것이고, header의 정보는 대부분 동일합니다.
  - 하지만 HTTP 1.1에서는 헤더를 중복해서 보낼 뿐만 아니라 cookie 정보 역시 매 요청마다 헤더에 포함하여 전송합니다.
  - 불필요한 데이터를 주고 받는데 네트워크 자원이 소비되는 문제가 발생합니다

 

HTTP/2.0

시간이 지나면서 웹에서 담아야 할 정보가 늘어나고 수 많은 멀티미디어 리소스들과 비동기 요청들이 발생함에 따라,

2015년 기존 HTTP/1.x 버전의 성능 향상에 초점을 맞춘 HTTP 2.0이 등장했습니다.

HTTP 2.0은 새로운 기능 확장이 아닌 기존 HTTP 버전이 가지고 있는 문제점과 성능을 개선하였습니다.

 

세부 설명

1. HTTP 메시지 전송 방식의 변화
   • binary framing 계층 사용
   •  파싱, 전송 속도 ⬆️, 오류 발생 가능성 ⬇️
2. Request and response multiplexing (I/O Multiplexing)
   • HTTP 1.1의 HTTP Pipelining의 개선안으로 하나의 Connection을 통해 동시에 여러 개의 메세지를 주고 받을 수 있습니다.
   • 또한, 응답은 요청 순서에 상관없이 Stream으로 받기 때문에 HOL(Head Of Line) Blocking 문제도 해결됩니다.
   • 여러 개의 스트림을 사용하여 송수신한다는 것. 이를 통해 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작할 수 있습니다.
3. Stream Prioritization
   • 리소스간 우선 순위를 설정 가능
   • 응답에 대한 우선순위를 정해 우선순위가 높을수록 응답이 빠름
4. Server Push
   • 클라이언트가 요청하기 전에 HTTP/2 호환 서버가 리소스를 HTTP/2 호환 클라이언트에 보낼 수 있음
   • 서버 푸시는 클라이언트가 리소스가 필요할지 알기도 전에 미리 리소스를 로드하여 대기 시간을 줄이는 것을 목표로 하는 성능 기술
   • 즉, 서버가 클라이언트의 요청없이 응답을 보내는 방법으로 클라이언트의 요청을 최소화하여 서버가 리소스를 보내주는 방식
5. Header Compression

• HTTP 1.1의 경우 이전 요청과 중복되는 Header도 똑같이 전송하여, 네트워크 자원을 불필요하게 낭비했습니다.
• HTTP 2.0의 경우, 헤더의 크기를 줄여 페이지 로드 시간 감소시켰습니다.
• Header Table과 Huffman Encoding을 사용하는 HPACK 압축방식으로 이를 개선
• 클라이언트와 서버는 각각 Header Table을 관리하고 이전 요청과 동일한 필드는 table의 index만 보내고, 변경되는 값은 Huffman Encoding 후 보냄으로서 Header의 크기를 경량화

 

HTTP/3.0

2020년 등장하였으며, TCP 위에서 돌아가는 이전 버전과 달리 HTTP3는 QUIC이라는 계층 위에서 돌아갑니다.

 TCP 기반이 아닌 UDP 기반으로 돌아갑니다.

또한, http/3.0에서는 무조건 https를 사용한다.

 

QUIC (Quick UDP Internet Connections)

전송 계층 프로토콜

순방향 오류 수정 메커니즘 적용

- 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며, 어느 네트워크 환경에서도 낮은 패킷 손실률이 보장됩니다.

Connection UUID 라는 고유한 식별자로 서버와 연결함 (Connection 수립이 필요없음)

 

TCP가 아닌 UDP를 사용하는 이유

• TCP 헤더는 신뢰성을 보장하지만 지연을 줄이기 힘듦
• UDP는 데이터 전송에 집중한 설계로 속도가 빠름
• 헤더 압축 또한 HPACK이 아닌 QPACK을 사용