HTTP/3, QUIC i TLS 1.3 na hostingu – jak nowoczesne protokoły przyspieszają strony internetowe

Strona może mieć szybki serwer, dyski NVMe i dobrze skonfigurowany cache, a mimo to tracić setki milisekund jeszcze przed wysłaniem pierwszego bajtu HTML. Powód bywa prozaiczny: przeglądarka musi najpierw zestawić połączenie TCP, przeprowadzić negocjację szyfrowania, a dopiero później rozpocząć pobieranie danych. HTTP/3, QUIC i TLS 1.3 skracają tę procedurę i ograniczają skutki utraty pakietów, ale nie są magicznym przyspieszaczem każdej witryny.

Największa różnica pojawia się przy połączeniach mobilnych, większych opóźnieniach i niestabilnym zasięgu. Użytkownik siedzący kilkanaście kilometrów od serwerowni, podłączony do światłowodu, może zobaczyć niewielką poprawę. Ten sam serwis otwierany przez LTE w pociągu albo z zagranicy potrafi zachowywać się wyraźnie lepiej. Nowoczesne protokoły nie zmniejszą zdjęcia ważącego 4 MB i nie naprawią wolnej bazy danych. Mogą jednak sprawić, że transport tych danych będzie mniej podatny na blokowanie i niepotrzebne rundy komunikacji.

HTTP/3 usuwa ograniczenie TCP, ale nie przyspiesza całej strony automatycznie

HTTP/1.1 zazwyczaj wymagał otwierania kilku połączeń TCP, ponieważ jedno połączenie słabo radziło sobie z równoległym pobieraniem wielu zasobów. HTTP/2 wprowadził multipleksowanie: pliki HTML, CSS, JavaScript, fonty i obrazy mogą być przesyłane równolegle w ramach jednego połączenia. Problem polega na tym, że HTTP/2 nadal działa nad TCP.

TCP dostarcza dane w ustalonej kolejności. Gdy zginie pojedynczy pakiet, kolejne odebrane pakiety muszą poczekać na jego retransmisję, nawet jeżeli zawierają fragmenty zupełnie innego zasobu. To mechanizm określany jako head-of-line blocking na poziomie transportowym. Przy stabilnym łączu jest mało widoczny. Przy utracie pakietów na Wi-Fi lub w sieci komórkowej potrafi zatrzymać jednocześnie kilka strumieni HTTP/2.

HTTP/3 przenosi komunikację z TCP na QUIC działający nad UDP. Każdy strumień ma własną kolejność danych. Utrata pakietu należącego do dużego obrazu nie musi więc blokować fragmentów arkusza CSS lub skryptu przesyłanych w innych strumieniach.

Nie oznacza to całkowitego usunięcia wpływu utraty pakietów. Wszystkie strumienie nadal korzystają ze wspólnego łącza i mechanizmu kontroli przeciążenia. Gdy sieć zaczyna gubić dużo danych, połączenie zwalnia. Różnica jest taka, że brak jednego pakietu nie zatrzymuje automatycznie dostarczania poprawnie odebranych danych z pozostałych strumieni.

HTTP/3 wprowadza też QPACK, czyli mechanizm kompresji nagłówków dostosowany do niezależnych strumieni QUIC. Jest odpowiednikiem HPACK znanego z HTTP/2, ale został zaprojektowany tak, aby ograniczać blokowanie związane z dynamiczną tablicą nagłówków.

W praktyce największe korzyści daje HTTP/3, gdy:

• użytkownicy korzystają głównie z LTE, 5G lub publicznego Wi-Fi;
• serwis obsługuje ruch z wielu krajów, a czas RTT do serwera wynosi np. 40–150 ms;
• strona pobiera wiele zasobów równolegle;
• połączenia często tracą pakiety albo zmieniają parametry w trakcie sesji;
• aplikacja wykonuje dużo krótkich żądań do API.

Efekt będzie mniejszy na prostej stronie działającej z pobliskiego centrum danych, z poprawnym cache i opóźnieniem sieciowym rzędu kilku–kilkunastu milisekund. W takim przypadku ważniejsze mogą być czas odpowiedzi aplikacji, rozmiar HTML, obrazy, JavaScript i konfiguracja cache.

Trzeba też rozumieć sposób uruchamiania HTTP/3. Przeglądarka nie zawsze od razu wie, że dana domena obsługuje ten protokół. Może najpierw połączyć się przez HTTP/2, a następnie otrzymać nagłówek Alt-Svc informujący o dostępności HTTP/3. Kolejne połączenia mogą już korzystać z QUIC. Informację można również publikować przez rekordy HTTPS w DNS, ale ich obsługa zależy od całego łańcucha: klienta, resolvera DNS, dostawcy infrastruktury i konfiguracji domeny.

Dlatego test wykonany wyłącznie po wyczyszczeniu całej pamięci przeglądarki może wyglądać inaczej niż kolejne wejście. To nie błąd. To konsekwencja negocjowania alternatywnej usługi.

QUIC skraca zestawianie połączenia i lepiej znosi zmianę sieci

Przy klasycznym HTTPS opartym na TCP klient musi najpierw przeprowadzić uzgadnianie TCP, a następnie handshake TLS. Przy nowym połączeniu TLS 1.3 potrzebuje standardowo jednej rundy RTT, ale wcześniejsze ustanowienie TCP również kosztuje jedną rundę. Dopiero potem można bezpiecznie przesyłać żądania aplikacyjne.

QUIC łączy ustanawianie transportu z negocjacją kryptograficzną TLS 1.3. Przy typowym nowym połączeniu dane aplikacyjne mogą zostać wysłane po jednej rundzie sieciowej, zamiast po osobnym zestawieniu TCP i TLS. Oszczędność jednej rundy nie zawsze robi wrażenie w lokalnej sieci. Przy RTT równym 80 ms oznacza jednak około 80 ms mniej przed rozpoczęciem właściwej wymiany danych. Przy kilku nowych połączeniach i odległym użytkowniku różnica staje się zauważalna.

Dla wcześniej odwiedzonej domeny QUIC może korzystać z mechanizmu 0-RTT, czyli wysłać wybrane dane od razu, na podstawie parametrów zapamiętanych z poprzedniej sesji. Nie należy jednak utożsamiać 0-RTT ze zwykłym działaniem HTTP/3. Mechanizm wymaga wznowienia sesji, prawidłowego biletu sesyjnego i zgodnej konfiguracji po obu stronach.

0-RTT ma też istotne ograniczenie bezpieczeństwa: przesłane w ten sposób żądanie może być podatne na powtórzenie przez atakującego. Z tego powodu nie powinno się bezrefleksyjnie obsługiwać w 0-RTT operacji zmieniających stan, takich jak:

• złożenie zamówienia;
• wykonanie płatności;
• zmiana hasła;
• dodanie użytkownika;
• usunięcie danych;
• jednorazowe zatwierdzenie transakcji.

Bezpieczniejszym kandydatem jest żądanie odczytujące dane, które po ponownym wykonaniu nie powoduje skutków ubocznych. Ostateczna decyzja zależy jednak od aplikacji, warstwy proxy i konfiguracji serwera. Włączenie 0-RTT bez sprawdzenia obsługi żądań przez aplikację jest niepotrzebnym ryzykiem.

Drugą praktyczną zaletą QUIC jest migracja połączenia. Połączenie nie musi być sztywno przypisane do jednej pary adresów IP i portów. Identyfikatory połączeń pozwalają kontynuować sesję po zmianie ścieżki sieciowej, np. gdy telefon przechodzi z Wi-Fi na LTE albo operator zmienia mapowanie NAT. Nie każda taka zmiana odbędzie się bez opóźnienia, ale QUIC ma mechanizm umożliwiający utrzymanie połączenia, podczas gdy TCP zwykle wymagałby zestawienia nowego.

Najczęstsza przeszkoda wdrożeniowa jest banalna: HTTP/3 potrzebuje ruchu UDP, zwykle na porcie 443. Otwarcie portu TCP 443 nie wystarcza. Ruch może blokować:

• firewall serwera;
• zapora dostawcy chmury;
• źle skonfigurowany load balancer;
• firmowy firewall użytkownika;
• operator sieci;
• urządzenie wykonujące inspekcję ruchu.

Dlatego serwer powinien nadal obsługiwać HTTP/2 i HTTP/1.1 jako fallback. Jeżeli UDP jest niedostępne, przeglądarka ma wrócić do połączenia TCP, zamiast wyświetlać błąd. Hosting reklamujący HTTP/3, ale nieoferujący sprawnego fallbacku lub mający okresowe problemy z UDP, będzie bardziej irytujący niż poprawnie działający HTTP/2.

Kolejny niuans dotyczy CDN. Gdy domena działa przez Cloudflare, Fastly, Akamai lub innego operatora, HTTP/3 może kończyć się na serwerze brzegowym CDN. Połączenie między CDN a właściwym hostingiem może nadal używać HTTP/2 albo HTTP/1.1. Dla odwiedzającego nadal ma to sens, ponieważ najdłuższa i najbardziej zawodna część trasy zwykle znajduje się między jego urządzeniem a punktem brzegowym. Nie należy jednak wyciągać z obecności HTTP/3 w przeglądarce wniosku, że cały łańcuch infrastruktury działa w tym samym protokole.

TLS 1.3 poprawia bezpieczeństwo i czas negocjacji, ale wymaga poprawnego wdrożenia

TLS 1.3 nie jest dodatkiem opcjonalnym dla HTTP/3. QUIC wykorzystuje handshake TLS 1.3 do uwierzytelnienia serwera i ustalenia kluczy szyfrujących. Jednocześnie QUIC nie przenosi rekordów TLS w taki sam sposób jak HTTPS nad TCP. TLS dostarcza mechanizm kryptograficzny, a transport zaszyfrowanych danych realizuje QUIC.

W porównaniu z TLS 1.2 nowa wersja upraszcza negocjację i usuwa wiele starych, problematycznych elementów. Nie obsługuje m.in. historycznych szyfrów opartych na RC4, 3DES ani statycznej wymiany kluczy RSA. Typowe zestawy szyfrów TLS 1.3 obejmują:

• TLS_AES_128_GCM_SHA256;
• TLS_AES_256_GCM_SHA384;
• TLS_CHACHA20_POLY1305_SHA256.

TLS 1.3 wymusza używanie nowoczesnej wymiany kluczy zapewniającej forward secrecy. Przejęcie klucza prywatnego certyfikatu w przyszłości nie powinno pozwolić na odszyfrowanie wcześniej nagranych sesji, o ile implementacja i dobór parametrów były prawidłowe.

Samo włączenie TLS 1.3 nie gwarantuje jednak dobrej konfiguracji HTTPS. Nadal można zepsuć wdrożenie przez:

• niepełny łańcuch certyfikatu;
• wygasający lub niedopasowany certyfikat;
• błędne przekierowania między HTTP i HTTPS;
• zbyt krótkie lub nieprawidłowo obsługiwane bilety sesyjne;
• stary reverse proxy przed nowoczesnym serwerem;
• niewłaściwą konfigurację HSTS;
• pozostawienie podatnych wersji TLS dla starych klientów bez uzasadnienia.

W większości publicznych serwisów nadal rozsądne jest utrzymanie TLS 1.2 jako warstwy zgodności, jeśli strona musi działać na starszych systemach lub urządzeniach. TLS 1.3 powinien być preferowany, ale wyłączenie TLS 1.2 wymaga sprawdzenia realnych klientów. W serwisie kierowanym do użytkowników aktualnych wersji Chrome, Edge, Firefox i Safari ryzyko jest małe. W panelach dla przemysłu, administracji lub starszych terminali płatniczych kompatybilność trzeba potwierdzić na podstawie logów, a nie przypuszczeń.

Obsługę protokołów można sprawdzić bez zgadywania:

• w narzędziach deweloperskich Chrome lub Edge należy otworzyć kartę Network i włączyć kolumnę Protocol; wpis h3 oznacza HTTP/3, h2 — HTTP/2;
• polecenie curl --http3 https://domena.pl pozwala przetestować HTTP/3, ale używana wersja curl musi być skompilowana z biblioteką obsługującą QUIC;
• openssl s_client -connect domena.pl:443 -tls1_3 sprawdza możliwość zestawienia TLS 1.3 dla klasycznego połączenia TLS nad TCP;
• nagłówki odpowiedzi warto skontrolować pod kątem Alt-Svc;
• test trzeba wykonać z co najmniej dwóch sieci, np. światłowodu i LTE, ponieważ lokalny firewall może przepuszczać TCP 443, a blokować UDP 443.

Po wdrożeniu należy porównywać nie tylko pojedynczy wynik syntetycznego testu. Sensowniejszy zestaw obejmuje:

• TTFB przy zimnym i ponownym połączeniu;
• czas zestawienia połączenia;
• wyniki z użytkowników mobilnych;
• udział ruchu obsługiwanego przez h3;
• odsetek błędów i przejść na fallback;
• LCP, INP i pozostałe dane terenowe Core Web Vitals;
• czasy odpowiedzi backendu i cache hit ratio.

HTTP/3 nie poprawi automatycznie Core Web Vitals. LCP może nadal być słaby, gdy główny obraz jest za duży albo zostaje wykryty dopiero po uruchomieniu JavaScriptu. INP nie spadnie od zmiany protokołu, jeśli główny wątek przeglądarki blokują długie zadania. TTFB pozostanie wysoki, gdy PHP, WordPress lub baza danych potrzebują 900 ms na wygenerowanie dokumentu.

Największy błąd polega na kupieniu droższego pakietu „z HTTP/3” bez ustalenia, gdzie faktycznie powstaje opóźnienie. W hostingu współdzielonym obsługa HTTP/3 i TLS 1.3 powinna być częścią standardowej usługi, a nie powodem do dużej dopłaty. Przy VPS koszt wynika głównie z administracji, konfiguracji Nginx, LiteSpeed, Caddy, HAProxy lub warstwy CDN, a nie z licencji na sam protokół. Ceny i zakres obsługi zależą od dostawcy, dlatego przed migracją trzeba potwierdzić na piśmie obsługę UDP 443, HTTP/3 na domenach klientów, automatyczny fallback oraz sposób terminacji TLS.

FAQ: najważniejsze pytania przed włączeniem HTTP/3

Czy HTTP/3 wymaga osobnego certyfikatu SSL?
Nie. Można użyć tego samego poprawnego certyfikatu, który obsługuje HTTPS przez HTTP/2. Serwer lub CDN musi natomiast prawidłowo zestawiać QUIC z TLS 1.3.

Czy HTTP/3 działa bez UDP 443?
Nie. QUIC standardowo korzysta z UDP na porcie 443. Gdy ruch UDP jest blokowany, przeglądarka powinna przejść na HTTP/2 lub HTTP/1.1 przez TCP.

Czy po włączeniu HTTP/3 każda wizyta będzie obsługiwana przez h3?
Nie. Klient może nie obsługiwać HTTP/3, blokować UDP albo rozpocząć pierwsze połączenie przez HTTP/2 i dopiero później zapamiętać informację z Alt-Svc.

Czy HTTP/3 przyspieszy WordPressa z wolnymi wtyczkami?
Nie naprawi wolnego PHP, bazy danych ani zapytań generowanych przez wtyczki. Może ograniczyć opóźnienia transportowe, ale najpierw trzeba usunąć problem backendu.

Czy 0-RTT należy zawsze włączać?
Nie. Daje korzyść przy wznawianiu sesji, ale wiąże się z ryzykiem powtórzenia żądania. Operacje zmieniające stan powinny być wyłączone z obsługi wczesnych danych albo odpowiednio zabezpieczone.

Czy obecność HTTP/3 poprawia pozycję w Google?
Sam protokół nie jest bezpośrednią gwarancją lepszej pozycji. Może pośrednio poprawić doświadczenie użytkownika i część pomiarów wydajności, ale nie zastąpi optymalizacji treści, renderowania, obrazów i backendu.

Co sprawdzić przed zmianą hostingu?
Poproś dostawcę o potwierdzenie obsługi HTTP/3 dla własnych domen, UDP 443, TLS 1.3, fallbacku do HTTP/2 oraz informację, czy protokół kończy się na CDN, reverse proxy czy bezpośrednio na serwerze.

Pierwszy krok nie polega na migracji ani włączaniu wszystkich opcji naraz. Otwórz stronę w narzędziach deweloperskich, sprawdź kolumnę Protocol, zmierz TTFB i powtórz test przez LTE. Jeżeli backend odpowiada przez 700–1000 ms, najpierw napraw cache, bazę danych lub kod aplikacji. Jeżeli serwer odpowiada szybko, ale użytkownicy mobilni mają problemy przy wysokim RTT i utracie pakietów, wtedy priorytetem jest poprawne uruchomienie HTTP/3 na UDP 443 z działającym fallbackiem do HTTP/2. To daje realną poprawę bez ryzyka odcięcia klientów, którzy z QUIC skorzystać nie mogą.