HTTP/3 i QUIC: po co przeglądarkom transport oparty na UDP

Adres w pasku przeglądarki nie mówi, którym protokołem pobierana jest strona. Coraz częściej jest to HTTP/3, czyli HTTP przetransportowane przez QUIC na UDP. Zmiana jest niewidoczna dla użytkownika, ale dotyczy jednego z najstarszych założeń internetu: że strona internetowa jedzie przez TCP. Wyjaśniamy, po co było to zmieniać i kiedy nowe rozwiązanie wypada gorzej od starego.

Problem, którego nie dało się naprawić w TCP

TCP dostarcza jeden uporządkowany strumień bajtów. Jeśli pakiet zginie, odbiorca czeka na jego retransmisję, zanim przekaże dalsze dane aplikacji. HTTP/2 próbowało obejść ograniczenie, dzieląc połączenie na wiele strumieni, ale wszystkie one jechały jednym połączeniem TCP. Jedna utrata pakietu blokowała więc wszystkie strumienie, nawet te, których dane już dotarły. To zjawisko nazywa się blokowaniem nagłówka linii, a jego źródło leży w warstwie transportowej, nie w samym HTTP.

Dodatkowy koszt to nawiązywanie połączenia. TCP wymaga trzech wymian, potem dochodzi negocjacja TLS. Przy dużym opóźnieniu sieci sama rozmowa wstępna potrafi zająć kilka rund, zanim pojawi się pierwszy bajt treści.

Co QUIC robi inaczej

QUIC przenosi multipleksowanie do warstwy transportowej i buduje je na UDP. Każdy strumień ma własną kontrolę przepływu, a utrata pakietu blokuje tylko dane, które do niego należały.^[1] To jedna zmiana, ale pociąga za sobą kilka innych.

Po drugie, QUIC łączy transport z szyfrowaniem. TLS 1.3 jest częścią protokołu, a nie warstwą doklejoną obok, co skraca uzgadnianie do jednej rundy w typowym przypadku. Po trzecie, połączenie jest identyfikowane przez identyfikator niezależny od adresu IP, dzięki czemu może przetrwać zmianę sieci, na przykład przejście z Wi-Fi na LTE.^[1] Po czwarte wreszcie, QUIC działa w przestrzeni użytkownika, a nie w jądrze systemu. To ułatwia rozwój i wdrażanie nowych wersji, ale przenosi część pracy do procesu aplikacji, co okaże się istotne przy szybkich łączach.

HTTP/3 to warstwa aplikacji na QUIC

Sam QUIC nie wie, czym jest strona internetowa. HTTP/3 to dokument, który opisuje, jak przenieść semantykę HTTP na QUIC: nagłówki, metody, kody odpowiedzi, a także kompresję nagłówków w postaci QPACK.^[2] Standard zastępuje część mechanizmów, które w HTTP/2 obsługiwał sam protokół aplikacji, i przenosi je do transportu.

W praktyce serwer ogłasza obsługę HTTP/3 nagłówkiem Alt-Svc, a przeglądarka przy kolejnym połączeniu próbuje QUIC na porcie UDP 443. Jeśli sieć blokuje UDP albo negocjacja się nie uda, ruch wraca do TCP i HTTP/2. To dlatego HTTP/3 nie jest wymuszane: jest propozycją, którą klient może przyjąć lub odrzucić. Daniel Stenberg, autor curla, opisuje w książce „HTTP/3 explained” zarówno samo ogłaszanie obsługi, jak i konsekwencje wyboru UDP jako podłoża transportu.^[5]

Gdzie QUIC wygrywa

Największe korzyści pojawiają się tam, gdzie sieć jest nierówna: wysokie opóźnienia, utrata pakietów, mobilne łącza i przełączanie między sieciami. Krótsze uzgadnianie pomaga przy krótkich połączeniach, a niezależne strumienie przy stronach złożonych z wielu zasobów. Google wdrożył QUIC na dużą skalę i opisał te zyski w pracy z konferencji SIGCOMM w 2017 roku, jeszcze przed finalizacją standardu.^[3]

Do tego dochodzi oszczędność na nawiązaniu połączenia przy powrotach do tej samej witryny oraz odporność na zmianę adresu. W scenariuszach mobilnych to często ważniejsze niż samo opóźnienie transmisji.

Gdzie przegrywa: szybkie łącza i koszt CPU

Obraz nie jest jednak jednostronny. Zespół badaczy z kilku amerykańskich uczelni zmierzył wydajność QUIC w szybkich sieciach i opublikował wyniki w 2024 roku na konferencji WWW. W ich testach stos UDP, QUIC i HTTP/3 osiągał do 45,2% niższą przepustowość niż TCP z TLS i HTTP/2, a różnica rosła wraz z dostępnym pasmem.^[4]

Problem zaobserwowano zarówno w lekkich klientach pobierania, jak i w przeglądarkach Chrome, Edge, Firefox i Opera, na komputerach i telefonach, w sieciach przewodowych i komórkowych. Dotyczył nie tylko transferu plików, ale też strumieniowania wideo, gdzie spadek bitrate sięgał 9,8%.^[4] Autorzy wskazali przyczynę po stronie odbiorcy: nadmierną liczbę pakietów danych oraz potwierdzenia wysyłane w przestrzeni użytkownika, które obciążają procesor szybciej niż ścieżka TCP w jądrze systemu.

To nie znaczy, że QUIC jest gorszy. Znaczy, że jego przewaga zależy od warunków. Na łączu z stratami i wysokim opóźnieniem mechanizmy QUIC nadrabiają koszt obliczeniowy. Na szybkim światłowodzie, gdzie pasmo jest tanie, a straty rzadkie, dodatkowa praca procesora może przeważyć nad korzyściami.

Co to oznacza dla zwykłej strony

Po pierwsze, HTTP/3 nie przyspieszy witryny, która ma wolny serwer albo ciężkie zasoby. Protokół transportowy nie zastąpi optymalizacji treści. Po drugie, wdrożenie wymaga wsparcia po stronie serwera i poprawnej konfiguracji TLS 1.3. Po trzecie, część sieci firmowych i publicznych blokuje UDP na porcie 443, więc strona musi mieć działający fallback do HTTP/2. Bez tego użytkownicy w takich sieciach zobaczą błąd, a nie starszą wersję protokołu.

Warto też pamiętać, że HTTP/3 zmienia sposób pomiaru. Narzędzia, które liczą czas do pierwszego bajtu, mogą pokazywać różne wyniki w zależności od tego, czy połączenie zostało wznowione, czy nawiązane od zera. Porównywanie witryn bez kontroli tych warunków prowadzi do błędnych wniosków.

Jak sprawdzić, czy witryna używa HTTP/3

W przeglądarce najprościej otworzyć narzędzia deweloperskie, wejść w zakładkę sieci i włączyć kolumnę protokołu. Wartość h3 oznacza HTTP/3, h2 HTTP/2. Można też sprawdzić nagłówki odpowiedzi: serwer ogłasza obsługę przez Alt-Svc. curl obsłuży HTTP/3 tylko wtedy, gdy został zbudowany z odpowiednią biblioteką, co warto sprawdzić przed wyciąganiem wniosków z wyniku.

Dla większości wydawców treści najważniejsza jest jednak inna rzecz: HTTP/3 jest dziś domyślnie włączane przez duże CDN-y, a jego wpływ na realne metryki bywa mniejszy niż zmiany w samych stronach. Traktuj go jako element infrastruktury, nie jako funkcję marketingową.

Źródła

1. Jana Iyengar, Martin Thomson (red.), „RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport”, IETF, maj 2021. https://www.rfc-editor.org/rfc/rfc9000.html
2. Mike Bishop (red.), „RFC 9114: HTTP/3”, IETF, czerwiec 2022. https://www.rfc-editor.org/rfc/rfc9114.html
3. Adam Langley i in., „The QUIC Transport Protocol: Design and Internet-Scale Deployment”, SIGCOMM 2017, Google Research. https://research.google/pubs/the-quic-transport-protocol-design-and-internet-scale-deployment/
4. Xumiao Zhang i in., „QUIC is not Quick Enough over Fast Internet”, Proceedings of the ACM Web Conference 2024, arXiv:2310.09423, wersja 2 z 30 września 2024. https://arxiv.org/abs/2310.09423
5. Daniel Stenberg, „HTTP/3 explained”, książka online o QUIC i HTTP/3, odczyt 23 października 2026. https://http3-explained.haxx.se/en