Capita spesso che ci siano cose ben progettate, fatte per durare.
Direi che il protocollo HTTP è uno di questi
Posizionato al livello 7 dello stack OSI nasce negli anni 90 (1989 prima versione non pubblica) con la versione 1.0.
Nel 1997 e 1999 il protocollo viene aggiornato alla versione HTTP 1.1 , e poi di fatto lo abbiamo iper-sfruttato fino a (quasi) oggi.
per 15 anni è andato bene, ce lo siamo fatti andare bene, ma qualcuno che sul protocollo HTTP basava il proprio business , Google, decise di rivedere i limiti di questo “vecchietto”.
In effetti i limiti c’erano, ed erano emersi per lo più grazie ai nuovi contenuti, ai nuovi dispositivi, ai nuovi servizi, alla richiesta di velocità e latenza bassi.
Basti pensare che ogni oggetto di una pagina web (immagini, testo, stili, codice client) equivale ad una connessione HTTP (->e quindi una connessione TCP completa) , questo implica:
- overehead client/server per informazioni ridondanti ad ogni connessione
- impossibilità di comprimere gli header
- raggiungimento di limiti sul numero di connessioni contemporanee client/server , tipicamente 10, l’undicesima aspetta…
- le richieste (e le risposte) sono sequenziali e senza possibilità di prioritizzazione
- il testo viene trasferito riga per riga
- comunicazione in un senso solo (no push)
Naturalmente si è cercato di aggirare questi limiti senza inventare un nuovo modo di comunicare tra client e server, per esempio:
- inlining / minify / oneliner
- embedding
- multiple domains (images. , cms. ,static. ,www.)
- Google Pagespeed
- gzip & caching
- CDN
… ma forse andava riscritto il protocollo.
- Nel 2009 Google inizia lo sviluppo di SPDY un protocollo per aggirare i limiti imposti da HTTP 1.0 e HTTP 1.1
- Nel 2011 tutti i servizi Google usavano già SPDY
- Nel 2012 era possibile installarlo autonomamente su qualsiasi webserver Apache HTTP Server e nginx
- Luglio 2012 il codice di SPDY viene donato per farlo evolvere e farlo diventare di fatto lo standard HTTP/2 (httpbis)
- E’ diventato standard a metà del 2015 (rfc7540)
- Oggi praticamente tutti i browser supportano SPDY 3.1(+) e HTTP2
- A fine 2018 si parla già di HTTP/3 (HTTP-Over-Quic) ma questa è un’altra storia…
Ma vediamo un pò nel dettaglio cosa cambia:
Stream, messaggi, frame
- Il flusso(stream) è un canale virtuale all’interno di un collegamento, che porta messaggi bidirezionali. Ogni flusso ha un identificatore unico intero (1, 2, …, N)
- Il messaggio è un messaggio HTTP logico, come una richiesta o una risposta, consiste di uno o più frame
- Il frame è la più piccola unità di comunicazione che trasporta un tipo specifico di dati, HTTP headers, payload, e così via
HTTPS
obbligatorio
01010101010111110101010110…
E’ completamente binario! (base64)
1 sito -> 1 connessione -> migliaia di oggetti
HTTP/2 introduce il multiplexing, che permette al collegamento TCP/IP di richiedere e ricevere più risorse, intrecciate.
Le richieste non saranno piu in linea e quindi non si bloccheranno una con l’altra…., quindi non c’è bisogno di più connessioni TCP su più nomi di dominio. (images.sito.it, css.sito.it, cms.sito.it….)
Header compressi (HPACK)
cookies e http header compressi!
meno traffico , meno overhead, più velocità!
PUSH!
immaginate nella prima visita di un browser (www.sito.it) di poter fare push di alcuni contenuti verso il client prima che il contenuto della pagina sia caricato o addirittura di comandare il caricamento di alcuni contenuti senza una GET…
Il Server ha un maggior controllo sul client!
Priorità
il server può prioritizzare alcune richieste in modo che arrivino al client prima di altre
Che cosa invece non cambia?
STATI
200,301,403,404,500… rimangono tutti come in HTTP1.1
METODI
GET, POST, HEAD… rimangono tutti come in HTTP1.1
Questa immagine spiega abbastanza bene la differenza tra HTTP1.1 e HTTP/2
Ormai qualsiasi browser in circolazione da almeno 3 anni supporta HTTP/2, tuttavia c’è ancora poca diffusione e conoscenza del protocollo.
Lo state già usando, per esempio per leggere questo articolo!
