ProHoster > Blogs > Administrācija > HTTP/3: izrāviens un drosmīga jauna pasaule

HTTP/3: izrāviens un drosmīga jauna pasaule

Vairāk nekā 20 gadus mēs skatāmies tÄ«mekļa lapas, izmantojot HTTP protokolu. Lielākā daļa lietotāju pat nedomā par to, kas tas ir un kā tas darbojas. Citi zina, ka kaut kur zem HTTP ir TLS, un zem tā ir TCP, zem kura ir IP utt. Un vēl citi - Ä·eceri - uzskata, ka TCP ir pagātne, viņi vēlas kaut ko ātrāku, uzticamāku un droŔāku. Taču savos mēģinājumos izgudrot jaunu ideālu protokolu viņi ir atgriezuÅ”ies pie 80. gadu tehnoloÄ£ijām un mēģina uz tās veidot savu drosmÄ«go jauno pasauli.
HTTP/3: izrāviens un drosmīga jauna pasaule

Nedaudz vēstures: HTTP/1.1

1997. gadā teksta informācijas apmaiņas protokols HTTP versija 1.1 ieguva savu RFC. Tolaik protokolu pārlūkprogrammas izmantoja vairākus gadus, un jaunais standarts ilga vēl piecpadsmit. Protokols darbojās tikai pēc pieprasījuma-atbildes principa un bija paredzēts galvenokārt teksta informācijas pārraidei.

HTTP tika izstrādāts, lai darbotos papildus TCP protokolam, nodroÅ”inot, ka paketes tiek uzticami piegādātas galamērÄ·im. TCP darbojas, izveidojot un uzturot uzticamu savienojumu starp galapunktiem un sadalot trafiku segmentos. Segmentiem ir savs sērijas numurs un kontrolsumma. Ja pēkŔņi kāds no segmentiem neierodas vai ierodas ar nepareizu kontrolsummu, pārraide apstāsies, lÄ«dz tiks atjaunots zaudētais segments.

HTTP/1.0 TCP savienojums tika aizvērts pēc katra pieprasÄ«juma. Tas bija ārkārtÄ«gi izŔķērdÄ«gi, jo... TCP savienojuma izveide (3-Way-Handshake) ir lēns process. HTTP/1.1 ieviesa saglabāŔanas mehānismu, kas ļauj atkārtoti izmantot vienu savienojumu vairākiem pieprasÄ«jumiem. Tomēr, tā kā tas var viegli kļūt par vājo vietu, dažādas HTTP/1.1 ievieÅ”anas ļauj vienam un tam paÅ”am resursdatoram atvērt vairākus TCP savienojumus. Piemēram, pārlÅ«kprogramma Chrome un jaunākās Firefox versijas ļauj izveidot lÄ«dz seÅ”iem savienojumiem.
HTTP/3: izrāviens un drosmīga jauna pasaule
Å ifrÄ“Å”ana bija jāatstāj arÄ« citiem protokoliem, un Å”im nolÅ«kam tika izmantots TLS protokols, izmantojot TCP, kas droÅ”i aizsargāja datus, bet vēl vairāk palielināja savienojuma izveidoÅ”anai nepiecieÅ”amo laiku. Rezultātā rokasspiediena process sāka izskatÄ«ties Ŕādi:
HTTP/3: izrāviens un drosmīga jauna pasaule
Cloudflare ilustrācija

Tādējādi HTTP/1.1 bija vairākas problēmas:

  • Lēna savienojuma iestatÄ«Å”ana.
  • Dati tiek pārsÅ«tÄ«ti teksta formā, kas nozÄ«mē, ka attēlu, video un citas informācijas, kas nav teksts, pārraide ir neefektÄ«va.
  • Vienam pieprasÄ«jumam tiek izmantots viens TCP savienojums, kas nozÄ«mē, ka citiem pieprasÄ«jumiem ir jāatrod cits savienojums vai jāgaida, lÄ«dz paÅ”reizējais pieprasÄ«jums to atbrÄ«vo.
  • Tiek atbalstÄ«ts tikai vilkÅ”anas modelis. Standartā nekas nav minēts par servera nosÅ«tÄ«Å”anu.
  • Virsraksti tiek pārsÅ«tÄ«ti tekstā.

Ja server-push ir vismaz ieviests, izmantojot WebSocket protokolu, tad atlikuŔās problēmas bija jārisina radikālāk.

Nedaudz modernitātes: HTTP/2

2012. gadā Google sāka strādāt pie SPDY (izrunā "ātrais") protokola. Protokols tika izstrādāts, lai atrisinātu galvenās HTTP/1.1 problēmas, un tajā paŔā laikā tam bija jāsaglabā atpakaļejoÅ”a savietojamÄ«ba. 2015. gadā IETF darba grupa ieviesa HTTP/2 specifikāciju, kuras pamatā ir SPDY protokols. Å eit ir atŔķirÄ«bas HTTP/2:

  • Binārā serializācija.
  • Vairāku HTTP pieprasÄ«jumu multipleksÄ“Å”ana vienā TCP savienojumā.
  • Servera izstumÅ”ana no kastes (bez WebSocket).

Protokols bija liels solis uz priekÅ”u. ViņŔ spēcÄ«gi ātrumā pārspēj pirmo versiju un nav nepiecieÅ”ams izveidot vairākus TCP savienojumus: visi pieprasÄ«jumi vienam resursdatoram tiek multipleksēti vienā. Tas ir, vienā savienojumā ir vairākas tā sauktās straumes, kurām katrai ir savs ID. Bonuss ir kastē ievietots servera piespieÅ”ana.

Tomēr multipleksÄ“Å”ana rada vēl vienu bÅ«tisku problēmu. Iedomājieties, ka mēs asinhroni izpildām 5 pieprasÄ«jumus vienam serverim. Izmantojot HTTP/2, visi Å”ie pieprasÄ«jumi tiks izpildÄ«ti viena un tā paÅ”a TCP savienojuma ietvaros, kas nozÄ«mē, ka, ja kāds no jebkura pieprasÄ«juma segmentiem tiek pazaudēts vai saņemts nepareizi, visu pieprasÄ«jumu un atbilžu pārraide tiks pārtraukta, lÄ«dz tiek zaudēts segments. atjaunota. AcÄ«mredzot, jo sliktāka savienojuma kvalitāte, jo lēnāk darbojas HTTP/2. Pēc Daniela Stenberga teiktā, apstākļos, kad zaudētās paketes veido 2% no visām paketēm, HTTP/1.1 pārlÅ«kprogrammā darbojas labāk nekā HTTP/2, jo tas atver 6 savienojumus, nevis vienu.

Å o problēmu sauc par ā€œgalvas bloÄ·Ä“Å”anuā€, un diemžēl to nav iespējams atrisināt, izmantojot TCP.
HTTP/3: izrāviens un drosmīga jauna pasaule
Daniela Šteinberga ilustrācija

Rezultātā HTTP/2 standarta izstrādātāji paveica lielisku darbu un izdarīja gandrīz visu, ko varēja paveikt OSI modeļa lietojumprogrammu slānī. Ir pienācis laiks doties uz transporta slāni un izgudrot jaunu transporta protokolu.

Mums ir nepiecieŔams jauns protokols: UDP vs TCP

Diezgan ātri kļuva skaidrs, ka pilnÄ«gi jauna transporta slāņa protokola ievieÅ”ana mÅ«sdienu realitātē ir neiespējams uzdevums. Fakts ir tāds, ka aparatÅ«ra vai vidējās kastes (marÅ”rutētāji, ugunsmÅ«ri, NAT serveri...) zina par transporta slāni, un iemācÄ«t viņiem kaut ko jaunu ir ārkārtÄ«gi sarežģīts uzdevums. Turklāt transportÄ“Å”anas protokolu atbalsts ir iebÅ«vēts operētājsistēmu kodolā, un arÄ« kodoli nav Ä«paÅ”i gatavi mainÄ«ties.

Un te varētu atmest rokas un teikt ā€œMēs, protams, izgudrosim jaunu HTTP/3 ar priekÅ”roka un kurtizānēm, bet tā ievieÅ”ana prasÄ«s 10-15 gadus (apmēram pēc Ŕī laika lielākā daļa aparatÅ«ras bÅ«s aizstāts), bet ir vēl viens ne tik AcÄ«mredzama iespēja ir izmantot UDP protokolu. Jā, jā, tas pats protokols, ar kuru mēs deviņdesmito gadu beigās un XNUMX. gadu sākumā izmantojām failu pārsÅ«tÄ«Å”anai pa LAN. Ar to var strādāt gandrÄ«z visa mÅ«sdienu aparatÅ«ra.

Kādas ir UDP priekÅ”rocÄ«bas salÄ«dzinājumā ar TCP? Pirmkārt, mums nav transporta slāņa sesijas, par kuru aparatÅ«ra zinātu. Tas ļauj mums paÅ”iem noteikt sesiju galapunktos un atrisināt konfliktus. Tas ir, mēs neaprobežojamies ar vienu vai vairākām sesijām (kā TCP), bet varam izveidot tik daudz no tām, cik mums nepiecieÅ”ams. Otrkārt, datu pārraide caur UDP ir ātrāka nekā caur TCP. Tādējādi teorētiski mēs varam pārvarēt paÅ”reizējos HTTP/2 ātruma griestus.

Tomēr UDP negarantē uzticamu datu pārraidi. PatiesÄ«bā mēs vienkārÅ”i sÅ«tām paciņas, cerot, ka otrs gals tās saņems. Vai neesat saņēmis? Nu, neveicās... Ar to pietika, lai pārraidÄ«tu video pieauguÅ”ajiem, bet nopietnākām lietām ir nepiecieÅ”ama uzticamÄ«ba, kas nozÄ«mē, ka UDP ir jāietina kaut kas cits.

Tāpat kā ar HTTP/2, darbs pie jauna protokola izveides uzņēmumā Google sākās 2012. gadā, tas ir, aptuveni tajā paŔā laikā, kad sākās darbs pie SPDY. 2013. gadā Džims Roskinds iepazÄ«stināja plaŔāku sabiedrÄ«bu QUIC (ātrie UDP interneta savienojumi) protokols, un jau 2015. gadā Interneta projekts tika ieviests standartizācijai IETF. Jau tajā laikā Roskinda Google izstrādātais protokols ļoti atŔķīrās no standarta, tāpēc Google versiju sāka saukt par gQUIC.

Kas ir QUIC

Pirmkārt, kā jau minēts, tas ir UDP iesaiņojums. QUIC savienojums tiek izveidots virs UDP, kurā, pēc analoÄ£ijas ar HTTP/2, var pastāvēt vairākas straumes. Å Ä«s straumes pastāv tikai galapunktos un tiek apkalpotas neatkarÄ«gi. Ja pakeÅ”u zudums notiek vienā straumē, tas neietekmēs citus.
HTTP/3: izrāviens un drosmīga jauna pasaule
Daniela Šteinberga ilustrācija

Otrkārt, Å”ifrÄ“Å”ana vairs netiek ieviesta atseviŔķā lÄ«menÄ«, bet ir iekļauta protokolā. Tas ļauj izveidot savienojumu un apmainÄ«ties ar publiskajām atslēgām vienā rokasspiedienā, kā arÄ« ļauj izmantot gudro 0-RTT rokasspiediena mehānismu un izvairÄ«ties no rokasspiediena aizkaves. Turklāt tagad ir iespējams Å”ifrēt atseviŔķas datu paketes. Tas ļauj negaidÄ«t datu saņemÅ”anas no straumes pabeigÅ”anu, bet gan patstāvÄ«gi atÅ”ifrēt saņemtās paketes. Å is darbÄ«bas režīms TCP parasti nebija iespējams, jo TLS un TCP darbojās neatkarÄ«gi viens no otra, un TLS nevarēja zināt, kādos gabalos TCP dati tiks sasmalcināti. Un tāpēc viņŔ nevarēja sagatavot savus segmentus tā, lai tie ietilptu TCP segmentos viens pret vienu un varētu tikt atÅ”ifrēti neatkarÄ«gi. Visi Å”ie uzlabojumi ļauj QUIC samazināt latentumu salÄ«dzinājumā ar TCP.
HTTP/3: izrāviens un drosmīga jauna pasaule
TreÅ”kārt, gaismas straumÄ“Å”anas koncepcija ļauj atsaistÄ«t savienojumu no klienta IP adreses. Tas ir svarÄ«gi, piemēram, kad klients pārslēdzas no viena Wi-Fi piekļuves punkta uz citu, mainot savu IP. Å ajā gadÄ«jumā, izmantojot TCP, notiek ilgstoÅ”s process, kura laikā esoÅ”ajiem TCP savienojumiem tiek veikta taimauts un tiek izveidoti jauni savienojumi no jauna IP. QUIC gadÄ«jumā klients vienkārÅ”i turpina sÅ«tÄ«t paketes uz serveri no jauna IP ar veco straumes ID. Jo Straumes ID tagad ir unikāls un netiek izmantots atkārtoti; serveris saprot, ka klients ir mainÄ«jis IP, atkārtoti nosÅ«ta pazaudētās paketes un turpina saziņu uz jauno adresi.

Ceturtkārt, QUIC tiek ieviests lietojumprogrammas, nevis operētājsistēmas lÄ«menÄ«. Tas, no vienas puses, ļauj ātri veikt izmaiņas protokolā, jo Lai saņemtu atjauninājumu, jums vienkārÅ”i jāatjaunina bibliotēka, nevis jāgaida jauna OS versija. No otras puses, tas izraisa ievērojamu procesora patēriņa pieaugumu.

Un visbeidzot virsraksti. Galvenes saspieÅ”ana ir viena no lietām, kas atŔķiras starp QUIC un gQUIC. Es neredzu jēgu tam veltÄ«t daudz laika, teikÅ”u tikai to, ka standartizācijai iesniegtajā versijā galvenes saspieÅ”ana tika padarÄ«ta pēc iespējas lÄ«dzÄ«ga galvenes saspieÅ”anai HTTP/2. JÅ«s varat lasÄ«t vairāk Å”eit.

Cik tas ir ātrāk?

Tas ir grÅ«ts jautājums. Fakts ir tāds, ka, kamēr mums nav standarta, nekas Ä«paÅ”s nav jāmēra. VarbÅ«t vienÄ«gā statistika, kas mums ir pieejama, ir Google statistika, kas gQUIC izmanto kopÅ” 2013. gada un 2016. gada. ziņoja IETFka aptuveni 90% datplÅ«smas, kas tiek novirzÄ«ta uz viņu serveriem no pārlÅ«ka Chrome, tagad izmanto QUIC. Tajā paŔā prezentācijā viņi ziņo, ka lapas tiek ielādētas par aptuveni 5% ātrāk, izmantojot gQUIC, un video straumÄ“Å”anā ir par 30% mazāk stostÄ«Å”anās, salÄ«dzinot ar TCP.

2017. gadā publicēja pētnieku grupa Arash Molavi Kakhki vadībā lielisks darbs lai izpētītu gQUIC veiktspēju salīdzinājumā ar TCP.
PētÄ«jums atklāja vairākus gQUIC trÅ«kumus, piemēram, nestabilitāti tÄ«kla pakeÅ”u sajaukÅ”anā, kanāla joslas platuma alkatÄ«bu (netaisnÄ«gumu) un lēnāku mazu (lÄ«dz 10 kb) objektu pārsÅ«tÄ«Å”anu. Tomēr pēdējo var kompensēt, izmantojot 0-RTT. Visos citos pētÄ«tajos gadÄ«jumos gQUIC uzrādÄ«ja ātruma palielināŔanos salÄ«dzinājumā ar TCP. Å eit ir grÅ«ti runāt par konkrētiem skaitļiem. Labāk lasi pats pētÄ«jums vai Ä«ss ieraksts.

Te gan jāsaka, ka Å”ie dati ir tieÅ”i par gQUIC, un tie nav aktuāli izstrādātajam standartam. Kas notiks ar QUIC: tas joprojām ir noslēpums, taču ir cerÄ«ba, ka gQUIC konstatētās nepilnÄ«bas tiks ņemtas vērā un novērstas.

Mazliet par nākotni: kā ar HTTP/3?

Bet Å”eit viss ir pilnÄ«gi skaidrs: API nekādā veidā nemainÄ«sies. Viss paliks tieÅ”i tāds pats kā HTTP/2. Ja API paliek nemainÄ«ga, pāreja uz HTTP/3 bÅ«s jāatrisina, izmantojot jaunu bibliotēkas versiju aizmugursistēmā, kas atbalsta QUIC transportu. Tiesa, jums bÅ«s jāsaglabā atkāpÅ”anās uz vecajām HTTP versijām diezgan ilgu laiku, jo Internets paÅ”laik nav gatavs pilnÄ«gai pārejai uz UDP.

Kas jau atbalsta

Ŕeit ir saraksts esoŔās QUIC implementācijas. Neskatoties uz standarta trūkumu, saraksts nav slikts.

PaŔlaik neviena pārlūkprogramma neatbalsta QUIC ražoŔanas laidienā. Nesen parādījās informācija, ka HTTP/3 atbalsts ir iekļauts pārlūkā Chrome, bet līdz Ŕim tikai Kanāriju salās.

No aizmugursistēmām atbalsta tikai HTTP/3 Tējas kārbiņa Šø Cloudflare, bet joprojām ir eksperimentāls. NGINX 2019. gada pavasara beigās paziņoja, ka viņi sāka strādāt pie HTTP/3 atbalsta, taču to vēl nav pabeiguÅ”i.

Kādas ir problēmas?

Jūs un es dzīvojam reālajā pasaulē, kur neviena liela tehnoloģija nevar sasniegt masu, nesastopoties ar pretestību, un QUIC nav izņēmums.

VissvarÄ«gākais ir tas, ka jums kaut kā jāpaskaidro pārlÅ«kprogrammai, ka ā€œhttps://ā€ vairs nav fakts, ka tas ved uz TCP portu 443. TCP var nebÅ«t vispār. Å im nolÅ«kam tiek izmantota Alt-Svc galvene. Tas ļauj jums pateikt pārlÅ«kprogrammai, ka Ŕī vietne ir pieejama arÄ« ar tādu un tādu protokolu tādā un tādā adresē. Teorētiski tam vajadzētu darboties kā Å”armam, taču praksē mēs saskarsimies ar faktu, ka UDP var, piemēram, aizliegt ugunsmÅ«rÄ«, lai izvairÄ«tos no DDoS uzbrukumiem.

Bet pat tad, ja UDP nav aizliegts, klients var atrasties aiz NAT marÅ”rutētāja, kas ir konfigurēts TCP sesijas uzturÄ“Å”anai pēc IP adreses, un tā kā mēs izmantojam UDP, kam nav aparatÅ«ras sesijas, NAT neuzturēs savienojumu un QUIC sesiju pastāvÄ«gi pārtrauks.

Visas Ŕīs problēmas ir saistÄ«tas ar to, ka UDP iepriekÅ” netika izmantots interneta satura pārsÅ«tÄ«Å”anai, un aparatÅ«ras ražotāji nevarēja paredzēt, ka tas kādreiz notiks. Tādā paŔā veidā administratori vēl Ä«sti nesaprot, kā pareizi konfigurēt savus tÄ«klus, lai QUIC darbotos. Å Ä« situācija pakāpeniski mainÄ«sies, un jebkurā gadÄ«jumā Ŕādas izmaiņas prasÄ«s mazāk laika nekā jauna transporta slāņa protokola ievieÅ”ana.

Turklāt, kā jau aprakstÄ«ts, QUIC ievērojami palielina CPU izmantoÅ”anu. Daniels Stenbergs novērtēts procesora pieaugums lÄ«dz trÄ«s reizēm.

Kad ieradīsies HTTP/3?

Standarts gribu pieņemt lÄ«dz 2020. gada maijam, taču, ņemot vērā to, ka 2019. gada jÅ«lijā plānotie dokumenti Å”obrÄ«d paliek nepabeigti, varam teikt, ka datums, visticamāk, tiks pārcelts.

Google ir izmantojis savu gQUIC ievieÅ”anu kopÅ” 2013. gada. Ja skatāties uz HTTP pieprasÄ«jumu, kas tiek nosÅ«tÄ«ts Google meklētājprogrammai, jÅ«s redzēsit Å”o:
HTTP/3: izrāviens un drosmīga jauna pasaule

Atzinumi

QUIC tagad izskatās pēc diezgan neapstrādātas, bet ļoti daudzsoloÅ”as tehnoloÄ£ijas. Ņemot vērā, ka pēdējo 20 gadu laikā visas transporta slāņa protokolu optimizācijas galvenokārt ir saistÄ«tas ar TCP, QUIC, kam vairumā gadÄ«jumu ir vislabākā veiktspēja, jau izskatās ārkārtÄ«gi labi.

Tomēr joprojām ir neatrisinātas problēmas, kas būs jārisina tuvāko gadu laikā. Process var aizkavēties tāpēc, ka ir iesaistīta aparatūra, kuru nevienam nepatīk atjaunināt, taču, neskatoties uz to, visas problēmas izskatās diezgan atrisināmas, un agri vai vēlu mums visiem būs HTTP/3.

Nākotne ir tepat aiz stūra!

Avots: www.habr.com

Pievieno komentāru