Už více než 20 let prohlížíme webové stránky pomocí protokolu HTTP. Většina uživatelů si vůbec neuvědomuje, co to obnáší a jak to funguje. Někteří vědí, že někde pod HTTP je TLS, pod ním TCP, a pod ním IP a tak dále. A třetí – heretici – si myslí, že TCP je minulostí, chtějí něco rychlejšího, spolehlivějšího a zabezpečenějšího. Ale ve svých pokusech vynalézt nový ideální protokol se vrátili k technologiím 80. let a snaží se na nich vybudovat svůj nový úžasný svět.
Trocha historie: HTTP/1.1
V roce 1997 byl protokol pro výměnu textových informací HTTP verze 1.1 oficiálně přijat. V té době byl protokol již několik let používán prohlížeči a nový standard vydržel ještě patnáct let. Protokol fungoval pouze na principu dotaz-odpověď a byl určen převážně pro přenos textových informací.
HTTP byl navržen pro práci nad protokolem TCP, který zaručuje spolehlivou dodávku paketů k adresátovi. Práce TCP spočívá v ustanovení a udržování spolehlivého spojení mezi koncovými body a dělení provozu na segmenty. Segmenty mají svoje pořadové číslo a kontrolní součet. Pokud některý ze segmentů nedorazí nebo dorazí s nesprávným kontrolním součtem, přenos se zastaví, dokud nebude ztracený segment obnoven.
V HTTP/1.0 byla TCP spojení uzavírána po každém požadavku. To bylo velmi nehospodárné, protože establishment TCP spojení (3-Way-Handshake) je pomalý proces. V HTTP/1.1 byl představen mechanismus keep-alive, který umožňuje znovu použít jedno spojení pro více požadavků. Nicméně protože se může snadno stát úzkým hrdlem, v různých implementacích HTTP/1.1 je povoleno otevření několika TCP spojení k jednomu hostiteli. Například v Chromu a v posledních verzích Firefoxu je povoleno až šest spojení.
Šifrování mělo být také ponecháno na jiných protokolech, a proto byl nad TCP používán protokol TLS, který dostatečně spolehlivě chránil data, ale ještě více zvyšoval čas potřebný pro establishment spojení. Nakonec proces handshake vypadal takto:
Ilustrace Cloudflare
HTTP/1.1 tedy mělo řadu problémů:
- Pomalá ustanovení spojení.
- Data jsou předávána textově, což znamená, že přenos obrázků, videí a další ne-textové informace není efektivní.
- Jedno TCP spojení se používá pro jeden dotaz, což znamená, že ostatní dotazy musí buď najít jiné spojení, nebo čekat, až aktuální dotaz uvolní spojení.
- Podporuje se pouze pull model. Ve standardu není nic o server-push.
- Hlavice se předávají textově.
Pokud je server-push nějakým způsobem implementován pomocí protokolu WebSocket, budou ostatní problémy řešeny radikálněji.
Pár moderních novinek: HTTP/2
V roce 2012 začal Google pracovat na protokolu SPDY (vyslovuje se „spidi“). Protokol měl vyřešit hlavní problémy HTTP/1.1 a měl současně zachovat zpětnou kompatibilitu. V roce 2015 pracovní skupina IETF představila specifikaci HTTP/2, založenou na protokolu SPDY. Zde jsou rozdíly v HTTP/2:
- Binární serializace.
- Multiplexování několika HTTP dotazů v jednom TCP spojení.
- Server-push „out of the box“ (bez WebSocket).
Protokol byl velkým pokrokem. Podstatně a nevyžaduje vytvoření několika TCP spojení: všechny dotazy na jeden hostitel se multiplexují do jednoho. To znamená, že v jednom spojení je několik tzv. streamů, z nichž každý má své ID. Jako bonus je k dispozici server-push.
Nicméně multiplexování vede k jiné základní problém. Představte si, že asynchronně vykonáváme 5 dotazů na jeden server. Při použití HTTP/2 budou všechny tyto dotazy vykonány v rámci jednoho TCP spojení, což znamená, že pokud jeden z segmentů jakéhokoliv dotazu ztratí nebo přijde chybně, přenos všech dotazů a odpovědí se zastaví, dokud nebude ztracený segment obnoven. Je zřejmé, že čím horší je kvalita spojení, tím pomaleji HTTP/2 funguje. , za podmínek, kdy ztracené pakety tvoří 2 % ze všech, HTTP/1.1 v prohlížeči vykazuje lepší výkon než HTTP/2 díky tomu, že otevírá 6 spojení, nikoli jedno.
Tento problém se nazývá „head-of-line blocking“ a bohužel se nedá vyřešit při použití TCP.
Ilustrace Daniel Steinberg
Jak již bylo řečeno, tvůrci standardu HTTP/2 odvedli obrovskou práci a udělali prakticky vše, co bylo možné na aplikační úrovni modelu OSI. Nyní je čas přejít na úroveň transportu a vymyslet nový transportní protokol.
Potřebujeme nový protokol: UDP vs TCP
Poměrně rychle se ukázalo, že zavést zcela nový transportní protokol v dnešních reáliích je úkol, který nelze vyřešit. Je to tím, že o transportní úrovni vědí zařízení nebo middle-boxy (routery, firewally, NAT servery...), a naučit je něco nového je velmi složitý úkol. Navíc je podpora transportních protokolů zabudována do jader operačních systémů, která se také nemění příliš ochotně.
A zde by bylo možné sklopit ruce a říct: „Samozřejmě, že vynalezneme nový HTTP/3 s preferencemi a kurtizánami, ale jeho zavedení bude trvat 10-15 let (přibližně za tuto dobu bude většina zařízení nahrazena),“ ale existuje ještě jedna, dalo by se říct, méně zřejmá varianta: využít protokol UDP. Ano, ten protokol, kterým jsme si v devadesátých letech a na začátku nultých házeli soubory po lokální síti. Prakticky všechna současná zařízení s ním umí pracovat.
Jaké jsou výhody UDP oproti TCP? Především v tom, že nemáme žádnou relaci na transportní úrovni, o které by zařízení vědělo. To nám umožňuje definovat relaci na koncových bodech a tam také řešit vzniklé konflikty. To znamená, že nejsme omezeni jednou nebo několika relacemi (jak je tomu v TCP), ale můžeme si jich vytvořit tolik, kolik potřebujeme. Za druhé, přenos dat pomocí UDP je rychlejší než pomocí TCP. Tím pádem teoreticky můžeme překonat současný rychlostní strop, dosažený v HTTP/2.
Nicméně UDP nezaručuje spolehlivost přenosu dat. V podstatě jen posíláme pakety s nadějí, že na druhé straně je obdrží. Neobdrželi? No, nevadí… To bylo dostatečné pro přenos videa pro dospělé, ale pro vážnější věci je potřeba spolehlivost, což znamená, že na UDP budeme muset navrstvit něco dalšího.
Stejně jako v případě HTTP/2 začala práce na vytvoření nového protokolu ve společnosti Google v roce 2012, tedy přibližně ve stejné době, kdy začala práce na SPDY. V roce 2013 Jim Roskind představil široké veřejnosti , a v roce 2015 byl přidán Internet Draft pro standardizaci v IETF. Už v té době se protokol vyvinutý Roskindem v Googlu značně lišil od navrženého standardu, a proto byla googleovská verze nazývána gQUIC.
Co je QUIC
Za prvé, jak již bylo zmíněno, je to obálka nad UDP. Nad UDP se vytváří QUIC-připojení, ve kterém mohou existovat, podobně jako v HTTP/2, více proudů. Tyto proudy existují pouze na koncových bodech a jsou obsluhovány nezávisle. Pokud dojde ke ztrátě paketu v jednom proudu, ostatní to nijak neovlivní.
Ilustrace Daniel Steinberg
Za druhé, šifrování je nyní realizováno nikoli jako samostatná úroveň, ale je zahrnuto v protokolu. To umožňuje navazovat připojení a vyměňovat veřejné klíče na jedno handshake, a také umožňuje používat úhledný mechanismus 0-RTT handshake a tím úplně eliminovat prodlevy při handshake. Kromě toho je nyní možné šifrovat jednotlivé datové pakety. To umožňuje nečekat na dokončení příjmu dat z proudu, ale dešifrovat přijaté pakety nezávisle. Tento způsob práce nebyl s TCP vůbec možný, protože TLS a TCP pracovaly nezávisle na sobě, a TLS nemohlo vědět, na jaké bloky budou data rozdělena TCP. A tím pádem nemohlo připravit své segmenty tak, aby se vešly do segmentů TCP jeden k jednomu a mohly být dešifrovány nezávisle. Všechny tyto vylepšení umožňují QUIC snížit latenci ve srovnání s TCP.
Za třetí, koncept lehkých proudů umožňuje odpojit připojení od IP adresy klienta. To je důležité například v případě, kdy se klient přepíná z jednoho Wi-Fi přístupového bodu na druhý, což mění jeho IP. V tomto případě při použití TCP probíhá dlouhý proces, během kterého existující TCP připojení vypadávají kvůli timeoutu a vytváří se nová připojení s novou IP. V případě QUIC klient jednoduše pokračuje v zasílání paketů serveru z nové IP se starým ID proudu. Protože ID proudu je nyní jedinečné a není znovu používáno, server rozumí tomu, že klient změnil IP, doplní ztracené pakety a pokračuje v komunikaci na nové adrese.
Za čtvrté, QUIC je implementován na úrovni aplikace, nikoli operačního systému. Na jedné straně to umožňuje rychleji provádět změny v protokolu, protože pro aktualizaci stačí pouze aktualizovat knihovnu, a nikoli čekat na novou verzi OS. Na druhé straně to vede k výraznému nárůstu spotřeby CPU.
A nakonec, hlavičky. Komprese hlaviček se týká právě těch aspektů, které se liší mezi QUIC a gQUIC. Nevidím důvod tomu věnovat příliš mnoho času, řeknu jen, že v verzi, poskytnuté ke standardizaci, byla komprese hlaviček co nejvíce podobná kompresi hlaviček v HTTP/2. Podrobnosti lze přečíst .
Jak moc je to rychlejší?
Tohle je složitá otázka. Faktem je, že zatím nemáme standard, takže není moc co měřit. Snad jediná statistická data, která máme, jsou statistiky Googlu, který používá gQUIC od roku 2013 a v roce 2016 , že asi 90 % provozu směřujícího k jejich serverům z prohlížeče Chrome nyní používá QUIC. Ve stejné prezentaci uvádějí, že stránky se prostřednictvím gQUIC načítají přibližně o 5 % rychleji a u streamovaného videa dochází k 30% poklesu záseků ve srovnání s TCP.
V roce 2017 skupina vědců vedená Arash Malavim Kakhkim publikovala o výkonu gQUIC v porovnání s TCP.
Studie odhalila několik slabých stránek gQUIC, jako je nestabilita vůči smíchání síťových paketů, nefér alokace šířky pásma a pomalejší přenos malých (do 10 kB) objektů. Poslední problém se však podaří kompenzovat použitím 0-RTT. Ve všech ostatních zkoumaných případech gQUIC vykázal zvýšení rychlosti oproti TCP. O konkrétních číslech je těžké mluvit. Nejlépe si přečíst nebo .
Je třeba říci, že tato data se týkají právě gQUIC a nejsou aktuální pro vyvíjený standard. Co bude pro QUIC: zatím je to tajemství, ale existuje naděje, že slabé stránky, které byly zjištěny u gQUIC, budou zohledněny a opraveny.
Trocha budoucnosti: co s HTTP/3?
Tady je vše naprosto jasné: API se nijak nezmění. Všechno zůstane přesně tak, jak bylo v HTTP/2. Pokud tedy API zůstává stejné, přechod na HTTP/3 bude vyžadovat použití nové verze knihovny, která podporuje transport přes QUIC na backendu. Nicméně, ještě dlouho bude potřeba mít fallback na starší verze HTTP, protože internet nyní není připraven na plný přechod na UDP.
Kdo již podporuje
Tady existující implementace QUIC. Přestože chybí standard, seznam není špatný.
Žádný prohlížeč v současnosti nepodporuje QUIC v produkčním vydání. Nedávno se objevila informace, že Chrome aktivoval podporu HTTP/3, ale zatím pouze v Canary.
Mezi backendy HTTP/3 podporuje pouze a , ale zatím experimentálně. NGINX na konci jara 2019 , oznámil, že začali pracovat na podpoře HTTP/3, ale zatím to nedokončili.
Jaké jsou problémy
Žijeme v reálném světě, kde žádná velká technologie nemůže proniknout do mas, aniž by se setkala s odporem, a QUIC není výjimkou.
Nejdůležitější je nějakým způsobem vysvětlit prohlížeči, že “https://” nyní nemusí vést na 443. TCP port. Může tam být dokonce žádný TCP. K tomu se používá hlavička Alt-Svc. Ta umožňuje sdělit prohlížeči, že tento web je také dostupný na určitém protokolu na určité adrese. Teoreticky by to mělo fungovat bez problémů, ale v praxi se setkáváme s tím, že UDP může být například zakázán na firewallu kvůli DDoS útokům.
Ale i když UDP není zakázán, klient může být za NAT routerem, který je nastaven na udržení TCP sezení podle IP adresy, a protože používáme UDP, kde není hardwarové sezení, NAT nebude udržovat spojení a QUIC sezení .
Všechny tyto problémy vyplývají z toho, že UDP nebylo dříve používáno k přenosu internetového obsahu a výrobci hardwaru nemohli předvídat, že se to někdy stane. Stejně tak administrátoři zatím přesně nechápou, jak správně nastavit své sítě pro práci s QUIC. Tato situace se postupně mění, a v každém případě takové změny zabere méně času než implementace nového transportního protokolu.
Kromě toho, jak již bylo popsáno, QUIC výrazně zvyšuje zatížení procesoru. Daniel Stenberg nárůst zatížení procesoru až třikrát.
Kdy nastane HTTP/3
Standard K květnu 2020, ale s ohledem na to, že dokumenty plánované na červenec 2019 jsou stále nedokončené, lze říci, že datum bude pravděpodobně posunuto.
Google používá svou implementaci gQUIC od roku 2013. Pokud se podíváte na HTTP žádost, která je odesílána na vyhledávač Google, můžete vidět toto:
Závěry
QUIC nyní vypadá jako poměrně syrová, ale velmi perspektivní technologie. Vzhledem k tomu, že posledních 20 let se všechny optimalizace transportních protokolů zaměřovaly převážně na TCP, QUIC, většinou vítězící z hlediska výkonu, nyní vypadá velmi dobře.
Nicméně stále existují nevyřešené problémy, se kterými se budeme muset potýkat v následujících letech. Proces může být zpožděn kvůli tomu, že je zapojeno zařízení, které nikdo nechce aktualizovat, ale všechny problémy se přesto zdají být řešitelné a dříve či později budeme mít všichni HTTP/3.
Budoucnost je blízko!
Zdroj: habr.com
