HTTP/3.0 a primit statutul standard propus

IETF (Internet Engineering Task Force), care este responsabil pentru dezvoltarea protocoalelor și arhitecturii Internet, a finalizat formarea unui RFC pentru protocolul HTTP/3.0 și a publicat specificațiile aferente sub identificatorii RFC 9114 (protocol) și RFC 9204 ( Tehnologia de compresie a antetului QPACK pentru HTTP/3). Specificația HTTP/3.0 a primit statutul de „Standard propus”, după care vor începe lucrările pentru a da RFC statutul de proiect de standard (Draft Standard), ceea ce înseamnă de fapt o stabilizare completă a protocolului și luarea în considerare a tuturor comentariile facute. În același timp, 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 solicitărilor HTTP (RFC 9110) și anteturile de control pentru cachingul HTTP. (RFC 9111).

Protocolul HTTP/3 definește utilizarea protocolului QUIC (Quick UDP Internet Connections) ca transport pentru HTTP/2. QUIC este o extensie a protocolului UDP care acceptă multiplexarea conexiunilor multiple și oferă metode de criptare echivalente cu TLS/SSL. Protocolul a fost creat în 2013 de Google ca alternativă la combinația TCP+TLS pentru Web, rezolvând problemele legate de configurarea conexiunii și timpii de negociere lungi în TCP și eliminând întârzierile la pierderea pachetelor în timpul transferului de date.

HTTP/3.0 a primit statutul standard propus

În prezent, suportul QUIC și HTTP/3.0 este deja implementat în toate browserele web populare (în Chrome, Firefox și Edge, suportul HTTP/3 este activat implicit, iar în Safari necesită setarea „Advanced > Experimental Features > HTTP/3” pentru a fi activat). Pe partea de server, implementările HTTP/3 sunt disponibile pentru nginx (într-o ramură separată și sub forma unui modul separat), Caddy, IIS și LiteSpeed. Suportul HTTP/3 este oferit și de rețeaua de livrare de conținut Cloudflare.

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;
  • Abilitatea 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) ;
    HTTP/3.0 a primit statutul standard propus
  • 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;
  • Creștere semnificativă a performanței și a randamentului în comparație cu TCP. Pentru serviciile video precum YouTube, s-a demonstrat că QUIC reduce operațiunile de rebuffering atunci când vizionați videoclipuri cu 30%.

Printre modificările aduse specificației HTTP/1.1, se remarcă interzicerea utilizării izolate a caracterului retur car (CR) în afara corpului cu conținut, i.e. În elementele de protocol, caracterul CR poate fi utilizat numai împreună cu caracterul de avans în linie (CRLF). Algoritmul de aspect al cererii în bucăți a fost îmbunătățit pentru a simplifica separarea câmpurilor și secțiunilor atașate cu anteturi. S-au adăugat recomandări pentru gestionarea conținutului ambiguu pentru a bloca atacurile „HTTP Request Smuggling”, care ne permit să ne confundăm cu conținutul solicitărilor altor utilizatori în fluxul dintre frontend și backend.

Actualizarea specificațiilor HTTP/2.0 definește în mod explicit suportul pentru TLS 1.3. Schema de prioritizare și câmpurile de antet asociate au fost depreciate. Mecanismul neutilizat pentru actualizarea conexiunii cu HTTP/1.1 a fost declarat caducat. Cerințele pentru verificarea numelor și valorilor câmpurilor au fost reduse. Unele tipuri de cadre și parametri rezervați anterior sunt propuși pentru utilizare. Câmpurile de antet interzise legate de conexiune sunt definite mai precis.

Sursa: opennet.ru

Adauga un comentariu