Lorsque l'on parle des versions HTTP, on a généralement ces réflexions.

« De toute façon, le web c'est du HTTP, non ? Qu'est-ce qui est si différent entre 1.1 et 2 ? »
« On n'a qu'à utiliser la nouvelle version HTTP/2, non ? »

En résumé :

  • HTTP/1.1 vs HTTP/2 sont plus des « différences de manière d’envoyer le même HTTP » (méthodes, en-têtes, codes d'état, etc.) de manière plus efficace.

  • Dans les services réels, ce n'est pas « choisir l'un ou l'autre », mais plutôt le serveur supporte les deux et le client choisit celui qui est possible.

Je vais résumer les points clés du point de vue des développeurs ci-dessous.

1. Résumé rapide de HTTP/1.1

Commandbox 광고

1) Protocole basé sur du texte

HTTP/1.1 est ce que nous voyons communément sous cette forme de demande/réponse.

GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<html>...</html>

  • Étant basé sur du texte lisible par l'homme, il est facile de déboguer,

  • Et on peut comprendre la structure même en utilisant des outils comme curl, telnet ou nc.

2) Connexion persistante + Pipelining

Le gros problème de HTTP/1.0 était d'ouvrir une nouvelle connexion TCP pour chaque demande,
Mais dans HTTP/1.1, la connexion persistante (keep-alive) est devenue la norme,
permettant l'envoi de plusieurs demandes de manière séquentielle sur une seule connexion.

De plus, il y avait une fonctionnalité appelée HTTP pipelining :

  • Envoyer des requêtes de manière continue sans attendre la réponse

  • Recevoir les réponses dans l'ordre.

Cependant, elle n'a presque jamais été utilisée dans les navigateurs,
car elle restait « avec une structure qui doit être traitée dans l'ordre », laissant des problèmes de performance.

3) Problème de blocage HOL (Head-of-Line)

Le principal goulet d'étranglement de HTTP/1.1 est le blocage HOL.

  • Étant donné que les demandes doivent être traitées séquentiellement sur une connexion unique,

  • si la première demande ralentit, toutes les demandes suivantes doivent également attendre.

  • Pour cette raison, les navigateurs ont ouvert plusieurs connexions TCP pour un seul domaine (origine) (par exemple, jusqu'à 6) pour atténuer ce problème.

En résumé :

HTTP/1.1 est « une méthode de création de plusieurs tuyaux pour réduire le goulet d'étranglement ».
(Plusieurs connexions TCP)

2. Qu'est-ce qui est différent dans HTTP/2 ?

Les objectifs de HTTP/2 sont clairs.

  • Réduire la latence

  • Utiliser les ressources réseau de manière plus efficace

Les mots-clés principaux sont :

  1. Framing binaire (Binary Framing)

  2. Multiplexage basé sur des flux (Stream-based Multiplexing)

  3. Compression des en-têtes (HPACK)

  4. (À l'origine) Pousse du serveur (Server Push) – effectivement mort côté navigateur

2-1. De texte à framing binaire

HTTP/1.1 se base sur un parsing textuel ligne par ligne, mais HTTP/2 envoie tout sous forme de morceaux binaires appelés frames.

  • Les en-têtes sont des frames HEADERS

  • Le corps est une frame DATA

  • Ces frames appartiennent à un ID de flux spécifique.

Les développeurs n'ont généralement que peu d'interactions directes avec les frames,
mais cela permet d'implémenter des fonctionnalités telles que le multiplexage, la compression des en-têtes et la priorisation.

2-2. Multiplexage

C'est là où la différence se ressent le plus.

  • HTTP/1.1 : traite les demandes-réponses séquentiellement sur une connexion TCP

  • HTTP/2 : envoie plusieurs flux simultanément sur une seule connexion TCP

C'est-à-dire :

« Au lieu d'ouvrir plusieurs connexions TCP,
on peut intercaler les demandes et les réponses et les envoyer simultanément sur une seule connexion »

Ainsi :

  • Lorsque une page HTML doit récupérer des dizaines voire des centaines de ressources,

  • il est possible de le faire simultanément tout en maintenant une seule connexion,

  • particulièrement bénéfique dans des environnements mobiles ou à forte latence (RTT).

Cependant, le bloqueur HOL est toujours présent au niveau TCP, une zone qui a été améliorée avec HTTP/3 (QUIC).

2-3. Compression des en-têtes (HPACK)

Les en-têtes des requêtes/réponses HTTP contiennent beaucoup de redondances.

  • Comme Cookie, User-Agent, Accept-*, etc.

  • Ils peuvent peser des centaines de Ko à plusieurs Ko à chaque requête.

HTTP/2 utilise un mode de compression d'en-tête appelé HPACK
pour réduire la redondance entre ces en-têtes.

  • Les en-têtes couramment utilisés sont enregistrés dans une table pour être envoyés avec des index courts

  • Seules les parties qui diffèrent par rapport à la requête précédente sont efficacement encodées.

Grâce à cela, surtout pour les SPA à nombreuses requêtes / les pages riches en ressources, les gains sont considérables.

2-4. Pousse du serveur (Server Push) est en réalité mort

Au début de HTTP/2, la fonctionnalité de pousse du serveur qui permettait au serveur d'envoyer CSS/JS avant que le client le demande était perçue comme un atout, mais en pratique :

  • la complexité d'implémentation est élevée

  • problèmes liés aux caches et aux ressources en double

  • les améliorations de performance sont minimes ou même négatives dans certains cas

Pour cette raison, Chrome/Chromium a désactivé par défaut cette fonction depuis 2022 (Chrome for Developers)
Firefox envisage également de retirer le support dans les années 2020, donc dans l'écosystème des navigateurs, cette fonction est effectivement finie.

De nos jours, lorsque l'on parle de HTTP/2, la pousse du serveur peut être considérée comme une fonction « historique ».

3. HTTPS, ALPN, et « choix entre h2 et http/1.1 »

Commandbox 광고

Dans les services réels, se demande-t-on « Faut-il utiliser HTTP/1.1 ou HTTP/2 ? »
Le client et le serveur négocient automatiquement lors de la procédure de TLS Handshake.

Ce qui s'occupe de cela est une extension TLS appelée ALPN (Application-Layer Protocol Negotiation).

  • Client : « Je sais faire h2 et http/1.1 »

  • Serveur : « Alors utilisons h2 » (ou « Je ne peux faire que http/1.1 »)

Exemple de configuration Apache :

Protocols h2 http/1.1

Si vous laissez ceci configuré :

  • Les navigateurs modernes supportant HTTP/2 utiliseront HTTP/2 (h2) automatiquement

  • Les anciens clients communiqueront automatiquement en HTTP/1.1

La plupart des grands navigateurs supportent déjà bien HTTP/2,
et bon nombre de sites web ont activé HTTP/2.

4. « Dans quels cas faut-il les utiliser séparément ? » – Résumé du point de vue du développement

Jetons un œil à cette question clé au cas par cas.

4-1. Services web généraux (ciblant les navigateurs)

Stratégie proche de la bonne réponse :

« HTTPS + active HTTP/2 par défaut,
et laisser HTTP/1.1 en fallback. »

  • La plupart des serveurs web (Nginx, Apache, Envoy, etc.) et les CDN
    négocient automatiquement juste en activant l'option de support de HTTP/2.

  • Au niveau de l'application, il est rare d'avoir à diviser les demandes entre « un envoi en 1.1 et l'autre en 2 ».

Autrement dit, si vous créez un nouveau service, envisagez « HTTPS avec HTTP/2 activé » comme valeur par défaut.

4-2. Communication API interne / microservices

Ici, il existe quelques choix supplémentaires.

  • S'il fonctionne bien avec REST + HTTP/1.1,
    il n'est pas nécessaire de le réécrire en HTTP/2.

  • Cependant,

    • Si vous échangez beaucoup de courtes requêtes entre les mêmes services,

    • ou si vous utilisez un protocole comme gRPC basé sur HTTP/2,
      → il est naturel d'utiliser HTTP/2.

Donc :

  • « API REST légacy existante » → maintenez 1.1 + en cas de besoin, faites la terminaison HTTP/2 sur vos proxy/load balancers

  • « Nouvel ajout de gRPC, appels de microservices à haute fréquence » → exploitez activement HTTP/2

4-3. Débogage, journalisation, environnements légacy

Il existe encore des situations où HTTP/1.1 est utile.

  • Étant basé sur du texte, il est facile de voir le contenu avec tcpdump ou Wireshark

  • Les anciens proxies/firewalls/clients peuvent ne pas prendre en charge HTTP/2

  • Dans des outils internes simples ou des serveurs de test, il n'est pas nécessaire d'utiliser HTTP/2

Dans de nombreuses situations réelles :

  • Externe (navigateur) ↔ Proxy avant (CDN/Load Balancer) : HTTP/2

  • Proxy ↔ Service backend : HTTP/1.1

Il existe souvent des structures mélangées.

5. Une réponse réaliste à la question « Ne peut-on pas juste utiliser HTTP/2 ? »

Théoriquement :

« Pour les nouveaux services publics, on peut envisager HTTP/2 par défaut. »

C'est vrai.

Cependant, en pratique :

  1. Il est difficile d'éliminer complètement HTTP/1.1

    • Les anciens clients ou environnements spéciaux ne peuvent toujours utiliser que 1.1

    • Il y a souvent des situations où 1.1 est plus pratique pour le débogage, les outils ou les systèmes internes.

  2. Du point de vue du serveur, ‘supporter les deux’ est courant

    • En réglant les serveurs web avec h2 http/1.1, par exemple,

    • laissez le client choisir automatiquement le meilleur protocole qu'il prend en charge.

  3. Nous considérons aussi HTTP/3 (QUIC)

    • Les navigateurs et services récents prennent déjà en charge HTTP/3

    • Cependant, cela fonctionne généralement en gardant « HTTP/1.1 + HTTP/2 + HTTP/3 » ouverts simultanément,
      la structure permettant au client de négocier et de sélectionner.

Donc, la conclusion réaliste est :

« Il vaut mieux considérer
HTTP/2 comme valeur par défaut et utiliser HTTP/1.1 comme un fallback naturel. »

.

Comparaison des méthodes de transmission selon les versions HTTP

6. Résumé

En un coup d'œil :

  • HTTP/1.1

    • Basé sur le texte

    • Connexion persistante + (théorique) pipelining

    • Les problèmes de blocage HOL poussent les navigateurs à ouvrir plusieurs connexions TCP

  • HTTP/2

    • Framing binaire

    • Multiplexage permettant de gérer plusieurs flux simultanément sur une seule connexion TCP

    • Compression des en-têtes HPACK

    • La pousse du serveur est en réalité dans un état de mort pratique

  • Stratégie d'utilisation

    • Web externe (ciblant les navigateurs) : activez HTTPS + HTTP/2 et laissez HTTP/1.1 comme fallback

    • API internes : maintenir 1.1 pour des REST existants est OK, actif pour le haut débit/streaming/gRPC si c'est le cas

    • Débogage/légacy : HTTP/1.1 est encore viable et utile

Une phrase bonne à garder en tête pour les développeurs :

« Ne vous inquiétez pas pour le choix de la version dans le code de l'application,
activez HTTP/2 sur le serveur et laissez le reste à la négociation des protocoles (ALPN). »