Le HTTP/2 est terminé et les navigateurs vont le supporter dans quelques semaines

HTTP2

L’Internet Engineering Task Force a enfin finalisé le HTTP/2 qui est le successeur du HTTP 1.0 et de HTTP 1.1. Le HTTP est la fondation même du web et donc, cette évolution sera l’une des plus importantes pour l’internet dans le futur. Le consortium a finalisé 2 normes. La première est le HTTP/2 proprement dit et le second est HPACK qui permet de compresser les entêtes HTTP/2.

Les problèmes avec le HTTP 1.x

Le travail sur le HTTP/2 a commencé en 2012 en réponse au protocole SPDY de Google. Google avait créer ce dernier pour résoudre des problèmes de performance avec le premier HTTP. Le principal problème avec le HTTP 1 est qu’il utilisait plusieurs connexions pour charger les ressources en parallèle (les images, le CSS, le Javascript, etc). Et tous ces composants se chargeaient l’un après l’autre ce qui provoquait des latences considérables. Et si un de ces composants échouait pendant le chargement, alors les autres dans la ligne pouvait attendre indéfiniment ce qui provoquait le problème bien connu des pages qui se chargent à l’infini.

Par la suite, la plupart des connexions en HTTP 1.x demandaient une requête sur un seul objet. Ce sont les navigateurs qui devaient faire le traitement en parallèle, mais cela nécessitait plusieurs connexions sur chaque serveur. Le résultat est que cela générait des ressources de réseau supplémentaires et le temps de chargement était plus long puisque chaque connexion individuelle nécessitait plusieurs transferts entre le client et le serveur.

Les solutions du HTTP/2

Le HTTP/2 résoud directement ce problème. Dans le HTTP/2, les flux bidirectionnels multiples sont multiplexés sur une seule connexion TCP. Chaque flux peut transporter une paire de requête/réponse et on peut effectuer plusieurs requêtes à un serveur en utilisant des flux multiples. Toutefois, les flux restent toujours indépendants et cela signifie que si l’un des flux devient lent pour une raison ou une autre, cela n’empêchera pas les autres flux de continuer le chargement. De même, un client peut demander un gros et un petit composant et la réponse pour le petit composant peut être donné avant ou même pendant la réponse du grand composant. Le concept d’attente des requêtes pour le traitement séquentiel qui existait dans le HTTP 1.x n’a plus de raison d’être dans le HTTP/2. Cette norme exige que les clients et les serveurs supporte au moins 100 flux différents sur une seule connexion.

Le HTTP/2 propose aussi des améliorations sur la performance et la stabilité. Le HTTP 1.x était un protocole de texte avec des requêtes et des réponses qui étaint conçus sur du texte. En revanche, le protocole HTTP/2 est binaire qui peut fractionner les requêtes et les réponses sur des cadres non lisibles par des humains et qui sont transmis sur une connexion TCP. Le HTTP/2 permet également aux serveurs de servir des flux aux clients même si ces derniers n’ont fait aucune demande.

Même si le HTTP/2 est un protocole binaire, il ne change pas le concept de base d’une connexion HTTP. Les requêtes et les réponses sont toujours divisés entre les entêtes et le corps. Les entêtes vont fournir les métadonnées importantes pour le corps, mais cette version le fera d’une manière plus efficace. Le HTTP/2 s’inspire principalement du SPDY de Google, mais il a supprimé certaines options. Le SPDY exigeait l’utilisation du TSL tandis que c’est facultatif dans le HTTP/2. Toutefois, certains fournisseurs ont déclarés qu’ils allait implémenter de facto le TSL pour avoir une meilleure sécurité.

SPDY utilisait également la compression Gzip pour les entêtes dans les 2 directions. Mais en 2012, on a découvert une faille dans Gzip qui permet de lancer une attaque connue sous le nom de CRIME. SPDY a arrêté d’utiliser Gzip tandis que le HTTP/2 a crée sa norme qui est le HPACK.

Le HPACK

Le HPACK est une manière de compresser les entêtes HTTP sur les connexions HTTP/2 pour éviter l’exploit CRIME. Contrairement à Gzip qui est un algorithme de compression général, HPACK est conçu spécifiquement pour les besoins du HTTP/2. Il reste encore des étapes avec la validation complète du HTTP/2 et du HPACK, mais elles deviendront bientôt des normes RFCs.

Les navigateurs vont supporter ces 2 protocoles dans les prochaines semaines. Chrome 40 va supporter le HTTP/2 et Google a annoncé l’abandon du SPDY. Mozilla a annoncé que Firefox 36 allait supporter cette norme en utilisant les versions 14 et 15 de la spécification et Firefox 37 et 38 vont également ajouter le support de la version 16. Microsoft n’est pas en reste puisque son nouveau navigateur, Spartan, va également supporter le HTTP/2.

Source

Advertisements

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s