Evoluzioni di HTTP: HTTP/2 e HTTP/3

Evoluzioni di HTTP

• HTTP/2 e HTTP/3 sono versioni più recenti del protocollo HTTP, che mirano a migliorare le prestazioni senza modificarne la semantica.
• HTTP/2 è focalizzato sulla riduzione del page load time percepito dall'utente, diminuendo la latenza e ottimizzando l'uso delle risorse.
• HTTP/2 mantiene la compatibilità con infrastrutture HTTP/1.1.

Caratteristiche principali di HTTP/2

• Compressione degli header: gli header HTTP/2 sono codificati in formato binario, comprimendo i dati e rendendoli più efficienti da gestire.
• Multiplexing e prioritizzazione: HTTP/2 supporta connessioni parallele, eliminando il problema dell'head-of-line blocking. I flussi di dati sono gestiti come stream paralleli, consentendo alle richieste di caricarsi in parallelo.
• Server push: HTTP/2 permette al server di inviare risorse al client (es. file CSS) prima che vengano richieste, migliorando i tempi di caricamento.

Frame e Stream in HTTP/2

• Frame: la più piccola unità di comunicazione in HTTP/2, composta da header e payload.
• Tipi di frame: DATA, HEADERS, PRIORITY, RST_STREAM, SETTINGS, PUSH_PROMISE, PING, GOAWAY.
• Stream: serie di frame che trasportano i dati per una specifica richiesta o risposta.

Server push e meccanismo PUSH_PROMISE

• Server push: il server invia risorse anticipando le richieste del client. Ad esempio, un file CSS associato a una pagina HTML.
• PUSH_PROMISE: frame che permette al server di "promettere" risorse al client prima che vengano richieste.

Funzionamento della connessione HTTP/2

• La comunicazione avviene in formato binario, a differenza di HTTP/1.1.
• La codifica binaria migliora l'efficienza, richiedendo però la comprensione da parte di client e server.
• Una richiesta tipica (GET) non include payload, mentre la risposta prevede frame di tipo HEADERS e DATA contenenti il payload.

Connessione TCP in HTTP/2

• In una connessione TCP, i dati di diversi stream possono essere mescolati.
• I dati e gli header dagli stream possono essere inviati in entrambe le direzioni, creando un flusso bidirezionale.
• Questo approccio previene il head-of-line blocking, consentendo a flussi più leggeri con dati minimi di completarsi rapidamente, anche in presenza di flussi pesanti.

Server Push

• Il server push permette al server di inviare risorse al client senza una richiesta esplicita.
• Il server può annunciare l'invio di risorse come file JS o CSS tramite un frame PUSH_PROMISE.
• Il client può rifiutare le risorse usando RST_STREAM o disabilitare il server push tramite specifici frame di settaggio.

Compressione degli Header con HPACK

• HTTP/2 usa HPACK per comprimere gli header HTTP, riducendo il consumo di banda e migliorando la trasmissione.
• HPACK utilizza un dizionario statico con termini comuni come GET, POST, index.html e "accept-encoding: gzip, deflate".
• Il dizionario dinamico si aggiorna in base alle combinazioni frequenti tra i nodi.
• Le combinazioni non presenti nel dizionario vengono compresse con l'algoritmo di Huffman.

Controllo di Flusso

• HTTP/2 implementa un controllo di flusso bidirezionale su ogni nodo (client, proxy, server).
• Il controllo di flusso aumenta la granularità e consente la priorizzazione delle risorse basata su dimensioni e importanza.
• La flow control window regola la capacità di ricezione di ogni stream, ottimizzando le risorse e assegnando larghezza di banda differenziata.

Controllo del Flusso in HTTP/2

• Ciascun stream in HTTP/2 può avere una capacità di ricezione diversa.
• La finestra di controllo del flusso ha un valore predefinito di 65.535 byte per stream.
• **La dimensione della finestra può essere modificata attraverso i frame di impostazione (SETTINGS). **
• Il parametro SETTINGS_INITIAL_WINDOW_SIZE regola la dimensione iniziale della finestra.
• La finestra può essere aggiornata in modo dinamico utilizzando i frame di aggiornamento della finestra (WINDOW_UPDATE).
• Un aggiornamento della finestra indica quanti byte in più possono essere inviati.
• La dimensione massima della finestra è 2^31 - 1 byte.

Trasmissione con Controllo del Flusso

• Il client stabilisce una connessione TCP e invia un frame di SETTINGS sullo stream 0 per definire il numero di stream e la dimensione della finestra.
• La vera trasmissione dei dati avviene su stream diversi, per esempio lo stream 1.
• Un frame di header per una richiesta POST della risorsa index.html viene inviato sullo stream 1.
• Ogni frame di dati (DATA) ha una dimensione di 16.384 byte.
• Il client si ferma dopo aver inviato 4 frame di dati (totale 65.535 byte) in attesa di un aggiornamento della finestra dal server.

Introduzione di HTTP/3 e QUIC

• HTTP/3 è stato introdotto per risolvere i limiti di HTTP/2 legati a TCP, come il problema dell'head-of-line blocking.
• In HTTP/2, se un pacchetto TCP viene perso, tutte le richieste multiplexate sulla stessa connessione TCP sono bloccate.
• HTTP/3 utilizza QUIC, un protocollo di trasporto basato su UDP, per risolvere questo problema.
• QUIC offre una maggiore efficienza e riduce i tempi di configurazione con connessioni di rete variabili e la funzionalità 0-RTT.

Sicurezza avanzata con QUIC

• QUIC integra la sicurezza a livello di trasporto utilizzando la crittografia end-to-end basata su TLS.
• A differenza di TCP, che non fornisce crittografia nativa, QUIC crittografa automaticamente il payload dei dati e alcuni campi dell'header.
• Questo offre maggiore sicurezza e semplifica la configurazione.
• La crittografia protegge da attacchi come replay e man-in-the-middle.

Confronto tra TCP e QUIC

• TCP richiede diversi passaggi per l'handshake e la configurazione TLS prima della trasmissione HTTP.
• In QUIC, questi passaggi sono unificati, riducendo il numero di messaggi necessari.
• In TCP, tutti i campi degli header sono visibili, mentre in QUIC solo alcuni campi sono leggibili.
• I dettagli dei frame e degli acknowledgement sono criptati in QUIC, rendendo impossibile l'analisi del traffico da parte di un attaccante.

Interazione Tra HTTP/3 e QUIC

• QUIC ha un'interazione più stretta con HTTP rispetto a TCP, gestendo direttamente gli stream HTTP.
• Risolve il problema dell'head-of-line blocking, garantendo che la perdita di un pacchetto non blocchi altri stream.
• QUIC ha una gestione dei pacchetti persi a livello di trasporto, evitando il blocco di tutti gli stream a causa della perdita di un pacchetto.
• Gestisce la congestione e corregge gli errori con codici di correzione, limitando le ritrasmissioni e migliorando la resilienza in reti lente.

Efficienza della Trasmissione e Compressione

• QUIC gestisce flussi fuori ordine e introduce un nuovo protocollo di compressione adattato a flussi dinamici.
• Migliora l'efficienza rispetto a HPACK (HTTP/2) adattando la compressione in base agli stream attivi.

Multiplexing e Sicurezza

• QUIC gestisce il multiplexing degli stream, integrando elementi di affidabilità e controllo della congestione.
• Integra i meccanismi TLS, semplificando la gestione di autenticazione e crittografia.

Prioritizzazione degli Stream

• QUIC gestisce flussi multipli, ma non implementa direttamente la prioritizzazione degli stream.
• HTTP/3 comunica i dati di priorità a QUIC, mantenendo la collaborazione tra i livelli.

Struttura del Protocollo e Semantica HTTP

• QUIC funziona a livello di trasporto su UDP, ma mantiene invariato il livello IP e la semantica dei messaggi HTTP.
• La logica semantica rimane la stessa di HTTP/1.1 e HTTP/2.
• QUIC introduce innovazioni a livello di trasporto per migliorare l'efficienza e la resilienza delle connessioni.

Interazione tra HTTP/3 e QUIC

• QUIC ha un'interazione più stretta con HTTP rispetto al normale livello di trasporto.
• A differenza di HTTP/2, QUIC gestisce direttamente gli stream HTTP, eliminando il problema dell'head-of-line blocking.
• QUIC permette la gestione indipendente dei pacchetti persi in ogni stream, evitando che la perdita di un pacchetto in uno stream blocchi gli altri.

Gestione avanzata della congestione e correzione degli errori

• QUIC migliora la gestione delle connessioni in reti lente o poco affidabili usando codici di correzione degli errori anziché solo ritrasmettere pacchetti.
• In questo modo, piccoli errori vengono corretti senza sovraccaricare la rete, a differenza di TCP.
• L'identificativo di connessione consente la migrazione della connessione tra reti diverse, riducendo l'overhead necessario per stabilire nuove connessioni.

Efficienza della trasmissione e compressione in HTTP/3

• QUIC gestisce i flussi fuori ordine e introduce un nuovo protocollo di compressione adattato per l'ordine dinamico dei flussi.
• A differenza di HPACK (usato in HTTP/2), il nuovo metodo in HTTP/3 adatta la compressione ai flussi attivi, migliorando l'efficienza.

Multiplexing e sicurezza

• In HTTP/3, il multiplexing degli stream è gestito a livello di QUIC, che integra elementi di affidabilità e controllo della congestione di TCP e funzionalità di autenticazione e crittografia da TLS.
• QUIC semplifica la gestione di autenticazione e crittografia, integrando i meccanismi TLS come parte integrante del protocollo.

Prioritizzazione degli stream e interazione tra HTTP/3 e QUIC

• QUIC gestisce flussi multipli ma non implementa la prioritizzazione degli stream, che è lasciata ad HTTP/3.
• HTTP/3 comunica i dati di priorità a QUIC, mantenendo una stretta collaborazione tra i livelli.
• Questo approccio rompe in parte il tradizionale modello a livelli, ma è pensato per massimizzare l'efficienza.

Struttura del protocollo e mantenimento della semantica HTTP

• QUIC funziona a livello di trasporto su UDP, ma mantiene invariati il livello IP sottostante e la semantica dei messaggi HTTP.
• La logica semantica rimane la stessa sia di HTTP/1.1 che di HTTP/2, mentre a livello di trasporto QUIC introduce innovazioni per migliorare l'efficienza e la resilienza delle connessioni.