HTTP 2 Le - Futur - Protocole - de Transfert de L'avenir

HTTP/2 : LE FUTUR PROTOCOLE DE TRANSFERT DU WEB ?
Kewin Dousse
Projet de Bachelor
Filière Informatique
Haute Ecole d’Ingénierie et d’Architecture de Fribourg
Fribourg, Suisse
Version 1.0
c 2016 Kewin Dousse

Superviseurs : Rudolf Scheurer, François Buntschu

Expert : Pierre-André Roubaty
Résumé
HTTP 1.1 est resté pendant longtemps le protocole de transfert le plus utilisé
pour le web. Les applications web d’aujourd’hui recherchent la performance sans
cesse, et HTTP/2 est une réponse à ce besoin. Ce projet analyse le protocole
HTTP/2, puis décrit la conception et l’implémentation d’un outil démonstratif de
ses nouveautés et termine par analyser ses performances observées.
Keywords. HTTP2, Web, Protocol
Table des matières
1 Introduction 9
1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Analyse 12
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Principes de base . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Fonctionnement des frames . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Streams et multiplexage . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Priorisation et dépendance . . . . . . . . . . . . . . . . . . . 15
2.4 Types de frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.3 PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.4 RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.5 SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.6 PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.7 PING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.8 GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.9 WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . 24
2.4.10 CONTINUATION . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 HPACK : Compression des headers . . . . . . . . . . . . . . . . . . 25
2.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.2 Principe de base . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.3 Représentation . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 PUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7 Utilisation du protocole . . . . . . . . . . . . . . . . . . . . . . . . 30
2.7.1 Première connexion . . . . . . . . . . . . . . . . . . . . . . . 30
3
TABLE DES MATIÈRES TABLE DES MATIÈRES
2.7.2 Connexions futures . . . . . . . . . . . . . . . . . . . . . . . 30
3 Conception 31
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Idée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.2 But de l’outil . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 Téléchargement de la page web . . . . . . . . . . . . . . . . 32
3.3.2 Mise en place sur le serveur . . . . . . . . . . . . . . . . . . 32
3.3.3 Benchmark de la page . . . . . . . . . . . . . . . . . . . . . 33
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Réalisation 36
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.1 Choix du client . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 Serveur HTTP . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.2 Téléchargement de la page web . . . . . . . . . . . . . . . . 39
4.3.3 Copie et ajustements . . . . . . . . . . . . . . . . . . . . . . 39
4.3.4 Configuration automatique de PUSH . . . . . . . . . . . . . 41
4.3.5 Page de benchmark . . . . . . . . . . . . . . . . . . . . . . . 42
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5 Validation 46
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Test du Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.1 Correspondance des pages téléchargées . . . . . . . . . . . . 47
5.2.2 Conformité des protocoles . . . . . . . . . . . . . . . . . . . 49
5.2.3 HTTP 1.1 sur le port 8081 . . . . . . . . . . . . . . . . . . . 49
5.2.4 HTTP/2 sur le port 8082 . . . . . . . . . . . . . . . . . . . . 50
5.2.5 HTTP/2 avec PUSH sur le port 8083 . . . . . . . . . . . . . 50
5.3 Test des Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6 Résultats 54
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2 Exécutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4
6.2.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.2 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7 Conclusion 60
7.1 Conclusion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.1.1 Délivrables . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.1.2 Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . 60
7.1.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2 Conclusion personnelle . . . . . . . . . . . . . . . . . . . . . . . . . 61
A Historique des versions 68
B Cahier des charges 69

B.1 Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
B.2 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
B.3 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . 70
C Documentation 72
C.1 Localisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
C.2 Contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
C.2.1 Forge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
C.2.2 DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
D Code source 73
D.1 README.md . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
D.2 copyExample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
D.3 downloadSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
D.4 clearSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
D.5 setDelay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
D.6 app/.htaccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
D.7 app/index.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
D.8 app/downloadSite.php . . . . . . . . . . . . . . . . . . . . . . . . . 81
D.9 app/compareSite.php . . . . . . . . . . . . . . . . . . . . . . . . . . 83
D.10 app/delay.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
D.11 example/.htaccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
D.12 example/index.html . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
D.13 example2/.htaccess . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
D.14 example2/index.html . . . . . . . . . . . . . . . . . . . . . . . . . . 92
E Résultats complets 94
5
F Procès-verbaux 95
6
Table des figures
1.1 Schéma classique de l’affichage d’une page web avec HTTP 1.1. . . 10
1.2 Evolution du transfert nécessaire pour une page web entre le 15 mai
2011 et 2016[4]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Format de l’en-tête des frames. . . . . . . . . . . . . . . . . . . . . 14

2.2 Une connexion HTTP/2 transmettant des frames de plusieurs streams. 15
2.3 Exemple de dépendance : Stream 3 et Stream 1 dépendent de Stream 2. 16
2.4 Un exemple arbre de dépendances avec poids pour chaque stream. . 17
2.5 Format des frames DATA. . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Format des frames HEADERS. . . . . . . . . . . . . . . . . . . . . 19
2.7 Format des frames PUSH_PROMISE. . . . . . . . . . . . . . . . . 22
2.8 Format des frames CONTINUATION. . . . . . . . . . . . . . . . . 25
2.9 Un Header List est composé de plusieurs Header Fields, eux-même
composés d’un nom et d’une valeur. . . . . . . . . . . . . . . . . . . 26
2.10 Encodage et décodage d’un Header List . . . . . . . . . . . . . . . . 26
2.11 L’Index Address Space, constitué de la Static Table et de la Dynamic
Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.12 Quelques champs de la Static Table. . . . . . . . . . . . . . . . . . 27
2.13 Quelques caractères et leur représentation encodée . . . . . . . . . . 28
2.14 Comparaison du transfert d’une page index.html référençant un
fichier style.css. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Téléchargement initial de la page d’un site d’exemple, et copie dans

les 3 serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Accès du client aux copies de la page . . . . . . . . . . . . . . . . . 34
4.1 Chacun des 4 Virtual Host est accessibles par un port différent. . . 38
4.2 Vue de la page d’accueil de l’application . . . . . . . . . . . . . . . 39
4.3 Vue de la page de téléchargement . . . . . . . . . . . . . . . . . . . 40
4.4 Vue de la page de benchmarks, en cours de test du domaine google.ch. 42
4.5 Script setDelay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7
TABLE DES FIGURES TABLE DES FIGURES
5.1 Test de validation sur la page twitter.com. . . . . . . . . . . . . . 47

5.2 Test de validation sur la page heia-fr.ch. . . . . . . . . . . . . . 47
5.3 Affichage du haut de la page originale . . . . . . . . . . . . . . . . . 48
5.4 Affichage du haut de la page copiée . . . . . . . . . . . . . . . . . . 48
5.5 Test de validation sur la page github.com. . . . . . . . . . . . . . 48
5.6 Aperçu de la page de test ’example2’ . . . . . . . . . . . . . . . . . 49
5.7 Trafic réseau pour la page de test ’example2’ servie en HTTP 1.1 . 49
5.8 Trafic réseau pour la page de test ’example2’ servie en HTTP/2 . . 50
5.9 Trafic réseau pour la page de test ’example2’ servie en HTTP/2
avec PUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.10 Résultats du benchmark de la page ’example2’ sur 50 tests, avec
500ms de latence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.11 Résultats du WebPageTest de la page ’example2’ en HTTP 1.1, avec
500ms de latence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.12 Résultats du WebPageTest de la page ’example2’ en HTTP/2, avec
500ms de latence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.13 Résultats du WebPageTest de la page ’example2’ en HTTP/2 +
PUSH, avec 500ms de latence . . . . . . . . . . . . . . . . . . . . . 52
6.1 Chargement de la page d’exemple 1, contenant 400 petites images. . 55

6.2 Temps moyen de chargement pour les pages testées . . . . . . . . . 56
6.3 Résumé des variations de temps de chargement nécessaire . . . . . . 57
6.4 Moyenne des temps de chargement pour chaque situation . . . . . . 58
6.5 Variation de la moyenne du temps de chargement en fonction de la
modification de protocole effectuée . . . . . . . . . . . . . . . . . . 59
E.1 Résultats de l’exécution de 5 tests avec 3 valeurs de latence diffé-

rente sur une quinzaine de sites web. Les temps sont exprimés en
millisecondes [ms]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8
Chapitre 1
Introduction
1.1 Contexte
HTTP est l’abréviation de "HyperText Transfer Protocol ", ou "Protocole de
transfert hypertexte" en français. Il s’agit d’un protocole de communication, utilisé
entre un serveur et un client pour transférer des données. Ce protocole est un des
piliers du fonctionnement du web actuel. La première version standardisée de ce
protocole, nommée HTTP 1.0, date de 1996[1]. Depuis, une version actualisée de
ce protocole a vu le jour sous le nom de HTTP 1.1 en 1997[2].
Voilà maintenant presque vingt ans que la version 1.1 du protocole existe, et elle
reste celle sur laquelle repose la plupart des communications du web d’aujourd’hui.
Durant cette période, le fonctionnement général de ces communications sur le web
n’a donc pas changé, mais son utilisation a explosé ; le trafic Internet mondial
augmente de manière exponentielle depuis maintenant quinze ans.
Bien que tout le trafic ne soit pas du HTTP, nous nous rendons bien compte
de l’évolution fulgurante de l’utilisation de ces technologies. HTTP est principale-
ment utilisé pour transférer des données d’un site web à un utilisateur. L’affichage
complet d’une page web se fait petit à petit. La figure 1.1 montre un schéma d’une
connexion classique à une page web, divisée en différentes étapes :
1. L’utilisateur demande au navigateur d’accéder à la page d’accueil du site
web.
2. Le navigateur demande le code HTML de la page d’accueil au serveur
concerné.
3. Le serveur donne au navigateur le code HTML de la page, qui va être lu et
compris. Ici, la page désire afficher une image et nécessite un autre fichier
de script.
4. Le navigateur envoie une demande par fichier supplémentaire nécessaire.
9
1.1. CONTEXTE CHAPITRE 1. INTRODUCTION
5. Le serveur répond avec le contenu de chaque fichier demandé.

6. Le navigateur indique que le chargement de la page est terminé.
Serveur
Client
Navigateur web
Utilisateur
1 2
3
6
index.html
4
5
image.png
4
5
script.js
Figure 1.1 – Schéma classique de l’affichage d’une page web avec HTTP 1.1.
Tous ces transferts sur le réseau nécessitent du temps et de la bande passante ;

Ceci va se traduire en attente pour l’utilisateur. Lorsque les conditions le per-
mettent, ce temps d’attente est suffisamment court pour ne pas être dérangeant,
mais cela n’est pas toujours le cas. Les sites web sont devenus plus complexes, plus
interactifs avec le temps, et nécessitent de plus en plus de ressources, réparties
dans un nombre grandissant de fichiers différents. La figure 1.2 montre l’évolution
sur les 5 dernières années du nombre de requêtes nécessaires à l’affichage d’une
seule page web, ainsi que la taille totale des fichiers transférés. On peut voir que
non seulement le nombre de fichiers nécessaires a augmenté d’environ 25%, mais
la taille totale de ces transferts a triplé !
Les utilisateurs désirent à la fois de plus en plus de contenu, et des temps
d’attente moindres ! Il est temps de chercher des solutions à ces demandes.
L’année passée, HTTP/2, un nouveau protocole de transport successeur de
HTTP 1.1, a été standardisé . Des implémentations client et serveur de ce nouveau
protocole existent déjà à l’heure actuelle, et sont prêtes à être utilisées. Il est
donc temps de s’intéresser de plus près à cette nouvelle technologie, qui permettra
de combler plusieurs lacunes de HTTP 1.1 afin d’améliorer les performances des
transferts.
10
CHAPITRE 1. INTRODUCTION 1.2. OBJECTIFS
Figure 1.2 – Evolution du transfert nécessaire pour une page web entre le 15 mai
2011 et 2016[4].
HTTP/2 va conserver une partie du protocole HTTP 1.1 afin de ne pas casser
la compatibilité avec les applications web existantes. En effet ; la partie de haut
niveau, visible par les applications, restera inchangée : Par exemple les méthodes,
les codes de statut, l’interprétation des URIs ou la signification des en-têtes ne
change pas. Les différences de HTTP/2 résident principalement dans la manière
dont ces informations sont représentées et sont échangées sur le réseau. Le but
de ce projet va donc être de se pencher sur le fonctionnement, les contraintes, les
améliorations apportées et les performances de HTTP/2.
1.2 Objectifs
À la fin du projet, nous serons en possession :
— D’une étude du fonctionnement du protocole HTTP/2.
— D’un comparatif de HTTP/2 avec ses alternatives.
— D’une analyse des contraintes de HTTP/2 par rapport à HTTP 1.1 : Quels
sont les changements nécessaires à faire dans la configuration actuelle des
serveurs.
— De statistiques sur les améliorations et les performances de HTTP/2 ainsi
que d’outils permettant de les mesurer.
11
Chapitre 2
Analyse
2.1 Introduction
HTTP/2 a été développé sur la base d’un autre protocole de transfert expé-
rimental. Celui-ci se nomme SPDY et a été développé principalement par Google
depuis environ 2010. Son but était déjà de réduire le temps de chargement des pages
web en se servant de plusieurs techniques comme la compression, le multiplexage
et la priorisation de ressources.
Les résultats concluants de SPDY ont poussé les discussions vers la rédaction
d’un nouveau standard, qui allait se nommer HTTP/2. Le développement s’est
ainsi peu à peu tourné vers HTTP/2, reprenant les bases de SPDY tout en y
apportant des modifications et améliorations.
2.1.1 Principes de base

Différences clés HTTP/2 se démarque de HTTP 1.1 par plusieurs différences
clés
— est binaire au lieu de textuelle
— est multiplexée et utilise plusieurs streams
— utilise une seule connexion par domaine
— compresse ses headers
— autorise le serveur à "push" des ressources sans demande préalable du client
Tout comme HTTP 1.1, HTTP/2 fonctionne en utilisant le protocole TCP.
De plus, toute la sémantique de HTTP 1.1 est conservée : Les modifications de
HTTP/2 ne surviennent pas dans la manière dont le protocole doit être utilisé,
mais plutôt dans son implémentation et dans la manière dont il représente les
données durant leur transfert sur le réseau. Cela lui donne la caractéristique d’être
compatible avec toute application utilisant HTTP 1.1 et désirant passer à HTTP/2
12
CHAPITRE 2. ANALYSE 2.2. FONCTIONNEMENT DES FRAMES
afin de profiter des améliorations de performances, sans avoir à adapter la logique

de l’application : Son utilisation est identique.
Techniques utilisées HTTP/2 tente de tirer profit de plusieurs concepts pour

améliorer les performances de HTTP 1.1 de multiples manières. Nous pouvons
rassembler ces innovations en 3 techniques principales :
1. La compression des headers HTTP, par le format HPACK.
2. L’utilisation d’une seule connexion TCP par domaine, comprenant plusieurs
streams multiplexés.
3. L’envoi prématuré de ressources depuis serveur, tentant de prédire les pro-
chaines requêtes du client, appelé "PUSH".
Alors que les deux premiers points sont des composants essentiels au fonction-
nement de HTTP/2, le dernier point est optionnel. Il peut s’agit d’un considérable
gain de performances supplémentaire, mais il est à configurer précautionneusement
par le responsable du serveur.
2.2 Fonctionnement des frames

2.2.1 Principe
Les données du protocole transitent sur le réseau sous la forme de "frames" ;
une "frame" représente un message HTTP/2. Il existe un total de 10 types de
frames différentes. Chaque type de frame sert à transmettre certaines informations
spécifiques : Par exemple, le type HEADERS va contenir des headers HTTP, et
le type DATA va servir à transporter le contenu effectif d’une requête ou d’une
réponse HTTP.
2.2.2 Format
Chaque type de frame utilise un format prédéfini. Leur en-tête est identique :
Elles utilisent toutes un header fixe de 9 octets. La figure 2.1 décrit cette structure.
Length Taille du contenu utile de la frame, sans compter 9 octets de ce header.

Représenté par un entier non signé de 24 bits. Les valeurs standard sont comprises
entre 0 et 16384 (214 ).
Type Type de la frame. Représenté par un entier non signé de 8 bits. Doit
correspondre à un des types définis.
13
2.3. STREAMS CHAPITRE 2. ANALYSE
0 7 8 15 16 23 24 31
Length Type
Flags R Stream ID
Stream ID
Frame payload
❤❤❤❤
❤❤❤❤❤❤❤❤❤❤
❤
❤❤❤❤ ❤❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤
❤❤❤❤❤
❤
Figure 2.1 – Format de l’en-tête des frames.
Flags Flags de la frame, utilisé par certains types spécifiques. Doit être laissé à
0 lorsque non utilisé.
R Bit réservé. Doit être laissé à 0.
Stream ID Numéro d’identification du stream. Représenté par un entier non

signé de 31 bits. La valeur 0 est réservée pour une frame concernant l’ensemble
des streams.
Frame payload Contenu utile de la frame.
2.3 Streams
2.3.1 Streams et multiplexage
HTTP 1.1 ouvrait une connexion TCP par fichier demandé, jusqu’à 6 connexions
sur le même serveur. Ces 6 connexions étaient ensuite réutilisées pour transférer les
prochains fichiers : Ceci a pour effet de limiter le nombre de transferts concurrents
par serveur à 6 fichiers.
Contrairement à HTTP 1.1, HTTP/2 n’ouvre qu’une seule connexion TCP par
serveur contacté, peu importe le nombre de ressources à demander sur ce serveur.
Le but est à présent de transférer toutes les requêtes et les réponses à travers cette
seule connexion. Pour y parvenir, HTTP/2 utilise plusieurs streams multiplexés.
14
CHAPITRE 2. ANALYSE 2.3. STREAMS
Un stream représente un flux de données (typiquement, un stream par fichier),

et le terme "multiplexé" signifie que des informations transitent dans les deux sens.
En effet, des frames circulent dans les deux sens de cette connexion.
Serveur
Client
Stream 2 Stream 2 Stream 2 Stream 5
HEADERS DATA DATA HEADERS
Stream 3 Stream 4
HEADERS DATA
Figure 2.2 – Une connexion HTTP/2 transmettant des frames de plusieurs

streams.
La figure 2.2 illustre une connexion HTTP/2 entre un client et un serveur. On

peut y voir que des frames circulent dans les deux sens de la connexion, et que
chaque frame peut concerner un stream différent.
Chaque stream porte un numéro d’identification unique par connexion. Rap-
pelons que les streams sont multiplexés, ce qui signifie que des frames peuvent
circuler dans les deux sens pour un même identificateur, et représentent donc des
informations spécifiques à ce stream. À noter qu’il existe un numéro d’identifi-
cateur spécial, le numéro 0 : Ce numéro sert à faire passer des informations qui
concernent la connexion elle-même, ou qui concerne l’ensemble des autres streams.
2.3.2 Priorisation et dépendance

Contrairement à HTTP 1.1, HTTP/2 offre la possibilité de définir une priorité
à chaque ressource, autrement dit à chaque stream. Par exemple, un navigateur
peut vouloir afficher en premier les images du haut de la page, et retarder l’af-
fichage des images du bas de la page. Ou encore, lorsqu’un site web a besoin de
plusieurs fichiers JavaScript, certaines fonctionnalités peuvent être dépendantes
d’autres fichiers. Il est donc important de charger les fichiers nécessaires en pre-
mier.
La priorisation de chaque stream dépend de deux paramètres, dans l’ordre
décroissant d’importance :
1. Sa dépendance
2. Son poids
Il est possible d’assigner ces deux valeurs à chacun des streams.
15
2.3. STREAMS CHAPITRE 2. ANALYSE
Dépendance
La figure 2.3 illustre principe de la dépendance des streams, et montre que

plusieurs streams peuvent dépendre d’un autre. À noter qu’il n’est pas possible
d’exprimer qu’un stream dépend de plusieurs streams différents.
Stream 2
Stream 1 Stream 3
Figure 2.3 – Exemple de dépendance : Stream 3 et Stream 1 dépendent de Stream

2.
À partir de ceci, il est donc possible de créer une structure en forme d’arbre
de dépendance des streams. Ceci signifie que les streams à la racine de l’arbre (en
haut) sont les plus importants à transmettre et seront transmis en priorité, alors
que les streams proches des feuilles (en bas) seront transmis plus tard.
Poids
Chaque dépendance peut se voir assigner un poids. Le poids est une valeur
entière entre 1 et 256. Ce poids va déterminer l’importance de ce stream particulier,
par rapport aux autres ayant la même dépendance. Le poids d’un stream qui serait
le seul a dépendre d’un autre n’aurait donc aucun effet, car ces poids n’ont de
signification que par rapport aux autres.
La figure 2.4 montre un arbre de dépendance avec un poids assigné à chacune
d’entre-elles. Nous pouvons en retirer les informations suivantes :
— Les streams 1, 3 et 4 dépendent du stream 2.
— Le stream 5 dépend du stream 2.
— Le stream 4 a deux fois plus de poids que le stream 1, qui a lui-même deux
fois plus de poids que le stream 3.
— Le poids de 12 du stream 5 n’a aucun effet, car il s’agit du seul stream
dépendant du stream 4.
16
CHAPITRE 2. ANALYSE 2.4. TYPES DE FRAMES
Stream 2
4 2 8
Stream 1 Stream 3 Stream 4
12
Stream 5
Figure 2.4 – Un exemple arbre de dépendances avec poids pour chaque stream.
Mécanisme facultatif
Notons que la priorisation des streams n’est qu’une demande du client au ser-
veur : Ceci ne force pas le serveur à adopter un tel comportement. Il ne s’agit que
d’une recommandation ; Le serveur peut très bien décider de ne pas écouter cette
recommandation et ignorer totalement la dépendance et les poids des streams.
2.4 Types de frames

L’information du type de la frame est contenu dans le champ Type en un entier
non signé de 8 bits. Dix valeurs particulières représentent les 10 types de frames
possibles. Parmi ces dix types, nous allons voir la structure de quatre d’entre eux :
Les types DATA, HEADER, PUSH_PROMISE et CONTINUATION, car il s’agit
des types qui servent à transmettre des données effectives d’une application. Les
six autres types de frames ne transmettent que des informations "internes" au
fonctionnement du protocole.
Nous allons donc passer en revue l’utilité de ces dix types de frames, et nous dé-
taillerons plus précisément la structure des types DATA, HEADER, PUSH_PROMISE
et CONTINUATION.
17
2.4. TYPES DE FRAMES CHAPITRE 2. ANALYSE
2.4.1 DATA
La frame de type DATA va servir
La frame de type DATA, représentée à la figure 2.5 possède la valeur de Type
0x0 et utilise deux flags :
END_STREAM (bit 0) Lorsque activé, signifie que cette frame est la der-
nière frame de DATA du stream.
PADDED (bit 3) Lorsque activé, signifie que cette frame peut contenir du
padding, et indique la présence du champ Pad Length.
0 7 8 15 16 23 24 31
Pad Length
Data
❤❤❤
❤
❤❤❤ ❤❤❤❤❤❤
❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤
❤❤❤❤ ❤
❤❤
Padding
❤❤❤❤
❤❤❤ ❤❤❤❤❤❤
❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤
❤❤❤❤ ❤
❤❤
Figure 2.5 – Format des frames DATA.
On y trouve jusqu’à 3 champs différents :
Pad Length Taille du champ Padding. Présent uniquement si le flag PADDED

est activé. Représenté par un entier non signé indiquant le nombre d’octets.
Data Données utiles à l’application.
Padding Octets de remplissage. Doivent être tous 0. Ne peut être présent que
si Pad length est présent et supérieur à 0.
18
2.4.2 HEADERS
La frame de type HEADERS, représentée à la figure 2.6 possède la valeur de
Type 0x1 et utilise quatre flags :
END_STREAM (bit 0) Lorsque activé, signifie que ce header block est le
dernier qui va être envoyé pour ce stream.
END_HEADERS (bit 2) Lorsque activé, signifie que cette frame contient
un header block complet, et ne va pas être suivie par des frames CONTI-
NUATION.
PRIORITY (bit 5) Lorsque activé, signifie que cette frame contient les champs
E, Stream Dep. et Weight.
0 7 8 15 16 23 24 31
Pad Length E Stream Dep.

Stream Dep. Weight
Header Block Fragment
❤❤❤❤
❤❤❤❤❤❤❤❤❤❤
❤
❤❤❤❤ ❤❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤
❤❤❤❤❤
❤
Padding
❤❤❤❤
❤❤❤❤❤❤❤❤❤❤
❤
❤❤❤ ❤
❤❤❤❤❤❤❤❤❤❤
❤❤❤ ❤
❤❤❤❤❤❤❤❤❤❤
❤❤ ❤ ❤
❤❤❤❤❤❤❤❤❤
❤❤❤❤❤
❤
Figure 2.6 – Format des frames HEADERS.

19
E Indique si la dépendance du stream est exclusive. Présent uniquement si le flag

PRIORITY est activé.
Stream Dep. Identificateur du stream sur lequel ce stream dépend. Présent

uniquement si le flag PRIORITY est activé.
Weight Poids de la priorisation de ce stream. Représenté par un entier non signé

entre 0 et 255, on y ajoute 1 pour obtenir le poids du stream, qui a une valeur
finale entre 1 et 256. Présent uniquement si le flag PRIORITY est activé.
Header Block Fragment Un Header Block Fragment. Décrit à la section 2.5.
20
2.4.3 PRIORITY
La frame de type PRIORITY possède la valeur de Type 0x2, et n’utilise aucun
flag.
Cette frame contient 3 champs différents :
E Indique si la dépendance du stream est exclusive.
Stream Dep. Identificateur du stream sur lequel ce stream dépend.
Weight Poids de la priorisation de ce stream. Représenté par un entier non signé

entre 0 et 255, on y ajoute 1 pour obtenir le poids du stream, qui a une valeur
finale entre 1 et 256.
2.4.4 RST_STREAM
La frame de type RST_STREAM possède la valeur de Type 0x3, et n’utilise
aucun flag.
Elle ne contient qu’un seul champ :
Error Code Code identificateur de l’erreur survenue.
2.4.5 SETTINGS
La frame de type SETTINGS possède la valeur de Type 0x4, et utilise un flag :
ACK (bit 0) Lorsque activé, signifie que l’envoyeur acquitte la réception et
l’application des règles d’une précédente frame SETTINGS reçue. Lorsque
activé, cette frame doit avoir un contenu vide.
Elle contient une succession de deux champs :
Identifier Identificateur d’un paramètre.
Value Valeur assignée au paramètre.
21
2.4.6 PUSH_PROMISE
La frame de type PUSH_PROMISE, représentée à la figure 2.7 possède la
valeur de Type 0x5 et utilise deux flags :
END_HEADERS (bit 2) Lorsque activé, signifie que cette frame contient
un header block complet, et ne va pas être suivie par des frames CONTI-
NUATION.
0 7 8 15 16 23 24 31
Pad Length R Promised Stream ID

Promised Stream ID

❤❤❤❤
❤❤❤❤❤❤❤❤❤❤
❤
❤❤❤❤ ❤❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤
❤❤❤❤❤
❤
Padding
❤❤❤❤
❤❤❤❤❤❤❤❤❤❤
❤
❤❤❤❤ ❤❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤
❤❤❤❤❤
❤
Figure 2.7 – Format des frames PUSH_PROMISE.

R Bit réservé.
Promised Stream ID Identificateur du stream réservé par la promesse.
22
23
2.4.7 PING
La frame de type PING possède la valeur de Type 0x6, et utilise un flag :
ACK (bit 0) Lorsque activé, signifie que l’envoyeur acquitte la réception d’une
première frame PING ayant un flag ACK désactivé.
Opaque Data 8 octets de valeurs quelconques.
2.4.8 GOAWAY
La frame de type GOAWAY possède la valeur de Type 0x7, et n’utilise aucun
flag.
Elle contient 4 champs :
R Bit réservé.
Last-Stream-ID Identificateur du stream ayant le numéro le plus élevé que

l’envoyeur a connaissance.
Error Code Code identificateur de l’éventuelle erreur survenue.
Additional Debug Data Informations supplémentaires pouvant aider au diag-

nostic de l’éventuelle erreur survenue.
2.4.9 WINDOW_UPDATE
La frame de type WINDOW_UPDATE possède la valeur de Type 0x8, et
n’utilise aucun flag.
Elle contient 2 champs :
R Bit réservé.
Last-Stream-ID Nombre d’octets supplémentaires que l’interlocuteur peut en-

voyer.
24
CHAPITRE 2. ANALYSE 2.5. HPACK : COMPRESSION DES HEADERS
2.4.10 CONTINUATION
La frame de type CONTINUATION possède la valeur de Type 0x9, et utilise
1 flag :
END_HEADERS (bit 2) Lorsque activé, signifie que cette frame termine
un header block, et ne va donc pas être suivie par d’autres frames CONTI-
NUATION.
0 7 8 15 16 23 24 31

❤❤❤❤
❤❤❤ ❤❤❤❤❤❤
❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤❤
❤❤❤❤ ❤
❤❤❤ ❤❤❤❤❤
❤❤❤❤ ❤
❤❤
Figure 2.8 – Format des frames CONTINUATION.
2.5 HPACK : Compression des headers

2.5.1 Introduction
Un problème apparent de HTTP 1.1 survient lorsqu’une page web demande
de nombreuses ressources, ce qui est très fréquent de nos jours. En effet, lorsque
des requêtes sont émises pour plusieurs ressources d’un même domaine, on verra
transiter les quasi mêmes headers répétés pour chaque requête et chaque réponse.
Ceci est une utilisation inefficace de la bande passante qui nous est à disposition,
et le standard HPACK propose une solution à ce problème en :
1. Compressant les informations des headers
2. Ne retransmettant pas les informations redondantes (déjà connues grâce à
une autre requête)
HPACK est le nom du format de compression utilisé pour réduire la taille des
headers HTTP dans le protocole HTTP/2. Un "header" complet est en fait une
liste ordrée appelée Header List, composée de paires nom-valeur appelées Header
Fields. La figure 2.9 montre un schéma de cette structure. Cette liste peut contenir
des paires dupliquées.
25
2.5. HPACK : COMPRESSION DES HEADERS CHAPITRE 2. ANALYSE
Nom Valeur
connection keep-alive


Header Field{ :path /index.html




:method GET Header List
referer http ://www.heia-fr.ch




... ...

Figure 2.9 – Un Header List est composé de plusieurs Header Fields, eux-même
composés d’un nom et d’une valeur.
2.5.2 Principe de base

Les Header Field sont compressés avant leur envoi, et décompressés à leur
réception. Le processus de compression est donc évidemment réversible, et sans
perte d’information. La figure 2.10 schématise ce procédé.
Header List
↓ Encodage
Header Block
↓ Décodage
Header List
Figure 2.10 – Encodage et décodage d’un Header List
Dans leur ordre d’apparition, chaque Header Field est transformé en son Header
Field Representation. La suite de tous ces Header Fields Representation, assemblés
bout-à-bout, se nomme un Header Block. Il s’agit de l’information effective qui va
être transférée sur le réseau.
2.5.3 Représentation
Le but est donc d’utiliser un encodage rendant un Header Field Representa-
tion plus courts que leur Header Field correspondant. Le principe de l’encodage est
simple : Utiliser un tableau mettant en correspondance des Header Fields utilisés
très fréquamment avec un index. Le Header Field Representation sera tout simple-
ment l’index lui-même. Ce tableau se nomme l’Index Address Space, et est séparé
en deux parties distinctes : La Static Table, et la Dynamic Table. La figure 2.11
illustre cette structure.
26
CHAPITRE 2. ANALYSE 2.5. HPACK : COMPRESSION DES HEADERS
0 Contenu pré-défini 


Static Table


61
62 Contenu dynamique 


Dynamic Table


62+k
Figure 2.11 – L’Index Address Space, constitué de la Static Table et de la Dyna-

mic Table.
La Static Table contient des données pré-définies et immuables. Ces données

sont les headers rencontrés le plus souvent. La figure 2.12 en montre quelques
valeurs.
Index Nom Valeur

1 :authority
2 :method GET
3 :method POST
4 :path /
5 :path /index.html
... ... ...
60 via
61 www-authenticate
Figure 2.12 – Quelques champs de la Static Table.
Lors de l’encodage, on va donc simplement remplacer un Header Field par son

index, qui sera le Header Field Representation. Le décodage va faire le procédé
inverse, et remplacer cet index par son Header Field correspondant. Cependant,
cette table ne contient que 61 Header Field possibles, et les communications com-
prendront bien souvent d’autres headers que ceux-ci.
Lorsqu’un Header Field n’est pas dans cette table, il va falloir le transmettre
littéralement. Une fois ce Header Field encodé ou décodé, il peut également ajouté
à la partie appelée Dynamic Table, à l’emplacement du premier index disponible.
Il sera à présent possible de le retransmettre en utilisant uniquement le nouvel
index auquel il a été assigné, celui qui figure dans la Dynamic Table, au lieu de
transmettre tout ce Header Field littéralement.
Un encodage est tout de même fait sur les Header Fields devant être transmis
27
2.6. PUSH CHAPITRE 2. ANALYSE
littéralement. Afin de gagner un peu de place, les caractères sont encodés grâce à
code de Huffman : Il s’agit de remplacer chaque caractère par une valeur, pouvant
être représentée par un nombre variable de bits.
Cette correspondance est également pré-définie et immuable. Ceci permet d’en-
coder les caractères très courants sur un nombre faible de bits, afin d’occuper le
moins de place possible en moyenne par caractère. La figure 2.13 montre la repré-
sentation binaire de quelques caractères.
On remarque que la représentation de caractères très courants comme les lettres
’a’ et ’e’ ne prennent que 5 bits, tantis que la représentation de caractères plus
rares comme ’<’ utilise 15 bits. Pour toute la table comprenant 255 caractères
différents, chaque caractère nécessite entre 5 et 30 bits.
Caractère Valeur en binaire Taille en bits

’0’ 00000 5
’1’ 00001 5
’4’ 011010 6
’a’ 00011 5
’e’ 00101 5
’?’ 1111111100 10
’<’ 111111111111100 15
’\’ 111111111111111000 19
Figure 2.13 – Quelques caractères et leur représentation encodée
2.6 PUSH
Avec HTTP 1.1, il était nécessaire que le client demande au serveur chacune des
ressources dont il a besoin. Bien que ce concept ne soit pas mauvais, un problème
de performances se pose avec la manière dont la plupart des sites web de nos jours
son construits.
En effet, le client va généralement devoir demander un seul fichier en premier
(par exemple un fichier index.html), attendre que le fichier arrive, l’analyser,
se rendre compte que d’autres fichiers sont nécessaires, puis seulement envoyer
d’autres demandes vers le ou les serveurs.
Ce processus va typiquement demander au moins deux aller-retour complets
sur le réseau : Les requêtes des fichiers référencés par la page ne peuvent partir
qu’après la réception du fichier initial.
Il est possible de faire mieux. HTTP/2 propose un mécanisme facultatif où le
serveur peut délibérément envoyer des fichiers en plus au client, avant même que
28
CHAPITRE 2. ANALYSE 2.6. PUSH
celui-ci décide de les demander. Le but pour le serveur va donc être d’envoyer aussi
tôt que possible les fichiers référencés par la page web demandée par le client. Ce
processus a été appelé PUSH.
Client Serveur Client Serveur
GET index.html GET index.html
index.html index.html
style.css
GET style.css
(b) HTTP/2 avec PUSH
style.css
(a) HTTP 1.1
Figure 2.14 – Comparaison du transfert d’une page index.html référençant un

fichier style.css.
Pour des raisons de sécurité évidentes, les fichiers que le serveur PUSH ne sont
pas directement traités par le client. Ces fichiers sont mis temporairement dans
le cache HTTP du client. Ainsi, lorsque le client va demander un fichier, il est
possible que ce fichier soit déjà disponible dans son cache.
La figure 2.14 montre la différence entre HTTP 1.1 (figure 2.14a) et HTTP/2
avec PUSH (figure 2.14b) au niveau du temps nécessaire pour charger l’entièreté
des ressources d’une page web simple.
On s’aperçoit que PUSH permet d’économiser du temps car il est possible
d’envoyer directement les ressources nécessaires.
Notons que cette fonctionnalité est facultative, et qu’un certain paramétrage est
à mettre en place par le développeur du site web. HTTP/2 ne peut pas "deviner"
29
2.7. UTILISATION DU PROTOCOLE CHAPITRE 2. ANALYSE
quels sont les fichiers à PUSHer au client : C’est au développeur de configurer ce

mécanisme, et de définir quels fichier envoyer en fonction d la page demandée, par
exemple.
2.7 Utilisation du protocole

2.7.1 Première connexion
Client La tâche d’initier la connexion HTTP/2 à partir d’une requête HTTP
1.1 est à la charge du client. Lorsqu’il se connecte à un serveur pour la première
fois et qu’il supporte le protocole HTTP/2, le client ajoute un Header Field à sa
requête :
1 Upgrade: h2c
pour une connexion non sécurisée (adresse en http://, sans utilisation de la

couche TLS), ou
1 Upgrade: h2
pour une connexion sécurisée (adresse en https://, utilisation de TLS).
Serveur Si le serveur ne supporte pas HTTP/2, le serveur va simplement ignorer

le header et la connexion va se dérouler en HTTP 1.1.
Si le serveur supporte HTTP/2, il va répondre au client en lui confirmant
l’utilisation de HTTP/2 :
1 HTTP/1.1 101 Switching Protocols
2 Connection: Upgrade
3 Upgrade: h2c
Le reste de la connexion va dès lors se dérouler avec HTTP/2.
2.7.2 Connexions futures

Si un client s’est déjà connecté au moins une fois à un serveur en utilisant
HTTP/2, il possède toutes les informations nécessaires pour le contacter à nouveau
en utilisant HTTP/2. Ceci évite de devoir à nouveau envoyer et attendre la réponse
d’une requête HTTP 1.1 pour démarrer la connexion.
30
Chapitre 3
Conception
3.1 Introduction
3.1.1 Idée
Après avoir pris connaissance du fonctionnement de HTTP/2, il est maintenant
temps d’y toucher concrètement. Nous allons mettre en place un environnement
permettant l’utiliser afin de regarder les effets du protocole en action. Ceci va se
faire à travers le développement d’un outil démonstratif, qui va permettre de se
rendre compte à la fois de la mise en place et de l’installation de l’environnement
nécessaire au protocole, et de s’intéresser aux résultats que celui-ci apporte.
L’idée de l’outil est la suivante : Un serveur va télécharger une page web exis-
tante, puis la servir alternativement à un client en HTTP 1.1, en HTTP/2, et en
HTTP/2 avec PUSH. Le client pourra ensuite tester et comparer les différences de
performances entre les 3 méthodes.
3.1.2 But de l’outil

Le but de cet outil sera démonstratif : Il va permettre à l’utilisateur de mettre
en évidence les différences de performances entre différents protocoles. Le client
pourra tester de manière automatisée et répétée l’accès par les trois méthodes à la
page web choisie.
3.2 Architecture
L’architecture de l’outil se compose donc d’une machine Client, et d’une ma-
chine Serveur.
31
3.3. PRINCIPE CHAPITRE 3. CONCEPTION
3.2.1 Client
La machine Client est celle qui va contrôler l’exécution de l’outil. Le Client a
deux rôles principaux :
— Définir quelle page d’accueil va être testée
— Effectuer l’accès aux pages téléchargées, et mesurer le temps nécessaire a
leur chargement.
Ces opérations pourront être effectuées à l’aide d’un navigateur web compatible
HTTP/2. L’utilisateur sera donc libre d’utiliser l’outil sur la page d’accueil qu’il
désire, ainsi que de lancer des mesures de performance sur celle-ci.
3.2.2 Serveur
La machine Serveur est celle qui va s’occuper du chargement et de la configu-
ration des trois serveurs différents, en plus de servir à la machine Client les pages
web permettant de contrôler l’outil. Le Serveur a donc deux rôles principaux :
— Télécharger les pages web demandées par le Client
— Servir de 3 manières les pages web téléchargées
3.3 Principe
L’outil va donc devoir procéder en plusieurs étapes afin d’arriver au but final,
qui est de servir au client une page web par différentes méthodes.
La figure 1.1 montre le schéma du processus de téléchargement d’une page web,
ainsi que sa copie vers les 3 serveurs HTTP d’une machine de l’école.
3.3.1 Téléchargement de la page web

Etapes 1 à 3 Tout d’abord, l’outil va présenter une page d’accueil à l’utilisateur,
lui demandant une page d’accueil à télécharger. Dans notre exemple, l’utilisateur
demande le site web "example.com". Le serveur se charge ensuite de télécharger
la page web ainsi, ainsi que ses ressources nécessaires (images, scripts, feuilles de
style...).
3.3.2 Mise en place sur le serveur

Etape 4 Le serveur va ensuite répliquer la page web ainsi que ses ressources dans
3 serveurs différents :
1. Un serveur HTTP 1.1
2. Un serveur HTTP/2
32
CHAPITRE 3. CONCEPTION 3.3. PRINCIPE
tic.heia-fr.ch Serveur HTTP 1.1
index.html image.png script.js

Client
2
Navigateur web Serveur HTTP/2
Utilisateur
5
1
3 Serveur HTTP/2 + PUSH
example.com Serveur HTTP
Figure 3.1 – Téléchargement initial de la page d’un site d’exemple, et copie dans
les 3 serveurs
3. Un serveur HTTP/2 utilisant PUSH

La page servie sera donc la même sur chacun des trois serveurs : Seul le moyen
dont elle sera envoyée différera.
3.3.3 Benchmark de la page

Une fois la mise en place terminée de la page sur les 3 serveurs, l’utilisateur
sera redigiré vers une page depuis laquelle il pourra à la fois accéder aux copies des
pages, mais également effectuer des mesures sur celles-ci. Ces mesures concerneront
principalement le temps de chargement nécessaire pour afficher la page.
Variation de latence Le client pourra également ajouter et faire varier un

temps de latence artificiel sur le serveur. Cette fonctionnalité permet de simuler
des conditions de réseau défavorables : Par exemple, on peut vouloir chercher à
33
3.4. CONCLUSION CHAPITRE 3. CONCEPTION
tic.heia-fr.ch
Serveur HTTP 1.1

Client
Navigateur web Serveur HTTP/2
Utilisateur
1 2
Serveur HTTP/2 + PUSH
Figure 3.2 – Accès du client aux copies de la page
reproduire la latence de l’accès à un site web depuis un appareil mobile, ou vers

un serveur très éloigné physiquement.
Automatisation La client sera capable de lancer automatiquement le test de

connexion et de chargement plusieurs fois d’affilée. Les résultats seront accumulés
et affichés au fur et à mesure des tests sur la page.
Comparatif Le résultat moyen, minimum et maximum sera affiché pour chaque

mesure, et pour chacun des 3 serveurs, sous la forme d’un tableau. Il sera alors
facile de comparer les différents résultats obtenus.
3.4 Conclusion
La motivation de l’outil est simple : Nous voulons pouvoir comparer les perfor-
mances de HTTP/2 par rapport aux performances de HTTP 1.1. Afin d’atteindre
ce but, nous avons choisi un concept poussant l’utilisateur de s’investir dans le
34
CHAPITRE 3. CONCEPTION 3.4. CONCLUSION
processus en lui permettant de tester le site web de son choix, afin de se rendre
compte des résultats sur un cas qui lui est parlant.
En ce qui concerne l’outil lui-même, l’implémentation va donc reposer sur une
architecture Client - Serveur classique.
35
Chapitre 4
Réalisation
4.1 Introduction
Le code de l’outil étant réparti entre un Client et un Serveur, plusieurs techno-
logies et langages différents vont intervenir. Ce chapitre va mettre en lumière les
aspects techniques du développement des deux côtés de l’outil.
4.2 Client
4.2.1 Choix du client
Le choix du client HTTP/2 détermine à la fois le degré confort de l’utilisateur
quand à l’utilisation de l’outil, et les possibilités d’automatisation des tests avec
JavaScript.
Plusieurs clients compatibles HTTP/2 existent déjà, il est donc nécessaire de
faire un choix et de s’y tenir afin d’avoir des résultats constants pour le reste du
développement.
La page https://github.com/http2/http2-spec/wiki/Implementations
liste certaines des implémentations connues de clients HTTP/2. Parmi cette liste,
plusieurs clients ont été envisagés, au vu de leurs fonctionnalités et de leur simpli-
cité d’utilisation :
— nghttp2
— node-http2
— Chromium
Bien que nghttp2 et node-http2 auraient également été utilisables, le choix
s’est rapidement porté sur Chromium pour une simple raison qui le distingue
très clairement des autres : Il s’agit d’un projet lié à Google Chrome, qui est un
navigateur déjà très largement répandu. Il se trouve d’ailleurs que Google Chrome
36
CHAPITRE 4. RÉALISATION 4.3. SERVEUR
lui-même supporte déjà le protocole HTTP/2 (avec TLS) depuis la version 41[11].
De plus, celui-ci comporte une palette d’outils pour développeurs : Ceci peut être
utile pour observer et comprendre certains comportements.
Une fois le client choisi, installé et fonctionnel, le projet n’y impose pas d’autre
limites outre l’activation de l’exécution du JavaScript.
4.3 Serveur
Le serveur doit assumer la tâche du téléchargement de pages web, et de leur
service ensuite. En ce qui concerne la machine utilisée, il s’agit d’une machine
virtuelle linux interne à l’école.
4.3.1 Serveur HTTP

Choix du serveur HTTP
La machine Serveur va devoir principalement servir des pages web via HTTP
au client : Le choix de la technologie du serveur HTTP est donc important. À
nouveau, un choix parmi une liste de serveurs a dû être fait.[12] Les critères de
sélection du serveur ont été les fonctionnalités HTTP/2 implémentées, la maturité
de la technologie, et sa facilité de mise en place.
Le choix s’est porté sur Apache : Il s’agit d’un système mûr, qui présente
déjà un grand nombre de fonctionnalités pour la mise en place de HTTP/2[13],
et permet une configuration automatisable grâce à des fichiers d’instructions qui
seront générés à la volée. De plus, il va être possible d’utiliser facilement le langage
PHP pour interagir avec le reste de la machine.
Configuration du serveur
Le serveur va devoir non seulement répondre aux requêtes demandant les copies
des sites web téléchargés (en HTTP 1.1, HTTP/2 et HTTP/2+PUSH), mais il va
également devoir servir certaines autres pages. En effet, il faut que l’utilisateur
soit accueilli sur une première page pour qu’il puisse renseigner quel domaine il
souhaite tester. Il est donc non seulement nécessaire de servir des pages web dans
les 3 méthodes différentes mentionnées, mais il faut également servir certaines
autres pages propres à l’application.
Pour des raisons de simplicité de compréhension, nous allons donc créer 3 + 1
= 4 "Virtual Hosts" selon les termes de Apache. Chaque Virtual Host correspond
à un point d’entrée différent vers la machine serveur : Dans notre cas, chacun
d’entre eux sera accessible par un numéro de port différent. La figure 4.1 montre
un schéma de cette architecture.
37
4.3. SERVEUR CHAPITRE 4. RÉALISATION
Serveur HTTP 1.1

Interface de l outil
:443
index.html
Serveur HTTP 1.1

Pages téléchargées
fraudit.tic.heia-fr.ch :8081
160.98.46.205 example.com other.com
Serveur HTTP/2
Apache
Web Server :8082
example.com other.com
Serveur HTTP/2 + PUSH

:8083
example.com other.com
Figure 4.1 – Chacun des 4 Virtual Host est accessibles par un port différent.
Les Virtual Hosts sont donc accessibles par les ports suivants :
:443 Il s’agit de l’interface de l’application. Celle-ci présente la page d’accueil

demandant à l’utilisateur de choisir un domaine à télécharger, puis présentera la
page de test. Notons que le port utilisé est le 443 et non le 80 : Cette page est
accessible par https uniquement.
:8081 Il s’agit de l’accès aux pages téléchargées, servies ici avec le protocole
HTTP 1.1.
HTTP/2, sans PUSH de ressources.
HTTP/2 ainsi qu’un PUSH de ressources configuré automatiquement.
38
Bien qu’un accès non sécurisé aurait été possible, il a été décidé pour des
raisons de cohérence que toutes les communications allaient être sécurisées, et
sont donc accessibles par https uniquement. Attention toutefois : Le certificat SSL
utilisé pour ces connexions est auto-signé. Il est fort possible que l’utilisateur doive
autoriser manuellement la connexion à ces pages.
4.3.2 Téléchargement de la page web

L’utilisateur accède à la page d’accueil de l’application via l’adresse du serveur
et en https, qui est ici https://fraudit.tic.heia-fr.ch. La figure 4.2 montre
un aperçu de la page d’accueil de l’application, qui permet à l’utilisateur de choisir
un site web à tester, ou d’utiliser une page d’exemple.
Figure 4.2 – Vue de la page d’accueil de l’application
Une fois que l’utilisateur a entré le nom de domaine qu’il souhaite utiliser, il
est redirigé vers une page PHP, qui lance un script bash nommé downloadSite.
4.3.3 Copie et ajustements

Le script downloadSite va, successivement :
— Vider les anciennes données de ce site si il a déjà été téléchargé.
— Créer le répertoire nécessaire pour accueillir la page d’accueil et les res-
sources du site demandé.
— Télécharger la page web demandée et son contenu grâce au programme
wget.
— Ajouter un morceau de script JavaScript (expliqué par la suite).
39
— Répliquer l’ensemble du contenu dans un dossier du même nom dans les

Virtual Hosts HTTP/2 et HTTP/2+PUSH.
— Tenter de reconnaître le type de chaque ressource de la page web pour le
PUSH.
Durant toutes ces opérations, une page d’attente est présentée à l’utilisateur,
montrée sur la figure 4.3. Celle-ci le redirige vers la page de benchmarks une fois
ces tâches terminées.
Figure 4.3 – Vue de la page de téléchargement
Un premier ajustement du contenu de la page web est nécessaire : Il faut

indiquer que toutes les ressources (images, vidéo, scripts...) se trouvent désormais
sur le serveur de l’école, et non plus sur leur serveur original. Le téléchargement
en lui-même et la modification des liens est fait grâce à la ligne bash suivante,
comprenant la commande wget ainsi que les options utilisées ($1 est la variable
contenant le nom de domaine du site demandé) :
1 wget --no-clobber --page-requisites --adjust-extension --convert-links --
restrict-file-names=nocontrol --remote-encoding --no-parent --span-hosts
--no-directories --directory-prefix=./1/$1/ $1
Un deuxième ajustement est nécessaire pour la suite : Il faut que cette page
transmette les performances de son temps chargement à l’outil. Cela se fait par
l’ajout d’un script JavaScript, lancé en fin de chargement de la page, qui va envoyer
ses informations qui seront récupérées plus tard.
Cependant, des aspects de sécurité implémentés dans les navigateurs restreignent
- à raison - considérablement les communications possibles entre plusieurs pages
web. Il a été nécessaire d’utiliser l’API pour navigateurs postMessage[14], permet-
tant à une page de communiquer des informations à une autre.
1 <script>window.addEventListener("load", function(){parent.postMessage(JSON.
stringify(window.performance.timing), "*");}, false);</script></html>
40
Il est également important pour la suite d’indiquer que ces ressources ne peuvent
pas être stockées dans le cache du navigateur : On désire qu’elles soient entière-
ment chargées à chaque fois, afin de pouvoir faire des tests consécutifs dans les
mêmes conditions. Ceci est réalisé par l’ajout des lignes suivantes dans le fichier
de configuration global Apache de chacun des Virtual Host :
1 Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
2 Header set Pragma "no-cache"
4.3.4 Configuration automatique de PUSH

Une autre difficulté a été de configurer automatiquement le PUSH des res-
sources une fois la page téléchargée. Ceci se fait, dans Apache, en ajoutant un
header HTTP nommé link à la réponse de la requête pour la page principale.
Voici un exemple de header :
1 link: </google.ch/googlelogo_white_background_color_272x92dp.png>;rel=preload
;as=image
Plusieurs informations y sont nécessaires. Tout d’abord, préciser l’adresse de

la ressource à PUSHer, ici
/google.ch/googlelogo_white_background_color_272x92dp.png.
Mais il est également nécessaire de définir de quelle manière doit être interprété
le contenu du fichier dans le champ as[15], qui prend ici la valeur image.
Il a donc fallu détecter automatiquement le type de contenu de chaque fichier
afin de pouvoir le PUSHer correctement. La décision du type de fichier s’est faite
en regardant l’extension de celui-ci. Cette méthode est loin d’être parfaite, mais
permet tout de même de deviner correctement le type de fichier d’une bonne partie
des ressources utilisées. Voici comme exemple une partie du script qui décide du
type de fichier.
1 filename=$(basename "$decoded");
2 ext=${filename##*.};
3 case "$ext" in # According to https://w3c.github.io/preload/#attributes
4 "aac" | "aiff" | "flac" | "m4a" | "mp3" | "ogg" | "wav" | "wma") # Audio
formats
5 echo -n "media"
6 ;;
7 "3gp" | "amv" | "avi" | "flv" | "gifv" | "m4v" | "mkv" | "mov" | "mp4" |
"mpg" | "mpeg" | "ogv" | "vob" | "webm" | "wmv") # Video formats
8 echo -n "media"
9 ;;
10 "js")
11 echo -n "script"
12 ;;
13 "css")
14 echo -n "style"
15 ;;
41
4.3.5 Page de benchmark
La page de benchmark propose à l’utilisateur de lancer des tests sur la même

page téléchargée, servie de 3 méthodes différentes.
Figure 4.4 – Vue de la page de benchmarks, en cours de test du domaine

google.ch.
La figure 4.4 montre une vue de cette page en cours d’utilisation : On peut y
voir que l’utilisateur a lancé le benchmark de la page google.ch. On remarque aussi,
dans le champ du haut, que le délai du serveur a été défini à 500 millisecondes.
42
Latence L’appui sur le bouton de changement de délai du serveur contacte une

page PHP qui appelle un script bash, nommé setDelay, montré sur la figure 4.5.
Celui-ci nécessite les droits d’administrateur sur la machine, et va ajouter une
latente d’accès artificielle à certains ports spécifiques de la carte réseau de la ma-
chine. Ici, on touche aux ports :8081, :8082 et :8083, qui pour rappel servent
les pages web téléchargées. Le script bash utilise le programme netem, à l’intérieur
de tc[16], pour gérer la modification de la configuration. Le délai est ensuite en-
registré dans un fichier texte, afin de pouvoir l’afficher à nouveau lorsque la page
web aura besoin de savoir que est le délai actuel du serveur.
1 # Check if root user

2 if [[ ‘id -u‘ -ne 0 ]] ; then echo "This script must be run as root" ; exit 1
; fi
3
4 # Delete past root class
5 tc qdisc del dev eth0 root
6
7 # Create the default root class
8 tc qdisc add dev eth0 handle 1: root htb
9
10 # Create children classes
11 tc class add dev eth0 parent 1: classid 1:11 htb rate 1000Mbps
14
15 # Apply rules on classes
16 tc qdisc add dev eth0 parent 1:11 handle 10: netem delay "$1ms"
19
20 # Apply filters
21 tc filter add dev eth0 protocol ip prio 1 u32 match ip sport 8081 0xffff
flowid 1:11
flowid 1:12
flowid 1:13
24
25 echo "$1" > ./app/currentDelay.txt
Figure 4.5 – Script setDelay
Répétition des tests Lors d’une phase de test, chaque page est chargée succes-
sivement en HTTP 1.1, HTTP/2 puis HTTP/2+PUSH depuis les Virtual Hosts
configurés auparavant. Une fois le chargement d’une page terminée, celle-ci trans-
met ses informations du temps de chargement nécessaire à la page principale, qui
va ensuite les afficher dans la colonne correspondante du tableau. Une fois la page
43
4.4. CONCLUSION CHAPITRE 4. RÉALISATION
complète, elle est déchargée afin de s’assurer qu’aucune exécution JavaScript sup-
plémentaire ne perturbe la suite des tests.
Au fur et à mesure des tests, les différentes statistiques s’accumulent, et la page
affiche pour chaque mesure :
— Le temps moyen
— Le temps le plus long
— Le temps le plus court
Les 6 premières lignes correspondent à des temps en millisecondes qui vont s’ajou-
ter les uns aux autres sur tout le chargement de la page, tandis que les 3 dernières
lignes correspondent au temps total avant l’arrivée de certains événements lors du
chargement de la page. Voici une explication des mesures reportées :
Redirect time Temps nécessaire à la redirection initiale vers la page correcte.
DNS time Temps nécessaire à la résolution DNS.
TCP time Temps nécessaire à l’établissement de la connexion TCP.
Request time Temps écoulé entre l’envoi de la requête et le début de la ré-
ponse.
Response time Temps nécessaire pour recevoir la totalité de la réponse
DOM Processing time Temps écoulé entre le début et la fin du chargement
du contenu de la page.
Ainsi que des temps totaux, qui sont mesurés depuis le lancement de la première
requête du navigateur :
Time to responseEnd Temps total jusqu’à la fin de la réception de la re-
quête initiale.
Time to domContentLoaded Temps total jusqu’à la fin du traitement du
contenu de la première requête.
Time to domComplete Temps total jusqu’à la fin du chargement complet
de la page.
Une fois les tests terminés, l’utilisateur a la possibilité d’en lancer à nouveau :
Le résultat de ceux-ci sera cumulé avec les tests déjà terminés.
4.4 Conclusion
La réalisation de cet outil a nécessité l’utilisation et l’interaction de plusieurs
technologies à différents niveaux. Plusieurs problèmes ont été rencontrés pendant
la phase d’implémentation, mais ont pu être résolus : Par exemple, le navigateur
ignorait totalement les ressources PUSHées tant que celles-ci n’avaient pas un
header comprenant le champ as valide. Ce genre de comportement est de manière
44
CHAPITRE 4. RÉALISATION 4.4. CONCLUSION
générale peu documenté pour HTTP/2, et il a été nécessaire de faire plusieurs

recherches afin de trouver l’origine du problème et le résoudre.
Néanmoins, l’implémentation finale est totalement fonctionnelle et utilisable.
45
Chapitre 5
Validation
5.1 Introduction
Le but de ce chapitre est de montrer que l’outil opère de manière correcte, et
conforme à nos attentes. Nous allons effectuer des tests et comparer les résultats
attendus aux résultats espérés afin de valider le fonctionnement du code.
5.2 Test du Serveur

Nous allons vérifier que le serveur a été implémenté correctement et fonctionne
de manière attendue. Nous pouvons séparer le comportement du serveur en deux
tâches distinctes à tester individuellement :
— Vérifier que les pages téléchargées soient répliquées de manière identique à
leur domaine original.
— Vérifier que les pages téléchargées soient servies de manière conforme à
chacune des 3 méthodes.
Afin de valider ces tâches, nous allons prendre 3 sites d’exemple :
1. twitter.com
2. heia-fr.ch
3. github.com
Ces 3 sites ont été choisis car ils ont été jugés assez différents plusieurs autres sites
web : La page d’accueil de twitter.ch est animée, celle de la heia-fr.ch est
composée de nombreux fragments d’informations répartis sur la page, et celle de
github.com est assez épurée et plus longue verticalement que les deux autres.
La validation a été évaluée sur deux critères :
Page visiblement identique Est-ce que l’aspect de la page copiée est le
même sur le domaine officiel ?
46
CHAPITRE 5. VALIDATION 5.2. TEST DU SERVEUR
Transferts de fichiers identiques Est-ce que les fichiers transférés sont les
mêmes, et y’a-t-il les mêmes erreurs sur la copie que sur le domaine officiel ?
Le test a été effectué sans prendre en compte l’exécution du JavaScript après
la fin du chargement de la page : En effet, le code JavaScript n’est pas prévu pour
être migré ainsi et il est donc normal et attendu que celui-ci n’agisse pas de la
même manière sur la copie du site.
5.2.1 Correspondance des pages téléchargées

twitter.com La figure 5.1 montre que tous les résultats observés sont identiques
aux résultats attendus. Nous pouvons donc valider l’exécution de l’outil sur ce site.
HTTP 1.1 HTTP/2 HTTP/2+PUSH

Page visiblement identique Oui Oui Oui
Transferts de fichiers identiques Oui Oui Oui
Figure 5.1 – Test de validation sur la page twitter.com.
heia-fr.ch La figure 5.2 montre que la page copiée n’a pas le même aspect que
la page sur le domaine initial.

Page visiblement identique Non Non Non
Figure 5.2 – Test de validation sur la page heia-fr.ch.
La figure 5.3 montre comment s’affiche la page originale, et la figure 5.4 montre
comment s’affiche la page copiée. En effet, les caractères spéciaux sur la page
originale s’affichent correctement, alors que les caractères spéciaux sur la page
copiée sont remplacés par des caractères inconnus.
Après inspection, le problème vient de l’encodage de la page. Le site web ori-
ginal déclare de manière contradictoire l’encodage de la page. On trouve, dans le
header de la réponse de la page :
1 Content-Type:text/html;charset=ISO-8859-1
Et la page déclare dans la balise <head> :

1 <meta charset="utf-8">
47
5.2. TEST DU SERVEUR CHAPITRE 5. VALIDATION
Figure 5.3 – Affichage du haut de la page originale
Figure 5.4 – Affichage du haut de la page copiée
Cette contradiction ne pose pas de problème sur la page originale, car la dé-
finition du header a la priorité sur la définition de la balise. Cependant, lors du
téléchargement de la page, seul le contenu est enregistré. La page copiée déclare
donc son contenu comme étant encodé en utf-8, alors qu’elle devrait être décodée
en ISO-8859-1 comme le suggère le header de la page originale.
Bien que visuellement dérangeante, cette différence mineure ne change pas la
manière dont la page sera servie et évaluée par la suite. Une amélioration de
l’outil pourrait donc être de prendre en compte les headers reçus qui écrasent des
configurations déclarées dans le contenu de la page elle-même, et de répercutes ces
changements sur le contenu de la page elle-même.
github.com La figure 5.5 montre que tous les résultats observés sont identiques
aux résultats attendus. Nous pouvons donc valider l’exécution de l’outil sur ce site.

Page visiblement identique Oui Oui Oui
Figure 5.5 – Test de validation sur la page github.com.
48
CHAPITRE 5. VALIDATION 5.2. TEST DU SERVEUR
5.2.2 Conformité des protocoles

Un autre aspect à vérifier, est le fait que les pages web soient bien servies
comme cela a été décidé. Pour vérifier ceci, nous allons utiliser Google Chrome
Canary, qui est une version pour développeurs de Google Chrome. Cette version
contient les fonctionnalités encore trop instables pour être intégrées à la version
grand public. Elle va cependant nous être utile car des informations plus précises
y sont présentes dans les Outils de Développement. La version utilisée pour ce test
est la suivante : Version 54.0.2796.2 canary (64-bit).
Pour ce test, nous allons charger une page d’exemple spécialement crée pour
montrer clairement le fonctionnement du protocole. Cette page est automati-
quement copiée dans le contenu de chacun des 3 serveurs lors de l’exécution
du script clearSite, qui nettoie les serveurs de toutes les autres pages télé-
chargées, et y insère deux sites d’exemple. Dans notre cas, l’exemple que nous
utilisons pour ce test est accessible à l’adresse suivante : https://fraudit.
tic.heia-fr.ch:8081/example2. Pour les tests automatisés, l’adresse d’accès
est donc : https://fraudit.tic.heia-fr.ch/compareSite.php?siteName=
example2. La figure 5.6 montre un aperçu de la page, très simple : Elle affiche une
simple image.
Figure 5.6 – Aperçu de la page de test ’example2’
Nous allons simplement charger cette page dans un onglet avec successivement
le numéro de port :8081, :8082 et :8083 pour observer le trafic réseau engen-
dré, disponible dans l’onglet "Network" dans les Outils de développeur de Chrome
Canary.
5.2.3 HTTP 1.1 sur le port 8081
Figure 5.7 – Trafic réseau pour la page de test ’example2’ servie en HTTP 1.1
49
5.2. TEST DU SERVEUR CHAPITRE 5. VALIDATION
La figure 5.7 montre que la page est bien chargée avec le protocole HTTP 1.1,
et que l’accès à l’image se fait après la fin de l’accès à la page web. Il s’agit là bien
du résultat attendu.
5.2.4 HTTP/2 sur le port 8082
Figure 5.8 – Trafic réseau pour la page de test ’example2’ servie en HTTP/2
La figure 5.8 montre que la page est bien chargée avec le protocole HTTP/2,
abrégé en h2 dans la colonne "Protocol ", et que l’accès à l’image se fait de manière
classique, après la fin de l’accès à la page web. Il s’agit là également du résultat
attendu. Nous pouvons remarquer au passage le gain de bande passante du pro-
tocole HTTP/2 par rapport à HTTP 1.1 : La taille du transfert de chacune des
ressources a diminué de 10% : La page d’accueil est passée de 1.2 KB à 997 B, et
l’image est passée de 3.3 KB à 3.0 KB. Ceci est l’effet d’optimisations telles que
la compression des headers, expliquée au chapitre consacré à HPACK.
5.2.5 HTTP/2 avec PUSH sur le port 8083
Figure 5.9 – Trafic réseau pour la page de test ’example2’ servie en HTTP/2 avec
PUSH
La figure 5.9 montre que la page est bien chargée avec le protocole HTTP/2,
abrégé en h2 dans la colonne "Protocol ", et que l’accès à l’image est chargée par
un Push du serveur : Ceci est indiqué par la mention de "Push" dans la colonne
"Initiator ". Cela signifie que l’image a été PUSHée depuis le serveur, que le navi-
gateur l’a correctement reçue et interprétée. Il n’y a d’ailleurs pas d’autre requête
de tentative d’accès à cette image. Il s’agit ici également du résultat attendu.
50
CHAPITRE 5. VALIDATION 5.3. TEST DES BENCHMARKS
5.3 Test des Benchmarks

Afin de valider les mesures des benchmarks, nous allons confronter celles-ci aux
mesures d’un outil externe. L’outil externe choisi est WebPageTest[18]. Celui-ci en
ligne nous permet de lancer une analyse semblable à celle effectuée sur la page de
benchmarks.
Afin d’obtenir des résultats facilement analysables et compréhensibles, nous
allons utiliser comme page de test la même que pour le test de conformité du
protocole, c’est-à-dire la page d’exemple ’example2’.
Afin d’obtenir des valeurs de temps significatives, nous ajoutons un délai de
500ms au serveur à l’aide de l’interface web. Puis, le benchmark est lancé sur 50
tests consécutifs.
Figure 5.10 – Résultats du benchmark de la page ’example2’ sur 50 tests, avec

500ms de latence
51
5.4. CONCLUSION CHAPITRE 5. VALIDATION
La figure 5.10 montre le résultat du benchmark pour les trois méthodes. Nous
pouvons y relever le "Request time", qui est proche à chaque fois de 500ms ; Il
s’agit du délai que nous avons ajouté au serveur.
Afin de valider ces résultats, il a été nécessaire de lancer trois tests différents
via l’interface de WebPageTest : Un pour chaque méthode.
Figure 5.11 – Résultats du WebPageTest de la page ’example2’ en HTTP 1.1,

avec 500ms de latence
Figure 5.12 – Résultats du WebPageTest de la page ’example2’ en HTTP/2, avec

500ms de latence
Figure 5.13 – Résultats du WebPageTest de la page ’example2’ en HTTP/2 +

PUSH, avec 500ms de latence
Les figures 5.11, 5.12 et 5.13 montrent les résultats tirés de WebPageTest
concernant les temps de chargements.
Nous pouvons principalement comparer la dernière des deux colonnes "Time",
qui correspond à la mesure nommée "Time to domComplete" de notre outil.
Nous voyons que dans tous les exemples, les temps sont légèrement plus élevés
d’environ 200ms sur WebPageTest : Il s’agit du délai supplémentaire engendré par
le fait que l’accès se fait depuis Paris, au lieu d’y accéder depuis le sous-réseau
même. En dehors de ceci, les temps affichés sont très cohérents entre eux.
Nous pouvons donc dire que le benchmark fait correctement son travail, et nous
donne les temps que nous attendions.
5.4 Conclusion
Nous pouvons voir qu’après des tests concrets sur des différentes parties de
l’application, les résultats observés sont ceux attendus. Nous pouvons donc dire
52
CHAPITRE 5. VALIDATION 5.4. CONCLUSION
que cette phase a permis de valider le bon fonctionnement général de l’outil.
53
Chapitre 6
Résultats
6.1 Introduction
Maintenant que nous savons que l’outil nous donne des résultats corrects, il peut
être intéressant de l’exécuter sur plusieurs domaines différents afin de constater
les différences de performances entre les protocoles, et entre les pages web elles-
même. Ces informations peuvent par exemple nous donner des indications sur les
potentiels bénéfices à passer de HTTP 1.1 à HTTP/2.
6.2 Exécutions
6.2.1 Explications
L’outil a été lancé sur une série de sites web : Il s’agit pour certains des sites
web les plus populaires en Suisse, et certains autres ont été choisis arbitrairement,
de manière à avoir un échantillon représentatif d’une variété assez large de types
de pages web.
Pages d’exemple En plus de ceux-ci, deux sites d’exemple ont été mis en place,
afin de représenter deux cas différents de pages web : Le premier affiche un total
de 400 images et sert à mettre en lumière les bénéfices de HTTP/2 par rapport à
HTTP 1.1.
Le premier exemple, accessible à l’adresse https://fraudit.tic.heia-fr.
ch/compareSite.php?siteName=example est une composition de 400 images.
La figure 6.1 montre la page en chargement.
Le deuxième exemple est un site très simple, n’affichant qu’une seule image :
Il s’agit de la même page qu’utilisée au chapitre 5.2.2
54
CHAPITRE 6. RÉSULTATS 6.2. EXÉCUTIONS
(a) Chargement en cours de la page (b) Chargement terminé
Figure 6.1 – Chargement de la page d’exemple 1, contenant 400 petites images.
Graphiques La figure 6.2 montre le temps nécessaire au chargement de chacun

des sites, une fois avec une latence nulle, et une fois avec une latence de 500ms. Les
résultats complets de ces mesures sont disponibles au chapitre E, avec une mesure
supplémentaire d’une latence de 200ms.
Les mesures prises en compte dans ce calcul sont la moyenne des "Time to
domComplete" sur 5 tests.
La figure 6.3 montre un résumé des résultats obtenus de cette exécution. Les
nombres correspondent au pourcentage de temps de différence entre les deux mé-
thodes comparées. Par exemple, "-30%" dans la colonne "1.1 → 2" signifie que le
site servi en HTTP/2 prend 30% de temps en moins à charger que celui servi en
HTTP 1.1.
La figure 6.4 montre la moyenne des temps de chargement de chaque méthode
pour tous les sites testés, dans deux situations différentes : Pour un temps de
latence nul, et pour un temps de latence de 500ms.
La figure 6.5 la variation en pourcentage du temps de chargement nécessaire,
avec l’application de modifications telles que le passage de HTTP 1.1 à HTTP/2,
ou le passage de HTTP/2 à HTTP/2 avec PUSH. Chaque courbe de couleur repré-
sente une modification, appliquée aux différents sites testés. Comme des valeurs
négatives signifient que le temps de chargement a diminué, les courbes se situant
le plus bas montrent les modifications réduisant le plus efficacement le temps de
chargement d’une page.
55
6.2. EXÉCUTIONS CHAPITRE 6. RÉSULTATS
ms
0 5000 10000 15000 20000 25000 30000
google.ch
facebook.com
youtube.com
wikipedia.org
amazon.com
20min.ch
heia-fr.ch
reddit.com
cff.ch
http2.github.io
Site d'exemple 1
Site d'exemple 2
Latence : 0ms HTTP 1.1 Latence : 0ms HTTP/2

Latence : 0ms HTTP/2+PUSH Latence : 500ms HTTP 1.1
Latence : 500ms HTTP/2 Latence : 500ms HTTP/2+PUSH
Figure 6.2 – Temps moyen de chargement pour les pages testées
56
CHAPITRE 6. RÉSULTATS 6.2. EXÉCUTIONS
Variation à 0ms latence Variation à 50ms latence

Site | Comparaison 1.1 → 2 2 → 2+PUSH 1.1 → 2 2 → 2+PUSH
google.ch -45.78% +0.33% -13.54% -13.26%
facebook.com -53.17% +18.98% -19.61% +15.61%
youtube.com -18.67% +20.57% -37.44% +14.78%
wikipedia.org -64.55% +26.32% -4.12% -3.67%
amazon.com -27.46% -17.63% -21.59% +14.96%
20min.ch -14.21% +21.11% -47.77% +41.36%
heia-fr.ch -16.82% -9.76% -15.25% +40.49%
reddit.com -31.44% +7.59% -33.95% +16.97%
cff.ch -8.64% +1.74% -34.23% +17.17%
http2.github.io -32.07% -6.20% -13.03% +17.17%
Site d’exemple 1 -69.19% +119.62% -80.43% -27.12%
Site d’exemple 2 -48.84% -55.52% -8.31% -17.81%
Moyenne -34.73% +16.61% -29.18% +12.22%
Figure 6.3 – Résumé des variations de temps de chargement nécessaire
6.2.2 Observations
Nous pouvons relever plusieurs faits intéressants dans ces statistiques.
HTTP 1.1 : Connexions TCP limitantes Tout d’abord sur la figure 6.2 no-
tons la variance élevée des performances des différents sites web dans les conditions
testées. Nous pouvons voir que, bien que toues les sites web aient un temps de char-
gement supérieur lorsque la latence est de 500ms, le site d’exemple 1 pousse cette
différence à l’extrême lorsqu’il est chargé en HTTP 1.1. Ceci s’explique par le fait
que, pour charger 400 images du même domaine en HTTP 1.1, seules 6 connexions
TCP sont disponibles : Le navigateur doit donc charger les images successivement
6 par 6. Contrairement au HTTP/2, où il est possible de démarrer le chargement
des 400 images en même temps.
HTTP/2 : Amélioration universelle Nous pouvons également remarquer, sur

l’ensemble des figures du chapitre, que le protocole HTTP/2 est plus rapide que
HTTP 1.1 dans absolument tous les cas testés. La figure 6.3 nous montre que le
passage de HTTP 1.1 à HTTP/2 diminue le temps de chargement d’environ 35%
dans des conditions de faible latence, et d’environ 30% avec une latence de 500ms.
PUSH automatique : Perfectible Il apparaît que la configuration PUSH au-

tomatique réalisée ne permet pas toujours d’améliorer les performances de HTTP/2.
57
6.2. EXÉCUTIONS CHAPITRE 6. RÉSULTATS
9 000
8 000
7 000
6 000
5 000
ms
4 000
3 000
2 000
1 000
0
HTTP 1.1 HTTP/2 HTTP/2+PUSH HTTP 1.1 HTTP/2 HTTP/2+PUSH
Latence : 0ms Latence : 500ms
Figure 6.4 – Moyenne des temps de chargement pour chaque situation
La tendance ici est même inverse : On remarque d’après la figure 6.3 que le PUSH
a tendance a dégrader les performances atteintes par HTTP/2 : Seuls 4 sites sur
les 12 ont profité bénéfiquement de ce changement. Le temps de chargement né-
cessaire moyen augmente en effet d’environ 17% dans des conditions de latence
faibles, et d’environ 12% avec une latence de 500ms.
PUSH configuré : Opportunités Malgré les résultats peu concluants de PUSH

au premier abord, deux des sites autres que les exemples ont pu être améliorés auto-
matiquement. Mais surtout, les deux exemples pour lequel le PUSH a été configuré
manuellement ont montré un gain de performance non négligeable dans certaines
conditions. Le site d’exemple 2 a pu diminuer son temps de chargement d’environ
58
CHAPITRE 6. RÉSULTATS 6.3. CONCLUSION
Variation à 0 ms 1.1 -> 2 Variation à 0 ms 2 -> 2+

Variation à 500 ms 1.1 -> 2 Variation à 500 ms 2 -> 2+
150.00%
100.00%
50.00%
0.00%
google.ch
facebook.com
youtube.com
wikipedia.org
amazon.com
20min.ch
heia-fr.ch
reddit.com
cff.ch
http2.github.io
Site d'exemple 1
Site d'exemple 2
-50.00%
-100.00%
Figure 6.5 – Variation de la moyenne du temps de chargement en fonction de la

modification de protocole effectuée
56% en utilisant PUSH.
6.3 Conclusion
Ces mesures de différents sites et différentes situations montrent des résultats
très convaincants pour HTTP/2 d’une manière générale. Celui-ci a en effet mon-
tré une amélioration sans conditions du temps de chargement. Il s’agit ici d’un
argument de force pour le passage à HTTP/2 : Il suffit de passer sur ce nouveau
protocole, sans configuration particulière pour déjà bénéficier d’avantages consé-
quents.
En revanche, l’utilisation de PUSH doit être faite avec parcimonie. Nous avons
vu que les performances de cet ajout sont très variables, et peuvent même souvent
s’en trouver dégradées si cela est fait avec peu de considération. Cependant, nous
avons également remarqué que lorsqu’il est configuré manuellement, ce concept
peut apporter des résultats bénéfiques supplémentaires conséquents. Notons tout
de même que l’algorithme de configuration automatique du PUSH utilisé ici est
très grossier et grandement améliorable : Les performances moyennes de la confi-
guration automatique sont clairement améliorables.
59
Chapitre 7
Conclusion
7.1 Conclusion du projet

7.1.1 Délivrables
Ce projet est passé par plusieurs étapes très distinctes qui ont mené à la pro-
duction de plusieurs délivrables :
— La phase d’Analyse a apporté une compréhension du fonctionnement des
mécanismes du protocole HTTP/2
— Les phases de Conception et de Réalisation ont apporté un outil démons-
tratif des différentes de HTTP/2 avec HTTP 1.1
— Les phases de Conception et de Réalisation ont également apporté des infor-
mations sur la configuration serveur nécessaire pour bénéficier des avantages
du protocole
— L’exécution de l’outil sur plusieurs sites montre dans la phase de Résultats
des informations intéressantes sur les gains potentiels à l’utilisation de ce
protocole
7.1.2 Conclusion générale

Au final, la phase d’analyse s’est trouvée assez détachée des autres parties du
projet, mais était cependant nécessaire afin d’apporter la compréhension du fonc-
tionnement du protocole. Ceci a permis de concevoir un outil mettant en lumière
les forces et faiblesses du protocole soulevées pendant la phase d’Analyse, ainsi que
de résoudre plus rapidement et plus efficacement des problèmes survenus pendant
l’implémentation. Les phases sont donc assez différentes, mais se complètent.
Ceci permet de dire que les objectifs principaux du projet ont été atteints :
Nous avons pu voir HTTP/2 sous plusieurs angles, créer un outil démonstratif
fonctionnel, et en avons tiré des résultats concrets et pertinents.
60
CHAPITRE 7. CONCLUSION 7.2. CONCLUSION PERSONNELLE
7.1.3 Perspectives
HTTP/2 est une technologie récente, et en plein essor. Nous pouvons constater
ici ces bénéfices grâce à un outil automatisant le processus de test. L’outil est
cependant améliorable dans plusieurs directions distinctes :
Plus de personnalisation de l’état simulé du réseau Ajouter de la va-
riance à la latence, des pertes de paquets etc...
Automatisation du changement des paramètres réseau Tester program-
matiquement plusieurs conditions réseau
Amélioration du PUSH automatique La configuration automatique du PUSH
est très brute et ne prend pas en compte beaucoup de paramètres.
Compatibilité avec des pages spécifiques L’outil ne peut actuellement trai-
ter qu’une page d’accueil d’un site web. Il pourrait être intéresser de pouvoir
spécifier d’analyser une autre page du domaine que celle-ci.
Compatibilité avec d’autres navigateurs L’outil n’est actuellement tota-
lement compatible et testé qu’avec Google Chrome.
Génération de graphes Les statistiques sont affichées sur la page de bench-
mark de manière brute. Des graphiques automatiquement générés pour-
raient augmenter l’attrait de la page.
7.2 Conclusion personnelle

J’ai choisi ce projet car je m’intéresse de près aux nouvelles technologies du web,
et ce projet n’est pas une exception : Ce travail m’a grandement motivé du début
à la fin. J’ai eu l’occasion ici de découvrir un protocole très récent en profondeur,
puis de mettre ces connaissances à profit en imaginant puis en réalisant un outil
complet et fonctionnel.
Le fait de travailler sur une technologie qui sera probablement utilisée mon-
dialement et qui semblait très prometteuse depuis le début était d’autant plus
stimulant que l’outil que j’ai conçu sera open-source : Il pourrait donc rendre
service en dehors du cadre de ce projet.
Au final, je suis ravi d’avoir eu l’occasion de travailler sur ce projet et très
satisfait du résultat final, autant le rapport que l’outil conçu.
61
Bibliographie
[1] IETF Tools, RFC 1945, https://tools.ietf.org/html/rfc1945,

Consulté en ligne en Juin 2016, 1996.
[4] http archive, Trends, http://httparchive.org/trends.php, Consulté en
ligne en Juin 2016, 2016.
[5] Github pages, HTTP/2, https://http2.github.io/, Consulté en ligne en
Juin 2016, 2016.
[6] Wikipedia, HTTP/2, https://en.wikipedia.org/wiki/HTTP/2, Consulté
en ligne en Juin 2016, 2016.
[7] Wikipedia, SPDY, https://en.wikipedia.org/wiki/SPDY, Consulté en
ligne en Juin 2016, 2016.
[8] HTTP Working Group, Hypertext Transfer Protocol Version 2 (HTTP/2),
http://httpwg.org/specs/rfc7540.html, Consulté en ligne en Juin 2016,
2016.
[9] HTTP Working Group, HPACK : Header Compression for HTTP/2, http:
//httpwg.org/specs/rfc7541.html, Consulté en ligne en Juin 2016, 2016.
[10] O’Reilly Atlas, High Performance Browser Networking, Chapitre 12 :
HTTP/2, http://chimera.labs.oreilly.com/books/1230000000545/
ch12.html, Consulté en ligne en Juin 2016, 2016.
[11] Can I Use..., HTTP/2 protocol http://caniuse.com/#feat=http2,
Consulté en ligne en Juillet 2016, 2016.
[12] Github, http2/http2-spec, Wiki : Implementations https://github.com/
http2/http2-spec/wiki/Implementations, Consulté en ligne en Juillet
2016, 2016.
[13] Apache HTTP Server Version 2.4, HTTP/2 guide, https://httpd.apache.
org/docs/2.4/howto/http2.html, Consulté en ligne en Juillet 2016, 2016.
62
BIBLIOGRAPHIE BIBLIOGRAPHIE
[14] Mozilla Developer Network, Window.postMessage, https://developer.

mozilla.org/fr/docs/Web/API/Window/postMessage, Consulté en ligne
en Juillet 2016, 2016.
[15] W3C, Preload, https://w3c.github.io/preload/#attributes, Consulté
en ligne en Juillet 2016, 2016.
[16] Linux man-pages, NetEm - Network Emulator, http://man7.org/linux/
man-pages/man8/tc-netem.8.html, Consulté en ligne en Juillet 2016, 2016.
[17] Microsoft Developer Network, Chronométrage de la navigation, https:
//msdn.microsoft.com/library/hh673552(v=vs.85).aspx, Consulté en
ligne en Juillet 2016, 2016.
[18] WebPagetest, Test a website’s performance, http://www.webpagetest.
org, Consulté en ligne en Juillet 2016, 2016.
63
Glossaire
Dynamic Table est une table qui associe des Header Fields rencontrés fré-
quamment avec un index. Cette table est dynamique et spécifique à un
contexte d’encodage ou de décodage.. 7, 26, 27, 64
frame se traduit par "trame" en français; représente un fragment du contenu

à transférer. 7, 13, 14, 17–19, 21, 22, 24, 25, 64
header se traduit par "en-tête" en français; représente les premières données

d’un fichier ou d’une frame. 64
Header Block est une liste ordrée de Header Field Representation. Lorsque
décodée complètement, elle donne une Header List.. 26
Header Field est une paire de clé-valeur.. 7, 25–27, 30, 64, 65
Header Field Representation est la représentation compressée d’un Hea-
der Fields, qui peut être un index ou un littéral.. 26, 27, 64
Header List est une liste ordrée de Header Fields.. 7, 25, 26, 64
HPACK est le nom du format de compression des headers utilisé par HTTP/2.
13, 25
HTML est l’abréviation de "HyperText Markup Language". Il s’agit du for-
mat de données utilisé par les pages web.. 9
HTTP est l’abréviation de "HyperText Transfer Protocol". Il s’agit d’un pro-
tocole de communication utilisé pour transférer des données sur le web. 9,
13, 25, 29, 37, 64
HTTP 1.0 est la version 1.0 du protocole HTTP. 9
HTTP 1.1 est la version 1.1 du protocole HTTP. 7–15, 25, 28–32, 34, 37, 38,
43, 47–50, 52, 54, 55, 57, 60, 69, 70
HTTP/2 est la version 2 du protocole HTTP. 7, 8, 10–15, 25, 28–34, 36–38,
40, 43, 45, 47, 48, 50, 52, 54, 55, 57–61, 64, 69, 70
Index Address Space est la table constituée de l’ajout d’une Dynamic Table
à la glsStatic Table. 7, 26, 27
64
Glossaire Glossaire
PHP est un langage de programmation couramment utilisé pour le web.. 37,

39, 43
PUSH est un mécanisme qui permet au serveur d’envoyer au client des fichiers
qu’il n’a pas (encore) demandés. Décrit à la section 2.6. 8, 31, 33, 37, 38,
40, 41, 43, 44, 47, 48, 50, 52, 55, 57–59
SPDY est le nom d’un protocole de communication. Prononcé "speedy", il

vise a améliorer la performance des communications HTTP. 12
Static Table est une table qui associe des Header Fields rencontrés fréquam-
ment avec un index. Cette table est statique, immuable et commune à tous
les contextes d’encodage et décodage.. 7, 26, 27
URI est l’abréviation de "Uniform Resource Identifier". Il s’agit d’une chaîne

de caractères permettant d’identifier de manière unique un fichier sur un
réseau.. 11
Virtual Host se traduit en "Hôte Virtuel". Il s’agit, dans Apache, d’une re-
présentation d’un serveur virtuel.. 7, 37, 38, 40, 41, 43
65
Remerciements
Je tiens à remercier mes superviseurs M. François Buntschu et M. Rudolf Scheu-

rer pour m’avoir soutenu et aidé tout au long de ce projet.
66
Déclaration d’honneur
Je, soussigné, Kewin Dousse, déclare sur l’honneur que le travail rendu est le
fruit d’un travail personnel. Je certifie ne pas avoir eu recours au plagiat ou à
toutes autres formes de fraudes. Toutes les sources d’information utilisées et les
citations d’auteur ont été clairement mentionnées.
Lieu Date Signature
67
Annexe A
Historique des versions
Voici l’historique des versions de ce document.

— 0.1 : Template du document
— 0.1.1 : Structure des chapitres
— 0.1.2 : Mise en page générale
— 0.1.3 : Ajout du cahier des charges
— 0.2 : Rédaction du fonctionnement et des types de frames
— 0.3 : Rédaction du reste de l’Analyse
— 0.4 : Ajout du code source
— 0.4.1 : Formattage et coloration syntaxique du code source
— 0.5 : Rédaction du chapitre Conception
— 0.6 : Rédaction du chapitre Réalisation
— 0.7 : Rédaction du chapitre Validation
— 0.8 : Rédaction des chapitres Résultats et Conclusion
— 1.0 : Finalisation, ajout des liens, de la bibliographie
68
Annexe B
Cahier des charges
B.1 Activités
Le développement du projet peut se découper en quatre phases, qui elles-mêmes
se divisent en plusieurs activités. Voici la liste de ces activités :
1. Analyse du nouveau protocole
(a) Listing des concepts introduits
(b) Etude de chacun des nouveaux concepts
(c) Rédaction de la documentation
2. Analyse des alternatives
(a) Listing des alternatives
(b) Pour chacune :
i. Etude du fonctionnement
ii. Différences notables avec HTTP/2
iii. Possibilité d’utilisation avec HTTP/2
3. Mise en place d’un environnement HTTP/2
(a) Serveur
i. Listing et comparaison des implémentations existantes
ii. Choix et installation d’une implémentation
iii. Etude des changements nécessaires par rapport à HTTP 1.1
(b) Client
i. Listing et comparaison des implémentations existantes
ii. Choix et installation d’une implémentation
4. Conception et réalisation d’un outil de mesure
69
B.2. PLANIFICATION ANNEXE B. CAHIER DES CHARGES
(a) Recherche de librairies utiles

(b) Conception de scénarios de tests
(c) Conception d’un algorithme de mesure de performance
(d) Implémentation de l’outil
5. Mesure des performances
(a) Etude des gains théoriques
(b) Exécution de l’outil sur des scénarios de tests
(c) Mesure des résultats obtenus
(d) Comparaison des résultats obtenus avec les résultats théoriques
(e) Différences avec HTTP 1.1
En annexe se trouve un diagramme de Gantt, situant ces points dans le temps
du projet.
B.2 Planification
Le projet comporte une série de dates-clé qu’il est important de respecter :
Date Semaine Tâche

Lundi 30 mai 2016 Semaine P14 Début du projet
Mercredi 15 juin 2016 - Fin de rédaction d’analyse du protocole
Vendredi 24 juin 2016 - Serveur + Client HTTP/2 fonctionnels
Jeudi 7 juillet 2016 - Implémentation de l’outil terminée
Vendredi 15 juillet 2016 - Rendu du rapport et du flyer
Mercredi 7 septembre 2016 - Rendu du poster
Vendredi 9 septembre 2016 - Présentation des travaux
12-14 septembre 2016 - Défense orale
Les dates en rouge sont des dates de rendu officielles. Les autres représentent
des jalons dans l’avancement du projet.
B.3 Diagramme de Gantt

Reprenant les tâches décrites par les activités, voici le diagramme de Gantt de
la planification.
70
ANNEXE B. CAHIER DES CHARGES B.3. DIAGRAMME DE GANTT
71
Annexe C
Documentation
C.1 Localisation
L’ensemble des documents du projet est disponible à l’adresse suivante :
https://redmine.forge.hefr.ch/projects/http2
Le code à son état du 15.07.2016 se trouve sur le dépôt git à l’adresse suivante :
https://gitlab.forge.hefr.ch/kewin.dousse/http2-demo
Le code, maintenu à jour, se trouve sur le dépôt git à l’adresse suivante :
https://github.com/Protectator/http2-demo
C.2 Contenu
C.2.1 Forge
Le projet présent sur la forge contient toutes les versions de chacun des
documents suivants, sous l’onglet « Documents » :
— Cahier des charges
— Rapport Final
— Les 11 procès-verbaux réalisés durant le projet, du 1 juin au 13 juillet 2016.
C.2.2 DVD
Le DVD contient l’arborescence de fichiers suivants :
— Sources/ : Contient l’ensemble du code source du projet, accompagné d’un
README pour l’installation
— PVs/ : Contient l’ensemble des PVs liés au projet
— Rapport_HTTP2_Dousse_Kewin.pdf : Document du rapport
— README.txt : Description du contenu du DVD
72
Annexe D
Code source
D.1 README.md
README.md
1 # http2-demo
2
3 Compare the differences of performance to serve a same page of your choice
using :
4
5 * HTTP 1.1
6 * HTTP/2
7 * HTTP/2 with PUSHed resources
8
9 # Requirements
10
11 You’ll need :
12
13 * An Unix environment
14 * [Apache](https://httpd.apache.org/) + PHP5
15
16 # Installing
17
18 ### Disclaimer
19
20 Before you install this, please read this :
21
22 This is an **experimental** application and it is **not safe** to use in a
production environment. Do not run it on a publicly available server.
23
24 ### App structure
25
26 * Clone/Extract/Copy all the content to a directory. Let’s say you use ‘/srv/
http2-demo/‘ for the rest of the explanations.
27 ‘‘‘bash
28 mkdir -p /srv/http2-demo/
29 cd /srv/http2-demo/
30 ‘‘‘
73
D.1. README.MD ANNEXE D. CODE SOURCE
31
32 * In it, create 3 directories named ‘1‘, ‘2‘, and ‘2push‘.
33 ‘‘‘bash
34 mkdir 1
35 mkdir 2
36 mkdir 2push
37 ‘‘‘
38
39 * Give write permissions to the group ‘www-data‘ (or the one Apache is
running as) for folders ‘app‘, ‘1‘, ‘2‘ and ‘2push‘, and execute for
folder ‘app‘.
40 ‘‘‘bash
41 sudo chgrp -R www-data app 1 2 2push
42 sudo chmod -R u+xwr *
43 sudo chmod -R g+wr app 1 2 2push
44 sudo chmod -R g+x app
45 ‘‘‘
46
47 ### Apache Configuration
48
49 Configure 4 virtual hosts on Apache :
50
51 * The first will be for the main application. Its root is the folder ‘app‘ of
the project, in this case ‘/srv/http2-demo/app/‘.
52
53 ‘‘‘
54 <VirtualHost *:443>
55 DocumentRoot /srv/http2-demo/app/
56
57 <Directory "/srv/http2-demo/app/">
58 Require all granted
59 Options +Indexes
60 </Directory>
61
62 SSLEngine On
63 SSLCertificateFile /etc/ssl/certs/your-cert.pem # Change path to your
cert file
64 SSLCertificateKeyFile /etc/ssl/private/your-cert.key # Change path to your
cert file
65 </VirtualHost>
66 ‘‘‘
67
68 * The three others will serve the downloaded pages in HTTP 1.1, HTTP/2 and
HTTP/2+PUSH. Here, We’ll use ports respectively 8081, 8082 and 8083.
69
70 Folder ‘/srv/http2-demo/1‘ will contain pages served over HTTP 1.1 on port
‘:8081‘
71
72 ‘‘‘
74 DocumentRoot /srv/http2-demo/1/
75
76 <Directory "/srv/http2-demo/1/">
78 Options +Indexes
79 AddDefaultCharset ISO-8859-1
74
ANNEXE D. CODE SOURCE D.1. README.MD
80 Header unset ETag

83 </Directory>
84 </VirtualHost>
85 ‘‘‘
86
87 Folder ‘/srv/http2-demo/2‘ will contain pages served over HTTP/2 on port
‘:8082‘. Use with SSL.
88
89 ‘‘‘
91 DocumentRoot /srv/http2-demo/2/
92
93 Protocols h2 http/1.1
94 H2Push Off
95
96 <Directory "/srv/http2-demo/2/">
98 Options +Indexes
100 Header unset ETag
103 </Directory>
104
105 SSLEngine On
cert file
cert file
108 </VirtualHost>
109 ‘‘‘
110
111 Folder ‘/srv/http2-demo/2push‘ will contain pages served over HTTP/2+PUSH
enabled on port ‘:8083‘. Use with SSL.
112
113 ‘‘‘
115 DocumentRoot /srv/http2-demo/2push/
116
117 Protocols h2 http/1.1
118 H2Push on
119 H2PushDiarySize 0 # We don’t want the server to cache pushed resources if
TCP connection is maintained through tests
120
121 <Directory "/srv/http2-demo/2push/">
123 Options +Indexes
125 AllowOverride All
128 </Directory>
129
130 SSLEngine On
75
D.2. COPYEXAMPLE ANNEXE D. CODE SOURCE

cert file
cert file
133 </VirtualHost>
134 ‘‘‘
135
136 Then of course, reload Apache configuration : ‘sudo service apache2 reload‘.
137
138 ### Enabling set delay from web interface
139
140 The bash script ‘setDelay‘ needs root permissions. If you want to use it, be
sure ‘www-data‘ can run ‘sudo‘ without password : Run ‘sudo visudo‘ and
add these lines at the end of the file :
141 ‘‘‘
142 User_Alias WWW_USER = www-data
143 Cmnd_Alias WWW_COMMANDS = /srv/http2-demo/setDelay
144 WWW_USER ALL = (ALL) NOPASSWD: WWW_COMMANDS
145 ‘‘‘
146
147 # Usage
148
149 Access the app using Google Chrome. Enter the address to access the first
VirtualHost, the one who’s root is ‘/srv/http2-demo/app/‘.
D.2 copyExample
copyExample
1 #!/bin/bash
2
3 mkdir -p "./1/example"
4 mkdir -p "./2/example"
5 mkdir -p "./2push/example"
6 mkdir -p "./1/example2"
7 mkdir -p "./2/example2"
8 mkdir -p "./2push/example2"
9 cp ./example/* ./1/example/
10 cp ./example/* ./2/example/
11 cp ./example/* ./2push/example/
12 cp ./example2/* ./1/example2/
13 cp ./example2/* ./2/example2/
14 cp ./example2/* ./2push/example2/
15
16 cat > ./2push/example/.htaccess <<- EOM
17 <Files "index.html">
18 Header add Link ’</example/img-0-0.png>;rel=preload;as=image’
76
ANNEXE D. CODE SOURCE D.3. DOWNLOADSITE

43 # A lot more lines that are not printed here. But you get the pattern.
48 </Files>
49 EOM
50
51 cat > ./2push/example2/.htaccess <<- EOM
52 <Files "index.html">
53 Header add Link ’</example2/img-0-0.png>;rel=preload;as=image’
54 </Files>
55 EOM
D.3 downloadSite
downloadSite
1 #!/bin/bash
2
3 rm -rf "./1/$1"
4 rm -rf "./2/$1"
5 rm -rf "./2push/$1"
6 mkdir -p "./1/$1"
7 mkdir -p "./2/$1"
8 mkdir -p "./2push/$1"
9
10 wget --no-clobber --page-requisites --adjust-extension --convert-links --
restrict-file-names=nocontrol --remote-encoding --no-parent --span-hosts
--no-directories --directory-prefix=./1/$1/ $1
11
12 # Generic headers
13 echo ’Header always set Access-Control-Allow-Origin "*"’ >> "./1/$1/.htaccess
"
77
D.3. DOWNLOADSITE ANNEXE D. CODE SOURCE
14 echo ’Header always set Access-Control-Allow-Methods "GET, OPTIONS"’ >> "./1/

$1/.htaccess"
15
16 # Sending postMessage to top frame
17 sed -i ’$s_<\/html>_ _’ "./1/$1/index.html"
18 echo ’<script>window.addEventListener("load", function(){parent.postMessage(
JSON.stringify(window.performance.timing), "*");}, false);</script></html
>’ >> "./1/$1/index.html"
19
20 # Copying files to HTTP/2 and HTTP/2+PUSH folders
21 cp -R ./1/$1/* "./2/$1/"
22 cp -R ./1/$1/* "./2push/$1/"
23
24 # PUSH configuration
25 echo ’<Files "index.html">’ >> "./2push/$1/.htaccess"
26 ls -1 --color=never --ignore="index.html" "./2push/$1/" | while read line; do
27 echo -n " Header add Link ’</$1/$line>;rel=preload;as=";
28 filename=$(basename "$line");
29 ext=${filename##*.};
30 case "$ext" in # According to https://w3c.github.io/preload/#attributes
31 "aac" | "aiff" | "flac" | "m4a" | "mp3" | "ogg" | "wav" | "wma") #
Audio formats
32 echo -n "media"
33 ;;
34 "3gp" | "amv" | "avi" | "flv" | "gifv" | "m4v" | "mkv" | "mov" | "mp4
" | "mpg" | "mpeg" | "ogv" | "vob" | "webm" | "wmv") # Video formats
35 echo -n "media"
36 ;;
37 "js")
38 echo -n "script"
39 ;;
40 "css")
41 echo -n "style"
42 ;;
43 "ttf" | "woff" | "abf" | "dfont" | "sfd" | "fnt" | "mf" | "otf" | "
pfb")
44 echo -n "font"
45 ;;
46 "png" | "jpeg" | "jpg" | "dds" | "tiff" | "bmp" | "tif" | "thumb" | "
gif" | "tga" | "jpe" | "jfif" | "ico")
47 echo -n "image"
48 ;;
49 "vsdx" | "svg")
50 echo -n "image"
51 ;;
52 "swf")
53 echo -n "embed"
54 ;;
55 "html" | "htm" | "xhtml" | "php")
56 echo -n "document"
57 ;;
58 *) # Default behaviour
59 echo -n "image" # Turns out that most unrecognized files are
images
60 ;;
61 esac
78
ANNEXE D. CODE SOURCE D.4. CLEARSITE
62 echo "’";
63 done >> "./2push/$1/.htaccess"
64 echo ’</Files>’ >> "./2push/$1/.htaccess"
D.4 clearSite
clearSite
1 #!/bin/bash
2
3 rm -r 1/*
4 rm -r 2/*
5 rm -r 2push/*
6 ./copyExample
D.5 setDelay
setDelay
1 #!/bin/bash
2
3 # Check if root user
4 if [[ ‘id -u‘ -ne 0 ]] ; then echo "This script must be run as root" ; exit 1
; fi
5
6 # Delete past root class
7 tc qdisc del dev eth0 root
8
9 # Create the default root class
10 tc qdisc add dev eth0 handle 1: root htb
11
12 # Create children classes
16
17 # Apply rules on classes
21
22 # Apply filters
flowid 1:11
flowid 1:12
flowid 1:13
26
79
D.6. APP/.HTACCESS ANNEXE D. CODE SOURCE
27 echo "$1" > ./app/currentDelay.txt
D.6 app/.htaccess
app/.htaccess
1 <Files "downloadSite.php">
2 php_value output_buffering Off
3 php_flag "output_buffering" Off
4 </Files>
D.7 app/index.html
app/index.html
1 <!DOCTYPE html>
2 <html>
3 <head>
4 <link rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/
semantic-ui/2.1.8/semantic.min.css"/>
semantic-ui/2.1.8/components/popup.min.css"/>
6
7 <meta charset="utf-8"/>
8 <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"/>
9 <meta name="viewport" content="width=device-width, initial-scale=1.0,
maximum-scale=1.0"/>
10
11 <title>http2-demo</title>
12 <style type="text/css">body{background-color:#FFFFFF;}.ui.menu .item img.
logo{margin-right:1.5em;}.main.container{margin-top:7em;}.wireframe{
margin-top:2em;}.ui.footer.segment{margin:5em 0em 0em;padding:5em 0em;}.
after-footer{background:#1b1c1d;}</style>
13 </head>
14 <body>
15 <div class="ui stackable inverted menu" id="topBar">
16 <div class="ui container">
17 <a href="/" class="header item">
18 http2-demo
19 </a>
20 <a href="/" class="item">Home</a>
21 </div>
22 </div>
23 <div class="ui main text container" style="margin-top: 1.5em;" id="
stickContext">
24 <div class="ui middle aligned center aligned grid">
25 <div class="column">
26 <h2 class="ui image">http2-demo</h2>
27 <h3 class="ui">Compare HTTP 1.1, HTTP/2 and HTTP/2 + PUSH</h3>
80
ANNEXE D. CODE SOURCE D.8. APP/DOWNLOADSITE.PHP
28 <form class="ui large form" action="/downloadSite.php" method="

get">
29 <div class="ui stacked segment">
30 <div class="field">
31 <label>Try your web page, or <a href="/compareSite.
php?siteName=example">the example page</a>.</label>
32 <div class="ui big input">
33 <input type="text" name="url" placeholder="google
.com">
34 </div>
35 </div>
36 <div class="field">
37 <button type="submit" class="ui fluid button huge">
Compare</button>
38 </div>
39 </div>
40 </form>
41 </div>
42 </div>
43 </div>
44 <div class="ui inverted vertical footer segment">
45 <div class="ui center aligned container">
46 <div class="ui horizontal inverted small divided link list">
47 <span class="item">http2-demo</span>
48 </div>
49 </div>
50 </div>
51 <div class="after-footer"></div>
52 </body>
53 </html>
D.8 app/downloadSite.php
app/downloadSite.php
1 <!DOCTYPE html>
2 <html>
3 <head>
6
10
81
D.8. APP/DOWNLOADSITE.PHP ANNEXE D. CODE SOURCE
13 </head>
14 <body>
18 http2-demo
19 </a>
21 </div>
22 </div>
stickContext">
28 <div class="ui stacked segment left aligned" id="dlContent">
29 <p>Download of <?php echo htmlspecialchars($_GET[’url’]); ?>
in progress... You’ll be redirected once it has ended.</p>
30 <p>If you haven’t been redirected after a minute, click <a
href="https://fraudit.tic.heia-fr.ch/compareSite.php?siteName=<?php echo
htmlspecialchars($_GET[’url’]); ?>">here</a>.
31 <pre id="feedback">
32 </pre>
33 </div>
34 </div>
35 </div>
36 </div>
41 </div>
42 </div>
43 </div>
45 <?php
46
47 ob_implicit_flush();
48
49 $shell_instruction = ’cd ..; /srv/http2-demo/downloadSite ’;
50 $shell_instruction .= escapeshellarg($_GET[’url’]);
51
52 while (@ ob_end_flush()); // end all output buffers if any
53 $proc = popen($shell_instruction, ’r’);
54 while (!feof($proc))
55 {
56 fread($proc, 4096);
57 @ flush();
58 }
59 $status = pclose($proc);
60 if ($status == 0) {
61 $script = "<script type=’text/javascript’> window.location.replace(’https
://fraudit.tic.heia-fr.ch/compareSite.php?siteName=".htmlspecialchars(
$_GET[’url’]). "’);</script>";
62 echo $script;
82
ANNEXE D. CODE SOURCE D.9. APP/COMPARESITE.PHP
63 } else {
64 echo "<script>feedback.innerHTML = ’Download failed : ";
65 echo $status;
66 echo "’;</script>";
67 }
68 ?>
69 </body>
70 </html>
D.9 app/compareSite.php
app/compareSite.php
1 <!DOCTYPE html>
2 <html>
3 <head>
6
10
13 </head>
14 <body>
15 <script src="https://code.jquery.com/jquery-2.2.4.min.js" integrity="sha256-
BbhdlvQf/xTY9gja0Dq3HiwQF8LaCRTXxZKRutelT44=" crossorigin="anonymous"></
script>
16 <div class="ui stackable inverted menu" id="topBar" style="margin-top: 0px;">
19 http2-demo
20 </a>
22 </div>
23 </div>
24 <div class="ui main text" style="margin-top: 1.5em;" id="stickContext">
25 <div class="ui middle aligned center aligned grid container">
29 <div class="ui stacked segment">
30 <h4 class="ui">Site <?php echo htmlspecialchars($_GET[’
siteName’]); ?></h4>
31 <div class="ui form">
83
D.9. APP/COMPARESITE.PHP ANNEXE D. CODE SOURCE
32 <div class="inline field">

33 <label>Delay</label>
34 <div id="testInput" class="ui right action input">
35 <input type="number" value="<?php echo intval(
file_get_contents("currentDelay.txt")); ?>" id="delay" name="delay" min="
0" max="10000" style="width:84px; padding-right: 4px;">
36 <button class="ui teal labeled icon button" id="
delayButton">
37 <i class="hourglass half icon"></i>
38 Set
39 </button>
40 </div>
41 </div>
42 <div class="inline field">
43 <label>Number of tests</label>
44 <div id="testInput" class="ui right action input">
45 <input type="number" value="5" id="numberOfTests"
name="numberOfTests" min="0" max="10000" style="width:84px; padding-
right: 4px;">
46 <button class="ui teal labeled icon button" id="
launchButton">
47 <i class="lab icon"></i>
48 Run
49 </button>
50 </div>
51 </div>
52 </div>
53 <p id="runningTest"></p>
54 <table class="ui celled striped table">
55 <thead>
56 <tr>
57 <th>Protocol</th>
58 <th><a href="<?php echo htmlspecialchars(’https://
fraudit.tic.heia-fr.ch:8081/’.$_GET[’siteName’]); ?>" target="_blank">
HTTP 1.1</a></th>
HTTP 2</a></th>
HTTP 2 + PUSH</a></th>
61 </tr>
62 </thead><tbody>
63 <tr>
64 <td style="width:10%">View</td>
65 <td style="width:30%; height:250px;" id="h1container"
>Ready</td>
66 <td style="width:30%; height:250px;" id="h2container"
>Ready</td>
67 <td style="width:30%; height:250px;" id="
h2pushcontainer">Ready</td>
68 </tr>
69 <?php
70 $stats = array(
71 "Redirect time" => "timing[’redirectEnd’] - timing[’
navigationStart’]",
84
72 "DNS time" => "timing[’domainLookupEnd’] - timing[’

redirectEnd’]",
73 "TCP time" => "timing[’requestStart’] - timing[’
domainLookupEnd’]",
74 "Request time" => "timing[’responseStart’] - timing[’
requestStart’]",
75 "Response time" => "timing[’responseEnd’] - timing[’
responseStart’]",
76 "DOM Processing time" => "timing[’domComplete’] -
timing[’domLoading’]",
77 "Time to responseEnd" => "timing[’responseEnd’] -
timing[’navigationStart’]",
78 "Time to domContentLoaded" => "timing[’
domContentLoadedEventStart’] - timing[’navigationStart’]",
79 "Time to domComplete" => "timing[’domComplete’] -
timing[’navigationStart’]",
80 );
81
82 $values = array_values($stats);
83
84 $id = 0;
85 foreach ($stats as $key => $value) {
86 if ($id == 6) {
87 echo "</tbody><tfoot>";
88 }
89 if ($id < 6) {
90 echo "<tr><td>".$key."</td><td id=’stat-h1-".$id.
"’></td><td id=’stat-h2-".$id."’></td><td id=’stat-h2push-".$id."’></td
></tr>";
91 } else {
92 echo "<tr><th>".$key."</th><th id=’stat-h1-".$id.
"’></th><th id=’stat-h2-".$id."’></th><th id=’stat-h2push-".$id."’></th
></tr>";
93 }
94 $id++;
95 }
96 ?>
97 </tfoot>
98 </table>
99 <p>
100 <b>Average</b> | Min | Max<br>
101 All units are in milliseconds [ms].
102 </p>
103 </div>
104 </div>
105 </div>
106 </div>
111 </div>
112 </div>
113 </div>
115 </body>
85
116 <script>
117 var origins = ["https://fraudit.tic.heia-fr.ch:8081",
118 "https://fraudit.tic.heia-fr.ch:8082",
119 "https://fraudit.tic.heia-fr.ch:8083"];
120
121 total = [];
122 total[’avg’] = [];
123 total[’avg’][0] = [];
124 total[’avg’][1] = [];
125 total[’avg’][2] = [];
126 total[’min’] = [];
127 total[’min’][0] = [];
128 total[’min’][1] = [];
129 total[’min’][2] = [];
130 total[’max’] = [];
131 total[’max’][0] = [];
132 total[’max’][1] = [];
133 total[’max’][2] = [];
134 total[’pass’] = 0;
135 total[’tests’] = 0;
136
137 function round1(float) {
138 return Math.round(float * 10) / 10;
139 }
140
141 window.addEventListener("message",
142 function (e) {
143 var timing = JSON.parse(e.data);
144 var stats = [<?php echo implode(", ", $values); ?>];
145 console.log("Message recieved ! : " + e.origin + " : " + e.data);
146 var i;
147 switch(e.origin) {
148 case origins[0]:
149 for (i = 0; i < stats.length; i++) {
150 if (total[’avg’][0][i]) {
151 total[’avg’][0][i] += stats[i];
152 } else {
153 total[’avg’][0][i] = stats[i];
154 }
155 if (total[’min’][0][i]) {
156 total[’min’][0][i] = Math.min(total[’min’][0][i],
stats[i]);
157 } else {
158 total[’min’][0][i] = stats[i];
159 }
160 if (total[’max’][0][i]) {
161 total[’max’][0][i] = Math.max(total[’max’][0][i],
stats[i]);
162 } else {
163 total[’max’][0][i] = stats[i];
164 }
165 var currentAvg = total[’avg’][0][i]/total[’pass’];
166 var currentMin = total[’min’][0][i];
167 var currentMax = total[’max’][0][i];
168 $(’#stat-h1-’ + i).html("<b>" + round1(currentAvg) +
"</b> | " + currentMin + " | " + currentMax);
86
169 }
170 break;
173 if (total[’avg’][1][i]) {
175 } else {
177 }
178 if (total[’min’][1][i]) {
stats[i]);
180 } else {
182 }
183 if (total[’max’][1][i]) {
stats[i]);
185 } else {
187 }
191 $(’#stat-h2-’ + i).html("<b>" + round1(currentAvg) +
"</b> | " + currentMin + " | " + currentMax);
192 }
193 break;
196 if (total[’avg’][2][i]) {
198 } else {
200 }
201 if (total[’min’][2][i]) {
stats[i]);
203 } else {
205 }
206 if (total[’max’][2][i]) {
stats[i]);
208 } else {
210 }
214 $(’#stat-h2push-’ + i).html("<b>" + round1(currentAvg
) + "</b> | " + currentMin + " | " + currentMax);
215 }
216 break;
217 default:
218 console.log(e.origin + " : " + e.data);
87
219 }
220 },
221 false);
222
223 $("#launchButton").click(function() {
224 $("#launchButton").prop(’disabled’, true);
225 $("#testInput").prop(’disabled’, true);
226 $("#launchButton").addClass(’loading disabled’);
227 $("#testInput").addClass(’disabled’);
228 $("#delay").prop(’disabled’, true).addClass(’disabled’);
229 $("#delayButton").prop(’disabled’, true).addClass(’disabled’);
230 total[’tests’] += parseInt($("#numberOfTests")[0].value);
231 launchBenchmark(500, parseInt($("#numberOfTests")[0].value));
232 });
233
234 $("#delayButton").click(function(){
235 var delayValue = $("#delay")[0].value;
236 $("#delay").prop(’disabled’, true).addClass(’disabled’);
237 $("#delayButton").prop(’disabled’, true).addClass(’disabled’);
238 $.get("/delay.php?delay=" + delayValue, function(data) {
239 if (data.substring(0, 5) == "ERROR") {
240 alert(data);
241 } else {
242 alert("Delay has been set to " + data + "ms.");
243 }
244 $("#delay").prop(’disabled’, false).removeClass(’disabled’);
245 $("#delayButton").prop(’disabled’, false).removeClass(’disabled’)
;
246 });
247 });
248
249 function launchBenchmark(delay, times) {
250 $(’#h1container’).html("");
251 $(’#h2container’).html("");
252 $(’#h2pushcontainer’).html("");
253 $(’<iframe>’, {
254 id: ’h1’,
255 style: ’width:100%; height:100%;’
256 }).appendTo(’#h1container’);
257 $(’<iframe>’, {
258 id: ’h2’,
260 }).appendTo(’#h2container’);
261 $(’<iframe>’, {
262 id: ’h2push’,
264 }).appendTo(’#h2pushcontainer’);
265 total[’pass’]++;
266 $("#runningTest").html("Test " + total[’pass’] + " / " + total[’tests
’]);
267 console.log("Starting test " + total[’pass’]);
268 console.log("Initializing iframes");
269 var h1 = $(’#h1’);
270 var h2 = $(’#h2’);
271 var h2push = $(’#h2push’);
88
ANNEXE D. CODE SOURCE D.10. APP/DELAY.PHP
272 h1[0].setAttribute("src", "<?php echo htmlspecialchars(’https://

fraudit.tic.heia-fr.ch:8081/’.$_GET[’siteName’]); ?>");
273 h1.load(function(){
274 h1[0].parentNode.innerHTML = "Test complete";
275 setTimeout(function(){
276 h2[0].setAttribute("src", "<?php echo htmlspecialchars(’https
://fraudit.tic.heia-fr.ch:8082/’.$_GET[’siteName’]); ?>");
277 h2.load(function(){
278 h2[0].parentNode.innerHTML = "Test complete";
279 setTimeout(function() {
280 h2push[0].setAttribute("src", "<?php echo
htmlspecialchars(’https://fraudit.tic.heia-fr.ch:8083/’.$_GET[’siteName
’]); ?>");
281 h2push.load(function(){
282 h2push[0].parentNode.innerHTML = "Test complete";
283 console.log("Loading finished");
284 if (--times > 0) {
285 setTimeout(function() {
286 launchBenchmark(delay, times);
287 }, delay);
288 } else {
289 $("#launchButton").prop(’disabled’, false);
290 $("#testInput").prop(’disabled’, false);
291 $("#launchButton").removeClass(’loading
disabled’);
292 $("#testInput").removeClass(’disabled’);
293 $("#delay").prop(’disabled’, false).
removeClass(’disabled’);
294 $("#delayButton").prop(’disabled’, false).
removeClass(’disabled’);
295 }
296 });
297 }, delay);
298 });
299 }, delay);
300 });
301 }
302
303 </script>
304 </html>
D.10 app/delay.php
app/delay.php
1 <?php
2 chdir("..");
3 $amount = intval($_GET[’delay’]);
4 $cmd = "sudo ./setDelay ".$amount;
5 exec($cmd, $output, $returnVal);
6 if ($returnVal != 0) {
7 echo "ERROR : ".$returnVal;
8 var_dump($output);
89
D.11. EXAMPLE/.HTACCESS ANNEXE D. CODE SOURCE
9 } else {
10 echo $amount;
11 }
12 ?>
D.11 example/.htaccess
example/.htaccess
1 Header always set Access-Control-Allow-Origin "*"
2 Header always set Access-Control-Allow-Methods "GET, OPTIONS"
D.12 example/index.html
example/index.html
1 <!DOCTYPE html>
2 <html>
3 <head>
6
10
11 <title>Example website</title>
13 </head>
14 <body>
18 http2-demo
19 </a>
21 </div>
22 </div>
stickContext">
90
ANNEXE D. CODE SOURCE D.12. EXAMPLE/INDEX.HTML
26 <h3 class="ui">This page’s purpose is to better show the

differences in HTTP 1.1, HTTP/2 and HTTP/2 + PUSH. </h3>
27 <table style="border: 0px; line-height: 0px;">
28 <tr>
29 <td><img src="img-0-0.png"></td>
49 </tr>
50 <tr>
55 
59 </tr>
60 </table>
61 </div>
62 </div>
63 </div>
68 </div>
69 </div>
70 </div>
72 </body>
stringify(window.performance.timing), "*");}, false);</script>
74 </html>
91
D.13. EXAMPLE2/.HTACCESS ANNEXE D. CODE SOURCE
D.13 example2/.htaccess
example2/.htaccess
1 Header always set Access-Control-Allow-Origin "*"
2 Header always set Access-Control-Allow-Methods "GET, OPTIONS"
D.14 example2/index.html
example2/index.html
1 <!DOCTYPE html>
2 <html>
3 <head>
6
10
11 <title>Example website</title>
13 </head>
14 <body>
18 http2-demo
19 </a>
21 </div>
22 </div>
stickContext">
26 <h3 class="ui">This page’s purpose is to better show the
differences in HTTP 1.1, HTTP/2 and HTTP/2 + PUSH. </h3>
27 <table style="border: 0px;">
28 <tr>
30 </tr>
31 </table>
32 </div>
33 </div>
92
ANNEXE D. CODE SOURCE D.14. EXAMPLE2/INDEX.HTML
34 </div>
39 </div>
40 </div>
41 </div>
43 </body>
stringify(window.performance.timing), "*");}, false);</script>
45 </html>
93
Annexe E
Résultats complets
Latence : 0ms Latence : 200ms Latence : 500ms

Site | Proto 1.1 2 2+ 1.1 2 2+ 1.1 2 2+
google.ch 557 302 303 2039 1981 1652 4299 3717 3224
facebook.com 961 450 535.4 2370 2178 2496 5808 4669 5398
youtube.com 1644 1337 1612 5846 3074 4345 10803 6758 7757
wikipedia.org 536 190 240 1794 1548 1552 3352 3214 3096
amazon.com 1118 811 668 3482 2564 3088 7146 5603 6441
20min.ch 5328 4571 5536 11952 7164 8953 25757 13454 19019
heia-fr.ch 1195 994 897 4078 2989 2867 8696 7370 10354
reddit.com 1959 1343 1445 4544 3634 3692 9201 6077 7108
cff.ch 1886 1723 1753 5122 3774 4525 10726 7054 8265
http2.github.io 973 661 620 2312 2540 2700 5450 4740 5554
Exemple 1 3275 1009 2216 21488 4514 3885 57526 11259 8206
Exemple 2 602 308 137 2054 1746 1432 3620 3319 2728
Moyenne 1670 1142 1330 5590 3142 3432 12699 6436 7263
Figure E.1 – Résultats de l’exécution de 5 tests avec 3 valeurs de latence différente

sur une quinzaine de sites web. Les temps sont exprimés en millisecondes [ms].
94
Annexe F
Procès-verbaux
Voici les documents des procès-verbaux réalisés.
95
ANNEXE F. PROCÈS-VERBAUX
Projet de Bachelor 15/16
PV de réunion
1 juin 2016, de 9h45 à 10h20, en C10.19
Présent : François Buntschu, Rudolf Scheurer, Kewin Dousse
Rédaction du PV le 1 juin
Compte-rendu
Points de discussion
• Discussion préalable
Une première discussion informelle a eu lieu lundi entre M. Scheurer et M. Dousse, clarifiant premièrement
quelques détails administratifs liés au projet, ainsi que quelques suggestions de recherches pour la séance
d'aujourd'hui.
• Contenu du Cahier des charges
La première discussion s'est portée sur le contenu du cahier des charges. Étant donné que le projet va
principalement consister en l'exploration d'une nouvelle technologie, le cahier des charges sera établi sur la
base d'une analyse préliminaire, destinée à contextualiser HTTP/2 parmi les produits existants et futurs.
La structure générale du Cahier des charges a été proposée : Une ébauche du contenu de celui-ci sera
envoyé vendredi.
• Alternative soulevée : QUIC
Parmi d'éventuelles alternatives à HTTP/2, la technologie QUIC a été discutée brièvement. Basée sur UDP
au lieu de TCP, QUIC utilise obligatoirement TLS, et également une partie de HTTP/2. Cette technologie
étant étroitement liée avec le développement de HTTP/2, elle sera prise en compte au moins dans l'analyse
préliminaire, nécessaire à l'élaboration du cahier des charges.
• Contact avec l'expert
Kewin ayant déjà reçu l'identité de l'expert assigné, quelques précisions ont été apportées sur son rôle dans
le projet ainsi que l'utilité et la fréquence des rencontres avec celui-ci.
Conclusion
La rédaction du Cahier des charges est la tâche actuelle à compléter pour le projet, une version d'ébauche
sera envoyée vendredi. Une analyse préliminaire de certains concepts sont nécessaires à son élaboration.
Points d'action Personne responsable Echéance

• Contact de l'expert Kewin Dousse 1 juin 16
• Ebauche du cahier des charges Kewin Dousse 3 juin 16
1/1
96
PV de réunion
8 juin 2016, de 9h45 à 10h20, en C10.19
Compte-rendu
• PV précédent
Le PV de la réunion précédente a été validé par toutes les personnes présentes.
• Contenu du Cahier des charges
Après quelques corrections durant la semaine, le cahier des charges a été présenté et validé.
• Etat de l’analyse
L’analyse du protocole HTTP/2 est quasiment terminée. Les principes centraux du protocole ont été
présentés : HPACK, une seule connexion TCP par domaine, les streams, et le principe de PUSH. Reste
maintenant à mettre en forme ce contenu et à rédiger la partie d’Analyse dans le rapport. Quelques
paragraphes seront également consacrés à QUIC, et comparé à HTTP/2. Ceci sera fait pour la semaine
prochaine, mercredi.
• Forme du rapport
Lors de la dernière réunion, Kewin avait proposé de rédiger le rapport en anglais. Il s’est trouvé que l’effort
rédactionnel à fournir pour ce document était trop grand pour assumer ceci en anglais, et la décision a été
prise de rédiger l’entier du document en français.
• VM
Une discussion a eu lieu et l’environnement sera, à moins de rencontrer des problèmes, faite sur la VM
existante qui a servi au projet de semestre précédent, Framework Audit.
Conclusion
Le chapitre d’analyse sera complété pour la semaine prochaine. L’environnement HTTP/2 sera également
mis en place et prêt à être utilisé pour la suite des phases du projet.

• Complétion de la rédaction de l’analyse Kewin Dousse 15 juin 16
• Installation du server-client HTTP/2 Kewin Dousse 15 juin 16
1/1
97
PV de réunion
15 juin 2016, de 9h45 à 10h30, en C10.19
Compte-rendu
• PV précédent
• Etat de l’analyse
L’avancement de l’analyse a pris un peu de retard. Il reste à expliquer le multiplexage et PUSH, ainsi que de
montrer les principes de QUIC. Ceci sera fait et envoyé jusqu’à samedi.
• Suite du projet
Après quelques explications, il se trouve que Kewin n’avait pas d’idée fixe de quelle direction allait prendre la
suite du projet. Bien que différentes idées d’outils aient été proposées, le cheminement n’était pas clair et
toutes n’étaient pas réalisables dans le temps du projet. Il a été clarifié que le but était de pouvoir produire
des mesures pertinentes sur HTTP/2 pour certaines utilisations, ainsi qu’un outil pouvant les automatiser.
Le problème était de savoir quel genre d’outil créer, et quelles statistiques nous allions pouvoir en tirer. Il a
été décidé que l’intérêt de l’outil allait être de mettre en lumière les différences de HTTP 1.1 et de HTTP/2 du
point de vue d’un développeur.
L’outil va comparer l’utilisation de HTTP 1.1 et de HTTP/2 sur un même site statique. Il va pouvoir permettre
de se rendre compte des gains de performances espérés via la mise en place de HTTP/2 à plusieurs
niveaux, ainsi que de montrer les changements de configuration nécessaires à ces résultats. Nous aurons
donc typiquement 3 cas différents à comparer : L’utilisation de HTTP 1.1 uniquement, de HTTP/2 sans
optimisations, et de HTTP/2 avec optimisations (telles que PUSH).
Une proposition finale de cette réalisation sera présentée lundi.
Conclusion
Une fois la phase d’analyse terminée, la deuxième partie du projet porte donc sur la réalisation d’un outil
permettant de mesurer et de comparer des performances et des configurations de HTTP/2. Cette démarche
va commencer dès lundi, avec la proposition finale du concept de l’outil.

• Envoi du chapitre d’analyse Kewin Dousse 18 juin 16
• Proposition d’outil à réaliser Kewin Dousse 20 juin 16
1/1
98
PV de réunion
20 juin 2016, de 13h30 à 14h05, en C10.19
Compte-rendu
• PV précédent
• Outil démonstratif
L’outil proposé était le suivant : Une interface web permet à un utilisateur d’entrer l’adresse d’un site web, qui
sera ensuite servi de 3 manières : HTTP 1.1, HTTP/2, et HTTP/2 avec PUSH. Une comparaison des
performances de chaque site sera ensuite affichée.
Après discussion, une idée est venue : Faire varier la latence entre les sites (avec un outil nommé vanem
par exemple), et observer le comportement de cette variable sur le temps de chargement total . La question
a également été posée : Faut-il charger les sites et récolter les résultats du chargement du côté client ou
serveur ? Une recherche est nécessaire pour déterminer la meilleure méthode.
Il est maintenant nécessaire de démarrer la mise en place de l’infrastructure de cet outil. Le processus
d’automatisation n’est pas la partie urgente, et sera probablement faite plus tard.
• Analyse
Dans le rapport, l’analyse actuelle semble suffisante. L’importance est maintenant sur la partie
Conception/Réalisation.
Conclusion
La mise en place de l’infrastructure de l’outil (les 3 manières de servir le site web) est à présent nécessaire
afin de commencer à réaliser des tests.

• Début de réalisation de l’outil Kewin Dousse 22 juin 16
• Préparation de réunion avec l’expert Kewin Dousse 24 juin 16
1/1
99
PV de réunion
22 juin 2016, de 9h50 à 10h00, en C10.19
Compte-rendu
• PV précédent
• Outil démonstratif
La configuration des sites web servis en HTTP 1.1 et HTTP/2 est terminée. Il reste à configurer la partie
PUSH des sites web à servir en HTTP/2 avec PUSH.
Une recherche sera relancée sur l’outil wanem, que Kewin avait mal orthographié lors de la discussion
précédente.
WebPageTest est un outil en ligne analysant le chargement des sites Web. Il existe une API afin d’y accéder
de manière automatisée, limitée à 200 requêtes par jour. Une étude sera faite sur l’utilisabilité de cette
mesure.
Kewin rendra compte vendredi de l’avancement actuel de l’outil, et des prochaines étapes du projet.
Conclusion
L’architecture de l’outil est presque en place, tandis que la recherche de la faisabilité de l’automatisation du
processus d’analyse de site web est en cours.

• Information de l’état d’avancement et tâches futures Kewin Dousse 24 juin 16
• Préparation de réunion avec l’expert Kewin Dousse 24 juin 16
1/1
100
PV de réunion
24 juin 2016, de 10h00 à 10h50, en C10.15
Présent : Pierre-André Roubaty, Kewin Dousse
Compte-rendu
• Présentation générale du protocole HTTP/2
Kewin a tout d’abord présenté de manière générale le protocole HTTP/2 ainsi que les différences principales
avec la version 1.1 du protocole : Les streams, le multiplexage, la compression des headers et le PUSH des
ressources.
• Présentation du projet
La réunion a ensuite continué sur une discussion sur le Cahier des Charges : Présentation du contexte du
projet, des objectifs de celui-ci, du planning défini et des activités. Nous sommes à la semaine 4, la moitié du
temps prévu pour le projet, et sommes dans les temps et en cohésion avec le planning.
La discussion s’est ensuite portée sur l’explication de l’outil qui va être réalisé : Télécharger un site web, et le
servir de manière statique de 3 manières différentes : HTTP 1.1, HTTP/2 et HTTP/2 avec PUSH.
• Prochaine réunion
La prochaine réunion avec l’expert a été définie : Elle se passera le lundi 4 juillet à 10h00.
1/1
101
PV de réunion
29 juin 2016, de 9h45 à 10h15, en C10.19
Compte-rendu
• PV précédent
• Outil et problèmes techniques
L’avancement de l’implémentation et de la configuration a rencontré plusieurs problèmes durant la semaine.

Tout d’abord, il s’est trouvé que le dossier personnel dans la VM mise à disposition était montée en NTFS,
ce qui ne permettait pas d’y accéder de manière automatisée, autrement dit d’accepter le contenu téléchargé
des sites web. Le problème a été réglé en utilisant le compte root pour créer un dossier ailleurs sur la
machine.
Le deuxième problème, actuellement non résolu, est le principe de PUSH des fichiers. Des tests sur une
page téléchargée assez simple, google.ch, montrent les problèmes suivants : Le serveur signale au client
que des images vont être PUSHées, celles-ci arrivent en effet jusqu’au client, mais le client les demande
ensuite une seconde fois. Ce problème va donc être investigué.
De plus, il semblerait que la configuration du PUSH doive être effectuée dans un fichier central, et qu’un
redémarrage du serveur soit nécessaire pour le changement de celui-ci. Ce qui laisse peu de flexibilité sur
l’automatisation de cette tâche. Une possibilité de configuration à la volée existe (avec des fichiers
.htaccess), mais elle interférerait avec la structure des fichiers téléchargés.
Conclusion
Il est nécessaire que ces problèmes soient investigué et résolus afin que la suite du développement de l’outil
continue. Kewin tiendra les superviseurs à jours avant la fin de la semaine de l’état de ces problèmes.

• Recherche de solutions aux problèmes, mail informatif Kewin Dousse 1 juillet 16
1/1
102
PV de réunion
4 juillet 2016, de 10h00 à 10h20, en C10.19
Présent : Pierre-André Roubaty, Rudolf Scheurer, Kewin Dousse
Rédaction du PV le 4 juillet
Compte-rendu
• Etat de l’implémentation
Kewin a présenté l’état actuel de l’implémentation : Une page web est mise en place et permet d’entrer un
nom de domaine à servir. Une fois validé, un script télécharge la page d’accueil de celui-ci et l’utilisateur est
redirigé vers une page sur laquelle il peut cliquer sur 3 liens, servant chacun la page d’une manière
différente : HTTP 1.1, HTTP/2 et HTTP/2 avec PUSH. L’implémentation d’une page procédant à un
benchmark automatique en JavaScript a été démarrée et est actuellement en cours de réalisation.
Après quelques réponses à des questions techniques de l’expert, le point est fait sur l’avancement du projet
dans le temps : L’avancement est en concordance avec le planning et touche à sa fin dans quelques jours.
Conclusion
L’avancement est en concordance avec le planning, et d’ici deux ou trois jours les benchmarks en JavaScript
et avec l’outil externe WebPageTest devraient être terminés.
1/1
103
PV de réunion
Compte-rendu
• PV précédent
• Implémentation actuelle du benchmark
L’implémentation du benchmark a été faite ainsi : Une fois le site web choisi téléchargée, l’utilisateur est
redirigé vers une page qui va ouvrir la page consécutivement en HTTP 1.1, HTTP/2 puis HTTP/2 + PUSH,
chacun dans une frame. Une fois un chargement de page complété, les résultats (temps nécessaire pour
charger la page) sont affichés dans un tableau comparatif, et le chargement de la prochaine méthode prend
place.
Il est aussi possible de définir, à l’aide d’un script via un accès SSH au serveur, un délai avant de servir les
pages afin de simuler une latence sur le réseau.
• Améliorations prévues
Quelques améliorations à ce benchmark ont été proposées et seront encore implémentées jusqu’à la fin de
la semaine :
• La configuration et mise en place d’un site « de référence », pour lequel on attend certains résultats
fixés à l’avance.
• La possibilité de lancer le test plusieurs fois d’affilée et d’afficher une moyenne des performances.
D’autres idées ont également été proposées et seront réalisées si le temps le permet : La possibilité de
régler la latence via l’interface web directement.
Conclusion
L’implémentation arrive à sa fin. Quelques détails sont à ajouter et retoucher, puis la rédaction des chapitres
correspondants dans le rapport sera entamée.

• Terminer implémentation de l’outil démonstratif Kewin Dousse 8 juillet 16
• Démarrer la documentation des parties restantes Kewin Dousse 11 juillet 16
1/1
104
PV de réunion
Présent : Pierre-André Roubaty, Kewin Dousse
Compte-rendu
• Benchmarks
Kewin a présenté l’état de l’implémentation : Le benchmark des pages est terminé. Il est à présent possible
de lancer le test plusieurs fois d’affilée sur la même page web, et d’obtenir des statistiques sur le résultat
final de ces tests : Moyenne, minimum et maximum de chacun des temps pour les 3 méthodes.
• Travail restant
Il ne reste à présent que du travail rédactionnel : Il s’agit d’écrire la fin du rapport. À savoir, les chapitres de
Conception, Réalisation, Résultats et Conclusion.
Conclusion
Pour la dernière semaine, l’important est donc de rassembler les concepts et les résultats obtenus afin de
former le contenu du rapport.
1/1
105
PV de réunion
Présent : François Buntschu, Kewin Dousse
Compte-rendu
• PV précédent
• Implémentation finale
Kewin a montré l’état final de l’outil : Il est désormais possible de lancer une succession de tests sur la page
web. Un tableau comparatif des résultats est tenu à jour au long des tests avec la valeur moyenne, minimum
et maximum de chaque temps. Il est également possible de régler la latence du serveur depuis l’interface
web. Notons toujours que cette implémentation pour une utilisation d’une seule personne à la fois.
• Rapport
L’implémentation de la modification de la latence via interface web a pris du temps sur la rédaction du
rapport. Il reste une partie de la Conception, Réalisation, Validation et Résultats à écrire. Kewin a présenté la
structure des chapitres, qui semble convenir.
• Flyer
Il a été rappelé que le Flyer était à rendre vendredi également, et qu’il s’adressait aux visiteurs de
l’exposition : Il est donc nécessaire de rédiger une description compréhensible par le grand public, et qui
donne envie de s’intéresser au projet.
Conclusion
Bien qu’avec un peu de retard, il ne reste plus que le rapport à terminer d’écrire ainsi que faire le flyer pour
vendredi. Le code est terminé, même si une ou deux corrections de bug seront encore faites (et
mentionnées) après le rendu du rapport, et avant la présentation.

• Terminer rapport + flyer Kewin Dousse 15 juillet 16
1/1
106

HTTP 2 Le - Futur - Protocole - de Transfert de L'avenir

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HTTP 2 Le - Futur - Protocole - de Transfert de L'avenir

Transféré par

Droits d'auteur :

Formats disponibles

HTTP/2 : LE FUTUR PROTOCOLE DE TRANSFERT DU WEB ?

c 2016 Kewin Dousse

Superviseurs : Rudolf Scheurer, François Buntschu

2.7.2 Connexions futures . . . . . . . . . . . . . . . . . . . . . . . 30

A Historique des versions 68

B Cahier des charges 69

2.1 Format de l’en-tête des frames. . . . . . . . . . . . . . . . . . . . . 14

3.1 Téléchargement initial de la page d’un site d’exemple, et copie dans

5.1 Test de validation sur la page twitter.com. . . . . . . . . . . . . . 47

6.1 Chargement de la page d’exemple 1, contenant 400 petites images. . 55

E.1 Résultats de l’exécution de 5 tests avec 3 valeurs de latence diffé-

5. Le serveur répond avec le contenu de chaque fichier demandé.

Tous ces transferts sur le réseau nécessitent du temps et de la bande passante ;

2.1.1 Principes de base

afin de profiter des améliorations de performances, sans avoir à adapter la logique

Techniques utilisées HTTP/2 tente de tirer profit de plusieurs concepts pour

2.2 Fonctionnement des frames

Length Taille du contenu utile de la frame, sans compter 9 octets de ce header.

Figure 2.1 – Format de l’en-tête des frames.

R Bit réservé. Doit être laissé à 0.

Stream ID Numéro d’identification du stream. Représenté par un entier non

Frame payload Contenu utile de la frame.

Un stream représente un flux de données (typiquement, un stream par fichier),

Figure 2.2 – Une connexion HTTP/2 transmettant des frames de plusieurs

La figure 2.2 illustre une connexion HTTP/2 entre un client et un serveur. On

2.3.2 Priorisation et dépendance

La figure 2.3 illustre principe de la dépendance des streams, et montre que

Figure 2.3 – Exemple de dépendance : Stream 3 et Stream 1 dépendent de Stream

Stream 1 Stream 3 Stream 4

2.4 Types de frames

Figure 2.5 – Format des frames DATA.

On y trouve jusqu’à 3 champs différents :

Pad Length Taille du champ Padding. Présent uniquement si le flag PADDED

Data Données utiles à l’application.

Pad Length E Stream Dep.

Figure 2.6 – Format des frames HEADERS.

On y trouve jusqu’à 6 champs différents :

Pad Length Taille du champ Padding. Présent uniquement si le flag PADDED

E Indique si la dépendance du stream est exclusive. Présent uniquement si le flag

Stream Dep. Identificateur du stream sur lequel ce stream dépend. Présent

Weight Poids de la priorisation de ce stream. Représenté par un entier non signé

Header Block Fragment Un Header Block Fragment. Décrit à la section 2.5.

E Indique si la dépendance du stream est exclusive.

Stream Dep. Identificateur du stream sur lequel ce stream dépend.

Weight Poids de la priorisation de ce stream. Représenté par un entier non signé

Error Code Code identificateur de l’erreur survenue.

Identifier Identificateur d’un paramètre.

Value Valeur assignée au paramètre.

Pad Length R Promised Stream ID

Header Block Fragment

Figure 2.7 – Format des frames PUSH_PROMISE.

On y trouve jusqu’à 5 champs différents :

Pad Length Taille du champ Padding. Présent uniquement si le flag PADDED

Promised Stream ID Identificateur du stream réservé par la promesse.

Header Block Fragment Un Header Block Fragment. Décrit à la section 2.5.

Opaque Data 8 octets de valeurs quelconques.

Last-Stream-ID Identificateur du stream ayant le numéro le plus élevé que

Error Code Code identificateur de l’éventuelle erreur survenue.

Additional Debug Data Informations supplémentaires pouvant aider au diag-

Last-Stream-ID Nombre d’octets supplémentaires que l’interlocuteur peut en-

Header Block Fragment

Figure 2.8 – Format des frames CONTINUATION.

Elle ne contient qu’un seul champ :