Daugiau nei 20 metų tinklalapius žiūrime naudodami HTTP protokolą. Daugelis vartotojų net nesusimąsto, kas tai yra ir kaip tai veikia. Kiti žino, kad kažkur po HTTP yra TLS, o po juo yra TCP, po kuriuo IP ir t.t. O dar kiti – eretikai – tiki, kad TCP yra praeitis, jie nori kažko greitesnio, patikimesnio ir saugesnio. Tačiau bandydami išrasti naują idealų protokolą, jie grįžo prie 80-ųjų technologijų ir bando ant jų sukurti savo drąsų naują pasaulį.
Šiek tiek istorijos: HTTP/1.1
1997 m. teksto informacijos mainų protokolas HTTP versija 1.1 įgijo savo RFC. Tuo metu protokolą naršyklės naudojo keletą metų, o naujasis standartas galiojo dar penkiolika. Protokolas veikė tik prašymo-atsakymo principu ir pirmiausia buvo skirtas tekstinei informacijai perduoti.
HTTP buvo sukurtas veikti kartu su TCP protokolu, užtikrinant, kad paketai būtų patikimai pristatyti į paskirties vietą. TCP veikia nustatydama ir palaikydama patikimą ryšį tarp galinių taškų ir suskirstydama srautą į segmentus. Segmentai turi savo serijos numerį ir kontrolinę sumą. Jei staiga vienas iš segmentų neatvyksta arba atvyksta su neteisinga kontroline suma, perdavimas sustos, kol bus atkurtas prarastas segmentas.
HTTP/1.0 TCP ryšys buvo uždarytas po kiekvienos užklausos. Tai buvo labai švaistoma, nes... TCP ryšio užmezgimas (3 krypčių rankos paspaudimas) yra lėtas procesas. HTTP/1.1 pristatė gyvybės išlaikymo mechanizmą, kuris leidžia pakartotinai naudoti vieną ryšį kelioms užklausoms. Tačiau kadangi tai gali lengvai tapti kliūtimi, įvairūs HTTP/1.1 diegimai leidžia atidaryti kelis TCP ryšius su tuo pačiu kompiuteriu. Pavyzdžiui, „Chrome“ ir naujausios „Firefox“ versijos leidžia prisijungti iki šešių.
Šifravimas taip pat turėjo būti paliktas kitiems protokolams, o tam buvo naudojamas TLS protokolas per TCP, kuris patikimai apsaugojo duomenis, tačiau dar labiau padidino ryšio užmezgimo laiką. Dėl to rankos paspaudimo procesas pradėjo atrodyti taip:
Cloudflare iliustracija
Taigi HTTP/1.1 turėjo daug problemų:
- Lėtas ryšio nustatymas.
- Duomenys perduodami tekstiniu pavidalu, o tai reiškia, kad nuotraukų, vaizdo įrašų ir kitos netekstinės informacijos perdavimas yra neefektyvus.
- Vienai užklausai naudojamas vienas TCP ryšys, o tai reiškia, kad kitos užklausos turi arba rasti kitą ryšį, arba palaukti, kol dabartinė užklausa jį atleis.
- Palaikomas tik traukimo modelis. Standarte nieko nėra apie serverio stūmimą.
- Antraštės perduodamos tekstu.
Jei serverio stūmimas bent jau įgyvendintas naudojant WebSocket protokolą, likusias problemas reikėjo spręsti radikaliau.
Šiek tiek modernumo: HTTP/2
2012 m. „Google“ pradėjo dirbti su SPDY (tariama „greitas“) protokolu. Protokolas buvo skirtas pagrindinėms HTTP/1.1 problemoms išspręsti ir tuo pačiu turėjo išlaikyti atgalinį suderinamumą. 2015 metais IETF darbo grupė pristatė HTTP/2 specifikaciją, pagrįstą SPDY protokolu. Štai HTTP/2 skirtumai:
- Dvejetainis serializavimas.
- Kelių HTTP užklausų sutankinimas į vieną TCP ryšį.
- Serverio išstūmimas iš dėžutės (be „WebSocket“).
Protokolas buvo didelis žingsnis į priekį. Jis labai ir nereikalauja sukurti kelių TCP jungčių: visos užklausos vienam pagrindiniam kompiuteriui yra multipleksuojamos į vieną. Tai yra, viename jungtyje yra keli vadinamieji srautai, kurių kiekvienas turi savo ID. Premija yra dėžutės serverio paspaudimas.
Tačiau multipleksavimas sukelia dar vieną svarbią problemą. Įsivaizduokite, kad mes asinchroniškai vykdome 5 užklausas vienam serveriui. Naudojant HTTP/2, visos šios užklausos bus vykdomos per tą patį TCP ryšį, o tai reiškia, kad jei kuris nors užklausos segmentas bus prarastas arba gautas neteisingai, visų užklausų ir atsakymų perdavimas bus sustabdytas, kol bus prarastas segmentas. atkurta. Akivaizdu, kad kuo prastesnė ryšio kokybė, tuo lėčiau veikia HTTP/2. , kai prarasti paketai sudaro 2% visų paketų, HTTP/1.1 naršyklėje veikia geriau nei HTTP/2 dėl to, kad atidaro 6 ryšius, o ne vieną.
Ši problema vadinama „head-of-line blokavimu“ ir, deja, jos neįmanoma išspręsti naudojant TCP.
Danielio Steinbergo iliustracija
Dėl to HTTP/2 standarto kūrėjai atliko puikų darbą ir padarė beveik viską, ką buvo galima padaryti OSI modelio taikomajame lygmenyje. Atėjo laikas pereiti į transporto sluoksnį ir išrasti naują transportavimo protokolą.
Mums reikia naujo protokolo: UDP vs TCP
Gana greitai tapo aišku, kad visiškai naujo transporto sluoksnio protokolo įdiegimas šiandieninėje realybėje yra neįmanomas uždavinys. Faktas yra tas, kad techninė arba vidurinės dėžutės (maršrutizatoriai, ugniasienės, NAT serveriai...) žino apie transporto sluoksnį, o išmokyti juos ko nors naujo yra nepaprastai sudėtinga užduotis. Be to, transportavimo protokolų palaikymas yra prijungtas prie operacinių sistemų branduolio, o branduoliai taip pat nelabai noriai keičiasi.
Ir čia būtų galima numoti ranka ir pasakyti: „Mes, žinoma, sugalvosime naują HTTP/3 su pirmenybe ir kurtizanėmis, bet jį įgyvendinti prireiks 10-15 metų (maždaug po tiek laiko bus didžioji dalis techninės įrangos pakeistas), bet yra dar vienas ne toks Akivaizdi galimybė yra naudoti UDP protokolą. Taip, taip, tas pats protokolas, kurį mes naudojome failams per LAN devintojo dešimtmečio pabaigoje ir XNUMX-ųjų pradžioje. Su juo gali dirbti beveik visa šiuolaikinė aparatinė įranga.
Kokie UDP pranašumai prieš TCP? Visų pirma, mes neturime transporto sluoksnio seanso, apie kurį aparatinė įranga žinotų. Tai leidžia mums patiems nustatyti galutinių taškų seansą ir ten išspręsti konfliktus. Tai yra, mes neapsiribojame viena ar keliomis sesijomis (kaip TCP), bet galime sukurti tiek jų, kiek mums reikia. Antra, duomenų perdavimas per UDP yra greitesnis nei per TCP. Taigi teoriškai galime peržengti dabartines greičio lubas, pasiekiamas HTTP/2.
Tačiau UDP negarantuoja patikimo duomenų perdavimo. Tiesą sakant, mes tiesiog siunčiame paketus, tikėdamiesi, kad kitas galas juos gaus. Ar negavote? Na, nesiseka... Perduoti vaizdo įrašus suaugusiems to užteko, bet rimtesniems dalykams reikia patikimumo, vadinasi, ant UDP reikia vynioti dar ką nors.
Kaip ir HTTP/2 atveju, naujo protokolo kūrimo darbai „Google“ prasidėjo 2012 m., ty maždaug tuo pačiu metu, kai prasidėjo darbas su SPDY. 2013 metais Jimas Roskindas pristatė plačiajai visuomenei , o jau 2015 metais Interneto juodraštis buvo pristatytas standartizavimui IETF. Jau tuo metu Roskindo „Google“ sukurtas protokolas labai skyrėsi nuo standartinio, todėl „Google“ versija pradėta vadinti gQUIC.
Kas yra QUIC
Pirma, kaip jau minėta, tai yra UDP paketas. QUIC ryšys kyla ant UDP, kuriame, analogiškai su HTTP/2, gali būti keli srautai. Šie srautai egzistuoja tik galutiniuose taškuose ir aptarnaujami atskirai. Jei paketas prarandamas viename sraute, tai neturės įtakos kitiems.
Danielio Steinbergo iliustracija
Antra, šifravimas nebėra įgyvendinamas atskiru lygiu, bet yra įtrauktas į protokolą. Tai leidžia užmegzti ryšį ir apsikeisti viešaisiais raktais vienu rankos paspaudimu, taip pat leidžia naudoti išmanųjį 0-RTT rankos paspaudimo mechanizmą ir visiškai išvengti rankų paspaudimo delsimo. Be to, dabar galima užšifruoti atskirus duomenų paketus. Tai leidžia nelaukti duomenų gavimo iš srauto pabaigos, o savarankiškai iššifruoti gautus paketus. Šis veikimo būdas TCP paprastai buvo neįmanomas, nes TLS ir TCP veikė nepriklausomai vienas nuo kito, todėl TLS negalėjo žinoti, į kokias dalis TCP duomenys bus susmulkinti. Ir todėl jis negalėjo paruošti savo segmentų, kad jie tilptų į TCP segmentus vienas prieš vieną ir galėtų būti iššifruoti savarankiškai. Visi šie patobulinimai leidžia QUIC sumažinti delsą, palyginti su TCP.
Trečia, šviesos srauto koncepcija leidžia atsieti ryšį nuo kliento IP adreso. Tai svarbu, pavyzdžiui, kai klientas persijungia iš vieno „Wi-Fi“ prieigos taško į kitą, pakeisdamas savo IP. Šiuo atveju, naudojant TCP, vyksta ilgas procesas, kurio metu baigiasi esamų TCP ryšių laikas ir sukuriami nauji ryšiai iš naujo IP. QUIC atveju klientas tiesiog toliau siunčia paketus į serverį iš naujo IP su senu srauto ID. Nes Srauto ID dabar yra unikalus ir nenaudojamas pakartotinai. Serveris supranta, kad klientas pakeitė IP, iš naujo siunčia prarastus paketus ir tęsia ryšį nauju adresu.
Ketvirta, QUIC įgyvendinamas programos, o ne operacinės sistemos lygiu. Tai, viena vertus, leidžia greitai pakeisti protokolą, nes Norėdami gauti naujinimą, tereikia atnaujinti biblioteką, o ne laukti naujos OS versijos. Kita vertus, tai stipriai padidina procesoriaus suvartojimą.
Ir galiausiai, antraštės. Antraštės glaudinimas yra vienas iš dalykų, kurie skiriasi tarp QUIC ir gQUIC. Nematau prasmės tam skirti daug laiko, tik pasakysiu, kad standartizavimui pateiktoje versijoje antraščių glaudinimas buvo kuo panašesnis į antraštės glaudinimą HTTP/2. Galite paskaityti daugiau .
Kiek tai greičiau?
Tai sunkus klausimas. Faktas yra tas, kad kol neturime standarto, nėra nieko ypatingo matuoti. Galbūt vienintelė statistika, kurią turime, yra „Google“, kuri naudoja gQUIC nuo 2013 m. ir 2016 m. kad maždaug 90 % srauto, nukreipiančio į jų serverius iš „Chrome“ naršyklės, dabar naudoja QUIC. Tame pačiame pristatyme jie praneša, kad puslapiai įkeliami maždaug 5 % greičiau naudojant gQUIC ir 30 % mažiau trūkčiojančių vaizdo transliacijų, palyginti su TCP.
2017 metais paskelbė Arasho Molavi Kakhki vadovaujama mokslininkų grupė ištirti gQUIC veikimą, palyginti su TCP.
Tyrimas atskleidė keletą gQUIC trūkumų, tokių kaip tinklo paketų maišymo nestabilumas, godumas (nesąžiningumas) kanalo pralaidumui ir lėtesnis mažų (iki 10 kb) objektų perdavimas. Tačiau pastarąjį galima kompensuoti naudojant 0-RTT. Visais kitais tirtais atvejais gQUIC, palyginti su TCP, padidino greitį. Čia sunku kalbėti apie konkrečius skaičius. Geriau skaityk arba .
Čia reikia pasakyti, kad šie duomenys yra konkrečiai apie gQUIC ir nėra svarbūs kuriamam standartui. Kas atsitiks su QUIC: tai vis dar paslaptis, tačiau yra vilties, kad į gQUIC nustatytus trūkumus bus atsižvelgta ir jie bus ištaisyti.
Šiek tiek ateities: o kaip su HTTP/3?
Bet čia viskas aišku: API niekaip nepasikeis. Viskas išliks lygiai taip pat, kaip buvo HTTP/2. Na, jei API išliks ta pati, perėjimas prie HTTP/3 turės būti išspręstas naudojant naują bibliotekos versiją, kuri palaiko QUIC transportą. Tiesa, senų HTTP versijų atsarginę dalį turėsite išlaikyti gana ilgą laiką, nes Šiuo metu internetas nėra pasirengęs visiškai pereiti prie UDP.
Kas jau palaiko
Čia esamas QUIC diegimas. Nepaisant to, kad nėra standarto, sąrašas nėra blogas.
Nė viena naršyklė šiuo metu nepalaiko QUIC gamybinėje versijoje. Neseniai buvo informacijos, kad HTTP/3 palaikymas buvo įtrauktas į „Chrome“, bet iki šiol tik „Canary“.
Iš užpakalinių sistemų palaiko tik HTTP/3 и , bet vis dar eksperimentinis. NGINX 2019 m. pavasario pabaigoje , kad jie pradėjo dirbti su HTTP/3 palaikymu, bet to dar nebaigė.
Kokios problemos?
Jūs ir aš gyvename realiame pasaulyje, kur jokia didelė technologija negali pasiekti masių nesutikdama pasipriešinimo, o QUIC nėra išimtis.
Svarbiausia, kad jūs turite kažkaip paaiškinti naršyklei, kad „https://“ nebėra faktas, kad jis veda į 443 TCP prievadą. TCP gali iš viso nebūti. Tam naudojama „Alt-Svc“ antraštė. Tai leidžia jums pasakyti naršyklei, kad ši svetainė taip pat pasiekiama tokiu ir tokiu protokolu tokiu ir tokiu adresu. Teoriškai tai turėtų veikti kaip žavesys, tačiau praktiškai susidursime su tuo, kad, pavyzdžiui, UDP gali būti uždraustas ugniasienėje, kad būtų išvengta DDoS atakų.
Tačiau net jei UDP nėra uždraustas, klientas gali būti už NAT maršruto parinktuvo, sukonfigūruoto palaikyti TCP seansą pagal IP adresą, ir kadangi mes naudojame UDP, kuris neturi aparatinės įrangos seanso, NAT neužlaikys ryšio ir QUIC sesiją .
Visos šios problemos kyla dėl to, kad UDP anksčiau nebuvo naudojamas interneto turiniui perduoti, o techninės įrangos gamintojai negalėjo numatyti, kad tai kada nors įvyks. Taip pat administratoriai dar nelabai supranta, kaip tinkamai sukonfigūruoti savo tinklus, kad veiktų QUIC. Ši situacija palaipsniui keisis ir bet kokiu atveju tokie pakeitimai užtruks trumpiau nei naujo transporto lygmens protokolo įgyvendinimas.
Be to, kaip jau buvo aprašyta, QUIC labai padidina procesoriaus naudojimą. Danielius Stenbergas procesoriaus augimas iki trijų kartų.
Kada ateis HTTP/3?
Standartinė iki 2020 m. gegužės mėn., tačiau atsižvelgiant į tai, kad 2019 m. liepos mėn. numatyti dokumentai šiuo metu lieka nebaigti, galime teigti, kad data greičiausiai bus nukelta.
Na, „Google“ savo gQUIC diegimą naudoja nuo 2013 m. Jei pažvelgsite į HTTP užklausą, siunčiamą „Google“ paieškos varikliui, pamatysite tai:
išvados
QUIC dabar atrodo kaip gana neapdorota, bet labai perspektyvi technologija. Atsižvelgiant į tai, kad per pastaruosius 20 metų visi transporto sluoksnio protokolų optimizavimai daugiausia buvo susiję su TCP, QUIC, kuris daugeliu atvejų pasižymi geriausiu našumu, jau atrodo itin gerai.
Tačiau vis dar yra neišspręstų problemų, kurias teks spręsti per ateinančius kelerius metus. Procesas gali užtrukti dėl to, kad yra įtraukta techninė įranga, kurios niekas nemėgsta atnaujinti, tačiau nepaisant to, visos problemos atrodo gana išsprendžiamos ir anksčiau ar vėliau visi turėsime HTTP/3.
Ateitis jau visai šalia!
Šaltinis: www.habr.com
