Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in RETI DI CALCOLATORI

Un’analisi del protocollo HTTP/2

Anno Accademico 2017-2018 Candidato: Nicola Esposito Matr. N46001980

Indice

Introduzione .................................................................................................... 2

1.1 Http e la sua collocazione nel modello di rete .......................................................... 2

1.2 Http/1.1 ..................................................................................................................... 3

1.3 Perché rinnovare HTTP/1.1 ....................................................................................... 7

1.4 Problemi noti............................................................................................................. 7

1.5 Da SPDY a HTTP/2 ..................................................................................................... 8

HTTP/2 .......................................................................................................... 10

2.1 I 5 propositi del nuovo protocollo ........................................................................... 10

2.2 Le novità introdotte ................................................................................................ 10

2.2.1 Compressione ............................................................................................. 11

2.2.2 Stream e Multiplexing ................................................................................. 13

2.2.3 Flow Controll ............................................................................................... 15

2.2.4 Stream priority e dipendenze ..................................................................... 15

2.2.5 Server Push ................................................................................................. 16

2.3 Connessione HTTP/2 ............................................................................................... 17

2.4 Supporto a HTTP/2 .................................................................................................. 19

Performance .................................................................................................. 20

3.1 Anti-Patterns ........................................................................................................... 20

3.2 Analisi delle prestazioni .......................................................................................... 21

3.3 Testing ..................................................................................................................... 26

3.3.1 Test 1 (www.tomshw.it).............................................................................. 25

3.3.2 Test 2 (www.ebay.it) ................................................................................... 26

3.3.3 Test 3 (www.facebook.com) ....................................................................... 27

HTTP/2: Limiti e Sicurezza .............................................................................. 29

4.1 TLS 1.3 ..................................................................................................................... 29

4.2 QUIC ........................................................................................................................ 29

4.3 Sicurezza .................................................................................................................. 30

4.4 Conclusioni .............................................................................................................. 32

Bibliografia .................................................................................................... 33

2

Introduzione

1.1 HTTP e la sua collocazione nel modello di rete

HTTP (Hypertext Transfer Protocol), definito in RFC 1945 e in RFC 2616, è

un protocollo a livello di applicazione del web. Questo protocollo, così come

tutti quelli a livello applicativo (es. SMTP, FTP, ecc...), sono distribuiti su più

sistemi periferici. Ad esempio, un’applicazione in un sistema periferico,

scambia messaggi con un altro sistema periferico tramite l’uso del protocollo.

Nel caso più semplice si ha un sistema periferico detto “Client” che richiede

informazioni o servizi al cosiddetto “Server”.

Figura 1: comunicazione Client/Server

Il protocollo HTTP definisce la struttura dei messaggi e la modalità con cui i

messaggi vengono scambiati. In particolare, se abbiamo un “browser web” lato

client e un “web server” lato server, HTTP va a definire in che modo il browser

richiede le pagine web al server.

Una pagina web è formata da oggetti, ovvero file, indirizzabili via URL. In

generale, si ha un file HTML base ed una serie di oggetti ad esso referenziati

non necessariamente presenti sullo stesso host. Quando un utente richiede una

pagina web, tramite il browser vengono inviate delle richieste HTTP al server,

il quale riceve le richieste, le elabora e invia messaggi di risposta HTTP

contenenti gli oggetti necessari. I client e i server inviano e ricevono i messaggi

tramite le proprie interfacce socket, affidando il trasporto al TCP, protocollo a

livello di trasporto utilizzato da HTTP, che fornisce un servizio di trasferimento

dati affidabile. Quando c’è uno scambio di messaggi, il client apre una

connessione TCP con il server ed entrambi accedono a TCP tramite le proprie

3

socket, avviando la comunicazione. Di conseguenza c’è un’interazione tra

livello applicativo e livello di trasporto: HTTP sfrutta i servizi di TCP senza

doversi preoccupare di come esso li implementi. Questo è frutto della cosiddetta

“Architettura a livelli”.

Il livello Applicativo è il primo di cinque livelli (o di sette se si considera il

modello di riferimento OSI) che costituiscono la pila di protocolli di Internet.

Organizzare i protocolli di rete tramite un’architettura a livelli, oltre a

semplificare la trattazione di una specifica parte di un sistema, introduce la

modularità. Ogni livello fornisce allo strato superiore, e richiede a quello

inferiore, un determinato servizio, quindi si ha la proprietà di accoppiamento:

ogni livello è accoppiato solo con quelli adiacenti. La modularità consente di

poter aggiornare e modificare i vari componenti in maniera del tutto

indipendente. Un livello di protocolli può essere implementato via software,

hardware o tramite combinazione dei due. I protocolli a livello applicativo, e

quindi soprattutto l’HTTP di interesse in questa trattazione, sono quasi sempre

implementati via software [5].

Figura 2: Pila dei protocolli Internet

1.2 HTTP/1.1

L’RFC 2068, che definiva lo sviluppo della versione 1.1 del protocollo

applicativo HTTP, fu pubblicato nel 1997, ad opera dello IETF (Internet

Engineering Task Force). Successivamente, nel 1999, fu pubblicato l’RFC 2616

che rese obsoleto l’RFC 2068. Nel 2014 è stata presentata un’ulteriore revisione

di questo protocollo, descritta nell’RFC 7230.

Come già accennato nel precedente paragrafo, una comunicazione HTTP

avviene tra client e server al fine di ottenere una serie di oggetti utili a

rappresentare una determinata risorsa, identificata tramite URI (Unified

4

Resource Identifier). Inoltre l’HTTP, al fine di soddisfare le richieste, consente

l’uso di “intermediari” e in base alla natura di ciascuna richiesta, un

intermediario può agire da server, proxy, gateway o tunnel.

Figura 3: Un esempio di messaggi HTTP

Si può notare un primo aspetto significativo: i messaggi HTTP sono in scritti in

testo ASCII, in modo tale che l’utente possa leggerli, e il numero di righe di un

messaggio è indefinito. Nella “Client request” si ha una prima riga detta “riga

di richiesta” mentre quelle successive sono dette “Righe di intestazione”.

La riga di richiesta presenta tre campi: Metodo (es: GET, HEAD, POST, PUT,

DELETE, TRACE, OPTIONS, CONNECT, PATCH), URL, Versione HTTP.

I campi delle righe di intestazione sono: User Agent (indica l’entità che sta

effettuando la richiesta), Host (indica l’host su cui si trova l’oggetto), Accept-

Language (indica in quale lingua l’utente vorrebbe ricevere la versione

dell’oggetto richiesto), Connection (indica se la connessione TCP va

mantenuta o chiusa).

Nel “Server Response” si ha una “riga di stato”, una serie di “righe di

intestazione” e il “corpo”. La riga di stato presenta tre campi:

1- Versione del protocollo

2- Codice di stato, di cui tra i più comuni:

a. 200 OK

b. 301 Moved Permanently

c. 400 Bad Request

d. 404 Not Found

e. 505 HTTP Version Not Supported

5

3- Messaggio di stato

Le righe di intestazione:

1- Date: ora e data di creazione della risposta HTTP

2- Server: indica che tipo di server ha generato la risposta

3- Last-Modified: ora e data in cui l’oggetto è stato creato o modificato

l’ultima volta

4- Content-Length: numero di Byte dell’oggetto inviato

5- Content-Type: indica di che tipo è l’oggetto del corpo

In un’interazione client/server è altamente probabile che i messaggi HTTP da

scambiare siano più di due e soprattutto la durata della comunicazione si svolga

in un lasso di tempo abbastanza lungo. Se client e server comunicano tramite

TCP, quindi se HTTP si affida al protocollo di trasporto TCP, bisogna scegliere

se rendere la connessione PERSISTENTE (request/response inviate tutte sulla

stessa connessione) o NON PERSISTENTE (request/response inviate su

connessioni separate).

La modalità di default di HTTP prevede l’uso di connessioni persistenti con

pipelining: una volta stabilita la connessione TCP tra client e server (tramite

handshake), il server può inviare l’intera pagina web (o più di una) sempre sulla

stessa connessione, la quale verrà chiusa dal server HTTP quando rimarrà

inattiva per un determinato lasso di tempo. Le richieste di oggetti da parte del

client possono essere fatte in sequenza, senza aspettare le risposte pendenti, e il

server risponde nella stessa modalità.

Per quanto riguarda una connessione non persistente, supponendo di voler

visualizzare una pagina web formata da un file HTML principale e 5 immagini,

per un totale quindi di 6 oggetti, l’intera operazione avrebbe un costo di 6

connessioni TCP totali e di 2 RTT (Round-Trip time) per ogni oggetto. In

particolare la richiesta di un solo oggetto prevede:

1- Inizializzazione della connessione TCP (prima fase dell’handshake

a tre vie)

2- Il server manda un piccolo segmento TCP per confermare (seconda

fase dell’handshake a tre vie) = 1 RTT

3- Richiesta del file (terza fase dell’handshake a tre vie)

6

4- Ricezione dell’oggetto (dopo un certo tempo di trasmissione del file)

= 1 RTT

In generale l’apertura di queste sei connessioni TCP avviene in serie ma alcuni

browser possono essere configurati (o lo sono già di default) per gestire

l’apertura di più connessioni in parallelo, ottenendo su ciascuna di esse l’oggetto

richiesto.

Tra le caratteristiche di HTTP/1.1 bisogna tener presente l’attività di “web

cache” e i “cookie” che, oltre a svolgere determinate funzionalità, cercano di

migliorare le prestazioni e personalizzare l’esperienza del web, aumentando

purtroppo la complessità e il peso delle intestazioni dei messaggi HTTP [5].

COOKIE: In generale si parla di HTTP come un protocollo privo di stato: la

semplice interazione client-server non prevede che il server mantenga

informazioni riguardanti il client e ciò è utile al fine di semplificare la

progettazione e non dare troppi oneri prestazionali al web server. Spesso però è

auspicabile che un web server tenga traccia dei propri client per motivi

commerciali, di sicurezza e per personalizzare i contenuti visualizzati.

L’utilizzo di questa tecnologia implica l’inserimento di un’ulteriore riga di

intestazione nei messaggi di richiesta e risposta HTTP, il mantenimento di un

file sul sistema dell’utente e di un database da parte del sito web.

WEB CACHING:

“Una web cache, nota anche come proxy server, è un’entità di rete che soddisfa richieste HTTP al posto del web server effettivo. Il proxy ha una propria memoria su disco (una cache) in cui conserva copie di oggetti recentemente richiesti. Il browser di un utente può essere configurato in modo che tutte le richieste HTTP dell’utente vengano innanzitutto dirette al proxy server”. (J.F.Kurose, K.W.Ross, Reti di Calcolatori

e Internet: un approccio top-down, Pearson, p.105)

L’utilizzo del web caching è utile al fine di ridurre il traffico di rete sul

collegamento di accesso ad internet ed inoltre fa sì che i tempi di risposta alle

richieste dei client siano minori. Il fatto che però una copia di un oggetto,

conservata in una web cache, possa essere scaduta, ha portato all’aggiunta di

un’ulteriore riga di intestazione detta “If-modified-since” e, se inclusa, il

messaggio HTTP è detto “messaggio di GET condizionale”.

7

1.3 Perché rinnovare HTTP/1.1: evoluzione della rete e delle esigenze degli

utenti

Da quando fu approvato nel 1999 il protocollo http/1.1, con l’avanzare degli

anni, il web ha subito un cambiamento radicale. Mentre in passato una pagina

web era complessivamente testuale, con una media di circa dieci oggetti e un

peso che era di pochi kilobytes, oggi lo scenario è totalmente differente: il peso

è nell’ordine dei megabytes e il numero degli oggetti è in media 140, basti

pensare ai moderni social network per esempio.

Oltre alla complessità del web sono aumentate in modo considerevole le

esigenze degli utenti. Stando ai dati forniti da Forrester Research (2009), mentre

verso la fine degli anni 90 gli utenti erano disposti ad aspettare più di 7 secondi

per il caricamento di una pagina web, oggi il 47% delle persone attende 2

secondi o meno, tendendo a non visitare più le pagine che richiedono 3 secondi

o più (le percentuali sono molto più basse per i siti di ecommerce). Stando ad

una ricerca più recente, effettuata ad opera di Google, l’utente medio tende a

“scoraggiarsi” per un ritardo di 400 ms, il tempo di un battito di ciglia.

Nonostante l’aumento della complessità del web e delle aspettative degli utenti,

l’http/1.1 è stato l’unico protocollo per il delivering dei contenuti web fino al

2015 [6].

1.4 Problemi noti

Il protocollo http/1.1 è stato largamente utilizzato per più di 15 anni, servendo

degnamente il Web. Tuttavia la necessità di un rinnovamento del noto

protocollo procede di pari passo con l’evoluzione della rete e soprattutto con

l’accrescere delle esigenze degli utenti.

La maggiore complessità delle pagine web, quindi l’aumento del numero degli

oggetti e delle attività interattive (che richiedono risposte in tempo reale,

immediato) hanno messo in luce alcune problematiche del protocollo http/1.1.

In particolare, l’http/1.1 presenta delle carenze nell’uso del livello di trasporto

sottostante, provocando complessivamente un effetto negativo sulle

performance applicative. Molte delle “best practise” riguardo le web

performance odierne sono state sviluppate proprio per risolvere alcune

mancanze di HTTP/1.1.

8

1- Mentre l’http/1.0 consentiva di avere una sola richiesta in sospeso su ogni

connessione TCP, l’http/1.1 ha introdotto la pipeline delle richieste, risolvendo

solo parzialmente però il problema della concorrenza delle richieste. Di

conseguenza, il client che deve effettuare un numero x di richieste, per evitare

problemi di concorrenza e ridurre la latenza, aprirà x connessioni verso il server

desiderato.

2- Http/1.1 non prevede un meccanismo per la compressione dell’intestazione.

Molto spesso l’intestazione risulta essere ripetitiva e più pesante del dovuto,

causando un traffico di rete non necessario e di conseguenza il riempimento

inutile della finestra di congestione del TCP.

3- È conosciuto come “head-of-line blocking” il problema che sorge ogni volta

che un browser, per ottenere una pagina web, deve richiedere più oggetti.

Generalmente, risulta abbastanza difficile che un browser debba ottenere un

singolo oggetto da un particolare host, mentre è altamente probabile che ne

debba richiedere più di uno. L’http/1.1 non ha alcun meccanismo per richiedere

gli oggetti simultaneamente e di conseguenza, pur implementando la pipeline

delle richieste, è costretta ad attendere le risposte una dopo l’altra nello stesso

ordine di invio delle richieste. Se una richiesta o una risposta ha un problema

allora il rendering della pagina verrà bloccato per far fronte a quel problema.

Alcuni browser, per risolvere tale problema, simulano una sorta di parallelismo

avviando dalle quattro alle otto connessioni verso l’host desiderato e inviando

una richiesta su ciascuna di queste connessioni [6].

1.5 Da SPDY a HTTP/2

L’idea che un protocollo differente da http/1.1 avrebbe causato una mole di

lavoro eccessiva per coordinare i cambiamenti tra server, intermediari, browser,

etc.., fece in modo di non dare risalto alle proposte di rinnovamento che si

susseguirono negli anni. La svolta, che ha aperto poi la strada all’entrata in

scena di http/2, è avvenuta nel 2009, quando Mike Belshe e Roberto Peon,

proposero un nuovo protocollo applicativo: SPDY. Lo scopo di SPDY era

quello di velocizzare il web, introducendo delle features per ridurre in modo

consistente il tempo di caricamento delle pagine. Tra le novità principali, SPDY

introdusse:

9

1) Compressione delle intestazioni di richiesta e risposta, riducendo quindi

l’uso della banda soprattutto quando le stesse intestazioni sono inviate più volte

per più richieste.

2) Multiplexing delle richieste su una singola connessione e prioritizzazione,

risparmiando così round trip tra client e server e evitando problemi di head-of-

line blocking.

3) Uso efficiente della banda non utilizzata, in quanto il server invia

attivamente risorse di cui il client necessiterà, ancor prima che quest’ultimo le

richieda (PUSH).

La messa in uso di SPDY non costrinse una modifica vera e propria dei server

poiché SPDY non sostituiva HTTP ma faceva da “tunnel” con i protocolli HTTP

e HTTPS. Infatti l’invio su SPDY fa sì che le richieste HTTP vengano elaborate,

tokenizate, semplificate e compresse. Per l’uso combinato con HTTPS, SPDY

necessitava dell’estensione TLS Next Protocol Negotiation (NPN).

SPDY è stato supportato velocemente da tutti i principali browsers (Chromium,

Mozilla Firefox, Opera, Internet Explorer, Safari), mettendo in evidenza la

necessità di cambiamento verso un protocollo più efficiente.

Nel 2012 fu dato il via alla realizzazione del nuovo protocollo http/2 usando

come base di partenza SPDY.

Nel Febbraio 2015 Google annunciò l’intenzione di abbandonare SPDY in

favore di HTTP/2.

Nel Maggio 2015 fu pubblicato l’RFC 7540 e di conseguenza l’entrata in scena

di HTTP/2 fu ufficiale.

Nel Febbraio 2016 Google annunciò ufficialmente che Chrome non avrebbe più

supportato SPDY e NPN [6].

10

HTTP/2

2.1 I cinque propositi del nuovo protocollo

Per rispondere alle esigenze di rinnovamento del protocollo HTTP, gli addetti

allo sviluppo di HTTP/2 (e di SPDY prima) hanno seguito questi cinque criteri:

1) Target a 50% reduction in page load time (PLT).

2) Avoid the need for any changes to content by website authors.

3) Minimize deployment complexity, avoid changes in network infrastructure.

4) Develop this new protocol in partnership with the open-source community.

5) Gather real performance data to (in)validate the experimental protocol. (I.Grigorik, High Performance Browser Networking, O’Reilly, 2015, 2.)

Il primo criterio, più significativo, è stato risolto introducendo il multiplexing

delle richieste e delle risposte, effettuando una compressione efficiente del

campo di intestazione del messaggio HTTP, aggiungendo il supporto per la

prioritizzazione delle richieste e per il pushing intelligente dei messaggi dal

server. Si dice che HTTP/2 è retro compatibile con HTTP/1.1: l’adozione di

http/2 non implica nessun cambio della semantica delle applicazioni web poiché

http/2 modifica la logica di basso livello ovvero la formattazione dei dati in

frame e come questi vengono trasportati da client a server (e viceversa). Di

conseguenza la modifica del protocollo è del tutto trasparente agli utenti [4].

2.2 Le novità introdotte

L’unità base del protocollo HTTP/2 è il frame, ovvero la più piccola entità di

comunicazione in una connessione HTTP/2, costituito da un’intestazione e da

una sequenza di ottetti a lunghezza variabile in base al tipo di frame. Ogni tipo

di frame ha uno scopo differente: ci sono, per esempio, i frame HEADERS e

DATA che sono i frame principali per i messaggi di richiesta e risposta. Inoltre

ad ogni frame è associato un identificatore univoco per ricostruire lo stream

originale nel caso in cui la trasmissione sia disordinata. I messaggi HTTP/1.1

sono codificati in ASCII e l’analisi comporta l’implementazione di un codice

più articolato, in quanto vanno letti tutti i bytes fino all’arrivo di un delimitatore

(una sorta di end of file) e inoltre questo tipo di analisi risulta più lento e

soggetto ad errori. I problemi relativi all’analisi dei messaggi di richiesta e

risposta in http/1.1 riguardano l’allocazione incerta delle memoria per effettuare

l’operazione e la limitazione nel trattare una sola richiesta (o risposta) per volta.

Il vantaggio nell’uso del framing è semplificare la lettura, l’analisi e la

11

composizione dei messaggi. Un protocollo che opera tramite frame consente al

ricevente di conoscere l’esatta dimensione del frame. In HTTP/2 ogni frame è

formato, nei primi 9 bytes, da un’intestazione che informa il ricevente di quanti

bytes è formato l’intero frame [6].

NOME ID DESCRIZIONE

DATA 0x0 Trasporta i dati principali in uno stream HEADERS 0x1 Contiene l’intestazione dei messaggi http e le priorità PRIORITY 0x2 Imposta o cambia la priorità e le dipendenze degli stream RST_STREAM 0x3 Consente ad un endpoint di chiudere uno stream SETTINGS 0x4 Imposta i parametri a livello di connessione PUSH_PROMISE 0x5 Avverte il client che il server sta per inviare qualcosa PING 0x6 Testa la connettività e misura il Round-Trip Time (RTT) GOAWAY 0x7 Avverte un endpoint che il peer non accetta altri stream WINDOWS_UPDATE 0x8 Imposta quanti byte un endpoint è disposto a ricevere CONTINUATION 0x9 Serve ad estendere un blocco HEADER

Tabella 1: tipi di frame

Figura 4: Suddivisione in frame di un messaggio a livello applicativo [4]

COMPRESSIONE - Le intestazioni dei messaggi HTTP/1.1 non sono

compresse, per cui le numerose richieste e risposte http sfruttano inutilmente la

banda trasportando informazioni ridondanti, a discapito della latenza.

GET / HTTP/1.1 Host: www.salvemini.na.it Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Upgrade-Insecure-Requests: 1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9, image/webp,image/apng,*/*;q=0.8 Accept-Encoding: gzip, deflate Accept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7

GET /start.php HTTP/1.1 Host: www.salvemini.na.it Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Upgrade-Insecure-Requests: 1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9, image/webp,image/apng,*/*;q=0.8 Accept-Encoding: gzip, deflate Accept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7

Figura 5: due messaggi HTTP/1.1, differiscono solo della stringa in grassetto

12

Con HTTP/2 è stato introdotto HPACK (Header Compression for HTTP/2),

ovvero un metodo di compressione che elimina le informazioni ridondanti delle

intestazioni e limita la vulnerabilità ad alcuni tipi di attacchi. HPACK è uno

schema di compressione che utilizza una lookup table basata sulla codifica di

Huffman. Si consideri questo esempio:

:authority: www.site.com :method: GET :path: / :scheme: https Accept: text/hmtl,application/xhtml+xml Accept-language: en-US,en;q=0.8 cookie: last_page=349A2F2IT upgrade-insecure-request: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

:authority: www.site.com :method: GET :path: /object.css :scheme: https Accept: text/hmtl,application/xhtml+xml Accept-language: en-US,en;q=0.8 cookie: last_page=638N1K9RN upgrade-insecure-request: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Figura 6: due pseudo-richieste http/2

In figura 6 la prima richiesta ha un peso di 251 bytes, la seconda di 261 bytes.

Le due richieste presentano le medesime informazioni, eccetto 19 bytes.

HPACK, concettualmente, fa in modo che vengano inviati soltanto quei 19

bytes. Nella realtà HPACK è più complicato, in generale esso è caratterizzato

da:

a- Due tabelle, possedute sia da client che da server e utilizzate per richieste e

risposte. Una tabella è statica, formata da 61 “header name” più usati con i

rispettivi valori; una è dinamica, formata da “header name” indicati dal

client in una richiesta specifica.

b- Una serie di controlli per controllare gli index degli elementi.

c- Usa la compressione dei valori INTEGER.

d- Sfrutta la tabella di codifica di Huffman per la compressione delle stringhe.

[10]

Figura 7: esempio di HPACK [4]

13

STREAM e MULTIPLEXING – Uno Stream è definito come un flusso

bidirezionale indipendente, contenente uno o più messaggi scambiati tra client

e server nell’ambito di una connessione HTTP/2. Uno stream serve una sola

coppia request/response. Le caratteristiche di uno stream sono:

1- In una singola connessione HTTP/2 possono viaggiare stream multipli in

input e output

2- Gli stream possono essere aperti e usati unilateralmente oppure condivisi sia

dal client che dal server.

3- Uno stream può essere chiuso da entrambi gli endpoint.

4- L’ordine di invio dei frame è importante: vengono elaborati nell’ordine in

cui sono ricevuti. In particolare l’ordine dei frame HEADERS e DATA è

semanticamente importante.

5- Agli stream viene assegnato un identificativo intero (unsigned integer) di 31

bit. Tale assegnazione è ad opera dell’endpoint che inizializza lo stream. Gli

stream inizializzati dal client devono usare identificativi con numeri dispari

(pari se inizializzati dal server). L’uso di un nuovo identificativo di stream

implica che tutti gli stream inattivi, con id inferiore a quello nuovo, vengano

chiusi. Gli identificativi non possono essere riutilizzati, se il range di

assegnazioni finisce (in una connessione lunga) allora il client può aprire

una nuova connessione per un nuovo stream oppure il server manda un

frame GOAWAY al client, forzandolo ad aprire una nuova connessione.

Figura 8: Ciclo di vita di uno stream [9]

14

In figura 8 è possibile vedere il diagramma a stati del ciclo di vita di uno stream,

il quale parte sempre da uno stato inattivo (“IDLE”). La transizione di stato

dello stream dallo stato inattivo può essere scatenata da tre eventi: la ricezione

o l’invio di un frame headers porta lo stream nello stato OPEN; l’invio di un

frame PUSH_PROMISE su un altro stream lo porta nello stato

RESERVED(local), ovvero viene riservato per un utilizzo successivo; la

ricezione di un frame PUSH_PROMISE fa sì che lo stream inattivo venga

riservato per un utilizzo successivo, portandolo nello stato

RESERVED(remote). Un frame PUSH_PROMISE non fa altro che riservare

uno stream inattivo associandolo ad un altro stream in stato OPEN, il quale è

stato inizializzato dal peer remoto. Lo stato RESERVED(local) può transitare

nello stato HALF-CLOSED(remote) se l’endpoint può inviare un frame headers

oppure nello stato CLOSED se lo stream invia un frame RST_STREAM. Si noti

che nella transizione appena citata un endpoint può inviare solo frame

HEADERS, RST_STREAM e PRIORITY: altri tipi di frame restituiranno

errore di connessione. Viceversa uno stream in stato RESERVED(remote) può

transitare nello stato HALF-CLOSED(local) o CLOSED. Lo stato HALF-

CLOSED indica che lo stream non sta più inviando o ricevendo frame. Uno

stream nello stato OPEN può essere usato da entrambi i peer per scambiare

frame di ogni tipo e può passare negli stati HALF-CLOSED (remote or local)

oppure nello stato CLOSED se uno degli endpoint invia o riceve il frame

RST_STREAM. Il numero di stream aperti contemporaneamente per un

endpoint può essere limitato impostando il valore desiderato in

SETTINGS_MAX_CONCURRENT_STREAMS, se si eccede quel valore si

avrà un PROTOCOL_ERROR o un REFUSED_STREAM [9].

Figura 9: Esempio stream per una richiesta GET

15

FLOW CONTROL – Dall’uso del multiplexing e degli stream segue il

problema della gestione della concorrenza nell’utilizzo della connessione TCP.

Http/2 consente di poter utilizzare più algoritmi di controllo del flusso e quindi

di gestire più stream su una stessa connessione senza che ci siano interferenze.

Il controllo del flusso viene regolato sempre dal ricevente tramite il frame

WINDOW_UPDATE e chi invia i dati ne deve rispettare i limiti . Si noti che

ogni intermediario, oltre agli endpoint principali, è inteso come ricevente e può

gestire indipendentemente il proprio controllo del flusso. Http/2 definisce

soltanto il formato e la semantica del frame WINDOW_UPDATE, non gli

algoritmi. Di default il limite di ottetti consentiti è impostato a 65,535 sia per

un nuovo stream che per tutta la connessione (stream flow-control window e

connection flow-control window). Si noti che gli unici frame soggetti a

controllo del flusso sono quelli DATA mentre tutti gli altri, che non consumano

eccessivamente la banda, possono transitare senza il rischio di essere bloccati

dal controllo del flusso. L’implementazione dell’ algoritmo è molto importante

e bisogna fare in modo che la lettura dal buffer della connessione TCP sia

tempestiva. La mancata lettura, in un intervallo di tempo molto breve, di frame

critici come WINDOW_UPDATE potrebbe portare a situazioni di deadlock [6].

STREAM PRIORITY e DIPENDENZE– Grazie al multiplexing di HTTP/2

un client può inviare tutte le richieste per delle risorse nello stesso momento e

il server, una volta ricevute, può processarle. Con l’introduzione della

prioritizzazione degli stream e la definizione delle loro dipendenze, un client

può ottenere prima gli oggetti più importanti, migliorando le performance,

soprattutto se il server ha capacità di invio limitate. Senza tale meccanismo, un

server invierebbe gli oggetti senza un criterio preciso, per cui oggetti meno

importanti potrebbero arrivare al client prima di alcuni più critici. Il client,

tramite i frame HEADERS e PRIORITY, può assegnare la priorità ad un nuovo

stream. Tale processo avviene dichiarando un “dependency tree” e il peso per

ciascuno stream. L’albero delle dipendenze consente di indicare al server la

“parentela” tra più stream e la relativa priorità. Il peso indica al server come

prioritizzare gli stream con dipendenze comuni e può assumere un valore da 1

a 256. Se per esempio un browser richiede ad un server una semplice pagina

16

web (tabella col.1) allora un esempio di albero delle dipendenze può essere

quello in col.2:

• index.html -sfondo.jpg -start.js -lab.css -log.js -zip.gif -banner_argo.png

• index.html -log.js -lab.css

-start.js -sfondo.jpg (weight 16) -zip.gif (weight 2) -banner_argo.png (weight 2)

Tabella 2: Esempio dependency-tree

SERVER PUSH – Un’ultima caratteristica peculiare di http/2 è il pushing degli

oggetti da parte del server. Quest’ultimo, potendo inviare messaggi multipli al

client, a fronte di una richiesta, oltre a fornire la risorsa desiderata, inoltra anche

oggetti non esplicitamente richiesti. Tali oggetti sono correlati alla richiesta

originaria del client e il server li invia in previsione di una probabile richiesta

successiva. Questa funzione consente ad esempio di ridurre i tempi di

caricamento di una pagina e di sfruttare a pieno la banda a disposizione.

Ovviamente il pushing degli oggetti è una funzionalità tanto importante quanto

delicata, sia per questioni di sicurezza sia perché bisogna far attenzione a non

degradare le prestazioni, ciò l’esatto contrario di quello che è lo scopo del

“Server Push”. Il processo di scelta per quale oggetto inviare deve tenere conto:

della probabilità che l’oggetto sia già nella cache del client, della priorità che il

client attribuisce all’oggetto e della larghezza di banda disponibile per poter

effettivamente ricevere l’oggetto. Quando il server vuole fare il pushing di un

oggetto usa il frame PUSH_PROMISE.

Figura 10: Push Promise Frame [6]

Lo “Stream ID” (31 bit) nell’intestazione del frame in figura 10 indica lo Stream

ID della richiesta a cui è associata la risposta. Il campo “Header Block

Fragment” (7 byte) contiene ciò che il client invierebbe al server se chiedesse

lui stesso l’oggetto normalmente. Quest’ultimo campo svolge una funzione di

17

sicurezza e dà potere al client di verificare cosa sta ricevendo. La pseudo-

intestazione di questo frame deve contenere un metodo considerabile sicuro,

ovvero deve essere un metodo che non è capace di cambiare lo stato (GET per

esempio è un metodo sicuro). Inoltre un client dovrebbe ricevere i frame

PUSH_PROMISE prima dei frame DATA che fanno (o potrebbero far)

riferimento all’oggetto da inviare tramite pushing. Infatti se arrivano prima tutti

i frame DATA e poi il frame PUSH_PROMISE, il client potrebbe nel frattempo

aver già fatto richiesta per quell’oggetto. Un requisito importante è che l’oggetto

che viene inviato deve essere memorizzabile nella cache. Ogni problema, che

può conseguire a oggetti già presenti nella cache o con metodi non sicuri o altro,

viene gestito dal client resettando lo stream con RST_STREAM oppure

inviando un PROTOCOL_ERROR tramite il frame GOAWAY [6].

Figura 11: Server Push

Figura 12: Richiesta di un file html e relativi oggetti senza Server Push (sinistra) e con Server Push (destra)

2.3 Connessione HTTP/2

Passare ad http/2 richiederà ancora alcuni anni poiché tutti i server e gli

intermediari devono essere aggiornati per utilizzare il nuovo protocollo e i

relativi meccanismi, mentre i client devono aggiornare le librerie e i browser.

18

Per quanto riguarda i browser, il supporto al nuovo protocollo è stato quasi

immediato. La coesistenza di http/1.1 e HTTP/2 richiede che, in una normale

comunicazione, client e server siano in grado di capire e negoziare quale

protocollo utilizzare. HTTP/2 prevede più meccanismi per capire quale

protocollo supporta l’endpoint che si sta contattando. Si noti innanzitutto che il

protocollo HTTP/2 richiede ALPN (Application-Layer Protocol Negotiation),

ovvero un’estensione di TLS (Transport Layer Security) che consente di

negoziare quale protocollo deve essere usato per una connessione sicura.

HTTP/2 possiede due identificativi: ‘h2c’ quando usa una connessione TCP non

criptata, quindi senza TLS, oppure ‘h2’ quando utilizza TLS. Nel momento in

cui un client vuole effettuare una richiesta per un URI ‘http’ senza TLS e senza

una preliminare conoscenza del supporto di http/2 da parte del server, utilizza il

meccanismo di UPGRADE HTTP. In particolare il client invia una richiesta

http/1.1 con un campo nell’ intestazione per l’aggiornamento della connessione

a http/2 (Figura 13 – passaggio 1). Se il server non supporta http2 allora

risponderà normalmente alla richiesta ignorando il campo di Upgrade (Figura

13 – passaggio 2). Se il server supporta connessioni http/2 allora accetterà la

richiesta di upgrade rispondendo con uno “Switching Protocols Response 101”

(Figura 13 – passaggio 3) e iniziando l’invio dei frame [9].

Figura 13: Esempio Upgrade Mechanism

Stesso discorso se si vuole negoziare una connessione http/2 sicura con TLS e

ALPN, basta utilizzare l’identificativo di protocollo “h2”. Del resto la maggior

parte dei browser abilita http/2 solo utilizzando connessioni sicure.

19

Un altro sistema per esplicitare il supporto al protocollo http/2 si basa su servizi

alternativi (http Alt-Svc) supportati dai browser: il server indica al client,

nell’intestazione della risposta, che nelle comunicazioni future si potrebbe usare

“un sistema più efficiente”, evitando in tal modo un round-trip di troppo per la

contrattazione del protocollo.

L’ultima caratteristica della connessione HTTP/2 è un’ulteriore conferma del

supporto da parte del client al server. Il client, dopo aver effettuato l’HTTP

UPGRADE, come primo dato sulla connessione, invia un ottetto che in

esadecimale è: 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a.

Decodificando l’ottetto in ASCII si ottiene: PRI * http/2.0\r\n\r\nSM\r\n\r\n.

Lo scopo di questa stringa è scatenare intenzionalmente un errore nel caso in

cui il server o un qualsiasi intermediario non è capace di supportare la

comunicazione tramite http/2. Il messaggio che il client invia ha le sembianze

di un messaggio http/1.1 e il server che lo riceve (si supponga che non supporti

http/2) si bloccherà sul metodo “PRI” o sulla versione “http/2.0”, restituendo

errore. La stringa PRI * http/2.0\r\n\r\nSM\r\n\r\n viene immediatamente

seguita da un frame SETTINGS: il server conferma la sua capacità di supportare

http/2, riceve i parametri della connessione dal client (tramite il frame

SETTINGS), risponde con un altro frame SETTINGS e la connessione HTTP/2

può avere inizio [6].

2.4 Supporto a HTTP/2

Figura 14: supporto a HTTP/2 by "caniuse.com/#search=http2"

Ad oggi (Dicembre 2017) il 77,37% dei browser offre pieno supporto ad http/2

su TLS e con negoziazione via ALPN. Il 5,81% dei browser offre supporto

parziale (limitato dai sistemi operativi). In definitiva si ha l’83,18% di supporto

a livello globale (Figura 14).

20

Performance

3.1 Anti-Patterns

Come già osservato in precedenza, alcuni pattern definiti per ottimizzare il

protocollo http/1.1 risultano essere invece degli “anti-pattern” per http/2.

1) Domain Sharding: sfrutta le funzionalità dei browsers per aprire più

connessioni in parallelo, rendendo possibile inviare più richieste in parallelo

e utilizzare maggiormente la banda disponibile. Quindi questo pattern

consente di sopperire ai problemi dovuti alla natura sequenziale di http/1.1.

Poiché http/2 fa già uso del multiplexing questo pattern risulta essere inutile.

La funzionalità di “Connection Coalescing” ha la capacità di rimuovere il

problema dello “Sharding” sotto certe condizioni.

2) Spriting: è una tecnica per evitare tante richieste per piccoli oggetti. Se per

esempio si devono ricevere molte immagini, esse vengono poste tutte in

una sola grande immagine e tramite CSS viene scelta quale porzione di

immagine mostrare in un determinato punto. Con http/2 lo Spriting risulta

conveniente o meno a seconda delle circostanze [7].

3) Inlining: è un ulteriore metodo per evitare eccessivi RTT e connessioni per

singoli oggetti e consiste nell’incorporare l’URL dell’oggetto nel file CSS

o anche nell’HTML.

4) Concatenating: unisce molti piccoli file in un unico file più grande (simile

al concetto di Inlining) e si usa, per esempio, quando in un sito ci sono molti

file javascript.

5) Cookie-less Domains: una delle tecniche maggiormente usate per

ottimizzare un sito web è quella di offrire contenuti statici (CSS, javascript,

immagini, ecc..) tramite un cookie-less domain, ovvero un dominio che non

utilizza cookies. Questa tecnica è utile con http/1.1 poiché non è prevista la

compressione dell’header e a volte alcuni siti web utilizzano cookies che

vanno oltre la misura del pacchetto TCP. Con il protocollo http/2 invece si

ha la compressione dell’header, come già visto in precedenza, quindi

l’utilizzo o meno dei cookies non è eccessivamente rilevante.

21

6) Prefetch: è un’ottimizzazione che, tramite un link tag nell’HTML, dice al

browser di scaricare oggetti nella cache ogni volta che ciò è possibile

(es.<link rel =” prefetch” href =” /file.css”>). Questo meccanismo è

superfluo con http/2 e l’uso del “Push Promise” [6].

3.2 Analisi delle prestazioni

Definito il nuovo protocollo, quanto sono migliorate le prestazioni rispetto a

http/1.1? Sono effettivamente migliorate?

Prima di esporre alcuni dei numerosi studi effettuati sulle performance di http/2

bisogna tenere in conto alcuni aspetti:

• Le performance possono variare a seconda del browser scelto.

• Meccanismi quali Push Promise e Multiplexing non incidono su studi

relativi all’analisi di SINGOLE richieste ma su gruppi di richieste.

Un interessante studio sull’impatto di http/2 e le sue prestazioni è stato

effettuato dall’ Akamai’s Foundry Team monitorando una grande mole di dati

provenienti da dispositivi reali e sotto diverse condizioni di rete. I risultati hanno

evidenziato differenze sostanziali tra i vari browsers e in molti casi hanno

registrato una maggiore velocità di http/2 rispetto al suo predecessore. In

particolare, con http/2, quasi il 24% di URLs hanno incrementato le loro

performance utilizzando Google Chrome, più del 18% utilizzando Firefox e più

del 9% utilizzando Chrome Mobile. I risultati però hanno mostrato anche che

una percentuale, inferiore, di URLs hanno subito peggioramenti in prestazioni

adottando http/2 (più del 7% con Google Chrome, più del 5% con Chrome

Mobile e circa l’1% con Firefox). Il motivo della variabilità dei risultati è dovuta

al fatto che, come già detto a inizio paragrafo, http/2 svolge il suo lavoro al

meglio su gruppi e non su singole richieste [6].

LATENZA - Mike Belshe, in uno studio del 2010, descrive come larghezza di

banda e RTT influenzano le performance del web. In particolare, come si vede

nelle figure 15 e 16, Mike Belshe ha affermato che aumentare la banda non

porta sempre ad un aumento delle prestazioni mentre diminuire il RTT aiuta

sempre a rendere più veloce il PLT (Page Load Time) [1].

22

Figura 15: (sx) diminuzione della latenza all'aumentare della banda, (dx) diminuzione percentuale della

latenza [1]

Figura 16: PLT al variare del RTT

In definitiva, la scelta migliore è quella di diminuire il NUMERO di round trip

in una connessione: uno degli obiettivi di http/2. Confrontando numerosi test,

si può notare che se si aumenta la distanza fra due endpoint, quindi si aumenta

la latenza, le prestazioni di http/2 sono migliori rispetto a quelle di http/1.1.

Figura 17: a sinistra [HTTP/2, 0s latency], a destra [HTTP/1.1, 0s latency] by http2.golang.org

23

Figura 18: a sinistra [HTTP/2, 200ms latency], a destra [HTTP/1.1, 200ms latency] by http2.golang.org

PERDITA DI PACCHETTI – Tale fenomeno si ha quando un pacchetto non

raggiunge la sua destinazione, spesso a causa della congestione della rete. Uno

studio dell’Università del Montana e dell’Akamai Foundry ha analizzato

l’effetto della perdita di pacchetti su siti web contenenti tanti piccoli oggetti

oppure pochi oggetti di dimensione maggiore. Dallo studio [3] è emerso che il

PLT con http/2, rispetto che con http/1.1, è più veloce quando il sito web

contiene tanti piccoli oggetti. I risultati sono i seguenti:

1) Pagine web contenenti tanti piccoli oggetti:

a. PLT (Page Load Time) con http/2 più veloce che con http/1.1. Si

noti infatti che ciò è dovuto al multiplexing di http/2 su una singola

connessione contro le sei connessioni in parallelo di http/1.1.

b. All’aumentare della congestione della rete aumenta il PLT in

entrambi i casi (gli effetti sono più evidenti su connessioni http/2, a

causa dell’architettura a singola connessione).

2) Pagine web contenenti pochi grandi oggetti:

a. Le prestazioni di http/1.1 sono nettamente superiori a quelle di http/2

a causa della finestra di controllo di congestione iniziale. Http/1.1,

avendo a disposizione 6 connessioni aperte in parallelo, ha una

finestra di congestione iniziale sei volte maggiore di quella di http/2.

Di conseguenza http/1.1 può iniziare a ricevere i dati molto più

24

velocemente mentre con http/2 bisogna aspettare che la finestra di

controllo di congestione raggiunga le dimensioni ottimali.

b. Le prestazioni di http/1.1 e http/2 sono pressoché uguali se si hanno

pochi oggetti ma molto grandi.

Time to First Byte – Questo parametro, che misura il grado di reattività del

web server, assume un significato diverso se applicato al protocollo http/1.1 o a

http/2 a causa della diversità di funzionamento.

Il carico di lavoro che il protocollo http/2 richiede, per offrire tutte le

funzionalità presentate precedentemente, è abbastanza oneroso:

1) Costruzione dell’albero delle dipendenze

2) Compressione e decompressione degli header

3) Creazione e mantenimento delle tabelle statiche e dinamiche per gli header

4) Gestione delle priorità

5) Server Push e quindi scelta degli stream da inviare

6) Gestione della finestra di flusso

Un client http/2 invia un maggior numero di richieste simultanee al server

(grazie al multiplexing) ottenendo risposta in maniera più veloce rispetto ad

http/1.1. Il problema sta nel fatto che tutte le attività inziali sopraelencate

andranno a ritardare l’inizio dell’invio delle richieste, facendo risultare nei test

una reattività maggiore per http/1.1. Quest’ultimo richiede un oggetto alla volta

per ogni connessione e il server risponde inviando ogni oggetto in ordine ed in

sequenza [6].

25

3.3 Testing

Di seguito si riportano tre test effettuati tramite la versione online di webpagetest, un web performance tool sviluppato e supportato da Google e GitHub. Webpagetest utilizza browser reali per accedere alle pagine web e raccogliere dati da fornire all’utente. TEST 1 - www.tomshw.it

Luogo Server: Milano, Italia

Connessione: Simulated, Cable (5/1 Mbps 28ms RTT)

Browser: Chrome, Desktop

Numero di test: 3 per ogni protocollo

Figura 19: Visually Complete www.tomshw.it

Figura 20: Visual Progress (%)

Figura 21: parametri a confronto

26

Figura 22: ottimizzazioni attive

TEST 2 – www.ebay.it

Luogo Server: Milano, Italia

Connessione: Simulated, Cable (5/1 Mbps 28ms RTT) e LTE (12 Mbps/12

Mbps 70ms RTT)

Browser: Chrome, Desktop

Numero di test: 3 per ogni protocollo e tipo di connessione

Figura 23: Visually complete "www.ebay.it"

Figura 24: Visual progress (%) "www.ebay.it"

27

Figura 25: parametri a confronto

Figura 26: valutazione ottimizzazioni: a sinistra [ebay.it LTE], a destra [ebay.it CABLE]

TEST 3 - www.facebook.com

Luogo Server: Milano (Italia) vs Virginia (USA)

Connessione: Simulated, LTE (12 Mbps/12 Mbps 70ms RTT)

Browser: Chrome, Desktop

Numero di test: 6 per ogni protocollo e locazione

Figura 27: Visually complete

28

Figura 28: Visual progress (%)

Figura 29: Parametri a confronto

Figura 30: gradi di ottimizzazione

29

HTTP/2: limiti e sicurezza

Nei capitoli precedenti si è visto come il protocollo applicativo http/2 sia

effettivamente limitato dal protocollo di trasporto TCP:

1) Problema del TCP head-of-line blocking.

2) Avvio lento e congestion avoidance.

3) Più RT per negoziazione TLS

4.1 TLS 1.3

Nel Luglio 2017 è stato pubblicato l’RFC di TLS 1.3 il quale fa in modo di

ridurre il numero di RT da 3 a 1 per l’apertura di una connessione (mentre si

hanno 0 RT per connessioni riutilizzate).

Figura 31: TLS 1.2 vs TLS 1.3, by blog.cloudflare.com/introducing-tls-1-3/

4.2 QUIC

La soluzione offerta da Google, è QUIC, un protocollo di trasporto che

combina la velocità di UDP e l’affidabilità di TCP. QUIC implementa il

proprio livello di sicurezza senza far uso di TLS 1.2 e quindi ha la capacità di

aprire una connessione, negoziando i parametri di sicurezza, con 1 o 2

pacchetti. Inoltre viene risolto il problema del TCP HOL Blocking [2].

Figura 32: QUIC nel modello di rete (Sinistra); Risoluzione del TCP HOL Blocking (Destra) [2]

30

4.3 Sicurezza

Stando ai dati forniti da w3techs.com, l’uso di http/2 sul web è del 23.2%

(Gennaio 2018), di cui una buona percentuale è formata da siti web molto

diffusi come Facebook, Twitter, Google. La percentuale di diffusione è in

continua crescita anche grazie al fatto che molti siti web si affidano a CDN

come Akamai, Cloud Flare e Incapsula. Una diffusione del protocollo su larga

scala e su siti che raggiungono milioni di utenti richiede una certa attenzione

alla sicurezza da attacchi hacker.

Uno studio [11] sulla sicurezza di http/2, effettuato sulle piattaforme Server

Web più diffuse (Apache, IIS, Ngnix e nghttp), ha evidenziato quattro

vulnerabilità:

1) Stream Multiplexing abuse: sfrutta il riuso (vietato) di un identificativo di

stream chiuso per provocare un arresto anomalo del server (figura 34).

2) Slow Read: un client richiede risorse consistenti al server, impostando la

WINDOW_UPDATE con un parametro molto basso costringendo il server a

trasmettere molto lentamente. Tale sistema viene esteso a più stream,

rendendo il server incapace di servire altri client (figura 35).

3) Dependency Cycle attack: sfrutta il fatto che la dimensione dei

dependency-tree non è limitata e crea un ciclo di dipendenza infinito

(figura 36).

4) HPACK Bomb: messaggi apparentemente innocui esplodono in gigabyte di

dati sul server, saturando le risorse di memoria e portando il server offline

(figura 37).

Figura 33: Vulnerabilità registrate per cinque implementazioni server [11]

31

Figura 34: Stream Reuse attack diagram IIS (sinistra), HTTP.sys BSOD (destra) [11]

Figura 35: Apache/IIS Slow GET attack [11]

Figura 36: Dependency cycle (sinistra), nghttp DC stream 3 e 7 nello stesso indirizzo di memoria (destra) [11]

Figura 37: HPACK BOMB [11]

32

4.4 Conclusioni

I protocolli del web vivono un periodo di rapide sperimentazioni e

implementazioni per cui si suppone che non trascorreranno altri venti anni per

avere una nuova versione di http. Http/2 è un protocollo giovane il cui impatto

in ambito di sicurezza e performance va ancora del tutto verificato e

perfezionato.

Il futuro vedrà senza dubbio l’entrata in scena di HTTP/3 e le sue basi si

fonderanno su HTTP/2 e QUIC per ottenere un protocollo ancora più veloce,

sicuro, affidabile e capace di adattarsi ad ogni condizione di rete.

“Get out there and start using h2, push the boundaries, break things, learn – and when

you are done, share. That is where HTTP/3 will come from” [6].

33

Bibliografia

[1] M.Belshe, More Bandwidth Doesn’t Matter (Much), in

www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much, 4 Maggio

2010

[2] M.Geniar, Google's QUIC protocol: moving the web from TCP to UDP, in

www.ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/ , 4 Dicembre

2016

[3] U.Goel, M.Steiner, M.P.Wittie, M.Flack, S.Ludin, HTTP/2 Performance in

Cellular Networks, in

www.akamai.com/kr/ko/multimedia/documents/technical-publication/http2-

performance-in-cellular-networks.pdf

[4] I.Grigorik, High Performance Browser Networking, O’Reilly, Settembre 2013

[5] J.F.Kurose, K.W.Ross, Reti di Calcolatori e Internet: un approccio top-down,

Pearson

[6] S.Ludin, J.Garza, Learning HTTP/2: a pratical guide for beginners, O’Reilly,

2017

[7] D.Stenberg, http2 Explained

[8] RFC 7230: Hypertext Transfer Protocol Version 1.1 (HTTP/1.1), in

https://tools.ietf.org/html/rfc7230

[9] RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2).

https://tools.ietf.org/html/rfc7540

[10] RFC 7541: HPACK: Header Compression for HTTP/2.

https://tools.ietf.org/html/rfc7541

[11] Imperva, HTTP/2: In-depth analysis of the top four flaws of the next

generation web, in: www.imperva.com/docs/Imperva_HII_HTTP2.pdf