Le Web a maintenant 25 ans et la manière dont votre navigateur communique avec un site Web n’a pas changé depuis. Notre façon d’utiliser Internet a changé en revanche, et les limites du protocole HTTP/1 commencent à apparaître. Le chargement de pages Web pourrait être plus rapide et utiliser le réseau de manière plus efficace. Cela s’explique notamment car HTTP/1 permet seulement une connexion TCP par requête à la fois.
Cela représente un gros problème depuis que les pages Web modernes ont souvent besoin de plus d’une centaine de requêtes pour charger des contenus JavaScript, CSS, ainsi que des images. Aujourd’hui, les navigateurs utilisent de nombreuses connexions pour chaque site afin de charger tous ces actifs. Ils ne peuvent cependant pas trop en utiliser car cela pourrait surcharger le réseau en aggravant cet encombrement. C’est pourquoi ils utilisent actuellement entre quatre et huit connexions, en devinant quelle requête envoyer à quel serveur, quitte à parfois faire des erreurs.
Le grand nombre de requêtes sur une page Web moderne cause également un autre problème : chaque requête présente un set de titres HTTP qui a grandi avec le temps, à cause d’éléments tels que les cookies, qui font grimper le nombre de données à envoyer. Cela a un impact significatif sur la performance des réseaux mobiles à forte latence. Tout cela a contribué à rendre HTTP/1 lent et de plus en plus complexe à utiliser. De nombreux sites essaient de s’occuper de ces problèmes avec des techniques de piratage informatique, d’impression CSS, d’extension inline et de concaténation. S’ils aident à résoudre des problèmes, ces actes de piratage pointent aussi du doigt des lacunes évidentes.
C’est sur ce constat que les travaux sur HTTP/2 ont débuté. Ce nouveau protocole, basé sur le projet SPDY (speedy), permet à une connexion d’être utilisée pour toutes les communications entre votre navigateur Web et le site Web. Cela se fait en séparant les messages de requêtes et de réponses en petit morceaux appelés « frames » ou « trames » et en les étiquetant de manière à ce qu’ils soient rassemblés une fois parvenus à leur destinataire.
Ce procédé est appelé multiplexage, et permet au réseau d’être utilisé de manière bien plus efficace parce que de nombreux messages peuvent transiter en même temps, à la différence de HTTP/1. En outre, HTTP/2 permet aux titres (en-têtes) d’être compressés, ce qui veut dire que la bande passante n’est pas gâchée par la répétition d’informations redondantes. Les pages Web peuvent ainsi être chargées plus rapidement même si elles nécessitent un plus grand nombre de requêtes, aussi nombreuses qu’elles soient, car elles prennent moins de temps pour traverser le réseau. D’autres optimisations comme le server-push permettent à un site d’envoyer des réponses au navigateur avant qu’elles ne soient demandées, ce qui, encore une fois, améliore la performance.
Les premiers résultats indiquent que passer sur HTTP/2 permet souvent, mais pas toujours, de gagner entre 5 et 15 pourcent de performance. Avec une mise au point, cette amélioration peut être bien plus importante. Il est important de savoir que le nouveau protocole ne change pas les méthodes HTTP utilisées. Les en-têtes ou codes de statuts que le protocole HTTP API utilise devraient ressembler à la même chose. HTTP/2 peut même être utilisé sur une base point par point (hop by hop), pour que vous n’ayez pas à mettre à jour la totalité de votre infrastructure simultanément.
HTTP/2 est presque terminé. Il devrait être bientôt compatible avec les navigateurs Web populaires comme Firefox, Internet Explorer, et Google Chrome. Akamai va également soutenir HTTP/2, intégrant ce nouveau protocole dans une grande partie du Web.