Již více než 20 let prohlížíme webové stránky pomocí protokolu HTTP. Většina uživatelů ani nepřemýšlí o tom, co to je a jak to funguje. Jiní vědí, že někde pod HTTP je TLS a pod tím TCP, pod kterým je IP a tak dále. A ještě jiní – heretici – věří, že TCP je minulostí, chtějí něco rychlejšího, spolehlivějšího a bezpečnějšího. Ale ve svých pokusech vymyslet nový ideální protokol se vrátili k technologii 80. let a snaží se na ní postavit svůj odvážný nový svět.
Trochu historie: HTTP/1.1
V roce 1997 získal protokol pro výměnu textových informací HTTP verze 1.1 vlastní RFC. V té době byl protokol používán prohlížeči již několik let a nový standard vydržel dalších patnáct. Protokol fungoval pouze na principu dotaz-odpověď a byl určen zejména pro přenos textových informací.
HTTP byl navržen tak, aby běžel nad protokolem TCP a zajistil, že pakety budou spolehlivě doručeny na místo určení. TCP funguje tak, že vytváří a udržuje spolehlivé spojení mezi koncovými body a rozděluje provoz na segmenty. Segmenty mají své vlastní sériové číslo a kontrolní součet. Pokud náhle jeden 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 bylo TCP spojení ukončeno po každém požadavku. Bylo to extrémně plýtvání, protože... navázání TCP spojení (3-Way-Handshake) je pomalý proces. HTTP/1.1 zavedl mechanismus keep-alive, který umožňuje znovu použít jedno připojení pro více požadavků. Protože se však může snadno stát úzkým hrdlem, různé implementace HTTP/1.1 umožňují otevření více připojení TCP ke stejnému hostiteli. Například Chrome a nejnovější verze Firefoxu umožňují až šest připojení.
Šifrování mělo být také ponecháno na jiných protokolech a k tomu byl použit protokol TLS přes TCP, který sice spolehlivě chránil data, ale dále prodlužoval dobu potřebnou k navázání spojení. V důsledku toho začal proces podání ruky vypadat takto:
Cloudflare ilustrace
Proto měl HTTP/1.1 řadu problémů:
- Pomalé nastavení připojení.
- Data jsou přenášena v textové podobě, což znamená, že přenos obrázků, videí a jiných netextových informací je neúčinný.
- Pro jeden požadavek je použito jedno TCP spojení, což znamená, že ostatní požadavky musí buď najít jiné spojení, nebo počkat, až jej aktuální požadavek uvolní.
- Podporován je pouze tahový model. Ve standardu není nic o server-push.
- Nadpisy jsou přenášeny v textu.
Pokud je server-push implementován alespoň pomocí protokolu WebSocket, pak bylo třeba radikálněji řešit zbývající problémy.
Trochu modernosti: HTTP/2
V roce 2012 začal Google pracovat na protokolu SPDY (vyslovováno jako „rychlý“). Protokol byl navržen tak, aby řešil hlavní problémy HTTP/1.1 a zároveň měl zachovat zpětnou kompatibilitu. V roce 2015 zavedla pracovní skupina IETF specifikaci HTTP/2 založenou na protokolu SPDY. Zde jsou rozdíly v HTTP/2:
- Binární serializace.
- Multiplexování více HTTP požadavků do jednoho TCP spojení.
- Server-push z krabice (bez WebSocket).
Protokol byl velkým krokem vpřed. On silně a nevyžaduje vytvoření více TCP spojení: všechny požadavky na jednoho hostitele jsou multiplexovány do jednoho. To znamená, že v jednom spojení existuje několik tzv. streamů, z nichž každý má své vlastní ID. Bonusem je boxovaný server-push.
Multiplexování však vede k dalšímu klíčovému problému. Představte si, že asynchronně provádíme 5 požadavků na jeden server. Při použití HTTP/2 budou všechny tyto požadavky prováděny v rámci stejného TCP spojení, což znamená, že pokud dojde ke ztrátě nebo nesprávnému přijetí některého ze segmentů jakéhokoli požadavku, přenos všech požadavků a odpovědí se zastaví, dokud nebude ztracený segment odstraněn. obnovena. Je zřejmé, že čím horší je kvalita připojení, tím pomalejší HTTP/2 funguje. V podmínkách, kdy ztracené pakety tvoří 2 % všech paketů, funguje HTTP/1.1 v prohlížeči lépe než HTTP/2, protože otevírá 6 připojení místo jednoho.
Tento problém se nazývá „head-of-line blocking“ a bohužel jej nelze vyřešit pomocí TCP.
Ilustrace Daniel Steinberg
Výsledkem bylo, že vývojáři standardu HTTP/2 odvedli skvělou práci a udělali téměř vše, co bylo možné udělat na aplikační vrstvě modelu OSI. Je čas jít dolů do transportní vrstvy a vymyslet nový transportní protokol.
Potřebujeme nový protokol: UDP vs TCP
Poměrně rychle se ukázalo, že implementace zcela nového protokolu transportní vrstvy je v dnešní realitě nemožným úkolem. Faktem je, že hardware nebo middle-boxy (routery, firewally, NAT servery...) vědí o transportní vrstvě a naučit je něco nového je extrémně obtížný úkol. Navíc podpora transportních protokolů je zabudována v jádře operačních systémů a jádra také nejsou příliš ochotná se měnit.
A tady by se dalo rozhodit rukama a říct „Samozřejmě vymyslíme nový HTTP/3 s předností a kurtizánami, ale implementace bude trvat 10–15 let (přibližně po této době bude většina hardwaru nahrazen), ale je tu ještě jeden ne. Zřejmou možností je použití protokolu UDP. Ano, ano, stejný protokol, který jsme používali k přehazování souborů přes LAN koncem devadesátých let a začátkem XNUMX. století. Dokáže s ním pracovat téměř veškerý dnešní hardware.
Jaké jsou výhody UDP oproti TCP? Za prvé, nemáme relaci transportní vrstvy, o které by hardware věděl. To nám umožňuje určit relaci na koncových bodech sami a vyřešit tam konflikty. To znamená, že nejsme omezeni na jednu nebo několik relací (jako v TCP), ale můžeme jich vytvořit tolik, kolik potřebujeme. Za druhé, přenos dat přes UDP je rychlejší než přes TCP. Teoreticky tak můžeme prolomit současný rychlostní strop dosažený v HTTP/2.
UDP však nezaručuje spolehlivý přenos dat. Ve skutečnosti jednoduše posíláme pakety v naději, že je druhý konec přijme. neobdrželi? No, to se nepovedlo... Na přenos videí pro dospělé to stačilo, ale pro vážnější věci potřebujete spolehlivost, což znamená, že musíte nad UDP zabalit něco jiného.
Stejně jako u HTTP/2 začaly práce na vytvoření nového protokolu ve společnosti Google v roce 2012, tedy přibližně ve stejnou dobu, kdy začaly práce na SPDY. V roce 2013 představil Jim Roskind široké veřejnosti , a již v roce 2015 byl zaveden Internet Draft pro standardizaci v IETF. Již v té době byl protokol vyvinutý Roskindem v Googlu velmi odlišný od standardu, a tak se verze Google začala nazývat gQUIC.
Co je QUIC
Za prvé, jak již bylo zmíněno, jedná se o obal přes UDP. Připojení QUIC vzniká nad UDP, ve kterém, analogicky s HTTP/2, může existovat několik streamů. Tyto streamy existují pouze na koncových bodech a jsou obsluhovány nezávisle. Pokud dojde ke ztrátě paketů v jednom proudu, neovlivní to ostatní.
Ilustrace Daniel Steinberg
Za druhé, šifrování již není implementováno na samostatné úrovni, ale je zahrnuto v protokolu. To vám umožňuje navázat spojení a vyměňovat si veřejné klíče v jediném handshake a také vám umožňuje používat chytrý mechanismus handshake 0-RTT a zcela se vyhnout zpoždění při podání ruky. Nově je navíc možné šifrovat jednotlivé datové pakety. To vám umožní nečekat na dokončení příjmu dat ze streamu, ale samostatně dešifrovat přijaté pakety. Tento režim provozu byl v TCP obecně nemožný, protože TLS a TCP fungovaly nezávisle na sobě a TLS nemohlo vědět, na jaké kousky budou data TCP rozsekána. A proto nemohl své segmenty připravit tak, aby se vešly do segmentů TCP jedna ku jedné a mohly být samostatně dešifrovány. Všechna tato vylepšení umožňují QUIC snížit latenci ve srovnání s TCP.
Za třetí, koncept streamování světla vám umožňuje oddělit připojení od IP adresy klienta. To je důležité například tehdy, když klient přechází z jednoho přístupového bodu Wi-Fi na jiný a mění svou IP. V tomto případě při použití TCP nastává zdlouhavý proces, během kterého vyprší časový limit stávajících TCP spojení a nová spojení jsou vytvářena z nové IP. V případě QUIC klient jednoduše pokračuje v odesílání paketů na server z nové IP adresy se starým ID streamu. Protože ID streamu je nyní jedinečné a není znovu použito; server chápe, že klient změnil IP, znovu odešle ztracené pakety a pokračuje v komunikaci na nové adrese.
Za čtvrté, QUIC je implementován na úrovni aplikace, nikoli na úrovni operačního systému. To na jedné straně umožňuje rychle provádět změny protokolu, protože Chcete-li získat aktualizaci, stačí aktualizovat knihovnu, nikoli čekat na novou verzi operačního systému. Na druhou stranu to vede k silnému nárůstu spotřeby procesoru.
A nakonec titulky. Komprese záhlaví je jednou z věcí, které se mezi QUIC a gQUIC liší. Nevidím smysl tomu věnovat mnoho času, jen řeknu, že ve verzi předložené ke standardizaci byla komprese hlaviček co nejvíce podobná kompresi hlaviček v HTTP/2. Můžete si přečíst více .
O kolik je to rychlejší?
To je těžká otázka. Faktem je, že dokud nemáme standard, není nic zvláštního k měření. Snad jedinou statistikou, kterou máme, jsou statistiky od Googlu, který gQUIC používá od roku 2013 a v roce 2016 že asi 90 % provozu směřujícího na jejich servery z prohlížeče Chrome nyní používá QUIC. Ve stejné prezentaci uvádějí, že stránky se načítají o 5 % rychleji prostřednictvím gQUIC a ve streamování videa je o 30 % méně zasekávání ve srovnání s TCP.
V roce 2017 publikovala skupina výzkumníků vedená Arashem Molavi Kakhkim studovat výkon gQUIC ve srovnání s TCP.
Studie odhalila několik slabých stránek gQUIC, jako je nestabilita při míchání síťových paketů, chamtivost (nespravedlnost) k šířce pásma kanálu a pomalejší přenos malých (do 10 kb) objektů. To však může být kompenzováno použitím 0-RTT. Ve všech ostatních studovaných případech vykazoval gQUIC ve srovnání s TCP zvýšení rychlosti. Zde je těžké mluvit o konkrétních číslech. Lepší čtení nebo .
Zde je třeba říci, že tato data se konkrétně týkají gQUIC a pro vyvíjenou normu nejsou relevantní. Co se stane s QUIC: je to stále tajemství, ale existuje naděje, že slabiny zjištěné v gQUIC budou zohledněny a opraveny.
Trochu budoucnosti: co HTTP/3?
Zde je ale vše křišťálově jasné: API se nijak nezmění. Vše zůstane úplně stejné jako v HTTP/2. Pokud API zůstane stejné, přechod na HTTP/3 bude muset být vyřešen použitím nové verze knihovny na backendu, která podporuje přenos QUIC. Je pravda, že na starých verzích HTTP budete muset nějakou dobu ponechat záložní verzi, protože Internet v současné době není připraven na úplný přechod na UDP.
Kdo již podporuje
zde je stávající implementace QUIC. Navzdory chybějícímu standardu není seznam špatný.
Žádný prohlížeč aktuálně nepodporuje QUIC v produkčním vydání. Nedávno se objevila informace, že podpora HTTP/3 byla zahrnuta v Chrome, ale zatím pouze v Canary.
Z backendů podporuje pouze HTTP/3 и , ale stále experimentální. NGINX na konci jara 2019 , že začali pracovat na podpoře HTTP/3, ale ještě to nedokončili.
jaké jsou problémy?
Vy a já žijeme ve skutečném světě, kde žádná velká technologie nemůže oslovit masy, aniž by narazila na odpor, a QUIC není výjimkou.
Nejdůležitější je, že musíte prohlížeči nějak vysvětlit, že „https://“ již není skutečností, že vede k portu TCP 443. TCP tam vůbec nemusí být. K tomu slouží hlavička Alt-Svc. Umožňuje vám sdělit prohlížeči, že tento web je dostupný také na takovém a takovém protokolu na takové a takové adrese. Teoreticky by to mělo fungovat na jedničku, ale v praxi narazíme na to, že UDP lze například zakázat na firewallu, aby se zabránilo DDoS útokům.
Ale i když UDP není zakázáno, klient může být za routerem NAT, který je nakonfigurován tak, aby držel TCP relaci podle IP adresy, a protože používáme UDP, který nemá žádnou hardwarovou relaci, NAT neudrží připojení a relaci QUIC .
Všechny tyto problémy jsou způsobeny skutečností, že protokol UDP se dříve nepoužíval k přenosu internetového obsahu a výrobci hardwaru nemohli předvídat, že k tomu někdy dojde. Stejně tak správci ještě pořádně nerozumí tomu, jak správně nakonfigurovat své sítě, aby QUIC fungoval. Tato situace se bude postupně měnit a v každém případě takové změny zaberou méně času než implementace nového protokolu transportní vrstvy.
Navíc, jak již bylo popsáno, QUIC výrazně zvyšuje využití CPU. Daniel Stenberg až trojnásobný růst procesoru.
Kdy dorazí HTTP/3?
Standardní do května 2020, ale vzhledem k tomu, že dokumenty plánované na červenec 2019 zůstávají v tuto chvíli nedokončené, můžeme říci, že datum bude s největší pravděpodobností posunuto.
Google používá svou implementaci gQUIC od roku 2013. Pokud se podíváte na požadavek HTTP odeslaný do vyhledávače Google, uvidíte toto:
Závěry
QUIC nyní vypadá jako poněkud hrubá, ale velmi slibná technologie. Vzhledem k tomu, že za posledních 20 let se všechny optimalizace protokolů transportní vrstvy týkaly hlavně TCP, QUIC, který má ve většině případů nejlepší výkon, už vypadá extrémně dobře.
Stále však existují nevyřešené problémy, které bude třeba v příštích letech řešit. Proces může být zdržen kvůli tomu, že se jedná o hardware, který nikdo neaktualizuje rád, ale přesto všechny problémy vypadají docela řešitelné a dříve nebo později budeme mít HTTP/3 všichni.
Budoucnost je hned za rohem!
Zdroj: www.habr.com