Brevet FR2788352A1 — publié le 20000713

INTERFONCTIONNEMENT ET SYSTEME DE CACHES COOPERANTS ET CACHES REPARTIS L'invention concerne un procédé de transmission de requêtes HTTP d'accès à un objet, constitué de fichiers tels que des pages HTML, des images ou autres. La transmission de messages, en particulier de fichiers tels que notamment les pages HTML, pour Hypertext Mark-up Language en langage anglo-saxon, ou pages WEB, sur le réseau INTERNET est actuellement confrontée à des problèmes de volume de trafic, et donc de débit de transmission de données, largeur de bande passante consommée et de temps d'attente. C'est en particulier le cas pour ce qui concerne le système W.W.W, World Web Wide en langage anglo-saxon, lequel permet couramment la transmission de documents hypertextes sous forme de pages HTML, d'images ou autres. Une solution pour réduire ou résoudre ce problème consiste à utiliser, afin d'assister les serveurs d'origine, gestionnaires de ces objets dont ils assurent la diffusion, des mémoires caches implantées dans des systèmes d'interfaçage utilisateur/serveur, appelés "proxies" en langage anglo-saxon. Ces proxies et mémoires caches tels que représentés en figure la font partie d'un ensemble appelé conjugué comportant un module d'analyse et de transformation HTML, M1, un module d'anticipation M2, un module M3 de conversion en ligne des documents et enfin la mémoire cache proprement dite M4. D'une manière générale, les mémoires caches, ainsi que représenté en figure lb, jouent le rôle d'un serveur auxiliaire. Sur requête HTTP d'accès à un document, A, par le terminal utilisateur, la mémoire cache M4 renvoie le document, B, à ce dernier. Sinon, un message de requête, requête HTTP, est envoyé, C, de la mémoire cache M4 au serveur d'origine, lequel transmet en retour, D, le document demandé à la mémoire M4, grâce au proxy qui lui est associé, stocke une copie de ce document, après indexation, E, et transmet le contenu de ce document, F, au terminal utilisateur. Afin d'améliorer la fonction de cache des mémoires précitées, des protocoles de gestion spécifique de ces mémoires caches ont été mis en oeuvre, ces protocoles ayant avant tout pour objet, soit de conférer à ces mémoires caches des fonctions de mémoires caches réparties, soit de mémoires caches coopérantes. Parmi les protocoles de gestion les plus couramment utilisés, le protocole ICP pour Internet Caching Protocol et le protocole CARP pour Cache Array Routing Protocole en langage anglo-saxon, sont les plus répandus. Le protocole CARP, décrit à titre de pur exemple non limitatif, consiste essentiellement à mettre en oeuvre un ensemble de plusieurs mémoires caches en réseau assorti d'une équi- répartition des documents mémorisés dans différents répertoires de ces dernières. Ce type de protocole est avant tout mis en oeuvre dans le cadre d'une entreprise, le caractère en réseau du mode opératoire de ces mémoires ne nécessitant pas la mise en oeuvre d'une copie de sauvegarde de chaque document dans chaque mémoire. En référence à la figure lc, le protocole de gestion de chaque mémoire cache CARP comporte, suite à l'envoi et la réception d'une requête HTTP d'accès la, une vérification de cette requête, lb. Si la requête est vérifiée, une fonction de hachage est appliquée, lc, pour retrouver la mémoire cache CARP détentrice du document. Dans le cas ld o cette mémoire cache dispose de ce document, ce dernier est transmis au titulaire le. Sinon, un accès if au serveur d'origine est effectué pour collecter le document et le cas échéant effectuer une copie de sauvegarde dans la mémoire cache CARP du réseau la plus appropriée. o10 Le protocole ICP, décrit à titre de pur exemple non limitatif, consiste avant tout à localiser l'objet requis par le terminal utilisateur dans un groupe de mémoires caches coopérantes associées chacune à un proxy, la coopération des mémoires caches du groupe de mémoires caches coopérantes étant réalisée entre une mémoire cache coopérante locale, mémoire réceptrice de la requête HTTP d'accès émise par le terminal client, et les mémoires caches coopérantes du groupe, appelées mémoires caches coopérantes voisines. Ces dernières sont subdivisées, par ordre hiérarchique, en mémoires caches coopérantes parentes et semblables (sibling en langage anglo-saxon). La fonction des mémoires caches coopérantes parentes et semblables ne sera pas décrite en détail car elle est connue en tant que telle de l'état de la technique. En référence à la figure ld, le protocole de gestion de chaque mémoire cache ICP comporte des étapes 2a, de réception de la requête HTTP d'accès au document et de vérification 2b, de la requête par la mémoire cache coopérante locale. Lorsque la requête est vérifiée, une requête ICP est lancée, 2c, de la mémoire cache coopérante locale vers les mémoires caches coopérantes voisines du groupe. Si le document est trouvé dans ces dernières, ce document est transmis au terminal utilisateur et la mémoire cache coopérante locale effectue une copie de sauvegarde de ce dernier, 2f. Sinon, la mémoire cache coopérante locale transmet, 2e, un message de requête au serveur d'origine, lequel transmet le document recherché à la mémoire cache coopérante locale. L'étape 2f est alors réalisée. Le protocole ICP donne satisfaction mais, alors qu'en l'absence du document recherché dans les mémoires caches coopérantes voisines, aucun message de réponse n'est transmis à la mémoire cache coopérante locale, l'interrogation du serveur d'origine est lancée par cette dernière au bout d'un temps déterminé, générateur d'un retard global d'ensemble. En outre, le document requis est systématiquement sauvegardé au niveau de la mémoire cache coopérante locale, ce qui finalement, pour toutes les mémoires caches coopérantes du groupe, impose en outre la fourniture de moyens de mémoire de masse importants et la gestion de ces derniers. La simple association de mémoires caches réparties et de mémoires caches coopérantes par juxtaposition dans un réseau, ne peut être directement envisagée. En effet, alors que les mémoires caches réparties impliquent une succession d'opérations au niveau local, les mémoires caches coopérantes impliquent une succession d'opérations au niveau étendu, dans le groupe, ainsi que l'existence de la mise en oeuvre systématique d'une copie de sauvegarde du document dans la mémoire cache coopérante locale, en l'absence préalable de celui-ci dans cette dernière, implique une surcharge importante de temps machine et d'occupation mémoire. La présente invention a pour objet de remédier aux inconvénients des protocoles de gestion de mémoires caches précités par la mise en oeuvre d'un procédé de transmission de requêtes HTTP d'accès à un objet, au moyen de mémoires caches réparties et coopérantes, dans lesquels les inconvénients de l'utilisation, séparée, des protocoles de gestion des mémoires caches réparties et coopérantes sont supprimés. En particulier, un autre objet de la présente invention est la mise en ouvre d'un procédé de transmission de requêtes HTTP d'accès à un objet à partir des protocoles de gestion des mémoires caches réparties et coopérantes dans lequel ces protocoles sont adaptés l'un à l'autre et réciproquement. En conséquence, un autre objet de la présente invention est le mise en oeuvre d'un procédé de transmission de requêtes HTTP d'accès à un objet à partir des protocoles de gestion des mémoires caches réparties et coopérantes dans lequel les interfaces de communication de chacun de ces protocoles et les mécanismes ou modes opératoires de ces protocoles sont réciproquement adaptés l'un à l'autre. Un autre objet de la présente invention est la mise en oeuvre d'un procédé de transmission de requêtes HTTP d'accès à un objet constitué par des pages HTML dans lequel l'espace mémoire nécessaire à chaque mémoire cache coopérante est optimisé. Un autre objet de la présente invention est, enfin, la mise en oeuvre d'un procédé de transmission de requêtes HTTP d'accès à un objet, constitué par des pages HTML, dans lequel le nombre d'accès au serveur d'origine et l'encombrement du réseau sont sensiblement réduits. Le procédé de transmission de requêtes HTTP d'accès à un objet, constitué de fichiers tels que des pages HTML, des images ou autres gérées par un serveur d'origine, entre un terminal utilisateur, des mémoires caches réparties coopérantes et ce serveur d'origine, objet de la présente invention, est remarquable en ce qu'il consiste à configurer les mémoires caches réparties comme mémoires caches de premier niveau, ces mémoires étant adaptées à recevoir et émettre des requêtes et des réponses HTTP relatives à cet objet et à mémoriser cet objet sur critère de gestion de mémoire et à configurer les mémoires caches coopérantes comme mémoires caches de deuxième niveau. Sur requête HTTP d'accès à cet objet émise par le terminal utilisateur, les mémoires caches réparties sont adaptées à recevoir cette requête, et, en présence de cet objet dans ces dernières, à transmettre au terminal utilisateur une réponse HTTP de transmission de cet objet. En l'absence de cet objet dans ces dernières, celles-ci sont adaptées à transmettre vers une mémoire cache coopérante locale une requête HTTP d'accès à cet objet. En présence de cet objet dans cette mémoire cache coopérante locale, ce dernier est transmis vers les mémoires caches réparties, puis vers le terminal utilisateur. En l'absence de cet objet dans la mémoire cache coopérante locale, un message de recherche de cet objet est transmis de cette dernière vers les mémoires caches coopérantes voisines. En présence de cet objet dans ces dernières, cet objet est transmis des mémoires caches coopérantes voisines vers la mémoire cache coopérante locale, en l'absence de copie de sauvegarde de cet objet dans cette dernière, puis vers les mémoires réparties et le terminal utilisateur. En l'absence de cet objet dans ces dernières, une requête HTTP d'accès à cet objet est transmise de cette mémoire cache coopérante locale vers le serveur d'origine. Une réponse HTTP contenant cet objet est ensuite transmise vers la mémoire cache coopérante locale, les mémoires caches réparties et le terminal utilisateur. Ce mode opératoire permet de réduire le nombre d'accès et le temps d'occupation du serveur d'origine. Il sera mieux compris à la lecture de la description et à l'observation des dessins ci-après dans lesquels, outre les figures la, lb, lc et ld relatives à l'art antérieur: - la figure 2a représente un organigramme général illustratif du procédé, objet de la présente invention; - la figure 2b représente, sur une configuration matérielle correspondant à l'interconnexion des mémoires caches réparties en réseau et de mémoires caches coopérantes, les étapes essentielles mises en oeuvre par le processus de coopération entre mémoires caches réparties et mémoires caches coopérantes configurées en mémoires caches de premier et de deuxième niveau respectivement, conformément au procédé objet de l'invention tel que représenté en figure 2a; - la figure 2c représente un organigramme plus détaillé des étapes mises en oeuvre par le processus de coopération entre mémoires caches réparties et mémoires caches coopérantes configurées en mémoires caches de premier et de deuxième niveau respectivement, conformément au procédé objet de la présente invention tel que représenté en figure 2a et 2b; - la figure 3a représente, à titre d'exemple non limitatif, la structure d'une mémoire cache coopérante locale conforme à l'objet de la présente invention; - la figure 3b représente un mode de réalisation particulier non limitatif de la mémoire cache coopérante locale représentée en figure 3a; - la figure 4 représente, à titre d'exemple non limitatif, la structure d'une mémoire cache coopérante locale conforme à l'objet de la présente invention, dans laquelle la fonction de répartition d'un objet dans les mémoires caches réparties est en outre implantée; - les figures 5 et 6 représentent une structure préférentielle d'une mémoire cache coopérante locale, particulièrement adaptée à une gestion des requêtes HTTP et requêtes ICP à partir d'une base de données en mode vignette, et une telle vignette respectivement, une vignette étant associée à une requête HTTP ou à une requête ICP, afin d'assurer une gestion optimisée de la recherche et de la transmission du document requis par le demandeur; la figure 7 représente une variante de réalisation de la figure 5, dans laquelle la base de données, externe à la mémoire cache coopérante locale, est gérée par l'intermédiaire du protocole de gestion des mémoires caches coopérantes; - la figure 8 représente, dans le cas d'une mémoire cache coopérante locale conforme à l'objet de la présente invention telle que représentée en figure 5 ou 7, un processus préférentiel de gestion des requêtes HTTP respectivement ICP reçues par cette mémoire cache coopérante locale. Une description plus détaillée du procédé de transmission de requêtes HTTP d'accès à un objet constitué de fichiers tels que des pages HTML, des images ou autres, objet de la présente invention, sera maintenant donnée en liaison avec les figures 2a à 2c. D'une manière générale, on indique que le procédé, objet de la présente invention, a pour objet d'assurer la transmission de requêtes HTTP d'accès à l'objet précité, cet objet et les pages HTML correspondantes par exemple étant gérés par un serveur d'origine afin de permettre l'obtention de réponses HTTP contenant cet objet par l'utilisateur auteur de la requête d'accès précitée. La requête est effectuée par ce dernier à partir d'un terminal utilisateur et les requêtes HTTP et réponses HTTP correspondantes, mises en ouvre par le procédé objet de la présente invention ainsi que représenté en figure 2a, interviennent entre l'utilisateur précité, des mémoires caches réparties, gérées selon un protocole de gestion de mémoires caches réparties, et des mémoires caches coopérantes gérées selon un protocole de gestion de mémoires caches coopérantes. Les mémoires caches réparties sont interconnectées en réseau et peuvent constituer par exemple des mémoires caches d'un réseau d'entreprise ou analogue. Les mémoires caches coopérantes comportent au moins une mémoire cache coopérante locale, laquelle est réputée recevoir la requête HTTP relative à un objet, et des mémoires caches coopérantes voisines et les mémoires caches réparties étant interconnectées en réseau au serveur d'origine. Selon un aspect particulièrement remarquable du procédé, objet de la présente invention, ainsi que représenté en figure 2a, les mémoires caches réparties sont configurées comme mémoires caches de premier niveau, ces mémoires caches réparties étant adaptées à recevoir du terminal utilisateur des requêtes HTTP et à émettre vers la mémoire cache coopérante locale des requêtes et à recevoir des réponses HTTP relatives à cet objet. En outre, les mémoires caches réparties sont adaptées de manière à mémoriser, sur critère de gestion de mémoire, l'objet précité. Un critère de gestion de mémoire classique peut consister en une équi-répartition en volume des données mémorisées au niveau de chaque mémoire cache répartie. L'ensemble des mémoires caches réparties est de ce fait interconnecté en réseau, chaque mémoire cache répartie ne comportant ainsi pas les mêmes documents mémorisés dans ces dernières. Le critère de gestion de mémoire des mémoires réparties et en particulier la fonction de répartition des objets constitués par les pages HTML les plus fréquemment demandés par l'utilisateur ne seront pas décrits en détail car ils correspondent à des processus mis en oeuvre couramment dans la technique, en particulier dans le cas o les mémoires réparties sont gérées selon le protocole de gestion CARP. Selon un autre aspect remarquable du procédé, objet de la présente invention, celui-ci consiste à configurer les mémoires caches coopérantes comme mémoires caches de deuxième niveau. Le mode opératoire du procédé, objet de la présente invention, entre mémoires caches réparties et mémoires caches coopérantes est alors le suivant, en référence à la figure 2a. Sur requête HTTP émise en une étape 1000 par le terminal utilisateur en vue d'une demande d'accès à un document donné, cette requête est reçue par les mémoires caches réparties connectées en réseau et formant les mémoires de premier niveau. En présence de l'objet considéré dans les mémoires caches réparties, le procédé, objet de la présente invention, consiste à transmettre au terminal utilisateur, en une étape 1001, une réponse HTTP de transmission de cet objet. En l'absence de cet objet dans les mémoires caches réparties, le procédé, objet de la présente invention, consiste au contraire à transmettre vers la mémoire cache coopérante locale une requête HTTP d'accès à cet objet. On rappelle que, par définition, la mémoire cache coopérante locale est celle qui est destinée à recevoir la requête relative à un objet donné de la part d'un réseau constitué par un ensemble de mémoires caches réparties. Cette transmission est effectuée par simple adressage déterminé à partir d'une mémoire cache répartie spécifique. Ce mode opératoire, connu en tant que tel, ne sera pas décrit en détail pour cette raison. La requête 1002, requête HTTP représentée en figure 2a, consiste ainsi à transmettre une requête d'accès au document considéré de l'ensemble des mémoires de premier niveau aux mémoires de second niveau constituées par les mémoires caches coopérantes. Selon un premier aspect du procédé, objet de la présente invention, en présence de cet objet dans la mémoire cache coopérante locale, celui- ci consiste à transmettre, en une étape 1003, constituant une réponse HTTP, de la mémoire cache coopérante locale vers les mémoires caches réparties, l'objet considéré puis, bien entendu, vers le terminal utilisateur par une réponse HTTP analogue à la réponse 1001 précédemment mentionnée. Au contraire, en l'absence de cet objet dans la mémoire cache coopérante locale, le procédé, objet de la présente invention, consiste à transmettre de cette mémoire cache coopérante locale vers les mémoires caches coopérantes voisines, un message de recherche MR de cet objet, en une opération 1004. En présence de cet objet dans les mémoires caches coopérantes voisines précitées, le procédé consiste alors, en une étape 1005, à transmettre cet objet des mémoires caches coopérantes voisines vers la mémoire cache coopérante locale. Cette opération réalisée, et conformément à un aspect particulièrement avantageux du procédé, objet de la présente invention, aucune copie de sauvegarde de cet objet dans la mémoire cache coopérante locale n'est alors effectuée, contrairement au protocole de gestion des mémoires caches coopérantes tel que le protocole ICP. Suite à l'étape 1005 précitée, l'objet est alors transmis vers les mémoires caches réparties et le terminal utilisateur par des étapes analogues aux étapes 1003 et 1001 précédemment mentionnées dans la description. En l'absence de cet objet dans les mémoires caches coopérantes voisines, le procédé, objet de la présente invention, consiste à transmettre une requête HTTP d'accès à cet objet de la mémoire cache coopérante locale vers le serveur d'origine, étape 1006 représentée sur la figure 2a réalisée par l'intermédiaire du réseau Internet et plus particulièrement du W.W.W, système HYPERMEDIA distribué précédemment mentionné dans la description. Suite à cet accès au serveur d'origine, une réponse HTTP 1007 contenant l'objet est alors transmise du serveur d'origine vers la mémoire cache coopérante locale par l'intermédiaire du W.W.W. puis vers les mémoires caches réparties par l'intermédiaire d'une réponse HTTP analogue à la réponse 1003 précédemment décrite, et enfin, vers le terminal utilisateur par l'intermédiaire d'une réponse HTTP 1001 précédemment décrite. Ainsi, et en référence à la figure 2a, on indique que selon le procédé, objet de la présente invention, les mémoires caches de premier niveau constituées par les mémoires caches réparties reçoivent la requête d'accès HTTP émise par l'utilisateur, vérifient l'existence locale du document demandé dans les mémoires caches réparties précitées. En cas de non-existence de ce document dans ces dernières, les mémoires caches de premier niveau transmettent une requête aux mémoires de second niveau, lesquelles sont constituées par les mémoires caches coopérantes mettant en ouvre un protocole de gestion allégé, en raison de l'absence de réalisation d'une copie de sauvegarde de document au niveau de la mémoire cache coopérante locale, de manière à localiser le document dans les mémoires caches coopérantes voisines. En particulier, on indique qu'il n'est pas nécessaire au niveau des mémoires caches de deuxième niveau, c'est-à-dire des mémoires caches coopérantes locales, de vérifier la requête transmise par l'utilisateur, puisque cette vérification a déjà été effectuée par les mémoires caches réparties constituant les mémoires caches de premier niveau. Dans le cas o le document est trouvé dans les mémoires caches voisines, ce document est alors simplement retourné vers la mémoire cache coopérante locale, laquelle peut alors être configurée de façon à ne pas procéder à la copie de sauvegarde ainsi que mentionné précédemment mais, au contraire, de façon à simplement transmettre ce document vers les mémoires caches de premier niveau, lesquelles permettent alors de transférer ce même document vers l'utilisateur, après bien entendu avoir effectué une copie de sauvegarde de ce document, conformément au critère de gestion de mémoire des mémoires caches réparties précédemment mentionné dans la description. On comprend ainsi que la mémoire cache coopérante locale joue le rôle d'un simple système de transfert en l'absence de mémorisation et de stockage d'une copie de sauvegarde. Ainsi, conformément à un aspect particulièrement remarquable du procédé, objet de la présente invention, et dans le but d'assurer la compatibilité entre mémoires caches de premier et de second niveau, les mémoires caches coopérantes, en particulier la mémoire cache coopérante locale, peuvent être modifiées dans leur configuration de façon à effectuer simplement le transfert des données support du document recherché qui était mémorisé, soit dans l'une des mémoires caches coopérantes voisines, soit, le cas échéant, dans un autre réseau de mémoires caches réparties. Dans ces conditions, on notera selon un aspect particulièrement remarquable du procédé, objet de la présente invention, que le document précité peut alors être stocké, soit dans une mémoire de masse lorsque la mémoire cache coopérante locale est munie d'une telle mémoire de masse, soit, au contraire, de manière externe à cette mémoire cache coopérante locale, lorsque cette dernière n'est pas munie d'une mémoire de masse. Dans ce dernier cas, et conformément à un aspect particulièrement remarquable du procédé, objet de la présente invention, les mémoires caches réparties apparaissent particulièrement adaptées à la réalisation de la fonction de stockage de la copie de sauvegarde. Une description plus détaillée d'un mode de mise en oeuvre spécifique du procédé, objet de la présente invention, sera maintenant donnée dans un exemple non limitatif dans le cas o les mémoires caches réparties sont gérées selon le protocole CARP et les mémoires caches coopérantes par l'intermédiaire d'un protocole de gestion de type ICP, en référence à la figure 2b. Sur la figure 2b, on a représenté les mémoires caches de premier niveau, mémoires réparties, constituées à titre d'exemple purement illustratif, par trois mémoires caches réparties référencées RCM1, RCM2, RCM3, ces mémoires étant par exemple gérées selon le protocole CARP. De même, on a représenté les mémoires caches coopérantes du deuxième niveau comme constituées par une mémoire cache coopérante locale CCM1, des mémoires caches coopérantes voisines constituées par une mémoire cache coopérante semblable notée CCM2 et une mémoire cache coopérante parente notée CCM3. Les mémoires caches coopérantes voisines semblable et parente et la mémoire cache coopérante locale sont réputées gérées par le protocole ICP. Les mémoires caches coopérantes locale et voisine sont interconnectées en réseau et le réseau de ces dernières est également interconnecté, d'une part, au réseau des mémoires caches réparties de premier niveau ainsi qu'au réseau Internet, c'est-à-dire au système d'interface Hypermedia W.W.W et ainsi au serveur d'origine. Sur la figure 2b, les requêtes et réponses HTTP émises par ou vers l'utilisateur 1000, 1001, par ou vers les mémoires caches de premier niveau 1002, 1003, par ou vers la mémoire cache coopérante locale 1004 et 1005 et 1006, 1007, portent les mêmes références que celles indiquées dans la figure 2a. On comprend en outre que dans le cas de l'existence de plusieurs mémoires caches coopérantes voisines, la mémoire cache coopérante locale CCM1, avant de procéder à l'envoi de la requête HTTP 1006 vers le serveur d'origine, peut avantageusement procéder à une exploration de chaque mémoire cache coopérante voisine, c'est-à-dire de la mémoire semblable CCM2 et de la mémoire parente CCM3. Par convention et sans présumer du routage effectif de l'une et l'autre des requêtes, on a représenté les différentes requêtes acheminées par une seule et même voie afin de ne pas surcharger le dessin, étant entendu que la requête HTTP 1006 et la réponse HTTP 1007, lesquelles ne sont pas adressées à la mémoire parente CCM3, ne sont aucunement perturbées dans leur transmission par cette dernière. Ainsi que représenté sur la figure 2b, on indique que selon un aspect particulièrement avantageux du procédé, objet de la présente invention, celui-ci peut consister à communiquer à la mémoire cache coopérante locale, la mémoire CCM1, une information, notée CCR, relative à la répartition du contenu des mémoires caches réparties. Dans le cas o une telle information consiste en une mise en correspondance biunivoque d'une adresse de chaque mémoire cache répartie RCM1 à RCM3 et du contenu de ces dernières, ce contenu permettant d'identifier les documents mémorisés par chacune d'elles, la mémoire cache coopérante locale CCM1 est ainsi en mesure, à partir de cette information, d'assurer directement la gestion des documents correspondants vers la mémoire cache répartie la plus appropriée. En outre, ainsi que représenté également sur la figure 2b de manière non limitative, le procédé, objet de la présente invention, peut consister à mémoriser, au niveau de la mémoire cache coopérante locale CCM1, un index de contenu IC de cet objet, cet index étant représentatif d'une adresse du contenu de cet objet, adresse de mémorisation de ce dernier. Cet index peut, ainsi que mentionné précédemment, être lié à l'information relative à la répartition du contenu des mémoires caches réparties. Enfin, dans un autre mode de réalisation non limitatif avantageux, ainsi que représentéen figure 2b, le procédé, objet de la présente invention, consiste en outre à communiquer à la mémoire cache coopérante locale CCM1 la fonction de répartition FR des mémoires caches réparties. Dans un tel cas, il est possible de délocaliser, au moins pour partie, la fonction de gestion des mémoires caches réparties au niveau de la mémoire cache coopérante locale CCM1, cette dernière pouvant alors dans ce cas être adaptée à partir de la fonction de répartition précitée, notée FR sur la figure 2b, d'établir l'existence ou la non-existence de l'objet dans les mémoires caches réparties et d'assurer la transmission d'un document à mémoriser dans ces dernières vers l'adresse de la mémoire cache répartie RCM1 à RCM3 la mieux adaptée. Une description plus détaillée du procédé, objet de la présente invention, lorsque ce dernier est mis en oeuvre à partir de mémoires caches de premier niveau gérées selon le protocole CARP et de mémoires caches de deuxième niveau gérées selon le protocole ICP, sera maintenant donnée en liaison avec la figure 2c dans le cadre plus spécifique de l'échange entre mémoires caches réparties de premier niveau et mémoires caches coopérantes de deuxième niveau. Sur la figure 2c, les références relatives aux requêtes et réponses HTTP ont été reproduites en référence à la figure 2b. Suite à la réception de la requête HTTP d'accès du client ou utilisateur aux mémoires caches réparties CARP à l'étape 1000, le procédé, objet de la présente invention, peut alors consister, au niveau de l'une des mémoires caches réparties RCM1 à RCM3 à l'étape 2000, en une étape de vérification de la requête formulée par ce dernier. Cette étape de vérification de requête 2000 est suivie d'une étape 2001 de la valeur vraie de cette vérification. En cas de réponse négative au test 2001, une étape 2002 consistant en le processus A précédemment décrit dans la description, lequel permet de gérer le défaut de vérification à la valeur vraie. Sur réponse positive au test 2001, une étape 2003 est réalisée par la mémoire cache répartie précitée, laquelle consiste à appliquer une fonction de hachage pour assurer, en l'absence du document dans l'une des mémoires caches réparties, la transmission de la requête HTTP 1002 vers la mémoire cache coopérante locale CCM1. L'étape 2003 est elle-même suivie d'une étape 2004 consistant à vérifier la présence de ce document dans la mémoire cache coopérante locale CCM1. Sur réponse positive au test 2004, une étape 2005 est prévue, consistant en une réponse au client, c'est-à-dire à l'utilisateur, laquelle met en oeuvre les étapes 1003 et 1001 précédemment mentionnées en liaison avec la figure 2b. Sur réponse négative au test 2004, une étape 2006 est prévue, laquelle consiste en un envoi d'un message de recherche MR, message 1004 de la figure 2b, aux mémoires caches coopérantes voisines. On rappelle que la transmission de ce message de recherche peut être effectuée dans le cas o les mémoires caches coopérantes de deuxième niveau sont gérées par le protocole ICP par une procédure GET. On rappelle également que la procédure 2006, c'est-à-dire l'envoi du message de recherche MR lors de l'opération 2004, peut être effectuée pour l'ensemble des mémoires caches coopérantes voisines ainsi que mentionné précédemment dans la description. La procédure d'envoi de message de recherche MR 2006 précitée est ellemême suivie d'une étape de test 2007 consistant à déterminer, au niveau de la mémoire cache coopérante locale CCM1, si le document recherché a été trouvé. Si tel n'est pas le cas, c'est-à-dire en réponse négative au test 2007, l'étape d'envoi d'une requête HTTP d'accès au serveur d'origine, étape 1006, est réalisée et, en conséquence, l'étape de réponse HTTP 1007 est également réalisée vers la mémoire cache coopérante locale CCM1. Le document recherché ayant été trouvé soit auprès des mémoires caches coopérantes voisines, soit auprès du serveur d'origine, la réponse au test 2007 est positive et suivie d'une étape 2008, laquelle consiste en la transmission du document recherché de la mémoire cache coopérante locale aux mémoires caches réparties, puis au terminal utilisateur selon les étapes 1003 et 1001 précédemment décrites en liaison avec la figure 2b. On a ainsi décrit un procédé de transmission de requêtes HTTP d'accès à un objet constitué par des pages HTML particulièrement performant dans la mesure o, grâce à la mise en oeuvre d'une hiérarchisation de mémoires caches réparties, mémoires de premier niveau, et de mémoires caches coopérantes, mémoires de second niveau, et en particulier en introduisant une légère modification du protocole de gestion des mémoires caches de second niveau lorsque le protocole de gestion utilisé est le protocole ICP, la réalisation de certaines tâches au sein des mémoires caches de premier niveau permet de supprimer la réalisation de tâches semblables dans les mémoires caches coopérantes de deuxième niveau. Cette approche est particulièrement remarquable en ce qui concerne la sauvegarde d'un document recherché lorsque ce document est présent dans les mémoires caches de premier niveau. En particulier, la suppression de la réalisation d'une copie de sauvegarde de ce document dans les mémoires caches de deuxième niveau est essentielle pour assurer la compatibilité entre les mémoires caches de premier niveau, mémoires caches réparties, et les mémoires caches de deuxième niveau, mémoires caches coopérantes. Ainsi, le procédé, objet de la présente invention, permet-il de récupérer tout document demandé par une requête HTTP par l'intermédiaire des mémoires caches de deuxième niveau en l'absence de réalisation de copie de sauvegarde au niveau de ces dernières. Un tel mode opératoire permet en particulier une simplification de la gestion des mémoires caches de deuxième niveau et, notamment, de mise en oeuvre de ces dernières, toute mémoire de masse pouvant être supprimée. Le procédé, objet de la présente invention, permet bien entendu de maintenir l'accès à des bases de données lointaines, c'est-à-dire au serveur d'origine, dans des conditions semblables au procédé de gestion de mémoires de premier niveau, procédé de gestion CARP, et procédé de gestion des mémoires caches coopérantes de deuxième niveau, procédé protocole de gestion ICP. Le procédé objet de l'invention permet également l'application d'une fonction de hachage utilisée pour la gestion des mémoires caches réparties, de premier niveau, pour permettre l'allocation de documents requis par une mémoire cache ICP externe, ce mode opératoire constituant un facteur de compatibilité du procédé, objet de la présente invention, vis-à-vis des protocoles de gestion existants. Les éléments nécessaires à la mise en oeuvre du procédé, objet de la présente invention, peuvent être implémentés sous forme d'instructions dans le BIOS du système d'exploitation du processeur équipant le proxy géré par le protocole de gestion ICP dans le cas o celui- ci ne comporte pas de mémoire de masse. Si au contraire une mémoire de masse est présente, alors, des données relatives à la gestion des mémoires caches réparties de premier niveau peuvent être mémorisées au niveau de cette mémoire de masse, bien que la réalisation d'une copie de sauvegarde ne soit pas nécessaire. Enfin, le protocole de gestion des mémoires réparties, lorsque ce protocole de gestion est le protocole CARP, peut également être modifié si nécessaire. La mise en oeuvre du procédé, objet de la présente invention, permet ainsi d'obtenir des avantages essentiels tels que le maintien de l'équilibre des charges et des performances offertes par le protocole de gestion CARP tout en conservant le bénéfice des avantages du protocole de gestion ICP pour la localisation de documents non- existants dans les mémoires caches voisines, sans qu'il soit nécessaire d'avoir systématiquement accès au serveur d'origine. Un autre avantage du procédé, objet de la présente invention, consiste également dans le fait de l'absence de nécessité d'espace mémoire de masse en raison de l'absence d'exécution d'une copie de sauvegarde au niveau de la mémoire cache coopérante locale. La mise en oeuvre du procédé, objet de la présente invention, a révélé une amélioration de 30% des performances de l'ensemble vis-à-vis de la seule utilisation du protocole de gestion CARP. Une description plus détaillée d'un système de mémoires caches particulièrement adapté à la mise en oeuvre du procédé, objet de la présente invention, sera maintenant donnée en liaison avec la figure 2b et les figures 3a, 3b et suivantes. En référence à la figure 2b, on rappelle que les mémoires caches réparties de premier niveau portent les références RCM1 à RCM3 et que les mémoires caches coopérantes de deuxième niveau portent les références CCM1 pour la mémoire cache coopérante locale, CCM2 pour une mémoire cache coopérante semblable et CCM3 pour une mémoire cache coopérante parente, l'ensemble de ces mémoires caches coopérantes constituant des mémoires caches coopérantes de deuxième niveau. Selon un aspect particulièrement remarquable du système de mémoires caches, objet de la présente invention, on indique que les mémoires caches réparties de premier niveau RCM1 à RCM3 assurent le partage de la fonction cache vis-à-vis du serveur d'origine. On comprend en particulier que les mémoires caches réparties de premier niveau assurent le partage de la fonction cache vis-à-vis du serveur d'origine représenté en figure 2b, mais également vis-à-vis de tout serveur interrogé par le terminal utilisateur non représenté au dessin. Selon un autre aspect particulièrement remarquable du système de mémoires caches, objet de la présente invention, les mémoires caches coopérantes de deuxième niveau assurent prioritairement la transmission des requêtes HTTP, des réponses à ces requêtes et la transmission de l'objet requis par le terminal utilisateur à partir d'une autre mémoire cache coopérante de deuxième niveau ou du serveur d'origine précédemment cité. On comprend en effet que par le jeu de la connexion en réseau de l'ensemble des mémoires caches précitées, les mémoires caches coopérantes permettent, par le protocole de gestion de ces mémoires caches coopérantes, le protocole ICP ainsi que mentionné précédemment dans la description à titre illustratif, de rechercher et de transmettre le document requis, soit au niveau du serveur d'origine, soit au niveau d'un ensemble de mémoires caches réparties de premier niveau. Ainsi, selon une caractéristique particulièrement remarquable du système de mémoires caches, objet de la présente invention, les mémoires caches réparties de premier niveau assurent la gestion descendante de chaque requête HTTP non satisfaite, requête 1000 sur la figure 2b, vers les mémoires caches coopérantes de deuxième niveau, et l'ensemble du processus décisionnel relatif à la sauvegarde répartie de l'objet requis dans les mémoires caches réparties de premier niveau RCM1 à RCM3. Compte tenu du système de mémoires caches et du procédé de gestion de ces mémoires caches conformes à l'objet de la présente invention, il est alors possible, dans un mode de réalisation préférentiel non limitatif des mémoires caches coopérantes locales, telles que la mémoire CCM1 par exemple, de définir une structure préférentielle non limitative telle que représentée en figure 3a. Conformément au système de mémoires caches, objet de la présente invention, chaque mémoire cache coopérante locale telle que la mémoire CCM1 appartenant aux mémoires caches coopérantes de deuxième niveau peut ainsi comprendre une unité de calcul, notée 1, et une mémoire morte, notée 2. L'unité de calcul 1 comprend, de manière avantageuse, un microprocesseur ou un microcontrôleur, noté CCPU, lequel est interconnecté à une mémoire vive RAM. La mémoire morte 2 de type ROM est également connectée à l'unité de calcul 1, et de manière plus spécifique au microprocesseur ou au microcontrôleur. La mémoire morte peut être une mémoire morte de type ROM accessible uniquement en lecture ou, le cas échéant et de préférence, une mémoire morte reprogrammable électriquement, dite de type REPROM. Enfin, une unité d'entrée/sortie 3, notée I/O, est prévue, laquelle est reliée également par une liaison par BUS à l'unité de calcul 1. Dans la structure telle que représentée de manière non limitative en figure 3a, on indique que la mémoire cache coopérante locale CCM1 permet ainsi d'assurer la transmission des requêtes HTTP, des réponses à ces requêtes et la transmission de l'objet en l'absence de mémoire de sauvegarde de cet objet. Dans un autre mode de réalisation spécifique tel que représenté en figure 3b, chaque mémoire cache coopérante locale, telle que la mémoire CCM1 représentée en figure 2b et appartenant aux mémoires caches coopérantes de deuxième niveau, peut avantageusement comprendre, dans la mémoire morte 2, une série d'instructions permettant la mise en oeuvre d'un protocole interactif d'accès aux données mémorisées des mémoires caches réparties de premier niveau. Dans ce but, et de manière non limitative ainsi que représenté sur la figure 3b, à la mémoire cache coopérante locale CCM1 est en outre associée une base de données interne contenant un index des documents mémorisés au niveau des mémoires caches réparties RCM1 à RCM3. Ainsi que représenté sur la figure 3b, et en référence aux notations précédentes, 1007 représente une requête ICP provenant d'une mémoire cache coopérante externe non représentée en figure 2b, 1007a représente une requête de la mémoire cache coopérante locale CCM1 à la base de données interne, 1007b représente la réponse de la base de données interne à la mémoire cache coopérante locale CCM1. Si l'index relatif au document a été trouvée, une réponse ICP contenant les données d'index est engendrée en 1006 par la mémoire cache coopérante locale CCM1. On comprend que l'index précité comporte une indication relative au document et une indication relative à la mémoire cache comportant ce document. Au contraire, lors de la réception d'une requête HTTP provenant du terminal utilisateur, requête notée 1000 sur la figure 3b, chaque requête HTTP peut elle-même être munie d'un index correspondant au format des index contenus dans la base de données interne. Les réponses à la requête HTTP 1000 portent les références 1003, 1002 et 1001 ainsi que représenté en figure 2b. La mise à jour de la base de données interne peut être effectuée à partir des mémoires caches réparties RCM1 à RCM3 par un signal de synchronisation. Dans un mode de réalisation spécifique tel que représenté en figure 4, chaque mémoire cache coopérante locale, telle que la mémoire CCM1, comporte en outre dans la mémoire morte 2 précédemment mentionnée la fonction de répartition de cet objet dans les mémoires caches réparties de premier niveau. Sur la figure 4, on a représenté la fonction de répartition FR comme consistant en un ensemble de données numériques FR1, FR2, FR3 mémorisées dans la mémoire morte 2 précitée, cette mémoire morte étant dans ce cas constituée par une mémoire reprogrammable électriquement. La fonction de répartition comprend un index relatif au document mémorisé dans chaque mémoire cache répartie RCM1, RCM2, RCM3, et une adresse de mémorisation dans chaque mémoire correspondante en fonction des disponibilités de chaque mémoire cache répartie. On rappelle que la gestion des mémoires caches réparties est effectuée selon une procédure de gestion connue en tant que telle, cette gestion étant assurée par exemple selon le protocole CARP précédemment mentionné dans la description. La mémoire cache coopérante locale CCM1 est alors en mesure, à partir d'une fonction de hachage, de rechercher chaque objet ou document sauvegardé dans les mémoires caches réparties de premier niveau, et requis par une requête ICP par exemple, par adressage direct des mémoires caches réparties RCM1 à RCM3 précitées. Sur la figure 4, la notion d'adressage direct est symbolisée par les flèches reliant directement la fonction de répartition FR par l'intermédiaire de la fonction de hachage à chaque mémoire cache répartie précitée. Bien entendu, la constitution d'une base de données interne au niveau de chaque mémoire cache coopérante locale peut être envisagée. Toutefois, l'introduction d'une telle base de données interne, laquelle doit être intégrée comme un module spécifique de la mémoire cache coopérante locale, implique l'adjonction d'une mémoire non volatile reprogrammable telle qu'une mémoire utilisée dans les cartes à microprocesseurs par exemple afin d'assurer la mise à jour de l'ensemble. Une telle mémoire n'est pas représentée en figure 3a mais peut correspondre à celle qui est nécessaire à la mise en oeuvre de la base de données interne représentée sur la figure 3b. Afin de remédier à l'inconvénient précité et conformément à un aspect particulièrement remarquable du système de mémoires caches, objet de la présente invention, tel que représenté en figure 5, la base de données associée à ce système de mémoires caches peut être externe. Dans un tel cas, la base de données n'est plus localisée au niveau de la mémoire cache coopérante locale CCME par exemple, mais peut être implantée sur un endroit quelconque du réseau. Dans un tel cas, un mode de gestion des requêtes HTTP et requêtes ICP en mode vignette est préférentiellement mis en oeuvre. On indique que la notion de vignette correspond sensiblement à celle d'index pour la base de données interne, à la différence que chaque vignette est ainsi associée à une requête HTTP ou à une requête ICP afin de gérer les adresses des mémoires caches réparties contenant le document recherché. En tout état de cause, la base de données externe contient un fichier indexé du contenu des mémoires caches réparties de premier niveau représentées par RCM1, RCM2 et RCM3 sur la figure 5. Sur requête HTTP 1000, cette requête étant munie d'une vignette contenant au moins un index d'identification du document ou objet recherché, index noté ID-OBJ, la recherche du document est transmise par une requête HTTP 1003 aux mémoires caches réparties précitées. Sur réponse positive, le document étant trouvé dans l'une des mémoires caches précitées en référence au numéro d'identification ID-OBJ de ce document, une réponse HTTP 1002 est renvoyée vers le terminal utilisateur. Si le document n'est pas trouvé dans les mémoires caches réparties précitées, une requête ICP est envoyée par la mémoire cache coopérante locale CCM1 vers la base de données externe. La base de données externe peut être reliée à la mémoire cache coopérante locale, soit par l'intermédiaire d'un protocole interactif, noté 1008a, 1008b, lorsque la base de données externe est sur un même site que la mémoire cache coopérante locale, soit par le protocole de gestion des mémoires caches coopérantes, protocole ICP, lorsque la base de données n'est pas située au voisinage de la mémoire cache coopérante locale, ainsi qu'il sera décrit ultérieurement dans la description. L'interrogation de la base de données externe précitée permet alors de compléter la vignette à partir des données contenues dans la base de données précitée, au numéro d'identification d'objet ID- OBJ étant ajouté par concaténation une adresse de mémoire cache répartie contenant le document recherché. La vignette correspondante représentée en figure 6 est ajoutée à la requête ICP, laquelle est alors transmise par exemple en une étape 1006 sur la figure 5. Lorsque la base de données externe est située au voisinage de la mémoire cache coopérante locale, le protocole de communication interactif utilisé est établi entre cette base de données externe et le système d'interfaçage utilisateur/serveur désigné par "proxy". Sur la figure 7, on a représenté au contraire la base de données externe située à un endroit quelconque du réseau, c'est-à-dire en fait en dehors de tout voisinage de la mémoire cache coopérante locale CCM1. Dans ce cas, l'interrogation de la base de données est effectuée à partir de la mémoire cache coopérante locale CCM1 par l'intermédiaire du protocole de gestion des mémoires caches coopérantes, c'est-à-dire du protocole ICP par l'intermédiaire des requêtes et réponses ICP 1006, 1007, 1008, 1009. La base de données externe peut être mise à jour à partir des mémoires caches réparties de premier niveau. Dans le cas o la base de données externe est gérée par l'intermédiaire du protocole de gestion des mémoires caches coopérantes, le protocole ICP, l'opération de mise à jour de la base de données externe peut alors être effectuée à partir du suivi du flux de données relatif à chaque objet. Un mode de gestion plus particulier des requêtes HTTP et ICP en mode vignette sera maintenant décrit en liaison avec la figure 8. Ce mode de gestion concerne une mémoire cache coopérante locale telle que la mémoire CCM1, dont le mode de réalisation correspond sensiblement au mode de réalisation de la figure 5 dans le cas o la base de données est externe. Les requêtes et les réponses portent les mêmes références que dans le cas de la figure 5. En référence à la figure 8, on rappelle que chaque mémoire cache coopérante locale est systématiquement en état d'attente, 3000, de réception d'une requête HTTP ou d'une requête ICP. Sur réception d'une requête HTTP, en 3001, cette requête HTTP comportant au moins l'identification ID-OBJ de l'objet en mode vignette, l'existence de cette vignette est vérifiée en une étape 3002 au niveau de la mémoire cache coopérante locale. Sur réponse positive à l'étape 3002 et en présence de la vignette considérée, une recherche du document correspondant au numéro d'identification ID-OBJ de ce dernier est effectuée dans les mémoires caches réparties RC1 à RC3. La recherche du document est effectuée en fonction du numéro d'identification de ce dernier, à l'étape 3003. Le document est bien entendu transmis et la mémoire cache coopérante locale retourne à l'état d'attente 3000. Sur réponse négative au test de vérification de la vignette 3002, la requête HTTP est ignorée à l'étape 3004. Lors de la réception d'une requête ICP, à l'étape 3005, cette requête ICP comporte au moins une vignette comprenant le numéro d'identification du document ou objet recherché. Un test 3006 est effectué par interrogation de la base de données externe lorsque la vignette est présente dans la requête ICP. Sur réponse négative au test 3006, la vignette n'étant pas présente dans la requête ICP, cette requête est ignorée à l'étape 3004. Au contraire, sur réponse positive à l'étape 3006, la requête ICP est transmise à la base de données externe par une requête ICP et la base de données, à l'étape 3007, renvoie une réponse, la réponse 1009, dans laquelle la vignette a été complétée avec le numéro de référence de la mémoire cache contenant le document ou l'objet recherché. Une réponse ICP avec la vignette complétée est renvoyée par la mémoire cache coopérante locale CCM1 et cette dernière revient à l'état d'attente 3000. Le processus de gestion en mode vignette précité apparaît particulièrement intéressant dans la mesure o il est susceptible d'être mis en oeuvre par un simple paramétrage du protocole HTTP à l'aide de chaque instruction GET[Document] o Document représente une liste de différents documents recherchés. REVENDICATIONS 1. Système de mémoires caches dans un réseau de transmission de requête HTTP d'accès à un objet constitué notamment par des pages HTML gérées par un serveur d'origine et de réponses HTTP contenant cet objet entre un utilisateur auteur de la requête d'accès à partir d'un terminal utilisateur, ce réseau comportant des mémoires caches réparties, gérées selon un protocole de gestion de mémoires caches réparties, et des mémoires caches coopérantes, comportant au moins une mémoire cache coopérante locale et des mémoires caches coopérantes voisines, les mémoires caches réparties et coopérantes, locales et voisines étant interconnectées en réseau au serveur d'origine, caractérisé en ce que ledit système comporte: - des mémoires caches réparties de premier niveau assurant le partage de la fonction cache vis- à-vis du serveur d'origine, et - des mémoires caches coopérantes de deuxième niveau assurant prioritairement la transmission desdites requêtes HTTP, des réponses à ces requêtes et la transmission de cet objet à partir d'une autre mémoire cache coopérante de deuxième niveau ou du serveur d'origine, lesdites mémoires caches réparties de premier niveau assurant la gestion descendante de chaque requête HTTP non satisfaite vers lesdites mémoires caches coopérantes de deuxième niveau et l'ensemble du processus décisionnel relatif à la sauvegarde répartie de cet objet dans lesdites mémoires caches réparties de premier niveau. 2. Système selon la revendication 1, caractérisé en ce que chaque mémoire cache coopérante locale appartenant auxdites mémoires caches coopérantes de deuxième niveau comprend une unité de calcul et une mémoire morte, permettant d'assurer la transmission desdites requêtes HTTP, des réponses à ces requêtes et la transmission de cet objet, en l'absence de mémoire de sauvegarde de cet objet. 3. Système selon la revendication 2, caractérisé en ce que chaque mémoire cache coopérante locale appartenant auxdites mémoires caches coopérantes de deuxième niveau comporte en outre dans ladite mémoire morte une série d'instructions permettant la mise en euvre d'un protocole interactif d'accès aux données mémorisées desdites mémoires caches réparties de premier niveau. 4. Système selon la revendication 3, caractérisé en ce que chaque mémoire cache coopérante locale appartenant auxdites mémoires caches coopérantes de deuxième niveau comporte en outre dans ladite mémoire morte la fonction de répartition de cet objet dans lesdites mémoires caches réparties de premier niveau, ce qui permet à ladite mémoire cache coopérante locale de rechercher chaque objet sauvegardé dans lesdites mémoires caches réparties de premier niveau par adressage direct de ces mémoires caches réparties. 5. Système selon la revendication 3, caractérisé en ce que celui-ci comporte en outre une base de données externe contenant un fichier indexé du contenu des mémoires caches réparties de premier niveau, ladite base de données étant mise à jour par un processus de synchronisation en relation avec lesdites mémoires caches réparties de premier niveau. 6. Système selon la revendication 5, caractérisé en ce que ladite base de données externe est gérée par l'intermédiaire d'un protocole de communication interactif entre cette base de données externe et le système d'interfaçage utilisateur/serveur "proxy". 7. Système selon la revendication 5, caractérisé en ce que ladite base de données externe est gérée par l'intermédiaire du protocole de gestion des mémoires caches coopérantes, l'opération de mise à jour étant effectuée à partir du suivi du flux de données relatif à chaque objet. 8. Système selon l'une des revendications 6 ou 7, caractérisé en ce que pour une gestion en mode vignette des requêtes et des réponses HTTP et des requêtes et des réponses des mémoires caches coopérantes de deuxième niveau, à chaque requête HTTP est associée une vignette comportant au moins un numéro de référence du document recherché par le terminal utilisateur, et en ce que chaque mémoire cache coopérante locale étant en état d'attente de réception d'une requête HTTP ou d'une requête selon le protocole de gestion des mémoires caches coopérantes de deuxième niveau, chaque mémoire cache coopérante locale permet: - sur réception d'une requête HTTP: * de vérifier la présence de cette vignette et sur réponse positive à cette étape de vérification, * de retrouver le document recherché dans la mémoire cache répartie à partir de cette vignette; * de retourner à cet état d'attente après transmission du document recherché au terminal utilisateur; et - sur réception d'une requête selon le protocole de gestion des mémoires caches coopérantes de deuxième niveau, chaque mémoire cache coopérante locale permet: * d'adresser une requête contenant ladite vignette à la base de données externe; * de compléter au niveau de la base de données externe ladite vignette avec l'adresse ou numéro d'identification de la mémoire cache répartie contenant ledit document recherché; * de transmettre à partir de la mémoire cache coopérante locale une réponse selon le protocole de gestion des mémoires caches coopérantes comportant ladite vignette comportant l'adresse de la mémoire cache répartie contenant le document recherché; a de retourner à l'état d'attente.