Oleme juba üle 20 aasta vaadanud veebilehti HTTP-protokolli kaudu. Enamik kasutajatest ei mõtle sellele, mis see on ja kuidas see töötab. Teised teavad, et kuskil HTTP all on TLS, selle all TCP, all IP jne. Ja kolmandad – heretikud – arvavad, et TCP on minevik, nad tahavad midagi kiiremat, usaldusväärsemat ja turvalisemat. Kuid oma katsetes leiutada uut ideaalset protokolli on nad tagasi pöördunud 80ndate tehnoloogiate juurde ja püüavad ehitada nendele oma imelist uut maailmaga.
Veidi ajalugu: HTTP/1.1
Aastal 1997 sai tekstilise teabe edastamise protokoll HTTP versioon 1.1 oma RFC. Selleks ajaks oli protokolli juba mitu aastat kasutanud brauserid, ja uus standard püsis veel viisteist aastat. Protokoll töötas ainult päringu-vastuse põhimõttel ja oli peamiselt mõeldud tekstilise teabe edastamiseks.
HTTP kavandati töötama TCP-protokolli peal, mis tagab paketide usaldusväärse kohaletoimetamise sihtkohta. TCP tööpõhimõte põhineb usaldusväärse ühenduse loomisel ja hoidmisel lõpp-punktide vahel ning andmete jagamisel segmentideks. Segmentidel on oma järjestusnumber ja kontrollsumma. Kui mõni segment ei jõua kohale või tuleb vale kontrollsumma korral, siis edastus peatub, kuni kadunud segment on taastatud.
HTTP/1.0 TCP-ühendus suleti pärast iga päringut. See oli äärmiselt raiskav, kuna TCP-ühenduse loomine (3-Way-Handshake) ei ole kiire protsess. HTTP/1.1 tutvustas keep-alive mehhanismi, mis võimaldab rakendada ühte ühendust mitme päringu jaoks. Kuid kuna see võib kergesti muutuda pudelikaelaks, siis erinevates HTTP/1.1 rakendustes on lubatud avada mitu TCP-ühendust ühe hostiga. Näiteks Chrome'is ja viimastes Firefoxi versioonides on lubatud kuni kuus ühendust.
Krüpteerimine pidi samuti olema usaldatud teistele protokollidele, ning selleks hakati TCP peal kasutama TLS-protokolli, mis kaitses andmeid piisavalt usaldusväärselt, kuid suurendas veelgi aega, mis oli vajalik ühenduse loomiseks. Seega hakkas käepigistuse protsess välja nägema järgmiselt:
Cloudflare'i joonis
Seega oli HTTP/1.1-l mitmeid probleeme:
- Aeglane ühenduse loomine.
- Andmed edastatakse tekstivormingus, mis tähendab, et piltide, video ja muu mitte-teksti info edastamine on ebaefektiivne.
- Üks TCP-ühendus kasutatakse ühe päringu jaoks, mis tähendab, et ülejäänud päringud peavad leidma uue ühenduse või ootama, kuni praegune päring vabastatakse.
- Toetatakse ainult pull-mudelit. Standardis ei ole midagi serveri-push kohta.
- Pealkirjad edastatakse tekstina.
Kui serveri-push on kuidagi realiseeritud WebSocketi protokolli abil, siis teiste probleemidega pidi tegelema radikaalsemalt.
Veidi tänapäevasust: HTTP/2
2012. aastal alustas Google'i meeskond SPDY protokolli arendamist (selgub hääldus «speedy»). Protokoll pidi lahendama HTTP/1.1 peamised probleemid, säilitades samal ajal tagurpidise ühilduvuse. 2015. aastal tutvustas IETF-i töörühm HTTP/2 spetsifikatsiooni, mis põhineb SPDY protokollil. Siin on, millised erinevused olid HTTP/2-l:
- Binaarne serialiseerimine.
- Mitme HTTP-päringu multitegemine ühes TCP-ühenduses.
- Server-push töötas out of the box (ilma WebSocketita).
Protokoll oli suur samm edasi. See on oluliselt ja ei nõua mitmete TCP-ühenduste loomist: kõik päringud ühele hostile multitegevatakse ühes. See tähendab, et ühes ühenduses on mitu nii-öelda streamingut, millest igaühel on oma ID. Boonusena on olemas serveri-push.
Kuid multitegemine toob kaasa teise nurgakivi probleemi. Kujutage ette, et täidame asünkroonselt 5 päringut ühele serverile. HTTP/2 kasutamisel täidatakse kõik need päringud ühe TCP-ühenduse raames ja see tähendab, et kui üks segmente mõnest päringust kaob või tuleb vale, siis peatatakse kõigi päringute ja vastuste edastamine, kuni kadunud segment taastatakse. On ilmne, et mida halvem on ühenduse kvaliteet, seda aeglasem on HTTP/2. , kui kadunud paketid moodustavad 2% kõigist, toimib HTTP/1.1 brauseris paremini kui HTTP/2, avades 6 ühendust, mitte ühte.
Seda probleemi nimetatakse "head-of-line blocking" ja kahjuks ei ole selle lahendamine TCP kasutamisel võimalik.
Illustratsioon Daniel Steinberg
Kokkuvõttes on HTTP/2 standardi arendajad teinud tohutut tööd ja saavutanud peaaegu kõike, mida OSI mudeli rakenduslikul tasemel saavutada oli võimalik. Aeg on liikuda transporditasemele ja leiutada uus transpordiprotokoll.
Meile on vajalik uus protokoll: UDP vs TCP
Suhteliselt kiiresti sai selgeks, et täiesti uue transporditase protokolli rakendamine on tänapäevaste reaalsuste valguses praktiliselt võimatu. Probleemiks on see, et riistvara, nagu ruuterid, tulemüürid ja NAT-serverid, teavad transporditasemest, ning nende õpetamine millegi uue jaoks on äärmiselt keeruline. Samuti on transpordiprotokollide tugi juba operatsioonisüsteemide tuumas, ja tuumad ei muutu just kiiresti.
Siinkohal võiks käed alla lasta ja öelda: "Loomulikult leiutame me uue HTTP/3 koos preference’ide ja kurtizanidega, kuid selle rakendamine võtab aega 10-15 aastat (umbes nii kaua on vaja, et suurem osa riistvarast asendataks)", kuid on veel üks mitte kõige ilmsem variant: kasutada UDP protokolli. Jah, just seda protokolli, millega me viskasime faile omavahel 90-ndate lõpus ja 2000-ndate alguses. Peaaegu kõik tänapäeva seadmed oskavad selle protsessiga töötada.
Millised on UDP eelised TCP ees? Esiteks on meil puudus transporditaseme sessioonist, millest riistvara teab. See võimaldab meil ise määrata sessiooni lõpp-punktides ja seal ka tekkinud konfliktid lahendada. See tähendab, et me ei ole piiratud ühe või mitme sessiooniga (nagu TCP-s), vaid võime luua neid nii palju, kui me vajame. Teiseks on andmete edastamine UDP kaudu kiirem kui TCP kaudu. Seega teoreetiliselt saame me rikkuda tänapäeva kiirusrekordeid, mis saavutati HTTP/2-s.
Kuid UDP ei garanteeri andmete edastamise usaldusväärsust. Tegelikult saadame lihtsalt pakette, lootes, et teisel pool nad kätte saadakse. Ei saanud kätte? Noh, ei vedanud... Sellest piisab täiskasvanutele mõeldud videote edastamiseks, kuid tõsisemate asjade jaoks on vajalik usaldusväärsus, seega tuleb UDP-le midagi veel peale panna.
Nagu HTTP/2 puhul, algas uue protokolli loomise töö Google'is 2012. aastal, mis tähendab, et see toimus umbes samal ajal, kui hakati töötama SPDY kallal. 2013. aastal tutvustas Jim Roskind laiemale avalikkusele , kuid juba 2015. aastal tehti IETF-is standardiseerimise eesmärgil Internet Draft. Juba tol ajal erines Google'is Rosskindi poolt välja töötatud protokoll oluliselt standardiks tehtud variandist, mistõttu hakati Google'i versiooni kutsuma gQUIC-iks.
Mis on QUIC
Esiteks, nagu juba mainitud, on see UDP ümberkülge. UDP peale tõuseb QUIC-ühendus, mille sees, nagu HTTP/2 puhul, võivad olla mitmed vood. Need vood eksisteerivad ainult lõpp-punktides ja neid teenindatakse iseseisvalt. Kui ühe voo paketid kaovad, ei mõjuta see teisi.
Illustratsioon Daniel Steinberg
Teiseks, krüpteerimine on nüüd rakendatud mitte eraldi tasemena, vaid sisalduse osana protokollis. See võimaldab luua ühenduse ja vahetada avalikke võtmeid ühe käepigistusega, samuti kasutada nutikat mehhanismi 0-RTT käepigistus, et vältida viivitusi käepigistuse ajal. Lisaks on nüüd võimalik krüpteerida eraldi andmepakette. See võimaldab mitte oodata voost andmete vastuvõtmise lõpetamist, vaid dekrüpteerida saadud pakkumisi iseseisvalt. Selline töörežiim oli TCP-s üldse võimatu, kuna TLS ja TCP töötasid iseseisvalt ning TLS ei teadnud, milliseid osi TCP andmeid lõikab. Seega ei saanud TLS ette valmistada oma segmente, et need sobituksid TCP segmentidega üks ühele ja saaksid iseseisvalt dekrüpteeritud. Kõik need täiustused võimaldavad QUIC-il vähendada latentsusaega võrreldes TCP-ga.
Kolmandaks, kergete voogude kontseptsioon võimaldab siduda ühenduse kliendi IP-aadressist. See on oluline näiteks siis, kui klient vahetab ühe Wi-Fi pääsupunkti teiseks, muutes oma IP-d. Sel juhul toimub TCP kasutamisel pikk protsess, mille käigus olemasolevad TCP-ühendused katkestatakse ajaülevaatuse tõttu ja luuakse uued ühendused uue IP-ga. QUIC-i puhul saadab klient lihtsalt serverile pakette uue IP-ga vanast voo ID-st. Kuna voo ID on nüüd ainulaadne ja seda ei kasutata uuesti, mõistab server, et klient on IP-d vahetanud, saadab kadunud paketid tagasi ja jätkab suhtlust uuel aadressil.
Neljandaks, QUIC rakendatakse rakenduse tasandil, mitte operatsioonisüsteemi tasandil. Ühelt poolt võimaldab see protokolli kiiremini muuta, kuna uuenduse saamiseks piisab lihtsalt teegi värskendamisest, mitte uue operatsioonisüsteemi versiooni ootamisest. Teiselt poolt viib see tugevalt protsessori tarbimise suurenemiseni.
Ja viimasena, pealkirjad. Pealkirjade kokkusurumine on just see, mis erineb QUIC-is ja gQUIC-is. Ma ei näe mõtet sellele palju aega pühendada, ütleksin vaid, et standardiseerimisele esitatud versioonis tehti pealkirjade kokkusurumine maksimaalselt sarnaseks HTTP/2 pealkirjade kokkusurumisele. Rohkem saab lugeda .
Kui palju see kiiremini on?
See on keeruline küsimus. Asi on selles, et hetkel pole meil standardit, seega pole ka eriti midagi mõõta. Tõenäoliselt on ainsad statistilised andmed, millega me disposineme, Google'i statistika, kes on kasutanud gQUIC-i alates 2013. aastast ning 2016. aastal , et umbes 90% nende serveritesse Chrome'i brauserist suunatavast liiklusest kasutab nüüd QUIC-it. Samas esituses teatavad nad, et gQUIC abil laaditakse lehti umbes 5% kiiremini ning voogesituse videos on katkestusi 30% vähem võrreldes TCP-ga.
2017. aastal avaldas uurijate grupp, mille juhiks oli Arash Molavi Kakhki, uurimuse gQUIC sooritusvõime kohta võrreldes TCP-ga.
Uuring tuvastas mitmeid gQUIC-i nõrkusi, nagu võrgupakettide segunemisele vastupidamatust, kanalite läbilaskevõimele ebaeetilisust ja väikeste (kuni 10 kB) objektide aeglasemat edastamist. Viimast suudetakse siiski kompenseerida 0-RTT kasutamisega. Kõikidel teistel uuritud juhtudel näitas gQUIC TCP-ga võrreldes kiirusetõusu. Konkreetsetest numbritest siin rääkida on keeruline. Parim on lugeda või .
Siin on oluline märkida, et need andmed puudutavad just gQUIC-i ning ei ole asjakohased arendatava standardi jaoks. Mis QUIC-i puudutab: see jääb veel saladuseks, kuid on lootust, et gQUIC-is tuvastatud nõrkused võetakse arvesse ja parandatakse.
Veidi tulevikust: mis saab HTTP/3-st?
Siin on kõik kristalselt selge: API ei muutu kuidagi. Kõik jääb täpselt samaks nagu see oli HTTP/2-s. Kui API jääb samaks, peab HTTP/3-le üleminek toimuma uusima raamatukogu versiooni kasutuselevõtu kaudu, mis toetab transporti QUIC-i kaudu. Tõsi, üsna kaua tuleb veel säilitada tagasipöördumise võimalus vanadele HTTP versioonidele, kuna internet ei ole praegu valmis täielikuks üleminekuks UDP-le.
Kes juba toetab
Siin olemasolevaid QUIC rakendusi. Vaatamata standardi puudumisele, on nimekiri üsna hea.
Praegu ei toeta ükski brauser QUIC-i tootmisversioonis. Ehkki hiljuti oli teavet, et Chrome on lisanud HTTP/3 toe, on see siiski vaid Canary versioonis.
HTTP/3 toetab praegu ainult ja , kuid veel katsetamiseks. NGINX alustas HTTP/3 toe arendamist 2019. aasta kevadel, , kuid ei ole veel lõpetanud.
Millised on probleemid
Me elame reaalne elu, kus ükski suur tehnoloogia ei saa massidesse murda, ilma et kohtaks vastuolu, ja QUIC ei ole siin erand.
Kõige olulisem on kuidagi seletada brauserile, et "https://" ei pruugi nüüd tähendada, et see läheb 443. TCP porti. Seal ei pruugi üldse olla TCP-d. Selleks kasutatakse Alt-Svc päist. See võimaldab brauserile öelda, et see veebisait on saadaval ka sellise protokolli kaudu sellises aadressis. Teoreetiliselt peaks see töötama nagu kell, kuid praktiliselt võime kokku puutuda sellega, et UDP võib olla 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 TCP sessiooni hoidmiseks IP-aadressi järgi, ja kuna me kasutame UDP-d, milles ei ole riistvaralist sessiooni, ei hoia NAT ühendust ja QUIC sessioon .
Kõik need probleemid on seotud sellega, et UDP-d ei ole varem kasutatud internetisisu edastamiseks ja riistvaratootjad ei osanud ette näha, et selline asi kunagi juhtub. Samuti ei mõista administraatorid veel päris hästi, kuidas õigesti seadistada oma võrgud QUIC töötamiseks. See olukord hakkab aeglaselt muutuma ja igal juhul võtavad sellised muudatused vähem aega kui uue transporditasandi protokolli juurutamine.
Lisaks suurendab QUIC oluliselt protsessori kasutust, nagu juba kirjeldatud. Daniel Stenberg protsessori kasvu kolmekordseks.
Millal saabub HTTP/3
Standard 2020. aasta maiks, kuid arvestades, et hetkel on siiski valmis saamata dokumendid, mis on planeeritud 2019. aasta juuliks, võib öelda, et kuupäeva tõenäoliselt edasi lükatakse.
Google on oma gQUIC rakendust kasutanud alates 2013. aastast. Kui vaadata HTTP-päringut, mis saadetakse Google'i otsingumootorisse, võib näha järgmist:
Järeldused
QUIC näib olevat hetkel üsna toores, kuid väga perspektiivikas tehnoloogia. Arvestades, et viimased 20 aastat on kõik transporditase protokollide optimeerimised põhinenud peamiselt TCP-l, paistab QUIC, mis suurendab jõudlust, juba praegu väga hästi.
Kuid siiski jäävad lahendamata probleemid, millega tuleb lähiaastatel tegeleda. Protsess võib venida, kuna on seotud riistvara, mida keegi ei armasta uuendada, kuid siiski tunduvad kõik probleemid täiesti lahendatavad ja varem või hiljem on meil kõigil HTTP/3.
Tulevik on juba lähedal!
Allikas: habr.com
