20 urte baino gehiago daramatzagu web orriak ikusten HTTP protokoloa erabiliz. Erabiltzaile gehienek ez dute pentsatzen zer den eta nola funtzionatzen duen. Beste batzuek badakite nonbait HTTPren azpian TLS dagoela, eta horren azpian TCP dagoela, zeinaren azpian IP, eta abar. Eta beste batzuek - herejeek - uste dute TCP iraganeko gauza dela; zerbait azkarragoa, fidagarriagoa eta seguruagoa nahi dute. Baina protokolo ideal berri bat asmatzeko saiakeretan, 80ko hamarkadako teknologiara itzuli dira eta horren gainean beren mundu ausart berri bat eraikitzen saiatzen ari dira.
Historia pixka bat: HTTP/1.1
1997an, testu informazioa trukatzeko HTTP protokoloak 1.1 bertsioak bere RFC propioa eskuratu zuen. Garai hartan, nabigatzaileek hainbat urtez erabiltzen zuten protokoloa, eta estandar berriak beste hamabost iraun zuen. Protokoloak eskaera-erantzunaren printzipioan soilik funtzionatzen zuen eta testu-informazioa transmititzeko zen nagusiki.
HTTP TCP protokoloaren gainean exekutatzeko diseinatu zen, paketeak helmugara modu fidagarrian bidaltzen direla ziurtatuz. TCP-k amaierako puntuen arteko konexio fidagarria ezarri eta mantenduz eta trafikoa segmentuetan zatituz funtzionatzen du. Segmentuek bere serie-zenbakia eta checksum propioa dute. Bat-batean segmenturen bat iristen ez bada edo checksum oker batekin iristen bada, orduan transmisioa geldituko da galdutako segmentua leheneratu arte.
HTTP/1.0-n, TCP konexioa itxi egin zen eskaera bakoitzaren ondoren. Hau izugarri xahutu zen, zeren... TCP konexioa ezartzea (3-Way-Handshake) prozesu motela da. HTTP/1.1-ek bizirik mantentzeko mekanismoa sartu zuen, hainbat eskaera egiteko konexio bat berrerabiltzeko aukera ematen duena. Hala ere, erraz bihur daitekeenez botila-lepo bat, HTTP/1.1-en hainbat inplementazioek ostalari berera TCP konexio anitz irekitzea ahalbidetzen dute. Adibidez, Chrome-k eta Firefox-en azken bertsioek sei konexio onartzen dituzte.
Enkriptatzea beste protokolo batzuen esku ere utzi behar zen, eta, horretarako, TLS protokoloa erabili zen TCPren gainean, eta horrek datuak fidagarriki babesten zituen, baina konexioa ezartzeko behar den denbora are gehiago handitzen zuen. Ondorioz, eskua emateko prozesua honela hasi zen:
Cloudflare ilustrazioa
Beraz, HTTP/1.1-ek hainbat arazo izan zituen:
- Konexio motela konfiguratzea.
- Datuak testu moduan transmititzen dira, hau da, irudiak, bideoak eta testua ez den beste informazio batzuen transmisioa ez da eraginkorra.
- TCP konexio bat erabiltzen da eskaera baterako, hau da, beste eskaerak beste konexio bat aurkitu behar dute edo uneko eskaerak askatu arte itxaron behar dute.
- Tira eredua bakarrik onartzen da. Zerbitzari-push-ari buruzko estandarrean ez dago ezer.
- Izenburuak testuan transmititzen dira.
Zerbitzari-push WebSocket protokoloa erabiliz gutxienez inplementatzen bada, gainerako arazoei errotikoki aurre egin behar zaie.
Modernitate pixka bat: HTTP/2
2012an, Google SPDY (ahoskatzen den "bizkorra") protokoloa lantzen hasi zen. Protokoloa HTTP/1.1-en arazo nagusiak konpontzeko diseinatu zen eta, aldi berean, atzerako bateragarritasuna mantendu behar zuen. 2015ean, IETF lan-taldeak SPDY protokoloan oinarritutako HTTP/2 zehaztapena aurkeztu zuen. Hona hemen HTTP/2-n desberdintasunak:
- Serializazio bitarra.
- Hainbat HTTP eskaera multiplexatzea TCP konexio bakarrean.
- Zerbitzaria kutxatik atera (WebSocket gabe).
Protokoloa aurrerapauso handia izan zen. Berak biziki eta ez du TCP konexio anitz sortzea eskatzen: ostalari bati egindako eskaera guztiak bakarrean multiplexatzen dira. Hau da, konexio batean hainbat korronte deiturikoak daude, eta bakoitzak bere ID propioa du. Bonua zerbitzari-push kutxa bat da.
Hala ere, multiplexatzeak beste arazo nagusi bat dakar. Imajinatu zerbitzari batera 5 eskaera asinkronoki exekutatzen ari garela. HTTP/2 erabiltzean, eskaera horiek guztiak TCP konexio berean egingo dira, hau da, edozein eskaeraren segmenturen bat galtzen bada edo gaizki jasotzen bada, eskaera eta erantzun guztien transmisioa geldituko da galdutako segmentua den arte. zaharberritu. Jakina, zenbat eta okerragoa izan konexioaren kalitatea, orduan eta motelago funtzionatzen du HTTP/2. , galdutako paketeek pakete guztien % 2 hartzen duten baldintzetan, arakatzailean HTTP/1.1 HTTP/2 baino hobeto funtzionatzen du, bat baino 6 konexio irekitzen dituelako.
Arazo honi "head-of-line blocking" deitzen zaio eta, tamalez, ezin da konpondu TCP erabiltzean.
Daniel Steinbergen ilustrazioa
Ondorioz, HTTP/2 estandarraren garatzaileek lan bikaina egin zuten eta OSI ereduaren aplikazio geruzan egin zitekeen ia guztia egin zuten. Garraio geruzara jaitsi eta garraio protokolo berri bat asmatzeko garaia da.
Protokolo berri bat behar dugu: UDP vs TCP
Azkar argi geratu zen garraio-geruzen protokolo guztiz berria ezartzea ezinezko zeregina dela gaur egungo errealitateetan. Kontua da hardware edo erdiko kutxak (bideratzaileak, suebakiak, NAT zerbitzariak...) garraio-geruza ezagutzen dutela, eta zerbait berria irakastea oso lan zaila da. Horrez gain, garraio-protokoloen euskarria sistema eragileen nukleoan sartuta dago, eta nukleoak ere ez daude oso prest aldatzeko.
Eta hemen norberak eskuak bota eta esan lezake "Guk, noski, HTTP/3 berri bat asmatuko dugu hobespenekin eta kortesanekin, baina 10-15 urte beharko dira inplementatzeko (denbora honen ondoren hardware gehiena egongo da). ordezkatu),β baina ez dago beste bat. Aukera nabaria da UDP protokoloa erabiltzea. Bai, bai, laurogeita hamarreko hamarkadaren amaieran eta XNUMXko hamarkadaren hasieran LAN bidez fitxategiak botatzeko erabili genuen protokolo bera. Gaur egungo hardware ia guztiek funtziona dezakete.
Zein abantaila ditu UDPk TCPren aldean? Lehenik eta behin, ez dugu hardwareak ezagutzen duen garraio-geruzako saiorik. Horri esker, amaierako puntuei buruzko saioa guk geuk zehaztu eta bertan gatazkak konpontzeko. Hau da, ez gaude saio batera edo hainbatetara mugatzen (TCPn bezala), baizik eta behar adina sor ditzakegu. Bigarrenik, datuen transmisioa UDP bidez TCP bidez baino azkarragoa da. Horrela, teorian, HTTP/2n lortutako egungo abiadura-sabaia hautsi dezakegu.
Hala ere, UDP-k ez du datu-transmisio fidagarria bermatzen. Izan ere, paketeak bidaltzen ari gara, beste muturrak jasoko dituelakoan. Ez al duzu jaso? Tira, zorterik ez... Helduentzako bideoak transmititzeko nahikoa izan zen, baina gauza serioagoetarako fidagarritasuna behar duzu, hau da, UDPren gainean beste zerbait bildu behar duzu.
HTTP/2rekin gertatzen den bezala, 2012an hasi ziren Googlen protokolo berri bat sortzeko lanak, hau da, SPDYren lanak hasi ziren garai berean. 2013an, Jim Roskind-ek publiko orokorrari aurkeztu zion , eta dagoeneko 2015ean Interneten Zirriborroa aurkeztu zen IETFn estandarizaziorako. Dagoeneko garai hartan, Roskind-ek Googlen garatutako protokoloa estandararekiko oso desberdina zen, eta, beraz, Google-ren bertsioa gQUIC deitzen hasi zen.
Zer da QUIC
Lehenik eta behin, esan bezala, hau UDPren bilgarri bat da. QUIC konexio bat UDPren gainean igotzen da, eta bertan, HTTP/2-ren analogia eginez, hainbat korronte egon daitezke. Korronte hauek amaierako puntuetan soilik daude eta modu independentean hornitzen dira. Korronte batean pakete-galera gertatzen bada, ez du besteei eragingo.
Daniel Steinbergen ilustrazioa
Bigarrenik, enkriptatzea ez da maila bereizi batean ezartzen, protokoloan sartzen da baizik. Honi esker, konexio bat ezarri eta gako publikoak trukatu ditzakezu esku-eskubide bakarrean, eta, gainera, 0-RTT esku-emate mekanismo adimentsua erabiltzeko eta esku-eskubideen atzerapenak guztiz saihesteko aukera ematen du. Gainera, orain posible da datu-pakete indibidualak enkriptatzea. Horrek aukera ematen du korrontetik datuak jasotzen amaitzen ez den arte itxaron, baina jasotako paketeak modu independentean deszifratzeko. Eragiketa modu hau, oro har, TCPn ezinezkoa zen, zeren TLS eta TCP elkarrengandik independentean funtzionatzen zuten, eta TLS-k ezin zuen jakin zer zatitan zatituko ziren TCP datuak. Horregatik, ezin izan zituen bere segmentuak prestatu TCP segmentuetan bat-batean sartzeko eta modu independentean deszifratu ahal izateko. Hobekuntza horiei guztiei esker, QUIC-k latentzia murrizten du TCPrekin alderatuta.
Hirugarrenik, argiaren streaming kontzeptuak bezeroaren IP helbidetik konexioa desakoplatzea ahalbidetzen du. Hau garrantzitsua da, adibidez, bezero bat Wi-Fi sarbide-puntu batetik bestera aldatzen denean, bere IPa aldatuz. Kasu honetan, TCP erabiltzean, prozesu luze bat gertatzen da lehendik dauden TCP konexioek denbora igarotzen duten bitartean eta IP berri batetik konexio berriak sortzen diren. QUIC-en kasuan, bezeroak zerbitzariari paketeak bidaltzen jarraitzen du IP berri batetik korronte ID zaharrarekin. Zeren Korrontearen IDa bakarra da orain eta ez da berrerabiltzen; zerbitzariak ulertzen du bezeroak IP aldatu duela, galdutako paketeak berriro bidaltzen ditu eta helbide berrian jarraitzen du komunikazioa.
Laugarrenik, QUIC aplikazio mailan ezartzen da, ez sistema eragilearen mailan. Honek, alde batetik, protokoloan aldaketak azkar egiteko aukera ematen du, zeren Eguneratze bat lortzeko, liburutegia eguneratu besterik ez duzu behar, OS bertsio berri baten zain egon beharrean. Bestalde, horrek prozesadorearen kontsumoa nabarmen handitzea dakar.
Eta azkenik, titularrak. Goiburuko konpresioa QUIC eta gQUIC artean desberdintzen den gauzetako bat da. Ez dut zentzurik ikusten honi denbora asko eskaintzeari, esango dut estandarizaziorako bidalitako bertsioan goiburuko konpresioa HTTP/2-n goiburuko konpresioaren antzekoena egin zela. Gehiago irakur dezakezu .
Zenbat azkarragoa da?
Galdera zaila da. Kontua da estandar bat izan arte ez dagoela ezer berezirik neurtzeko. Agian, ditugun estatistika bakarrak Googleren estatistikak dira, 2013tik eta 2016tik gQUIC erabiltzen ari baita. Chrome arakatzailetik zerbitzarietara doan trafikoaren %90 inguruk QUIC erabiltzen duela orain. Aurkezpen berean, orriak gQUIC-en bidez % 5 inguru azkarrago kargatzen direla eta bideoaren streaming-ean % 30 gutxiago kargatzen direla jakinarazi dute TCPrekin alderatuta.
2017an, Arash Molavi Kakhkik zuzendutako ikertzaile talde batek argitaratu zuen gQUIC-en errendimendua TCPrekin alderatuta aztertzeko.
Azterketak gQUIC-en hainbat ahulezia agerian utzi ditu, hala nola, sare-paketeen nahasketaren ezegonkortasuna, banda-zabalera bideratzeko zaletasuna (bidegabetasuna) eta objektu txikien (10 kb-raino) transferentzia motelagoa. Azken hori, ordea, 0-RTT erabiliz konpentsatu daiteke. Aztertutako beste kasu guztietan, gQUIC-ek abiadura handitu egin zuen TCPrekin alderatuta. Zaila da hemen zenbaki zehatzei buruz hitz egitea. Hobe irakurri edo .
Hemen esan beharra dago datu hauek gQUIC-i buruzkoak direla, eta ez dela garrantzitsua garatzen ari den estandararentzat. Zer gertatuko den QUIC-ekin: sekretua da oraindik, baina gQUIC-en identifikatutako ahuleziak kontuan hartu eta zuzenduko diren itxaropena dago.
Etorkizuneko pixka bat: zer gertatzen da HTTP/3?
Baina hemen dena argi dago: APIa ez da inola ere aldatuko. Dena HTTP/2-n zegoen berdin jarraituko du. Beno, APIak berdin jarraitzen badu, HTTP/3rako trantsizioa konpondu beharko da liburutegiaren bertsio berri bat erabiliz QUIC garraioa onartzen duen backend-ean. Egia da, HTTP-ren bertsio zaharretako babesa denbora luzez mantendu beharko duzu, zeren Une honetan Internet ez dago prest UDPra erabateko trantsiziorako.
Dagoeneko onartzen duena
Hemen dauden QUIC inplementazioak. Estandarrik ez dagoen arren, zerrenda ez da txarra.
Une honetan, ez da arakatzailerik onartzen QUIC ekoizpen-oharra. Duela gutxi, HTTP/3rako euskarria Chrome-n sartzen zela jakin zen, baina orain arte Kanarietan bakarrik.
Backendetatik, HTTP/3-k soilik onartzen du ΠΈ , baina oraindik esperimentala. NGINX 2019ko udaberri amaieran , HTTP/3 euskarria lantzen hasi zirela, baina oraindik ez dutela amaitu.
Zeintzuk dira arazoak?
Zu eta ni mundu errealean bizi gara, non teknologia handirik masetara iristen ez den erresistentzia topatu gabe, eta QUIC ez da salbuespena.
Garrantzitsuena da nolabait arakatzaileari azaldu behar diozula "https://" jada ez dela TCP 443 atakara eramaten duela. Baliteke TCPrik ez egotea. Alt-Svc goiburua erabiltzen da horretarako. Nabigatzaileari esateko aukera ematen dio webgune hau halako eta halako protokolo batean ere eskuragarri dagoela halako helbide batean. Teorian, honek ederki funtzionatu beharko luke, baina praktikan UDP, adibidez, suebaki batean debekatu daitekeela topo egingo dugu DDoS erasoak saihesteko.
Baina UDP debekatuta ez badago ere, bezeroa IP helbidearen arabera TCP saio bat edukitzeko konfiguratuta dagoen NAT bideratzaile baten atzean egon daiteke, eta, hardware saiorik ez duen UDP erabiltzen dugu, NATek ez du konexioa mantenduko eta QUIC saio bat .
Arazo horiek guztiak Interneteko edukiak transmititzeko UDP erabili ez izanaren ondoriozkoak dira, eta hardware-ekoizleek ezin zuten aurreikusi hori inoiz gertatuko zenik. Modu berean, administratzaileek oraindik ez dute ulertzen nola konfiguratu behar diren sareak QUIC-ek funtziona dezan. Egoera hori pixkanaka aldatzen joango da, eta, nolanahi ere, aldaketa horiek garraio-geruzako protokolo berri bat ezartzeak baino denbora gutxiago beharko dute.
Gainera, lehen deskribatu bezala, QUIC-ek PUZaren erabilera asko handitzen du. Daniel Stenberg prozesadorearen hazkundea hiru aldiz arte.
Noiz iritsiko da HTTP/3?
Standard 2020ko maiatzerako, baina 2019ko uztailerako aurreikusitako dokumentuak momentuz amaitu gabe jarraitzen dutela kontuan hartuta, data ziurrenik atzeratuko dela esan dezakegu.
Bada, Google-k gQUIC inplementazioa erabiltzen du 2013az geroztik. Google bilatzaileari bidaltzen zaion HTTP eskaerari begiratzen badiozu, hau ikusiko duzu:
Findings
QUIC orain teknologia nahiko gordina dirudi, baina oso itxaropentsua. Azken 20 urteotan, garraio-geruzen protokoloen optimizazio guztiek TCP, QUIC, kasu gehienetan errendimendu onena duena, oso itxura ona duela kontuan hartuta.
Dena den, badaude oraindik konpondu gabeko arazoak, datozen urteetan landu beharko direnak. Prozesua atzeratu egin daiteke hardwarea dagoelako, inori ez zaiola eguneratzea gustatzen, baina, hala ere, arazo guztiak nahiko konpongarriak dirudite, eta lehenago edo beranduago denok izango dugu HTTP/3.
Etorkizuna izkinan dago!
Iturria: www.habr.com