Groupe de travail Réseau

D. Wessels, K. Claffy

Request for Comments : 2186

National Laboratory for Applied Network Research/UCSD

Catégorie : Information

septembre 1997

Traduction Claude brière de L'Isle

 

 

 

Protocole des antémémoires Internet (ICP), version 2

 

 

Statut de ce mémoire

Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

 

Résumé

Le présent document décrit la version 2 du protocole des antémémoires de l'Internet (ICPv2, Internet Cache Protocol version 2) telle qu'elle est actuellement mise en œuvre dans deux paquetages de mandataire d'antémémoire de la Toile mondiale [3, 5]. ICP est un format de message léger utilisé pour les communications entre les antémémoires de la Toile. ICP est utilisé pour échanger des indications sur l'existence des URL dans les antémémoires voisines. Les antémémoires échangent des interrogations et des réponses ICP pour rassembler des informations qui seront utilisées pour choisir la localisation la plus appropriée à partir de laquelle restituer un objet.

 

Le présent document décrit seulement le format et les champs des messages ICP. Un document d'accompagnement (RFC2187) décrit l'application de ICP aux antémémoires de la Toile. Plusieurs mises en œuvre indépendantes de mise en antémémoire utilisent maintenant ICP, et on considère qu'il est important de codifier les utilisations pratiques existantes de ICP pour ceux qui essayent de mettre en œuvre, déployer et étendre son utilisation pour leurs propres besoins.

 

1.   Introduction

 

ICP est un format de message utilisé pour communiquer entre antémémoires de la Toile. Bien que les antémémoires de la Toile utilisent HTTP [1] pour le transfert des données d'objets, les antémémoires bénéficient d'un protocole de communication plus simple et plus léger. ICP est principalement utilisé dans un maillage d'antémémoires pour localiser des objets spécifiques de la Toile dans les antémémoires voisines. Une antémémoire envoie une interrogation ICP à ses voisines. Les voisines renvoient les réponses ICP indiquant "TOUCHE" ou "ÉCHEC."

 

Dans la pratique courante, ICP est mis en œuvre par dessus UDP, mais il n'y a pas d'exigence qu'il soit limité à UDP. Nous estimons que ICP sur UDP offre des caractéristiques importantes pour les applications de mise en antémémoire sur la Toile. Un échange d'interrogation/réponse ICP a besoin de se faire rapidement, normalement en moins d'une seconde ou deux. Une antémémoire ne peut pas attendre plus longtemps que cela avant de commencer à restituer un objet. Échouer à recevoir un message de réponse signifie très vraisemblablement que le chemin réseau est soit encombré soit rompu. Dans l'un ou l'autre cas, on ne va pas vouloir choisir ce voisin. Comme indication des conditions immédiates du réseau entre antémémoires voisines, ICP sur un protocole léger tel que UDP est meilleur qu'un autre avec la redondance de TCP.

 

En plus de son utilisation comme protocole de localisation d'objets, le message ICP peut être utilisé pour le choix de l'antémémoire. L'échec à recevoir une réponse d'une antémémoire peut indiquer une défaillance réseau ou système. La réponse ICP peut comporter des informations qui pourront aider au choix de la source la plus appropriée à partir de laquelle restituer un objet.

 

ICP a été initialement développé par Peter Danzig, et autres à l'Université de Californie du Sud comme partie centrale de la mise en antémémoire hiérarchique dans le projet de recherche Harvest [3].

 

Format du message ICP

 

Le format du message ICP consiste en un en-tête fixe de 20 octets plus une charge utile de taille variable (voir la Figure 1).

 

NOTE : Tous les champs doivent être représentés dans l'ordre des octets du réseau .

 

Opcode

Un des opcodes définis ci-dessous.

 

Version

Le numéro de version du protocole ICP. Au moment de la rédaction, les deux versions deux et trois sont utilisées. Le présent document décrit seulement la version deux. Le champ Numéro de version permet des développements futurs de ce protocole.

 

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|   Opcode      |    Version    |     Longueur de message       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        Numéro de demande                      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

|                            Options                            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                       Données d'option                        |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                    Adresse de l'hôte envoyeur                 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                                                               |

|                          Charge utile                         |

/                                                               /

/                                                               /

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Figure 1 : Format de message ICP.

Longueur de message

La longueur totale (en octets) du message ICP. Les messages ICP NE DOIVENT PAS dépasser 16 384 octets de long.

 

Numéro de demande

Un identifiant opaque. Lors de la réponse à une interrogation, cette valeur doit être copiée dans le message de réponse.

 

Options

Un champ de 32 bits des fanions d'option qui permet l'extension de cette version du protocole de certaines façons, limitées. Voir "Fanions d'options ICP" ci-dessous.

 

Données d'option

Un champ de quatre octets pour prendre en charge les caractéristiques facultatives. Les caractéristiques ICP suivantes utilisent ce champ :

L'option ICP_FLAG_SRC_RTT utilise les 16 bits de moindre poids de Données d'option pour retourner les mesures de RTT. L'option ICP_FLAG_SRC_RTT est décrite plus en détail ci-dessous.

 

Adresse de l'hôte envoyeur

C'est l'adresse IPv4 de l'hôte qui envoie le message ICP. On ne devrait probablement pas trop faire confiance à ce qui est fourni dans ce champ par getpeer-name(), accept(), et recvfrom(). Il y a quelque ambiguïté sur l'objectif original de ce champ. Il n'est pas utilisé en pratique.

 

Charge utile

Le contenu du champ Charge utile varie selon Opcode, mais le plus souvent, il contient une chaîne d'URL terminée par des zéros.

 

2.   Opcodes ICP

 

Le tableau suivant donne les opcodes ICP actuellement définis :

 

Valeur

Nom

0

ICP_OP_INVALID

1

ICP_OP_QUERY

2

ICP_OP_HIT

3

ICP_OP_MISS

4

ICP_OP_ERR

5-9

UNUSED

10

ICP_OP_SECHO

11

ICP_OP_DECHO

12-20

Non utilisé

21

ICP_OP_MISS_NOFETCH

22

ICP_OP_DENIED

23

ICP_OP_HIT_OBJ

 

ICP_OP_INVALID

Un bouche-trou pour détecter les messages remplis de zéros ou mal formés. Une antémémoire ne doit jamais envoyer intentionnellement un message ICP_OP_INVALID. ICP_OP_ERR devrait être utilisé à la place.

 

ICP_OP_QUERY

Un message d'interrogation. NOTER que cet opcode a un format de charge utile différent de celui de la plupart des autres. D'abord il y a l'adresse IPv4 du demandeur, suivie par un URL. L'adresse de l'hôte demandeur n'est pas celle de l'antémémoire qui génère le message ICP, mais plutôt l'adresse du client de l'antémémoire qui est à l'origine de la demande. L'adresse de l'hôte demandeur est souvent remplie de zéros. Un message ICP avec une adresse de l'hôte demandeur toute à zéro devrait être considérée comme une adresse de demandeur non spécifiée ; elle n'indique pas une adresse IPv4 valide.

 

Format de charge utile de ICP_OP_QUERY :

 

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                  Adresse de l'hôte demandeur                  |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                                                               |

/                       URL terminée par des zéros              /

/                                                               /

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

En réponse à ICP_OP_QUERY, le receveur doit retourner :

ICP_OP_HIT, ICP_OP_MISS, ICP_OP_ERR, ICP_OP_MISS_NOFETCH, ICP_OP_DENIED, ou ICP_OP_HIT_OBJ.

 

ICP_OP_SECHO

Similaire à ICP_OP_QUERY, mais à utiliser pour simuler une interrogation à un serveur d'origine. Lorsque ICP est utilisé pour choisir le plus proche voisin, le serveur d'origine peut être inclus dans l'algorithme en lançant un message ICP_OP_SECHO à son accès d'écho. La charge utile est simplement l'URL terminé par des zéros.

 

NOTE : le serveur d'écho ne va pas interpréter les données (c'est-à-dire, on pourrait envoyer n'importe quoi). Cet opcode est utilisé pour faire la différence entre une interrogation ou réponse légitime, un détritus aléatoire, et une réponse d'écho.

 

ICP_OP_DECHO

Similaire à ICP_OP_QUERY, mais utilisé pour simuler une interrogation à une antémémoire qui n'utilise pas ICP. Lorsque ICP est utilisé pour choisir le plus proche voisin, une antémémoire non ICP peut être incluse dans l'algorithme en lançant un message ICP_OP_DECHO à son accès d'écho. La charge utile est simplement l'URL terminé par des zéros.

 

NOTE : un problème de cette approche est qu'alors que l'accès d'écho d'un système peut fonctionner parfaitement, le logiciel d'antémémoire peut ne pas fonctionner du tout.

 

Un des six opcodes ICP suivants est envoyé en réponse à un message ICP_OP_QUERY. Sauf mention contraire, la charge utile doit être la chaîne d'URL terminée par des zéros. La chaîne d'URL et le champ Numéro de demande doivent tous deux être exactement les mêmes que dans le message ICP_OP_QUERY.

 

ICP_OP_HIT

Une réponse ICP_OP_HIT indique que l'URL demandé existe dans cette antémémoire et que le demandeur est autorisé à le restituer.

 

ICP_OP_MISS

Une réponse ICP_OP_MISS indique que l'URL demandé n'existe pas dans cette antémémoire. L'antémémoire qui interroge peut encore choisir d'aller chercher l'URL à partir de l'antémémoire qui répond.

 

ICP_OP_ERR

Une réponse ICP_OP_ERR indique une erreur de quelque sorte dans l'analyse ou le traitement du message d'interrogation (par exemple un URL invalide).

 

ICP_OP_MISS_NOFETCH

Une réponse ICP_OP_MISS_NOFETCH indique que cette antémémoire est active, mais dans un état où elle ne veut pas traiter des échecs d'antémémoire. Un exemple d'un tel état est celui d'une phase de démarrage où une antémémoire serait en train de reconstruire sa mémorisation d'objets. Une antémémoire dans un tel mode peut souhaiter retourner ICP_OP_HIT pour les touches d'antémémoire, mais pas ICP_OP_MISS pour les échecs. ICP_OP_MISS_NOFETCH signifie essentiellement "Je suis actif et fonctionne, mais ne venez pas chercher cet URL chez moi pour l'instant."

 

Noter que ICP_OP_MISS_NOFETCH a une signification différente de ICP_OP_MISS. La réponse ICP_OP_MISS est une invitation à aller chercher l'URL auprès de l'antémémoire qui répond (si leur relation le permet), mais ICP_OP_MISS_NOFETCH est une demande de NE PAS aller chercher l'URL auprès de l'antémémoire qui répond.

 

ICP_OP_DENIED

Une réponse ICP_OP_DENIED indique que le site qui interroge n'est pas autorisé à restituer l'objet désigné à partir de cette antémémoire. Les antémémoires et mandataires peuvent mettre en œuvre des contrôles d'accès complexes. Cette réponse doit être interprétée comme signifiant "vous n'êtes pas autorisé à me demander cet URL à ce moment particulier."

 

Les antémémoires qui reçoivent un fort pourcentage de réponses ICP_OP_DENIED sont probablement mal configurées. Les antémémoires devaient relever le pourcentage de toutes les réponses qui sont ICP_OP_DENIED et désactiver une voisine qui dépasse un certain seuil (par exemple, 95 % des interrogations ou plus).

 

De même, une antémémoire devrait relever le pourcentage des messages ICP_OP_DENIED qui sont envoyés à une adresse donnée. Si le pourcentage de messages refusés excède un certain seuil (par exemple, 95 % ou plus), l'antémémoire peut choisir d'ignorer tous les messages ICP_OP_QUERY suivants de cette adresse jusqu'à ce que survienne une forme d'intervention administrative.

 

ICP_OP_HIT_OBJ

Tout comme une réponse ICP_OP_HIT, mais les données d'objet réelles ont été incluses dans ce message de réponse. De nombreux objets demandés sont assez petits pour qu'il soit possible de les inclure dans la réponse à l'interrogation et d'éviter d'avoir besoin de faire une demande HTTP ultérieure pour l'objet.

 

ATTENTION : ICP_OP_HIT_OBJ a des effets secondaires négatifs qui peuvent rendre son utilisation indésirable. Il transfère les données d'objet sans HTTP et donc court-circuite le traitement standard HTTP, y compris l'autorisation et la validation d'age. Un autre effet secondaire négatif est que les messages ICP_OP_HIT_OBJ vont souvent être beaucoup plus gros que la MTU du chemin, causant par là la fragmentation du paquet UDP. Pour ces raisons, l'utilisation de ICP_OP_HIT_OBJ N'EST PAS recommandée.

 

Une antémémoire ne doit pas envoyer un ICP_OP_HIT_OBJ si le fanion ICP_FLAG_HIT_OBJ n'est pas mis dans le champ Options du message d'interrogation.

 

Format de charge utile de ICP_OP_HIT_OBJ :

 

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                                                               |

/                  URL terminé par des zéros                    /

/                                                               /

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|               Taille d'objet  |                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |

|                                                               |

/                        Données d'objet                        /

/                                                               /

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

L'application receveuse doit vérifier d'être sûre de réellement recevoir les octets Taille d'objet de données. Si elle ne les reçoit pas, elle devrait alors traiter la réponse ICP_OP_HIT_OBJ comme si elle était une ICP_OP_HIT normale.

 

NOTE : le champ Taille d'objet ne commence pas nécessairement sur une limite de 32 bits comme montré dans le diagramme ci-dessus. Il commence immédiatement à la suite de l'octet NULL de la chaîne d'URL.

 

OPCODES non reconnus

Les messages ICP avec des opcodes non reconnus ou non utilisés devraient être ignorés, c'est à dire qu'aucune réponse n'est générée. L'application peut choisir de noter le comportement anormal dans un fichier de journalisation d'événements.

 

3.   Fanions d'option ICP

 

0x80000000   ICP_FLAG_HIT_OBJ

Ce fanion est mis dans un message ICP_OP_QUERY pour indiquer qu'il est d'accord pour répondre par un message ICP_OP_HIT_OBJ si les données d'objet tiennent dans la réponse.

 

0x40000000   ICP_FLAG_SRC_RTT

Ce fanion est mis dans un message ICP_OP_QUERY pour indiquer que le demandeur aimerait que la réponse ICP comporte le RTT mesuré du répondant vers le serveur d'origine.

 

À réception d'un ICP_OP_QUERY avec le bit ICP_FLAG_SRC_RTT mis, une antémémoire devrait vérifier une base de données interne de mesures de RTT. Si elle est disponible, la valeur de RTT DOIT être exprimée par un entier de 16 bits, en millisecondes. Si elle n'est pas disponible, le répondant peut régler la valeur de RTT à zéro, ou éliminer le bit ICP_FLAG_SRC_RTT dans la réponse ICP. La réponse ICP NE DOIT PAS être retardée en attendant que survienne la mesure du RTT.

 

Ce fanion est mis dans un message de réponse ICP (ICP_OP_HIT, ICP_OP_MISS, ICP_OP_MISS_NOFETCH, ou ICP_OP_HIT_OBJ) pour indiquer que les 16 bits de moindre poids du champ Données d'option contiennent le RTT mesuré avec l'hôte donné dans l' URL demandé. Si ICP_FLAG_SRC_RTT est à zéro dans l'interrogation, il DOIT aussi être à zéro dans la réponse. Si ICP_FLAG_SRC_RTT est mis dans l'interrogation, il peut alors être mis ou non dans la réponse.

 

4.   Considérations pour la sécurité

 

Les questions de sécurité en rapport avec ICP sont exposées dans le document d'accompagnement, RFC2187.

 

5.   Références

[1]   R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Protocole de transfert Hypertext -- HTTP/1.1", RFC2068, janvier 1997. (Obsolète, voirRFC2616) (P.S.)

[2]   T. Berners-Lee et autres, "Localisateurs uniformes de ressource (URL)", RFC1738, décembre 1994. (Obsolète, voir les RFC 4248 et 4266)

[3]   Bowman M., Danzig P., Hardy D., Manber U., Schwartz M., and Wessels D., "The Harvest Information Discovery and Access System", Internet Research Task Force - Resource Discovery, http://harvest.transarc.com/.

[4]   Wessels D., Claffy K., "ICP and the Squid Web Cache", National Laboratory for Applied Network Research, http://www.nlanr.net/~wessels/Papers/icp-squid.ps.gz

[5]   Wessels D., "The Squid Internet Object Cache", National Laboratory for Applied Network Research, http://squid.nlanr.net/Squid/

 

6.   Remerclements

 

Les auteurs tiennent à remercier Paul A Vixie <paul@vix.com> qui a fourni d'excellentes réactions sur ce document.

 

7.   Adresse des auteurs

 

Duane Wessels

K. Claffy

National Laboratory for Applied Network Research

National Laboratory for Applied Network Research

10100 Hopkins Drive

10100 Hopkins Drive

La Jolla, CA 92093 USA

La Jolla, CA 92093 USA

mél : wessels@nlanr.net

mél : kc@nlanr.net