Le protocole HTTP/2 est finalisé. Ce qui va changer pour nos ingénieurs du web

Le web est le service Internet le plus connu et le plus utilisé par le commun des internautes burkinabè. HTTP/1.0 et surtout 1.1 ont fait leur temps: près de 15 ans de bons et loyaux services. Face aux signes de souffrance et de faiblesse, et face au silence d’un certain nombre de grands acteurs Internet, Google avait décidé de lancer tout seul SPDY (se prononce Speedy) que j’ai d’ailleurs implémenter avec intérêt sur mes serveurs. En gros, HTTP/2 ou HTTPbis reprend les grands avantages de SPDY tout en se démarquant pour une utilisation plus simplifiée et plus performante. Pour les techniciens qui aiment les précisions, et en attendant la publication du RFC (le statut actuel étant « Proposed Standard »), voici les détails du protocole en anglais.

Pourquoi faut-il migrer immédiatement vers HTTP/2?

Les avantages d’utiliser HTTP2 dès maintenant sont les suivants:

  1. Accélération du chargement des pages web avec des temps de réponse plus rapide. Autant dire que pour nos pays ou le débit/bande passante de la connexion Internet est faible, c’est une aubaine à saisir et vite
  2. Meilleure sécurisation des connexions et meilleure lutte contre les attaques DDOS sur les sites web, à une époque où les révélations de Edward SNOWDEN continue de faire un flop partout dans le monde

C’est en tout cas les deux principaux avantages qui sont mis en avant présentement, même si en y regardant de plus près, je vois plus que cela pour des configurations particulières.

 

Qu’est ce qui différencie en gros HTTP/2 de HTTP/1.1?

  1. Déjà on dit HTTP/2 et non HTTP/2.0: On ne vas plus parler de HTTP/2.0, HTTP/2.1.. mais simplement de HTTP/2 pour plus de simplicité. La notation pointée (version mineure) dans la version 2 c’est terminée! Ainsi en a décidé le comité IETF et c’est tant mieux
  2. Mode binaire entre le serveur et le client et compression des entêtes (Voir HPACK) en mode Statefull: Le transport entre le serveur et le client se fera en mode binaire et non en mode texte comme présentement avec HTTP/1.1. Cela veut aussi dire d’oublier TELNET dès à présent pour vos tests d’école, vos scripts de ping web et de débogage, car ça ne marchera pas. Il faut plutôt passer par Wireshark par exemple. Pour ceux qui veulent savoir pourquoi du binaire, venez à un des cours que j’anime sur le thème du « client/serveur et middleware »
  3. Multiplexage des connexions et communication bidirectionnelle entre client et serveur: cela veut dire moins de processus et de thread pour gérer une requête cliente, pour ne pas dire qu’une seule connexion suffirait dans la plupart des cas avec HTTP/2, et donc moins de travail pour un firewall classique et simple qui n’utilise pas de Deep Packet Inspection (DPI); cela veut aussi dire que les feuilles de style CSS3 pourront être envoyé du serveur vers le client sans que ce dernier le demande expressément, ce qui est logique, puisqu’il faudra de toute façon ces feuilles CSS pour bien afficher la page web
  4. Vous entendrez parler de HTTPng ou HTTP-ng, mais passer votre chemin car cette spécification du W3C n’a été qu’un fantôme de lui-même

 

Voici ce qui va changer coté cour pour nos webmasters et gestionnaires de serveurs web

  • Première bonne nouvelle, ce n’est que la nature du tuyau sur lequel nous faisons transiter HTML5, CSS3… qui va changer; ce qui veut dire que nos scripts (notamment les cookies, cache) pour l’instant resteront bien en place pour quelques jours encore. Pour mes compatriotes burkinabè qui codent toujours en HTML4, pardon, il y a plus facile et plus sophistiqué avec HTML5, commençons par là d’abord et on y gagnera en veille technologique. Période de cinéma africain oblige, un clin d’œil de félicitations au FESPACO qui a changer le look de son site, et qui roule désormais en HTML5.
  • Il faut se préparer à revoir le support de HTTP/2 sur nos serveurs webs, nos proxys web, nos reverse-proxys web, et bien entendu nos firewalls au besoin. Pour les serveurs webs, le support sur Nginx est prévu pour le dernier trimestre de 2015. En attendant, je vous propose de vous rabattre sur SPDY, le temps de maîtriser quelques concepts qui sont d’ailleurs repris et améliorer sur HTTP/2. Du coté client, Mozilla Firefox et Google Chrome annoncent déjà le support de HTTP/2, mais il faudrait surveiller les prochaines versions des clients web sur les autres médias: tablettes, smartphones… La liste des logiciels supportant HTTP/2 en cliquant ici, et pour les versions draft citées dans le précédent lien, voir ici..
  • Pour ceux qui utilisent des proxy ou reverse proxy web, il va falloir vraiment être vigilent et notamment augmenter les ressources processeurs et la RAM avec HTTP/2, du fait justement de la compression des entêtes en mode Statefull (mémoriser l’échange); des dialogues entre acteurs sont en cours pour régler ce problème (on supprime la compression ou on trouve une autre possibilité en n’interprétant que la première entête par exemple!). Il va falloir également se préparer à changer vos stratégies de load balancing, de géo optimisation ou de failover
  • Pour ceux qui veulent que leur serveur envoie des données au client sans que ce dernier ne le demande, faites des fouilles sur l’entête « X-Associated-Content ». En exemple: X-Associated-Content: « https://url_css.css », « https://url_script »:2, « https://url_image »: 5, « https://autre_url »
  • HTTP/2 ne veut pas dire HTTPS, cependant il y a un MAIS!
    Oui, c’est vrai que dans Google SPDY, HTTPS est utilisé d’office (c’est la mode à la configuration), mais cela ne sera pas le cas pour HTTP/2 (HTTP/2 over TCP), car tous nos webmasters ne sont pas près (financièrement, fonctionnellement et techniquement) à acheter ou à générer un certificat Verisign ou équivalent. Voici le gros « MAIS »:  si vos internautes utilisent majoritairement Google Chrome ou Mozilla Firefox (eh oui, il faut avoir un bon outil de suivi des stats pour survivre!), il va s’en dire que vous devrez penser dès à présent à TLS (au lieu de SSL…), et donc à implémenter une connexion sécurisée (HTTP/2 over TLS, c’est à dire HTTPS) entre le serveur et le client; c’est la loi du plus fort! Un conseil: autant y aller dès maintenant en suivant les sous-spécifications des grands pour ne pas balkaniser vos sites webs face à vos internautes.
    Ces deux grands navigateurs du web vous exigeront au bas mot ceci: TLS 1.2, avec les options suivantes: SNI, Renegotiation interdite durant la communication, AEAD ciphers, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 w/ P256; Faites attention donc au certificat que vous achèterez ou fabriquerez
  • Pour savoir dès à présent si un site web est HTTP/2 Ready, installer les extensions « SPDY indicator » sur Mozilla Firefox, Google Chrome et Opera

Meilleures stratégies pour migrer vers HTTP/2

  • Ce n’est pas une exigence, mais commencer à passer tous vos sites sous HTTPS, avec un certificat auto-signé ou avec les autorités comme Symantec Verisign
  • Revoyez comment vos contenus et scrypts sont envoyés vers le client, et utiliser les nouvelles techniques d’optimisation. Les astuces suivantes nous permettaient de perdre du poids en requête/réponse HTTP sous HTTP/1.1: le CSS Spriting, la concaténation (CSS et JavaScript), Inline CSS/JS, le spriting, le domain sharding. Avec HTTP/2, ces techniques sont à éviter, sinon à utiliser en connaissance de cause
  • Attendez tranquillement que les serveurs web et les clients web se mettent à jour, ou tâtez le terrain avec SPDY (qui fera encore « deux jours » avant de disparaître vraiment)
  • Et surtout, mettez en place dès maintenant des outils de suivi du traffic HTTP… et de suivi des visiteurs

Je considère pour ce qui me concerne que cette version ne fera pas long feu (beaucoup de discussions chaudes: codage binaire au lieu de la compression des entêtes, TLS vaille que vaille…), et qu’elle sera en quelque sorte une version de transition vers HTTP/3 qui durera dans le temps comme HTTP/1.1. Encore une fois, efforçons-nous de suivre les géants de l’Internet, car en ces temps c’est eux qui dictent de manière subtile leur loi et le rythme à suivre. Mon plus grand souhait est que le champ DNS de type SRV soit enfin implémenté au niveau des principaux navigateurs; on aurait déjà gagné une bataille sure et pérenne.

Tagged on: , , ,

One thought on “Le protocole HTTP/2 est finalisé. Ce qui va changer pour nos ingénieurs du web

  1. Raog biiga

    Alors qu’avec le mail, il y a les champs MX qui permettent d’atteindre les serveurs secondaires même en cas de panne du principal, nous sommes encore bloqués à ne pas utiliser les enregistrements SRV pour HTTP/2. Cela est inadmissible chez des navigateurs comme Mozilla Firefox ou Google Chrome.

    Les raisons évoquées: la compatibilité avec ce qui se fait actuellement, c’est à dire en interrogeant uniquement les champs tels A, CNAME..; des problèmes de lenteur qui ne tiennent pas d’ailleurs…

    Il faut que les grands acteurs du web (Mozilla, Google..) vote en faveur de l’enregistrement SRV, pour permette à tous d’avoir une infrastructure web distribuée de façon native et simple sans forcement passer par des solutions couteuses de load balancing et cie.

Laisser un commentaire

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