HTTP/1.0 → HTTP/1.1 → HTTP/2.0 → HTTP/3.0 버전별 차이를 이해하기
HTTP 버전마다 어떤 단점이 있었고, 다음 버전에서 그 단점을 어떻게 해결했는지를 소개하고자 합니다.
HTTP/1.0
HTTP/1.0 은 서버와 클라이언트간에 Connection 을 지속하지 않습니다.
즉, 클라이언트가 서버와 Connection 을 맺기 위해 DNS 조회, TCP 3-way handshake, SSL/TLS handshake 같이 네트워크 지연 시간을 늘리는 행위를 1개의 요청 마다 반복적으로 했다는 것이었습니다.
이는 매우 불필요한 행위이기 때문에, HTTP/1.1 은 이를 최적화 하게 됩니다.
HTTP/1.1
▶ HTTP/1.1 의 기능 : Keep-Alive
그래서, HTTP/1.1 부터 매 요청마다 Connection 을 맺지 않기 위해 서버와 클라이언트간의 Connection 을 Keep-Alive 하게 유지합니다.
* Keep - Alive : 클라이언트와 서버간의 연결을 유지하여 하나의 TCP 연결로 여러 개의 요청/응답을 처리할 수 있는 상태
이 덕분에 하나의 TCP Connection 을 통해 여러 개의 요청/응답을 처리할 수 있게 되었습니다.
그렇게 Keep-Alive 는 HTTP/1.1 부터 기본 동작으로 포함되었습니다.
만약, 클라이언트가 서버와의 연결을 끊고 싶다면 Connection: close 를 헤더에 포함시켜 서버에 명시적으로 요청할 수 있습니다.
▶ HTTP/1.1 의 기능 : 파이프라이닝
또한, HTTP/1.1 은 파이프라이닝 기능도 있었습니다.
파이프라이닝이란 클라이언트 요청에 대한 응답을 기다리지 않고도 단일 TCP 연결을 통해 여러 HTTP 요청을 보내는 것입니다.
▶ HTTP/1.1 의 기능 : 파이프라이닝의 단점
그러나, 파이프라이닝은 요청 순서에 맞게 응답을 받아야 하는 치명적인 단점이 있습니다.
예를 들어, 클라이언트가 [요청1, 요청2, 요청3] 순으로 요청하면 [응답1, 응답2, 응답3] 순으로 응답을 받아야 합니다.
만약, 응답2가 가장 먼저 클라이언트에게 왔다면, 응답2는 응답1이 오기 전까지 처리되지 않고 기다리게 됩니다.
이렇게 동일한 Connection 에서 특정 요청에 대해 후속 요청이 영향을 받는 것을 Head of Line Blocking(HOL Blocking)이라 합니다. 그래서, HTTP/2.0 에서는 HOL Blocking 을 해결하고자 합니다.
추가로, 파이프라이닝은 구현이 어려웠고, 프록시(중계) 서버가 파이프라이닝을 제대로 처리하지못해서 크롬, 파이어폭스 같은 브라우저는 결국 이 파이프라이닝을 지원하지 않게 되었습니다.
HTTP/2.0
▶ HTTP/2.0 의 기능 : frame 과 Stream 소개
우선 HTTP/1.1 에서 메시지를 text 로 보냈다면, HTTP/2.0 은 text를 binary 화 하여 header 로는 header frame, body 는 body frame 이란 데이터 단위를 만듭니다(사진 출처: 링크)
이렇게 1개의 메시지는 1 or 2개의 HEADER frame 과 0개 이상의 DATA frame 으로 나뉘어서 전송되어집니다.
그리고, 이렇게 나뉜 frame 들은 TCP내에서 header frame, data frame 순으로 전송되야 하기 때문에 각 frame 들을 구분하고자 Stream Sequence 란 번호를 frame 에 붙입니다.
이렇게 같은 번호인 frame 들을 Stream 이란 개념으로 구분짓게 됩니다.
ex) 1번 header frame + 1번 data frame + 1번 data frame 을 1번 Stream 으로 부릅니다.
▶ HTTP/2.0 의 기능 : multiplexing (멀티플렉싱)
이렇게, 1개의 메시지를 여러 개의 frame 으로 나누어서 전송하게 되니 위 사진처럼 요청3의 header frame 이 요청2의 header frame 보다 먼저 올 수 있게 되었습니다.(응답이 요청 순서에 따라 처리되지 않아도 됨)
HTTP/1.1 의 문제였던 응답이 순서대로 와야해서 후속 요청들이 영향을 받는 문제인 HOL Blocking을 Application Layer 에서 해결할 수 있었습니다.
HTTP/2.0 은 스트림이라는 개념을 도입해서 파이프라이닝의 단점을 멀티플렉싱(multiplexing) 으로 극복하였습니다.
즉, HTTP/2.0은 기본적으로 하나의 TCP 커넥션을 계속 유지하면서 멀티플렉싱으로 여러 요청을 동시에 처리하는 구조라 keep-alive 헤더 자체가 의미 없어져서 keep-alive 를 deprecated 하게 됩니다.
▶ multiplexing (멀티플렉싱) 의 단점
하지만, 여전히 TCP Connection 에서 frame 들을 주고 받았기 때문에, TCP 에서 발생하는 HOL Blocking 을 해결할 순 없었습니다.
예를 들어, 사진3 에서 stream2 header 의 패킷이 손실이 되었다면 해당 stream2 header 는 손실된 패킷이 올 때까지 기다리게 되고, 그 뒤에있는 stream 1 data, 3 data, 2data 는 여전히 기다리게 되었습니다.
즉, multiplexing 은 Application Layer 에서의 HOL Blocking 은 해결했지만 Transport Layer 에서의 HOL Blocking 은 여전히 문제가 되었습니다. 이는 후에 HTTP/3.0 인 QUIC 이 나오면서 해결되었고, QUIC 을 설명할 때 다시 언급하겠습니다.
▶ HTTP/2.0 의 기능 : Server push
HTTP/2.0 의 기능으로 Server Push 가 있습니다.
Server Push 는 클라이언트가 요청하기 전에 서버가 클라이언트에 리소스를 보내는 것으로 미리 리소스를 보낸다는 점에서 네트워크 요청을 줄인다는 이점이 있을 것이라 생각되었습니다.
하지만, 클라이언트가 서버가 보낸 리소스를 알지 못하고, 리소스를 다시 요청한다는 점에서 22년 10월 Google 은 Chrome 에서 Server push 기능을 제거하였습니다.(출처 : wikipeidia - HTTP/2.0)
HTTP/3.0
▶ TCP 레벨에서의 HOL Blocking 해결
HTTP/2.0 의 TCP HOL Blocking 은 TCP 프로토콜 특성상 발생했기 때문에, 이를 해결하기 위해 HTTP/3.0 은 TCP 에 의존하지 않고, UDP 에 기반한 QUIC 프로토콜을 사용하게 됩니다.
이 덕에, TCP 에 기반한 Stream 들이 UDP 에 기반한 QUIC 프로토콜을 사용하게 되면서 각 스트림들은 독립적이게 되었습니다.
예를 들어, 사진5에서 1번 패킷이 손실되었다면, TCP 기반에서는 2~8번까지의 패킷이 모두 Blocking 되지만 UDP 기반의 QUIC 프로토콜에서는 2,3 번의 패킷만 Blocking 되게 되었습니다.
▶ HTTP/3.0 의 기능 : zero RTT Connection 달성
또한, HTTP/3.0 은 서버와 클라이언트간의 Connection 을 맺는데 0 RTT(Round-Trip Time, 단위 : ms)를 달성합니다.
TCP 연결은 1 RTT(100ms) , TCP + TLS 연결은 2~3 RTT(200~300ms) 이 걸리는 반면에 HTTP/3.0 의 QUIC 은 0 RTT 를 달성하여 연결하면서 데이터를 전송할 수 있게 되었습니다.
출처
- StackOverflow : HTTP/2 HEADERS and DATA Frames
- Youtube : ByteByteGo - HTTP/1.1 HTTP/2.0 HTTP/3.0
- Youtube : The QUIC Protocol, HTTP3, and How HTTP Has Evolved
- RFC 9113 - HTTP/2
'법, 용어 > 용어' 카테고리의 다른 글
| 스토리 기반 CMS란 (0) | 2026.03.25 |
|---|---|
| QUIC 프로토콜 (0) | 2026.03.24 |
| 용어 정리 | CRUD POST GET PUT DELETE (0) | 2026.03.19 |
| 용어 Usenet, Magnet (0) | 2026.03.19 |
| 선물 거래(Futures Trading) (0) | 2026.03.19 |