Oleme juba rohkem kui 20 aastat sirvinud veebilehti HTTP protokolli kaudu. Enamik kasutajatest ei mõtle sellele, mis see on ja kuidas see töötab. Teised teavad, et HTTP all on TLS, selle all TCP, mille all on IP ja nii edasi. Ja kolmandad – erahoolikud – usuvad, et TCP on minevik, nad tahavad midagi kiiremat, usaldusväärsemat ja turvalisemat. Kuid oma katsetes leiutada uus ideaalne protokoll on nad naasnud 80-ndate tehnoloogiate juurde ja püüavad nende põhjal luua oma imelise uue maailma.
Veidi ajalugu: HTTP/1.1
Aastal 1997 sai tekstilise informatsiooni edastamise protokoll HTTP versioon 1.1 oma RFC. Sel hetkel oli protokoll olnud juba mitu aastat brauserites kasutusel ja uus standard püsis veel viisteist aastat. Protokoll toimis ainult päringu-vastuse põhimõttel ning oli peamiselt mõeldud tekstilise informatsiooni edastamiseks.
HTTP projekteeriti töötama TCP protokolli kohal, mis tagab pakettide usaldusväärse edastamise sihtkohta. TCP töö põhineb usaldusväärse ühenduse loomisel ja säilitamisel lõpp-punktide vahel ning liikluse jagamisel segmentideks. Segmentidel on oma järjestusnumber ja kontrollsumma. Kui mõni segment ei jõua kohale või jõuab vale kontrollsummaga, siis edastus peatub, kuni kadunud segment on taastatud.
HTTP/1.0 puhul suleti TCP-ühendus pärast iga päringut. See oli äärmiselt raiskav, kuna TCP-ühenduse loomine (3-Way-Handshake) on aeglane protsess. HTTP/1.1-s tutvustati keep-alive mehhanismi, mis võimaldab kasutada sama ühendust mitme päringu jaoks. Kuid kuna see võib kergesti muutuda pudelikaelaks, lubatakse erinevates implementatsioonides HTTP/1.1 avada mitu TCP-ühendust ühe hostiga. Näiteks Chrome'is ja viimastes Firefox'i versioonides on lubatud kuni kuus ühendust.
Krüpteerimine pidi samuti olema usaldatud teistele protokollidele, ja selle jaoks hakati TCP kohal kasutama TLS protokolli, mis kaitses andmeid usaldusväärselt, kuid suurendas oluliselt aega, mis oli vajalik ühenduse loomisele. Tulemuseks sai käepigistuse protsess välja näha selline:
Illustratsioon Cloudflare
Seega oli HTTP/1.1-l mitmeid probleeme:
- Aeglane ühenduse loomine.
- Andmed edastatakse tekstivormingus, mistõttu piltide, videote ja muu mitte-tekstilise informatsiooni edastamine on ebaefektiivne.
- Üks TCP-ühendus kasutatakse ühe päringu jaoks, mis tähendab, et ülejäänud päringud peavad kas leidma endale muu ühenduse või ootama, kuni praegune päring jätab selle vabaks.
- Toetatakse ainult pull-mudelit. Standardis pole midagi serveri-push kohta.
- Pealkirjad edastatakse tekstina.
Kui serveri-push'i suudetakse mingil määral rakendada WebSocketi protokolli abil, siis teiste probleemidega pidi tegelema radikaalselt.
Veidi tänapäevast: HTTP/2
2012. aastal hakkas Google'is töötama protokolli SPDY kallal (hääldatakse kui 'spidi'). Protokoll pidi lahendama HTTP/1.1 peamised probleemid, säilitades samal ajal tagurpidi ühilduvuse. Aastal 2015 esitas IETF töögrupp HTTP/2 spetsifikatsiooni, mis põhines SPDY-l. Siin on, millised olid HTTP/2 erinevused:
- Binaarne serialiseerimine.
- Mitme HTTP-päringu multiploiseerimine ühte TCP-ühendusse.
- Serveri-push karbist väljas (ilma WebSocketita).
Protokoll oli suur samm edasi. See on oluliselt ja ei nõua mitme TCP-ühenduse loomist: kõik päringud ühele hostile multiploiseeritakse ühte. See tähendab, et ühes ühenduses on mitu nn voogu, igaühel on oma ID. Boonusena tuleb karbist väljas serveri-push.
Siiski toob multiploiseerimine esile teise põhiprobleemi. Kujutage ette, et teeme asünkroonselt 5 päringut ühele serverile. HTTP/2 puhul täidetakse kõik need päringud ühe TCP-ühenduse raames, seega kui mõni segment mis tahes päringust kaob või jõuab vale, peatub kõikide päringute ja vastuste edastamine, kuni kadunud segment on taastatud. Ilmselgelt, mida halvem on ühenduse kvaliteet, seda aeglasemalt töötab HTTP/2. , kui kaotatud paketid moodustavad 2% kõigist, siis HTTP/1.1 käitub brauseris paremini kui HTTP/2, kuna see avab 6 ühendust, mitte ühte.
Seda probleemi nimetatakse 'head-of-line blocking' ja kahjuks pole selle lahendamine TCP kasutamisel võimalik.
Illustratsioon Daniel Steinberg
Kokkuvõttes on HTTP/2 standardi arendajad teinud suure töö ning saavutanud praktiliselt kõik, mis on võimalik OSI mudeli rakendustasandil. On aeg liikuda transporttase ja leiutada uus transportprotokoll.
Me vajame uut protokolli: UDP vs TCP
Ruttu sai selgeks, et täiesti uue transporttase protokolli rakendamine on tänase eluoludega praktiliselt teostatav. Probleem seisneb selles, et transporttase on tuntud riistvara või vahekatkestuste (ruuterid, tulemüürid, NAT-serverid...) seas ning neid millegi uue õpetamine on äärmiselt keeruline. Lisaks sellele on transportprotokollide toetus süvendas operatsioonisüsteemide tuumadesse, mis samuti ei muutu just väga kergesti.
Siin võiks käed alla anda ja öelda: "Me leiutame kindlasti uue HTTP/3 koos lugupeetud ja kaunitaridega, kuid selle rakendamine võtab 10-15 aastat (umbes nii kaua võtab aega enamus riistvara asendamine)". Küll aga on veel üks mitte kõige ilmsem variant: kasutada UDP protokolli. Jah, see sama protokoll, millega me saatsime faile kohalikus võrgus 90ndate lõpus ja 2000ndate alguses. Peaaegu kõik tänapäeva seadmed oskavad sellega töötada.
Mis on UDP eelised võrreldes TCP-ga? Esiteks, meil ei ole transporttase sessiooni, millest riistvara teab. See võimaldab meil ise määrata sessiooni lõpp-punktides ja seal lahendada tekkivaid konflikte. See tähendab, et me ei ole piiratud ühe või mitme sessiooniga (nagu TCP), vaid saame luua neid nii palju, kui soovime. Teiseks, andmete edastamine UDP kaudu toimub kiiremini kui TCP kaudu. Nii et teoorias suudame me ületada tänase HTTP/2 kiiruspiiri.
Kuid UDP ei garanteeri andmeedastuse usaldusväärsust. Tegelikult saadame me lihtsalt pakette, lootes, et teisel pool need kätte saadakse. Kui ei saadud? Tundub, et ei vedanud... Selleks, et edastada täiskasvanute video, oli seda piisavalt, kuid tõsisemate asjade jaoks on vajalik usaldusväärsus, seega tuleb midagi veel UDP peale lisada.
Nagu HTTP/2 puhul, algas uue protokolli loomine Google'is 2012. aastal, umbes samal ajal kui SPDY arendamine. 2013. aastal esitles Jim Roskind seda laiemale avalikkusele. , ning juba 2015. aastal tehti Interneti kavand standardimiseks IETF-is. Juba tol ajal erines Google'is loodud protokoll Roskindi poolt oluliselt standardisse viidud versioonist, mistõttu hakati Google'i versiooni nimetama gQUIC-iks.
Mis on QUIC?
Esiteks, nagu juba öeldud, on see UDP ümberpakendamine. UDP kohal tekib QUIC-ühendus, milles võivad eksisteerida mitu voogu, nagu HTTP/2 puhul. Need vood eksisteerivad ainult lõpp-punktides ja teenindatakse iseseisvalt. Kui paketi kaotus tekib ühes voos, ei mõjuta see teisi.
Illustratsioon Daniel Steinberg
Teiseks, krüpteerimine on nüüd integreeritud protokolli, mitte eraldi tasemena. See võimaldab luua ühenduse ja vahetada avalike võtmeid ühes käepigistuses, samuti võimaldab see kasutada nutikat mehhanismi 0-RTT käepigistus, vältides viivitusi käepigistuste ajal. Lisaks on nüüd võimalik krüpteerida üksikuid andmepakette. See tähendab, et ei pea ootama voost andmete vastuvõtmise lõpetamist, vaid valmiskärbed saadud paketid iseseisvalt. Selline töörežiim oli TCP-s täiesti võimatu, kuna TLS ja TCP töötasid iseseisvalt ning TLS ei teadnud, millisteks tükkideks TCP andmeid jagab. Seega ei saanud TLS oma segmente ette valmistada nii, et need mahuksid TCP segmente ühte ja saaksid iseseisvalt dekodeerida. Kõik need täiustused võimaldavad QUIC-il vähendada latentsust võrreldes TCP-ga.
Kolmandaks, kergete voogude kontseptsioon võimaldab siduda ühenduse kliendi IP-aadressist lahti. See on oluline näiteks siis, kui klient vahetab ühe Wi-Fi juurdepääsupunkti teise, muutes oma IP-d. Sellisel juhul, kui kasutatakse TCP-d, toimub pikk protsess, mille käigus olemasolevad TCP-ühendused lähevad ajavahemiku tõttu puruks ja uued ühendused luuakse uue IP-ga. QUIC puhul saadab klient lihtsalt pakette serverile uue IP-ga vana voo ID-ga. Kuna voo ID on nüüd ainulaadne ja seda ei taaskasutata, mõistab server, et klient on IP-d vahetanud, saadab kaotatud paketid teele ja jätkab suhtlust uuel aadressil.
Neljandaks, QUIC rakendatakse rakenduslootel, mitte operatsioonisüsteemis. See võimaldab protokolli kiiremini muuta, kuna värskenduse saamiseks piisab lihtsalt teegi uuendamisest, mitte uue OS-i versiooni ootamisest. Teiselt poolt põhjustab see protsessori kasutamise märkimisväärset suurenemist.
Ja viimaseks, pealkirjad. Pealkirjade kompressioon seondub just nendele erinevustele QUIC-is ja gQUIC-is. Ei näe mõtet sellele palju aega pühendada, ütlen vaid, et standardiseerimiseks esitatud versioonis tehti pealkirjade kompressioon võimalikult sarnaseks HTTP/2-s kasutatavale kompressioonile. Rohkem saab lugeda .
Kui palju kiiremini see on?
See on keeruline küsimus. Asi on selles, et hetkel meil ei ole standardit, midagi pole mõõta. Tõenäoliselt on ainsad statistilised andmed, millega me ei saa arvestada, Google'i statistika, kes on gQUIC-i kasutanud alates 2013. aastast ja 2016 , et umbes 90% Chrome'i brauserist nende serveritesse suunduvalt liiklusest kasutab nüüd QUIC-i. Samas esitlusel teatatakse, et gQUIC-is laaditakse lehed umbes 5% kiiremini ja voogedastuse videos on 30% vähem viivitusi võrreldes TCP-iga.
2017. aastal avaldas Arash Molavi Kakhki juhtimisel uurijate rühm uuringu gQUIC-i ja TCP vahelise jõudluse võrdlemiseks.
Uuring tõi esile mitmeid gQUIC-i nõrkusi, nagu võimetus võrgu pakette segada, kanalite läbilaskevõime ebaausus ja väikeste (kuni 10 kb) objektide aeglasem edastamine. Viimast saame siiski kompenseerida 0-RTT kasutamisega. Kõigis teistes uuritud juhtumites näitas gQUIC kiiruselist tõusu võrreldes TCP-ga. Konkreetsetes numbrites on siin raske rääkida. Parim on lugeda või .
Siinkohal tuleb öelda, et need andmed puudutavad just gQUIC-i ja need ei ole aktuaalsed väljatöötatava standardi jaoks. Mis juhtub QUIC-iga: see on praegu seitsme pitseri taga saladus, kuid on lootust, et gQUIC-is avastatud nõrkused võetakse arvesse ja parandatakse.
Veidi tulevikku: mis saab HTTP/3-st?
Siin on kõik kristalselt selge: API ei muutu. Kõik jääb täpselt samaks nagu HTTP/2-s. Kui API jääb samaks, peab üleminek HTTP/3-le toimuma värskete teekide versioonide kasutuselevõtuga, mis toetavad QUIC-i transporti. Kuid üsna kaua tuleb endiselt hoida tagasipöördeid vanadele HTTP-versioonidele, kuna internet ei ole praegu valmis täielikuks üleminekuks UDP-le.
Kes juba toetab
Siin on olemasolevaid QUIC-i rakendusi. Malasi puudumise tõttu on loetelu siiski tubli.
Praegu ei toeta ükski brauser QUIC-i avalikus versioonis. Hiljuti tuli teade, et Chrome'is on lisatud HTTP/3 tugi, kuid praegu ainult Canary versioonis.
Tagapool toetab HTTP/3 ainult ja , kuid praegu eksperimentaalselt. NGINX teatas 2019. aasta kevadel, et nad on alustanud HTTP/3 toe arendamist, kuid pole veel lõpetanud.
Millised probleemid on
Elame tõeliselt maailmas, kus ükski suur tehnoloogia ei saa massidesse minna, ilma et see kohtuks vastupanuga, ja QUIC ei ole erand.
Kõige olulisem on kuidagi brauserile selgitada, et "https://" ei tähenda enam tingimata 443. TCP-porti. Seal ei pruugi TCP-d üldse olla. Selleks kasutatakse Alt-Svc pealkirja. See võimaldab teavitada brauserit, et see veebileht on saadaval ka mingil protokollil teatud aadressil. Teoorias peaks see töötama nagu kellavärk, kuid praktikas võime kokku puutuda olukordadega, kus UDP on näiteks tulemüüris keelatud DDoS rünnakute vältimiseks.
Kuid isegi kui UDP-d ei ole keelatud, võib klient olla NAT-ruuteri taga, mis on seadistatud säilitama TCP-seanssi IP-aadressi kaudu, ja kuna me kasutame UDP-d, kus ei ole riistvaralist seanssi, ei hoia NAT ühendust ja QUIC-seanss .
Need probleemid on seotud sellega, et UDP-d pole enne interneti sisu edastamiseks kasutatud ja riistvara tootjad ei suutnud ette näha, et see kunagi juhtub. Samuti ei mõista administraatorid praegu eriti hästi, kuidas oma võrke õigesti seadistada, et QUIC toimiks. See olukord muutub järk-järgult, ja igal juhul võtab sarnaste muudatuste tegemine vähem aega kui uue transportprotokolli rakendamine.
Lisaks, nagu juba mainitud, suurendab QUIC oluliselt protsessori kasutamist. Daniel Stenberg protsessori kasvu kuni kolme korda.
Kui HTTP/3 tuleb
Standart maiks 2020, kuid arvestades, et hetkel jäävad juuli 2019 plaanitud dokumendid lõpetamata, võib öelda, et kuupäeva tõenäoliselt edasi lükatakse.
Aga Google kasutab oma gQUIC rakendust alates 2013. aastast. Kui vaadata HTTP-päringut, mis saadetakse Google'i otsingumootorile, võib näha järgmist:
Järeldused
QUIC näeb praegu välja kui suhteliselt toores, kuid väga paljutõotav tehnoloogia. Arvestades, et viimased 20 aastat on kõik transpordikihtide protokollide optimeerimised peamiselt käsitlenud TCP-d, tundub QUIC, mis enamasti pakub paremat jõudlust, juba praegu suurepärasena.
Siiski jäävad veel lahendamata probleemid, millega tuleb lähiaastatel tegeleda. Protsess võib viibida, kuna tegeletakse riistvaraga, mille uuendamine ei ole kellegi seas populaarne, ent kõik probleemid näivad siiski olevat lahendatavad, ja varem või hiljem on HTTP/3 kõigile meie seas.
Tulevik on lähedal!
Allikas: habr.com
