Nel 2012 è stata lanciata una richiesta per proporre nuove versioni del protocollo HTTP. Perché cambiarlo? Quando nel 1999 furono pubblicate le specifiche HTTP/1.1 i siti web erano composti di un po’ di testo, qualche immagine e, talvolta, un banner pubblicitario. Era tutto abbastanza semplice e le connessioni avvenivano attraverso un modem da 56k. Oggi tutto è cambiato, comprese le nostre aspettative: una pagina deve caricarsi istantaneamente, deve essere responsive e visualizzata perfettamente su qualsiasi dispositivo, facendo vivere un’esperienza di navigazione sempre piacevole. Inoltre, ci aspettiamo che il tutto funzioni anche su una connessione wireless o sullo schermo di uno smartphone, ovunque nel mondo. Forse un po’ troppo per qualcosa progettato quasi due decenni fa. I requisiti di HTTP/2 erano semplici: migliorare le prestazioni del protocollo pensando al modo in cui viene utilizzato oggi. Dopo tre anni e molte ore di lavoro, IETF ha approvato lo standard HTTP/2 e i principali browser oggi lo supportano. Chiunque utilizzi versioni aggiornate di Firefox o Chrome o usi Explorer su una delle prime release di Windows 10 probabilmente sfrutta HTTP/2 già da qualche mese senza rendersene conto. HTTP/2 ha un gran numero di nuove funzioni che permettono di gestire le attuali modalità di utilizzo del web. Esaminiamo le principali.
Multiplexing
Il multiplexing per HTTP è un mezzo per richiedere e ricevere più di un elemento web per volta ed è’ il rimedio al fenomeno dell’head-of-line blocking tipico della precedente versione.
HTTP/2 è un protocollo binary framed, ovvero le richieste e risposte sono spezzettate in frammenti denominati frame, contenenti meta informazioni che identificano a quale richiesta/risposta essi siano associati. Ciò consente la sovrapposizione di richieste e risposte per diversi oggetti sulla stessa connessione senza causare confusione, mentre i frame possono essere ricevuti in qualsivoglia ordine. Una prima richiesta, ad esempio, potrebbe richiedere più tempo per il completamento ma non determinerà ritardi nella consegna degli oggetti successivi. Ne consegue un caricamento e una visualizzazione più rapida della pagina.
Compressione dell’header
Gli header (ovvero le meta informazioni che il browser invia insieme con la richiesta per informare il server di ciò che desidera e che può accettare) furono aggiunti come componente di HTTP/1.1 e, in origine, non erano molto pesanti, ma con la recente crescita sia della diffusione sia della complessità, ora possono essere davvero grossi. A causa della natura neutrale dell’HTTP/1.1 il browser deve comunicare il supporto di un dato formato di file o linguaggio ad ogni richiesta, creando una gran quantità di byte ridondanti.
HTTP/2 aiuta a risolvere questo problema. Ricorrendo a una combinazione di tabelle di lookup e codifica Huffman, può ridurre fino a zero il numero di byte inviati con una richiesta. Nel corso di una sessione web media, tassi di compressione superiori al 90% non sono rari e per una tipica pagina web ciò non ha un grande impatto sulla risposta. Ma l’effetto è significativo invece per quanto riguarda la richiesta: per esempio, anche una pagina non molto ricca contenente 75 oggetti e con dimensioni dell’header di appena 500 byte potrebbe richiedere al browser 4 andate e ritorno TCP solo per richiedere un singolo oggetto. Con gli stessi parametri e una compressione del 90%, un browser può inviare tutte le richieste solo con una andata e ritorno.
Dipendenze e prioritizzazione
Multiplexing e compressione degli header fanno una differenza significativa, ma pongono anche una nuova sfida. Essendo piuttosto sofisticati, i browser hanno introdotto i pre-loader per essere certi di richiedere per primi gli elementi più importanti. I CSS, ad esempio, sono essenziali per definire la struttura della pagina, mentre un logo alla base della pagina non è così importante. Nel nuovo modello – in cui il browser richiede tutto allo stesso momento e consente al server di restituire gli oggetti il più velocemente possibile – vi sarà paradossalmente una riduzione nelle performance della pagina poiché, sebbene tutto possa essere globalmente più veloce, gli elementi importanti per il rendering della pagina non necessariamente arrivano al browser per primi. Anziché scaricare il problema sul browser, i progettisti hanno scelto di incorporare questa capacità nel protocollo. Comunicando al server quali oggetti dipendano da quali altri oggetti eseguendo le priorità il server può assicurare che i dati critici siano consegnati immediatamente al browser.
Server Push
Un modo per risolvere il problema della latenza dovuta all’andata e ritorno delle richieste/risposte HTTP consiste nel fare in mod che il server invii un oggetto al browser prima che sia richiesto. Qui è dove interviene il server push. Apparentemente il vantaggio è ovvio: consegna istantanea della pagina anche nelle peggiori condizioni. Ma, per consegnare l’oggetto giusto senza spreco di banda, il server deve potere immaginare quale sarà la prossima mossa dell’utente e quale sia lo stato della cache del browser. La questione è complicata e questo è il motivo per cui oggi non esistono applicazioni su larga scala della tecnologia push in protocolli di supporto come SPDY. Se HTTP/2 fornisce lo strumento per applicare il server push oggi, sono certo che negli anni a venire ne vedremo usi innovativi.
E per l’utente qualunque?
Nessuno dovrà modificare il proprio sito o le proprie app perché funzionino correttamente. Non solo il codice applicativo e le API HTTP continueranno a lavorare senza interruzioni, ma anche le applicazioni miglioreranno probabilmente le prestazioni consumando meno risorse sia sul client sia sul server.
Col diffondersi di HTTP/2 le organizzazioni che intendono beneficiare delle sue performance e funzioni di sicurezza dovrebbero iniziare a pensare a come sfruttare al massimo queste nuove funzionalità. Le considerazioni da fare dovrebbero essere:
- Crittografia: le applicazioni che girano sopra HTTP/2 avranno probabilmente miglioramenti delle prestazioni su connessioni sicure. Questa è una considerazione importante per la aziende che intendono passare a TLS.
- Ottimizzazione del layer TCP: le applicazioni dovrebbero essere disegnate implementando un layer TCP per gestire il passaggio da connessioni TCP multiple a una connessione singola e prolungata, in particolare nell’adattare la finestra di congestione in risposta alla perdita di pacchetti.
- Abbandonare le best practice HTTP/1.1: molte delle buone pratiche relative alle applicazioni distribuite su HTTP/1.1 (quali ad esempio domain sharing, image spriting, resource inlining e concatenazione) non solo sono inutili su HTTP/2, ma in alcuni casi possono in realtà ridurre le performance.
- Decidere cosa e quando spingere: le applicazioni progettate per sfruttare le nuove funzionalità di server push di HTTP/2 devono essere attentamente disegnate in modo da bilanciare prestazioni e utilità.
Vale quindi la pena di investire tempo ed energie nell’affrontare queste e altre sfide, come ad esempio ottimizzare in modo diverso le connessioni HTTP/1.1 o HTTP/2 nell’attesa che i browser e altri client completino gradualmente la transizione. Questo è, dopotutto, il futuro del web.
A cura di Michael Gooding, Web Performance Optimisation Evangelist, Akamai Technologies EMEA
