[Network] HTTP/3 and QUIC

QUIC (Quick UDP Internet Connection) to HTTP/3

• 구글에서 만든 프로토콜, 2013년 6월 공개
• IETF(Internet Engineering Task Force)에 QUIC 프로토콜 표준화를 제안
• Google-QUIC은 오로지 HTTP만 전송했으나 IETF QUIC 워킹 그룹을 통해 IETF-QUIC 은 TLS 1.3의 암호화 보안 적용
• HTTP-over-QUIC은 2018년 11월에 HTTP/3로 개명
• 2021년 5월 RFC 9000으로 버전 1 공식화

RFC

출처: www.saturnsoft.net/network/2021/05/27/quic-rfc9000/

• RFC 8999 Version-Independent Properties of QUIC - 통칭 Invariants. 버전에 관계없이 공통적인 사항에 대한 것입니다.
• RFC 9000 QUIC: A UDP-Based Multiplexed and Secure Transport - 통칭 Transport. 제일 중심이 되는 내용으로 패킷 포맷, 상태 머신, 기본적인 동작
• RFC 9001 Using TLS to Secure QUIC - 통칭 QUIC-TLS. QUIC은 기본적으로 암호화를 해야 하는데 TLS 1.3 기반으로 확장
• RFC 9002 QUIC Loss Detection and Congestion Control - 통칭 Recovery. Transport에 추가하여 손실 복구 및 혼잡 제어 알고리즘

HTTP/2 vs HTTP/3

공통점	차이점
스트림을 이용해서 하나의 연결을 통해 멀티플렉싱 제공	0-RTT handshake는 더 빠르고 나은 data를 전송/TCP Fast Open + TLS는 더 적은 데이터를 보내지만, 종종 문제 발생
서버 푸시 제공	TCP + TLS 보다 QUIC이 빠른 handshake를 보여준다.
헤더 압축 제공(QPACK과 HPACK은 설계상 비슷)	HTTP/3는 암호화가 기본 / HTTP/2는 암호화가 안돼도 된다.
	HTTP/3는 우선순위가 없다.
	HTTP/2가 ALPN 확장을 이용하여 즉시 TLS 핸드쉐이크 협상을 완료/ HTTP/3는 QUIC을 사용하므로 클라이언트에 Alt-Svc: 헤더 응답이 먼저 있어야 한다.

왜 QUIC

• TCP의 한계
  • Head Of Line 문제
• 고착화(Ossification) 방지
  • 미들박스^[각주:1]가 지나가는 프로토콜에서 많은 것을 볼 수 없도록 통신을 최대한 암호화
• 안전(TLS 1.3이 default)
  • 고착화를 방지하고 HTTPS의 모든 보안 속성을 갖는다.
• 0-RTT, 1-RTT 핸드쉐이크 둘 다 제공하여 새로운 연결 시간을 줄여준다.
  • "이른 데이터(early data)"를 처음부터 지원하고 이는 TCP Fast Open보다 더 쉽게 사용 가능

HTTP/3의 핵심은 UDP

HTTP/3는 TCP 프로토콜 자체가 갖는 느리다는 문제를 해결하기 위해 UDP를 사용

• UDP는 데이터 전송 자체에만 초점을 맞추고 설계되었기 때문에 헤더가 갖고 있는 정보가 몇 개 없다.
• 헤더가 비워져 있기 때문에 마음대로 Custom 할 수 있는 UDP를 사용 하여 프로토콜 설계

 

특징

TCP가 갖는 문제를 해결하기 위해 UDP를 커스텀한 QUIC 프로토콜이 갖는 특징들이 있다.

A. 0-RTT handshakes

handshake를 제거했기 때문에 1RTT^[각주:2](Round Trip Time)만 사용된다.  (TCP는 TLS까지 하면 3 RTT)

• 첫 번째 핸드 셰이크를 거칠 때, 연결 설정에 필요한 정보와 함께 데이터도 보내는 방법

B. 개선된 혼잡 제어

Congestion Control Tuning of the QUIC Transport Layer Protocol - 2.3 Congestion control

혼잡 제어의 목적은 시스템 과부하 상태를 보통의 로드 상태와 안정적인 OS로 복구하는 데 있다. TCP와 다르게 UDP는 혼잡 제어가 없다. 아무 제약 없이 사용하면 다른 네트워크 프로토콜 대역폭에 침해될 수 있다. 따라서 Cubic과 Packet pacing과 같은 TCP의 혼잡 제어를 구현했다. 

TCP의 혼잡 제어를 그대로 구현한 거처럼 보이지만 다른 점들이 있다.

 

*TCP와 Quic의 표준 혼잡 제어는 NewReno. Cubic과 Reno 차이 참고

Pluggable

• 다양한 레벨의 혼잡제어 알고리즘이 운영체제나 커널의 도움 없이 애플리케이션 레벨에서 구현될 수 있다.
• 단일 애플리케이션에서의 다른 연결들을 서로 다른 혼잡 제어를 설정 할 수 있다.
• 혼잡제어 변경은 downtime이나 upgrade 없이 구현될 수 있다.

 QUIC Loss Detection and Congestion Control - 4.Relevant Differences between QUIC and TCP

1. Seperate Packet Number Spaces

encryption level에서 별도의 packet number 공간을 사용한다. 별도의 패킷 번호 공간을 사용하면 한 단계의 encription 된 packet이 다른 단계의 encription된 잘못된 패킷이 재전송되는 것을 막습니다.

2.  Monotonically Increasing Packet Numbers

TCP의 byte order number와 ACK로 메시지가 순서대로 도착했는지 확인하는 방법을 사용하지 않는다.  Quic은 Packet number를 사용한다. 각각의 Packet Number는 엄격하게 증가된다. 따러서 N번째의 Packet이 유실되어도 N number는 사라지지 않는다. Monotic 하게 증가하는 Packet Number로 TCP 재전송 모호성^[각주:3](retransmission ambiguity)를 해결한다.

3. Clearer Loss Epoch

QUIC은 packet이 손실됐을 때 loss epoch가 실행된다. Epoch^[각주:4] 시작 후 전송된 패킷이 확인되면 손실 Epoch가 종료된다. TCP는 시퀀스 번호 공간의 공백이 채워질 때까지 기다리기 때문에 세그먼트가 연속으로 여러 번 손실되면 loss epoch는 몇 번의 round trip 동안 끝나지 않을 수 있다. TCP와 UDP 모두 epoch 당 congestion window를 한 번만 줄이려고 하는데 QUIC는 손실이 발생하는 모든 왕복에 대해 한 번만 이 작업을 수행하는 반면 TCP는 여러 왕복에 걸쳐 한 번만 수행한다.

4. No Reneging

TCP의 SACKs와 비슷하다. 다만, QUIC은 패킷 ack 취소(reneg ^[각주:5])를 허용하지 않고 양쪽 사이드에서의 구현을 단순화하고 sender의 메모리 압박을 줄였다.

5. More ACK Ranges

TCP가 세 개의 SACK만 있는 것에 비해 QUIC은 많은 ACK 범위를 지원한다. 높은 손실이 있는 환경에서는 복구 속도를 높여주고, 

QUIC는 TCP의 세 가지 SAK 범위와 반대로 많은 ACK 범위를 지원한다. 손실률이 높은 환경에서는 복구 속도를 높이고, 거짓된(spurious) 재전송을 줄이며, 시간 초과에 의존하지 않고 향후 진행이 보장된다.

6. Explicit Correction for Delayed Acknowledgments

QUIC 엔드포인트는 패킷이 수신되는 시점과 해당 수신확인이 전송되는 시점 사이의 지연을 측정하여 peer가 보다 정확한 RTT 측정을 하게 한다. see 13.2 section

7.  Probe Timeout Replaces RTO and TLP

QUIC은 TCP의 RTO을 기초로 probe timeout(PTO; see Section 6.2)를 사용한다.  TCP의 loss 탐지 알고리즘인 RACK-TLP와 비슷 하게 PTO 동안 윈도우를 줄이지 않는다. 대신에 QUIC은 영구적인 정체가 생기면 윈도우를 줄인다. see Section 7.6

8. The Minimum Congestion Window Is Two Packets

TCP는 최소한의 congestion window를 사용한다. 하지만 하나의 패킷이 손실되면 sender는 PTO 동안 기다려야 하고 이거는 RTT보다 길어질 수가 있다. 따라서 QUIC은 최소한의 congestion window를 패킷 두 개로 하기를 권장한다. 이렇게 하면 네티워크 부하를 늘리지만 persistent congestion에서 잠재적으로 sender의 sending 비율을 잠재적으로 낮추기 때문에 안전하다고 여거진다. see Sectio 6.2

9. Handshake Packets Are Not Special

TCP는 SYN 또는 SYN-ACK 패킷의 손실을 지속적인 혼잡으로 처리하고 congestion window를 하나의 패킷으로 줄인다. QUIC는 handshake 데이터를 포함하는 패킷의 손실을 다른 손실과 동일하게 취급한다.

C. 멀티 플렉싱

좌)HTTP/2, 우)HTTP/3, https://http3-explained.haxx.se/ko/why-quic/why-tcphol

HTTP/2: 는 하나의 컨넥션에서 여러 스트림이 FIFO로 처리된다. 따라서 중간에 패킷이 손실이 되면 뒤에 있는 스트림들이 blocking 되는  TCP 프로토콜이 갖는 문제점

HTTP/3: UDP를 사용하기 때문에 패킷들이 독립적이다. 따라서 스트림들이 앞선 스트림에 의해 blocking이 되지 않는다.

D. Connection Migration

서로 다른 네트워크 간에(가정의 와이파이 네트워크에 연결되어 있다 출근할 때 집에서 나서면 휴대폰 모바일 네트워크로 연결되는 경우 등) 새로 연결을 만들지 않고 끊김 없이 기존의 연결이 이전된다.

Connection ID로 연결을 식별하게 된다. 

chrome://net-export에서 로그를 확인한 후netlog-viewer.appspot.com/#quic에서 connection ID를 확인할 수 있었다.

*FYR: 어떻게 conneciton ID가 만들어지게 대한 답변이 달렸으면 좋겠다. 

 

 

E. Default TLS 1.3

QUIC은 보안 통신을 기본으로 강제한다.

• round trip 절약(TLS handshake와 QUIC handshake가 동시에 이뤄지기 때문)
• 더 넓어진 encription

www.smashingmagazine.com/2021/08/http3-core-concepts-part1/

HTTP/3 도입이 어려울 수 있다.

• QUIC은 CPU를 너무 많이 사용한다
• 커널에서 UDP는 느리다.
• (DNS에서 사용하는) 53 포트가 아닌 UDP 트래픽이 최근에는 주로 공격에 사용되기 때문에 많은 기업, 운영자, 조직에서 차단하거나 속도를 제한하고 있다.
• 이미 기존 버전에 최적화 한경우 다시 최적화해야 하는 부담
  • 도메인 분할을 적용한 경우 오히려 멀티플렉싱 기반 프로토콜이 성능 반감시킬 수 있다
  • Prefetch를 적용한 경우 Server Push를 할지 말지 성능 비교 필요
• 보안 취약점이나 사례가 부족 
  • QUIC is used by 7.3% of all the websites. W3 Tech
• 기존에 암호화하지 않고 있던 헤더까지 암호화되어 이런 헤더의 정보를 사용하는 ISP나 네트워크 중계회사들은 고민
• QUIC은 패킷 별로 암호화
  • 기존의 TLS-TCP에서 패킷을 묶어서 암호화하는 것보다 더 큰 리소스 소모를 불러올 수 있다

 

 

---

Reference

• blog.cloudflare.com/ko-kr/cubic-and-hystart-support-in-quiche-ko-kr/
• blog.cloudflare.com/the-road-to-quic/
• ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12154
• www.hamilton.ie/net/htcp3.pdf
• medium.com/codavel-blog/quic-vs-tcp-tls-and-why-quic-is-not-the-next-big-thing-d4ef59143efd
• www.saturnsoft.net/network/2021/05/27/quic-rfc9000/
• www.youtube.com/watch?v=dQ5AND4DPyU
• http3-explained.haxx.se/ko/why-quic
• m.blog.naver.com/sehyunfa/221680799006
• www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
• blog.cloudflare.com/ko-kr/cubic-and-hystart-support-in-quiche-ko-kr/
• evan-moon.github.io/2019/10/08/what-is-http3/#3-way-handshake
• datatracker.ietf.org/doc/rfc9002/

 

1. endpoint 사이에 있는 네트워크 장비 [본문으로]
2. 클라이언트가 보낸 요청을 서버가 처리한 후 다시 클라이언트로 응답해주는 사이클 [본문으로]
3. RTT 측정에서 패킷 손실이 발생하여 애매해진 상황으로 timestamp를 패킷에 찍어주는 방법이 있다. [본문으로]
4. We define an epoch of a TCP connection to be th e time period during which an entire window 's worth of packets have been acknowledged. Some Observations on the Dynamics of a Congestio n Control Algorithm [본문으로]
5. Transport layer reneging [본문으로]