HTTP/3.0란?
HTTP/3.0의 등장 배경
HTTP/2.0은 TCP 자체의 HOLB 문제와 초기 연결 설정으로 인한 시간 지연이 발생한다.
TCP의 HOLB 문제가 발생하는 원인
TCP의 연속성과 순서 보장 기능 때문에 송신측에서 데이터를 순차적으로 전송하고 수신측은 패킷의 순서를 기반으로 데이터를 재조립해야 한다.
순서 보장 기능으로 인해 패킷 지연과 손실이 발생하여 TCP의 HOLB 문제가 발생하게 된다.
- 패킷 지연: 한 패킷에서 지연이 발생하면 그 이후의 모든 패킷도 지연된다.
- 패킷 손실: 중간에 패킷이 손실되면 이후의 패킷은 재전송을 기다려야 한다.
TCP 연결과 TLS handshake
TCP로 통신하기 위해 우선 3-way handshake 과정이 필요하다.
3-way handshake는 클라이언트와 서버가 서로 연결 가능한 상태인지 확인하는 과정으로 1-RTT가 발생한다.
이후 보안 연결을 위해 TLS handshake 과정을 수행한다. (TLS 1.2)
TLS handshake 과정은 아래와 같다.
- 클라이언트가 서버에게 암호화된 연결을 시작하고 싶다는 메시지를 보낸다.
- 메시지를 전달 받은 서버는 인증서, 공개 키 등을 클라이언트에게 보낸다. (1-RTT)
- 클라이언트는 공개 키를 개인 키로 복호화한 후 그 키를 사용해 암호화된 핸드쉐이크 완료 값을 계산해서 서버에게 보낸다.
- 완료 값을 전달 받은 서버는 값이 올바른지 검증하고 확인 메시지를 보낸다. (2-RTT)
위와 같이 2번의 handshake 과정을 수행하면 3-RTT가 발생한다.
결국 TCP로 통신하는 행위 자체가 문제였던 것!
HTTP/3.0이란?
HTTP/2.0의 장점을 가져가며 TCP의 단점을 보완한 프로토콜이다.
QUIC
HTTP/3.0은 UDP 기반 프로토콜인 QUIC을 사용하여 통신한다.
QUIC은 TCP와 TLS의 기능을 합쳐서 하나의 프로토콜로 제공한다.
QUIC handshake 과정은 기존의 TCP 3-way handshake와 TLS handshake를 합친 것과 유사하며 1-RTT만에 연결이 가능하다.
멀티플렉싱
HTTP/3.0의 멀티플렉싱은 QUIC을 기반으로 동작하며 독립 스트림 방식으로 HTTP/2.0의 멀티플렉싱을 개선했다.
0-RTT
한 번 HTTP 연결이 이루어진 서버와 클라이언트는 이전 설정값을 가져와서 handshake 과정을 건너뛸 수 있다.
암호화
QUIC은 기본적으로 전송 계층에서 암호화된 연결을 설정하므로 애플리케이션 계층 데이터가 항상 암호화된다.
연결 유지
스마트 폰이 WiFi에서 셀룰러 데이터로 전환될 때 HTTP/2.0에서는 handshake 과정을 다시 거쳐서 연결해야하지만 HTTP/3.0에서는 Connection ID를 통해 handshake 과정을 생략할 수 있다.