Arendajad hiljuti kes on taga Google Chrome'i veebibrauserist avaldas uudise HTTP / 3 protokolli toe lisamise kohta Chrome Canary eksperimentaalsete versioonide juurde, mis rakendab pistikprogrammi, et lubada HTTP QUIC-i kaudu.
QUIC-protokoll ise lisati brauserisse viis aastat tagasi ja sellest ajast alates on seda kasutatud Google'i teenustega töö optimeerimiseks. Samal ajal erines Chrome'is kasutatav Google'i QUIC-versioon mõningate üksikasjade osas IETF-i spetsifikatsioonide versioonist, kuid nüüd on rakendused sünkroonis.
Google Chrome Canary sai just esimeseks (saadaval) brauseriks, mis integreeris (väga) eksperimentaalse #KIIR ja HTTP / 3 tugi!
Lisage lipud "–enable-quic –quic-version = h3-23" ja peaksite nägema, et devtools ilmub "http / 2 + quic / 99", mis on tegelikult varjatud http3! pic.twitter.com/5Fhui46h3x
- Robin Marx (@programmingart) September 19, 2019
Oluline on seda esile tõsta Google on välja töötanud QUIC (Kiire UDP Interneti-ühendus) alates 2013. aastast alternatiivina veebipaketile TCP + TLS, mis lahendab TCP-ühenduste pika konfigureerimise ja läbirääkimiste aja probleemid ning välistab viivitused pakettide kadumisel andmeedastuse ajal.
QUIC on UDP-protokolli täiendus, mis toetab mitme ühenduse multipleksimist ja pakub TLS / SSL-iga samaväärseid krüpteerimismeetodeid.
Kõnealune protokoll on juba sisse ehitatud Google'i serverite infrastruktuuri, see on osa Chrome'ist, plaanitakse lisada Firefoxi ja seda kasutatakse aktiivselt klientide päringute esitamiseks Google'i serverites.
QUICi peamised omadused, mis silma paistavad, on:
- Kõrge turvalisus, sarnaselt TLS-ile (tegelikult pakub QUIC võimalust kasutada TLS-i UDP kaudu)
- Voo terviklikkuse kontroll, mis hoiab ära pakettide kadumise
- Võimalus luua ühendus koheselt (0-RTT, umbes 75% juhtudest saab andmeid edastada kohe pärast ühenduse seadistuspaketi saatmist) ja tagada minimaalsed viivitused päringu saatmise ja vastuse saamise vahel (RTT, edasi-tagasi aeg)
- Paketi uuesti edastamisel sama järjekorranumbri mittekasutamine, mis väldib vastuvõetavate pakettide määramisel ebaselgust ja välistab ajalõpu
- Paketi kaotamine mõjutab ainult sellega seotud voo edastamist ja ei peata andmete edastamist paralleelselt praeguse ühenduse kaudu edastatud voogudes
- Vigade parandamise tööriistad, mis minimeerivad kaotatud pakettide uuesti edastamisest tingitud viivitusi.
- Spetsiaalsete paketitaseme tõrkeotsingu koodide kasutamine olukordade vähendamiseks, mis nõuavad kadunud pakettandmete uuesti edastamist.
- Plokkide krüptograafilised piirid on joondatud QUIC-pakettide piiridega, vähendades pakettide kadumise mõju järgmiste pakettide sisu dekodeerimisele
- TCP järjekorra blokeerimisega pole probleeme
- Toetus ühenduse identifikaatorile, mis vähendab mobiiliklientide jaoks ühenduse loomise aega
- Võimalus ühendada täiustatud mehhanisme ühenduse ülekoormuse juhtimiseks
Samuti tuuakse esile, et selles kasutatakse ribalaiuse prognoosimise tehnikat igas suunas tagada pakettide edastamise optimaalne intensiivsus, takistades selle jõudmist ülekoormatusseisundisse, milles täheldatakse pakettide kadu;
Sama hästi kui märkimisväärne jõudlus ja jõudluse kasv TCP-ga võrreldes. Selliste videoteenuste nagu YouTube puhul näitas QUIC videote vaatamisel 30% vähem puhverdamistoiminguid.
HTTP / 3 protokoll standardiseerib QUIC-i kasutamise HTTP / 2 transpordiks. HTTP / 3 ja 23 eelnõu IETF-i spetsifikatsioonide QUIC-versiooni lubamiseks tuleb Chrome käivitada valikutega „–enable-quic –quic-version = h3-23” ja siis, kui quik-testsait avaneb .rocks: 4433 arendaja tööriistade võrgukontrolli režiimis kuvatakse HTTP / 3 tegevus kui "http / 2 + quic / 99".
Paralleelsete HTTP-ühenduste tõttu kaotatud paketiga võrreldes peatatakse ainult üks paljudest ühendustest, mis tähendab, et QUIC saab toetada tellimusevälist kohaletoimetamist, nii et kaotatud paketil on vähem mõju.
Si soovite selle kohta rohkem teada saada selle kohta saate nõu pidada järgmine link.