Résumé

  • ICPv2 a été conçu comme un protocole léger d’indices entre caches afin d’aider à choisir rapidement où tenter une récupération, non comme un mécanisme de certification du contenu ou du répondant.
  • HIT, MISS, MISS_NOFETCH, DENIED, écho, RTT et silence UDP ont chacun une portée précise : ils peuvent guider une décision locale, mais ne prouvent jamais à eux seuls la fraîcheur, l’autorité d’origine, l’identité authentifiée ou la livraison applicative.
  • HIT_OBJ réduit encore la séparation entre indice et transfert, mais son raccourci contourne l’autorisation HTTP et la validation d’âge, tout en restant distinct du problème général selon lequel les réponses ICP ne sont pas authentifiées.

Un protocole conçu pour choisir vite

RFC 2186, publié en septembre 1997 par D. Wessels et K. Claffy avec le statut Informatif, codifie ICPv2 comme un mécanisme léger permettant à des caches Web voisins de s’échanger des indications avant une récupération. Le problème n’est pas de prouver la valeur d’un objet, mais de choisir rapidement quel voisin paraît utile.

Cette orientation se lit directement dans le format. L’en-tête fixe mesure 20 octets et un message complet ne peut dépasser 16 384 octets. L’échange typique s’inscrit dans une attente d’environ une à deux secondes. Le protocole privilégie donc un signal court et exploitable plutôt qu’une négociation complète.

La logique de décision est particulièrement visible avec UDP. Lorsqu’aucune réponse n’arrive, ICPv2 ne tente pas de distinguer une congestion d’un chemin cassé, d’une panne du réseau ou d’une panne du système distant. Ces causes différentes sont volontairement ramenées à la même action : ne pas choisir ce voisin maintenant.

Ce silence ne démontre donc pas la cause de l’échec. Il ne prouve pas non plus que le voisin restera indisponible, ni qu’une autre source est intrinsèquement meilleure. Il suffit seulement à modifier le choix immédiat.

HIT est une indication de présence, pas une preuve de livraison

Un HIT signifie que l’URL est présente dans le cache qui répond et que ce demandeur est autorisé à y accéder. L’objet doit normalement être récupéré ensuite par HTTP. Le signal aide donc à choisir une source de récupération ; il ne constitue pas la récupération elle-même.

Cette distinction limite ce qu’un HIT peut prouver. À lui seul, il ne démontre ni l’autorité de l’origine, ni la fraîcheur du contenu, ni une validation HTTP réussie, ni l’identité authentifiée du répondant. Il ne prouve pas non plus que tous les octets seront obtenus, que leur rendu sera sûr, que ce voisin est la meilleure source possible, qu’il restera disponible ou que la transaction produira le résultat métier recherché.

MISS signifie que l’objet n’est pas présent dans le cache. Ce code peut néanmoins inviter le demandeur à passer par ce voisin pour effectuer la récupération. Il ne faut donc pas le lire comme une conclusion générale sur l’utilité du voisin.

MISS_NOFETCH décrit une autre situation : le cache est actif mais refuse temporairement de traiter les misses. Une reconstruction du store est un exemple de contexte compatible avec ce comportement. Le signal décrit un état du moment, sans permettre de conclure sur la disponibilité future.

DENIED doit lui aussi rester contextualisé. Le refus vaut pour ce demandeur, cette URL et cet instant. Un taux très élevé de DENIED suggère davantage une mauvaise configuration entre voisins qu’une intention malveillante. Le code exprime donc une décision d’accès, pas un diagnostic sur les motivations du répondant.

Corrélation et identité ne sont pas la même chose

Le numéro de requête est opaque et recopié dans la réponse. L’URL reste identique. Ces éléments permettent de corréler une réponse avec une requête, mais cette corrélation ne constitue pas une authentification.

Il faut également distinguer deux champs d’adresse que l’on pourrait facilement confondre. Le Sender Host Address n’est pas plus digne de confiance que l’adresse du pair observée par le transport. Son rôle était ambigu et, en pratique, le champ n’était pas utilisé.

Le Requester Host Address est un champ distinct. Sa valeur peut être entièrement nulle ; dans ce cas, cela signifie simplement que l’adresse n’est pas spécifiée. Cette valeur tout-zéro ne doit pas être attribuée au Sender Host Address.

Cette séparation illustre une règle plus générale : un champ présent dans le protocole n’acquiert pas automatiquement une valeur probante supérieure à ce que le mécanisme de transport permet déjà d’observer.

RTT et écho : utiles sans être décisifs

La source RTT peut contenir une mesure mémorisée, ne rien fournir d’exploitable ou valoir zéro. Le protocole précise que la collecte d’une mesure RTT ne doit pas retarder la réponse. La rapidité de la décision prime donc sur l’obtention d’une métrique complète.

Les signaux SECHO et DECHO ont eux aussi une portée limitée. Ils prouvent au plus que le mécanisme d’écho fonctionne. L’écho peut encore réussir alors que le cache est arrêté. Un écho positif ne constitue donc pas une preuve de disponibilité applicative.

Cette distinction entre connectivité élémentaire et fonctionnement utile est fondamentale. Un mécanisme peut répondre sans que la fonction recherchée soit disponible.

HIT_OBJ supprime une étape, mais aussi des contrôles

HIT_OBJ permet à une réponse ICP de transporter directement l’objet. Cette possibilité peut éviter la récupération HTTP séparée, mais elle change la nature du raccourci.

Le mécanisme est déconseillé et exige une activation explicite. Il peut contourner l’autorisation HTTP ainsi que la validation d’âge qui auraient été effectuées pendant une récupération HTTP normale. Ce contournement doit être distingué d’un autre fait : les réponses ICP elles-mêmes ne sont pas authentifiées. Ce sont deux limites différentes, même si elles peuvent se renforcer mutuellement.

La taille ajoute une contrainte supplémentaire. Un message dépassant le MTU du chemin peut être fragmenté. Si l’objet ne peut pas être inclus entièrement, les octets incomplets ne doivent pas être traités comme un objet complet : la réponse revient à un simple HIT.

Le risque de réponses forgées rend cette fonction particulièrement sensible. Une réponse usurpée peut pousser un cache à choisir un voisin ou à l’éviter. Les paquets multicast provenant de sources non configurées doivent être ignorés. Lorsque HIT_OBJ est utilisé, l’usurpation peut aller plus loin que la sélection d’un chemin et servir à introduire un objet indésirable dans le cache.

Lire chaque signal à sa juste portée

ICPv2 ne doit pas être confondu avec les directives de cache HTTP, l’histoire des CDN, le cache DNS ou une théorie générale de la fiabilité UDP. Ces sujets peuvent partager certains mots ou certaines contraintes, mais ils décrivent des mécanismes différents.

La distinction avec le cache HTTP est particulièrement importante. ICPv2 sert à orienter une tentative de récupération entre voisins. Les mécanismes HTTP déterminent séparément comment une réponse peut être réutilisée, validée ou considérée comme fraîche.

La valeur historique d’ICPv2 tient ainsi à une leçon simple : un signal faible peut être parfaitement utile si l’on conserve la frontière entre ce qu’il indique et ce qu’il ne prouve pas. Aucun signal ICP, pris isolément, ne garantit l’autorité d’origine, la fraîcheur, la validation HTTP, l’identité authentifiée, l’exhaustivité des octets, un rendu sûr, la meilleure source, la disponibilité future, la livraison applicative ou le résultat métier.