Résumé

  • Dans RFC 2187, parent et sibling sont des rôles de service configurés. Un sibling peut fournir un HIT qu’il possède déjà ; il ne doit pas devenir transit pour un MISS. Un parent peut résoudre HIT et MISS, tandis que l’origine reste une voie distincte.
  • ICP apporte des indices de disponibilité et de sélection, pas une délégation générale d’autorité. HIT, MISS, RTT, timeout, multicast ou objet retourné ne prouvent chacun qu’un fait borné dans une transaction et une configuration données.
  • La frontière documentaire compte : RFC 2186 décrit le format et les opcodes d’ICPv2 ; RFC 9211 standardise bien plus tard l’observabilité de la manière dont des caches HTTP ont traité une requête et une réponse.

La lecture la plus utile de RFC 2187 commence par un détail qui paraît presque banal : « parent » et « sibling » ne sont pas des coordonnées. Le document présente bien un parent comme situé un niveau plus haut dans une hiérarchie et un sibling au même niveau, mais il définit leur différence décisive par ce qu’ils sont autorisés à faire. Lorsqu’un voisin annonce un HIT, le cache local peut récupérer l’objet auprès d’un parent ou d’un sibling. Lorsqu’il n’y a que des MISS, le sibling sort de la course : il faut choisir un parent ou l’origine.

La figure centrale du texte sépare ainsi les HIT servis par un sibling, les HIT et MISS résolus par un parent et certaines récupérations directes auprès du serveur d’origine.

Cette logique interdit de réduire la hiérarchie à une carte de proximité physique. Un parent pouvait idéalement se trouver sur le chemin d’un fournisseur de transit, mais son rôle n’était pas déduit d’une distance. Il était établi par configuration et contrôle d’accès. La même machine pouvait même être traitée comme sibling pour une classe de requêtes et comme parent pour une autre. La topologie pertinente était donc d’abord une topologie de permission et de traitement.

L’exemple de configuration de RFC 2187 rend cette séparation très concrète. Un côté déclare l’autre comme parent ou sibling ; l’autre applique ses propres listes d’accès et peut refuser les MISS pour imposer un comportement de sibling. Le type de relation n’est pas encodé dans la requête ICP elle-même. Le message reçu dit quelque chose sur une URL ou un résultat local ; la relation opérationnelle résulte de politiques installées aux extrémités. Un label de voisin ne prouve donc ni autorité réciproque ni politique symétrique.

C’est ici qu’ICP doit être compris comme un système de preuves locales. Un ICP_OP_HIT signifie, dans la logique décrite, que l’URL se trouve dans le cache répondant et qu’une requête HTTP suivante est censée produire un hit. Mais la RFC reconnaît une condition de course : l’objet peut être évincé avant la requête HTTP. Le HIT est donc fort pour la question immédiate qu’il traite, pas pour l’état futur du voisin, la fraîcheur durable ou la capacité à servir d’autres demandes.

Le MISS est encore plus révélateur. Un ICP_OP_MISS venant d’un sibling est ignoré pour la sélection de la source, précisément parce que ce sibling n’est pas censé fournir le transit nécessaire. Le même opcode venant d’un parent peut, au contraire, être retenu pour le repli et vaut invitation à récupérer l’URL via ce parent. Un ICP_OP_MISS_NOFETCH ferme explicitement cette possibilité. La conséquence ne réside donc pas dans l’opcode seul : elle dépend du couple signal-rôle.

Même la latence n’acquiert jamais le statut d’autorité. Harvest et Squid pouvaient mémoriser le premier parent ayant répondu MISS ; Squid permettait de pondérer les RTT, parce que le parent au RTT le plus faible n’était pas nécessairement celui que l’opérateur voulait utiliser. Avec ICP_FLAG_SRC_RTT, une instance pouvait aussi considérer un RTT vers l’origine, voire préférer l’accès direct si l’origine paraissait plus proche. La mesure nourrit une décision ; elle ne remplace pas la politique et ne prouve pas le chemin économiquement le moins cher.

Le timeout révèle la même architecture de responsabilité. ICP fonctionne sur UDP et la RFC prévoit des réponses perdues. Squid et Harvest installaient donc un délai d’attente — deux secondes par défaut dans les versions décrites — puis choisissaient une source lorsque les réponses attendues étaient arrivées ou que le délai expirait. Si aucun parent approprié n’émergeait, l’origine pouvait être choisie directement, sauf contrainte de pare-feu. Derrière un pare-feu empêchant cette sortie, il fallait un parent de repli ou une autre règle de sélection. ICP ne garantissait pas à lui seul la continuité : le déploiement la construisait.

Le multicast renforce cette responsabilité locale. RFC 2187 autorise l’envoi de requêtes ICP vers une adresse multicast, mais avertit qu’une adhésion au groupe ne confère aucune confiance. Les messages provenant d’adresses non configurées comme voisins doivent être ignorés. L’adhésion multicast prouve donc au mieux une présence technique dans le groupe, pas une relation bilatérale, une permission de transit ou une identité authentifiée.

La sécurité ferme le cercle. RFC 2187 note qu’ICPv2 n’intègre pas de champ d’authentification. L’adresse source et la liste des voisins connus constituent un premier filtre, mais le texte souligne la vulnérabilité à l’usurpation d’adresse IP et décrit comment de fausses réponses pourraient forcer ou empêcher l’usage d’un voisin. ICP_OP_HIT_OBJ est particulièrement sensible parce qu’il peut transporter directement l’objet. Un objet reçu n’est donc pas, par sa seule présence, une preuve cryptographique de son identité ou de son innocuité.

La distinction avec RFC 2186 est essentielle. RFC 2186 décrit le format du message ICPv2 — en-tête, opcodes, champs et charge utile — et la possibilité d’utiliser les réponses comme aide à la sélection. RFC 2187 documente l’application de ce protocole dans des hiérarchies de caches, avec leurs contrôles, leurs choix et leurs faiblesses. Le format ne détermine pas à lui seul le contrat d’usage.

La RFC 3040, taxonomie ultérieure de la réplication et du cache Web, élargit le cadre en distinguant plusieurs architectures et mécanismes, avec des objectifs comme la réduction du temps de réponse, de la bande passante ou de la charge serveur. Elle mentionne aussi des services commerciaux de distribution de contenu. Ce recul empêche de projeter mécaniquement le « parent » d’ICP sur l’économie d’un CDN moderne : un rôle de transit dans une hiérarchie ne prouve ni contrat, ni prix, ni propriété de capacité, ni préférence commerciale.

Les problèmes recensés par la RFC 3143 renforcent cette prudence. Le document relève que sélectionner un peer selon la première réponse peut mal optimiser la latence finale et qu’ICP peut mal passer à l’échelle lorsque le nombre de peers augmente. Il note aussi qu’un maillage peut renvoyer un contenu plus ancien selon le chemin suivi. Une récupération réussie ne démontre donc ni que le chemin était le moins coûteux, ni qu’il restera le plus rapide, ni qu’il garantira la même fraîcheur lors d’une requête suivante.

Il faut également séparer ICP du cache-control HTTP générique. RFC 2187 reconnaissait déjà que la prédiction d’une future requête pouvait dépendre d’autres champs HTTP, notamment Cache-Control. ICP échange un indice compact ; les règles complètes de validation, de réutilisation et de fraîcheur d’une réponse ne se réduisent pas au couple HIT/MISS.

Un quart de siècle plus tard, RFC 9211 formalise une autre couche : Cache-Status, destiné à expliquer comment un ou plusieurs caches ont traité une requête et sa réponse. Son paramètre hit indique qu’une requête a été satisfaite par le cache sans être transmise ; d’autres paramètres décrivent notamment transfert, stockage ou durée de fraîcheur. C’est de l’observabilité de livraison, pas un protocole de choix de voisin comparable à ICP. Même une trace précise ne prouve pas, à elle seule, l’autorité mutuelle des opérateurs, leur capacité future, une livraison complète jusqu’à l’utilisateur ou le résultat économique de la chaîne.

Le fil directeur est donc institutionnel autant que technique. RFC 2187 décrit un système où les machines échangent des indices tandis que les opérateurs décident de leur portée. La configuration choisit les peers, les domaines concernés, les exceptions, les poids, les délais, le comportement sous pare-feu et le repli. La relation sibling limite le droit de transit ; la relation parent l’élargit ; l’origine demeure une option distincte lorsque politique et connectivité l’autorisent.

Cette séparation offre une grille de preuve rigoureuse. Un label de voisin prouve une désignation locale, pas une autorité réciproque. Un HIT prouve un état annoncé à un instant, pas la fraîcheur future ni l’identité authentifiée. Un RTT prouve une mesure dans certaines conditions, pas le coût total. Une pondération prouve une préférence configurée, pas une qualité intrinsèque. Une adhésion multicast prouve une présence dans un groupe, pas la confiance. Un objet retourné prouve qu’un objet a été fourni, pas qu’il est sûr.

Une récupération réussie prouve l’achèvement d’une étape, pas nécessairement la livraison de bout en bout ni la valeur économique créée.

La force historique de RFC 2187 est d’avoir documenté assez précisément les mécanismes pour empêcher ces glissements. Sa hiérarchie n’est pas une carte disant qui est « proche » : c’est un ensemble de permissions, de préférences et de sorties de secours dans lequel chaque preuve reste relative à une question bien bornée.