Comitetul IETF (Internet Engineering Task Force), care se ocupă cu dezvoltarea protocoalelor și arhitecturii internetului, a finalizat formarea RFC pentru protocolul HTTP/3.0 și a publicat specificațiile aferente sub identificatorii RFC 9114 (protocol) și RFC 9204 (tehnologia de compresie a antetelor QPACK pentru HTTP/3). Specificația HTTP/3.0 a primit statutul de „Standard propus”, după care va începe procesul de acordare a RFC-ului statutului de standard draft (Draft Standard), ceea ce înseamnă, în fapt, stabilizarea completă a protocolului și luarea în considerare a tuturor observațiilor exprimate. De asemenea, au fost publicate versiuni actualizate ale specificațiilor pentru protocoalele HTTP/1.1 (RFC 9112) și HTTP/2.0 (RFC 9113), precum și documente care definesc semantica cererilor HTTP (RFC 9110) și antetele HTTP pentru gestionarea cache-ului (RFC 9111).
Protocolul HTTP/3 definește utilizarea protocolului QUIC (Quick UDP Internet Connections) ca transport pentru HTTP/2. QUIC este o suprastructură peste protocolul UDP, care suportă multiplexarea mai multor conexiuni și oferă metode de criptare echivalente cu TLS/SSL. Protocolul a fost creat în 2013 de către Google ca alternativă la combinația TCP+TLS pentru Web, abordând problemele legate de timpul mare de stabilire și negociere a conexiunilor în TCP și eliminând întârzierile cauzate de pierderile de pachete în timpul transmiterii datelor.
În prezent, suportul pentru QUIC și HTTP/3.0 este deja implementat în toate browserele web populare (în Chrome, Firefox și Edge suportul HTTP/3 este activat în mod implicit, în timp ce în Safari necesită activarea setării „Advanced > Experimental Features > HTTP/3”). Pe partea de server, implementările HTTP/3 sunt disponibile pentru nginx (într-o ramificare separată și sub formă de modul separat), Caddy, IIS și LiteSpeed. Suportul pentru HTTP/3 este oferit și de rețeaua de livrare a conținutului Cloudflare.
Caracteristici principale ale QUIC:
- Securitate înaltă, similară cu TLS (în esență, QUIC oferă posibilitatea utilizării TLS peste UDP);
- Controlul integrității fluxului, prevenind pierderea pachetelor;
- Capacitatea de a stabili o conexiune instantanee (0-RTT, în aproximativ 75% din cazuri, datele pot fi transmise imediat după trimiterea pachetului de stabilire a conexiunii) și de a asigura întârzieri minime între trimiterea unei cereri și primirea răspunsului (RTT, Round Trip Time);
- Utilizarea unui alt număr de secvență pentru retransmisia pachetului, ceea ce permite evitarea ambiguității în determinarea pachetelor primit și eliminarea timeout-urilor;
- Pierderea unui pachet afectează livrarea doar a fluxului asociat și nu oprește livrarea datelor în fluxurile transmise în paralel prin conexiunea curentă;
- Mijloace de corectare a erorilor, care minimizează întârzierile cauzate de retransmisia pachetelor pierdute. Utilizarea unor coduri speciale de corectare a erorilor la nivel de pachet pentru a reduce situațiile care necesită retransmiterea datelor din pachetul pierdut.
- Limitele blocurilor criptografice sunt aliniate cu limitele pachetelor QUIC, ceea ce reduce impactul pierderilor de pachete asupra decodificării conținutului pachetelor următoare;
- Lipsa problemelor cu blocarea cozii TCP;
- Suport pentru identificatorul de conexiune, care permite reducerea timpului de reinstaurare a conexiunii pentru clienți mobile;
- Posibilitatea de a activa mecanisme extinse de control al supraîncărcării conexiunii;
- Utilizarea tehnicii de previzionare a capacității de transmisie în fiecare direcție pentru a asigura o intensitate optimă a trimiterii pachetelor, prevenind astfel ajungerea într-o stare de supraîncărcare, în care se observă pierderi de pachete;
- O creștere semnificativă a performanței și a capacității de transmisie comparativ cu TCP. Pentru servicii video, cum ar fi YouTube, utilizarea QUIC a arătat o reducere cu 30% a operațiunilor de re-buffering în timpul vizionării video.
Printre modificările din specificația HTTP/1.1 se numără interdicția utilizării izolate a simbolului de întoarcere a carierei (CR) în afara corpului de conținut, adică în elementele protocolului, simbolul CR poate fi utilizat doar împreună cu simbolul de transfer de linie (CRLF). Algoritmul pentru organizarea cererilor chunked a fost îmbunătățit pentru a simplifica separarea câmpurilor atașate și a secțiunii de antete. S-au adăugat recomandări pentru tratarea conținutului ambiguu pentru a bloca atacurile din categoria „HTTP Request Smuggling”, care permit infiltrarea în conținutul cererilor altor utilizatori în fluxul dintre front-end și back-end.
În actualizarea specificației HTTP/2.0, a fost definită clar suportul pentru TLS 1.3. Schema de definire a priorităților și câmpurile asociate din header-uri au fost mutate în categoria celor învechite. Mecanismul de actualizare a conexiunii cu HTTP/1.1, care nu a prins avânt, a fost declarat învechit. Cerințele pentru verificarea numelui câmpurilor și valorilor au fost reduse. Au fost propuse pentru utilizare câteva tipuri de cadre și parametri anterior rezervate. Câmpurile header-ului interzise, referitoare la conexiune, au fost definite mai exact.
Sursa: opennet.ro
