Foar mear dan 20 jier hawwe wy websiden besjoen mei it HTTP-protokol. De measte brûkers tinke net iens oer wat it is en hoe't it wurket. Oaren witte dat der earne ûnder HTTP TLS is, en ûnder dat is TCP, wêrûnder IP, ensfh. En noch oaren - ketters - leauwe dat TCP in ding fan it ferline is, se wolle wat flugger, betrouberder en feiliger. Mar yn har besykjen om in nij ideaal protokol út te finen, binne se weromkommen nei de technology fan 'e jierren '80 en besykje har dappere nije wrâld derop te bouwen.
In bytsje skiednis: HTTP/1.1
Yn 1997 krige it protokol foar útwikseling fan tekstynformaasje HTTP ferzje 1.1 syn eigen RFC. Yn dy tiid waard it protokol ferskate jierren brûkt troch browsers, en de nije standert duorre noch fyftjin. It protokol wurke allinnich op it prinsipe fan fersyk-antwurd en wie benammen bedoeld foar de oerdracht fan tekstynformaasje.
HTTP is ûntworpen om boppe op it TCP-protokol te rinnen, en soarget derfoar dat pakketten betrouber wurde levere oan har bestimming. TCP wurket troch it fêstigjen en ûnderhâlden fan in betroubere ferbining tusken einpunten en it brekken fan ferkear yn segminten. Segminten hawwe har eigen serial number en kontrôlesum. As ynienen ien fan 'e segminten net oankomt of komt mei in ferkearde kontrôlesum, dan sil de oerdracht stopje oant it ferlerne segmint is hersteld.
Yn HTTP/1.0 waard de TCP-ferbining nei elk fersyk sletten. Dit wie heul fergriemd, om't ... it oprjochtsjen fan in TCP-ferbining (3-Way-Handshake) is in stadich proses. HTTP/1.1 yntrodusearre it keep-alive-meganisme, wêrtroch jo ien ferbining opnij kinne brûke foar meardere oanfragen. Om't it lykwols maklik in knelpunt kin wurde, kinne ferskate ymplemintaasjes fan HTTP / 1.1 meardere TCP-ferbiningen iepenje foar deselde host. Bygelyks, Chrome en resinte ferzjes fan Firefox tastean maksimaal seis ferbinings.
Fersifering soe ek wurde oerlitten oan oare protokollen, en dêrfoar waard it TLS-protokol brûkt oer TCP, dy't de gegevens betrouber beskerme, mar de tiid dy't nedich is om in ferbining te meitsjen, fierder fergrutte. As resultaat begon it handshakeproses sa te sjen:
Cloudflare yllustraasje
Sa hie HTTP/1.1 in oantal problemen:
- Stadige ferbining opset.
- Gegevens wurde oerdroegen yn tekstfoarm, wat betsjut dat de oerdracht fan foto's, fideo's en oare net-tekstynformaasje net effektyf is.
- Ien TCP-ferbining wurdt brûkt foar ien fersyk, wat betsjut dat oare oanfragen of in oare ferbining fine moatte of wachtsje oant it hjoeddeistige fersyk it frijlit.
- Allinich it pull-model wurdt stipe. D'r is neat yn 'e standert oer server-push.
- Koppen wurde oerdroegen yn tekst.
As server-push op syn minst ymplementearre wurdt mei it WebSocket-protokol, dan moasten de oerbleaune problemen radikaler behannele wurde.
In bytsje moderniteit: HTTP/2
Yn 2012 begon Google te wurkjen oan it SPDY (útsprutsen "speedy") protokol. It protokol is ûntworpen om de haadproblemen fan HTTP/1.1 op te lossen en tagelyk soe efterútkompatibiliteit behâlde. Yn 2015 yntrodusearre de IETF-wurkgroep de HTTP/2-spesifikaasje basearre op it SPDY-protokol. Hjir binne de ferskillen yn HTTP/2:
- Binêre serialisaasje.
- Multiplexing meardere HTTP-oanfragen yn ien TCP-ferbining.
- Tsjinner-push út it fak (sûnder WebSocket).
It protokol wie in grutte stap foarút. Hy sterk en fereasket net it oanmeitsjen fan meardere TCP-ferbiningen: alle fersiken nei ien host wurde multiplexed yn ien. Dat is, yn ien ferbining binne d'r ferskate saneamde streamen, dy't elk in eigen ID hawwe. De bonus is in doaze server-push.
Multiplexing liedt lykwols ta in oar wichtich probleem. Stel jo foar dat wy 5 fersiken asynchronysk útfiere nei ien tsjinner. By it brûken fan HTTP/2 sille al dizze oanfragen útfierd wurde binnen deselde TCP-ferbining, wat betsjut dat as ien fan 'e segminten fan in fersyk ferlern of ferkeard ûntfongen is, de oerdracht fan alle oanfragen en antwurden stopje oant it ferlerne segmint is restaurearre. Fansels, hoe slimmer de ferbiningskwaliteit, hoe stadiger HTTP/2 wurket. , yn betingsten dêr't ferlerne pakketten 2% fan alle pakketten rekkenje, docht HTTP / 1.1 yn 'e browser better as HTTP / 2 troch it feit dat it 6 ferbiningen iepenet ynstee fan ien.
Dit probleem hjit "head-of-line blocking" en, spitigernôch, is it net mooglik om it op te lossen by it brûken fan TCP.
Yllustraasje troch Daniel Steinberg
As gefolch hawwe de ûntwikkelders fan 'e HTTP/2-standert in geweldige baan dien en hast alles dien wurde koe by de applikaasjelaach fan it OSI-model. It is tiid om nei de transportlaach del te gean en in nij transportprotokol út te finen.
Wy hawwe in nij protokol nedich: UDP vs TCP
Hiel gau waard dúdlik dat it ymplementearjen fan in folslein nij protokol foar transportlaach in ûnmooglike taak is yn de hjoeddeiske realiteiten. It feit is dat hardware of middendoazen (routers, firewalls, NAT-tsjinners ...) witte oer de ferfierslaach, en har wat nijs leare is in ekstreem drege taak. Dêrnjonken is stipe foar ferfierprotokollen yn 'e kernel fan bestjoeringssystemen ynboud, en kernels binne ek net heul ree om te feroarjen.
En hjir kin men de hannen opsmite en sizze "Wy sille fansels in nije HTTP/3 útfine mei foarkar en courtisanen, mar it sil 10-15 jier duorje om te ymplementearjen (nei sawat dizze tiid sil it measte fan 'e hardware wêze ferfongen), mar d'r is noch ien net sa De foar de hân lizzende opsje is it UDP-protokol te brûken. Ja, ja, itselde protokol dat wy brûkten om bestannen oer LAN te smiten yn 'e lette jierren njoggentich en begjin XNUMX's. Hast alle hjoeddeistige hardware kin dermei wurkje.
Wat binne de foardielen fan UDP boppe TCP? Alderearst hawwe wy gjin transportlaach sesje wêrfan de hardware wit. Hjirmei kinne wy sels de sesje op 'e einpunten bepale en dêr konflikten oplosse. Dat is, wy binne net beheind ta ien of meardere sesjes (lykas yn TCP), mar kinne safolle meitsje as wy nedich binne. Twad, gegevens oerdracht fia UDP is flugger dan fia TCP. Sa kinne wy yn teory troch it hjoeddeistige snelheidsplafond brekke dy't yn HTTP/2 berikt is.
UDP garandearret lykwols gjin betroubere gegevensoerdracht. Yn feite stjoere wy gewoan pakketten, yn 'e hoop dat it oare ein se sil ûntfange. Net krigen? No, gjin gelok ... Dit wie genôch om fideo's foar folwoeksenen te ferstjoeren, mar foar mear serieuze dingen hawwe jo betrouberens nedich, wat betsjut dat jo wat oars moatte wrapje boppe op UDP.
Lykas mei HTTP/2 begon it wurk oan it meitsjen fan in nij protokol by Google yn 2012, dat is sawat deselde tiid as it wurk oan SPDY begon. Yn 2013, Jim Roskind presintearre oan it algemien publyk , en al yn 2015 waard it Internet Draft ynfierd foar standerdisearring yn 'e IETF. Al op dat stuit, it protokol ûntwikkele troch Roskind by Google wie hiel oars as de standert, sadat de Google ferzje begûn te wurde neamd gQUIC.
Wat is QUIC
As earste, lykas al neamd, is dit in wrapper oer UDP. In QUIC-ferbining komt boppe op UDP, wêryn, nei analogy mei HTTP/2, ferskate streamen kinne bestean. Dizze streamen besteane allinich op 'e einpunten en wurde ûnôfhinklik betsjinne. As in pakketferlies foarkomt yn ien stream, sil it gjin ynfloed hawwe op oaren.
Yllustraasje troch Daniel Steinberg
Twad, fersifering wurdt net mear ymplementearre op in apart nivo, mar is opnommen yn it protokol. Hjirmei kinne jo in ferbining meitsje en iepenbiere kaaien útwikselje yn ien handshake, en kinne jo ek it tûke 0-RTT-handshake-meganisme brûke en handshake-fertragingen hielendal foarkomme. Derneist is it no mooglik om yndividuele gegevenspakketten te fersiferjen. Hjirmei kinne jo net wachtsje op it foltôgjen fan it ûntfangen fan gegevens fan 'e stream, mar om de ûntfongen pakketten selsstannich te ûntsiferjen. Dizze modus fan operaasje wie oer it algemien ûnmooglik yn TCP, omdat TLS en TCP wurken ûnôfhinklik fan inoar, en TLS koe net witte yn hokker stikken TCP gegevens wurde chopped. En dêrom koe hy syn segminten net tariede sadat se ien op ien passe yn TCP-segminten en selsstannich ûntsiferje kinne. Al dizze ferbetterings tastean QUIC te ferminderjen latency yn ferliking mei TCP.
Tredde, it konsept fan ljochtstreaming lit jo de ferbining loskeppelje fan it IP-adres fan 'e kliïnt. Dit is wichtich, bygelyks, as in klant oerstapt fan it iene Wi-Fi-tagongspunt nei it oare, en feroaret syn IP. Yn dit gefal, by it brûken fan TCP, bart in lang proses wêryn besteande TCP-ferbiningen time-out en nije ferbinings wurde makke fanút in nije IP. Yn it gefal fan QUIC giet de kliïnt gewoan troch mei it stjoeren fan pakketten nei de tsjinner fan in nije IP mei de âlde stream-ID. Omdat De stream-ID is no unyk en wurdt net opnij brûkt.
Fjirde wurdt QUIC ymplementearre op it tapassingsnivo, net op it bestjoeringssysteemnivo. Dit, oan 'e iene kant, kinne jo fluch meitsje feroarings oan it protokol, omdat Om in update te krijen, moatte jo gewoan de bibleteek bywurkje, ynstee fan wachtsje op in nije OS-ferzje. Oan 'e oare kant liedt dit ta in sterke tanimming fan prosessorferbrûk.
En as lêste, de krantekoppen. Koptekstkompresje is ien fan 'e dingen dy't ferskille tusken QUIC en gQUIC. Ik sjoch it punt net om dit in protte tiid te besteegjen, ik sil gewoan sizze dat yn 'e ferzje dy't foar standerdisearring yntsjinne is, header-kompresje sa ferlykber as mooglik makke waard oan header-kompresje yn HTTP / 2. Jo kinne mear lêze .
Hoefolle flugger is it?
It is in drege fraach. It feit is dat oant wy in standert hawwe, d'r neat spesjaal is te mjitten. Miskien binne de ienige statistiken dy't wy hawwe statistiken fan Google, dy't gQUIC sûnt 2013 en yn 2016 hat brûkt dat sawat 90% fan it ferkear dat nei har servers giet fan 'e Chrome-blêder no QUIC brûkt. Yn deselde presintaasje melde se dat siden sa'n 5% flugger laden fia gQUIC en d'r binne 30% minder stutters yn fideostreaming yn ferliking mei TCP.
Yn 2017 publisearre in groep ûndersikers ûnder lieding fan Arash Molavi Kakhki om de prestaasjes fan gQUIC te studearjen yn ferliking mei TCP.
De stúdzje die bliken ferskate swakkens fan gQUIC, lykas instabiliteit oan it mingen fan netwurk pakketten, gierigens (ûnrjochtlik) te kanaal bânbreedte en stadiger oerdracht fan lytse (oant 10 kb) objekten. Dat lêste kin lykwols kompensearre wurde troch 0-RTT te brûken. Yn alle oare ûndersochte gefallen toande gQUIC in ferheging fan snelheid yn ferliking mei TCP. It is lestich om hjir oer spesifike nûmers te praten. Better lêze of .
Hjir moat sein wurde dat dizze gegevens binne spesifyk oer gQUIC, en it is net relevant foar de standert wurdt ûntwikkele. Wat sil barre foar QUIC: it is noch in geheim, mar d'r is hope dat de swakkens identifisearre yn gQUIC wurde rekken holden en korrizjearre.
In bytsje fan 'e takomst: hoe sit it mei HTTP/3?
Mar hjir is alles kristal dúdlik: de API sil op gjin inkelde manier feroarje. Alles sil krekt itselde bliuwe as it wie yn HTTP/2. No, as de API itselde bliuwt, sil de oergong nei HTTP/3 oplost wurde moatte troch in frisse ferzje fan 'e bibleteek te brûken op' e efterkant dy't QUIC-ferfier stipet. Wier, jo moatte de fallback op âlde ferzjes fan HTTP noch in skoft hâlde, om't It ynternet is op it stuit net klear foar in folsleine oergong nei UDP.
Wa al stipet
hjir besteande QUIC ymplemintaasjes. Nettsjinsteande it ûntbrekken fan in standert, de list is net min.
Gjin browser stipet op it stuit QUIC yn in produksjeferzje. Koartlyn wie d'r ynformaasje dat stipe foar HTTP / 3 waard opnommen yn Chrome, mar oant no ta allinich yn Kanaryske.
Fan 'e backends stipet HTTP/3 allinich и , mar noch eksperiminteel. NGINX oan 'e ein fan maitiid 2019 , dat se begûn te wurkjen oan HTTP/3-stipe, mar hawwe it noch net klear.
Wat binne de problemen?
Jo en ik libje yn 'e echte wrâld, wêr't gjin grutte technology de massa's kin berikke sûnder ferset te treffen, en QUIC is gjin útsûndering.
It wichtichste is dat jo de browser op ien of oare manier moatte útlizze dat "https://" net langer in feit is dat it liedt ta TCP-poarte 443. D'r kin hielendal gjin TCP wêze. De Alt-Svc-header wurdt dêrfoar brûkt. Dêrmei kinne jo de browser fertelle dat dizze webside ek beskikber is op sa'n en sa'n protokol op sa'n en sa'n adres. Yn teory soe dit as in sjarme moatte wurkje, mar yn 'e praktyk komme wy it feit tsjin dat UDP bygelyks ferbean wurde kin op in firewall om DDoS-oanfallen te foarkommen.
Mar sels as UDP net ferbean is, kin de kliïnt efter in NAT-router sitte dy't konfigureare is om in TCP-sesje te hâlden troch IP-adres, en sûnt wy brûke UDP, dat hat gjin hardware sesje, NAT sil net hâld de ferbining, en in QUIC sesje .
Al dizze problemen binne te tankjen oan it feit dat UDP net earder waard brûkt om ynternetynhâld te ferstjoeren, en hardwarefabrikanten koene net foarsizze dat dit ea soe barre. Op deselde wize begripe behearders noch net echt hoe't se har netwurken goed ynstelle kinne foar QUIC om te wurkjen. Dizze situaasje sil stadichoan feroarje, en yn alle gefallen sille sokke feroaringen minder tiid duorje dan de ymplemintaasje fan in nij protokol foar transportlaach.
Derneist, lykas al beskreaun, fergruttet QUIC it CPU-gebrûk sterk. Daniel Stenberg prosessor groei oant trije kear.
Wannear sil HTTP/3 oankomme?
Standert troch maaie 2020, mar jûn dat dokuminten pland foar july 2019 op it stuit net foltôge bliuwe, kinne wy sizze dat de datum nei alle gedachten sil wurde skood.
No, Google hat syn gQUIC-ymplemintaasje sûnt 2013 brûkt. As jo sjogge nei it HTTP-fersyk dat wurdt stjoerd nei de Google-sykmasine, sille jo dit sjen:
befinings
QUIC liket no op in nochal rûge, mar heul belofte technology. Yn betinken nommen dat oer de ôfrûne 20 jier, alle optimalisaasjes fan ferfier laach protokollen hawwe besoarge benammen TCP, QUIC, dy't yn de measte gefallen hat de bêste prestaasje, sjocht der al ekstreem goed.
Der binne lykwols noch net oploste problemen dy't de kommende jierren oanpakt wurde moatte. It proses kin fertrage wurde troch it feit dat d'r hardware belutsen is, dy't gjinien graach bywurkje, mar lykwols sjogge alle problemen frij oplosber, en ier of letter sille wy allegear HTTP/3 hawwe.
De takomst is krekt om 'e hoeke!
Boarne: www.habr.com
