HTTP/1.1, HTTP/2 et HTTP/3 : Évolution des protocoles Web

Comment HTTP a évolué : de la version 1.1 à 3

HTTP est le protocole qui alimente le Web — c'est le langage que les navigateurs et les serveurs utilisent pour communiquer entre eux. Au fil des ans, il a connu trois versions majeures, chacune répondant aux limitations de la précédente. Comprendre les différences vous aide à apprécier pourquoi le Web ne cesse de s'accélérer.

HTTP/1.1 : Le cheval de bataille du Web primitif

HTTP/1.1 existe depuis la fin des années 1990 et est encore largement utilisé. C'est un protocole basé sur le texte — vous pouvez réellement lire les requêtes et les réponses. Chaque requête est envoyée en texte brut, et la réponse revient en texte brut, avec des en-têtes décrivant des éléments comme le type de contenu, les règles de mise en cache et l'état de la connexion.

La principale limitation de HTTP/1.1 est qu'il ne peut gérer qu'une seule requête à la fois par connexion. Si une page a besoin de dix images, le navigateur doit soit attendre que chacune se termine avant de demander la suivante, soit ouvrir plusieurs connexions (généralement six par domaine). Au début, les développeurs contournaient ce problème en utilisant plusieurs noms de domaine et en combinant de nombreuses petites images en une seule feuille de sprites.

HTTP/2 : Un grand bond en avant

HTTP/2 a changé la donne en passant du texte à un format binaire. Cela peut sembler un détail technique, mais cela a permis quelque chose d'important : le multiplexage. Au lieu d'attendre qu'une requête se termine avant d'en commencer une autre, plusieurs requêtes et réponses peuvent être envoyées simultanément sur une seule connexion. Plus besoin de faire la queue.

HTTP/2 a également introduit la compression des en-têtes, qui réduit la surcharge des en-têtes répétés sur plusieurs requêtes, et le push serveur, qui permet au serveur d'envoyer des ressources avant même que le navigateur ne les demande. En pratique, le plus grand avantage est qu'une seule connexion est beaucoup plus efficace que les six connexions nécessaires à HTTP/1.1.

HTTP/3 : Conçu pour le monde mobile

HTTP/3 est la version la plus récente, et elle est fondamentalement différente de ses prédécesseurs. Au lieu de fonctionner sur TCP, il fonctionne sur QUIC, qui est construit au-dessus d'UDP. Cela peut sembler un petit changement, mais il a des implications significatives sur les performances.

TCP a un problème appelé blocage de tête de ligne : si un seul paquet est perdu, toutes les données suivantes doivent attendre qu'il soit retransmis, même si les autres données ne sont pas liées. QUIC résout ce problème en traitant chaque flux indépendamment — un paquet perdu sur un flux n'affecte pas les autres. QUIC chiffre également tout par défaut, réduit le temps d'établissement de la connexion et peut survivre aux changements de réseau (comme le passage du Wi-Fi aux données mobiles) sans perdre la connexion.

Lequel devriez-vous utiliser ?

Il n'y a aucune raison de n'en choisir qu'un. Les serveurs modernes peuvent prendre en charge les trois versions et négocier la meilleure avec chaque client. HTTP/1.1 est toujours acceptable pour les API simples et les systèmes hérités. HTTP/2 est la norme pour la plupart des sites Web de production aujourd'hui. HTTP/3 est particulièrement bénéfique pour les utilisateurs mobiles, les personnes sur des réseaux à haute latence et les publics mondiaux. À mesure que la prise en charge de QUIC mûrit, HTTP/3 deviendra la valeur par défaut.

Activer HTTP/2 et HTTP/3 sur votre serveur est simple avec des serveurs Web modernes comme NGINX, Caddy ou Cloudflare. Le navigateur gère la négociation automatiquement, de sorte que vos visiteurs obtiennent le meilleur protocole disponible sans aucun changement de leur côté.