Il Comitato IETF (Internet Engineering Task Force), che si occupa dello sviluppo dei protocolli e dell'architettura di Internet, ha completato la formazione dell'RFC per il protocollo HTTP/3.0 e ha pubblicato le specifiche correlate con gli identificatori RFC 9114 (protocollo) e RFC 9204 (tecnologia di compressione degli header QPACK per HTTP/3). La specifica HTTP/3.0 ha ricevuto lo status di "Standard Proposto", dopo il quale inizierà il lavoro per conferire all'RFC lo status di Standard Bozza (Draft Standard), che significa sostanzialmente la completa stabilizzazione del protocollo e la considerazione di tutte le osservazioni espresse. Sono state pubblicate anche versioni aggiornate delle specifiche per i protocolli HTTP/1.1 (RFC 9112) e HTTP/2.0 (RFC 9113), così come documenti che definiscono la semantica delle richieste HTTP (RFC 9110) e gli header di controllo della cache HTTP (RFC 9111).
Il protocollo HTTP/3 definisce l'uso del protocollo QUIC (Quick UDP Internet Connections) come trasporto per HTTP/2. QUIC è un'estensione del protocollo UDP, che supporta il multiplexing di più connessioni e fornisce metodi di crittografia equivalenti a TLS/SSL. Il protocollo è stato creato nel 2013 da Google come alternativa alla combinazione TCP+TLS per il Web, risolvendo problemi di elevato tempo di connessione e negoziazione in TCP ed eliminando le latenze in caso di perdita di pacchetti durante la trasmissione dei dati.
Attualmente, il supporto per QUIC e HTTP/3.0 è già implementato in tutti i browser web popolari (in Chrome, Firefox e Edge, il supporto HTTP/3 è attivo per impostazione predefinita, mentre in Safari è necessaria l'attivazione dell'impostazione "Advanced > Experimental Features > HTTP/3"). Sul lato server, le implementazioni di HTTP/3 sono disponibili per nginx (in una branch separata e come modulo separato), Caddy, IIS e LiteSpeed. Il supporto per HTTP/3 è fornito anche dalla rete di distribuzione dei contenuti Cloudflare.
Caratteristiche principali di QUIC:
- Elevata sicurezza, simile a TLS (essenzialmente QUIC offre la possibilità di utilizzare TLS sopra UDP);
- Controllo dell'integrità del flusso, che previene la perdita di pacchetti;
- Possibilità di stabilire una connessione istantaneamente (0-RTT, in circa il 75% dei casi i dati possono essere trasmessi immediatamente dopo l'invio del pacchetto di stabilimento della connessione) e garantire minimi ritardi tra l'invio della richiesta e la ricezione della risposta (RTT, Round Trip Time);
- Utilizzo di un numero di sequenza diverso per la ritrasmissione di pacchetti, il che consente di evitare ambiguità nella determinazione dei pacchetti ricevuti e di eliminare i timeout;
- La perdita di pacchetti influisce solo sulla consegna del flusso a essi associato e non interrompe la consegna dei dati nei flussi trasmessi parallelamente attraverso l'attuale connessione;
- Strumenti di correzione degli errori, che minimizzano i ritardi dovuti alla ritrasmissione dei pacchetti persi. Utilizzo di codici speciali di correzione degli errori a livello di pacchetto per ridurre le situazioni che richiedono la ritrasmissione dei dati del pacchetto perso.
- I confini dei blocchi crittografici sono allineati con i confini dei pacchetti QUIC, riducendo l'impatto delle perdite di pacchetti sulla decodifica del contenuto dei pacchetti successivi;
- Assenza di problemi di blocco della coda TCP;
- Supporto per l'identificatore di connessione, che consente di ridurre i tempi per stabilire una nuova connessione per i clienti mobili;
- Possibilità di connettere meccanismi avanzati di controllo del sovraccarico della connessione;
- Utilizzo di tecniche di previsione della larghezza di banda in entrambe le direzioni per garantire un'intensità ottimale di invio dei pacchetti, evitando di scivolare in uno stato di sovraccarico, caratterizzato dalla perdita di pacchetti;
- Un notevole incremento delle prestazioni e della capacità di throughput rispetto a TCP. Per i servizi video, come YouTube, l'adozione di QUIC ha mostrato una riduzione delle operazioni di buffering durante la visione dei video del 30%.
Tra le modifiche nella specifica HTTP/1.1 si può notare il divieto di utilizzo isolato del carattere di ritorno a capo (CR) al di fuori del corpo del contenuto, ovvero, negli elementi del protocollo il simbolo CR può essere utilizzato solo insieme al simbolo di fine linea (CRLF). L'algoritmo per la creazione di richieste chunked è stato migliorato per semplificare la suddivisione dei campi allegati e della sezione intestazione. Sono state aggiunte raccomandazioni per la gestione di contenuti ambigui al fine di bloccare attacchi di tipo "HTTP Request Smuggling", che consentono di infiltrarsi nel contenuto delle richieste di altri utenti nel flusso tra il frontend e il backend.
Nell'aggiornamento della specifica HTTP/2.0 è stata esplicitamente definita la compatibilità con TLS 1.3. È stata trasferita nella categoria obsoleta la scheda di definizione delle priorità e i campi correlati nelle intestazioni. È stato dichiarato obsoleto il meccanismo per l'aggiornamento della connessione da HTTP/1.1, che non ha avuto diffusione. Sono stati ridotti i requisiti per la verifica dei nomi dei campi e dei valori. Sono stati proposti per l'uso alcuni tipi di frame e parametri precedentemente riservati. Sono stati definiti in modo più preciso i campi delle intestazioni proibiti relativi alla connessione.
Fonte: opennet.ru
