Quand un navigateur ouvre une page en HTTPS, il ne se contente pas de chiffrer la connexion. Il doit aussi se mettre d’accord avec le serveur sur la façon de parler : HTTP/1.1, HTTP/2, parfois HTTP/3 via un autre mécanisme. Cette étape discrète, appelée négociation ALPN, joue un rôle central dans l’adoption de HTTP/2 et dans les performances perçues par les internautes.
ALPN signifie Application-Layer Protocol Negotiation. Il s’agit d’une extension de TLS, normalisée dans la RFC 7301, qui permet au client et au serveur de choisir le protocole applicatif à utiliser pendant l’établissement de la connexion sécurisée. Dans le cas de HTTP/2, cette négociation sert à déterminer si la session HTTPS utilisera le protocole h2 ou restera en HTTP/1.1.
Concrètement, le navigateur annonce au serveur une liste de protocoles qu’il sait gérer. Cette liste peut par exemple contenir h2 et http/1.1. Le serveur compare cette proposition avec sa propre configuration, puis sélectionne un protocole compatible. Si tout est correctement configuré, HTTP/2 est retenu. Sinon, la connexion peut basculer vers HTTP/1.1 sans que l’utilisateur ne voie nécessairement d’erreur.
HTTP/2 a été conçu pour améliorer l’efficacité du Web : multiplexage des requêtes, compression des en-têtes, meilleure utilisation d’une connexion TCP unique. Mais pour qu’un navigateur puisse l’utiliser, il doit savoir dès le début de l’échange quel protocole employer. Sans mécanisme de négociation clair, il faudrait tenter une méthode, échouer éventuellement, puis recommencer, ce qui ralentirait l’accès aux pages.
Avant ALPN, une extension appelée NPN, pour Next Protocol Negotiation, avait été expérimentée, notamment par Google. Elle n’a toutefois pas été standardisée de la même manière et a progressivement été abandonnée. ALPN a pris le relais en s’intégrant proprement à TLS, ce qui a facilité son adoption par les navigateurs, les serveurs web et les CDN.
La négociation ALPN intervient pendant le handshake TLS, avant que les données HTTP ne soient envoyées. Le client commence par transmettre un message ClientHello. Dans ce message, il indique les versions TLS acceptées, les suites cryptographiques possibles, le nom de domaine visé via SNI, et la liste des protocoles applicatifs proposés par ALPN.
Le serveur répond ensuite en choisissant une option. Avec TLS 1.2, la sélection ALPN apparaît dans la réponse du serveur. Avec TLS 1.3, elle est placée dans les extensions chiffrées du handshake. Dans les deux cas, l’objectif reste le même : établir une session sécurisée en sachant immédiatement si les échanges HTTP utiliseront HTTP/2 ou HTTP/1.1.
Cette logique rappelle un principe fréquent dans les infrastructures Internet : deux systèmes doivent annoncer leurs capacités avant d’échanger efficacement. À une autre échelle, le routage interdomaines repose aussi sur des annonces et des décisions entre réseaux, comme l’illustre le fonctionnement du dialogue entre réseaux autonomes.
Le navigateur joue le rôle du client ALPN. Chrome, Firefox, Safari ou Edge proposent généralement h2 et http/1.1 lorsqu’ils se connectent à un site HTTPS compatible. Le serveur, de son côté, doit être configuré pour accepter HTTP/2. Sur Nginx, Apache, Caddy ou certains services managés, cette activation dépend de la version du logiciel, des modules disponibles et des paramètres TLS.
Le certificat TLS n’active pas HTTP/2 à lui seul. Il garantit l’identité du site et permet le chiffrement, mais ALPN dépend de la pile TLS et de la configuration du serveur. Un site peut donc avoir un certificat parfaitement valide et rester en HTTP/1.1 si HTTP/2 n’est pas activé ou si le reverse proxy placé devant l’application ne le prend pas en charge.
Cette distinction est importante, car les mécanismes réseau et les mécanismes d’authentification sont souvent confondus. Dans l’e-mail, par exemple, un enregistrement DNS peut contribuer à vérifier l’origine d’un message, comme dans le cas d’un contrôle SPF publié dans le DNS, mais il ne remplace pas les autres couches de sécurité.
Imaginons un internaute qui visite un site d’actualité en HTTPS. Son navigateur ouvre une connexion vers le port 443 du serveur et envoie un ClientHello contenant notamment la liste ALPN suivante : h2, puis http/1.1. Le serveur, configuré avec HTTP/2, répond en sélectionnant h2. Dès la fin du handshake TLS, le navigateur sait qu’il peut envoyer des requêtes HTTP/2.
La différence ne se voit pas dans l’URL, qui reste une adresse commençant par https. Elle se constate dans les outils de développement du navigateur, dans les journaux du serveur ou avec des commandes de diagnostic comme openssl s_client avec l’option alpn. Les administrateurs peuvent ainsi vérifier si le protocole négocié est bien h2.
Lorsque HTTP/2 est actif, plusieurs ressources d’une même page peuvent transiter sur une seule connexion. Images, fichiers CSS, scripts et réponses API sont multiplexés, ce qui évite une partie des blocages typiques de HTTP/1.1. Le gain dépend toutefois du site, de la latence, du poids des ressources et de la qualité de la configuration côté serveur.
Une négociation ALPN ne débouche pas toujours sur HTTP/2. Le cas le plus simple est celui d’un serveur qui ne propose pas h2. Le client annonce h2 et http/1.1, mais le serveur ne retient que http/1.1. La connexion reste valide, simplement moins moderne sur le plan du protocole applicatif.
D’autres causes sont plus subtiles. Un proxy inverse peut terminer TLS en frontal et ne pas transmettre HTTP/2 vers l’arrière-plan. Une ancienne bibliothèque OpenSSL peut ne pas gérer ALPN. Un pare-feu applicatif ou un répartiteur de charge peut aussi imposer une configuration limitée. Dans certains environnements, HTTP/2 est désactivé volontairement après des incidents liés à des implémentations vulnérables ou mal dimensionnées.
Ces retours à HTTP/1.1 ne sont pas forcément catastrophiques, mais ils peuvent réduire les bénéfices attendus. C’est comparable à d’autres mécanismes du Web qui fonctionnent correctement uniquement si plusieurs couches sont alignées. Le code 304 Not Modified dans la gestion du cache, par exemple, dépend à la fois des en-têtes HTTP, du navigateur et de la configuration serveur.
ALPN n’accélère pas directement une page par magie. Son intérêt est d’éviter une négociation supplémentaire après l’établissement de TLS. Le protocole applicatif est choisi pendant la poignée de main sécurisée, ce qui réduit les ambiguïtés et permet d’utiliser immédiatement HTTP/2 lorsque les deux parties le supportent.
Sur le plan de la sécurité, ALPN profite du cadre TLS. La négociation est associée à la session chiffrée, ce qui limite les risques de désaccord entre ce que le client croit utiliser et ce que le serveur accepte réellement. Cela ne rend pas un site invulnérable, mais cela réduit la surface d’erreur liée au choix du protocole.
Il faut également distinguer HTTP/2 de HTTP/3. HTTP/3 repose sur QUIC, au-dessus d’UDP, et n’utilise pas ALPN de la même façon dans une connexion TCP classique. Les identifiants de protocole existent toujours, mais le transport change. Cette évolution s’inscrit dans un mouvement plus large de modernisation d’Internet, visible aussi avec le déploiement progressif d’adresses IPv6 sur les réseaux publics.
Pour vérifier ALPN, plusieurs approches existent. Les outils de développement des navigateurs indiquent souvent le protocole utilisé pour chaque requête. Des services de test TLS en ligne affichent aussi la présence d’ALPN et la compatibilité HTTP/2. En ligne de commande, openssl permet d’observer le protocole sélectionné lors d’une connexion vers un domaine donné.
Côté configuration, les points à contrôler sont connus : disposer d’une version récente du serveur web, activer HTTP/2 sur le port 443, utiliser une bibliothèque TLS compatible ALPN et vérifier la configuration du CDN ou du load balancer. Sur Nginx, par exemple, HTTP/2 s’active au niveau de l’écoute TLS. Sur Apache, le module HTTP/2 doit être présent et correctement déclaré.
Enfin, ALPN doit être considéré comme une pièce d’un ensemble. Un site rapide et robuste dépend aussi du cache, de la compression, du DNS, du routage, de la sécurité applicative et de la qualité du code. De la même manière, la lutte contre les abus en ligne ne repose jamais sur un protocole unique, comme le montre la limite structurelle du protocole SMTP face au spam.
