HTTP/3 v roce 2026: co to je, jak funguje a jak ho zapnout na Nginx

HTTP/3: když starý protokol přestává stačit

Uživatel otevírá e-shop na mobilu v metru. Signál je slabý, datové pakety se ztrácejí, některá spojení padají. Na HTTP/2 to znamená pauzu na několik sekund — prohlížeč čeká, až se ztracené pakety znovu odešlou. Uživatel vidí bílou obrazovku a zavírá záložku. Na HTTP/3 se ta samá stránka načte — protože se protokol neblokuje kvůli ztraceným paketům a může paralelně pokračovat v doručování ostatních částí stránky.

Podle výzkumů 40 % uživatelů opustí web, který se nenačte do 3 sekund. Pro e-commerce je to přímá ztráta peněz, pro média — ztráta publika, pro SaaS — ztráta zákazníků. HTTP/3 není jen „nová verze starého protokolu." Je to fundamentální změna v tom, jak jsou data přenášena po síti, a řeší reálné problémy, které HTTP/2 opravit nemohl.

Můžete namítnout: „mně všechno funguje rychle, proč další protokol?" Spravedlivá námitka — pokud je vaše publikum tvořeno desktopovými uživateli s drátovým internetem ve stejném městě, kde je váš server, rozdíl je skutečně malý. Ale většina webů dnes obsluhuje mobilní publikum: uživatele s nestabilním 4G, s roamingem, se špatným Wi-Fi v kavárnách, s přepínáním mezi sítěmi. Právě zde HTTP/3 přináší 20–40% nárůst rychlosti.

V tomto článku — bez zbytečné teorie — co je HTTP/3, proč je rychlejší než HTTP/2 i v roce 2026, jak ho zapnout na serveru za 15 minut, a kdy přináší největší efekt (a kdy je rozdíl nepostřehnutelný).

Krátce o evoluci HTTP

Abyste pochopili, proč je HTTP/3 lepší než jeho předchůdci, je užitečné se podívat na problémy, které řešila každá verze. Každá následující verze nepřidávala jen nové funkce — opravovala principiální omezení té předchozí.

Problém HTTP/2 byl v tom, že byl postavený nad TCP. TCP garantuje doručení paketů ve správném pořadí — a pokud se jeden paket ztratí, všechny následující čekají. I když prohlížeč už obdržel data pro jiný požadavek na té samé stránce, nemůže je zpracovat, dokud nedorazí ztracený paket. Tomu se říká „head-of-line blocking" — blokování na úrovni transportu. HTTP/2 tento problém vyřešil na úrovni aplikace (více požadavků v jednom spojení), ale TCP problém zůstal.

Představte si analogii s dálnicí. HTTP/1.1 je jedna úzká silnice, kde auta jedou jedno za druhým, a když první zabrzdí — brzdí všichni. HTTP/2 přidal několik pruhů na té samé silnici — auta mohou jet paralelně. Ale když je uprostřed silnice nehoda (ztracený TCP paket), všechny pruhy zastavují. HTTP/3 jsou samostatné silnice pro každý stream, takže nehoda na jedné silnici neovlivňuje provoz na ostatních.

HTTP/3 řeší tento problém radikálně: opouští TCP ve prospěch QUIC — nového transportního protokolu postaveného nad UDP. UDP nezaručuje doručení na úrovni transportu, a proto si QUIC může sám rozhodnout, jak zpracovávat ztráty paketů — nezávisle pro každý stream.

Co je QUIC a proč UDP místo TCP

QUIC (Quick UDP Internet Connections) je transportní protokol vyvinutý v Google v roce 2012 a standardizovaný IETF v roce 2021. Běží nad UDP, ale zajišťuje spolehlivé doručení dat jako TCP — jen bez jeho nevýhod.

Nezávislé streamy

Hlavní výhoda QUIC — každý požadavek (např. obrázek, CSS, JavaScript) je přenášen samostatným streamem. Pokud se ztratí paket jednoho streamu, ostatní pokračují ve zpracování bez zpoždění. V HTTP/2 nad TCP to bylo nemožné — ztráta jednoho paketu zablokovala všechny streamy najednou.

0-RTT: spojení bez handshake

Klasické HTTPS spojení vyžaduje několik kol výměny paketů: TCP handshake (1 RTT), poté TLS handshake (další 1–2 RTT). Na mobilu s pingem 100 ms je to už 200–300 ms jen na navázání spojení — předtím, než přijde první bajt obsahu. A uživatel mezitím kouká na bílou obrazovku a začíná být nervózní.

QUIC sjednocuje transportní a kryptografický handshake do jednoho kroku. Poprvé — 1 RTT místo 3. A při opětovném připojení k témuž serveru používá 0-RTT — první požadavek je odeslán okamžitě spolu s handshake paketem, bez jakýchkoliv dodatečných kol. To ušetří 100–300 ms na každé nové spojení.

Pro API požadavky z mobilu je to kritické. Typická mobilní session není jeden požadavek, ale desítky krátkých připojení (každé otevření obrazovky, každý refresh seznamu). Úspora 200 ms na každém — to jsou sekundy znatelného rozdílu pro uživatele během jedné session.

Migrace spojení

To je funkce, kterou HTTP/2 nemá. Když uživatel v dopravě přepíná z Wi-Fi na mobilní síť, IP adresa se mění — a TCP spojení padá. Prohlížeč musí navázat nové spojení od nuly: znovu TCP handshake, TLS handshake, opakovaný požadavek. To je 500–1000 ms výpadku, během kterého se načítání zastaví.

QUIC identifikuje spojení ne podle IP adresy, ale podle connection ID — unikátního identifikátoru, který se přenáší v každém QUIC paketu. Když se IP změní, server rozpozná klienta podle connection ID a pokračuje ve spojení, jako by se nic nestalo. Pro uživatele to vypadá jako nepřetržité načítání — žádné přerušení, žádná pauza. Zvláště patrné při streamování videa nebo velkých souborů: stahování se nepřeruší při přepínání mezi sítěmi.

Proč prostě neopravit TCP?

Logická otázka: proč vymýšlet nový protokol, když se dal TCP jednoduše opravit? Odpověď ve dvou slovech — je to nemožné. TCP je implementován v jádře operačního systému a na úrovni síťového hardware (routery, firewally, middleboxy). Jakákoliv změna TCP vyžaduje aktualizaci miliard zařízení po celém světě. To trvá desetiletí.

QUIC je implementován v user-space — přímo v kódu prohlížeče a webového serveru. Aktualizovat Chrome nebo Nginx jsou týdny, ne roky. A síťový hardware se nemusí vůbec měnit: UDP pakety procházejí vším, co propouští internetový provoz, bez jakýchkoliv úprav. Proto Google šel cestou nového protokolu — umožnilo to rychle iterovat a vydat HTTP/3 do produkce za roky, ne za desetiletí.

Reálný nárůst výkonu

Teorie je fajn, ale co ukazují reálné testy? Zde jsou data z porovnání HTTP/2 a HTTP/3 na stránce s 15 zdroji (HTML, CSS, JS, obrázky) za různých síťových podmínek.

Závěr je jednoduchý: na stabilním desktopovém spojení je rozdíl minimální (5 % — v rámci chyby měření). Ale na mobilních sítích se ztrátami paketů přináší HTTP/3 20–40 % zlepšení. To je obrovský rozdíl pro uživatele smartphonů, kteří tvoří 60 %+ provozu ve většině segmentů.

Proč takový velký rozdíl na špatných sítích? Zpátky k head-of-line blocking. Na stabilní síti se pakety téměř neztrácejí — HTTP/2 a HTTP/3 vykazují téměř stejný výkon. Ale jakmile začnou ztráty paketů, HTTP/2 se zasekává kvůli TCP blokování, zatímco HTTP/3 pokračuje v doručování obsahu přes ostatní streamy. Čím horší síť, tím větší výhoda HTTP/3.

Kdy HTTP/3 přináší největší efekt

Ne každý web získá stejných 40 % zrychlení. Čím víc je vaše publikum na mobilech, na špatných sítích, daleko od serveru — tím větší zisk. Seznam situací, kde HTTP/3 reálně mění obraz:

• Mobilní aplikace a PWA — uživatelé v dopravě, s nestabilním signálem, s přepínáním mezi Wi-Fi a mobilními sítěmi
• Streaming — video, audio, živé přenosy, kde každý buffering obtěžuje a snižuje dobu sledování
• E-commerce s mezinárodním publikem — vysoký ping ze vzdálených regionů, kde je 0-RTT zvláště patrný
• Real-time aplikace — chaty, notifikace, kolaborativní nástroje, online hry
• API pro mobilní klienty — 0-RTT ušetří znatelný čas na každém požadavku a mobilní aplikace dělá desítky požadavků za session
• Weby s velkým množstvím zdrojů — hodně obrázků, skriptů, CSS souborů (multiplexování bez head-of-line blocking)

Kdy je rozdíl nepostřehnutelný

Malý WordPress blog s publikem z jednoho regionu, které přistupuje převážně z desktopu — HTTP/3 přinese 2–5 % zrychlení v nejlepším případě. Není to špatný výsledek, ale není to ten WOW efekt, o kterém píšou titulky. Pro takové projekty je HTTP/3 bonus, ne priorita.

HTTP/3 + CDN: synergie

Zvlášť stojí za zmínku kombinace HTTP/3 s CDN. Když používáte CDN (Cloudflare, Fastly, BunnyCDN atd.), uživatel se nepřipojuje k vašemu origin serveru, ale k nejbližšímu edge uzlu CDN. Ping klesá na minimum — 10–20 ms místo 150–200 ms ke vzdálenému serveru. HTTP/3 nad takovým spojením dává ještě větší efekt: 0-RTT handshake plus krátká fyzická trasa plus odolnost vůči ztrátám — vše dohromady poskytuje skutečně rychlé weby i z nejhorších síťových podmínek.

Většina moderních CDN má HTTP/3 zapnutý ve výchozím stavu. Cloudflare byl jedním z prvních — už v roce 2019, dlouho před oficiálním standardem. Fastly, Akamai, BunnyCDN, KeyCDN — všichni podporují HTTP/3 pro edge provoz bez jakéhokoliv dalšího nastavení z vaší strany. Jednoduše zapnete CDN — a vaši uživatelé automaticky dostávají HTTP/3 tam, kde funguje.

Bezpečnost: TLS 1.3 jako povinný požadavek

HTTP/3 neexistuje bez šifrování. Na rozdíl od HTTP/2, kde byl TLS volitelný (i když téměř vždy použitý), HTTP/3 vyžaduje TLS 1.3 povinně. Není to volba — je to součást specifikace QUIC. Nelze vytvořit „nešifrovaný HTTP/3" — protokol takovou konfiguraci prostě nepředpokládá.

To zjednodušuje život administrátorům a zvyšuje celkovou úroveň bezpečnosti internetu. Už není třeba kontrolovat „zda je TLS zapnutý na této doméně" — pokud HTTP/3 funguje, znamená to, že TLS 1.3 funguje. Pokud TLS není nastaven — HTTP/3 se vůbec nespustí.

Co to dává v praxi:

• Rychlejší handshake — TLS 1.3 nahradil 2-RTT handshake z TLS 1.2 za 1-RTT (nebo 0-RTT při opětovném spojení)
• Moderní cipher suites — TLS 1.3 vyhodil zastaralé a zranitelné algoritmy (RC4, SHA-1, MD5, statické RSA)
• Ochrana před downgrade útoky — prohlížeč nemůže být přinucen použít starší protokol
• Šifrování metadat — QUIC šifruje více polí hlaviček než TLS over TCP, což ztěžuje analýzu provozu

Jak zapnout HTTP/3 na Nginx

Nginx oficiálně podporuje HTTP/3 od verze 1.25.0 (květen 2023) přes modul ngx_http_v3_module. V roce 2026 je to production-ready funkcionalita, ne experiment. Mnozí si stále myslí, že HTTP/3 v Nginx je experimentální funkce, která vyžaduje sestavení z cizích forků. To byla pravda v letech 2022–2023, ale nyní oficiální Nginx podporuje vše z krabice. Stačí zkontrolovat verzi: nginx -V by mělo ukázat verzi 1.25+.

Zde je minimální konfigurace, která přidává HTTP/3 k existujícímu HTTPS serveru:

server {
    # HTTP/2 — zůstává jako fallback
    listen 443 ssl;
    http2 on;
    # HTTP/3 (QUIC) — nový protokol
    listen 443 quic reuseport;
    http3 on;
    server_name example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    # TLS 1.3 je povinný pro HTTP/3
    ssl_protocols TLSv1.2 TLSv1.3;
    # Hlavička Alt-Svc oznamuje prohlížeči, že je dostupný HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';
    # ... zbytek konfigurace (root, location atd.)
}

Klíčový bod — direktiva listen 443 quic a hlavička Alt-Svc. Prohlížeč se nejprve připojí přes HTTP/2, vidí hlavičku Alt-Svc a při dalších požadavcích zkouší HTTP/3. Pokud HTTP/3 funguje — všechny další požadavky jdou přes něj. Pokud ne — zůstává u HTTP/2. Říká se tomu „happy eyeballs" — prohlížeč si sám vybere nejlepší variantu.

Hodnota ma=86400 v hlavičce Alt-Svc znamená „max age" — kolik sekund si prohlížeč má pamatovat, že tento server podporuje HTTP/3. 86400 sekund = 24 hodin. Tedy po první návštěvě, další den prohlížeč rovnou zkouší HTTP/3 bez předchozího HTTP/2 požadavku. Poté — znovu kontrola. Pro weby s častými návštěvami to funguje prakticky nepozorovaně.

Otevřete UDP 443 ve firewallu

To je nejčastější důvod, proč HTTP/3 „nefunguje" po nastavení. QUIC používá UDP, ne TCP. Většina serverových firewallů ve výchozím stavu otevírá pouze TCP 443 pro HTTPS — protože takhle to bylo nastavené všude roky. Nic nenapovídá administrátorovi, že je třeba otevřít ještě i UDP.

sudo ufw allow 443/tcp
sudo ufw allow 443/udp    # ← toto se často zapomíná

Na cloudových poskytovatelích (AWS, GCP, DigitalOcean, Hetzner) zkontrolujte security groups / firewall rules — UDP 443 musí být explicitně povolen pro příchozí provoz. Je to samostatné pravidlo od TCP 443 a nastavuje se odděleně v konzoli poskytovatele. Na AWS je to inbound pravidlo v Security Group, na GCP — ve VPC Firewall Rules.

Jak ověřit, že HTTP/3 skutečně funguje

Po nastavení nezapomeňte ověřit, že vše funguje. Zapnutí v konfiguraci nezaručuje, že je protokol reálně používán — mohou být problémy s firewallem, verzí Nginx nebo TLS nastaveními.

Přes curl

Nejrychlejší způsob z příkazové řádky (potřeba curl s podporou HTTP/3):

curl --http3 -I https://example.com

V odpovědi by mělo být HTTP/3 200. Pokud vidíte HTTP/2 — HTTP/3 nefunguje, i když hlavička Alt-Svc může být přítomna.

Přes prohlížeč

V Chrome nebo Firefoxu otevřete Developer Tools → záložka Network → načtěte stránku. Ve sloupci Protocol by mělo být h3 pro požadavky na vaši doménu. Pokud sloupec Protocol není vidět — klikněte pravým tlačítkem na záhlaví sloupců a zapněte ho.

Důležitý nuance: první požadavek na doménu obvykle jde přes HTTP/2. Prohlížeč obdrží Alt-Svc a zkouší HTTP/3 pro další požadavky. Proto stránku znovu načtěte (Ctrl+F5) — a pak uvidíte h3. Pokud je po znovunačtení stále HTTP/2 — zkontrolujte konzoli prohlížeče, zda tam nejsou chyby QUIC, a ověřte, zda hlavička Alt-Svc skutečně přichází ze serveru (v záložce Headers → Response Headers).

Online služby

Existují bezplatné služby pro rychlé ověření: http3check.net, https.hardenize.com, ssllabs.com/ssltest. Kontrolují nejen fakt podpory HTTP/3, ale i konfiguraci TLS, přítomnost Alt-Svc a další parametry.

Typické problémy a řešení

Většina problémů s HTTP/3 nesouvisí se samotným protokolem, ale s infrastrukturou kolem něj — firewally, zastaralými verzemi softwaru, špatně nastavenými cloudovými security groups. Zde jsou nejčastější scénáře, které vidíme u klientů Hostiserver, a způsoby jejich opravy.

Poslední situace je důležitá — některé korporátní sítě a staré routery stále blokují nebo throttlují UDP provoz. To není váš problém — prohlížeč se automaticky vrátí na HTTP/2 a web bude fungovat jako dřív. Hlavní je, že pro většinu uživatelů bude HTTP/3 fungovat a přinese zrychlení.

Adopce HTTP/3 v roce 2026

HTTP/3 v roce 2026 už není experiment. Je to standard, který podporují všichni hlavní hráči:

• Prohlížeče: Chrome, Firefox, Edge, Safari, Opera — všechny podporují HTTP/3 ve výchozím stavu od let 2022–2023
• Webové servery: Nginx (od 1.25), LiteSpeed (nativně), Caddy (z krabice), Cloudflare (globálně), HAProxy (od 2.6)
• CDN: Cloudflare, Fastly, Akamai, BunnyCDN — všechny hlavní CDN podporují HTTP/3 pro edge spojení
• Mobilní OS: iOS a Android používají HTTP/3 v nativních síťových knihovnách

Podle W3Techs, k začátku roku 2026 používá HTTP/3 asi 30 % z top 10 milionů webů. Pro srovnání: HTTP/2 používá asi 80 % — většina ještě nepřešla, ale aktivně se tím směrem pohybuje. Apache HTTP Server stále nemá production-ready HTTP/3 — to je jeden z důvodů, proč mnoho WordPress webů na Apache zůstává na HTTP/2.

Zajímavá statistika: mezi weby z top 1000 podle provozu — adopce HTTP/3 je už přes 50 %. Tedy velcí hráči (Google, Facebook, Netflix, Cloudflare, Amazon) jsou dávno na HTTP/3. Adopce je nerovnoměrná — čím větší web, tím víc investuje do optimalizace rychlosti, tím rychleji přechází na nový protokol. Malé a střední firmy obvykle následují se zpožděním 2–3 roky.

Samostatná kategorie — mobilní API a backend služby pro smartphone aplikace. Adopce HTTP/3 je tam ještě vyšší — prakticky všechny velké mobilní aplikace už používají HTTP/3 pro komunikaci se svými servery. Důvod je jasný: mobilní provoz — to je právě ten segment, kde HTTP/3 přináší největší nárůst.

Často kladené dotazy