Résumé

  • La RFC 3466 décrit comment des réseaux de contenu indépendants pourraient partager des ressources pour accroître leur échelle ou leur portée.
  • Elle définit un modèle informatif, non un protocole de peering, un tarif, une autorisation de service ou la preuve d’une coopération réelle.

Le paquet ne racontait plus toute l’histoire

Un navigateur demandait une image. Le serveur d’origine pouvait être lointain, le cache voisin ne pas détenir l’objet, et un seul fournisseur ne pas disposer d’assez de sites pour servir tous les publics. Au début des années 2000, une partie de la réponse se trouvait désormais dans des systèmes qui examinaient les requêtes applicatives et le contenu, pas uniquement les en-têtes IP.

Publiée en février 2003, la RFC 3466 nomma ce niveau un « réseau de contenu ». Son vocabulaire décrivait des fonctions des couches 4 à 7, chargées des demandes et réponses portant sur des objets qui pouvaient traverser de nombreux paquets. Il ne remplaçait pas le routage IP. Il identifiait un autre plan de coordination : savoir quel contenu était disponible, où diriger la demande, comment déplacer les copies et comment comptabiliser l’activité.

Le texte écarta aussi une analogie séduisante. « Content peering » ou « CDN peering » évoquait une interconnexion comparable à celle des réseaux IP, avec des attentes parfois tacites d’ouverture, de réciprocité ou de règlement. Le groupe privilégia « content internetworking ». Ce changement de nom ne résolvait pas le problème ; il évitait de confondre des systèmes différents sous un mot chargé.

Une livraison, quatre fonctions

La RFC distingue quatre fonctions. Le routage des requêtes dirige l’agent utilisateur vers un surrogate adapté. La distribution déplace le contenu contrôlé par l’éditeur depuis l’origine vers les surrogates, à l’avance ou après une demande. La livraison est la réponse du surrogate au client. La comptabilité enregistre les activités de routage, distribution et livraison, parfois pour un transfert ultérieur d’argent, de biens ou d’obligations.

Ces fonctions ne produisent pas les mêmes preuves. Une redirection ne prouve pas que le contenu est arrivé. Une copie présente sur un surrogate ne prouve pas qu’un client y a été dirigé. Une réponse réussie ne révèle pas forcément quel réseau amont a fourni l’objet. Un journal n’est pas une facture acceptée par les deux parties. L’intérêt du modèle était de nommer ces étapes séparément.

Le contrôle restait lui aussi réparti. L’éditeur contrôlait le contenu et sa distribution ; l’origine conservait la copie maîtresse ou faisant autorité ; le surrogate livrait sans devenir l’origine. Une passerelle d’interconnexion de contenu pouvait prendre en charge la distribution, le routage, la comptabilité, ou seulement certaines de ces fonctions.

Une boîte noire a tout de même besoin d’un accord

Traiter un voisin comme une « boîte noire » ne garantissait pas l’interopérabilité. La RFC définit une relation négociée dont les conditions sont établies en partie ou entièrement en dehors des protocoles d’interconnexion. Les réseaux pouvaient partager des ressources et masquer leur organisation interne, mais le vocabulaire ne décidait pas quels objets pouvaient être copiés, où ils pouvaient être servis, quelle activité était facturable ou qui répondait d’un journal erroné.

Une passerelle pouvait exposer une portée nouvelle tout en restant soumise à des limites commerciales sur les contenus, les données comptables ou les responsabilités. Un chemin techniquement valide n’autorisait pas à servir tout objet. La sécurité devait aussi couvrir l’identité des partenaires, l’intégrité du contenu et la fiabilité des données comptables. La RFC 3466 signalait ces questions sans en définir tous les mécanismes.

Une carte avant les mécanismes

La RFC 3466 était informative : elle proposait un modèle, pas un protocole normalisé sur le fil. En 2012, la RFC 6707 présentait encore l’interconnexion CDN comme un problème à cadrer, avec des interfaces de contrôle, de routage, de métadonnées et de journalisation, tandis que les relations commerciales restaient hors périmètre. Ce jalon ultérieur ne décrit pas le déploiement actuel.

La contribution historique de la RFC 3466 est donc une frontière. Des réseaux pouvaient parler d’un échange de portée sans prétendre que des mots communs créaient un marché ouvert. Il fallait toujours des preuves distinctes pour la route, la copie, l’autorisation du service et la facture.

Sources