Avec les travaux du groupe de travail HTTP/2 qui s'approchent de leur terme et des implémentations qui commencent à apparaître, Mark Nottingham, le président du groupe a communiqué via son blog sur 9 points importants qui devraient faire partie de ce nouveau protocole :
- Utiliser la même API que pour HTTP. Comme le souligne Mark "Faire en sorte que HTTP/2 soit un succès signifie qu'il doit fonctionner avec le Web existant. Cela signifie faire en sorte que HTTP soit meilleur sur le réseau sans changer l'essence du protocole". Bien qu'il y ait des mécanismes permettant de mieux ajuster certaines fonctionnalités, globalement, il n'y a pas de nouvelles méthodes, en-têtes ou de codes de status.
- Des requêtes moins coûteuses. "HTTP/2 utilise le multiplexage pour permettre à plusieurs messages d'être entrelacés ensemble sur une même connexion à un instant t, de façon à ce qu'une réponse volumineuse (ou plus longue à générer) ne bloque pas les autres. À cela s'ajoute la compression des en-têtes, pour éviter que les en-têtes classiques de requêtes et réponses ne représentent pas le plus gros volume de bande passante consommée — même si ce que vous requêtez est très petit. Ce point va être vital pour le mobile où le gros volume d'en-têtes de requêtes peut facilement gonfler le temps de chargement d'une page".
- Le protocole est conçu pour être davantage en accord avec le réseau et le serveur. "HTTP/2 est conçu pour utiliser moins de connexion ce qui devrait réduire la charge pour les réseaux et les serveurs. Cela est surtout important lorsque le réseau devient encombré du fait de la parallélisation sur plusieurs connexions que fait HTTP/1". Dorénavant HTTP/2 permet une seule connexion par hôte et préfère que les sites soient regroupés sur un seul domaine si possible.
- HTTP/2 introduit le concept de "push serveur", qui permet au serveur de transmettre des données de manière proactive au cache du client avant que le client en ait même l'utilité, ce qui devrait améliorer les performances. Il va sans dire que HTTP2 permet de désactiver cette fonctionnalité si le client n'en veut pas.
- Le nouveau protocole propose une manière plus élégante de gérer l'abandon de réponse par le client (le navigateur) . En HTTP/1, la seule vraie solution était de fermer la connexion. "Avec HTTP/2, RST_STREAM frame permet à un client de changer d'avis ; si le navigateur change de page ou si l'utilisateur annule un téléchargement, il peut éviter d'ouvrir une nouvelle connexion et gâcher toute la bande passante".
- HTTP/2 supporte mieux le chiffrement et nous avons déjà abordé les pour et les contre de ce choix.
- Si vous aimez avoir la possibilité de fouiner et lire vous-même vos requêtes et réponses HTTP, ou utiliser telnet pour communiquer avec le serveur, préparez-vous à être déçus. HTTP/1 est un protocole textuel et HTTP/2 sera binaire. "Bien que les protocoles binaires aient généralement des overheads moins importants et une empreinte réseau plus faible, la vraie raison derrière ce changement est que les protocoles binaires sont plus simples et donc moins sujets aux erreurs". Mark discute ce point et comment délimiter le texte, mais une lacune majeure de HTTP/1 et du texte sont les problèmes de sécurité. "La nature textuelle de HTTP/1 le rend source de plusieurs problèmes de sécurité ; En effet, des implémentations différentes vont choisir de lire un message différemment et des programmes malintentionnés peuvent alors s'y immiscer (par exemple les attaques de response splitting".
- Ne vous attendez pas à ce que HTTP/2 améliore miraculeusement les performances de votre application ou de votre serveur. "Il est plus correct de voir ce nouveau protocole comme une solution supprimant d'anciens freins à la performance ; lorsque les navigateurs et les serveurs apprendront à en tirer parti, les performances devraient grimper". Comme Mark le souligne, la plupart des sites actuels ont été écrits en tenant compte des limitations de HTTP/1 et il faudra du temps pour qu'ils soient revus pour tirer profit des nouveautés de HTTP/2. "Un des inconvénients de cette meilleure connivence entre HTTP/2 et le réseau est de rendre la gestion de l'encombrement TCP plus visible ; maintenant que les navigateurs utilisent une seule connexion par domaine, la fenêtre initiale et la perte de paquets seront plus visibles".
- Si vous pensez que HTTP/2 a fini d'évoluer, vous pouvez reconsidérer. L'équipe se penche déjà sur la suite. "Actuellement, les gens attendent HTTP/2 avec impatience, du coup, de nouvelles fonctionnalités plus avancées ou expérimentales comme l'envoi de certificats TLS et les entrées DNS au client (tous les 2 pour améliorer les performances) ont été laissées de côté. HTTP/3 pourrait les voir arriver, si les tests se passent bien. Il se pourrait aussi que HTTP/3 devienne la version où la communauté vienne corriger tous les problèmes à côté desquels nous sommes passés, mais pour le moment la tendance est plus à la confiance compte tenu des essais de déploiements avec SPDY et des premières implémentations HTTP/2, qui montrent que HTTP/2 est bientôt prêt".
Et voilà. Un tour d'horizon de ce qui devrait bientôt arriver avec HTTP/2 grâce à Mark. Que pensez-vous de ces possibilités ? Quelque chose là-dedans qui vous inquiète ? Ou bien êtes-vous enthousiastes à l'idée de pouvoir utiliser ce nouveau protocole lorsqu'il sera plus populaire ?