HTTP/3

손정만·2022년 7월 11일
0

요약

  • 구글 내부에서 사용되던 QUIC (Quick UDP Internet Connections) 프로토콜을 웹통신에 적용
  • QUIC 은 UDP 기반으로 구성된 프로토콜, 핸드쉐이킹 과정을 개선
  • QUIC 안에 TLS 가 내포되어 HTTPS 가 필수

HTTP/2

2015년 IETF에 의해 공식적으로 발표
구글의 SPDY를 기반으로 HTTP/1.1 을 개선

SPDY

기존의 HTTP의 데이터 전송 포맷과 커넥션 관리 부분을 고쳐서 TCP 커넥션을 보다 효율적으로 쓰도록 만든 것

Server Push

기존엔 클라이언트는 요청한 HTML문서를 수신한 후 HTML문서를 해석하면서 필요한 리소스를 재요청.
HTML문서에 포함된 리소스를 Push 해주는 방법으로 클라이언트의 요청을 최소화 해서 성능 향상

HTTP Header Data Compression

Static/Dynamic Header Table을 통해 중복된 header 전달을 피하고,
Huffman Coding 알고리즘을 쓰는 HPACK으로 압축하여 전달

멀티플렉싱 (multiplexing)

둘 이상의 데이터 스트림을 단일 물리적 연결로 결합하는 프로세스이며 TCP는 소스 및 대상 포트 번호를 사용하여 다중화 기능을 제공합니다. 이러한 포트 번호를 통해 TCP는 물리적 연결을 통해 여러 가상 연결을 설정하고 해당 연결을 통해 데이터 스트림을 다중화가 가능.
이 질문 에서 처럼 멀티 플렉싱은 소켓에서도 적용된다.

HOLB(Head of line Blocking)
HTTP2에선 handshake 이후 하나의 TCP 연결로 다중 요청 (멀티플렉싱) 을 처리하도록 하여 개선하였다.
이런 다중 요청이 가능해짐에 따라 Stream 우선순위 (Stream Prioritization) 와 같이 병렬 요청시,
우선순위 지정이 가능하도록 되었다.

HTTP/3

통신 구조의 차이

패킷구조

L4 스위치
로드밸런싱 처리 방법 중 L4 는 OSI 7계층의 Trasport 계층에서 처리되는것

참조

TCP / UDP

HTTP 통신에서 TCP 는 3way-Handshake 를 거쳐 검증 후 데이터를 가상 회선을 통해 클라이언트로 전달된다.
이 과정을 통해 데이터의 순번을 유지한채로 지정된 라우터 회선을 통해 전달 받게된다.
HOLB(Head of line Blocking) 는 순번을 유지하는 이런 과정에서 발생된다.

HTTP2 에서 HOLB 가 개선되었으나 다른 종류의 문제는 남아있었다.
TCP 스트림에서 하나의 손실된 패킷을 다시 전송 및 수신될 때까지 모든 스트림을 대기하게 된다.

하지만 UDP는 전달이 중점이 되기에 전달되는 라우터 경로 / 순번은 관계 없이 목적지만을 지정하여 전달된다.

TCPUDP
패킷
전달
구조

구조 비교

QUIC 은 기본적으로 TLS를 포함하게 된다.
UDP 의 특성상 handshake 과정이 없는것을 TLS 를 통하여 보장하고자 하는것으로 생각된다.

HTTP/2HTTP/3
프로토콜TCP + TLSQUIC (UDP + TLS)
시퀀스

HTTP/3 특징

기본적으로 QUIC 내에 TLS 이 포함되어있기 때문에 TCP와 달리 헤더 영역도 같이 암호화된다.

패킷 손실 감지

TCP 에서 ARQ를 사용하여 패킷 손실을 처리하게 되는데
QUIC 에서도 패킷 손실 대응을 위해 Packet number 헤더 항목이 있다.

ARQ (Automatic Repeat Request)

QUIC 의 손실감지 특징

  • Packet number는 별도의 공간을 사용한다.
    패킷번호가 클수록 나중에 전송되었음을 의미하여 이를 통해 누락된 패킷을 간략하게 검증한다.
  • ACK 영역이 TCP 에 비해 더 커서 손실 회복이 더 빠르다.

Connection ID

Connction ID는 각 연결은 연결 식별자나 연결 ID를 가지므로 이를 통해 연결을 식별한다. 엔드포인트가 자유롭게 연결 ID를 선택한다. 각 엔드포인트는 엔드포인트의 피어가 사용할 연결 ID를 선택한다.
이 연결 ID의 주요 기능은 하위 프로토콜 계층(UDP, IP 혹은 그 아래 계층)에서 주소가 변경되더라도 QUIC 연결의 패킷이 잘못된 엔드포인트로 전달되지 않도록 보장하는 것이다.

Connection ID는 IoT 분야에 더욱 유리한 장점으로 적용될 것 이다.

그래서 사용은?

java

https://github.com/ptrd/kwik
https://github.com/cloudflare/quiche
https://kachayev.github.io/quiche4j/
https://webtide.com/jetty-http-3-support/
https://blog.cloudflare.com/experiment-with-http-3-using-nginx-and-quiche/

go

https://pkg.go.dev/github.com/lucas-clemente/quic-go#section-readme
https://github.com/lucas-clemente/quic-go

참조

0개의 댓글