Od HTTP/1.1 do HTTP/3 — krótka historia

Protokół HTTP przeszedł długą drogę od swojej pierwszej wersji z lat 90. HTTP/1.1, który przez ponad dekadę był fundamentem sieci, miał poważne ograniczenia wydajnościowe — przede wszystkim obsługiwał jedno żądanie na połączenie TCP w danym momencie. Przeglądarki radziły sobie z tym, otwierając po 6 równoległych połączeń do jednego serwera, co było nieeleganckim obejściem.

HTTP/2, wprowadzony w 2015 roku, rozwiązał ten problem dzięki multipleksowaniu — wiele żądań mogło być przesyłanych jednocześnie przez jedno połączenie TCP. Dodał też kompresję nagłówków (HPACK) i server push. Był to ogromny krok naprzód, ale nadal opierał się na TCP, co niosło ze sobą fundamentalne ograniczenie: head-of-line blocking na poziomie transportu.

HTTP/3 rozwiązuje ten problem w sposób radykalny — całkowicie rezygnuje z TCP na rzecz nowego protokołu transportowego QUIC.

Czym jest QUIC

QUIC (Quick UDP Internet Connections) to protokół transportowy opracowany pierwotnie przez Google, a następnie zestandaryzowany przez IETF w RFC 9000 (maj 2021). Działa na bazie UDP zamiast TCP, co daje mu unikalne możliwości.

Eliminacja head-of-line blocking to kluczowa zaleta. W HTTP/2 utrata jednego pakietu TCP blokowała wszystkie strumienie w danym połączeniu, nawet te niezwiązane z utraconym pakietem. QUIC obsługuje strumienie niezależnie — utrata pakietu w jednym strumieniu nie wpływa na pozostałe. To fundamentalna zmiana, szczególnie widoczna na niestabilnych połączeniach mobilnych.

Wbudowane szyfrowanie TLS 1.3 jest integralną częścią QUIC, a nie osobną warstwą jak w TCP+TLS. Nie ma możliwości nawiązania nieszyfrowanego połączenia QUIC — bezpieczeństwo jest obowiązkowe i wbudowane od podstaw.

Szybsze nawiązywanie połączenia to bezpośredni efekt połączenia handshake'u transportowego z kryptograficznym. Nowe połączenie QUIC wymaga zaledwie jednej wymiany pakietów (1-RTT), a w przypadku wcześniej odwiedzanego serwera — zero wymian (0-RTT). Dla porównania, TCP+TLS 1.3 wymaga minimum 2-RTT, a TCP+TLS 1.2 nawet 3-RTT.

Co to oznacza w praktyce

Różnice są najbardziej odczuwalne w kilku scenariuszach.

Sieci mobilne — użytkownicy smartfonów regularnie przechodzą między sieciami Wi-Fi a LTE/5G. TCP traktuje zmianę adresu IP jako zerwanie połączenia i wymaga ponownego nawiązania sesji. QUIC identyfikuje połączenia za pomocą unikalnych identyfikatorów (Connection ID), niezależnych od adresu IP. Przejście z Wi-Fi na LTE jest dla QUIC transparentne — strona dalej się ładuje bez przerwy.

Słabe połączenia z dużą utratą pakietów — na sieciach z 1-2% utratą pakietów HTTP/2 over TCP drastycznie traci wydajność przez head-of-line blocking. QUIC w tych samych warunkach zachowuje się znacznie lepiej, bo strumienie są od siebie izolowane.

Pierwsze odwiedziny vs. powracający użytkownicy — mechanizm 0-RTT pozwala QUIC na wysłanie danych aplikacyjnych już w pierwszym pakiecie przy ponownym połączeniu z serwerem. Strona zaczyna się ładować natychmiast, bez czekania na handshake.

Adopcja HTTP/3

Stan adopcji HTTP/3 w 2025 roku jest imponujący. Po stronie klientów wszystkie główne przeglądarki — Chrome, Firefox, Safari i Edge — wspierają HTTP/3 od kilku lat. Po stronie serwerów sytuacja wygląda równie dobrze.

Cloudflare włączył HTTP/3 domyślnie dla wszystkich obsługiwanych domen. Google obsługuje QUIC na wszystkich swoich usługach od lat. Akamai, Fastly i inne duże CDN-y oferują pełne wsparcie. Według danych W3Techs, w 2025 roku ponad 30% stron internetowych obsługuje HTTP/3.

Po stronie serwerów open source wsparcie jest coraz lepsze. Nginx od wersji 1.25 oferuje eksperymentalną obsługę QUIC. Caddy wspiera HTTP/3 domyślnie od dawna. LiteSpeed był jednym z pierwszych serwerów z pełnym wsparciem. W ekosystemie Go biblioteka quic-go umożliwia implementację HTTP/3 w aplikacjach Go.

Wyzwania i ograniczenia

HTTP/3 nie jest pozbawiony wyzwań. Firewalle i middleboxy mogą blokować ruch UDP, na którym opiera się QUIC. Wiele korporacyjnych firewalli jest skonfigurowanych tak, by przepuszczać tylko TCP na portach 80 i 443. Dlatego przeglądarki implementują mechanizm fallback — jeśli QUIC nie działa, automatycznie przełączają się na HTTP/2 over TCP.

Zużycie CPU po stronie serwera jest wyższe niż w przypadku HTTP/2. QUIC wymaga więcej obliczeń kryptograficznych i obsługi stanu połączeń w przestrzeni użytkownika (user space), ponieważ UDP nie oferuje mechanizmów niezawodności na poziomie jądra systemu.

Debugowanie jest trudniejsze. Wireshark obsługuje QUIC, ale analiza ruchu jest bardziej skomplikowana niż w przypadku TCP, ponieważ niemal cała komunikacja jest szyfrowana — łącznie z nagłówkami transportowymi.

Jak włączyć HTTP/3 na swoim serwerze

Jeśli korzystasz z Cloudflare lub innego CDN, HTTP/3 jest prawdopodobnie już włączony. W przypadku własnego serwera najłatwiejszą ścieżką jest użycie serwera Caddy, który obsługuje HTTP/3 bez dodatkowej konfiguracji.

Dla Nginx potrzebna jest wersja 1.25+ skompilowana z modułem QUIC i biblioteką BoringSSL lub OpenSSL 3.x. Konfiguracja wymaga dodania listen 443 quic obok standardowego listen 443 ssl oraz nagłówka Alt-Svc informującego przeglądarkę o dostępności HTTP/3.

Warto zacząć od włączenia HTTP/3 na środowisku testowym i monitorowania zachowania. Mechanizm fallback sprawia, że ryzyko jest minimalne — przeglądarki, które nie mogą połączyć się po QUIC, po prostu użyją HTTP/2.

Podsumowanie

HTTP/3 i QUIC to nie ewolucja, a rewolucja w warstwie transportowej internetu. Eliminacja head-of-line blocking, szybsze nawiązywanie połączeń, odporność na zmianę sieci i wbudowane szyfrowanie — to realne korzyści, które wpływają na doświadczenie użytkowników, szczególnie na urządzeniach mobilnych.

Adopcja rośnie stabilnie i HTTP/3 staje się de facto standardem nowoczesnego internetu. Jeśli chcesz wdrożyć HTTP/3 na swojej stronie lub infrastrukturze, skontaktuj się z nami — pomożemy dobrać odpowiednią konfigurację.