Mozilla ir paziņojusi par savu nodomu sākt pakāpenisku HTTP/3 un QUIC ieviešanu ar Firefox 88 izlaišanu, kas plānota 19. aprīlī (sākotnēji bija paredzēts izlaist 20. aprīlī, bet, spriežot pēc grafika, tas tiks atlikts par vienu dienu). HTTP/3 atbalsts sākotnēji tiks iespējots tikai nelielai daļai lietotāju, un līdz maija beigām tas tiks ieviests visiem, izņemot negaidītas problēmas. Nakts veidojumos un beta versijās HTTP/3 pēc noklusējuma tika iespējots marta beigās.
Atgādināsim, ka HTTP/3 ieviešana pārlūkprogrammā Firefox balstās uz Mozilla izstrādāto neqo projektu, kas nodrošina klienta un servera ieviešanu QUIC protokolam. HTTP/3 un QUIC atbalsta komponenta kods ir rakstīts Rust. Lai kontrolētu, vai HTTP/3 ir iespējots, about:config nodrošina opciju “network.http.http3.enabled”. No klienta programmatūras pārlūkam Chrome un curl ir pievienots arī eksperimentāls HTTP/3 atbalsts, un serveriem tas ir pieejams nginx, kā arī nginx moduļa un testa servera veidā no Cloudflare. Vietnes pusē HTTP/3 atbalsts jau tiek nodrošināts Google un Facebook serveros.
HTTP/3 protokols joprojām ir specifikācijas projekta stadijā, un IETF to vēl nav pilnībā standartizējis. HTTP/3 ir nepieciešams klienta un servera atbalsts vienai un tai pašai QUIC uzmetuma standarta versijai un HTTP/3, kas norādīts Alt-Svc galvenē (Firefox atbalsta specifikācijas melnrakstus no 27. līdz 32.).
HTTP/3 definē QUIC protokola izmantošanu kā HTTP/2 transportu. Protokolu QUIC (Quick UDP Internet Connections) Google izstrādā kopš 2013. gada kā alternatīvu TCP+TLS kombinācijai tīmeklī, risinot problēmas ar ilgu iestatīšanas un sarunu laiku savienojumiem TCP un novēršot aizkavi, kad datu laikā tiek zaudētas paketes. nodošana. QUIC ir UDP protokola paplašinājums, kas atbalsta vairāku savienojumu multipleksēšanu un nodrošina TLS/SSL līdzvērtīgas šifrēšanas metodes. IETF standarta izstrādes gaitā tika veiktas izmaiņas protokolā, kā rezultātā parādījās divi paralēli atzari, viens HTTP/3, bet otrs atbalsta Google (Chrome atbalsta abas opcijas).
Galvenās QUIC funkcijas:
- Augsta drošība, līdzīga TLS (patiesībā QUIC nodrošina iespēju izmantot TLS, izmantojot UDP);
- Straumes integritātes kontrole, lai novērstu pakešu zudumu;
- 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 aizkavi starp pieprasījuma nosūtīšanu un atbildes saņemšanu (RTT, Round Trip Time);
- Atkārtoti pārsūtot paketi, tiek izmantots cits kārtas numurs, kas ļauj izvairīties no neskaidrībām saņemto pakešu identificēšanā un atbrīvoties no taimauta;
- Pakešu zudums ietekmē tikai ar to saistītās straumes piegādi un neaptur datu piegādi straumēs, kas tiek pārraidītas paralēli pašreizējā savienojumā;
- Kļūdu labošanas rīki, kas samazina aizkavi zaudēto pakešu atkārtotas pārsūtīšanas dēļ. Īpašu kļūdu labošanas kodu izmantošana pakešu līmenī, lai samazinātu situācijas, kurās nepieciešams atkārtoti nosūtīt zaudētos pakešdatus.
- Kriptogrāfisko bloku robežas tiek saskaņotas ar QUIC pakešu robežām, kas samazina pakešu zudumu ietekmi uz nākamo pakešu satura dekodēšanu;
- Nav problēmu ar TCP rindas bloķēšanu;
- Savienojuma ID atbalsts, lai samazinātu atkārtota savienojuma laiku mobilajiem klientiem;
- Iespēja pieslēgt progresīvus mehānismus savienojuma pārslodzes kontrolei;
- Izmantojot joslas platuma prognozēšanas paņēmienus katrā virzienā, lai nodrošinātu optimālu pakešu nosūtīšanas intensitāti, novēršot pārtīšanu pārslodzes stāvoklī, kurā notiek pakešu zudumi;
- Ievērojams veiktspējas un caurlaidspējas pieaugums salīdzinājumā ar TCP. Ir pierādīts, ka tādiem video pakalpojumiem kā YouTube, QUIC samazina atkārtotas buferizācijas darbības, skatoties videoklipus par 30%.
Avots: opennet.ru