첫 바이트 시간이 줄어든다
왕복 지연이 큰 모바일과 장거리 경로에서 차이가 더 크게 보인다.
QUIC은 전송 연결과 TLS 1.3 협상을 한 왕복에 묶는다
TCP 기반 HTTPS는 먼저 TCP 연결을 만들고 그 위에서 TLS를 협상한다. QUIC은 UDP 위에서 신뢰성, 혼잡 제어, 암호화 핸드셰이크를 통합해 첫 요청까지 필요한 왕복 수를 줄인다.
TCP+TLS cold
TCP 연결 뒤 TLS 1.3, 첫 요청까지 약 2 RTT
QUIC cold
Initial에 TLS를 함께 실어 첫 요청까지 약 1 RTT
QUIC resume
조건이 맞으면 첫 패킷에 early data 포함
TCP + TLS
cold connection
SYN →
← SYN-ACK
ACK + ClientHello →
← ServerHello
Finished + HTTP →
QUIC 1-RTT
new connection
Initial + ClientHello →
← Handshake
HTTP/3 request →
QUIC 0-RTT
resumed session
Initial + early GET →
← accept / reject
1-RTT 전환
0-RTT는 replay-safe 요청만
GET처럼 중복 실행돼도 안전한 요청에 제한해야 한다.
Retry, 손실, 정책 거부 시 RTT 증가
QUIC도 네트워크 조건과 서버 판단에 따라 더 늦어질 수 있다.
커널 TCP가 아닌 사용자 공간 전송
연결 ID와 스트림 제어를 QUIC 구현이 직접 관리한다.
암호화가 선택이 아니라 기본
QUIC의 전송 제어 정보 상당 부분도 암호화 보호를 받는다.
빠르지만 모든 요청에 쓰지 않는다
멱등성, replay 방어, 서버 정책이 맞을 때만 열어야 한다.
QUIC의 속도 이득은 “UDP라서”가 아니라 핸드셰이크 통합에서 온다
HTTP/3는 UDP를 쓰지만 단순히 빠른 포트를 고른 것이 아니다. TCP와 TLS가 나누어 처리하던 연결 수립 절차를 QUIC이 하나의 보안 전송 계층으로 묶어, 새 연결은 보통 1-RTT, 재접속은 조건부 0-RTT까지 줄인다.