Už viac ako 20 rokov prezeráme webové stránky pomocou protokolu HTTP. Väčšina používateľov ani nepremýšľa o tom, čo to je a ako to funguje. Iní vedia, že niekde pod HTTP je TLS a pod tým je TCP, pod ktorým je IP atď. A ďalší - heretici - veria, že TCP je minulosťou, chcú niečo rýchlejšie, spoľahlivejšie a bezpečnejšie. Ale vo svojich pokusoch vynájsť nový ideálny protokol sa vrátili k technológii 80-tych rokov a snažia sa na nej postaviť svoj odvážny nový svet.
Trochu histórie: HTTP/1.1
V roku 1997 protokol výmeny textových informácií HTTP verzie 1.1 získal vlastný RFC. V tom čase bol protokol používaný prehliadačmi už niekoľko rokov a nový štandard vydržal ďalších pätnásť. Protokol fungoval len na princípe požiadavka-odpoveď a bol určený predovšetkým na prenos textových informácií.
HTTP bol navrhnutý tak, aby bežal nad protokolom TCP, čím sa zabezpečilo, že pakety budú spoľahlivo doručené na miesto určenia. TCP funguje tak, že vytvára a udržiava spoľahlivé spojenie medzi koncovými bodmi a rozdeľuje prevádzku na segmenty. Segmenty majú svoje sériové číslo a kontrolný súčet. Ak náhle jeden zo segmentov nedorazí alebo príde s nesprávnym kontrolným súčtom, prenos sa zastaví, kým sa stratený segment neobnoví.
V HTTP/1.0 sa TCP spojenie uzavrelo po každej požiadavke. Bolo to mimoriadne nehospodárne, pretože... nadviazanie TCP spojenia (3-Way-Handshake) je pomalý proces. HTTP/1.1 zaviedol mechanizmus keep-alive, ktorý vám umožňuje opätovne použiť jedno pripojenie pre viacero požiadaviek. Keďže sa však môže ľahko stať prekážkou, rôzne implementácie HTTP/1.1 umožňujú otvorenie viacerých pripojení TCP k rovnakému hostiteľovi. Napríklad Chrome a najnovšie verzie Firefoxu umožňujú až šesť pripojení.
Šifrovanie malo byť tiež ponechané na iné protokoly a na to bol použitý protokol TLS nad TCP, ktorý síce dáta spoľahlivo chránil, no ešte viac predĺžil čas potrebný na nadviazanie spojenia. Výsledkom bolo, že proces podávania rúk začal vyzerať takto:
Cloudflare ilustrácie
HTTP/1.1 mal teda niekoľko problémov:
- Pomalé nastavenie pripojenia.
- Údaje sa prenášajú v textovej forme, čo znamená, že prenos obrázkov, videí a iných netextových informácií je neúčinný.
- Na jednu požiadavku sa používa jedno TCP spojenie, čo znamená, že ostatné požiadavky musia buď nájsť iné spojenie, alebo počkať, kým ho aktuálna požiadavka neuvoľní.
- Podporovaný je iba ťahový model. V štandarde nie je nič o server-push.
- Nadpisy sa prenášajú v texte.
Ak je server-push implementovaný aspoň pomocou protokolu WebSocket, potom sa zvyšné problémy museli riešiť radikálnejšie.
Trochu modernosti: HTTP/2
V roku 2012 začal Google pracovať na protokole SPDY (vyslovuje sa „rýchly“). Protokol bol navrhnutý tak, aby riešil hlavné problémy HTTP/1.1 a zároveň mal zachovať spätnú kompatibilitu. V roku 2015 zaviedla pracovná skupina IETF špecifikáciu HTTP/2 založenú na protokole SPDY. Tu sú rozdiely v HTTP/2:
- Binárna serializácia.
- Multiplexovanie viacerých HTTP požiadaviek do jedného TCP spojenia.
- Server-push von z krabice (bez WebSocket).
Protokol bol veľkým krokom vpred. On je veľmi a nevyžaduje vytvorenie viacerých TCP spojení: všetky požiadavky na jedného hostiteľa sú multiplexované do jedného. To znamená, že v jednom spojení existuje niekoľko takzvaných streamov, z ktorých každý má svoje vlastné ID. Bonusom je boxovaný server-push.
Multiplexovanie však vedie k ďalšiemu kľúčovému problému. Predstavte si, že asynchrónne vykonávame 5 požiadaviek na jeden server. Pri použití HTTP/2 sa všetky tieto požiadavky uskutočnia v rámci toho istého TCP spojenia, čo znamená, že ak dôjde k strate alebo nesprávnemu prijatiu jedného zo segmentov akejkoľvek požiadavky, prenos všetkých požiadaviek a odpovedí sa zastaví, kým sa stratený segment nezruší. obnovené. Je zrejmé, že čím horšia je kvalita pripojenia, tým pomalšie funguje HTTP/2. V podmienkach, kde stratené pakety tvoria 2 % všetkých paketov, HTTP/1.1 v prehliadači funguje lepšie ako HTTP/2, pretože otvára 6 spojení namiesto jedného.
Tento problém sa nazýva „blokovanie hlavy“ a, žiaľ, nie je možné ho vyriešiť pomocou protokolu TCP.
Ilustrácia Daniel Steinberg
Výsledkom bolo, že vývojári štandardu HTTP/2 odviedli skvelú prácu a urobili takmer všetko, čo sa dalo urobiť na aplikačnej vrstve modelu OSI. Je čas prejsť na transportnú vrstvu a vymyslieť nový transportný protokol.
Potrebujeme nový protokol: UDP vs TCP
Pomerne rýchlo sa ukázalo, že implementácia úplne nového protokolu transportnej vrstvy je v dnešnej realite nemožná úloha. Faktom je, že hardvér alebo middle-boxy (smerovače, firewally, NAT servery...) vedia o transportnej vrstve a naučiť ich niečo nové je mimoriadne náročná úloha. Navyše, podpora transportných protokolov je pevne zakomponovaná do jadra operačných systémov a jadrá tiež nie sú veľmi ochotné meniť sa.
A tu by sa dalo rozhodiť rukami a povedať: „Samozrejme, vymyslíme nový HTTP/3 s preferenciou a kurtizánami, ale implementácia bude trvať 10-15 rokov (približne po tomto čase bude väčšina hardvéru Nahradené), ale je tu ešte jeden nie. Samozrejmou možnosťou je použiť protokol UDP. Áno, áno, rovnaký protokol, ktorý sme používali na prehadzovanie súborov cez LAN koncom deväťdesiatych rokov a začiatkom roku XNUMX. Dokáže s ním pracovať takmer všetok dnešný hardvér.
Aké sú výhody UDP oproti TCP? Po prvé, nemáme reláciu transportnej vrstvy, o ktorej by hardvér vedel. To nám umožňuje určiť reláciu na koncových bodoch sami a vyriešiť tam konflikty. To znamená, že nie sme obmedzení na jednu alebo niekoľko relácií (ako v TCP), ale môžeme ich vytvoriť toľko, koľko potrebujeme. Po druhé, prenos dát cez UDP je rýchlejší ako cez TCP. Teoreticky tak môžeme prelomiť súčasný rýchlostný strop dosiahnutý v HTTP/2.
UDP však nezaručuje spoľahlivý prenos dát. V skutočnosti jednoducho posielame pakety v nádeji, že ich druhý koniec dostane. Nedostali ste? No, nedarilo sa... Na prenos videí pre dospelých to stačilo, ale na vážnejšie veci potrebujete spoľahlivosť, čo znamená, že musíte nad UDP pribaliť niečo iné.
Rovnako ako v prípade HTTP/2, práce na vytvorení nového protokolu začali v spoločnosti Google v roku 2012, teda približne v rovnakom čase, ako začali práce na SPDY. V roku 2013 predstavil Jim Roskind širokej verejnosti , a už v roku 2015 bol pre štandardizáciu v IETF zavedený Internet Draft. Už v tom čase bol protokol vyvinutý Roskindom v Google veľmi odlišný od štandardu, preto sa verzia Google začala nazývať gQUIC.
Čo je QUIC
Po prvé, ako už bolo spomenuté, ide o obal nad UDP. Spojenie QUIC vzniká nad UDP, v ktorom, analogicky s HTTP/2, môže existovať niekoľko streamov. Tieto toky existujú iba na koncových bodoch a sú obsluhované nezávisle. Ak dôjde k strate paketov v jednom streame, neovplyvní to ostatné.
Ilustrácia Daniel Steinberg
Po druhé, šifrovanie už nie je implementované na samostatnej úrovni, ale je zahrnuté v protokole. To vám umožňuje nadviazať spojenie a vymieňať si verejné kľúče v rámci jediného handshake a tiež vám to umožňuje používať šikovný mechanizmus handshake 0-RTT a úplne sa vyhnúť oneskoreniam pri podaní rúk. Okrem toho je teraz možné šifrovať jednotlivé dátové pakety. To vám umožní nečakať na dokončenie prijímania údajov z prúdu, ale dešifrovať prijaté pakety nezávisle. Tento režim prevádzky bol v TCP vo všeobecnosti nemožný, pretože TLS a TCP pracovali nezávisle od seba a TLS nevedelo, na aké kúsky budú TCP dáta rozsekané. A preto nemohol pripraviť svoje segmenty tak, aby sa zmestili do segmentov TCP jedna k jednej a dali sa samostatne dešifrovať. Všetky tieto vylepšenia umožňujú QUIC znížiť latenciu v porovnaní s TCP.
Po tretie, koncept streamovania svetla vám umožňuje odpojiť pripojenie od IP adresy klienta. To je dôležité napríklad vtedy, keď klient prepína z jedného prístupového bodu Wi-Fi na druhý a mení svoju IP. V tomto prípade pri použití TCP nastáva zdĺhavý proces, počas ktorého vyprší časový limit existujúcich TCP spojení a nové spojenia sa vytvoria z novej IP. V prípade QUIC klient jednoducho pokračuje v odosielaní paketov na server z novej IP so starým ID streamu. Pretože ID toku je teraz jedinečné a nie je znovu použité, server chápe, že klient zmenil IP, znova odošle stratené pakety a pokračuje v komunikácii na novej adrese.
Po štvrté, QUIC sa implementuje na úrovni aplikácie, nie na úrovni operačného systému. To vám na jednej strane umožňuje rýchlo vykonávať zmeny v protokole, pretože Ak chcete získať aktualizáciu, stačí aktualizovať knižnicu a nemusíte čakať na novú verziu operačného systému. Na druhej strane to vedie k silnému nárastu spotreby procesora.
A nakoniec titulky. Kompresia hlavičky je jednou z vecí, ktoré sa líšia medzi QUIC a gQUIC. Nevidím zmysel venovať tomu veľa času, len poviem, že vo verzii odoslanej na štandardizáciu bola kompresia hlavičiek čo najviac podobná kompresii hlavičiek v HTTP/2. Môžete si prečítať viac .
O koľko je to rýchlejšie?
Je to ťažká otázka. Faktom je, že kým nemáme štandard, nie je nič špeciálne na meranie. Snáď jediné štatistiky, ktoré máme, sú štatistiky od Google, ktorý gQUIC používa od roku 2013 a v roku 2016 že asi 90 % návštevnosti smerujúcej na ich servery z prehliadača Chrome teraz používa QUIC. V tej istej prezentácii uvádzajú, že stránky sa cez gQUIC načítavajú približne o 5 % rýchlejšie a pri streamovaní videa je o 30 % menej zasekávaní v porovnaní s TCP.
V roku 2017 publikovala skupina výskumníkov vedená Arashom Molavim Kakhkim na štúdium výkonnosti gQUIC v porovnaní s TCP.
Štúdia odhalila niekoľko slabých stránok gQUIC, ako je nestabilita pri miešaní sieťových paketov, chamtivosť (neférovosť) k šírke pásma kanála a pomalší prenos malých (do 10 kb) objektov. Ten však možno kompenzovať použitím 0-RTT. Vo všetkých ostatných skúmaných prípadoch gQUIC vykazoval zvýšenie rýchlosti v porovnaní s TCP. Tu je ťažké hovoriť o konkrétnych číslach. Lepšie čítať alebo .
Tu je potrebné povedať, že tieto údaje sú konkrétne o gQUIC a nie sú relevantné pre vyvíjaný štandard. Čo sa stane s QUIC: je to stále tajomstvo, ale existuje nádej, že slabé stránky identifikované v gQUIC budú zohľadnené a opravené.
Trochu budúcnosti: čo HTTP/3?
Ale tu je všetko jasné: API sa nijako nezmení. Všetko zostane úplne rovnaké ako v HTTP/2. No, ak API zostane rovnaké, prechod na HTTP/3 bude potrebné vyriešiť použitím novej verzie knižnice na backende, ktorá podporuje prenos QUIC. Je pravda, že na starých verziách HTTP budete musieť nejaký čas ponechať záložnú verziu, pretože Internet v súčasnosti nie je pripravený na úplný prechod na UDP.
Kto už podporuje
Tu existujúce implementácie QUIC. Napriek chýbajúcemu štandardu zoznam nie je zlý.
Žiadny prehliadač momentálne nepodporuje QUIC v produkčnom vydaní. Nedávno sa objavili informácie, že podpora HTTP/3 bola zahrnutá v Chrome, ale zatiaľ len v Canary.
Z backendov podporuje iba HTTP/3 и , ale stále experimentálne. NGINX na konci jari 2019 , že začali pracovať na podpore HTTP/3, no ešte to nedokončili.
Aké sú problémy?
Vy a ja žijeme v skutočnom svete, kde žiadna veľká technológia nemôže osloviť masy bez toho, aby narazila na odpor, a QUIC nie je výnimkou.
Najdôležitejšie je, že musíte prehliadaču nejako vysvetliť, že „https://“ už nie je skutočnosťou, že vedie k portu TCP 443. TCP tam vôbec nemusí byť. Na to slúži hlavička Alt-Svc. Umožňuje vám povedať prehliadaču, že tento web je dostupný aj na takom a takom protokole na takej a takej adrese. Teoreticky by to malo fungovať ako kúzlo, ale v praxi sa stretneme s tým, že UDP môže byť napríklad zakázané na firewalle, aby sa predišlo DDoS útokom.
Ale aj keď UDP nie je zakázané, klient sa môže nachádzať za smerovačom NAT, ktorý je nakonfigurovaný tak, aby udržiaval reláciu TCP podľa adresy IP, a keďže používame UDP, ktorý nemá žiadnu hardvérovú reláciu, NAT neudrží pripojenie a reláciu QUIC .
Všetky tieto problémy sú spôsobené skutočnosťou, že protokol UDP sa predtým nepoužíval na prenos internetového obsahu a výrobcovia hardvéru nemohli predvídať, že sa to niekedy stane. Rovnako tak správcovia ešte poriadne nerozumejú tomu, ako správne nakonfigurovať svoje siete, aby QUIC fungovali. Táto situácia sa bude postupne meniť a v každom prípade takéto zmeny zaberú menej času ako implementácia nového protokolu transportnej vrstvy.
Okrem toho, ako už bolo popísané, QUIC výrazne zvyšuje využitie CPU. Daniel Stenberg až trojnásobný nárast procesora.
Kedy príde HTTP/3?
Štandardné do mája 2020, ale vzhľadom na to, že dokumenty naplánované na júl 2019 ostávajú v súčasnosti nedokončené, môžeme povedať, že dátum bude s najväčšou pravdepodobnosťou posunutý.
Google používa implementáciu gQUIC od roku 2013. Ak sa pozriete na požiadavku HTTP odoslanú do vyhľadávacieho nástroja Google, uvidíte toto:
Závery
QUIC teraz vyzerá ako dosť hrubá, ale veľmi sľubná technológia. Vzhľadom na to, že za posledných 20 rokov sa všetky optimalizácie protokolov transportnej vrstvy týkali hlavne TCP, QUIC, ktorý má vo väčšine prípadov najlepší výkon, už teraz vyzerá mimoriadne dobre.
Stále však existujú nevyriešené problémy, s ktorými sa bude treba v najbližších rokoch vysporiadať. Proces môže byť oneskorený kvôli tomu, že ide o hardvér, ktorý nikto rád neaktualizuje, no napriek tomu všetky problémy vyzerajú celkom riešiteľné a HTTP/3 budeme mať skôr či neskôr všetci.
Budúcnosť je hneď za rohom!
Zdroj: hab.com
