Wydajność TLS: QUIC i HTTP/3

HTTP/2 multipleksuje wiele strumieni w ramach jednego połączenia TCP, rozwiązując problem blokowania początku kolejki występującego osobno w każdym połączeniu HTTP/1.1. Jednak samo TCP powoduje blokowanie początku kolejki w warstwie transportowej: jeśli jeden segment TCP zostanie utracony, wszystkie znajdujące się za nim dane w kolejce czekają na retransmisję, blokując jednocześnie wszystkie strumienie HTTP/2. Utrata 1% pakietów może obniżyć wydajność HTTP/2 poniżej wydajności HTTP/1.1 korzystającego z wielu połączeń. QUIC rozwiązuje ten problem, implementując multipleksowane strumienie nad UDP, gdzie odzyskiwanie danych po utracie na poziomie strumienia nie blokuje pozostałych strumieni.

QUIC to protokół transportowy oparty na UDP, opracowany przez Google (2012–2015) i standaryzowany przez IETF jako RFC 9000 (2021). QUIC integruje TLS 1.3 w warstwie transportowej — nie istnieje oddzielny handshake TLS wykonywany nad QUIC; TLS jest wpleciony w sam handshake QUIC. QUIC zapewnia: multipleksowane strumienie bez blokowania początku kolejki, migrację połączenia (utrzymanie połączenia podczas zmiany sieci, np. z WiFi na LTE), ustanawianie połączenia 0-RTT dla ponownych połączeń oraz wbudowane wykrywanie utraty pakietów i kontrolę przeciążenia. HTTP/3 (RFC 9114) to semantyka HTTP przeniesiona na strumienie QUIC.

Handshake QUIC łączy ustanawianie połączenia z negocjacją TLS. W pierwszej wymianie pakietów (określanej w terminologii QUIC jako 0 RTT) klient wysyła pakiety Initial zawierające TLS ClientHello. Serwer odpowiada własnym pakietem Initial (ServerHello) oraz pakietami Handshake (encrypted extensions, certificate, Finished). Klient wysyła Handshake Finished i jest wtedy gotowy do przesyłania danych aplikacji — jest to 1-RTT. W przypadku połączeń 0-RTT klient wysyła pakiety 0-RTT zawierające dane aplikacji wraz z ClientHello, korzystając z klucza wyprowadzonego z sekretu wznowienia poprzedniej sesji, dzięki czemu dla sesji zapisanych w pamięci podręcznej nie są wymagane żadne dodatkowe rundy komunikacji.

QUIC używa czterech odrębnych poziomów szyfrowania odpowiadających fazom harmonogramu kluczy TLS: Initial (AEAD wyprowadzone przez QUIC z użyciem znanego klucza stałego — zapewnia integralność, ale nie poufność przed zaawansowanymi atakującymi), Handshake (wyprowadzone z TLS handshake_secret — zapewnia poufność wiadomości handshake TLS), 0-RTT (wyprowadzone z sekretu poprzedniej sesji early_secret — szyfruje dane aplikacji 0-RTT) oraz 1-RTT (wyprowadzone z TLS master_secret — szyfruje wszystkie dane aplikacji). Nagłówki QUIC są częściowo szyfrowane: numer pakietu i payload są szyfrowane, ale niektóre informacje routingu (Connection ID) pozostają widoczne dla modułów równoważenia obciążenia.

Połączenia QUIC są identyfikowane przez Connection ID (CID), a nie przez 4-tuple (src IP, src port, dst IP, dst port). Dzięki temu połączenia mogą przetrwać zmiany sieci: gdy urządzenie mobilne przełącza się z WiFi na LTE, adres IP się zmienia, ale CID pozostaje taki sam. Klient wysyła ramkę PATH_CHALLENGE nową ścieżką, a serwer odpowiada za pomocą PATH_RESPONSE, weryfikując nowy adres. Połączenie jest kontynuowane bez zakłóceń i bez ponownej negocjacji. TCP nie obsługuje tego mechanizmu — połączenie TCP jest związane z jego 4-tuple i po zmianie sieci musi zostać ustanowione ponownie, co wymaga nowego handshake TLS. Migracja QUIC znacząco poprawia odczuwaną wydajność przez użytkowników mobilnych.

HTTP/3 mapuje semantykę HTTP na strumienie QUIC. Każda para żądanie–odpowiedź HTTP zajmuje osobny dwukierunkowy strumień QUIC. Strumienie QUIC są niezależne: utrata danych na strumieniu 3 nie blokuje strumienia 7. HTTP/3 używa QPACK do kompresji nagłówków (zastępując HPACK z HTTP/2) — QPACK przeprojektowano tak, aby nie wymagał dostarczania danych w kolejności. Dwa dedykowane jednokierunkowe strumienie sterujące przenoszą ustawienia oraz instrukcje dekodera i enkodera. Server push w HTTP/3 korzysta ze strumieni push (jednokierunkowych). W rezultacie HTTP/3 osiąga największą przewagę nad HTTP/2 w warunkach utraty pakietów (sieci mobilne, przeciążone ścieżki), gdzie blokowanie początku kolejki w TCP jest najbardziej dotkliwe.

Pomiary wydajności QUIC i HTTP/3 w rzeczywistych warunkach dają różne wyniki zależnie od warunków sieciowych. W sieciach wysokiej jakości (o małych opóźnieniach i niewielkiej utracie pakietów) HTTP/3 i HTTP/2 działają podobnie — narzut QUIC (większe nagłówki i narzut przetwarzania UDP) może nawet sprawić, że HTTP/3 będzie nieco wolniejsze. W sieciach z utratą pakietów (> 1%, co często występuje w sieciach mobilnych i satelitarnych) HTTP/3 znacząco przewyższa HTTP/2. Google odnotowało zmniejszenie ponownego buforowania w YouTube o 7–8% po przejściu na QUIC. Facebook (Meta) odnotował poprawę opóźnienia żądań o 7–15% w kanałach Instagramu korzystających z QUIC. Zyski są najbardziej widoczne w opóźnieniu ogonowym (p95, p99), gdzie przestoje spowodowane retransmisją TCP mają największy wpływ.

Równoważenie obciążenia ruchu QUIC jest bardziej złożone niż w przypadku TCP, ponieważ QUIC bazuje na UDP, a bezstanowe moduły równoważenia UDP nie mogą zapewnić trwałego przypisania połączenia. Dokument IETF draft-ietf-quic-load-balancers definiuje podejście, w którym serwery kodują informacje routingu w Connection ID, aby moduły równoważenia mogły kierować pakiety z tego samego połączenia do tego samego serwera bez śledzenia stanu poszczególnych połączeń. Connection ID zawiera zaszyfrowany identyfikator serwera z użyciem wspólnego klucza modułu równoważenia i serwerów. Cloudflare, Fastly i Nginx implementują warianty tego podejścia. Kolejną kwestią jest przechodzenie przez NAT: połączenia QUIC muszą przetrwać ponowne przypisanie NAT, obsługiwane przez mechanizm migracji połączenia.

Największe sieci CDN wdrożyły QUIC i HTTP/3 na dużą skalę. Cloudflare obsługuje HTTP/3 od 2019 roku i informuje, że około 20% ruchu korzysta z QUIC tam, gdzie obsługują go zarówno klient, jak i serwer. Fastly, Akamai i AWS CloudFront obsługują HTTP/3 na swoich punktach brzegowych. Własna infrastruktura Google (Search, YouTube, Gmail) korzysta z QUIC wewnętrznie od 2013 roku i publicznie udostępnia HTTP/3. Wdrożenia CDN korzystają ze wznowienia 0-RTT w QUIC: powracający użytkownicy ustanawiają połączenia szybciej, a migracja połączenia poprawia wydajność użytkowników mobilnych przemieszczających się między punktami dostępu podczas dostarczania treści.

Projekt QUIC oparty na UDP wiąże się z określonymi kwestiami bezpieczeństwa. Ataki wzmacniające: atakujący może sfałszować źródłowy adres IP i wysłać małe pakiety Initial, powodując, że serwer wyśle ofierze duże odpowiedzi Handshake — QUIC ogranicza to zagrożenie, ograniczając odpowiedzi serwera do 3x ilości odebranych danych do czasu zakończenia walidacji adresu (za pomocą mechanizmu RETRY). Zalewanie połączeniami: serwery QUIC muszą ograniczać częstotliwość nowych prób nawiązywania połączeń z tego samego adresu IP. Atakom na negocjację wersji zapobiega uwzględnienie wersji w chronionym kryptograficznie handshake. Wbudowane szyfrowanie QUIC oznacza, że urządzenia do inspekcji ruchu nie mogą analizować payloadu QUIC, chyba że znajdują się na ścieżce transmisji i posiadają certyfikat serwera — poprawia to prywatność w porównaniu z możliwym do inspekcji ruchem TCP.

Wdrożenie HTTP/3 wymaga: (1) serwera obsługującego QUIC (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed lub implementacji na poziomie aplikacji za pośrednictwem bibliotek quic-go, aioquic, ngtcp2). (2) Otwarcia portu UDP 443 w zaporach — wiele firmowych zapór blokuje UDP 443, powodując przejście QUIC na TCP/TLS. (3) Ogłoszenia obsługi HTTP/3 za pomocą nagłówka odpowiedzi Alt-Svc: Alt-Svc: h3=":443"; ma=86400, co skłania klientów HTTP/2 do przejścia na nowszy protokół. (4) Modułów równoważenia obciążenia świadomych QUIC lub przekazywania UDP na poziomie L4. (5) Monitorowania metryk charakterystycznych dla QUIC: zdarzeń migracji połączeń, współczynnika akceptacji 0-RTT oraz współczynnika przejścia na inny protokół. Stopniowe wdrażanie z fallbackiem do HTTPS jest niewidoczne dla klientów, które nie obsługują QUIC.

Jak QUIC rozwiązuje problem blokowania początku kolejki, który występuje w HTTP/2 działającym nad TCP?

QUIC integruje TLS 1.3 w warstwie transportowej nad UDP, eliminując blokowanie początku kolejki w TCP dzięki niezależnemu odzyskiwaniu danych po utracie dla każdego strumienia. Connection ID umożliwia migrację po zmianie sieci bez ponownej negocjacji. HTTP/3 mapuje HTTP na strumienie QUIC, używając kompresji nagłówków QPACK. Wznowienie połączenia 0-RTT ponownie wykorzystuje sekrety sesji TLS. QUIC zapewnia największą przewagę nad HTTP/2 przy utracie pakietów (w sieciach mobilnych i przeciążonych). Równoważenie obciążenia QUIC wymaga zakodowania informacji o routingu serwera w Connection ID. Wdrożenie wymaga UDP 443, serwerów obsługujących QUIC oraz nagłówków Alt-Svc do ogłaszania protokołu.