Způsob, jakým prohlížeč komunikuje s webovými servery, se mění. Více než dvacet let se hypertextový přenosový protokol spoléhal při doručování webových stránek na protokol řízení přenosu a po většinu této doby fungoval dostatečně dobře. Ale „dostatečně“ už nestačí.
Protokol HTTP/3 představuje nejvýznamnější změnu v oblasti přenosu v historii webu. Zcela opouští protokol TCP ve prospěch nového transportního protokolu QUIC, který běží nad protokolem uživatelských datagramů. Tento posun není jen technickou zajímavostí – je přímou reakcí na to, jak dnes používáme internet: na mobilních zařízeních, přes poruchová připojení a s očekáváním téměř okamžité odezvy.
V této příručce se dozvíte, co přesně je HTTP/3, jak se liší od předchozích verzí, proč je QUIC důležitý a jak jej nasadit v produkčním prostředí. Ať už jste vývojář, který se snaží porozumět tomuto protokolu, nebo inženýr plánující migraci, tento přehled obsahuje potřebné koncepty a praktické kroky.
HTTP/3 v kostce
HTTP/3 je třetí hlavní revize hypertextového přenosového protokolu HTTP, dokončená jako RFC 9114 v červnu 2022. Na rozdíl od svých předchůdců neběží protokol HTTP/3 přes protokol TCP. Místo toho mapuje sémantiku HTTP na QUIC, protokol transportní vrstvy, který jako základ používá UDP. Tato architektonická změna řeší zásadní omezení, která po léta trápila výkonnost webu. Základní myšlenka je jednoduchá: zachovat vše, co vývojáři znají a mají rádi z protokolu HTTP – metody jako GET a POST, stavové kódy, hlavičky, vzory požadavek-odpověď – ale nahradit základní transport něčím, co lépe vyhovuje podmínkám moderního internetu. HTTP/3 stále mluví jazykem HTTP. Jen tyto zprávy doručuje přes zásadně odlišný protokol.
HTTP/3 se od HTTP/2 liší několika zásadními změnami. Zaprvé, QUIC nahrazuje TCP, čímž se eliminuje blokování na úrovni transportní hlavičky linky, které trápilo HTTP/2. Zadruhé, zabezpečení transportní vrstvy (TLS 1.3) je integrováno přímo do transportního handshake, čímž se kryptografické a transportní handshake spojují do jediné cesty. Za třetí, migrace připojení umožňuje relacím přežít změny sítě –přepnutí telefonu z Wi-Fi na mobilní síť nezpůsobí přerušení připojení. Za čtvrté, snížení latence je možné díky obnovení 0-RTT u opakovaných spojení.
V reálném světě došlo k významnému přijetí. Společnost Google byla průkopníkem protokolu QUIC přibližně od roku 2012 a již několik let obsluhuje provoz HTTP/3. Společnost Meta jej používá ve službách Facebook a Instagram. Společnost Cloudflare povolila protokol HTTP/3 v celé své globální síti a společnost Akamai ji následovala. Do roku 2024-2025 budou tito poskytovatelé sami zpracovávat významný podíl celosvětového webového provozu přes HTTP/3.
Protokol již není experimentální. Hlavní webové prohlížeče – Chrome, Firefox, Safari, Edge – všechny podporují HTTP/3 ve výchozím nastavení. Pokud tento článek čtete v moderním prohlížeči, je velmi pravděpodobné, že některé z vašich dnešních požadavků již používají protokol HTTP/3, aniž byste o tom věděli.
V praxi to znamená: rychlejší načítání stránek ve ztrátových sítích, odolnější připojení v mobilních zařízeních a vyšší výkon aplikací, které provádějí více požadavků paralelně. Přínosy nejsou ve všech síťových podmínkách stejné, ale pro scénáře, které jsou nejdůležitější – skuteční uživatelé ve skutečných sítích – přináší protokol HTTP/3 měřitelná zlepšení.
Od HTTP/1.1 a HTTP/2 k HTTP/3
Pro pochopení existence protokolu HTTP/3 je nutné porozumět tomu, co bylo předtím. Vývoj od HTTP/1.1 přes HTTP/2 k HTTP/3 probíhal podle jasného vzoru: každá verze řešila omezení své předchůdkyně a zároveň zachovávala sémantiku HTTP.
Protokol HTTP/1.1 se objevil v roce 1997 (RFC 2068, později upřesněný v RFC 2616 a nakonec nahrazený RFC 7230-7235). Zavedlo trvalé připojení a pipelining, který umožňoval více požadavků přes jedno spojení tcp. V praxi však pipelining nikdy dobře nefungoval. Pomalá odezva na začátku fronty blokovala vše za ní –blokování na aplikační vrstvě. Prohlížeče to kompenzovaly otevíráním 6-8 paralelních spojení TCP na jeden původ, což fungovalo, ale plýtvalo to zdroji a komplikovalo řízení přetížení.
Protokol HTTP/2 (RFC 7540, 2015) opravil blokování na aplikační vrstvě pomocí binárního rámování a multiplexování datových toků. Více datových toků mohlo sdílet jedno připojení, přičemž požadavky a odpovědi se prokládaly jako rámce. Komprese záhlaví pomocí HPACK omezila nadbytečná metadata. Funkce Server push umožnila serverům proaktivně odesílat prostředky. V praxi se protokol TLS stal povinným, i když ho specifikace nevyžadovala.
Protokol HTTP/2 však zdědil základní omezení protokolu TCP: všechny datové toky sdílejí jeden uspořádaný tok bajtů. Když se ztratí paket s daty pro jeden stream, TCP vše zadrží, dokud není ztracený paket znovu odeslán. Jedná se o blokování na úrovni přenosu – a HTTP/2 se mu nemohl vyhnout, protože TCP vynucuje doručování v pořadí na úrovni spojení.
Hlavní rozdíly mezi verzemi:
- HTTP/1.1: Na bázi textu, jeden požadavek na spojení v daném okamžiku (prakticky), více TCP spojení na jeden původ
- HTTP/2: Binární rámování, multiplexovaná připojení přes jedno připojení TCP, komprese záhlaví HPACK, server push
- HTTP/3: sémantika HTTP nad QUIC/UDP, nezávislé toky bez blokování transportu HOL, komprese QPACK, integrovaná TLS 1.3.
Motivace pro HTTP/3 byla jasná: zachovat sémantiku HTTP beze změny, ale zcela nahradit transportní vrstvu. Protokol TCP, přes veškerou jeho spolehlivost, nebylo možné opravit tak, aby se odstranilo blokování HOL bez zásadních změn, které by narušily kompatibilitu s desítky let používanou infrastrukturou. Řešením byl QUIC – nový transportní protokol navržený od základu pro moderní požadavky.
Co je QUIC a proč je důležitý pro HTTP/3
QUIC je zkratka pro rychlé připojení k internetu pomocí protokolu UDP, ačkoli skupina Internet Engineering Task Force tuto zkratku při standardizaci vypustila. QUIC byl původně navržen společností Google kolem roku 2012 a v květnu 2021 byl standardizován jako RFC 9000, v roce 2022 následoval HTTP/3 jako RFC 9114.
QUIC je ve své podstatě transportní protokol postavený na protokolu UDP. Na rozdíl od surového UDP však QUIC implementuje vše, co byste od spolehlivého přenosu očekávali: navázání spojení, spolehlivost, řazení (pro jednotlivé proudy), řízení přetížení a šifrování. Klíčový rozdíl oproti TCP spočívá v tom, že QUIC toto všechno provádí v uživatelském prostoru, nikoli v jádře, a poskytuje více nezávislých proudů, nikoli jediný proud bajtů.
Transportní protokol QUIC je pro HTTP/3 důležitý kvůli několika kritickým vlastnostem. Multiplexování datových toků na transportní vrstvě znamená, že každý požadavek HTTP dostane svůj vlastní datový tok a ztráta paketu v jednom toku neblokuje ostatní. Integrovaný protokol TLS 1.3 znamená, že šifrování není samostatnou vrstvou – je začleněno do počátečního handshake. ID připojení umožňují, aby připojení přežila změny IP adres. A obnovení 0-RTT umožňuje opakovaným návštěvníkům odesílat data okamžitě bez čekání na dokončení handshake.
Volba návrhu QUIC odráží zkušenosti získané z omezení protokolu TCP a z obtížnosti vývoje protokolu TCP v důsledku zkostnatělosti middleboxů. Díky šifrování většiny hlavičky paketu a běhu v uživatelském prostoru se QUIC může vyvíjet rychleji, aniž by musel čekat na aktualizace jádra nebo se obávat, že zprostředkující zařízení budou předpokládat chování protokolu.
Zde je srovnání na vysoké úrovni:
- TCP: implementace na úrovni jádra, jediný uspořádaný proud bajtů, třícestný handshake a samostatný handshake TLS, spojení vázané na tuple IP:port.
- QUIC: Implementace v uživatelském prostoru, více nezávislých toků, kombinovaný transportní a kryptografický handshake (1-RTT nebo 0-RTT), spojení identifikované pomocí CID nezávisle na IP.
Protokol UDP má v základu minimální režii – pouze 64 bitů hlavičky pro zdrojový port, cílový port, délku a kontrolní součet. QUIC staví na spolehlivosti, ale získává flexibilitu, které se implementace TCP na úrovni jádra nemůže rovnat.
TCP vs. QUIC na transportní vrstvě
Navazování spojení TCP probíhá podle známého třícestného handshake: SYN, SYN-ACK, ACK. To je jedna cesta tam a zpět jen pro navázání spojení. V případě protokolu HTTPS je pak třeba provést handshake TLS– minimálně další kruhový přenos v případě protokolu TLS 1.3 nebo více ve starších verzích. Než začnou proudit jakákoli data aplikace, strávíte 2-3 RTT jenom nastavením.
Protokol TCP také vynucuje jediný uspořádaný proud bajtů. Každý bajt musí přijít v pořadí, a pokud se jeden datový paket ztratí, všechny následující pakety čekají v přijímací vyrovnávací paměti, dokud není chybějící paket znovu odeslán a přijat. V případě protokolu HTTP/2 to znamená, že ztracený paket přenášející data pro jeden datový tok zablokuje všechny datové toky na tomto připojení – i kdyžjejich data úspěšně dorazila.
QUIC zaujímá jiný přístup. Každý proud QUIC je nezávisle uspořádán. Ztracený paket ovlivňuje pouze datový tok (datové toky), jehož (jejichž) data byla v tomto paketu obsažena. Ostatní toky pokračují v příjmu a zpracování dat bez zpoždění. Tím se zcela eliminuje blokování na úrovni dopravního vedení.
Pro bezpečné navázání spojení integruje QUIC handshake TLS 1.3 přímo do transportní vrstvy. První let paketů může dokončit navázání spojení i výměnu klíčů, čímž se počáteční zpoždění sníží na 1 RTT. U spojení se servery, které klient již dříve navštívil, umožňuje obnovení s 0 RTT odeslání aplikačních dat již v prvním paketu na základěklíčů relace uložených v mezipaměti.
Rychlé srovnání:
- TCP + TLS 1.3: 1 RTT pro TCP handshake + 1 RTT pro TLS = minimálně 2 RTT před daty
- QUIC: 1 RTT pro kombinovaný handshake nebo 0 RTT při obnovení.
- Vliv ztráty paketů (TCP): Všechny toky se zdrží a čekají na opětovné odeslání.
- Dopad ztráty paketů (QUIC): Pouze postižený tok se zastaví, ostatní pokračují
Praktický rozdíl je nejvíce patrný na cestách s vysokou latencí – mobilní sítě, satelitní spojení, provoz mezi kontinenty. Úspora jedné nebo dvou okružních cest může zkrátit počáteční načítání stránek o stovky milisekund.
Přehled protokolu HTTP/3
Protokol HTTP/3 je definován v dokumentu RFC 9114 jako „mapování sémantiky protokolu HTTP přes transportní protokol QUIC„. Klíčové slovo je „mapování“ – HTTP/3nemění to, co HTTP dělá, pouze to, jak je přenášen po síti. Každý klientem iniciovaný obousměrný proud quic přenáší jeden požadavek HTTP a jemu odpovídající odpověď. Tento model s jedním požadavkem na stream nahrazuje multiplexování protokolu HTTP/2 v rámci jednoho spojení TCP. Jednosměrné proudy iniciované serverem přenášejí řídicí informace (nastavení, GOAWAY ) a v případě použití data push serveru.
Uvnitř každého streamu používá HTTP/3 rámce podobné konceptu rámců HTTP/2. Rámce HEADERS obsahují hlavičky požadavků a odpovědí (komprimované pomocí QPACK). Rámce DATA přenášejí těla zpráv. Rámce SETTINGS určují parametry připojení. Rámce jsou binární, nikoli textové, ale vývojáři s touto úrovní přímo pracují jen zřídka.
Protože QUIC se stará o multiplexování datových toků, řízení toku a spolehlivost, je několik konceptů HTTP/2 delegováno na transportní vrstvu nebo zcela odstraněno. Například vlastní řízení toku na úrovni toku HTTP/2 není nutné, protože QUIC jej poskytuje nativně.
Koncepční struktura:
- Připojení QUIC: Šifrovaná přenosová relace mezi klientem a serverem
- Proud QUIC: Nezávislý obousměrný nebo jednosměrný tok bajtů v rámci připojení.
- Rámec HTTP/3: Jednotka protokolu (HEADERS, DATA atd.) přenášená v rámci datového toku.
- Zpráva HTTP: Požadavek nebo odpověď složená z rámců na určitém datovém toku.
Toto rozvrstvení znamená, že HTTP/3 může těžit ze všech vylepšení QUIC, aniž by se měnil samotný HTTP/3. Nové algoritmy řízení přetížení, lepší detekce ztrát, podpora více cest – to vše lze přidat na transportní vrstvě.
Sémantika a rámování protokolu HTTP
HTTP/3 zachovává sémantiku http, kterou vývojáři znají z HTTP/1.1 a HTTP/2. Metody (GET, POST, PUT, DELETE), stavové kódy (200, 404, 500), hlavičky a těla zpráv fungují přesně podle očekávání. Aplikační vrstva vidí stejný protokol HTTP jako vždy.
Požadavky používají pseudohlavičky, které sdělují, co je v řádku požadavku zakódováno protokolem HTTP/1.1. Pseudohlavička :method nese označení GET nebo POST. Hlavička :path nese cestu k adrese URL. Hlavička :scheme určuje http nebo https. Hlavička :authority nahrazuje hlavičku Host. Tyto pseudohlavičky se musí objevit před běžnými poli hlavičky požadavku v rámci HEADERS.
V daném proudu quic se požadavek skládá z rámce HEADERS (obsahujícího hlavičky požadavku), po kterém volitelně následují rámce DATA (tělo požadavku) a který je ukončen uzavřením proudu pro odeslání. Odpovědi mají stejný vzor: Rámce HEADERS obsahují stavové hlavičky a hlavičky odpovědi, rámce DATA obsahují tělo požadavku.
Klíčová pravidla rámování:
- Jeden požadavek a jedna odpověď na obousměrný proud
- Rámeček HEADERS musí být v každém streamu na prvním místě.
- Pseudozáhlaví před běžnými záhlavími
- Snímky jsou v rámci proudu seřazeny, ale proudy jsou nezávislé.
- NASTAVENÍ se vztahují na připojení, nikoli na jednotlivé streamy.
- GOAWAY signalizuje elegantní vypnutí připojení
Mezi běžné typy rámců patří HEADERS (komprimovaný blok záhlaví), DATA (obsah těla), SETTINGS (parametry připojení), GOAWAY (signál o ukončení) a PUSH_PROMISE (pro server push, pokud je povolen). Typy rámců, které se překrývaly s vestavěnými možnostmi QUIC, byly z návrhu HTTP/2 odstraněny nebo zjednodušeny.
Komprese záhlaví: HPACK vs QPACK
Komprese záhlaví snižuje nadbytečná metadata v přenosu HTTP. Každý požadavek obsahuje hlavičky jako Hostitel, User-Agent, Accept-Encoding a cookies. Mnohé z nich se v požadavcích doslovně opakují. Bez komprese toto opakování plýtvá šířkou pásma – zejména v případě chatovacích připojení, která provádějí mnoho volání API.
HTTP/2 zavedl HPACK, který používá dynamickou tabulku dříve zobrazených hlaviček a Huffmanovo kódování ke zmenšení bloků hlaviček. HPACK funguje pro HTTP/2 dobře, ale předpokládá doručení v pořadí, protože stav komprese je sdílen v rámci jednoho spojení tcp.
HTTP/3 nemůže používat HPACK přímo. Proudy QUIC jsou nezávislé, takže bloky záhlaví mohou přijít mimo pořadí. Pokud se jeden proud odkazuje na položku tabulky, která byla definována v jiném proudu, jehož data ještě nedorazila, dekódování selže nebo se zablokuje – což způsobí blokování hlavičky na kompresní vrstvě.
QPACK to řeší tak, že odděluje aktualizace tabulky záhlaví od odkazů na bloky záhlaví:
- HPACK: Sdílená dynamická tabulka, aktualizace v pořadí, určená pro uspořádaný tok bajtů TCP
- QPACK: Proudy kodéru a dekodéru zpracovávají aktualizace tabulek asynchronně
- Riziko HPACK: Doručení mimo pořadí porušuje dekódovací předpoklady
- Řešení QPACK: Bloky záhlaví mohou odkazovat pouze na záznamy potvrzené jako přijaté.
- Výsledek: QPACK zachovává účinnost komprese bez blokování HOL
V praktických scénářích – např. mobilní aplikace provádějící desítky malých volání API s podobnými hlavičkami – přináší QPACK jak úsporu šířky pásma, tak zlepšení latence. Oddělení aktualizací tabulek od kritické cesty doručování datového toku znamená, že jediný pomalý tok neblokuje dekompresi záhlaví pro ostatní.
Multiplexování, server Push a upřednostňování
Možnosti multiplexování protokolu HTTP/3 vycházejí přímo z konstrukce QUIC založené na proudu. Přes jedno spojení QUIC proudí více požadavků, každý ve svém vlastním obousměrném proudu. Na rozdíl od protokolu HTTP/2, kde všechny proudy sdílely pořadová omezení jednoho spojení TCP, jsou proudy protokolu HTTP/3 skutečně nezávislé. Ztracený paket v jednom proudu neblokuje pokračování ostatních. To umožňuje webovým prohlížečům efektivněji paralelně načítat zdroje stránek. HTML, CSS, JavaScript a obrázky mohou být požadovány současně, aniž by jeden pomalý zdroj blokoval ostatní. V sítích se ztrátovým přenosem dat, které jsou běžné u mobilních uživatelů, se tato nezávislost projevuje rychlejším a předvídatelnějším načítáním stránek.
Server push existuje v protokolu HTTP/3, ale jeho nadšení klesá. Koncept zůstává stejný: servery mohou proaktivně odesílat prostředky dříve, než si je klienti vyžádají, pomocí rámců PUSH_PROMISE. V praxi se ukázalo, že server push je složitý na správnou implementaci, špatně spolupracuje s mezipamětí prohlížeče a často přináší jen okrajové výhody. Mnoho nasazení jej nyní zcela vypíná.
Vyvinula se také prioritizace. Složitý stromový model priorit HTTP/2 způsoboval problémy s interoperabilitou a byl často implementován nejednotně. HTTP/3 používá jednodušší přístup definovaný v RFC 9218, který využívá spíše úrovně naléhavosti a přírůstkové nápovědy než stromy závislostí. Díky tomu je určování priorit v různých implementacích předvídatelnější.
Multiplexování a shrnutí push:
- Multiplexování: Více nezávislých streamů na jedno připojení, žádné blokování napříč streamy
- Push serveru: K dispozici, ale stále častěji volitelný; mnozí jej vypínají
- Stanovení priorit: Jednodušší než model HTTP/2; používá naléhavost a přírůstkové příznaky.
- Praktický dopad: Paralelní zatížení zdrojů je na ztrátových sítích odolnější.
Vezměme si prohlížeč, který načítá typickou webovou stránku: Vezměte si příklad: dokument HTML, několik souborů CSS, svazky JavaScriptu a desítky obrázků. Díky protokolu HTTP/3, který umožňuje vícenásobné požadavky, mohou být všechny tyto požadavky v pohybu současně. Pokud se ztratí paket přenášející obrazová data, čeká na opětovné odeslání pouze tento proud obrázků – CSS a JavaScript se načítají dál.
TLS 1.3 a integrace zabezpečení
Protokol HTTP/3 vyžaduje protokol TLS 1.3 nebo vyšší. Neexistuje žádný nešifrovaný HTTP/3 – žádný ekvivalent HTTP na portu 80 přes TCP. Každé spojení HTTP/3 je z definice šifrované, což zajišťuje bezpečné spojení pro veškerý přenos dat.
QUIC integruje protokol TLS 1.3 na transportní vrstvě, nikoliv jako vrstvu nad ním. Kryptografický handshake probíhá současně s navazováním spojení, nikoli až po něm. Tato integrace přináší několik výhod:
- Méně okružních jízd: Nastavení připojení a šifrování probíhá společně.
- Silnější výchozí hodnoty: TLS 1.3 s dopředným utajením
- Šifrované hlavičky: Většina metadat paketů QUIC je šifrována, nejen užitečné zatížení.
- Žádné útoky na snížení úrovně: Nelze vyjednat slabší šifrování nebo otevřený text.
- Vzájemné ověřování: Ověření certifikátu serveru během kombinovaného handshake
Šifrování se nevztahuje pouze na užitečné zatížení HTTP. QUIC šifruje čísla paketů a většinu informací v záhlaví, které protokoly TCP a TLS zpřístupňují pasivním pozorovatelům. Tím je zajištěno vyšší zabezpečení a soukromí – mezilehléuzly vidí méně informací o vašem provozu.
Nicméně, toto šifrování vytváří problémy. Tradiční nástroje pro monitorování sítě, které se spoléhají na kontrolu hlavičky TCP nebo viditelnost záznamové vrstvy TLS, s QUIC nefungují. Firewally a systémy detekce narušení mohou potřebovat aktualizace, aby zvládly provoz QUIC. Podnikové sítě zvyklé na hloubkovou kontrolu paketů musí přizpůsobit své zásady zabezpečení a nástroje.
Tento kompromis je záměrný: Návrháři QUIC upřednostnili soukromí koncového uživatele a odolnost proti zkostnatění middleboxu před viditelností operátora. Pro organizace s oprávněnými potřebami monitorování se stává zásadní protokolování na úrovni koncových bodů a aktualizovaná bezpečnostní infrastruktura.
Výkonnostní charakteristiky protokolu HTTP/3
Zlepšený výkon protokolu HTTP/3 je nejvýraznější za specifických síťových podmínek. Mobilní sítě s proměnlivou ztrátovostí paketů, Wi-Fi s rušením, cesty s vysokou latencí napříč kontinenty a scénáře zahrnující časté změny sítě – to vše přináší výrazné výhody. Protokol QUIC byl navržen speciálně pro tyto reálné podmínky.
Na stabilních připojeních datových center s nízkou latencí může být výkon HTTP/3 jen nepatrně lepší než u dobře vyladěného nasazení HTTP/2. Protokol TCP má za sebou desítky let optimalizace a moderní jádra jej zvládají velmi efektivně. Výhody spočívající v zamezení blokování HOL a úspoře kruhových cest handshake mají menší význam, pokud je latence již nízká a ztráta paketů vzácná.
Tento diferencovaný pohled podporují i reálná měření. Společnost Cloudflare hlásí zlepšení v době do prvního bajtu a odolnosti vůči chybám, zejména u mobilních uživatelů. Měření společnosti Google ukázala snížení výpadků připojení a rychlejší načítání stránek v oblastech s vysokou latencí. Akademické studie z let 2020-2024 konzistentně ukazují, že HTTP/3 překonává HTTP/2 při ztrátách, přičemž zisky se pohybují od mírných až po značné v závislosti na míře ztrát.
Je tu jeden kompromis, který stojí za zmínku: QUIC může spotřebovávat více procesoru než zpracování protokolu TCP na úrovni jádra, zejména na serverech s velkým výkonem. Operační systémy neměly desítky let na optimalizaci kódových cest QUIC. U serverů, které zpracovávají obrovské množství spojení, může dojít ke zvýšenému využití CPU, zejména na málo výkonném hardwaru.
Kde HTTP/3 pomáhá nejvíce:
- Mobilní prohlížení s předáváním mobilní sítě
- Uživatelé v přetížených sítích Wi-Fi
- Dálková připojení (vysoká RTT)
- Aplikace provádějící mnoho paralelních požadavků
- Uživatelé, kteří často navštěvují stejné stránky (výhody 0-RTT).
- Aplikace reálného času citlivé na zpoždění
Nastavení připojení a 0-RTT
Rozdíly v handshake mezi HTTP/2 a HTTP/3 mají přímý vliv na to, jak rychle se uživatelům zobrazí obsah. U protokolu HTTP/2 přes TLS 1.3 vyžaduje navázání spojení minimálně jeden RTT pro třícestný handshake TCP a poté jeden RTT pro handshake TLS. Při cestě s RTT 100 ms je to 200 ms, než dojde k toku dat HTTP.
Kombinovaný přístup protokolu HTTP/3 tento problém výrazně omezuje. QUIC provádí transportní a TLS 1.3 handshake společně a dokončí jej v jediném kole. Na stejné 100ms cestě odesíláte data HTTP po 100 ms místo po 200 ms.
U opakovaných návštěvníků jde obnovení 0-RTT ještě dále. Pokud má klient v mezipaměti klíče relace z předchozího připojení ke stejnému serveru, může odeslat aplikační data hned v prvním paketu – ještě před dokončením handshake. Server může okamžitě odpovědět pomocí klíčů uložených v mezipaměti.
Srovnání potřesení rukou:
- HTTP/2 + TLS 1.3: TCP SYN → SYN-ACK → ACK (1 RTT), pak TLS ClientHello → ServerHello → Finished (1 RTT) = 2 RTT
- HTTP/3 (nové připojení): QUIC Initial with TLS ClientHello → odpověď serveru s daty TLS → spojení připraveno = 1 RTT
- HTTP/3 (obnovení 0-RTT): Klient odešle požadavek v prvním paketu, server odpoví okamžitě = 0 RTT
Nulový RTT je spojen s bezpečnostními výhradami. Protože jsou data odesílána před dokončením handshake, je potenciálně zranitelný vůči replay útokům. Záškodník by mohl zachytit paket 0-RTT a znovu jej odeslat. Servery musí implementovat zásady proti přehrání a obvykle omezují, jaké operace jsou v 0-RTT povoleny (např. bezpečné požadavky pouze pro čtení). Proto je 0-RTT „obnovovací“ funkcí– spoléhá se na dříve vytvořenou důvěru.
Konkrétní příklad: uživatel navštíví váš e-shop, prohlédne si produkty a druhý den ráno se vrátí. S 0-RTT může být jejich první požadavek – načtení domovské stránky – dokončen bez čekání. Stránka se začne okamžitě načítat.
Řešení ztrát paketů a přetížení
Ztráty paketů jsou na internetu nevyhnutelné a způsob, jakým je protokoly zvládají, určuje jejich výkonnost v reálném světě. Obnova ztrát v rámci jednoho proudu protokolu QUIC se zásadně liší od přístupu protokolu TCP a má přímý dopad na efektivitu sítě.
Když protokol TCP zjistí ztracený paket, pozastaví doručování všech následujících dat, dokud není ztracený paket znovu odeslán a přijat. To je nezbytné, protože protokol TCP zaručuje doručení celého proudu bajtů v daném pořadí. V případě protokolu HTTP/2 to znamená, že jeden ztracený paket nesoucí data souboru CSS zablokuje JavaScript a obrázky, které úspěšně dorazily – veškerýdatový tok čeká.
QUIC zachovává spolehlivost pro jednotlivé proudy. Pokud dojde ke ztrátě paketu quic s daty pro stream 5, na opakované vysílání čeká pouze Stream 5. Proudy 6, 7 a 8 pokračují v příjmu dat a v postupu. . Tím se eliminuje plýtvání šířkou pásma kvůli zbytečnému blokování a zlepšuje se výkon vnímaný uživatelem při ztrátách.
Řízení přetížení v systému QUIC funguje podobně jako u protokolu TCP – na základě algoritmů založených na oknech, které zkoumají dostupnou šířku pásma a při zjištění přetížení se vrátí zpět. Protože však QUIC běží v uživatelském prostoru, je experimentování s novými algoritmy řízení přetížení snazší. Aktualizace nevyžadují záplaty jádra, jedná se o aktualizace knihoven.
Charakteristiky zvládání ztrát:
- Obnova za proud: Ztracený paket blokuje pouze svůj datový tok, nikoli celé připojení.
- Řízení pomocí ACK: Podobně jako osvědčené principy řízení přetížení TCP
- Vývoj uživatelského prostoru: Algoritmy přetížení lze aktualizovat beze změn v operačním systému.
- Výslovné hlášení ztrát: Rozšíření umožňují přesnější detekci ztrát
Uvažujme scénář streamování videa přes přetíženou mobilní síť. Při použití protokolu HTTP/2 způsobuje periodická ztráta paketů zastavení všech streamů, což vede k viditelnému zadrhávání. V případě protokolu HTTP/3 ztráta datového toku videa ovlivňuje pouze tento tok – řídicí data, titulky a ostatní toky proudí dál. Výsledkem je plynulejší přehrávání a lepší doručování dat v náročných síťových podmínkách.
Migrace připojení pomocí ID připojení
Připojení TCP jsou identifikována čtyřmi dvojicemi: zdrojová IP, zdrojový port, cílová IP, cílový port. Pokud některý z nich změníte – což se stane, když telefon přepne z Wi-Fi na mobilní síť – spojení TCP se přeruší. Následuje nový handshake a vyjednávání TLS, což zvyšuje zpoždění a narušuje probíhající přenosy.
QUIC zavádí id připojení, logické identifikátory, které zůstávají nezávislé na základních IP adresách a portech. Pokud se síťová cesta klienta změní, může klient pokračovat v používání stejného připojení quic předložením svého identifikátoru CID. Server rozpozná připojení a pokračuje tam, kde skončil – žádné nové podávání rukou, žádné nové vyjednávání TLS.
Tato migrace připojení je cenná zejména pro mobilní uživatele. Přechod z jedné sítě do druhé při videohovoru, stahování velkého souboru nebo streamování hudby již neznamená přerušované připojení. Zkušenosti jsou bezproblémové.
Je zde i aspekt ochrany soukromí: pokud by se CID nikdy nezměnil, pozorovatelé by mohli sledovat připojení při změnách v síti a potenciálně propojit domácí IP uživatele s IP v kanceláři. QUIC to řeší tím, že umožňuje rotaci CID. Během připojení lze vydávat nové identifikátory CID a klienti je mohou používat ke snížení propojitelnosti při změnách v síti. Při implementaci je třeba dbát na rovnováhu mezi kontinuitou a soukromím.
Výhody a aspekty migrace připojení:
- Plynulé přechody: Změny v síti nepřerušují relace HTTP/3
- Žádné opětovné podání ruky: Vyhnout se nákladům na RTT při navazování nového spojení
- Rotace CID: Při správné implementaci zmírňuje sledování napříč sítěmi.
- Podpora na straně serveru: Vyžaduje, aby servery udržovaly stav připojení podle klíče CID.
Příklad scénáře: Nahráváte velkou dávku fotografií z telefonu, když odcházíte z domova. Vaše zařízení přejde z domácí Wi-Fi na mobilní síť 5G. Při použití protokolu HTTP/2 přes TCP se po navázání nového spojení nahrávání znovu spustí od posledního potvrzeného bodu. S HTTP/3 pokračuje odesílání bez přerušení – jen s krátkou pauzou, než se nová síťová cesta stabilizuje.
Stav nasazení a podpora prohlížeče/serveru
Standardizace protokolu HTTP/3 je dokončena. Mezi základní specifikace patří RFC 9114 (HTTP/3), RFC 9000 (transport QUIC), RFC 9001 (QUIC-TLS) a RFC 9204 (QPACK). Nejedná se o experimentální návrhy – jsou to navrhované normy na standardizační trati IETF.
Podpora prohlížeče je nyní univerzální mezi hlavními webovými prohlížeči. Od roku 2024-2025:
- Google Chrome: Ve výchozím nastavení povoleno od roku 2020
- Microsoft Edge: Ve výchozím nastavení povoleno (na bázi Chromu)
- Mozilla Firefox: Povoleno ve výchozím nastavení od verze 88
- Safari: Stabilní podpora od macOS Monterey (12) a iOS 15
- Prohlížeče založené na platformě Chromium: Brave, Opera a Vivaldi zdědily podporu Chromu.
Implementace serverů výrazně vyspěly:
- NGINX: Podpora QUIC dostupná prostřednictvím modulů; integrace do hlavní řady pokračuje
- LiteSpeed: Nativní podpora protokolu HTTP/3, často používaná pro výkonnostní testy.
- Envoy: Podpora protokolu HTTP/3 připravená k výrobě
- Apache httpd: K dispozici prostřednictvím modulů (mod_http3)
- Caddy: Vestavěná podpora HTTP/3
- Microsoft IIS: Podpora v posledních verzích Windows Serveru
CDN a hlavních poskytovatelů:
- Cloudflare: HTTP/3 povoleno globálně v celé jejich okrajové síti
- Akamai: Široká podpora HTTP/3
- Fastly: HTTP/3 je k dispozici na jejich platformě edge
- AWS CloudFront: dostupná podpora HTTP/3
- Google Cloud CDN: Nativní podpora QUIC/HTTP/3
Celosvětové metriky přijetí se liší podle zdrojů měření, ale podle údajů W3Techs a HTTP Archive nyní používají HTTP/3 desítky procent webových požadavků a meziročně dochází k nárůstu. Trajektorie je jasná: HTTP/3 přechází od „nové možnosti“ k „očekávanému výchozímu nastavení“.
Důsledky pro infrastrukturu a middleware
Protokol HTTP/3 běží ve výchozím nastavení přes UDP na portu 443. Jedná se o stejný port, který se používá pro HTTPS přes TCP, ale jiný protokol. Síťová infrastruktura, která filtruje nebo omezuje rychlost protokolu UDP nebo jej považuje za méně prioritní než protokol TCP, může zhoršit výkon protokolu HTTP/3 nebo mu zcela zabránit.
Praktické aspekty infrastruktury:
- Firewally: Musí povolit příchozí a odchozí port UDP 443; některé podnikové firewally ve výchozím nastavení blokují nebo omezují UDP.
- Vyrovnávače zatížení: Musí podporovat vyrovnávání zátěže QUIC/UDP; tradiční vyrovnávače zátěže TCP nebudou pro HTTP/3 fungovat.
- Zařízení DDoS: Potřebují povědomí o QUIC; útoky založené na UDP a legitimní provoz QUIC vypadají na úrovni paketů odlišně.
- Kontrola paketů: Šifrované hlavičky QUIC brání tradiční hloubkové kontrole paketů; nástroje se musí přizpůsobit
Vzhledem k tomu, že QUIC šifruje většinu metadat, která TCP vystavuje, čelí tradiční nástroje pro sledování sítě problémům. Pomocí sniffingu paketů nelze snadno zjistit stavové kódy HTTP/3 nebo cesty požadavků. Sledování musí probíhat na koncových bodech – serverech, klientech nebo prostřednictvím standardizovaného protokolování.
Akční body pro týmy infrastruktury:
- Ověřte, zda je protokol UDP 443 povolen ve všech segmentech sítě.
- Ověřte si, že load balancery podporují QUIC nebo mohou předávat UDP backendům.
- Aktualizace pravidel pro zmírňování DDoS pro modely provozu QUIC
- Nasazení sběru metrik na úrovni koncových bodů pro pozorovatelnost protokolu HTTP/3
- Testování nouzového chování při zablokování QUIC
Některé organizace se mohou setkat se složitým nastavením sítě, kde je protokol UDP z historických důvodů depriorizován nebo blokován. Postupné zavádění s pečlivým monitorováním pomáhá tyto problémy identifikovat dříve, než ovlivní produkční provoz.
Přechod z HTTP/2 na HTTP/3
Přechod z HTTP/2 na HTTP/3 je navržen jako postupný a zpětně kompatibilní. Nemusíte si vybírat jeden nebo druhý – nasaďteHTTP/3 vedle HTTP/2 a HTTP/1.1 a nechte klienty vyjednávat o nejlepším dostupném protokolu.
Vyjednávání protokolu probíhá prostřednictvím protokolu ALPN (Application-Layer Protocol Negotiation) během předávání protokolu TLS. Klienti inzerují podporované protokoly (např. „h3“, „h2“, „http/1.1“) a servery vyberou preferovanou možnost. Kromě toho mohou servery inzerovat dostupnost protokolu HTTP/3 prostřednictvím hlavičky Alt-Svc v odpovědích HTTP/2, což prohlížečům umožňuje aktualizovat následné požadavky.
Klienti, kteří nepodporují protokol HTTP/3, budou nadále používat protokol HTTP/2 nebo HTTP/1.1 bez jakéhokoli přerušení. Neexistuje žádný den vlajky nebo zlomová změna – migraceje čistě aditivní.
Kontrolní seznam migrace na vysoké úrovni:
- Ověřte připravenost protokolu TLS 1.3: HTTP/3 vyžaduje TLS 1.3; ujistěte se, že váš zásobník TLS a certifikáty jej podporují.
- Potvrzení podpory serveru: Upgradujte na webový server nebo reverzní proxy server s podporou protokolu HTTP/3.
- Aktualizace síťové infrastruktury: Otevřete UDP 443, ověřte kompatibilitu s load balancerem
- Konfigurace protokolu HTTP/3 na serveru: Povolte QUIC listener, nakonfigurujte hlavičky Alt-Svc.
- Důkladně otestujte: K ověření použijte nástroje pro vývojáře prohlížeče, curl a online testery.
- Sledování a porovnávání: Sledujte latenci, chybovost a využití procesoru ve srovnání se základními hodnotami HTTP/2.
- Rozšiřujte postupně: Začněte s nekritickými doménami a rozšiřujte na základě výsledků.
Cílem je bezproblémové soužití. Většina nasazení bude v dohledné budoucnosti používat HTTP/3, HTTP/2 a HTTP/1.1 současně.
Praktické kroky pro povolení protokolu HTTP/3
Krok 1: Zajištění podpory protokolu TLS 1.3
Protokol HTTP/3 vyžaduje integraci protokolu TLS 1.3 do systému QUIC. Zkontrolujte, zda vaše knihovna TLS (OpenSSL 1.1.1+, BoringSSL, LibreSSL atd.) podporuje TLS 1.3. Certifikáty by měly být platné, důvěryhodné pro hlavní prohlížeče a neměly by být samopodepsané pro veřejně přístupné weby. Zkontrolujte, zda vaše konfigurace sady šifer nevylučuje algoritmy TLS 1.3.
Krok 2: Konfigurace webového serveru pro protokol HTTP/3
Pro NGINX budete potřebovat sestavení s podporou QUIC (experimentální větve nebo sestavení třetích stran) nebo počkejte na integraci do hlavního proudu. LiteSpeed má nativní podporu – povolte ji pomocí konfigurace. Envoy podporuje HTTP/3 v posledních verzích. Příklad pro LiteSpeed: Povolte naslouchání na UDP 443, nakonfigurujte certifikát SSL a nastavte protokol tak, aby zahrnoval HTTP/3.
Krok 3: Aktualizace síťové infrastruktury
Otevřete port UDP 443 na všech firewallech mezi servery a internetem. U cloudových nasazení aktualizujte skupiny zabezpečení. Ověřte, zda váš load balancer zvládá UDP – některé (například AWS ALB) vyžadují specifickou konfiguraci nebo NLB pro podporu UDP. Aktualizujte pravidla ochrany proti DDoS tak, aby rozpoznávala vzory provozu QUIC.
Krok 4: Testování funkčnosti protokolu HTTP/3
Použijte nástroje pro vývojáře prohlížeče: otevřete kartu Síť, přidejte sloupec „Protokol“ a ověřte, zda se u požadavků zobrazuje „h3“ nebo „http/3“. Použijte curl s podporou HTTP/3: curl –http3 https://your-domain.com. Vyzkoušejte online testery (vyhledejte „HTTP/3 checker“), které ověřují hlavičky Alt-Svc a úspěšná spojení QUIC.
Krok 5: Postupné zavádění a monitorování
Nejprve nasaďte protokol HTTP/3 na testovací nebo staging doméně. Sledujte klíčové metriky: dobu připojení, čas do prvního bajtu (TTFB), čas do posledního bajtu (TTLB), chybovost a využití procesoru serveru. Porovnání se základními hodnotami HTTP/2. Pokud metriky vypadají dobře, rozšiřte je na další domény. Udržujte záložní protokol HTTP/2 pro klienty, kteří nemohou vyjednat protokol HTTP/3.
Běžné problémy a jejich řešení
Blokování nebo omezování rychlosti UDP
Některé podnikové sítě, poskytovatelé internetových služeb nebo země blokují nebo omezují provoz UDP na portu 443. QUIC obsahuje záložní mechanismy – v případě selhání QUIC budou prohlížeče opakovat pokus přes HTTP/2. Ujistěte se, že konfigurace HTTP/2 zůstává jako záložní cesta v pořádku. U interních podnikových nasazení spolupracujte se síťovými týmy na povolení UDP 443.
Problémy s pozorovatelností
Šifrované hlavičky QUIC ztěžují analýzu na úrovni paketů. Tradiční nástroje, které analyzují hlavičky TCP nebo záznamové vrstvy TLS, nevidí ekvivalentní data v QUIC. Situaci zmírníte zavedením robustního protokolování koncových bodů, exportem metrik QUIC do monitorovacího systému a použitím distribuovaného trasování, které pracuje na aplikační vrstvě.
Zvýšené využití procesoru
Implementace QUIC v uživatelském prostoru mohou spotřebovávat více CPU než TCP optimalizované pro jádro, zejména při vysokém počtu spojení. Vylaďte parametry QUIC (např. limity spojení, algoritmy řízení přetížení). Zvažte hardware s lepším jednovláknovým výkonem. Je-li to možné, použijte hardwarovou akceleraci TLS/QUIC. Sledujte trendy procesoru a v případě potřeby horizontálně škálujte.
Kompatibilita se staršími klienty
Starší prohlížeče, vestavěné systémy a některá rozhraní API nemusí podporovat protokol HTTP/3 nebo dokonce HTTP/2. U těchto klientů zachovejte podporu HTTP/1.1 a HTTP/2 na dobu neurčitou. Použijte vyjednávání ALPN, abyste každému klientovi poskytli nejlepší protokol, který podporuje. Nevypínejte starší verze ve snaze „vynutit“ HTTP/3.
Rušení středního boxu
Některá síťová zařízení vycházejí z předpokladů o struktuře provozu. Šifrovaná konstrukce QUIC záměrně zabraňuje zásahům prostředníka, ale to znamená, že zařízení, která očekávají kontrolu provozu, budou v tichosti selhávat nebo QUIC blokovat. Během testování identifikujte dotčené síťové cesty a spolupracujte se síťovými týmy na aktualizacích zásad.
Problémy s certifikátem
Certifikáty s vlastním podpisem fungují pro testování, ale v produkčních prohlížečích způsobí selhání připojení QUIC. Ujistěte se, že certifikáty vydávají důvěryhodné certifikační autority a že jsou správně nakonfigurovány pro vaše domény.
Bezpečnost, ochrana soukromí a provozní aspekty
Zabezpečení protokolu HTTP/3 je přinejmenším stejně silné jako HTTPS nad HTTP/2. Povinné TLS 1.3, šifrované transportní hlavičky a integrované kryptografické handshaky poskytují ve výchozím nastavení vyšší zabezpečení. Prostor pro útoky se poněkud liší od protokolu HTTPS založeného na protokolu TCP, ale celkový model zabezpečení je robustní.
Bezpečnostní vlastnosti:
- Povinné šifrování: Neexistuje žádný nešifrovaný režim HTTP/3
- Pouze TLS 1.3: Moderní sady šifer s dopředným utajením
- Šifrovaná metadata: Čísla paketů a pole záhlaví jsou skryta před pasivními pozorovateli.
- Integrita dat: Ověřování QUIC zabraňuje manipulaci s daty.
- Ochrana proti zesílení: QUIC omezuje velikost odpovědi před ověřením adresy, aby se zabránilo odrazu DDoS.
Ochrana osobních údajů:
- Snížená viditelnost: Méně metadat vystavených pozorovatelům sítě
- Sledování ID připojení: CID by mohly umožnit sledování, pokud by nebyly otočeny
- Korelační rizika: Dlouhodobá spojení napříč změnami IP by mohla být propojena.
- První strana vs. třetí strana: Stejný model ochrany osobních údajů jako HTTPS pro přístup k obsahu
Provozní problémy:
- Zákonné zachycení: Šifrovaný QUIC komplikuje tradiční přístupy k odposlechům
- Monitorování podniku: Hloubková kontrola paketů nefunguje, je nutné protokolování koncových bodů
- Správa certifikátů: Platí standardní požadavky PKI
- Odmítnutí služby: Připojení QUIC mohou stát více serverových zdrojů; důležité je omezení rychlosti
- Dopředná korekce chyb: Některé implementace mohou přidat redundanci pro odolnost proti ztrátám, což ovlivňuje množství přenášených dat.
Pro organizace, které mají požadavky na dodržování předpisů v oblasti kontroly provozu, vyžaduje protokol HTTP/3 přizpůsobení přístupů. Agenti koncových bodů, integrace SIEM a aktualizované bezpečnostní nástroje nahrazují kontrolu na úrovni paketů.
HTTP/3 pro sítě CDN a rozsáhlé služby
CDN byly jedny z prvních, kdo přijali protokol HTTP/3, a důvody jsou jasné: slouží globálně rozptýleným uživatelům, často na mobilních zařízeních s vysokou latencí připojení na poslední míli. Vlastnosti protokolu HTTP/3 – rychlejší handshake, lepší odolnost proti ztrátám, migrace připojení – přímo prospívají výkonu okrajových sítí CDN.
V okrajových uzlech sítě CDN zkracuje protokol HTTP/3 dobu do prvního bajtu tím, že šetří RTT při handshake. U uživatelů v oblastech s vysokou latencí k okrajovým serverům to může zkrátit načítání stránek o stovky milisekund. Lepší zpracování ztrát paketů znamená konzistentnější výkon v proměnlivých síťových podmínkách.
Běžný model nasazení: HTTP/3 se ukončí na okraji a pak se komunikuje s původními servery pomocí HTTP/2 nebo HTTP/1.1 přes páteřní síť CDN. Díky tomu mohou sítě CDN nabízet uživatelům výhody protokolu HTTP/3, aniž by vyžadovaly jeho podporu od původních serverů. Postupem času bude HTTP/3 přijímat přímo více origins.
CDN a vzory nasazení ve velkém měřítku:
- Ukončení na hraně: HTTP/3 od uživatelů k okraji, HTTP/2 od okraje k původu
- Globální konzistence: QUIC funguje dobře v různých podmínkách sítě
- Optimalizace pro mobilní zařízení: Migrace připojení pomáhá uživatelům v mobilních sítích
- Snížení počtu opakovaných pokusů: Méně neúspěšných spojení znamená méně opakovaných pokusů klientů.
Příklad scénáře: Globální mediální web slouží uživatelům v Asii, Evropě a Americe. Uživatelé v jihovýchodní Asii mají 150-200 ms RTT k nejbližšímu okraji. S protokolem HTTP/3 se počáteční připojení dokončí za jeden RTT místo dvou a obnovení za 0 RTT je téměř okamžité. Pokud tito uživatelé používají mobilní zařízení, která se pohybují mezi sítěmi, migrace připojení zabraňuje frustrujícím opětovným připojením.
Shrnutí a výhled
Protokol HTTP/3 představuje nejvýznamnější změnu způsobu přenosu protokolu HTTP od jeho vzniku. Nahrazením protokolu TCP protokolem QUIC přes UDP řeší protokol HTTP/3 zásadní omezení, která sužovala výkonnost webu – zejména u mobilních uživatelů a ve ztrátových sítích.
Sémantika protokolu http zůstává nezměněna: vývojáři pracují se stejnými požadavky, odpověďmi, hlavičkami a stavovými kódy jako vždy. Mění se vše, co je pod ním – jak datové pakety procházejí sítí, jak se navazují spojení, jak se řeší ztráta paketů a jak se zařízení pohybují mezi sítěmi bez přerušení.
Standardizace je dokončena, podpora prohlížečů je univerzální a hlavní sítě CDN a webové servery mají implementace připravené k výrobě. Potřebné investice do infrastruktury jsou reálné, ale zvládnutelné: otevření protokolu UDP 443, modernizace serverů a aktualizace monitorovacích nástrojů. Pro většinu nasazení je zapnutí HTTP/3 vedle stávající podpory HTTP/2 jednoduchým vývojem, nikoli riskantní migrací.
Do budoucna se HTTP/3 pravděpodobně stane výchozím transportem HTTP během několika příštích let. Vyvíjí se nová rozšíření – vícecestnýQUIC, vylepšené algoritmy řízení přetížení, lepší nástroje pro ladění a monitorování. S tím, jak ekosystém dozrává, se budou dále vyvíjet možnosti ladění a osvědčené postupy.
Klíčové poznatky:
- HTTP/3 zachovává sémantiku HTTP beze změny; liší se pouze transportní vrstva.
- QUIC eliminuje blokování na úrovni přenosu prostřednictvím nezávislých datových toků.
- Integrované rozhraní TLS 1.3 zkracuje dobu nastavení připojení na 1 RTT (0 RTT při obnovení).
- Migrace připojení umožňuje relacím přežít změny v síti.
- Všechny hlavní prohlížeče a sítě CDN dnes podporují protokol HTTP/3.
- Migrace je aditivní: HTTP/2 a HTTP/1.1 fungují i nadále společně s HTTP/3.
- Nejnovější verze protokolu HTTP je připravena pro produkční použití
Pokud jste ještě nezačali vyhodnocovat HTTP/3 pro svou infrastrukturu, máte nejvyšší čas. Povolte jej ve zkušebním prostředí, změřte dopad na klíčové ukazatele a naplánujte postupné zavádění. Zlepšení výkonu – zejména pro mobilní uživatele – je reálné a měřitelné. Web přechází na HTTP/3 a první uživatelé již vidí výhody.