L'IETF (Internet Engineering Task Force), responsabile dello sviluppo dei protocolli e dell'architettura Internet, ha completato la formazione di un RFC per il protocollo HTTP/3.0 e ha pubblicato le relative specifiche sotto gli identificatori RFC 9114 (protocollo) e RFC 9204 ( Tecnologia di compressione dell'intestazione QPACK per HTTP/3). La specifica HTTP/3.0 ha ricevuto lo status di “Proposed Standard”, dopodiché inizieranno i lavori per conferire alla RFC lo status di bozza di standard (Draft Standard), il che significa di fatto una completa stabilizzazione del protocollo e tenendo conto di tutti i commenti fatti. Contestualmente sono state pubblicate versioni aggiornate delle specifiche dei protocolli HTTP/1.1 (RFC 9112) e HTTP/2.0 (RFC 9113), nonché documenti che definiscono la semantica delle richieste HTTP (RFC 9110) e gli header di controllo del caching HTTP (RFC 9111).
Il protocollo HTTP/3 definisce l'utilizzo del protocollo QUIC (Quick UDP Internet Connections) come trasporto per HTTP/2. QUIC è un'estensione del protocollo UDP che supporta il multiplexing di connessioni multiple 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 legati ai lunghi tempi di installazione e negoziazione della connessione in TCP ed eliminando i ritardi quando i pacchetti vengono persi durante il trasferimento dei dati.
Attualmente, il supporto QUIC e HTTP/3.0 è già implementato in tutti i browser Web più diffusi (in Chrome, Firefox ed Edge, il supporto HTTP/3 è abilitato per impostazione predefinita e in Safari richiede l'impostazione "Avanzate > Funzionalità sperimentali > HTTP/3" essere abilitato). Lato server sono disponibili implementazioni HTTP/3 per nginx (in un ramo separato e sotto forma di modulo separato), Caddy, IIS e LiteSpeed. Il supporto HTTP/3 è fornito anche dalla rete di distribuzione dei contenuti Cloudflare.
Caratteristiche principali di QUIC:
- Sicurezza elevata simile a TLS (sostanzialmente QUIC offre la possibilità di utilizzare TLS su UDP);
- Controllo dell'integrità del flusso, prevenendo la perdita di pacchetti;
- La capacità di stabilire istantaneamente una connessione (0-RTT, in circa il 75% dei casi i dati possono essere trasmessi immediatamente dopo l'invio del pacchetto di configurazione della connessione) e di garantire ritardi minimi tra l'invio di una richiesta e la ricezione di una risposta (RTT, Round Trip Time);
- Utilizzo di un numero di sequenza diverso durante la ritrasmissione di un pacchetto, che evita ambiguità nell'identificazione dei pacchetti ricevuti ed elimina i timeout;
- La perdita di un pacchetto influisce solo sulla consegna del flusso ad esso associato e non interrompe la consegna dei dati nei flussi paralleli trasmessi attraverso la connessione corrente;
- Funzionalità di correzione degli errori che riducono al minimo i ritardi dovuti alla ritrasmissione di 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 persi.
- I confini dei blocchi crittografici sono allineati ai confini dei pacchetti QUIC, il che riduce l'impatto delle perdite di pacchetti sulla decodifica del contenuto dei pacchetti successivi;
- Nessun problema con il blocco della coda TCP;
- Supporto per l'identificatore di connessione, che riduce il tempo necessario per stabilire una riconnessione per i client mobili;
- Possibilità di collegare meccanismi avanzati di controllo della congestione delle connessioni;
- Utilizza tecniche di previsione del throughput per direzione per garantire che i pacchetti vengano inviati a velocità ottimali, evitando che si congestionino e causino la perdita di pacchetti;
- Aumento significativo delle prestazioni e del throughput rispetto al TCP. Per i servizi video come YouTube, è stato dimostrato che QUIC riduce le operazioni di rebuffering durante la visione di video del 30%.
Tra le modifiche apportate alla specifica HTTP/1.1 si segnala il divieto dell'uso isolato del carattere di ritorno a capo (CR) al di fuori del corpo del contenuto, ad es. Negli elementi del protocollo il carattere CR può essere utilizzato solo insieme al carattere di avanzamento riga (CRLF). L'algoritmo di layout della richiesta in blocchi è stato migliorato per semplificare la separazione dei campi e delle sezioni allegati con intestazioni. Aggiunti consigli per la gestione di contenuti ambigui per bloccare gli attacchi di “contravvenzione di richieste HTTP”, che ci consentono di incunearci nel contenuto delle richieste di altri utenti nel flusso tra frontend e backend.
L'aggiornamento della specifica HTTP/2.0 definisce esplicitamente il supporto per TLS 1.3. Deprecato lo schema di definizione delle priorità e i campi di intestazione associati. Il meccanismo inutilizzato per l'aggiornamento della connessione con HTTP/1.1 è stato dichiarato obsoleto. I requisiti per il controllo dei nomi e dei valori dei campi sono stati ridotti. Vengono proposti per l'uso alcuni tipi di frame e parametri precedentemente riservati. I campi di intestazione vietati relativi alla connessione sono definiti in modo più preciso.
Fonte: opennet.ru