HTTP/3와 QUIC 전송 계층의 패킷 손실 복구 및 혼잡 제어 메커니즘
QUIC은 ACK 기반 손실 판정과 혼잡 제어로 전송을 조절합니다. 0-RTT와 1-RTT는 Application Data 패킷 번호 공간을 공유하며, 스트림별 전달은 독립적일 수 있지만 연결의 혼잡 상태는 공유됩니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
QUIC 손실 복구는 ACK를 바탕으로 손실된 전송을 찾아 필요한 정보를 다시 보내고, 혼잡 제어는 한 연결의 스트림들이 공유하는 전송 한도를 조절합니다.
1. QUIC 패킷 번호와 재전송 정보
QUIC은 암호화 레벨마다 패킷 번호 공간을 단순히 하나씩 두지 않습니다. RFC 9002 §4.1에 따르면 0-RTT와 모든 1-RTT 세대는 Application Data 패킷 번호 공간을 공유하며, 각 공간 안에서 번호를 되풀이하지 않습니다. 패킷 번호는 전송을 식별하고 순서를 추적하는 데 쓰입니다. 손실된 패킷의 정보가 필요하면 원래 패킷을 그대로 복제하지 않고 필요한 프레임을 새 번호의 패킷에 담습니다. 수신자는 ACK의 번호 범위로 받은 전송을 알리고, 송신자는 새로 확인된 패킷의 전송 시각 등으로 RTT 표본을 계산합니다. ACK 하나만으로 경로 지연을 오차 없이 알 수 있는 것은 아니므로 ACK 지연, 재정렬과 측정 조건도 고려합니다.
2. 손실 선언과 PTO는 서로 다른 절차
RFC 9002는 ACK 정보를 바탕으로 패킷 손실을 판단하는 기준으로 패킷 수 임계값과 시간 임계값을 설명합니다. 권고된 패킷 임계값은 3이며, 시간 기준은 최신 RTT와 평활 RTT 중 큰 값의 9/8을 바탕으로 합니다. 이는 구현이 네트워크 재정렬을 잠시 허용한 뒤, 충분히 뒤처진 미확인 패킷을 손실로 처리하도록 돕습니다.
PTO(Probe Timeout)는 다른 문제를 다룹니다. 확인을 요청하는 패킷이 비행 중인데 손실 판정을 위한 ACK가 도착하지 않으면, 송신자는 RTT 추정치와 변동폭, 적용되는 경우 최대 ACK 지연을 이용해 PTO 시점을 계산합니다. 타이머가 만료되면 하나 또는 두 개의 ACK 유도 패킷을 보내 응답을 다시 끌어냅니다. PTO 만료만으로 미확인 패킷이 손실이라고 선언되는 것은 아니며, 혼잡 창을 자동으로 1 MSS로 줄이지도 않습니다. 이후 ACK나 시간 임계값이 손실을 확인하면 복구 로직이 실행됩니다. 이 구분은 타임아웃을 곧바로 재전송 또는 연결 실패와 동일시하지 않게 해 줍니다.
3. 혼잡 제어가 보내는 속도 신호
손실 복구와 혼잡 제어는 연결되어 있지만 같은 기능은 아닙니다. 복구 로직은 어떤 패킷의 정보가 확인되지 않았는지 추적하고, 혼잡 제어는 네트워크가 감당할 수 있는 전송량을 조절합니다. RFC 9002의 부록은 구현 예시로 느린 시작, 혼잡 회피, 복구 상태를 보여 줍니다. 예시 알고리즘은 새로운 혼잡 이벤트에서 혼잡 창을 줄이고, 확인된 데이터와 상태에 따라 다시 늘립니다. 이는 모든 QUIC 구현이 반드시 같은 혼잡 제어 알고리즘을 써야 한다는 뜻은 아닙니다. 실제 동작은 구현과 설정, 경로의 ACK 및 손실 신호에 따라 달라집니다.
RFC 9002 부록 B의 예시 알고리즘에서는 손실 또는 ECN 혼잡 신호가 새 혼잡 이벤트로 확인되면 복구 기간에 들어가 혼잡 창을 줄이고, 손실이 지속 혼잡으로 판단되면 최소 창까지 낮춥니다. ACK가 돌아올 때마다 무조건 창을 키우는 것은 아닙니다. 애플리케이션이나 수신 측 흐름 제어에 막힌 경우, 또는 복구 기간에 해당하는 데이터에는 증가를 적용하지 않습니다. 이 설명은 RFC의 예시 제어기 동작이며 특정 브라우저나 서버가 반드시 같은 수치를 사용한다는 의미는 아닙니다.
4. 전문가 관점: HTTP/2와 HTTP/3에서 손실이 미치는 범위
HTTP/2는 여러 HTTP 스트림을 하나의 TCP 연결에 실어 보냅니다. TCP는 바이트 순서를 보장하므로 중간 바이트가 유실되면 뒤에 도착한 바이트도 빠진 구간이 복구될 때까지 애플리케이션에 순서대로 전달되지 못할 수 있습니다. 이 전송 계층의 대기는 한 TCP 연결을 공유하는 HTTP/2 스트림에 영향을 줄 수 있습니다.
HTTP/3는 QUIC 스트림을 사용해 스트림별 오프셋과 순서 전달을 관리합니다. 한 스트림에 필요한 데이터가 유실되면 그 스트림의 후속 데이터 전달은 기다릴 수 있지만, 다른 스트림의 데이터를 같은 순서 대기 때문에 멈출 필요는 없습니다. Cloudflare의 설명도 대부분의 경우 한 스트림의 손실이 다른 스트림을 막지 않는다고 하면서, QUIC 연결의 혼잡 상태는 공유된다고 명시합니다. 그러므로 “손실 영향이 완전히 격리된다”거나 “모든 페이지가 더 빨라진다”고 말할 수는 없습니다. 공유 혼잡 제어와 연결 수준 흐름 제어는 여전히 전송에 영향을 줍니다.