{"id":104306,"date":"2022-06-07T09:36:47","date_gmt":"2022-06-07T07:36:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta"},"modified":"2022-06-07T09:36:47","modified_gmt":"2022-06-07T07:36:48","slug":"protokol-http-3-0-poluchil-status-predlozhennogo-standarta","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta","title":{"rendered":"Il protocollo HTTP\/3.0 ha ottenuto lo status di standard proposto.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Il Comitato IETF (Internet Engineering Task Force), che si occupa dello sviluppo dei protocolli e dell'architettura di Internet, ha completato la stesura della 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 acquisito lo status di \"Standard Proposto\", dopodich\u00e9 inizier\u00e0 il lavoro per conferire alla RFC lo status di Standard Bozza (Draft Standard), il che significa di fatto la completa stabilizzazione del protocollo e la considerazione di tutti i commenti espressi. Sono stati pubblicati anche aggiornamenti delle specifiche per i protocolli HTTP\/1.1 (RFC 9112) e HTTP\/2.0 (RFC 9113), oltre a documenti che definiscono la semantica delle richieste HTTP (RFC 9110) e gli header di controllo della cache HTTP (RFC 9111). <\/p>\n
Il protocollo HTTP\/3 definisce l'uso del protocollo QUIC (Quick UDP Internet Connections) come trasporto per HTTP\/2. QUIC \u00e8 un'estensione del protocollo UDP, che supporta il multiplexing di pi\u00f9 connessioni e fornisce metodi di crittografia equivalenti a TLS\/SSL. Il protocollo \u00e8 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.
<\/center> <\/p>\n
Attualmente, il supporto per QUIC e HTTP\/3.0 \u00e8 gi\u00e0 implementato in tutti i principali browser web (in Chrome, Firefox ed Edge, il supporto per HTTP\/3 \u00e8 abilitato di default, mentre in Safari richiede l'attivazione dell'impostazione \"Avanzate > Funzioni sperimentali > HTTP\/3\"). Sul lato server, le implementazioni di HTTP\/3 sono disponibili per nginx (in un ramo separato e sotto forma di modulo separato), Caddy, IIS e LiteSpeed. Il supporto per HTTP\/3 \u00e8 fornito anche dalla rete di distribuzione dei contenuti Cloudflare. <\/p>\n
Caratteristiche principali di QUIC: <\/p>\n
\n
Elevata sicurezza, simile a TLS (essenzialmente QUIC offre la possibilit\u00e0 di utilizzare TLS sopra UDP); <\/li>\n
Controllo dell'integrit\u00e0 del flusso, che previene la perdita di pacchetti; <\/li>\n
Possibilit\u00e0 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);
<\/center> <\/li>\n
Utilizzo di un numero di sequenza diverso per la ritrasmissione di pacchetti, il che consente di evitare ambiguit\u00e0 nella determinazione dei pacchetti ricevuti e di eliminare i timeout; <\/li>\n
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; <\/li>\n
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. <\/li>\n
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; <\/li>\n
Assenza di problemi di blocco della coda TCP; <\/li>\n
Supporto per l'identificatore di connessione, che consente di ridurre i tempi per stabilire una nuova connessione per i clienti mobili; <\/li>\n
Possibilit\u00e0 di connettere meccanismi avanzati di controllo del sovraccarico della connessione; <\/li>\n
Utilizzo di tecniche di previsione della larghezza di banda in entrambe le direzioni per garantire un'intensit\u00e0 ottimale di invio dei pacchetti, evitando di scivolare in uno stato di sovraccarico, caratterizzato dalla perdita di pacchetti; <\/li>\n
Un notevole incremento delle prestazioni e della capacit\u00e0 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%. <\/ul>\n
Tra le modifiche nella specifica HTTP\/1.1, si segnala il divieto di utilizzo isolato del carattere di ritorno a capo (CR) al di fuori del corpo del contenuto, cio\u00e8, negli elementi del protocollo, il carattere CR pu\u00f2 essere utilizzato solo insieme al carattere di fine linea (CRLF). L'algoritmo di impacchettamento delle richieste chunked \u00e8 stato perfezionato per semplificare la separazione dei campi allegati e della sezione degli header. Sono state aggiunte raccomandazioni per la gestione di contenuti ambigui per bloccare attacchi di tipo \"HTTP Request Smuggling\", che consentono di infiltrarsi nel contenuto delle richieste di altri utenti nel flusso tra il front-end e il back-end. <\/p>\n
Nell'aggiornamento della specifica HTTP\/2.0 \u00e8 stata esplicitamente definita la compatibilit\u00e0 con TLS 1.3. \u00c8 stata trasferita nella categoria obsoleta la scheda di definizione delle priorit\u00e0 e i campi correlati nelle intestazioni. \u00c8 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\u00f9 preciso i campi delle intestazioni proibiti relativi alla connessione. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Il](\"\/wp-content\/uploads\/2022\/06\/0821fd634337ac1f1cc0924abb4f55dc.jpg\")
<\/center> <\/p>\n![\"Il](\"\/wp-content\/uploads\/2022\/06\/d416668e500fd2b79304fa0b13f793e3.jpg\")
<\/center> <\/li>\n