Le standard HTTP 2.0 est devenu réalité !

Le contenu qui est envoyé via Internet a énormément évolué au cours de cette dernière décennie. Mais le protocole utilisé pour échanger ces données est resté le même – et avait en fait urgemment besoin d’être revu. Mais c’est désormais chose faite : HTTP/2 a en effet été présenté sous sa forme définitive la semaine passée. Voici donc quelques explications à ce sujet...

La manière dont l’utilisateur consomme du contenu sur Internet a fortement changé au cours de ces dernières années. Il regarde en effet davantage de vidéos, envoie plus de messages, et les réseaux sociaux détiennent une place centrale dans ce contexte, puisqu’ils suivent toutes ces interactions. D’autre part, les sites et services web sont eux aussi conçus autrement qu’avant : ils rassemblent du contenu provenant de toutes sortes de sources, obtiennent leurs annonces publicitaires d’ici, la surveillance de l’interaction avec les réseaux sociaux de là, etc. Conséquence : des quantités colossales de requêtes sont envoyées à beaucoup plus de serveurs.

Avec l’ancien protocole HTTP1, qui est déjà utilisé depuis 1999, ces requêtes étaient soigneusement traitées par ordre chronologique, ce qui avait pour conséquence qu’il suffisait d’une seule requête erronée pour que le chargement de la page soit sérieusement ralenti. Cela a donc obligé les développeurs à avoir recours à toutes sortes de stratagèmes, comme la création de code inline.

Le temps est venu pour un nouveau protocole de transfert hypertexte : HTTP/2

HTTP/2 fait en effet appel au multiplexage, grâce auquel plusieurs requêtes peuvent être transmises et traitées simultanément, de manière à ce que le chargement de la page ne puisse pas être bloqué. Avec HTTP/2, on utilise aussi beaucoup moins de connexions, ce qui devrait en principe entraîner une charge moins importante pour les serveurs et les réseaux.

Bien que HTTP/2 ait été développé par l’IETF HTTP Working Group, une organisation qui élabore et établit des standards Internet, le protocole est tout de même basé sur une version spéciale d’un autre protocole qui a en fait été développé par Google, à savoir SPDY (prononcez : « speedy »). Ses principales caractéristiques étaient la compression du champ d’en-tête (header field compression) et le multiplexage (multiplexing). SPDY est déjà intégré dans les navigateurs Chrome, IE et Firefox, mais n’est en général pas encore pris en charge par les sites web mêmes.

Google prend les devants

Le nouveau standard HTTP/2 est donc aujourd’hui devenu réalité, et Google est déjà partisane de le rendre disponible dès que possible sur Internet. Le géant de Mountain View a d’ailleurs annoncé qu’il utilisera HTTP/2 dans la prochaine version de son navigateur Chrome. Les développeurs qui souhaitent tester HTTP/2 sans plus attendre peuvent le faire en utilisant les navigateurs Firefox et Chrome. Il y a aussi des serveurs de test qui peuvent être téléchargés pour pouvoir tester l’une ou l’autre fonctionnalité. Pour de plus amples informations à ce sujet, n’hésitez pas à consulter la FAQ sur HTTP/2.

Des critiques dénoncent le manque de chiffrement

Les observateurs applaudissent le multiplexage des requêtes : grâce à lui, c’est un peu comme si vous pouviez inclure plusieurs lettres adressées au même expéditeur dans une seule enveloppe avant de les envoyer. Mais ils émettent toutefois des critiques sur le fait qu’avec HTTP/2, le chiffrement TLS n’est pas intégré, comme il était prévu de le faire initialement. À une époque où toutes sortes de hackers et de services de sécurité indiscrets fourrent sans cesse leur nez dans les communications des entreprises et des citoyens, un tel chiffrement semble tout de même conseillé. L’intégration du chiffrement TLS dans le nouveau protocole HTTP/2 a cependant dû être éliminée sous la pression des grands acteurs de l’industrie, comme les opérateurs de réseaux, car il aurait nécessité des efforts supplémentaires de leur part.

Mais cela ne signifie pas pour autant que SSL et TLS perdront de l’importance avec le nouveau protocole. Au contraire : les développeurs des navigateurs Firefox et Chrome ont déjà déclaré qu’ils ne prendront pas en charge HTTP/2 à moins qu’il ne permette aussi le chiffrement des données. En d’autres termes, les sites qui veulent bénéficier de la rapidité offerte par HTTP/2 devront aussi utiliser TLS.

Ou comment les sites sont incités à utiliser SSL en leur mettant la carotte de la rapidité devant le nez...