Jak działa HTTP/3 i czy przyspiesza stronę?

Jak działa HTTP/3? Przeglądarka nadal wysyła zwykłe żądania HTTP i odbiera odpowiedzi, ale transportuje je przez QUIC działający nad UDP, zamiast przez połączenie TCP. Dzięki niezależnym strumieniom utrata jednego pakietu nie musi wstrzymywać innych zasobów strony. Najwięcej możesz zyskać w sieci komórkowej, zatłoczonym Wi-Fi i wszędzie tam, gdzie połączenie ma opóźnienia lub gubi pakiety. Na stabilnym światłowodzie poprawa może być trudna do zauważenia.

HTTP/3 nie wymaga zmiany adresów URL, kodu HTML ani sposobu tworzenia odnośników. Zmiana zachodzi między przeglądarką, serwerem albo siecią CDN. Żeby ocenić jej sens, najpierw warto rozumieć warstwy połączenia. Jeśli chcesz uzupełnić podstawy, przeczytaj też, jak działa DNS i skąd przeglądarka zna adres serwera.

Jak działa HTTP/3 i czym jest QUIC

HTTP określa między innymi format żądania, odpowiedzi, nagłówków i kodów stanu. HTTP/1.1 oraz HTTP/2 korzystają zwykle z TCP jako warstwy transportowej. HTTP/3 przenosi semantykę HTTP na QUIC. Taką architekturę opisuje RFC 9114, standard HTTP/3 opublikowany przez IETF w czerwcu 2022 roku.

QUIC jest protokołem transportowym opakowanym w datagramy UDP. Sam UDP nie gwarantuje dostarczenia ani kolejności danych, lecz QUIC dodaje potrzebne mechanizmy: potwierdzenia, retransmisję, kontrolę przeciążenia i strumienie. Integruje też TLS 1.3, dlatego połączenie HTTP/3 jest szyfrowane. Szczegóły transportu, w tym identyfikatory połączeń i zmianę ścieżki sieciowej, definiuje RFC 9000 dotyczący QUIC w wersji 1.

Po pierwszym kontakcie serwer może poinformować przeglądarkę, że obsługuje HTTP/3, na przykład przez nagłówek Alt-Svc. Przy kolejnym połączeniu klient próbuje użyć QUIC. Jeżeli firmowy firewall blokuje UDP, zgodna implementacja może wrócić do wersji HTTP opartej na TCP. Dlatego uruchomienie HTTP/3 nie powinno odcinać użytkowników starszych urządzeń lub restrykcyjnych sieci.

Dlaczego utrata pakietu mniej szkodzi innym zasobom

HTTP/2 potrafi obsługiwać wiele żądań równolegle w jednym połączeniu TCP. TCP dostarcza jednak jeden uporządkowany strumień bajtów. Gdy pakiet zginie, warstwa transportowa czeka na jego ponowne przesłanie, zanim przekaże dalsze bajty aplikacji. W praktyce opóźnienie może dotknąć kilka odpowiedzi podróżujących tym samym połączeniem.

W HTTP/3 każda para żądanie-odpowiedź zajmuje osobny, dwukierunkowy strumień QUIC. RFC 9114 wskazuje wprost, że zablokowanie lub utrata pakietu dotycząca jednego strumienia nie powstrzymuje postępu innych. Jeśli fragment dużego zdjęcia trzeba wysłać ponownie, dane CSS albo odpowiedź API na innym strumieniu mogą nadal docierać do przeglądarki.

Korzyść rośnie wraz z niestabilnością sieci. Zakłócenia radiowe, słabszy zasięg i przeciążony punkt dostępowy zwiększają ryzyko strat. Sam zakup nowszego sprzętu nie usuwa każdego wąskiego gardła, dlatego przy diagnozie przydaje się szersze spojrzenie na to, kiedy router Wi-Fi 7 faktycznie poprawia połączenie.

Co daje szybsze zestawianie i migracja połączenia

TCP i TLS są osobnymi etapami, choć nowoczesne implementacje potrafią część pracy wykonywać sprawnie i równolegle. QUIC łączy negocjację transportu z uzgadnianiem TLS 1.3. Przy ponownym połączeniu z tym samym serwerem może też wykorzystać dane sesji i wariant 0-RTT, czyli wysłać część danych aplikacji już na początku. Serwer musi ostrożnie obsługiwać takie żądania, ponieważ dane 0-RTT mogą zostać powtórzone przez atakującego. Operacje zmieniające stan, takie jak zakup, wymagają ochrony przed ponownym wykonaniem.

Druga cecha jest ważna na telefonie. QUIC rozpoznaje połączenie za pomocą identyfikatora, a nie wyłącznie pary adresów IP i portów. Po przejściu z Wi-Fi na LTE klient może zweryfikować nową ścieżkę i kontynuować istniejące połączenie. Nie oznacza to braku chwilowego opóźnienia, ale pozwala uniknąć pełnego budowania sesji od początku, jeśli klient i serwer poprawnie obsługują migrację.

HTTP/3 nie zastępuje ochrony prywatności. Operator nadal może poznać adres serwera, z którym się łączysz, a właściciel witryny nadal widzi ruch przychodzący. Jeśli interesuje Cię zakres ochrony całego ruchu urządzenia, osobnym mechanizmem jest zaszyfrowany tunel VPN i jego ograniczenia.

Jak sprawdzić HTTP/3 na swojej stronie

Najprostszy test wykonasz w Chrome. Otwórz narzędzia deweloperskie, przejdź do zakładki Network, kliknij prawym przyciskiem nagłówek tabeli i włącz kolumnę Protocol. Przeładuj stronę. Wartość h3 przy dokumencie lub zasobach oznacza HTTP/3, natomiast h2 wskazuje HTTP/2. Pierwsze wejście może jeszcze użyć starszej wersji, zanim przeglądarka pozna alternatywną usługę, więc powtórz test po przeładowaniu.

Możesz także sprawdzić terminal. Najpierw uruchom curl -V i zobacz, czy używana kompilacja obsługuje HTTP/3. Następnie wykonaj curl --http3-only -I https://twoja-domena.pl. Opcja --http3-only wymusza nowy protokół, więc błąd może oznaczać brak obsługi w lokalnym curl, serwerze albo sieci. Polecenie curl --http3 -I dopuszcza powrót do wcześniejszej wersji i lepiej odzwierciedla zachowanie klienta w codziennym użyciu.

Powtórz kontrolę przez domowe Wi-Fi i internet komórkowy. Jeżeli h3 pojawia się tylko w jednej sieci, przyczyną może być filtracja UDP po drodze. Taki wynik jest cenniejszy niż pojedynczy test z serwera, ponieważ pokazuje doświadczenie rzeczywistego użytkownika.

Przy wdrożeniu sprawdź cztery rzeczy:

1. Czy serwer lub CDN ma aktywne HTTP/3 oraz ważny certyfikat TLS.
2. Czy UDP na porcie 443 przechodzi przez zaporę i warstwę równoważenia ruchu.
3. Czy przeglądarka rzeczywiście pokazuje h3, zamiast samej deklaracji w panelu hostingu.
4. Czy strona zachowuje dostęp przez HTTP/2, gdy QUIC zostanie zablokowany.

Czy warto włączać HTTP/3

Włącz HTTP/3, jeśli hosting lub CDN oferuje je jako stabilną funkcję, a test awaryjnego przejścia na HTTP/2 działa. Zwykle jest to zmiana infrastrukturalna bez przebudowy aplikacji. Szczególnie rozsądna będzie dla serwisu odwiedzanego z telefonów, działającego na wielu małych zasobach lub obsługującego użytkowników z sieci o zmiennej jakości.

Nie traktuj samej etykiety h3 jako gwarancji szybkiej witryny. Ciężkie obrazy, blokujący JavaScript, wolna odpowiedź serwera i brak pamięci podręcznej potrafią kosztować znacznie więcej czasu niż wybór protokołu. Porównuj wyniki na tych samych urządzeniach i sieciach, najlepiej dla HTTP/2 oraz HTTP/3, obserwując czas odpowiedzi, ładowanie kluczowych zasobów i błędy połączeń.

Praktyczna decyzja jest prosta: aktywuj funkcję, potwierdź h3 w realnym ruchu, zachowaj fallback i mierz. HTTP/3 daje solidną przewagę konstrukcyjną przy utracie pakietów oraz zmianie sieci, lecz końcowy efekt zależy od warunków użytkownika i jakości całej strony.