Versiunile de noapte și beta ale Firefox includ suport pentru protocolul HTTP/3 în mod implicit. În ramura stabilă, includerea HTTP/3 este programată pentru lansarea Firefox 88, programată pentru 20 aprilie. Chrome a început să activeze selectiv HTTP/3 în octombrie 2020.
Suportul HTTP/3 al Firefox se bazează pe proiectul neqo al Mozilla, care oferă o implementare client și Server pentru protocolul QUIC. Codul pentru componentele care acceptă HTTP/3 și QUIC este scris în Rust. Pentru a activa HTTP/3, opțiunea „network.http.http3.enabled” este disponibilă în about:config. De asemenea, a fost adăugat suport experimental pentru HTTP/3 în Chrome și curl pentru software-ul client și servere Este disponibil în Nginx, precum și ca modul Nginx și server de testare de la Cloudflare. Au fost lansate mai multe site-uri de testare pentru a testa funcționalitatea clientului HTTP/3.
Protocolul HTTP/3 este încă în faza de proiectare a specificațiilor și nu a fost încă pe deplin standardizat de IETF. HTTP/3 definește utilizarea protocolului QUIC ca transport pentru HTTP/2. Protocolul QUIC (Quick UDP Internet Connections) a fost dezvoltat de Google din 2013 ca o alternativă la combinația TCP+TLS pentru Web, rezolvând problemele cu timpi lungi de configurare și negociere pentru conexiunile în TCP și eliminând întârzierile atunci când pachetele sunt pierdute în timpul datelor. transfer. QUIC este o extensie a protocolului UDP care acceptă multiplexarea conexiunilor multiple și oferă metode de criptare echivalente cu TLS/SSL. În timpul dezvoltării standardului IETF au fost aduse modificări protocolului, ceea ce a dus la apariția a două ramuri paralele, una pentru HTTP/3, iar a doua suportată de Google (Chrome acceptă ambele opțiuni).
Caracteristicile cheie ale QUIC:
- Securitate ridicată similară cu TLS (în esență QUIC oferă posibilitatea de a utiliza TLS peste UDP);
- Controlul integrității fluxului, prevenind pierderea pachetelor;
- Capacitatea de a stabili instantaneu o conexiune (0-RTT, în aproximativ 75% din cazuri datele pot fi transmise imediat după trimiterea pachetului de configurare a conexiunii) și de a oferi întârzieri minime între trimiterea unei cereri și primirea unui răspuns (RTT, Round Trip Time);
- Utilizarea unui număr de secvență diferit la retransmiterea unui pachet, ceea ce evită ambiguitatea în identificarea pachetelor primite și scapă de timeout-uri;
- Pierderea unui pachet afectează doar livrarea fluxului asociat cu acesta și nu oprește livrarea datelor în fluxuri paralele transmise prin conexiunea curentă;
- Funcții de corectare a erorilor care minimizează întârzierile datorate retransmiterii pachetelor pierdute. Utilizarea codurilor speciale de corectare a erorilor la nivel de pachet pentru a reduce situațiile care necesită retransmiterea pachetelor de date pierdute.
- Granițele blocurilor criptografice sunt aliniate cu granițele pachetelor QUIC, ceea ce reduce impactul pierderilor de pachete asupra decodării conținutului pachetelor ulterioare;
- Fără probleme cu blocarea cozii TCP;
- Suport pentru identificatorul de conexiune, care reduce timpul necesar pentru stabilirea unei reconectari pentru clienții mobili;
- Posibilitatea de conectare a mecanismelor avansate de control al congestionării conexiunii;
- Utilizează tehnici de prognoză a debitului pe direcție pentru a se asigura că pachetele sunt trimise la rate optime, prevenind congestionarea acestora și pierderea pachetelor;
- O creștere vizibilă a performanței și a debitului în comparație cu TCP. Pentru serviciile video precum YouTube, s-a demonstrat că QUIC reduce operațiunile de rebuffering la vizionarea videoclipurilor cu 30%.
Sursa: opennet.ru
