Több mint 20 éve HTTP protokoll használatával nézzük meg a weboldalakat. A legtöbb felhasználó nem is gondol arra, hogy mi ez és hogyan működik. Mások tudják, hogy valahol HTTP alatt van TLS, alatta pedig TCP, ami alatt az IP stb. Megint mások - az eretnekek - úgy vélik, hogy a TCP a múlté, valami gyorsabbat, megbízhatóbbat és biztonságosabbat akarnak. Ám az új ideális protokoll feltalálására tett kísérleteik során visszatértek a 80-as évek technológiájához, és arra próbálják felépíteni bátor új világukat.
Egy kis történelem: HTTP/1.1
1997-ben a HTTP 1.1-es verziójú szöveges információcsere protokoll saját RFC-t kapott. Akkoriban a protokollt már több éve használták a böngészők, és az új szabvány további tizenötig tartott. A protokoll csak kérés-válasz elven működött, és főként szöveges információk továbbítására szolgált.
A HTTP-t úgy tervezték, hogy a TCP protokollon felül fusson, biztosítva a csomagok megbízható kézbesítését a rendeltetési helyükre. A TCP úgy működik, hogy megbízható kapcsolatot hoz létre és tart fenn a végpontok között, valamint a forgalmat szegmensekre bontja. A szegmenseknek saját sorozatszámuk és ellenőrző összegük van. Ha az egyik szegmens hirtelen nem érkezik meg, vagy hibás ellenőrzőösszeggel érkezik, akkor az átvitel leáll, amíg az elveszett szegmens vissza nem áll.
HTTP/1.0 esetén a TCP-kapcsolat minden kérés után leállt. Ez rendkívül pazarló volt, mert... a TCP kapcsolat létrehozása (3-Way-Handshake) lassú folyamat. A HTTP/1.1 bevezette az életben tartási mechanizmust, amely lehetővé teszi egy kapcsolat újrafelhasználását több kéréshez. Mivel azonban könnyen szűk keresztmetszetgé válhat, a HTTP/1.1 különféle megvalósításai lehetővé teszik több TCP-kapcsolat megnyitását ugyanahhoz a gazdagéphez. Például a Chrome és a Firefox legújabb verziói legfeljebb hat csatlakozást tesznek lehetővé.
A titkosítást is más protokollokra kellett volna hagyni, ehhez pedig TCP-n keresztül a TLS protokollt használták, amely megbízhatóan védte az adatokat, de tovább növelte a kapcsolat létrehozásához szükséges időt. Ennek eredményeként a kézfogási folyamat így kezdett kinézni:
Cloudflare illusztráció
Így a HTTP/1.1-nek számos problémája volt:
- Lassú kapcsolat beállítása.
- Az adatok továbbítása szöveges formában történik, ami azt jelenti, hogy a képek, videók és egyéb nem szöveges információk továbbítása hatástalan.
- Egy kérelemhez egy TCP-kapcsolat kerül felhasználásra, ami azt jelenti, hogy a többi kérésnek vagy másik kapcsolatot kell találnia, vagy meg kell várnia, amíg az aktuális kérés felszabadítja azt.
- Csak a pull modell támogatott. A szabványban nincs semmi a szerver-push-ról.
- A címsorok szövegben kerülnek továbbításra.
Ha a szerver-push legalább WebSocket protokollal valósul meg, akkor a fennmaradó problémákat radikálisabban kellett kezelni.
Egy kis modernitás: HTTP/2
2012-ben a Google elkezdett dolgozni az SPDY (ejtsd: „speedy”) protokollon. A protokollt a HTTP/1.1 főbb problémáinak megoldására tervezték, ugyanakkor a visszamenőleges kompatibilitást is fenn kellett tartania. 2015-ben az IETF munkacsoport bevezette az SPDY protokollon alapuló HTTP/2 specifikációt. Itt vannak a HTTP/2 különbségei:
- Bináris szerializálás.
- Több HTTP kérés multiplexelése egyetlen TCP-kapcsolatba.
- Szerver-push a dobozból (WebSocket nélkül).
A protokoll nagy előrelépést jelentett. Ő erősen és nem szükséges több TCP-kapcsolat létrehozása: az egy gazdagéphez intézett összes kérés egy multiplexelésre kerül. Vagyis egy kapcsolatban több úgynevezett folyam van, amelyek mindegyikének saját azonosítója van. A bónusz egy dobozos szerver-push.
A multiplexelés azonban egy másik kulcsfontosságú problémához vezet. Képzelje el, hogy aszinkron módon 5 kérést hajtunk végre egy szerver felé. HTTP/2 használatakor ezek a kérések ugyanazon a TCP-kapcsolaton belül kerülnek végrehajtásra, ami azt jelenti, hogy ha valamelyik kérés valamelyik szegmense elveszik vagy hibásan érkezik, az összes kérés és válasz továbbítása leáll, amíg az elveszett szegmens meg nem érkezik. helyreállították. Nyilvánvaló, hogy minél rosszabb a kapcsolat minősége, annál lassabban működik a HTTP/2. , olyan körülmények között, amikor az elveszett csomagok az összes csomag 2%-át teszik ki, a HTTP/1.1 a böngészőben jobban teljesít, mint a HTTP/2, mivel egy helyett 6 kapcsolatot nyit meg.
Ezt a problémát „head-of-line blokkolásnak” nevezik, és sajnos TCP használatával nem lehet megoldani.
Illusztráció: Daniel Steinberg
Ennek eredményeként a HTTP/2 szabvány fejlesztői nagyszerű munkát végeztek, és szinte mindent megtettek, amit az OSI modell alkalmazási rétegében lehetett. Ideje leszállni a szállítási rétegre, és kitalálni egy új szállítási protokollt.
Új protokollra van szükségünk: UDP vs TCP
Elég hamar világossá vált, hogy egy teljesen új szállítási réteg protokoll megvalósítása a mai valóságban lehetetlen feladat. Az tény, hogy a hardverek vagy a középső dobozok (routerek, tűzfalak, NAT szerverek...) ismerik a szállítási réteget, és valami újat tanítani nekik rendkívül nehéz feladat. Emellett a szállítási protokollok támogatása be van építve az operációs rendszerek kernelébe, és a kernelek sem nagyon hajlandóak változtatni.
És itt felteheti az ember a kezét, és azt mondhatja: "Természetesen ki fogunk találni egy új HTTP/3-at, előszeretettel és udvarhölgyekkel, de 10-15 évbe fog telni a megvalósítás (kb. ennyi idő után a hardver nagy része kicserélve), de van még egy nem úgy A kézenfekvő lehetőség az UDP protokoll használata. Igen, igen, ugyanaz a protokoll, amelyet a XNUMX-es évek végén és a XNUMX-es évek elején használtunk a LAN-on keresztüli fájlok továbbítására. Szinte az összes mai hardver képes működni vele.
Melyek az UDP előnyei a TCP-vel szemben? Először is, nincs olyan szállítási réteg munkamenetünk, amelyről a hardver tud. Ez lehetővé teszi, hogy magunk határozzuk meg a munkamenetet a végpontokon, és megoldjuk az ott felmerülő konfliktusokat. Vagyis nem korlátozódunk egy vagy több munkamenetre (mint a TCP-ben), hanem annyit tudunk létrehozni belőlük, amennyire szükségünk van. Másodszor, az UDP-n keresztüli adatátvitel gyorsabb, mint a TCP-n keresztül. Így elméletileg áttörhetjük a HTTP/2-ben elért jelenlegi sebességplafont.
Az UDP azonban nem garantálja a megbízható adatátvitelt. Valójában egyszerűen csak csomagokat küldünk, remélve, hogy a másik vég megkapja azokat. Nem kapta meg? Nos, nem szerencsés... Ez elég volt a felnőtteknek szóló videók átviteléhez, de komolyabb dolgokhoz megbízhatóság kell, vagyis valami mást kell csomagolni az UDP tetejére.
A HTTP/2-höz hasonlóan a Google-nál is 2012-ben kezdődött el egy új protokoll létrehozása, vagyis nagyjából egy időben, amikor az SPDY-n elkezdődött. 2013-ban Jim Roskind bemutatta a nagyközönségnek , és már 2015-ben az Internet Draft szabványosításra került az IETF-ben. Már akkoriban a Roskind által a Google-nál kifejlesztett protokoll nagyban eltért a szabványtól, így a Google verziót gQUIC-nak kezdték hívni.
Mi az a QUIC
Először is, amint már említettük, ez egy UDP feletti burkoló. Az UDP tetején egy QUIC kapcsolat emelkedik, amelyben a HTTP/2-vel analóg módon több adatfolyam is létezhet. Ezek az adatfolyamok csak a végpontokon léteznek, és egymástól függetlenül szolgálnak ki. Ha az egyik adatfolyamban csomagvesztés történik, az nem lesz hatással a többire.
Illusztráció: Daniel Steinberg
Másodszor, a titkosítást már nem külön szinten valósítják meg, hanem benne van a protokollban. Ez lehetővé teszi a kapcsolat létrehozását és a nyilvános kulcsok cseréjét egyetlen kézfogásban, valamint lehetővé teszi az okos 0-RTT kézfogási mechanizmus használatát, és általában elkerüli a kézfogási késéseket. Ezen kívül most már lehetőség van az egyes adatcsomagok titkosítására is. Ez lehetővé teszi, hogy ne várja meg az adatfolyamból az adatok fogadásának befejezését, hanem a kapott csomagok önálló visszafejtését. Ez a működési mód általában lehetetlen volt a TCP-ben, mert A TLS és a TCP egymástól függetlenül működött, és a TLS nem tudhatta, hogy a TCP-adatokat milyen darabokra vágják fel. Ezért nem tudta felkészíteni a szegmenseit úgy, hogy azok egytől egyig TCP szegmensekbe illeszkedjenek, és egymástól függetlenül visszafejthetők legyenek. Mindezek a fejlesztések lehetővé teszik, hogy a QUIC csökkentse a késleltetést a TCP-hez képest.
Harmadszor, a fény streaming koncepciója lehetővé teszi a kapcsolat leválasztását az ügyfél IP-címétől. Ez fontos például akkor, ha egy kliens átvált egyik Wi-Fi hozzáférési pontról a másikra, és megváltoztatja az IP-címét. Ebben az esetben a TCP használatakor egy hosszadalmas folyamat megy végbe, amely során a meglévő TCP-kapcsolatok időtúllépést okoznak, és új kapcsolatok jönnek létre egy új IP-ről. A QUIC esetében a kliens egyszerűen tovább küldi a csomagokat a szervernek egy új IP-ről a régi adatfolyam-azonosítóval. Mert A streamazonosító mostantól egyedi, és nem kerül újra felhasználásra; a szerver megérti, hogy a kliens megváltoztatta az IP-címet, újraküldi az elveszett csomagokat, és az új címen folytatja a kommunikációt.
Negyedszer, a QUIC az alkalmazás szintjén valósul meg, nem az operációs rendszer szintjén. Ez egyrészt lehetővé teszi a protokoll gyors módosítását, mert Frissítéshez csak frissítenie kell a könyvtárat, ahelyett, hogy várna az operációs rendszer új verziójára. Másrészt ez a processzorfogyasztás erőteljes növekedéséhez vezet.
És végül a főcímek. A fejléctömörítés az egyik olyan dolog, amely különbözik a QUIC és a gQUIC között. Nem látom értelmét ennek sok időt szánni, csak annyit mondok, hogy a szabványosításra benyújtott verzióban a fejléctömörítést a HTTP/2-ben a fejléctömörítéshez a lehető legjobban hasonlították. Bővebben olvashatsz .
Mennyivel gyorsabb?
Nehéz kérdés. Az tény, hogy amíg nincs szabványunk, addig nincs mit mérni. Talán az egyetlen statisztikánk a Google statisztikái, amely 2013 és 2016 óta használja a gQUIC-ot. hogy a Chrome böngészőből a szervereikre érkező forgalom mintegy 90%-a már QUIC-ot használ. Ugyanebben a prezentációban arról számolnak be, hogy az oldalak körülbelül 5%-kal gyorsabban töltődnek be a gQUIC-on keresztül, és 30%-kal kevesebb a dadogás a videó streamelésben a TCP-hez képest.
2017-ben Arash Molavi Kakhki vezette kutatócsoport publikált hogy tanulmányozza a gQUIC teljesítményét a TCP-hez képest.
A tanulmány feltárta a gQUIC számos gyengeségét, mint például a hálózati csomagok keveredésének instabilitása, a csatorna sávszélességével szembeni mohóság (méltánytalanság), valamint a kis (10 kb-ig) objektumok lassabb átvitele. Ez utóbbi azonban 0-RTT használatával kompenzálható. Az összes többi vizsgált esetben a gQUIC sebességnövekedést mutatott a TCP-hez képest. Itt nehéz konkrét számokról beszélni. Olvass inkább vagy .
Itt el kell mondani, hogy ezek az adatok kifejezetten a gQUIC-ról szólnak, és nem relevánsak a kidolgozás alatt álló szabvány szempontjából. Mi fog történni a QUIC-cal: ez még titok, de van remény, hogy a gQUIC-ban azonosított gyengeségeket figyelembe veszik és kijavítják.
Egy kis jövő: mi a helyzet a HTTP/3-mal?
De itt minden kristálytiszta: az API semmilyen módon nem fog változni. Minden pontosan ugyanaz marad, mint a HTTP/2-ben volt. Nos, ha az API változatlan marad, akkor a HTTP/3-ra való átállást meg kell oldani a QUIC szállítást támogató háttérrendszeren lévő könyvtár friss verziójával. Igaz, jó ideig meg kell őriznie a tartalékot a HTTP régi verzióinál, mert Az internet jelenleg nem áll készen az UDP-re való teljes átállásra.
Aki már támogatja
Itt meglévő QUIC implementációk. A szabvány hiánya ellenére a lista nem rossz.
Jelenleg egyetlen böngésző sem támogatja a QUIC-ot éles kiadásban. Nemrég voltak olyan információk, hogy a HTTP/3 támogatása bekerült a Chrome-ba, de eddig csak a Canary-ban.
A háttérprogramok közül csak a HTTP/3 támogatja и , de még kísérleti jellegű. NGINX 2019 tavaszának végén , hogy elkezdtek dolgozni a HTTP/3 támogatáson, de még nem fejezték be.
Mik a problémák?
Te és én a való világban élünk, ahol egyetlen nagy technológia sem érheti el a tömegeket anélkül, hogy ellenállásba ütközne, és ez alól a QUIC sem kivétel.
A legfontosabb dolog az, hogy valahogy el kell magyarázni a böngészőnek, hogy a „https://” már nem tény, hogy a 443-as TCP-porthoz vezet. Lehet, hogy egyáltalán nincs TCP. Ehhez az Alt-Svc fejlécet használják. Lehetővé teszi, hogy közölje a böngészővel, hogy ez a weboldal is elérhető ilyen és olyan protokollon, ilyen és ilyen címen. Elméletileg ennek úgy kellene működnie, mint egy bűbájnak, de a gyakorlatban találkozni fogunk azzal a ténnyel, hogy a DDoS támadások elkerülése végett például tűzfalon tiltható az UDP.
De még ha az UDP nincs is tiltva, a kliens egy NAT útválasztó mögött állhat, amely úgy van beállítva, hogy IP-cím alapján TCP-munkamenetet tartson, és mivel UDP-t használunk, amelynek nincs hardveres munkamenete, a NAT nem tartja fenn a kapcsolatot, és egy QUIC szekciót .
Mindezek a problémák abból fakadnak, hogy az UDP-t korábban nem használták internetes tartalom továbbítására, és a hardvergyártók nem tudták előre látni, hogy ez valaha is megtörténik. Ugyanígy a rendszergazdák még nem igazán értik, hogyan kell megfelelően konfigurálni a hálózataikat a QUIC működéséhez. Ez a helyzet fokozatosan megváltozik, és mindenesetre az ilyen változtatások kevesebb időt vesznek igénybe, mint egy új szállítási réteg protokolljának megvalósítása.
Ezenkívül, amint azt már leírtuk, a QUIC nagymértékben növeli a CPU-használatot. Daniel Stenberg processzor növekedés akár háromszorosára.
Mikor érkezik meg a HTTP/3?
Standard 2020 májusára, de tekintettel arra, hogy a 2019 júliusára tervezett dokumentumok jelenleg még befejezetlenek, elmondhatjuk, hogy a dátumot nagy valószínűséggel kitolják.
Nos, a Google 2013 óta használja a gQUIC megvalósítását. Ha megnézi a Google keresőmotornak küldött HTTP-kérést, ezt fogja látni:
Álláspontja
A QUIC most meglehetősen nyers, de nagyon ígéretes technológiának tűnik. Figyelembe véve, hogy az elmúlt 20 évben a szállítási réteg protokolljainak minden optimalizálása elsősorban a TCP-re vonatkozott, a legtöbb esetben a legjobb teljesítményt nyújtó QUIC már most is rendkívül jól néz ki.
Vannak azonban még megoldatlan problémák, amelyeket a következő néhány évben meg kell oldani. A folyamat elhúzódhat, mert hardverről van szó, amit senki sem szeret frissíteni, de ennek ellenére minden probléma megoldhatónak tűnik, és előbb-utóbb mindannyiunknak meglesz a HTTP/3.
A jövő a sarkon van!
Forrás: will.com