hosting: il successore di http 1.1 il perchè dell' http 2.0
TRANSCRIPT
Il successore del protocollo HTTP 1.1:
il perché dell’HTTP 2.0
La continua ricerca
della migliore esperienza utente
e della velocità Web
hanno portato al rilascio
dell’HTTP 2.0
#e-Commerce
Contenuti a cura di HostingTalk
Tutti gli utenti vogliono che il Web corra veloce,
così, oltre a migliorare la tecnologia delle connessioni Internet
e rendere più performanti i servizi di hosting,
ci sono molte altre questioni da affrontare e che,
al momento, rappresentano il collo di bottiglia della Internet moderna.
Uno di questi è l’attuale protocollo HTTP 1.1, che rappresenta il cuore della Rete.
La continua ed estenuante ricerca di un Web sempre più veloce
ha portato alla maturazione di un nuovo protocollo
indicato con il nome HTTP 2.0, ufficialmente rilasciato come bozza
e in attesa di approvazione da parte degli enti preposti (RFC)
Per diventare uno standard a tutti gli effetti.
Scopriamo come si è arrivati a questo nuovo
metodo di comunicazione Web.
A dare il via alla riscrittura dell’attuale HTTP 1.1 è stata Google,
che ha deciso di procedere con la stesura di un proprio protocollo
chiamato SPDY, che, sembra suggerire la parola speedy, rapido.
La lentezza del protocollo HTTP 1.1 è la limitazione principale
del protocollo stesso e SPDY l’ avrebbe dovuto battere proprio su questo punto.
L’obiettivo era rendere le comunicazioni fra browser client e server ancora più veloci.
I risultati ottenuti da questo nuovo protocollo (prontamente
integrato in browser come Chrome e in web server come Nginx)
spinsero la Internet Engineering Task Force (IETF) a usare SPDY
come base per la definizione dell’HTTP 2.0,
ormai pronto a proporsi come il prossimo standard del Web.
Le specifiche dell’HTTP 2.0 sono dunque definite e,
anche se esistono alcune differenze fra lo SPDY originale di Google
e l’attuale HTTP 2.0, in realtà Google stessa ha deciso
di interrompere lo sviluppo di SPDY,
e di abbracciare appieno il nuovo HTTP 2.0.
Per capire su cosa l’HTTP 2.0 è migliore rispetto alla precedente versione, facciamo un piccolo paragone tratto dalla vita quotidiana.
Un’analogia dalla vita quotidiana
Si pensi, per un attimo, a quando si va a fare la spesa e ci si ferma davanti al banco servito dei salumi. Ora si metta in conto di trovarsi in due diverse occasioni al banco affettati,
all’orario di punta e con una decina di persone in fila per attendere il proprio turno.
Nel primo caso, al banco c’è un solo salumiere con cinque affettatrici disponibili,
mentre nel secondo caso al medesimo banco ci sono cinque salumieri
e cinque affettatrici disponibili.
Non ci vuole un genio per capire in quale occasione ci si sbrigherà prima. Nel caso in cui cinque salumieri servano altrettante persone contemporaneamente, per il decimo cliente in fila, l’attesa sarà sicuramente inferiore.
Ciò che conta è che la diminuzione dell’attesa è funzionale all’ottimizzazione del servizio, per cui più sono i salumieri a disposizione, minore è il tempo che si dovrà attendere per essere serviti, anche all’orario di punta.
L’HTTP 1.1 come il salumiere di bottega, l’HTTP 2.0 come il grande ipermercato
Ora che ci si creda o no, l’analogia del salumiere funziona anche per il Web.
Il protocollo HTTP 1.1 risale a 25 anni fa ed è come se paragonassimo
il salumiere di fiducia di 25 anni fa nella sua piccola bottega
con i banchi salumi degli ipermercati moderni,
dove il personale composto da un numero maggiore di salumieri
serve contemporaneamente più clienti,
riducendone l’attesa.
La simultaneità nel servire le richieste è una peculiarità
che manca nel protocollo HTTP 1.1,
che non aveva questo tipo di necessità all’epoca del rilascio,
quando cioè i siti erano leggeri,
le connessioni lente, il traffico inferiore
e gli hardware computazionali dei server molto limitati.
Questo significa che oggi quando un client come il browser
richiede una pagina Web a un server,
ogni risorsa viene richiesta una alla volta
attraverso una singola connessione.
Come se dall’altra parte della Rete ci fosse un solo salumiere
che serve le diverse richieste singolarmente.
Il browser attende di ricevere ogni risposta alla sua richiesta, prima di poterne effettuare un’altra.
Per ovviare alla questione, i browser più moderni effettuano due connessioni alla volta al medesimo server, cercando di suddividere le richieste su ciascun canale e si passa così alla situazione in cui da un singolo salumiere se ne aggiungono altri pronti a servire.
Su ogni singola connessione, comunque,
il browser deve attendere che il server risponda,
prima di poter inoltrare una nuova richiesta.
Per quanto si possano quindi moltiplicare le connessioni, quindi,
resta comunque un barlume di inefficienza,
che si concretizza nell’attesa che il browser deve comunque
sopportare prima di poter inviare una nuova richiesta.
Poiché una pagina Web moderna ha più di 100 risorse al suo interno,
si capisce bene come vi sia una perdita di tempo notevole e, quindi,
un rallentamento di non poco conto.
La soluzione a questa impasse sta nel protocollo HTTP 2.0
Immaginiamo ora che ogni salumiere dei cinque su citati
sia capace di servire contemporaneamente più persone.
Questo è il metodo del multiplexing integrato nel protocollo HTTP 2.0.
Pur usando una singola connessione
(ma in realtà se ne potrebbero usare anche più di una),
con l’HTTP 2.0 il browser non deve attendere
che vi sia la risposta alla prima richiesta per poterne inviare una nuova.
In questo modo si ottengono diversi benefici:
• il browser non resta nulla facente nei periodi di attesa,
ma si occupa di renderizzare ogni risorsa della pagina
man a mano che questa si rende disponibile,
richiedendo di continuo le nuove risorse di cui ha necessità;
• si previene il problema del blocco head-of-line,
ossia della lunga attesa dovuta a una risorsa
che occupa molto tempo a essere servita dal server al client;
• si migliora l’efficienza di ogni singola connessione;
• si migliora la velocità di navigazione e quindi l’esperienza utente.
In realtà, anche se il discorso si è concentrato
sul concetto del multiplexing, le migliorie introdotte nell’HTTP 2.0
non si limitano solo a questo e sono molte.
In breve:
• introduzione della tecnologia Server Push.
che permette al server di fornire le risorse di una pagina
ancora prima che il client ne faccia richiesta;
• miglioramento della sicurezza:
il protocollo introduce l’opportunità di lavorare
con la sua controparte sicura HTTPS per migliorare
la sicurezza delle connessioni client-server;
• minimizzazione dell’handshake iniziale sul protocollo HTTPS;
• prioritizzazione dei contenuti;
• compressione opzionale degli haeder;
Poiché un’immagine vale più di mille parole
e un video vale più di un milione di immagini,
per capire cosa significa HTTP 2.0 all’atto pratico
nella vita di tutti i giorni è sufficiente guardare il seguente video
di un esperimento condotto in parallelo usando HTTP 1.1 e HTTP 2.0.
Come si può notare, cambiano drasticamente
i tempi di caricamento delle risorse, il Web si ottimizza e si velocizza, migliorando l’esperienza utente.
Anche se la notizia del protocollo HTTP 2.0 come bozza finale è recente,
i browser e alcuni Web server supportano il protocollo SPDY 3.1/HTTP 2.0 da qualche tempo.
Chrome e Firefox supportano questi protocolli ormai da tempo,
Apple ha aggiunto il supporto a SPDY nel 2014 con l’avvento di Safari 8,
mentre Internet Explorer lo supporta a partire dalla versione 11,
ma solo se il browser viene eseguito su Windows 8.
Dal punto di vista mobile, Google Chrome Mobile usa lo stesso codice
della versione Desktop, per cui i protocolli su citati sono già supportati,
mentre Apple ha aggiunto il supporto necessario al Safari iOS
a partire dalla versione 8 del sistema operativo mobile.
Riguardo i Web server, Nginx supporta perfettamente SPDY e ha già
pianificato il supporto a HTTP 2.0, mentre Apache supporta SPDY/HTTP 2.0
attraverso il modulo mod_spdy.
Le piattaforme online, come WordPress.com e CloudFlare
supportano già il protocollo HTTP 2.0.
