Résumé

  • Alt-Svc permet à une origine d’annoncer un autre protocole, hôte et port par lesquels ses ressources peuvent être disponibles sans changer l’URI d’origine.
  • Une annonce encore fraîche ne prouve pas qu’un client donné a atteint l’alternative, l’a authentifiée pour l’origine, a négocié le protocole attendu ou y a réussi une requête.
  • Le choix du client est facultatif, le contexte réseau compte et l’échec d’une alternative peut déclencher un repli dont les propriétés doivent être observées.
  • Un reçu de chemin alternatif doit relier âge de l’annonce, identité de l’origine, authentification, résultat ALPN, choix du client, résultat de la requête et repli depuis un même point d’observation.

Imaginons un service qui renvoie Alt-Svc: h3=":443"; ma=86400. Un tableau de déploiement voit l’en-tête à l’origine et déclare la migration HTTP/3 achevée. Sur un réseau d’accès, pourtant, la connexion alternative ne peut pas être établie. Les clients continuent discrètement sur la connexion d’origine, les requêtes aboutissent et la disponibilité globale reste verte. L’annonce était réelle, mais le changement de chemin revendiqué n’a jamais eu lieu pour cette population.

Il s’agit d’une trace hypothétique, non d’un incident attribué à un fournisseur. Le mécanisme fonctionne normalement. L’erreur consiste à confondre l’admissibilité d’une route avec son exécution.

Le routage alternatif conserve l’origine

Le RFC 7838 définit les services HTTP alternatifs afin que les ressources d’une origine soient disponibles de manière autoritative à un autre emplacement réseau, éventuellement avec un protocole différent. L’alternative associe protocole applicatif, hôte et port. C’est une information de routage pour l’origine, pas une redirection qui change l’URI.

Le contexte de sécurité suit cette identité. Le logiciel situé au-dessus du mécanisme d’accès HTTP continue de voir le schéma, l’hôte et le port d’origine. Avec TLS, l’alternative doit présenter un certificat valable pour le nom d’hôte de l’origine, non seulement pour celui de l’alternative.

L’annonce ne démontre pas cette authentification. Elle indique une nomination par l’origine. La preuve d’un usage sûr commence avec la connexion réellement établie et l’identité réellement vérifiée par le client.

Admissibilité, négociation et usage sont des événements distincts

Les services alternatifs sont facultatifs pour les clients. Un client peut choisir parmi les alternatives fraîches selon ses propres critères et continuer sur une connexion existante pendant qu’il établit l’autre. L’ordre de préférence du serveur n’est donc pas le journal de la décision du client.

Le RFC 7301 définit la négociation du protocole applicatif dans TLS. RFC 7838 exige de considérer l’alternative comme défaillante si la connexion ne négocie pas le protocole attendu. Une socket joignable ou une négociation TLS terminée ne suffit pas si le protocole annoncé n’a pas été sélectionné.

Pour HTTP/3, le RFC 9114 transporte la sémantique HTTP sur QUIC et utilise le jeton ALPN h3. Voir h3 dans Alt-Svc n’est pas établir QUIC, négocier HTTP/3 et achever une requête. Chaque transition mérite un compteur séparé.

Alt-Used peut indiquer au serveur qu’une requête a utilisé une alternative. Son observation dépend toutefois du point de mesure : origine, CDN, client et sonde synthétique ne voient pas la même tranche du choix. Toute affirmation crédible nomme son point d’observation.

La fraîcheur n’est pas l’état de santé

Alt-Svc possède sa propre durée de fraîcheur. ma fixe la période pendant laquelle l’information peut servir à établir de nouvelles connexions, indépendamment du cache HTTP ordinaire. Une nouvelle valeur remplace les alternatives en cache et clear les invalide.

La fraîcheur signifie que l’annonce reste admissible selon ces règles. Elle ne garantit ni la joignabilité actuelle, ni un chemin depuis tous les réseaux, ni l’autorisation de QUIC à chaque frontière de politique, ni la capacité ou la latence attendue.

Lors d’un changement de réseau détecté, les clients effacent normalement les alternatives dépourvues de persist=1. Même une annonce persistante suggère seulement que la route pourrait rester utile. Elle ne certifie pas la joignabilité ou la politique du nouveau réseau.

Le repli peut préserver le service et masquer l’échec

RFC 7838 autorise le repli vers l’origine ou une autre alternative si le service choisi échoue ou ne répond pas. Cela protège la disponibilité tout en pouvant masquer l’échec d’une migration. Une requête réussie ne dit rien du chemin voulu si le chemin réel n’est pas identifié.

Le repli peut aussi perdre des propriétés de sécurité et créer une possibilité de déclassement. Le reçu doit conserver quelle alternative a échoué, comment, quelle route l’a remplacée, si ce repli était permis et quelle propriété a changé.

Disponibilité, adoption de l’alternative et sûreté du repli sont donc trois mesures différentes. Un seul taux de réussite ne peut les représenter toutes.

Clore le changement par un reçu de chemin alternatif

Ouvrez le reçu à l’observation de l’annonce. Enregistrez l’origine, la valeur Alt-Svc exacte, la source de la réponse, l’heure, l’âge calculé, ma, persist, le contexte réseau et la cohorte client. Conservez si l’annonce venait directement de l’origine ou d’une réponse en cache, puis si une valeur ultérieure l’a remplacée ou effacée.

Pour chaque tentative, notez hôte et port atteints, authentification du nom d’origine, ALPN proposé et négocié, résultat de connexion, raison du choix client, statut de requête, latence, observation d’Alt-Used et éventuel repli. Les échecs et contournements expliquent pourquoi une annonce fraîche n’est pas devenue du trafic.

Ne clôturez une affirmation de déploiement que pour la population et la période couvertes. L’annonce prouve la nomination, l’authentification l’autorité de l’origine, ALPN le protocole, et la requête l’usage et le résultat. Le chemin n’est prouvé que lorsque ces événements sont reliés à un point d’observation nommé.

Sources