Il Comitato IETF (Internet Engineering Task Force), responsabile 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 relative specifiche con gli identificatori RFC 9114 (protocollo) e RFC 9204 (tecnologia di compressione intestazioni QPACK per HTTP/3). La specifica HTTP/3.0 ha ottenuto lo status di "Standard Proposto", dopo di che inizierà il lavoro per conferire all'RFC lo status di Standard Abbozzato (Draft Standard), che significa di fatto la completa stabilizzazione del protocollo e l'accoglimento di tutte le osservazioni sollevate. 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 le intestazioni di controllo della cache (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 elevata latenza nella creazione e negoziazione delle connessioni TCP e riducendo i ritardi in caso di perdita di pacchetti durante il trasferimento dei dati.
Attualmente il supporto per QUIC e HTTP/3.0 è già implementato in tutti i principali browser web (in Chrome, Firefox ed Edge il supporto per HTTP/3 è abilitato di default, mentre in Safari richiede l'attivazione dell'impostazione "Advanced > Experimental Features > HTTP/3"). Sul lato server, le implementazioni di HTTP/3 sono disponibili per nginx (in un ramo separato e come modulo separato), Caddy, IIS e LiteSpeed. Anche la rete di distribuzione dei contenuti Cloudflare supporta HTTP/3.
Caratteristiche principali di QUIC:
- Elevata sicurezza, simile a TLS (in sostanza, QUIC offre la possibilità di utilizzare TLS sopra UDP);
- Controllo dell'integrità del flusso, prevenendo la perdita di pacchetti;
- La possibilità di stabilire una connessione in modo istantaneo (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 latenze minime tra l'invio della richiesta e la ricezione della risposta (RTT, Round Trip Time);
- Uso di un numero di sequenza diverso per la ritrasmissione di un pacchetto, consentendo di evitare ambiguità nella definizione dei pacchetti ricevuti e di eliminare i timeout;
- La perdita di pacchetti influisce solo sulla consegna del flusso correlato e non interrompe la consegna dei dati nei flussi trasmessi in parallelo attraverso la connessione attuale;
- Strumenti di correzione degli errori che minimizzano i ritardi causati dalla ritrasmissione dei pacchetti persi. Utilizzo di codici di correzione degli errori a livello di pacchetto per ridurre le situazioni che richiedono la ritrasmissione dei dati del pacchetto perso.
- I limiti dei blocchi crittografici sono allineati con i limiti 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 dell'identificatore della connessione, che consente di ridurre il tempo per stabilire una connessione di ripristino per i clienti mobili;
- Possibilità di collegare meccanismi avanzati di controllo della congestione della connessione;
- L'uso di tecniche di previsione della capacità in ogni direzione per garantire un'intensità ottimale nell'invio dei pacchetti, evitando di scivolare in uno stato di sovraccarico in cui si verifica la perdita di pacchetti;
- Un notevole aumento delle prestazioni e della larghezza di banda rispetto al TCP. Per i servizi video, come YouTube, l'uso di QUIC ha mostrato una riduzione del 30% delle operazioni di buffering durante la visione di video.
Tra le modifiche nella specifica HTTP/1.1, si segnala il divieto di utilizzare il carattere di ritorno a capo (CR) al di fuori del corpo del contenuto, cioè, negli elementi del protocollo, il carattere CR può essere utilizzato solo insieme al carattere di avanzamento riga (CRLF). L'algoritmo di impacchettamento delle richieste chunked è stato revisionato per semplificare la separazione dei campi allegati e della sezione delle intestazioni. Sono state aggiunte raccomandazioni per gestire contenuti ambigui per bloccare attacchi di tipo "HTTP Request Smuggling", che consentono di infiltrarsi nei contenuti delle richieste di altri utenti nel flusso tra il frontend e il backend.
Nell'aggiornamento della specifica HTTP/2.0 è stata chiaramente definita la compatibilità con TLS 1.3. È stata declassata a obsoleta la precedente modalità di definizione delle priorità e le relative intestazioni. È stato dichiarato obsoleto il meccanismo di aggiornamento delle connessioni da HTTP/1.1, che non ha trovato ampia diffusione. Sono stati ridotti i requisiti per la verifica dei nomi dei campi e dei valori. Sono stati suggeriti per l'uso alcuni tipi di frame e parametri precedentemente riservati. Sono stati definiti in modo più preciso i campi delle intestazioni vietati, che si riferiscono alla connessione.
Fonte: opennet.ru
