Discussion autour de HTTP/2 (ex-SPDY)

Si le protocole SPDY n’a pas convaincu grand monde (à part Google qui en est à l’origine et l’utilise sur ses sites et dans son browser Chrome), il en sera tout autrement pour HTTP/2, devenu une RFC de l’IETF en Mai 2015.  Je ne vais pas vous demander de lire la RFC 7540 mais HTTP/2 est quasiment identique à SPDY, en gros Google est donc à l’origine du prochain protocole du web (rien que ca).

Tout comme SPDY, le nouveau protocole

  • est binaire; fini de voir passer les codes “en clair” dans tcpdump
  • permet de transférer plusieurs ressources dans un seul “socket” ouvert.
  • mieux encore, il permet de mettre fin à une transmission d’une de ces ressources
  • permet de “pousser” du contenu dans la connexion avant même que l’interlocuteur ne se rende compte qu’il en aura besoin ( ex: images linkées dans le bas du code. )
  • est prévu pour être crypté TLS (il y a un certain débat car le cryptage n’est pas obligatoire)
  • possède d’autres caractéristiques encore, mais celles-ci sont les principales

Là où ce protocole devient intéressant c’est au niveau de la rétro compatibilité d’une part, et de l’optimisation des temps de transferts.

En effet on peut se demander comment diable un protocole binaire (!) ca venir se greffer dans un monde de proxies, de firewalls applicatifs, d’applications, qui ne seront probablement jamais mises à jour à http/2 (et ne parlent que http1.1) et vont donc “casser” internet si ce protocole se diffuse. Bien sûr, les gars de l’IETF y ont pensé et je voulais en dire un mot car c’est tout simple :

Exemple d’un browser supportant HTTP/2 qui fait une demande,  à ce stade de départ il parle toujours ASCII et HTTP1.1 ;

GET / HTTP/1.1
     Host: server.example.com
     Connection: Upgrade, HTTP2-Settings
     Upgrade: h2c
     HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

Et la réponse ne tarde pas ;

     HTTP/1.1 200 OK
     Content-Length: 243
     Content-Type: text/html

Ici on parle à un bon vieux webserver qui n’a jamais entendu parler de HTTP/2, de sa demande d’upgrade planquée dans des en-têtes qu’il va ignorer, et il continue en HTTP1.1 puisque c’est la seule chose qu’il connait. Au browser de comprendre ce qui lui arrive.

Si le serveur comprend la demande, il l’annonce en HTTP1.1, et puis juste après la discussion passera en mode binaire.

HTTP/1.1 101 Switching Protocols
     Connection: Upgrade
     Upgrade: h2c

A noter à ce stade que l’upgrade “h2c” signifie “je veux parler HTTP/2 en Clair”. Par clair, entendez “non crypté TLS” (qui lui correspond à une demande “h2” ). Comprenez aussi que si c’est en clair, c’est quand même binaire. Il va falloir s’y faire.

Je ne rentre pas dans le détail de HTTP2, d’une part ça n’a pas d’intérêt, d’autre part c’est moins le protocole que son résultat qui est important : c’est mon deuxième chapitre ; l’opposition totale entre les méthodes d’optimisation du web actuel et d’un web basé HTTP/2.

En effet les webmasters actuels se battent pour que leurs pages s’affichent vite. Pour cela ils utilisent des techniques qui ont toutes pour but de limiter le nombre de sockets ouvert vers un unique serveur ( généralement les browsers n’autorisent que 4 ou 8 connexions simultanées), par exemple par la création de “sprites” qui regroupent des images, ainsi que d’autres techniques (sharding, CDN, etc) qui consistent à distribuer les éléments de la page sur plusieurs serveurs.

Hors comme on vient de le voir (c’est pour ca que j’ai commencé par ca) vous avez clairement un overhead (une lenteur supplémentaire) lors de l’établissement d’une connexion HTTP/2 (et encore je n’ai pas évoqué la partie binaire de la discussion) par rapport à une HTTP1.1. Bien sûr une fois établie, la “mono connexion fourre tout” et la compression d’en-têtes de HTTP/2 auront tôt fait de rattraper le retard.

Vous voyez où cela nous mène ; si on tape un site web actuel, avec les techniques actuelles, derrière un serveur HTTP/2 l’effet sera souvent contre productif. En particulier si vous servez des éléments séparés de leur contexte ( images externes, sprites ) la connexion HTTP/2 n’utilisera pas les fonctions qui “poussent” du contenu non sollicité. D’autre part, pire encore, si votre contenu est “splitté” sur plusieurs serveurs (ce qui est actuellement une très bonne façon de travailler) vous torpillez encore une fois les fonctions de HTTP/2 puisque vous forcez l’ouverture de plusieurs sockets HTTP/2.

En résumé et c’est assez amusant de le constater; pour HTTP/2 il faudra “désoptimiser” le web, en particulier cesser de distribuer le contenu, oublier ces anciennes limites de “sockets simultanés”, tout servir en “flat” sans se prendre le chou, et maximiser les départs depuis le même serveur. Il faut également oublier les sprites, les domaines sans cookie, et l’inlining de ressources. Je n’évoque pas l’html dynamique, mais là aussi on va devoir jeter une partie des pratiques. Hélas ; un site web ne pourra pas être optimisé HTTP1.1 et HTTP/2. Ne cherchez pas ce n’est pas possible.

Un mot également, je parle ici du “web” mais HTTP/2 est en réalité surtout pensé pour les applicatifs ( communication entre une app mobile et son serveur de DB ) et il est probable que le “web” tel qu’on le connait disparaisse doucement. Après tout dans un monde mobile, le “web” n’est jamais qu’une appli (le browser) parmi des milliers d’autres. Et pour ce qui est des applis, bien sûr, vous maîtrisez toute la chaîne donc vous pourrez attaquer en HTTP/2 dès que les SDK vous permettent de le faire.

Un dernier mot sur le support actuel de HTTP/2 ; en réalité tous les browsers modernes le supportent déjà :

  • IE (Edge) dans Windows 10 (pas dans les autres),
  • Firefox v34+ par défaut,
  • Safari à partir de iOS9 et El Capitan,
  • Chrome 41+ par défaut (ou via activation dans les “flags”)

Ils supportent uniquement le H2 (donc le http2 over TLS : l’https du futur si vous voulez). Vous pouvez tester votre browser actuel via cette url bien pratique chez mes amis d’Akamai. La démo est amusante aussi.

Vous pouvez expérimenter coté serveur ;

  • en ajoutant “mod_h2” à Apache 2.4.12+ (ce module vient d’être donné à la fondation Apache, il sera donc fourni d’office avec Apache 2.4.x bientôt.)
  • Chez Microsoft, IIS sous Windows 10 Beta le supporte par défaut (!).
  • On peut bidouiller un reverse proxy HTTP/2 avec Nghttp2 (à compiler).
  • Ironiquement, seul Nginx ne supporte pas encore http/2 (à l’heure où je tape ceci).

Après presque 20 ans de status quo ; le futur combinera donc IPV6 et HTTP/2 probablement avec un retour en force d’Apache, peut être sous PHP7 ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *