Izstrādātāji nesen kas ir aiz muguras Google Chrome tīmekļa pārlūks izlaida ziņas par atbalsta pievienošanu HTTP / 3 protokolam Chrome Canary eksperimentālajām versijām, kas ievieš spraudni, lai iespējotu HTTP, izmantojot QUIC.
Pats protokols QUIC pārlūkprogrammai tika pievienots pirms pieciem gadiem un kopš tā laika to izmanto, lai optimizētu darbu ar Google pakalpojumiem. Tajā pašā laikā pārlūkā Chrome izmantotā Google QUIC versija dažās detaļās atšķīrās no IETF specifikāciju versijas, taču tagad ieviešana ir sinhronizēta.
Google Chrome Canary tikko kļuva par pirmo (pieejamo) pārlūku, kas integrēja (ļoti) eksperimentālu #ĀTRI un HTTP / 3 atbalsts!
Pievienojiet karodziņus "–enable-quic –quic-version = h3-23", un jums vajadzētu redzēt, ka devtools parādās "http / 2 + quic / 99", kas patiesībā ir maskēts http3! pic.twitter.com/5Fhui46h3x
- Robins Markss (@programmingart) Septembris 19, 2019
Ir svarīgi to izcelt Google ir izstrādājis QUIC (Ātrie UDP interneta savienojumi) kopš 2013. gada kā alternatīva TCP + TLS pakotnei tīmeklim, kas atrisina problēmas ar ilgu TCP savienojumu iestatīšanu un sarunu laiku un novērš pakešu zaudēšanas aizkavēšanos datu pārsūtīšanas laikā.
QUIC ir UDP protokola papildinājums, kas atbalsta vairāku savienojumu multipleksēšanu un nodrošina TLS / SSL līdzvērtīgas šifrēšanas metodes.
Attiecīgais protokols jau ir iebūvēts Google serveru infrastruktūrā, ir daļa no Chrome, ir paredzēts iekļaušanai Firefox un tiek aktīvi izmantots klientu pieprasījumu apkalpošanai Google serveros.
Starp galvenajām QUIC īpašībām, kas izceļas, ir:
- Augsta drošība, līdzīga TLS (faktiski QUIC nodrošina iespēju izmantot TLS, izmantojot UDP)
- Plūsmas integritātes kontrole, kas novērš pakešu zaudēšanu
- Iespēja uzreiz izveidot savienojumu (0-RTT, aptuveni 75% gadījumu datus var pārsūtīt uzreiz pēc savienojuma iestatīšanas paketes nosūtīšanas) un nodrošināt minimālu aizkavēšanos starp pieprasījuma nosūtīšanu un atbildes saņemšanu (RTT, turp un atpakaļ)
- Ja atkārtoti pārsūtot pakešu, netiek izmantots viens un tas pats kārtas numurs, kas novērš neskaidrību saņemto pakešu noteikšanā un novērš noildzi
- Paketes zaudēšana ietekmē tikai ar to saistītās straumes piegādi un nepārtrauc datu piegādi straumēs, kas tiek pārraidītas paralēli pa pašreizējo savienojumu.
- Kļūdu labošanas rīki, kas samazina aizkavēšanos zaudēto pakešu atkārtotas pārsūtīšanas dēļ.
- Īpašu pakešu līmeņa kļūdu labošanas kodu izmantošana, lai mazinātu situācijas, kad nepieciešama atkārtota zaudēto pakešdatu pārraide.
- Bloku kriptogrāfijas robežas ir saskaņotas ar QUIC pakešu robežām, samazinot pakešu zuduma ietekmi uz šo pakešu satura dekodēšanu
- Nav problēmu ar TCP rindas bloķēšanu
- Atbalsts savienojuma identifikatoram, kas samazina laiku, lai izveidotu atkārtotu savienojumu mobilajiem klientiem
- Spēja savienot uzlabotus mehānismus, lai kontrolētu savienojuma pārslodzi
Tiek arī uzsvērts, ka tajā tiek izmantota joslas platuma prognozēšanas metode katrā virzienā nodrošināt optimālu pakešu piegādes intensitāti, neļaujot tai sasniegt pārslodzes stāvokli, kurā tiek novērots pakešu zudums;
Kā arī ievērojams sniegums un veiktspējas pieaugums, salīdzinot ar TCP. Tādiem video pakalpojumiem kā YouTube QUIC parādīja 30% samazinājumu atkārtotas buferizācijas darbībās, skatoties videoklipus.
HTTP / 3 protokols standartizē QUIC izmantošanu kā HTTP / 2 transportu. Lai iespējotu HTTP / 3 un 23 IETF specifikāciju projekta QUIC versiju, pārlūks Chrome ir jādarbina ar opcijām “–enable-quic –quic-version = h3-23” un pēc tam, kad tiek atvērta quic testa vietne .rocks: 4433 tīkla pārbaudes režīms izstrādātāja rīkos, HTTP / 3 darbība tiks parādīta kā "http / 2 + quic / 99".
Salīdzinot ar pakešu, kuru zaudēja paralēli HTTP savienojumi, tiks apturēts tikai viens no daudzajiem savienojumiem, kas nozīmē, ka QUIC var atbalstīt piegādi ārpus pasūtījuma, lai zaudētajai paketei būtu mazāka ietekme.
Si jūs vēlaties uzzināt vairāk par to par to jūs varat konsultēties šo saiti.