Comprendre HTTP/2

Par Stéphane Bordage le mercredi 25 février 2015

Vous entendez parler de HTTP/2 sans bien comprendre de quoi il s'agit ? Ce billet est pour vous : en moins de 5 minutes, vous découvrirez les limites de HTTP 1.1 et les promesses de HTTP/2.

HTTP

HTTP est l'accronyme de HyperText Transfert Protocol. Il s'agit d'un protocole de transfert de données client / serveur, principalement utilisé par nos navigateurs Internet. La première spécification d'HTTP date de 1996. A cette époque, la bande passante était très limitée et les sites simples et légers. Avec l'évolution fulgurante des usages, une révision est devenue nécessaire, dès l'année suivante, pour optimiser les performances. HTTP 1.1 date donc de 1997. Depuis, quelques améliorations ont été réalisées, notamment en 1999, avec l'introduction du "pipelining", une méthode permettant de gérer plusieurs requêtes dans une même connexion. Près de 15 ans plus tard, ces évolutions ne suffisent plus pour répondre aux nouveaux usages. L'IETF a donc décidé de revoir sa copie, toujours dans une optique d'optimisation. La première RFC d'HTTP/2 sera disponible dans quelques semaines.

Limites de HTTP 1.1

HTTP 1.1 est une mise à jour du protocole HTTP qui visait à optimiser les temps de chargement des pages. Elle ajoutait la possibilité d'effectuer plusieurs requêtes au sein d'une même connexion, les unes à la suite des autres. C'est cette version que nous utilisons encore aujourd'hui.

Sa principale limite est le risque d'embouteillage : si une requête est longue ou n'aboutit pas, elle ralentit toutes les autres.

Pour contourner ce problème, les sites modernes réalisent plusieurs requêtes HTTP au sein de connexions concurrentes. Malheuresement, les navigateurs modernes ne savent pas gérer plus de 6 connexions simultanées. Et il est impossible de réutiliser une connexion du fait d'un délais serveur de 500 ms en moyenne. Il était donc temps de faire quelque chose !

Intérêt de HTTP/2

HTTP/2 est une nouvelle optimisation de HTTP 1.1. Le protocol est donc totalement rétro-compatible. Les optimisations s'appuient en partie sur SPDY, un protocol réseau expérimental proposé par Google en 2009 (nous en parlons à la fin de ce billet). La grande nouveauté dans HTTP/2, c'est la possibilité d'effectuer des requêtes concurrentes au sein d'une même connexion. Le tout orchestré par des flux indépendants (multiplexing) gérés (flow control ) et priorisés (prioritization). Il n'est donc plus nécessaire de multiplier les connexions.

Multiplexing

Avant, pour une connexion, on avait :

- connexion
    - request / response | request / response | ...

Et maintenant on a :

- connexion
    - stream
        - request / response
    - stream
        - request / response
    - ...
        - ...

L'intérêt principal est de pouvoir gérer, au sein d'une même connexion, des flux concurrents qui ne se bloquent pas entre-eux. Cela permet de gagner du temps en évitant d'établir plusieurs connexions. Cela permet aussi d'éviter les goulots d'étranglement.

Gestion des flux

La gestion des flux est réalisée au niveau de chaque flux et de chaque connexion. Le principe général est que le client indique au serveur combien d'octets il est prêt à recevoir pour chaque flux et pour la connexion dans son ensemble. Le serveur doit impérativement respecter ces quotas. Grâce a cette mécanique, on est certain que les données envoyées seront entièrement utilisées.

Priorisation

HTTP/2 permet aussi -mais sans obligation- de prioriser chaque flux. Cette mécanique va loin puisqu'elle gère les dépendances entre flux et permet même de donner un poids relatif à chaque dépendence... C'est un moyen efficace d'optimiser les flux, par exemple en fonction de la bande passante disponible.

Push

HTTP/2 introduit un nouveau mode d'interaction qui permet au serveur d' informer le client que le serveur envoie une ressource avant que le client ne la demande. Ce système est particulièrement utile la première fois qu'un utilisateur charge une page.

Ça va ? Vous suivez ? C'est presque fini ;-)

Compression des entêtes

Comme les entêtes HTTP sont verbeuses et donc volumineuses, HTTP/2 permet de les compresser. On gagne encore quelques millisecondes.

Sécurité

La sécurité est le parent pauvre de HTTP/2. Les premiers drafts de la spécification incluaient une encryption native via TLS. Mais, devant la levée de boucliers de certains acteurs (opérateurs réseau, proxy, etc.), cette proposition a été rejettée et n'est pas présente dans la spécification finale. Cependant, il semblerait que Mozilla et Google n'adopteront HTTP/2 que si le nouveau protocole supporte TLS. Une façon à peine déguisée de forcer la main à l'IETF HTTP Working Group... dont ils sont membres.

et SPDY dans tout ça ?

HTTP/2 est en partie basé sur SPDY, proposé par Google en 2009. SPDY est un protocole réseau expérimental fonctionnant sur la couche application. Son objectif est de réduire au maximum la latence lors du téléchargement d'une page. Pour cela, deux optimisations sont mises en oeuvre :

compression des headers
requêtes multiples au sein d'une même connexion

Google annonce des réductions de temps de chargement de page allant jusqu'à -64%... en laboratoire. Pour l'instant, seuls de gros sites comme Facebook, Twitter et Google implémentent SPDY en production. SPDY est supporté par Mozilla Firefox 11+, Chrome, Opera 12.10+, Internet Explorer 10+ et Safari 8+

Sources :