QUIC i HTTP/3

Faster Connection Setup

0-RTT dla powracających userów vs. 2 RTT dla TCP+TLS

50-200ms szybszy cold start

Brak HoL Blocking

Utrata pakietu blokuje tylko jeden stream, nie całe połączenie

Lepsza performance na stratnych sieciach

Connection Migration

Połączenie przeżywa zmianę IP (WiFi → LTE)

Brak reconnect przy zmianie sieci

Always Encrypted

TLS 1.3 wbudowane — nie można używać QUIC bez szyfrowania

Security by default

Co to jest QUIC i HTTP/3 i dlaczego powstały?

QUIC to nowoczesny protokół transportowy opracowany przez Google (2012), a następnie standaryzowany przez IETF (RFC 9000, 2021). HTTP/3 to trzecia wersja protokołu HTTP która używa QUIC zamiast TCP jako transport. Historia: HTTP/1.1 (1997) — request-response na TCP, head-of-line blocking. HTTP/2 (2015) — multiplexing na jednym TCP connection, nagłówki HPACK. Ale nadal na TCP — jeden pakiet loss blokuje wszystkie streamy. QUIC (2012/2021) — Google zaczął od eksperymentu, IETF standaryzował jako RFC 9000. HTTP/3 (2022, RFC 9114) — HTTP semantics over QUIC. Problem z TCP: TCP jest protokołem z lat 70-tych, głęboko wbudowanym w kernel OS. Trudno go modyfikować (deployment przez OS updates). QUIC działa na UDP — może być wdrożony i aktualizowany jak zwykła biblioteka (bez OS update). Dlaczego QUIC jest lepszy niż TCP+TLS: Faster connection setup: QUIC łączy transport handshake + TLS 1.3 w jeden round-trip (0-RTT dla powracających klientów). TCP+TLS 1.3: 2-3 round-trips przed pierwszym danymi. Connection Migration: QUIC connections surwiwują zmianę IP (np. telefon przełącza z WiFi na LTE) bez reconnect. Adopcja: do 2024 około 25-30% ruchu internetowego używa HTTP/3. Cloudflare, Google, Facebook — wszyscy obsługują HTTP/3.

QUIC vs. TCP — kluczowe różnice techniczne?

QUIC vs. TCP — różnice techniczne: Warstwa transportu: TCP — warstwa 4 (Transport), zaimplementowany w kernel OS. QUIC — działa na UDP (warstwa 4), ale sam jest user-space protokołem. Multiplexing: HTTP/2 over TCP: wiele streamów, ale wszystkie blokowane gdy jeden pakiet zginie (TCP Head-of-Line Blocking). QUIC: każdy stream jest niezależny. Utrata pakietu na streamie A nie blokuje streamu B. Connection Setup: TCP + TLS 1.3: SYN, SYN-ACK, ACK (1 RT) + TLS Hello (1 RT) = 2 RTT. QUIC + TLS 1.3: 1 RTT dla nowych połączeń, 0-RTT dla powracających (session resumption). Connection Migration: TCP: connection identifier to 4-tuple (src IP, src port, dst IP, dst port). Zmiana IP = reset połączenia. QUIC: connection ID jest niezależny od IP. Telefon zmienia sieć → connection przeżywa. Encryption: TCP: TLS jest opcjonalne (add-on). QUIC: TLS 1.3 jest wbudowane — QUIC jest zawsze szyfrowany. Nie można używać QUIC bez szyfrowania. Congestion Control: TCP: congestion control w kernel (CUBIC, BBR, etc.). QUIC: congestion control w user-space — łatwiej aktualizować (Chromium aktualizuje algorytm bez OS update). Realistic Performance Gains: największe zyski na stratnych połączeniach (mobilnych, Wi-Fi). Na doskonałej sieci LAN — marginalna różnica. Mobilne sieci — QUIC daje 10-30% improvement w load time.

HTTP/3 adopcja — jak włączyć na serwerze i sprawdzić wsparcie?

HTTP/3 adopcja i konfiguracja: Wsparcie przeglądarek: Chrome (85+), Firefox (88+), Safari (14+), Edge (88+). Prawie 100% nowoczesnych przeglądarek. Wsparcie serwerów: Nginx (nginx-quic branch / nginx 1.25+ experimental). Caddy — HTTP/3 domyślnie włączone. LiteSpeed / OpenLiteSpeed — pełne wsparcie. Apache — mod_quic (experimental). CDN z HTTP/3: Cloudflare — HTTP/3 domyślnie włączone dla wszystkich stron. Fastly, AWS CloudFront — wsparcie. Google Cloud Load Balancer. Jak sprawdzić HTTP/3: Firefox DevTools → Network → Protocol column (h3). Chrome: chrome://flags → QUIC. curl --http3 https://example.com (curl 7.66+ z QUIC support). Konfiguracja Nginx (experimental): listen 443 quic reuseport; listen 443 ssl; ssl_protocols TLSv1.3; add_header Alt-Svc 'h3=":443"'; — nagłówek informuje przeglądarkę o dostępności HTTP/3. Caddy jest najłatwiejszym serwerem do HTTP/3 — zero dodatkowej konfiguracji. Alt-Svc header: kluczowy mechanizm — serwer informuje klienta że obsługuje HTTP/3 na danym porcie. Przeglądarka używa HTTP/1.1 lub HTTP/2 za pierwszym razem, potem upgradeuje do HTTP/3.

0-RTT i connection migration — jak działają w praktyce?

0-RTT (Zero Round-Trip Time): Cel: dla powracających klientów, dane można wysłać natychmiast bez czekania na handshake. Jak działa: pierwsze połączenie — normalny handshake (1 RTT). Serwer wysyła Session Ticket (zaszyfrowane dane sesji). Następne połączenie — klient dołącza Session Ticket + dane w pierwszym pakiecie. Serwer może deszyfrować natychmiast. Zysk: eliminuje cały handshake dla returning users. Różnica 1 RTT może być 50-200ms na wolnych połączeniach. Bezpieczeństwo 0-RTT: podatność na Replay Attacks — atakujący może retransmitować first-flight pakiety. Rozwiązanie: 0-RTT dane nie mogą powodować side effects (safe methods only — GET, nie POST). Serwer może limitować 0-RTT do idempotentnych operacji. Connection Migration: Scenariusz: user na telefonie przełącza z WiFi na 4G. IP address się zmienia. TCP: connection reset — przeglądarka musi się reconnectować, re-download strony. QUIC: connection ID pozwala na seamless migration. Użytkownik nie zauważa przełączenia sieci. IETF QUIC vs. gQUIC: gQUIC (Google QUIC) — wewnętrzna implementacja Google, różni się od IETF QUIC. IETF QUIC (RFC 9000) — standardowy, interoperabilny. Nowoczesne implementacje używają IETF QUIC. Implementacje QUIC: quic-go (Go), ngtcp2 (C), msquic (Microsoft C), lsquic (LiteSpeed), quinn (Rust), MsQuic.

QUIC dla aplikacji — kiedy konfigurować i ograniczenia?

QUIC dla aplikacji — praktyczne wskazówki: Kiedy HTTP/3 jest najważniejszy: Mobilne aplikacje webowe — największy benefit (zmiany sieci, packet loss). High-latency connections (geograficznie odległe). Aplikacje z wieloma równoczesnymi requestami (multiplexing bez HoL blocking). API z wieloma małymi requestami. Kiedy korzyść jest mniejsza: LAN lub szybka kablowa sieć — różnica minimalna. Aplikacje z małą liczbą requestów (1-2 na stronę). Kiedy QUIC może być gorszy: Firewalle blokujące UDP — korporacyjne sieci często blokują UDP 443. QUIC musi fallback na TCP+TLS (Alt-Svc). UDP jest często rate-limited przez ISPs. Wdrożenie: zacznij od CDN (Cloudflare) — zero server-side pracy. Użyj Caddy jeśli self-hosted — HTTP/3 out of the box. Monitoruj fallback rate (czy firewalle blokują QUIC). HTTP/3 i WebTransport: WebTransport to nowe Web API oparte na QUIC/HTTP/3. Pozwala na bidirectional streams i datagrams bezpośrednio z przeglądarki. Alternatywa dla WebSockets z lepszym performance. Use case: gaming, real-time collaboration, video streaming. Status: Chrome 97+, Firefox eksperymentalne. QUIC jako transport layer: coraz więcej protokołów eksperymentuje z QUIC jako transport (MQTT over QUIC, gRPC over QUIC, DNS over QUIC). Szybsze handshake i connection migration to wartość dla każdego długożyciowego połączenia.

Wyślij zapytanie