Rohkem kui 20 aastat oleme vaadanud veebilehti HTTP-protokolli abil. Enamik kasutajaid isegi ei mõtle, mis see on ja kuidas see töötab. Teised teavad, et kuskil HTTP all on TLS ja selle all on TCP, mille all on IP jne. Ja veel teised - ketserid - usuvad, et TCP on minevik, nad tahavad midagi kiiremat, usaldusväärsemat ja turvalisemat. Kuid püüdes leiutada uut ideaalset protokolli, on nad naasnud 80ndate tehnoloogia juurde ja üritavad sellele oma vaprat uut maailma ehitada.
Natuke ajalugu: HTTP/1.1
1997. aastal omandas tekstiinfovahetuse protokoll HTTP versioon 1.1 oma RFC. Sel ajal olid brauserid seda protokolli kasutanud juba mitu aastat ja uus standard kestis veel viisteist. Protokoll töötas ainult päring-vastus põhimõttel ja oli mõeldud peamiselt tekstiinfo edastamiseks.
HTTP töötati välja TCP-protokolli peal, tagades pakettide usaldusväärse kohaletoimetamise sihtkohta. TCP töötab, luues ja säilitades usaldusväärse ühenduse lõpp-punktide vahel ning jagades liikluse segmentideks. Segmentidel on oma seerianumber ja kontrollsumma. Kui äkki üks segmentidest ei saabu või saabub vale kontrollsummaga, siis edastamine peatub, kuni kaotatud segment taastatakse.
HTTP/1.0 puhul suleti TCP-ühendus pärast iga päringut. See oli äärmiselt raiskav, sest... TCP-ühenduse loomine (3-Way-Handshake) on aeglane protsess. HTTP/1.1 tutvustas elushoidmise mehhanismi, mis võimaldab kasutada ühte ühendust mitme päringu jaoks. Kuid kuna see võib kergesti muutuda kitsaskohaks, võimaldavad HTTP/1.1 erinevad teostused avada mitu TCP-ühendust samasse hosti. Näiteks Chrome ja Firefoxi uusimad versioonid võimaldavad kuni kuut ühendust.
Krüpteerimine pidi jääma ka teistele protokollidele ja selleks kasutati üle TCP protokolli TLS, mis kaitses andmeid usaldusväärselt, kuid suurendas veelgi ühenduse loomiseks kuluvat aega. Selle tulemusena hakkas käepigistuse protsess välja nägema järgmine:
Cloudflare'i illustratsioon
Seega oli HTTP/1.1-l mitmeid probleeme:
- Aeglane ühenduse loomine.
- Andmeid edastatakse teksti kujul, mis tähendab, et piltide, videote ja muu mittetekstilise teabe edastamine on ebaefektiivne.
- Ühe päringu jaoks kasutatakse ühte TCP-ühendust, mis tähendab, et teised päringud peavad leidma teise ühenduse või ootama, kuni praegune päring selle vabastab.
- Toetatakse ainult tõmbemudelit. Standardis pole server-tõuke kohta midagi.
- Pealkirjad edastatakse tekstina.
Kui server-push on vähemalt WebSocket-protokolli kasutades realiseeritud, siis tuli ülejäänud probleemidega radikaalsemalt tegeleda.
Natuke modernsust: HTTP/2
2012. aastal alustas Google tööd SPDY (hääldatakse "kiire") protokolli kallal. Protokoll oli mõeldud HTTP/1.1 peamiste probleemide lahendamiseks ja samal ajal pidi säilitama tagasiühilduvuse. 2015. aastal võttis IETF töörühm kasutusele SPDY protokollil põhineva HTTP/2 spetsifikatsiooni. Siin on HTTP/2 erinevused:
- Binaarne serialiseerimine.
- Mitme HTTP päringu multipleksimine üheks TCP-ühenduseks.
- Serveri karbist väljalükkamine (ilma WebSocketita).
Protokoll oli suur samm edasi. Ta tugevalt ja see ei nõua mitme TCP-ühenduse loomist: kõik päringud ühele hostile multipleksitakse üheks. See tähendab, et ühes ühenduses on mitu nn voogu, millest igaühel on oma ID. Boonuseks on kastiga serveri tõuge.
Multipleksimine toob aga kaasa veel ühe olulise probleemi. Kujutage ette, et me täidame ühele serverile asünkroonselt 5 päringut. HTTP/2 kasutamisel teostatakse kõik need päringud sama TCP-ühenduse piires, mis tähendab, et kui mis tahes päringu üks segment läheb kaotsi või võetakse vastu valesti, peatub kõigi päringute ja vastuste edastamine seni, kuni kadunud segment on lõppenud. taastatud. Ilmselgelt, mida halvem on ühenduse kvaliteet, seda aeglasemalt HTTP/2 töötab. , tingimustes, kus kaotatud paketid moodustavad 2% kõigist pakettidest, toimib HTTP/1.1 brauseris paremini kui HTTP/2, kuna see avab 6 ühendust, mitte ühe.
Seda probleemi nimetatakse "pea-of-line blokeerimiseks" ja kahjuks ei ole seda võimalik TCP-d kasutades lahendada.
Daniel Steinbergi illustratsioon
Selle tulemusena tegid HTTP/2 standardi arendajad suurepärast tööd ja tegid peaaegu kõike, mida OSI mudeli rakenduskihis teha sai. On aeg minna alla transpordikihile ja leiutada uus transpordiprotokoll.
Vajame uut protokolli: UDP vs TCP
Üsna kiiresti sai selgeks, et täiesti uue transpordikihi protokolli juurutamine on tänapäeva reaalsuses võimatu ülesanne. Fakt on see, et riistvara või keskmised kastid (ruuterid, tulemüürid, NAT-serverid...) teavad transpordikihti ja neile millegi uue õpetamine on äärmiselt keeruline ülesanne. Lisaks on transpordiprotokollide tugi juhtmega ühendatud operatsioonisüsteemide tuumaga ja ka tuumad ei ole eriti valmis muutuma.
Ja siin võiks käed laiutada ja öelda: "Muidugi, me leiutame eelistuse ja kurtisaanidega uue HTTP/3, kuid selle juurutamine võtab aega 10-15 aastat (umbes selle aja pärast on suurem osa riistvarast asendatud), kuid on veel üks mitte nii Ilmselge võimalus on kasutada UDP-protokolli. Jah, jah, sama protokoll, mida kasutasime XNUMXndate lõpus ja XNUMXndate alguses failide üle kohtvõrgu loopimiseks. Peaaegu kogu tänapäeva riistvara saab sellega töötada.
Millised on UDP eelised TCP ees? Esiteks ei ole meil transpordikihi seanssi, millest riistvara teab. See võimaldab meil lõpp-punktide seansi ise määrata ja seal konflikte lahendada. See tähendab, et me ei piirdu ühe või mitme seansiga (nagu TCP-s), vaid saame luua neid nii palju kui vaja. Teiseks on andmete edastamine UDP kaudu kiirem kui TCP kaudu. Seega saame teoreetiliselt läbi murda praegusest HTTP/2-s saavutatud kiiruslaest.
UDP ei garanteeri aga usaldusväärset andmeedastust. Tegelikult saadame lihtsalt pakke, lootes, et teine ots need vastu võtab. Ei ole kätte saanud? No ei vedanud... Sellest piisas täiskasvanutele mõeldud videote edastamiseks, aga tõsisemate asjade jaoks on vaja töökindlust, mis tähendab, et UDP peale tuleb mähkida midagi muud.
Nagu HTTP/2 puhul, alustati uue protokolli loomisega Google'is 2012. aastal, st umbes samal ajal, kui algas töö SPDY kallal. 2013. aastal esitles Jim Roskind laiemale avalikkusele , ja juba 2015. aastal võeti IETF-is standardiseerimiseks kasutusele Internet Draft. Juba sel ajal erines Roskindi Google'is välja töötatud protokoll standardist oluliselt, nii et Google'i versiooni hakati nimetama gQUIC-ks.
Mis on QUIC
Esiteks, nagu juba mainitud, on see UDP ümbris. UDP peale kerkib QUIC-ühendus, milles analoogselt HTTP/2-ga võib eksisteerida mitu voogu. Need vood eksisteerivad ainult lõpp-punktides ja neid teenindatakse iseseisvalt. Kui ühes voos toimub paketi kadu, ei mõjuta see teisi.
Daniel Steinbergi illustratsioon
Teiseks, krüpteerimist ei rakendata enam eraldi tasemel, vaid see on protokollis. See võimaldab teil luua ühenduse ja vahetada avalikke võtmeid ühe käepigistusega, samuti võimaldab teil kasutada nutikat 0-RTT käepigistuse mehhanismi ja vältida käepigistuse viivitusi. Lisaks on nüüd võimalik üksikuid andmepakette krüpteerida. See võimaldab teil mitte oodata voost andmete vastuvõtmise lõpetamist, vaid saab vastuvõetud paketid iseseisvalt dekrüpteerida. See töörežiim oli TCP-s üldiselt võimatu, kuna TLS ja TCP töötasid üksteisest sõltumatult ning TLS ei saanud teada, millisteks tükkideks TCP andmed tükeldatakse. Ja seetõttu ei saanud ta oma segmente ette valmistada nii, et need sobiksid üks ühele TCP segmentidesse ja neid saaks iseseisvalt dekrüpteerida. Kõik need täiustused võimaldavad QUIC-il vähendada latentsusaega võrreldes TCP-ga.
Kolmandaks võimaldab valguse voogesituse kontseptsioon eraldada ühendus kliendi IP-aadressist. See on oluline näiteks siis, kui klient lülitub ühelt Wi-Fi pääsupunktilt teisele, muutes oma IP-d. Sellisel juhul toimub TCP kasutamisel pikk protsess, mille käigus olemasolevad TCP-ühendused aeguvad ja luuakse uued ühendused uuest IP-st. QUIC-i puhul jätkab klient lihtsalt pakettide saatmist serverisse uuelt IP-lt vana voo ID-ga. Sest Voo ID on nüüd kordumatu ja seda ei kasutata uuesti; server mõistab, et klient on IP-d muutnud, saadab kadunud paketid uuesti ja jätkab sidet uuel aadressil.
Neljandaks, QUIC rakendatakse rakenduse, mitte operatsioonisüsteemi tasemel. See ühest küljest võimaldab teil kiiresti protokollis muudatusi teha, kuna Värskenduse saamiseks peate lihtsalt teeki värskendama, mitte ootama uut OS-i versiooni. Teisest küljest toob see kaasa protsessoritarbimise tugeva kasvu.
Ja lõpuks pealkirjad. Päise tihendamine on üks asjadest, mis QUICi ja gQUICi vahel erinevad. Ma ei näe mõtet sellele palju aega pühendada, ütlen lihtsalt, et standardiseerimiseks esitatud versioonis tehti päise tihendamine võimalikult sarnaseks HTTP/2 päise tihendamisega. Saate rohkem lugeda .
Kui palju kiirem see on?
See on raske küsimus. Fakt on see, et kuni meil pole standardit, pole midagi erilist mõõta. Võib-olla ainus statistika, mis meil on, on Google'i statistika, mis on gQUIC-i kasutanud alates 2013. aastast ja 2016. aastast. et umbes 90% Chrome'i brauserist nende serveritesse suunatavast liiklusest kasutab nüüd QUIC-i. Samas esitluses teatavad nad, et gQUIC-i kaudu laaditakse lehti umbes 5% kiiremini ja video voogesituses esineb TCP-ga võrreldes 30% vähem kokutamist.
2017. aastal avaldas Arash Molavi Kakhki juhitud teadlaste rühm gQUICi jõudluse uurimiseks võrreldes TCP-ga.
Uuring paljastas mitmeid gQUIC-i nõrkusi, nagu ebastabiilsus võrgupakettide segamisel, ahnus (ebaõiglus) kanali ribalaiuse suhtes ja väikeste (kuni 10 kb) objektide aeglasem edastamine. Viimast saab aga kompenseerida 0-RTT abil. Kõigil muudel uuritud juhtudel näitas gQUIC kiiruse suurenemist võrreldes TCP-ga. Siin on raske rääkida konkreetsetest numbritest. Parem lugeda või .
Siinkohal tuleb öelda, et need andmed puudutavad konkreetselt gQUIC-i ja need ei ole arendatava standardi jaoks olulised. Mis saab QUIC-iga: see on endiselt saladus, kuid on lootust, et gQUIC-is tuvastatud nõrkusi võetakse arvesse ja need parandatakse.
Natuke tulevikku: kuidas on lood HTTP/3-ga?
Kuid siin on kõik kristallselge: API ei muutu kuidagi. Kõik jääb täpselt samaks nagu HTTP/2-s. Noh, kui API jääb samaks, tuleb HTTP/3-le üleminek lahendada, kasutades taustaprogrammi teegi värsket versiooni, mis toetab QUIC-transporti. Tõsi, peate mõnda aega kasutama HTTP vanade versioonide tagavara, kuna Internet ei ole praegu täielikuks UDP-le üleminekuks valmis.
Kes juba toetab
siin on olemasolevad QUIC-i juurutused. Vaatamata standardi puudumisele pole nimekiri halb.
Tootmisväljaandes ei toeta praegu ükski brauser QUIC-i. Hiljuti oli teave selle kohta, et HTTP/3 tugi on Chrome'is kaasas, kuid seni ainult Canary.
Taustaprogrammidest toetab ainult HTTP/3 и , kuid siiski eksperimentaalne. NGINX 2019. aasta kevade lõpus , et nad alustasid tööd HTTP/3 toega, kuid pole seda veel lõpetanud.
Millised on probleemid?
Sina ja mina elame pärismaailmas, kus ükski suur tehnoloogia ei jõua massideni ilma vastupanuta, ja QUIC pole erand.
Kõige tähtsam on see, et peate brauserile kuidagi selgitama, et "https://" ei ole enam tõsiasi, et see viib TCP-porti 443. TCP-d ei pruugi üldse olla. Selleks kasutatakse Alt-Svc päist. See võimaldab teil brauserile öelda, et see veebisait on saadaval ka sellise ja sellise protokolliga sellisel ja sellisel aadressil. Teoreetiliselt peaks see toimima nagu võlu, kuid praktikas puutume kokku tõsiasjaga, et DDoS-i rünnakute vältimiseks võib näiteks tulemüüril UDP ära keelata.
Kuid isegi kui UDP pole keelatud, võib klient olla NAT-ruuteri taga, mis on konfigureeritud hoidma IP-aadressi järgi TCP-seanssi ja kuna kasutame UDP-d, millel pole riistvaraseanssi, NAT ei hoia ühendust ja QUIC-seanssi .
Kõik need probleemid on tingitud asjaolust, et UDP-d ei olnud varem Interneti-sisu edastamiseks kasutatud ja riistvaratootjad ei osanud ette näha, et see kunagi juhtub. Samamoodi ei saa administraatorid veel päriselt aru, kuidas oma võrke QUICi töötamiseks õigesti konfigureerida. See olukord muutub järk-järgult ja igal juhul võtavad sellised muudatused vähem aega kui uue transpordikihi protokolli rakendamine.
Lisaks, nagu juba kirjeldatud, suurendab QUIC oluliselt CPU kasutust. Daniel Stenberg protsessori kasv kuni kolm korda.
Millal HTTP/3 saabub?
Standard 2020. aasta maiks, kuid arvestades, et 2019. aasta juuliks kavandatud dokumendid on hetkel pooleli, võib öelda, et kuupäev lükkub suure tõenäosusega edasi.
Noh, Google on oma gQUIC-i juurutamist kasutanud alates 2013. aastast. Kui vaatate Google'i otsingumootorile saadetud HTTP-päringut, näete järgmist:
Järeldused
QUIC näeb nüüd välja üsna töötlemata, kuid paljutõotava tehnoloogiana. Arvestades, et viimase 20 aasta jooksul on kõik transpordikihi protokollide optimeerimised puudutanud peamiselt TCP-d, siis enamikul juhtudel parima jõudlusega QUIC näeb juba väga hea välja.
Siiski on veel lahendamata probleeme, millega tuleb lähiaastatel tegeleda. Protsess võib viibida, kuna tegemist on riistvaraga, mida kellelegi ei meeldi uuendada, kuid sellegipoolest tunduvad kõik probleemid üsna lahendatavad ning varem või hiljem on meil kõigil HTTP/3.
Tulevik on kohe nurga taga!
Allikas: www.habr.com