FR 2800224 A1 20010427 FR 0011032 A 20000829 PROCEDE ET SYSTEME DE MISE EN ANTEMEMOIRE DE DONNEES HTTP TRANSPORTEES AVEC DES DONNEES DE SOCKS DANS DES DATAGRAMMES IP Domaine Technique de l'Invention La présente invention concerne les réseaux d'ordinateurs et, plus particulièrement, un procédé et un système pour mettre en antémémoire des données HTTP transportées avec des données Socks dans un Datagramme de Protocole Internet (IP). Art Antérieur La présente invention concerne les réseaux d'ordinateurs et, plus particulièrement, un procédé et un système pour mettre en antémémoire des données HTTP transportées avec des données Socks dans un Datagramme de Protocole Internet (IP). La présente invention concerne les réseaux d'ordinateurs et, plus particulièrement, un procédé et un système pour mettre en antémémoire des données HTTP transportées avec des données Socks dans un Datagramme de Protocole Internet (IP). La présente invention concerne les réseaux d'ordinateurs et, plus particulièrement, un procédé et un système pour mettre en antémémoire des données HTTP transportées avec des données Socks dans un Datagramme de Protocole Internet (IP). INTERNET L'Internet est un réseau global d'ordinateurs et de réseaux d'ordinateurs (le "Net"). Internet relie des ordinateurs utilisant une variété des systèmes d'exploitation ou de langages différents, y compris UNIX, DOS, Windows, Macintosh, et autres. Pour faciliter et permettre la communication parmi ces divers systèmes et langages, Internet utilise un langage que l'on appelle TCP/IP ("Transmission Control Protocol/Internet Protocol"). Le protocole TCP/IP supporte trois applications fondamentales sur Internet : . la transmission et la réception de messagerie électronique, # l'utilisation à distance d'ordinateurs (le "Telnet"), et # le transfert de fichiers et de programmes d'un ordinateur à un autre ("FTP" ou "File Transfer Protocol"). TCP/IP La suite TCP/IP comprend deux des protocoles les plus importants : # un protocole de contrôle de transmission (TCP), et # un protocole Internet (IP). Le terme plus usuel TCP/IP est utilisé pour désigner la totalité de la suite. Le premier but qui a été visé au niveau de la conception de TCP/IP a été de construire une interconnexion de réseaux offrant des services de communication universels : un internetwork, ou Internet. Chaque réseau physique dispose de sa propre interface de communication en fonction de la technologie, sous la forme d'une interface de programmation offrant des services de communication de base fonctionnant entre les réseaux physiques et les applications utilisateur. L'architecture des réseaux physiques est cachée à l'utilisateur. Le deuxième but de TCP/IP est d'interconnecter différents réseaux physiques pour former ce qui apparaît à l'utilisateur comme étant un grand réseau unique. TCP est un protocole de la couche transport permettant le transfert des données de bout en bout. Il est responsable d'échanges fiables d'information entre 2 systèmes d'ordinateur. Une pluralité d'applications peuvent être supportées simultanément sur une connexion TCP entre deux systèmes d'ordinateur. IP est un protocole de la couche de réseau Internet qui masque derrière lui l'architecture physique du réseau. Une partie des messages entre les ordinateurs sert à l'acheminement (au routage) des messages et assure que les messages sont correctement dirigés dans le réseau et délivrés à leur destination. IP assure cette fonction d'acheminement (de routage). Un message IP est appelé un Datagramme IP. Des Protocoles de Niveau Application sont utilisés dans la partie supérieure du protocole TCP/IP pour transférer des données utilisateur et applicatives d'un système d'ordinateur origine à un système d'ordinateur destinataire. De tels protocoles de Niveau Application sont par exemple le File Transfer Protocol (FTP), Telnet, Gopher, Hyper Text Transfer Protocol (HTTP). ROUTEUR IP Un "Routeur" est un ordinateur qui assure l'interconnexion de deux réseaux et la transmission des messages d'un premier réseau à l'autre. Les routeurs sont en mesure de sélectionner le meilleur chemin de transmission entre les réseaux. La fonction de base du routage est assurée dans la couche IP de la pile de protocole TCP/IP, si bien qu'un éventuel hôte (ou ordinateur) ou poste de travail fonctionnant sous TCP/IP avec plus d'une interface peut en théorie transmettre des messages entre des réseaux. Du fait qu'IP assure les fonctions de routage de base, le terme "Routeur IP" est souvent utilisé. Cependant, des équipements matériels dédiés à des réseaux particuliers, que l'on appelle "Routeurs" peuvent fournir des fonctions de routage plus sophistiquées que les fonctions minimales mises en oeuvre au sein d'IP. WORLD WIDE WEB Avec l'augmentation de la taille et de la complexité d'Internet, des outils ont été développés pour aider l'utilisateur à trouver de l'information sur le réseau. Ces outils sont appelés souvent des "navigateurs" ou des "systèmes de navigation". Les systèmes de navigation qui ont été développés comprennent des standards tels que Archie, Gopher et WAIS. Le World Wide Web ("WWW" ou "Le Web") est un système de navigation supérieur récent. Le Web est : # un système de navigation à base Internet, # un système de distribution et de gestion d'information destiné à l'Internet, et # un format dynamique pour communiquer sur le Web. Le Web intègre l'information de façon transparente pour l'utilisateur, que ce soit des images fixes, du texte, du son (de l'audio) ou de la vidéo. Un utilisateur opérant sur le Web, utilisant une interface graphique utilisateur ("GUI", que l'on prononce "gooey") peut communiquer de façon transparente avec différents ordinateurs hôtes sur le système, différents systèmes d'application (y compris FTP et Telnet), et différents formats de fichiers et de documents incluant, par exemple, du texte, du son et des graphiques. HYPERMEDIA Le Web utilise de l'hypertexte et de l'hypermédia. L'hypertexte est un sous-ensemble de l'hypermédia et désigne des "documents" électroniques basés sur ordinateurs, dans lesquels les lecteurs peuvent se déplacer d'un endroit à un autre à l'intérieur d'un même document, ou se déplacer d'un document à l'autre, de manière non linéaire. Pour se faire, le Web utilise une architecture client-serveur. Les serveurs Web permettent à l'utilisateur d'accéder à de l'information hypertexte et hypermédia au travers le Web et au moyen de l'ordinateur (L'ordinateur de l'utilisateur est un ordinateur qui est client des Serveurs Web). Les clients envoient des requêtes à destination des Serveurs Web, qui réagissent, effectuent des recherches et répondent. Le Web permet à un logiciel d'application client de demander à recevoir des documents hypermédias (comprenant du texte, de l'audio, de la vidéo et/ou des graphiques, formatés), avec des liens hypertextes vers d'autres documents hypermédias à partir d'un serveur de fichier Web. Le Web, ensuite, peut être vu comme étant un ensemble de fichiers/documents, résidant sur des ordinateurs Web, interconnectés par des hyperliens au moyen de protocoles de réseau, et formant un "Web" virtuel couvrant l'Internet. ADRESSES UNIFORMISEES DE RESSOURCE Une ressource sur Internet est identifiée, de façon non ambiguë, par une adresse URL Uniform Resource Locator - URL) qui est un pointeur désignant une ressource particulière en un emplacement particulier. Une URL spécifie le protocole utilisé pour accéder au serveur (par exemple, HTTP, FTP,..), le nom du serveur, et l'emplacement d'un fichier sur ce serveur. PROTOCOLE DE TRANSFERT HYPERTEXTE Chaque page Web visualisée sur l'écran du client Web peut apparaître sous la forme d'un document complexe intégrant, par exemple, du texte, des images, du son et de l'animation. Chaque page de ce type peut également contenir des hyperliens allant vers d'autres documents Web, de manière qu'un utilisateur se trouvant sur un ordinateur client, puisse en utilisant une souris et en cliquant sur des icônes, activer un hyperlien et sauter sur une nouvelle page (qui est une représentation graphique d'un autre fichier/document) située sur le même serveur Web ou sur un serveur Web différent. Un serveur Web est un programme logiciel sur un ordinateur hôte Web. Il répond a des demandes émanant de clients Web, connectés typiquement sur Internet. L'ensemble du Web utilise un langage ou un protocole particulier pour communiquer avec les clients Web. Ce protocole est appelé protocole de transfert de documents hypertextuels (Hyper Text Transfert Protocol - "HTTP"). Tous les types de données peuvent être échangés entre les serveurs Web et les clients Web, en utilisant ce protocole, que ce soit le langage de description de documents hypertextuels (Hyper Text Markup Language - "HTML"), des éléments graphiques, du son et de la vidéo. HTML décrit l'agencement, le contenu et les hyperliens des document et des pages. Les clients Web, lorsqu'ils effectuent une recherche : # convertissent des instructions spécifiées par l'utilisateur en des requêtes GET HTTP, # se connectent au serveur Web approprié pour obtenir de l'information, et # attendent une réponse. La réponse issue du serveur Web peut être le document objet de la requête ou bien un message d'erreur. Après que le document ou bien un message d'erreur ait été retourné, la connexion entre le client Web et le serveur Web est fermée. Dans la première version de HTTP, il n'y a aucune connexion continue entre client et serveur. Le client Web utilisant HTTP reçoit une réponse sous la forme de données HTML ou bien sous forme d'autres données. Cette description s'applique à la version 1. 0 du protocole HTTP. La nouvelle version 1.1 va au-delà cette barrière en conservant, dans certaines conditions, à l'état actif la connexion entre le serveur et le client. NAVIGATEUR (Browser) Après réception, le client Web formate et présente les données ou active une application auxiliaire, telle qu'un lecteur sonore, pour présenter les données. Pour ce faire, le serveur ou le client détermine les divers types de données reçus. Le client Web est également qualifié de navigateur Web (Web Browser), étant donné que, en fait, il navigue sur des documents récupérés du serveur Web. NOMS DE DOMAINE Les noms des hôtes ou des ordinateurs (tels que www. entreprise.com) sont traduits en des adresses Internet numériques (comme 194.56.78.3), et vice versa, en utilisant un procédé appelé DNS ("Serveur de Noms de Domaine") ("Domain Name Service"). DNS est supporté par des serveurs résidents sur le réseau, connus également comme étant des serveurs de noms de domaine ou des serveurs DNS. INTRANET Certaines sociétés utilisent le même mécanisme que le Web pour communiquer à l'intérieur de leur propre organisation. Dans ce cas, le mécanisme est appelé "Intranet". Ces sociétés utilisent les mêmes protocoles de réseau/transport et des serveurs Web basés localement pour fournir un accès à une grande quantité d'information, de manière cohésive. Etant donné que ces données peuvent être des données confidentielles ou à usage privé pour certaines sociétés et du fait que les membres de ces sociétés doivent également avoir accès à de l'information Web publique, afin d'éviter que des personnes n'appartenant pas à ces sociétés puisse accéder à l'Intranet privé à partir de l'Internet public, les sociétés protègent l'accès à leur réseau par utilisation d'un équipement spécial que l'on appelle un Coupefeu (Firewall). FIREWALL Un Coupefeu protège un ou plusieurs ordinateurs, ayant des connections Internet, d'un accès à partir d'ordinateurs externes connectés à l'Internet. Un Coupefeu est une configuration de réseau, comprenant habituellement du matériel et du logiciel, formant une barrière (ou frontière) entre les ordinateurs connectés en réseau à l'intérieur du Coupefeu et ceux installés à l'extérieur du Coupefeu. Les ordinateurs situés à l'intérieur du Coupefeu forment un sous-réseau sécurisé, ayant des capacités d'accès internes et des ressources partagées, qui ne sont pas offertes à des ordinateurs extérieurs. Souvent, l'accès à la fois aux ordinateurs internes et externes est contrôlé par une machine unique, ladite machine comprenant le Coupefeu. Etant donné que l'ordinateur sur lequel se trouve un Coupefeu interagit directement avec l'Internet, des mesures de sécurité strictes contre tout accès indésirable venant d'ordinateurs externes sont nécessaires. Un Coupefeu est habituellement utilisé pour protéger de l'information, telle qu'un courrier électronique ou des fichiers de données, à l'intérieur d'un bâtiment physique ou d'un site d'une organisation. Un Coupefeu a comme effet de réduire le risque d'intrusion de la part de personnes non autorisées, depuis l'Internet. Les mêmes mesures de sécurité peuvent limiter ou nécessiter un logiciel spécial de la part du personnel opérant à l'intérieur du Coupefeu, personnel souhaitant accéder à de l'information se trouvant à l'extérieur dudit Coupefeu. Un Coupefeu peut être configuré en utilisant des serveurs passerelles appelés "Serveurs Proxy" ou de "Socks", pour contrôler l'accès à de l'information, de chaque côté du Coupefeu. SERVEUR PROXY Un Proxy HTTP est un serveur spécial qui fonctionne typiquement en liaison avec un logiciel Coupefeu. Il permet un accès à Internet depuis l'intérieur d'un Coupefeu. Le Serveur Proxy : # attend une requête (par exemple une requête HTTP) venant de l'intérieur du Coupefeu, # transmet la requête au serveur distant situé à l'extérieur du Coupefeu, # lit la réponse, et # retourne la réponse au client. Un ordinateur unique peut faire fonctionner une pluralité de serveurs, chaque connexion de serveur étant identifiée par un numéro de port. Un Serveur Proxy, tel qu'un serveur HTTP ou un serveur FTP, occupe un port. Typiquement, une connexion utilise des numéros de ports standardisés pour chaque protocole (par exemple, HTTP = 80 et FTP = 21). Ceci est la raison pour laquelle l'utilisateur final doit sélectionner un numéro de port spécifique pour chaque Serveur Proxy. Les navigateurs Web laissent habituellement à l'utilisateur final le choix du nom de l'hôte et du numéro de port des Serveurs Proxy, à partir d'une table ou d'un écran personnalisable. Des protocoles, tels que HTTP, FTP, Gopher, WAIS, et Security, peuvent avoir des Serveurs Proxy désignées. Les Proxy sont généralement préférés aux Socks, du fait de leur aptitude à utiliser de l'antémémoire, à faire de l'enregistrement de haut niveau, à faire du contrôle d'accès, et du fait qu'ils fournissent une connexion spécifique à chaque protocole de service du réseau. MISE EN ANTEMEMOIRE HTTP HTTP est un protocole de Niveau Application utilisé par les connexions TCP entre les Navigateurs WEB et les Serveurs Proxy HTTP. Par conséquent, les Datagrammes IP échangés entre les navigateurs Web et les Serveurs Proxy HTTP comprennent des données HTTP. Etant donné que les Serveurs Proxy HTTP gèrent les connexions HTTP, ils voient et traitent les données HTTP comprises dans les datagrammes IP. Lorsqu'un Serveur Proxy reçoit depuis un système source (un Navigateur WEB) une requête, dans le but de récupérer des données HTTP (une page WEB) placées sur un système destinataire (un serveur WEB), deux situations peuvent se produire, selon que les données HTTP requises sont déjà stockées dans une antémémoire locale ou non. # Si les données HTTP requises sont déjà placées dans l'antémémoire locale, le Serveur Proxy HTTP envoie immédiatement une réponse au système source, avec les données stockées dans l'antémémoire. # Si les données HTTP requises ne sont pas placées dans l'antémémoire locale, le Serveur Proxy HTTP transmet la requête au système WEB destinataire (le Serveur WEB). Lorsque le Serveur Proxy HTTP reçoit de ce système WEB destinataire (le serveur WEB) la réponse comprenant les données HTTP (la page WEB), il mémorise lesdites données HTTP (la page WEB) dans son antémémoire locale et transmet la réponse au système source (le Navigateur WEB). Lorsque des données HTTP sont déjà placées dans l'antémémoire, la requête n'a pas à être transmise par le Serveur Proxy HTTP au système WEB destinataire. Une réponse est retournée immédiatement par le Serveur Proxy HTTP. La mise en antémémoire HTTP offre plusieurs avantages : # Le temps de réponse du service HTTP est amélioré. Le Serveur Proxy HTTP répond immédiatement à la requête en récupérant les données HTTP lorsque les données HTTP sont déjà stockées dans l'antémémoire du Serveur Proxy HTTP. # L'utilisation des ressources de réseau est optimisée. Aucun trafic n'est nécessaire entre le Serveur Proxy HTTP et le système WEB destinataire pour des données HTTP requises et déjà stockées dans l'antémémoire. SOCKS ET SERVEUR SOCKS Socks est un protocole qui effectue une certaine forme d'encapsulation des Protocoles de Niveau Application (par exemple FTP, Telnet, Gopher, HTTP). En utilisant Socks, le trafic au Niveau Application - entre un système faisant fonctionner un logiciel client Socks et un système faisant fonctionner un Logiciel serveur SOCKS - est encapsulé dans un tunnel Socks virtuel entre les deux systèmes. Socks est principalement utilisé par les systèmes évoluant dans l'Intranet afin d'obtenir un accès sécurisé auprès des systèmes placés à l'extérieur de l'Intranet. Un Serveur Socks agit comme un relais entre les systèmes situés à l'intérieur de l'Intranet et les systèmes situés à l'extérieur de l'Intranet, cachant ainsi les systèmes internes à l'Internet externe. Un Serveur Socks est considéré comme étant une sorte de Coupefeu. Un Serveur Socks (également appelé Passerelle Socks) est un logiciel permettant à des ordinateurs situés à l'intérieur d'un Coupefeu d'avoir accès à l'Internet. Un Serveur Socks est usuellement installé sur un serveur positionné soit à l'intérieur, soit sur le Coupefeu. Pour atteindre l'Internet, les ordinateurs situés à l'intérieur du Coupefeu, accèdent au Serveur Socks comme les Clients Socks. Les Navigateurs Web demandent généralement à l'utilisateur final de déterminer le nom de l'hôte et le numéro de port des Serveur Socks à partir d'un écran personnalisable. Sur certains systèmes d'exploitation, le Serveur Socks est spécifié dans un fichier séparé (par exemple le fichier socks.conf). Etant donné que le Serveur Socks agit comme une couche sous-jacente aux protocoles (HTTP, FTP,..), il ne peut mettre en antémémoire des données (comme le Proxy le fait) parce qu'ils ne décode pas le protocole pour connaître quel type de données il transfère. Les publications ci-après, incorporées ici à titre de référence, permettent d'obtenir des explications supplémentaires concernant le domaine technique présenté ci-dessus : # "TCP/IP Tutorial and Technical Overview" par Martin W. Murhammer, Orcun Atakan, Stefan Bretz, Larry R. Pugh, Kazunari Suzuki, David H. Wood, International Technical Support Organization, Octobre 1998, GG24337605. # "Java Network Programming" par Elliotte Rusty Harold, publié par O'Reilly, Février 1997. # "Internet in a Nutshell" par Valerie Quercia, publié par O'Reilly, Octobre 1997. # "Building Internet Firewalls" by Brent Chapman et Elizabeth Zwichky, publié par O'Reilly, Septembre 1995. PROBLEME Le problème consiste à mettre en antémémoire des données HTTP dans un environnement Socks. Les Serveurs Socks sont utilisés dans un Intranet pour offrir un accès sécurisé vers des systèmes placés à l'extérieur de l'Intranet. Le protocole Socks est une forme d'encapsulation du trafic de Niveau Application, tel que HTTP, FTP, Telnet. Le protocole Socks (contrairement à HTTP) est le protocole qui est utilisé par les connexions TCP établies dans l'Intranet entre les Navigateurs WEB et les Serveurs Socks. Par conséquent, des Datagrammes IP échangés entre des Navigateurs WEB et des Serveurs Socks comprennent des données Socks. Dans un environnement Socks, les Routeurs IP et les dispositifs de réseau que l'on trouve dans l'Intranet ne voient et ne traitent que le trafic Socks. En conséquence, les Protocoles de Niveau Application (y compris HTTP) encapsulés par Socks ne sont pas vus et ne sont donc pas traités par un éventuel Routeur IP et de façon plus générale par un éventuel dispositif de réseau situé dans le réseau TCP/IP. Etant donné que les données HTTP transportées dans les Datagrammes IP ne sont pas vues par les Routeurs IP dans un environnement Socks, les Routeurs IP ne peuvent mettre en antémémoire lesdites données HTPP. Le problème est ensuite de mettre en antémémoire dans les Routeurs IP les données HTTP transportées dans les Datagrammes IP. Les solutions actuelles traitent partiellement de ce problème : # Des Serveurs Proxy HTTP fournissant la mise en antémémoire HTTP peuvent être utilisés à la place des Serveurs Socks pour accéder aux systèmes extérieurs à l'Intranet. Les navigateurs Web se trouvant dans l'Intranet peuvent ensuite être configurés pour accéder à ces systèmes extérieurs à l'Intranet via ces Serveurs Proxy HTTP. L'inconvénient majeur est le suivant : # les Serveurs Proxy HTTP peuvent traiter le protocole HTTP (et quelques protocoles additionnels tels que FTP), mais ne peuvent traiter certains autres protocoles (tels que Telnet). En conséquence, l'accès à des systèmes extérieurs à l'Intranet est limité aux protocoles particuliers supportés par le Serveur Proxy HTTP. Cette limitation peut poser problème si un protocole qui n'est pas supporté par le Serveur Proxy HTTP est nécessaire pour une activité particulière. # Une combinaison de Serveurs Socks et de Serveurs Proxy HTTP offrant une mise en antémémoire HTTP peut être utilisée pour obtenir l'accès à des systèmes extérieurs à l'Intranet. L'inconvénient majeur est que : # la configuration des Navigateurs WEB (et des postes de travail des utilisateurs finaux) dans l'Intranet devient alors complexe. Chaque poste de travail doit être configuré avec de multiples informations telles que l'adresse de chaque Serveur Proxy HTTP pour les protocoles principaux (tels que HTTP, FTP, et Secure HTTP), et l'adresse de chaque Serveur Socks. Cette complexité entraîne parfois des erreurs au niveau de la configuration des postes de travail, ce qui peut entraîner des problèmes. # Les Serveurs Socks qui sont utilisés par les postes de travail pour obtenir l'accès à des systèmes extérieurs à l'Intranet peuvent être améliorés pour permettre la mise en antémémoire HTTP. L'inconvénient majeur est que : . La mise en antémémoire des données HTTP n'est pas optimisée. En particulier, l'utilisation des ressources du réseau dans l'Intranet n'est pas réduite parce que la mise en antémémoire est effectuée à la limite de l'Intranet et non pas à l'intérieur de l'ossature de l'Intranet. Etant donné que les données HTTP sont mises en antémémoire dans les Serveurs Socks, toutes les requêtes pour récupérer des données HTTP passent par l' Intranet. Il est généralement admis que plus la mise en antémémoire HTTP se fait près des postes de travail, plus cette mise en antémémoire HTTP est efficace. Le problème est que les Serveurs Socks sont habituellement éloignés des postes de travail des utilisateurs finaux. Objets de l'invention # Un objet de la présente invention est de mettre en antémémoire des données HTTP transportées dans des Datagrammes IP, comprenant des données Socks. # Un autre objet de la présente invention est d'optimiser les performances pour accéder au WEB, via des Serveurs Socks, en mettant en antémémoire des données HTTP dans le réseau Intranet. # Encore un autre objet de la présente invention est d'optimiser l'utilisation des ressources liées au réseau Intranet, et de réduire le trafic HTTP dans le réseau Intranet. Résumé de l'invention La présente invention concerne les réseaux d'ordinateurs et, plus particulièrement, un système et un procédé dans un dispositif de réseau pour mettre en antémémoire des données de protocole de transfert d'hypertexte (HTTP) transportées dans un Datagramme de protocole Internet (IP) envoyé sur une connexion Socks établie sur une connexion de Protocole de Contrôle de Transmission (TCP) entre un port source situé sur un dispositif source et un port destinataire situé sur un dispositif destinataire. Le procédé comprend des étapes consistant à : # Identifier le dispositif source, le dispositif destinataire, le port sur le dispositif source, le port sur le dispositif destinataire, d'un Datagramme IP entrant. # Déterminer si le Datagramme IP entrant provient d'un client socks ou d'un serveur Socks : Si le Datagramme IP entrant provient d'un client Socks : # Terminer la connexion TCP et la connexion Socks; # Identifier la connexion Socks dans une table; # Identifier le protocole de niveau d'application associé à la connection Socks en se référant à cette table, cette table comprenant, pour chaque connexion Socks, un protocole de niveau application; # Déterminer si ledit protocole de niveau application est HTTP ou non : Si ledit protocole de niveau application est HTTP : # Déterminer si les données HTTP requises par le Datagramme IP entrant se trouvent dans une antémémoire locale dans le dispositif de réseau ou non : Si les données HTTP requises par le Datagramme IP entrant se trouvent dans une antémémoire locale : # Construire un Datagramme IP sortant comprenant les données HTTP requises, récupérées à partir de l'antémémoire locale ; # Envoyer ledit Datagramme IP sortant au client Socks originaire du Datagramme entrant. Brève Description des Dessins Les caractéristiques de l'invention, considérées comme ayant des propriétés nouvelles et inventives, sont indiquées dans les revendications annexées. L'invention elle même, ainsi qu'un mode d'utilisation préféré de celle-ci, d'autres objets et avantages de celle-ci, vont être mieux compris en se référant à la description détaillée ci-après d'un mode de réalisation donné à titre d'illustration avec les dessins annexés, dans lesquels : # La figure 1 est une vue logique d'un système utilisateur accédant au World Wide Web, selon l'art antérieur. # La figure 2 est une vue générale d'un système utilisateur accédant au World Wide Web, selon l'art antérieur. # La figure 3 représente un Datagramme IP selon l'art antérieur. # La figure 4 est une vue générale d'un Client Socks, avec une pluralité de Serveurs Socks selon l'art antérieur. # La figure 5 représente un système de mise en antémémoire de données HTTP transportées par des Datagrammes IP dans un trafic Socks, selon la présente invention. # La figure 6 représente les tables utilisées par l'Extension d'Antémémoire Socks selon la présente invention. # La figure 7 est un schéma du composant Gestionnaire de Connexion Socks installé dans le Système Routeur IP Socks, selon la présente invention. # La figure 8 est un schéma du composant de Point d'Extrémité d'Entrée situé dans le Système Routeur IP Socks selon la présente invention. # La figure 9 est un schéma du composant de Point d'Extrémité Sortant Socks dans le Système Routeur IP Socks selon la présente invention. # La figure 10 est un schéma du composant Gestionnaire de Connexion HTTP installé dans le Système Routeur IP Socks selon la présente invention. # La figure 11 est un schéma du Composant Constructeur TOS Socks installé dans le Système Routeur IP Socks selon la présente invention. Mode de réalisation préféré de l'invention ACCES AU WORLD WIDE WEB Aperçu Logique La Figure 1 représente un système utilisateur avec une interface utilisateur (102), comprenant un Navigateur Web (101) pour accéder au World-Wide-Web (WWW). Le contenu WWW est transféré par utilisation du protocole HTTP. Les requêtes et les réponses HTTP sont échangées entre le programme Navigateur Web (101) et un Serveur Web destinataire (103) contenant l'information WWW à laquelle l'utilisateur souhaite accéder. Le Serveur Socks (104), installé entre le Navigateur Web (101) et le Serveur Web (103), agit comme un relais HTTP intermédiaire. Il transmet les requêtes et les réponses HTTP à leur destination. Le programme du Navigateur Web (101) fait une requête HTTP au Serveur Socks (104) et le Serveur Socks transmet la requête au Serveur Web destinataire (103). Le flux intervenant dans le sens inverse (réponse HTTP), passe de nouveau par le Serveur Socks (104) vers le Navigateur Web (101). De cette manière, le Serveur Socks peut limiter le trafic à des transactions autorisées, selon sa configuration (en se basant sur certaines règles de sécurité et de contrôle d'accès préalablement définies). Par conséquent le Serveur Socks protège le réseau dans lequel le Navigateur Web est situé. Aperçu physique La Figure 2 est un aperçu physique de l'agencement décrit logiquement à la Figure 1. Dans cet exemple particulier, le Navigateur Web (201) fonctionne sur un système (poste/station de travail) relié à un réseau Intranet (202). Le réseau Intranet comprend des dispositifs de réseaux tels que des Routeurs IP 206. Les Serveur Socks (203) protégeant l'Intranet connectent les deux réseaux que sont l'Intranet (privé) (202) et l'Internet (public) (204). Le Serveur Web destinataire (205) est également connecté à l'Internet. Il est important de noter que les Serveurs Socks relient deux réseaux et agissent par conséquent comme intermédiaires pour les communications intervenant entre lesdits deux réseaux. Une pluralité de Serveurs Socks sont souvent utilisés pour offrir des accès d'une façon robuste avec un partage efficace de la charge de trafic. DATAGRAMME IP L'unité de transfert d'un paquet de données dans TCP/IP est appelée Datagramme IP. Il est constitué d'une entête contenant de l'information pour le protocole IP et des données qui ne concernent que le protocole de niveau supérieur. La Figure 3 représente le format d'un Datagramme IP, dans l'environnement décrit aux Figures 1 et 2 : # (301) Datagramme IP. Un Datagramme IP est un message échangé entre 2 systèmes d'ordinateur sur un réseau TCP/IP. Un Datagramme IP est divisé en 2 parties : # une Entête, et # des Données. # (302) Entête de Datagramme IP. L'entête comprend des champs tels que : # l'Adresse IP Source (310) (c'est l'adresse IP de l'ordinateur qui envoie le Datagramme IP). # l'Adresse IP destinataire (311) (c'est l'adresse IP de l'ordinateur qui est le destinataire du Datagramme IP). L'entête du Datagramme IP est principalement utilisée pour acheminer le Datagramme IP à sa destination finale. # (303) Données de Datagramme IP. Ce champ comprend les données envoyées par l'originateur (l'émetteur) au système d'ordinateur destinataire. Le système d'ordinateur destinataire traite ces données. Etant donné que la suite de protocole TCP/IP est organisée en couches, ce champ "Données de Datagramme IP" comprend le message concernant le protocole de plus haut niveau (qui est TCP dans l'environnement lié à l'invention). # (304) Segment TCP. Un message TCP est habituellement appelé Segment TCP. # (305) Entête TCP. Une entête TCP comprend des champs tels que le Port Source (312) et le Port Destinataire (313), qui identifient le protocole d'application (par exemple, HTTP, FTP, Telnet, Socks) transporté par TCP. Ce champ est principalement utilisé par le destinataire du Datagramme IP afin de déterminer quelle application doit traiter les données transportées par TCP. # (306) Données TCP. Le champ de Données TCP comprend des données d'application qui sont envoyées par l'originateur (l'émetteur) au système d'ordinateur destinataire. Le système d'ordinateur destinataire traite les données. Etant donné que la suite de protocole TCP/IP est organisée en couches, la partie Données TCP contient l'information concernant le protocole de plus haut niveau qui est le protocole de Niveau Application (tel que HTTP, FTP, Telnet, Socks). # (307) Message de Niveau Application. La partie Données TCP du Datagramme IP contient un Message de Niveau Application. Ceci est par exemple un message Socks (par exemple, un message "CONNECT" ou "BIND", un message HTTP, un message FTP, ou un message Telnet). Selon le protocole de niveau application, ce Message de Niveau Application peut également être divisé en 2 parties. # (308) Entête de Niveau Application. L'Entête de Niveau Application est l'entête concernant le protocole d'application, tel que HTTP, FTP, Telnet. # (309) Données de Niveau Application. C'est la partie données qui est traitée par l'application responsable du traitement du protocole de Niveau Application. Il s'agit usuellement des données qui concernent directement l'utilisateur final (par exemple, les données introduites par un utilisateur final sur son poste de travail). CLIENT SOCKS ET SERVEUR SOCKS Un Socks est un protocole Proxy de réseau permettant à des postes de travail client d'avoir plein accès à des hôtes extérieurs à leur réseau local, tout en fournissant un haut degré de sécurité. La Figure 4 représente le poste de travail d'un utilisateur final (401) relié à un Intranet (402). Les Serveurs Socks (403) qui protègent l'Intranet relient à la fois l'Intranet (privé) (402) et l'Internet (public) (404). Le Système Web destinataire (405) connecte également l'Internet (le Système Web est par exemple un Navigateur WEB, un Serveur FTP, ou tout système attaché à l'Internet, qui peut faire l'objet d'un accès depuis l'Intranet). Le poste de travail de l'utilisateur final (401) comprend un programme Logiciel qui est appelé Client Socks (407), permettant un accès sécurisé au World-Wide-Web (WWW) via un Serveur Socks. Le Client Socks crée une certaine forme de "tunnel virtuel" (que l'on appelle une "Connexion Socks") entre le poste de travail et le Serveur Socks. Le protocole Socks est indépendant du protocole de Niveau Application et peut par conséquent être utilisé par exemple pour des communications HTTP, FTP ou Telnet. La connexion Socks, prévue pour transporter des données Socks, est créée au moyen d'une connexion TCP établie entre le Client Socks et le Serveur Socks. Le Routeur IP (406) installé dans l'Intranet achemine vers sa destination chaque Datagramme IP qu'il reçoit, en utilisant le champ d'Adresse IP Destinataire dans l'entête du Datagramme IP. Les applications WEB fonctionnant sur le poste de travail de l'utilisateur final (tel un Navigateur WEB (408), un Client FTP (409) ou un Client Telnet (410)) utilisent les services d'un Client Socks (407) pour accéder à un système Web extérieur (405). Le Client Socks situé sur le poste de travail de l'utilisateur final envoie (411) chaque Datagramme IP sur le réseau Intranet à un Serveur Socks destinataire. Des Routeurs IP installés dans l'Intranet reçoivent les Datagrammes IP et les acheminent (412) vers leur Serveur Socks destinataire. Le Serveur Socks authentifie l'utilisateur, autorise la requête, établit une connexion (413) avec le système WEB extérieur, puis transmet de façon transparente les données applicatives entre le poste de travail et le système WEB (414). SYSTEME SOCKS A ROUTEUR IP La présente invention concerne un système et un procédé permettant de mettre en antémémoire des données HTTP transportées avec des données Socks dans des Datagrammes IP. La Figure 5 représente un Routeur IP Socks selon la présente invention. Le poste de travail de l'utilisateur final (501), comprenant un Client Socks, est relié à l'Intranet (502). Ledit Intranet comprend une pluralité de Serveurs Socks (503) pour accéder au Système Web (505) connecté à l'Internet (504). Le Routeur IP qui est en charge, dans l'Intranet, du traitement des Datagrammes IP en transportant les données IP est appelé "Système Routeur IP Socks" (506)". Le Système Routeur IP Socks selon la présente invention comprend : # un composant de Routage IP (514) pour assurer l'acheminement de tout Datagramme IP dans l'Intranet. Ce composant de routage IP peut être constitué par tout Routeur IP existant. # Un composant d'Extension d'Antémémoire Socks (507). Les trafics Entrant et Sortant sont traités différemment dans l'Extension d'Antémémoire Socks : ' Trafic Entrant : il s'agit du Trafic (515) (518) intervenant entre le poste de travail de l'utilisateur final (501) et le Routeur IP Socks (506). Une connexion TCP établie entre le poste de travail de l'utilisateur final et le Routeur IP Socks est appelée "Connexion TCP Entrante". Une connexion TCP comprenant des données Socks entre le poste de travail de l'utilisateur final et le Routeur IP Socks est appelée "Connexion Socks Entrante". # Trafic Sortant : il s'agit du Trafic (516) (517) intervenant entre le Routeur IP Socks (506) et un Serveur Socks (503). Une connexion TCP entre le Routeur IP Socks et un Serveur Socks est appelée "Connexion TCP Sortante". Une connexion TCP avec des données Socks entre le Routeur IP Socks et un Serveur Socks est appelée "Connexion Socks Sortante". EXTENSION D'ANTEMEMOIRE SOCKS L'Extension d'Antémémoire Socks : # achève et gère les connexions Socks Entrante et Sortante, # met en antémémoire les données HTTP transportées dans le Datagramme IP reçu, ce Datagramme IP comprenant des données Socks, et # établit le relais entre connexion Socks Entrante et connexion Socks Sortante. Lorsque le Système Routeur IP Socks (506) reçoit (515) un Datagramme IP depuis un poste de travail (501) ou (517) d'un Serveur Socks (503), il commence par transmettre ce Datagramme IP (que l'on appelle le Datagramme IP Entrant) à l'Extension d'Antémémoire Socks (507). Ledit Datagramme IP Entrant est ensuite transmis à une pluralité d'autres composants afin de mettre en oeuvre le procédé selon la présente invention : # (508) Un Composant Gestionnaire de Connexion Socks : # détermine si le Datagramme IP Entrant appartient soit à une connexion Socks Entrante soit à une connexion Socks Sortante, # achève et gère la connexion (connexion Socks Entrante et Sortante) selon le protocole TCP. # (509) Un composant Point d'Extrémité Entrant Socks : # achève et gère la connexion Socks Entrante selon le protocole Socks, # analyse le Datagramme IP Entrant, # construit une table de Connexion Socks (511) avec les caractéristiques de la connexion Socks Entrante, et # détermine si ledit Datagramme IP transporte des données HTTP, en se basant sur l'information comprise dans la table de Connexion Socks (511) et au vu des champs Adresse IP Source, Port Source, Adresse IP Destinataire et Port Destinataire dudit Datagramme IP. # (510) Un composant de Point d'Extrémité Sortant Socks : # achève et gère la connexion Socks Sortante selon le protocole Socks, et # détermine si le Datagramme IP Entrant transporte des données HTTP en se basant sur l'information comprise dans la table de Connexion Socks (511) et au vu des champs Adresse IP Source, Port Source, Adresse IP Destinataire et Port Destinataire dudit diagramme IP. # (512) Un composant Gestionnaire de Connexion HTTP, comprend un composant de Mise en Antémémoire HTTP pour : # achever et gérer la connexion HTTP, selon le protocole HTTP, # récupérer des données HTTP (par exemple une page WEB), appelées Données HTTP Sortantes, lorsque le Datagramme IP entrant comprend une requête pour récupérer desdites données HTTP, # construire un message HTTP, appelé message HTTP Sortant, comprenant lesdites données HTTP sortantes, # fournir la mise en antémémoire locale des données HTTP (par exemple une page WEB) récupérées depuis des systèmes WEB, dans le Système Routeur IP Socks. L'invention est indépendante du composant de Mise en Antémémoire HTTP compris dans le Gestionnaire de Connexion HTTP et ne dépend pas de la manière selon laquelle les données HTTP comprises dans le Datagramme IP Entrant sont traitées et sont mises localement en antémémoire par ce composant de Mise en Antémémoire HTTP. # (513) Un composant Relais Socks : # met à jour la table de Connexion Socks (511) avec les caractéristiques de la Connexion Socks Sortante associée à la Connexion Socks Entrante, et # relaie des données comprises dans le Datagramme IP entrant, entre la connexion Socks Entrante et la connexion Socks Sortante associée. Le composant Relais Socks construit un Datagramme IP sortant, en utilisant : # la table de Connexion Socks (511), # le message HTTP sortant, fourni par le Gestionnaire de Connexion HTTP, # les champs Adresse IP Source, Port Source, Adresse IP Destinataire et Port Destinataire du Datagramme IP Entrant. L'Extension d'Antémémoire Socks transmet enfin le Datagramme Sortant, construit par le composant Relais Socks, au composant Routeur IP (507) installé dans le Système Routeur IP Socks. Le composant Routeur IP achemine le Datagramme IP Sortant vers sa destination (soit (516) un Serveur Socks, soit (518) le poste de travail d'un utilisateur final). L'invention est indépendante du composant Routeur IP et ne repose pas sur la manière selon laquelle le Datagramme IP est traité et est acheminé par Le composant Routeur IP. L'Extension d'Antémémoire Socks peut être validée ou invalidée, par exemple par un paramètre configurable sur ledit Système Routeur IP Socks. Typiquement, l'Extension d'Antémémoire Socks : # est validée sur les Systèmes Routeur IP Socks d'accès se situant à la limite de l'Intranet. # est invalidée sur les Systèmes Routeur IP Socks situés à l'intérieur de l'ossature Intranet. TABLES D'EXTENSION D'ANTIMEMOIRE SOCKS La Figure 6 montre les différentes tables utilisées par les différents composants de l'Extension d'Antémémoire Socks, pour analyser et relayer le trafic Socks. L'Extension d'Antémémoire Socks construit et utilise dynamiquement une table interne, à des fins internes : # (601) Table de Connexion Socks. Cette table comprend, pour chaque Connexion Socks Entrante, l'identificateur de la Connexion Socks Sortante et le protocole de Niveau Application. Cette table interne est détaillée à la Figure 6. TABLE DE CONNEXION SOCKS La table de Connexion Socks (601) est une table interne construite par le Composant de Point d'Extrémité Entrante Socks et par le Composant de Relais Socks. Cette table est utilisée par tous les Composants de l'Extension d'Antémémoire Socks afin de mémoriser pour chaque Connexion Socks Entrante, l'identificateur de la Connexion Socks Sortante et le protocole de Niveau Application. La table contient une liste d'enregistrements (602), chaque enregistrement comprenant l'information suivante : # (603) Sous-Enregistrement Entrant. Ce sous-enregistrement (un par enregistrement (602)) identifie la connexion Socks Entrante (la connexion entre le poste de travail de l'utilisateur final et le Système Routeur IP Socks). Il comprend l'information suivante : # (606) In~Source~IP~Adress. Il s'agit de l'Adresse IP du Système à l'origine de la connexion Socks Entrante (ce système est appelé "originateur" ou "dispositif originateur"). Typiquement, c'est l'adresse d'un poste de travail. # (607) In Source Port. C'est le numéro du Port identifiant le programme (l'application) fonctionnant sur le dispositif originateur et qui est à l'origine de la connexion Socks Entrante. # (608) In~Dest~IP~Adress. C'est l'adresse IP du système qui est destinataire de la connexion Socks Entrante (ce système est appelé "destinataire" ou "dispositif destinataire"). Typiquement, c'est l'adresse du Serveur Socks. Ce n'est pas l'adresse du Système Routeur IP Socks étant donné que le poste de travail de l'utilisateur final établit des connexions avec des Serveur Socks et non pas avec le Système Routeurs IP Socks (le Système Routeurs IP Socks est transparent vis à vis du poste de travail de l'utilisateur final qui lui ne connaît que les Serveur Socks). # (609) In Dest Port. C'est le numéro du Port identifiant le programme (l'application) fonctionnant sur le dispositif destinataire et qui est la destination de la connexion Socks Entrante. La combinaison de In~Source~IP~Address, In~Source~Port, In~Dest~IP~Address, et In~Dest~Port identifie la connexion Socks Entrante de manière unique. # (604) Sous-Enregistrement Sortant. Ce sous-enregistrement (un par enregistrement (602) ) identifie la connexion Socks Sortante (la connexion entre le Système Routeur IP Socks et un Serveur Socks) associé à la connexion Socks Entrante (603). Le sous-enregistrement Sortant comprend l'information suivante : # (610) In~Source~IP~Adress. C'est l'Adresse IP du Système qui est à l'origine de la connexion Socks Sortante (ce système est appelé "originateur" ou "dispositif originateur). C'est typiquement l'adresse du Système Routeur IP Socks. # (611) Out Source Port. C'est le numéro du Port identifiant le Programme (l'application) fonctionnant sur le dispositif d'origine et qui est à l'origine de la connexion Socks Sortante. # (612) Out Dest IP Adress. C'est l'adresse IP du système destinataire de la connexion Socks sortante (ce système est appelé "destinataire" ou "dispositif destinataire"). Typiquement, c'est l'adresse d'un Serveur Socks. # (613) Out Dest Port. C'est le numéro du Port identifiant le programme (l'application) fonctionnant sur le dispositif destinataire et qui constitue la destination de la connexion Socks Sortante. La combinaison de Out~Source~IP~Address, Out~Source~Port, Out~Dest~IP~Address, et Out~Dest~Port identifie d'une manière unique la connexion Socks Sortante. # (605) Cx~ALP. C'est le protocole de Niveau Application (tel que HTTP, FTP, Telnet) utilisé par les données Socks transportées dans le Datagramme IP de la connexion Socks Entrante (603). Etant donné que le même ALP est utilisé entre le poste de travail et le Système Routeur IP Socks (connexion Socks Entrante) et entre le Système Routeur IP Socks et le Serveur Socks (connexion Socks Sortante), Cx ALP est également le protocole de Niveau Application utilisé par des données Socks transportées dans les Datagrammes IP de la connexion Socks Sortante associée à la connexion Socks Entrante. GESTIONNAIRE DE CONNEXION SOCKS Le composant Gestionnaire de Connexion Socks de l'Extension d'Antémémoire Socks est, de préférence, un programme d'ordinateur fonctionnant sur le Système Routeur IP Socks. Ce composant: # Détermine si le Datagramme IP entrant appartient à une connexion Socks Entrante ou à une connexion Socks Sortante, et # Termine la gestion de ladite connexion Socks Entrante et Sortante, selon le protocole TCP. La Figure 7 montre la logique interne du composant Gestionnaire de Connexion Socks. Ce composant : # (701) Récupère un Datagramme IP (le Datagramme IP Entrant). # (702) Teste pour savoir si le Datagramme IP appartient ou non à une connexion Socks Entrante. Le test utilise, de préférence, le champ Port Destinataire de l'entête TCP comprise dans la partie Données du Datagramme IP. Le Port destinataire est comparé au Port utilisant le protocole Socks (par défaut, le Port utilisé par le protocole Socks est 1080) . Par exemple le Port utilisé par le protocole Socks peut être un paramètre de configuration de l'extension d'Antémémoire Socks. Si le Port Destinataire oans l'entête TCP est égal au Port utilisé par Socks, alors le Datagramme IP transporte du trafic Socks vers un Serveur Socks. Le Datagramme IP est par conséquent émis par un poste de travail et, en tant que tel, appartient à une connexion Socks Entrante. # Si le Datagramme IP appartient à une connexion Socks Entrante : # (711) Achève et gère la connexion TCP lancée par le poste de travail de l'utilisateur final, selon le protocole TCP. Le Gestionnaire de Connexion Socks agit comme un Point d'Extrémité Destinataire TCP pour cette connexion Socks Entrante. # (712) Elimine de la table de Connexion Socks (708), les enregistrements des Connexions Socks fermées. Les connexions Socks fermées sont détectées par exemple en utilisant les indications FIN et ACK que l'on trouve dans l'Entête TCP. De façon optionnelle, une connexion Socks est considérée comme fermée après une certaine période de temps sans Datagramme IP sur cette connexion Socks (la durée de cette période de temps peut par exemple être un paramètre de configuration de l'Extension d'Antémémoire Socks). Tout autre algorithme existant pour détecter la fermeture ou la semi-fermeture de connections TCP (par exemple, lorsqu'une extrémité de la connexion a terminé la connexion TCP de façon anormale) peut également être utilisé pour enlever de telles connexions de la table. # (713) Stocke une information indiquant que le Datagramme IP appartient à une connexion Socks Entrante: # Incoming~Cx = Entrante # (714) Appelle le composant de Point d'Extrémité Entrant Socks. # Si le Datagramme IP n'est pas compris dans une connexion Socks Entrante : # Teste en (703) si le Datagramme IP appartient ou non à une connexion Socks Sortante. Le test utilise de préférence le champ de Port Source de l'Entête TCP comprise dans la partie Données du Datagramme IP. Le Port Source est comparé au Port utilisant le protocole Socks (par défaut, le Port utilisé par Socks est 1080). A titre d'exemple, le Port utilisé par le protocole Socks peut être un paramètre de Configuration de l'Extension d'Antémémoire Socks. Si le Port de Source dans l'Entête TCP est égal au Port utilisé par Socks, alors le Datagramme IP transporte du trafic Socks depuis un Serveur Socks. Le Datagramme IP est par conséquent émis par un Serveur Socks et, en tant que tel, appartient à une connexion Socks Sortante. # Si le Datagramme IP appartient à une connexion Socks Sortante : # (706) Achève et gère la connexion TCP lancée par le Serveur Socks, selon le protocole TCP. Le Gestionnaire de Connexion Socks agit comme le Point d'Extrémité Destinataire TCP pour la connexion Socks Sortante. # (707) Supprime de la table de Connexion Socks (708) les enregistrements des connexions Socks fermées. Les connexions Socks fermées sont détectées par exemple en utilisant les indications FIN et ACK que l'on trouve dans l'entête TCP. De façon optionnelle, une connexion Socks est considérée comme fermée après une certaine période de temps pendant laquelle il n'y a pas eu de Datagramme IP (cette période de temps peut être par exemple un paramètre de configuration de l'Extension d'Antémémoire Socks). Tout autre algorithme existant permettant de détecter des connexions TCP fermées ou semi-fermées (par exemple, lorsqu'une extrémité de la connexion s'est terminées de façon anormale), peut également être utilisé pour enlever de telles connexions de la table. # (709) Stocke une information indiquant que le Datagramme IP appartient à une connexion Socks Sortante: # Incoming~Cx = Sortant # (710) Appelle le Composant de Point d'Extrémité Entrant Socks, # Si le Datagramme IP n'est pas compris dans une connexion Socks Sortante : Le Datagramme IP, par conséquent, n'appartient pas à une connexion Socks (ni Entrante, ni Sortante) : # (704) L'Extension d'Antémémoire Socks n'est pas impliquée dans le traitement d'un trafic qui n'est pas un trafic Socks. Le Datagramme IP est transmis directement au composant Routeur IP du Système Routeur IP Socks. # (705) Le traitement effectué par l'Extension d'Antémémoire Socks du Datagramme IP est achevé. L'extension d'Antémémoire Socks attend le prochain Datagramme IP. POINT D'EXTREMITE ENTRANT DE SOCKS Le composant Point d'Extrémité Entrant Socks de l'Extension d'Antémémoire Socks est de préférence un programme d'ordinateur fonctionnant sur le Système Routeur IP Socks. Ce composant est en charge de : # l'achèvement et la gestion de la connexion Socks Entrante selon le protocole Socks; # la construction de la table de Connexions Socks (601) avec les caractéristiques de la connexion Socks Entrante, # la détermination du fait que le Datagramme IP qui a été reçu comprend des données HTTP, en se basant sur l'information comprise dans la table de Connexion Socks (601) et au vu des Champs Adresse IP Source, Port Source, Adresse IP Destinataire, et Port Destinataire dudit Datagramme IP. La Figure 8 montre la logique interne du composant de Point d'Extrémité Entrant Socks. Ce composant : # (801) Récupère un Datagramme IP (le Datagramme IP Entrant). # (802) Achève et gère la connexion Socks émise par le poste de travail d'utilisateur final, selon le Protocole Socks. Le Point d'extrémité Entrant Socks agit comme Point d'Extrémité Destinataire de la Connexion Socks Entrante. # (803) Contrôle pour savoir si le Datagramme IP est un message Socks CONNECT. Un message Socks CONNECT est identifié par le champ CD dans le message de Niveau Application (CD = 1). # Si le Datagramme IP est un message Socks CONNECT : Le Datagramme IP appartient par conséquent à une nouvelle connexion Socks Entrante. # (804) Détermine à partir du Datagramme IP (dans le champ Destport du message Socks CONNECT, le protocole de Niveau Application (ALP) transporté par la connexion Socks : # Datagramme~ALP = Champ Destport (dans le message Socks CONNECT) # (805) Sauvegarde dans un nouvel enregistrement dans la table de Connexion Socks (806) l'information liée à la connexion Socks Entrante. La connexion Socks Entrante est identifiée de façon unique par l'information comprise dans l'entête IP et l'entête TCP, concernant l'originateur et le destinataire du Datagramme IP : # In~Source~IP~Address = champ d'Adresse IP Source (dans l'entête IP) # In~Source~Port = champ Port Source (dans l'entête TCP) # In~Dest~IP~Address = champ d'Adresse IP Destinataire (dans l'entête IP) # In~Dest~Port = champ Port Destinataire (dans l'entête TCP) # Cx ALP = Datagramme~ALP # (807) Teste pour savoir si le Datagramme IP transporte un trafic HTTP ou non. Le test utilise Datagram ALP. Datagram~ALP est comparé au Port utilisant le protocole HTTP (par défaut, le port utilisé par HTTP est 80). Par exemple, le Port utilisé par le Protocole HTTP peut être un paramètre de configuration de l'Extension de Cache d'Antémémoire. Si Datagram~ALP = HTTP, le Datagramme IP transporte du trafic HTTP. # Si le Datagramme IP transporte du trafic HTTP : # (808) Le traitement du Datagramme IP par l'Extension d'Antémémoire Socks est achevé. L'Extension d'Antémémoire Socks attend le prochain Datagramme IP. # Si le Datagramme IP ne transporte pas de trafic HTTP : Aucun traitement HTTP n'est effectué dans l'Extension d'Antémémoire Socks. Les données comprises dans le Datagramme IP Entrant sont relayées vers leur destination. Etant donné que le Datagramme IP Entrant appartient à une Connexion Socks Entrante, les données comprises dans ledit Datagramme IP Entrant sont relayées au moyen d'un Datagramme IP Sortant appartenant à une Connexion Socks Sortante. # (815) Stocke une information indiquant que le Datagramme IP Sortant doit être envoyé sur une Connexion Socks Sortante : # Outgoing~Cx = Sortant # (809) Appelle le Relais Socks, # Si le Datagramme IP n'est pas un message Socks CONNECT : Le Datagramme IP appartient alors à une connexion Socks Entrante déjà établie. Ceci signifie qu'un message CONNECT a déjà été reçu et que l'enregistrement correspondant a déjà été créé dans la table de Connexion Socks. # (810)Récupère tous les enregistrements depuis la table de Connexion Socks (806). # (811) Trouve l'enregistrement qui correspond à la Connexion Socks Entrante à laquelle appartient le Datagramme IP. Cet enregistrement est identifié par quatre conditions) : # In~Source~IP~Address = champ d'Adresse IP Source (dans l'Entête IP) # In~Source~Port = champ Port Source (dans l'Entête TCP) # In~Dest~IP~Address = champ d'Adresse IP Destinataire (dans l'Entête IP) # In~Dest~Port = champ de Port Destinataire (dans l'Entête TCP) # (812)Récupère l'ALP de la connexion Socks Entrante depuis cet enregistrement. C'est le protocole de Niveau Application utilisé par les données Socks, comprises dans le Datagramme IP : # Datagram~ALP = Cx~ALP # (813) Teste pour savoir si le Datagramme IP transporte ou non du trafic HTTP. Le test utilise le Datagram ALP, qui est comparé au Port utilisant le protocole HTTP (par défaut, le Port utilisé par HTTP est 80). Par exemple, le Port utilisé par le protocole HTTP peut être un paramètre de configuration de l'Extension d'Antémémoire Socks. Si Datagram ALP = HTTP, le Datagramme IP transporte du trafic HTTP. # Si le Datagramme IP transporte du trafic HTTP: # (814) Appelle le Gestionnaire de Connexion HTTP # Si le Datagramme IP ne transporte pas de trafic HTTP: Aucun traitement HTTP n'est effectué par l'extension d'Antémémoire Socks. Les données comprises dans le Datagramme IP Entrant sont relayées vers leur destination. Etant donné que le Datagramme IP Entrant appartient à une connexion Socks Entrante, les données comprises dans ledit Datagramme IP sont relayées dans un Datagramme IP Sortant appartenant à une connexion Socks Sortante. # (815) Stocke une information indiquant que le Datagramme IP Sortant doit être envoyé sur une connexion Socks Sortante : # Outgoing~Cx = Sortant # (809) Appelle le Relais Socks. POINT D'EXTREMITE SORTANT DE SOCKS Le composant de Point d'Extrémité Sortant Socks de l'Extension d'Antémémoire Socks est, de préférence, un programme d'ordinateur fonctionnant sur le Système Routeur IP Socks. Ce composant est en charge de : # l'achèvement et la gestion de la Connexion Socks Sortante selon le protocole Socks, # la détermination du fait que le Datagramme IP reçu transporte des Données HTTP, en se basant sur l'information comprise dans la Table de Connexion Socks (601) et, au vu des champs Adresse IP Source, Port Source, Adresse IP Destinataire et Port Destinataire, dudit Datagramme IP. La Figure 9 montre la logique interne du composant Point d'Extrémité Sortant Socks. Ce composant : # (901) Récupère un Datagramme IP (le Datagramme IP Entrant) . Le Datagramme IP appartient à une connexion Socks Sortante. Etant donné qu'une connexion Socks est toujours initiée par un poste de travail d'un utilisateur final sur une connexion Socks Entrante, un message CONNECT a déjà été reçu sur la connexion Socks Entrante associée à cette connexion Socks Sortante. L'enregistrement (602) associée à la connection a, par conséquent, déjà été créé dans la table de Connexion Socks (601). # (902) Achève et gère la connexion Socks initiée par le Serveur Socks selon le protocole Socks. Le composant Point d'Extrémité Sortant Socks agit comme point d'extrémité destinataire pour la connexion Socks Sortante. # (903) Récupère tous les enregistrements depuis la table de Connexion Socks (904). # (905) Trouve l'enregistrement qui correspond à la connexion Socks Sortante. Etant donné que le sous-enregistrement Sortant est créé par le composant Relais Socks avec l'information de source et destination récupérée depuis un Datagramme IP Sortant, ladite information de source et de destination doit être échangée pour traiter un Datagramme IP Entrant. Par exemple, le Serveur Socks qui est le destinataire d'un Datagramme IP Sortant est la source d'un Datagramme IP Entrant. L'enregistrement est ensuite identifié par (quatre conditions) : # Out~Source~IP~Address = champ d'Adresse IP Destinataire (dans l'Entête IP) # Out~Source~Port = champ de Port Destinataire (dans l'Entête TCP) # Out~Dest~IP~Address = champ d'Adresse IP Source (dans l'Entête IP) # Out Dest Port = champ de Port Source (dans l'Entête TCP) # (906) Récupère l'ALP de la connexion Socks Sortante depuis cet enregistrement. Ceci est le protocole de Niveau Application utilisé par les données Socks comprises dans le Datagramme IP : # Datagram~ALP = Cx- # (907) Teste pour savoir si le Datagramme IP transporte du trafic HTTP ou non. Le test utilise Datagram~ALP qui est comparé au Port qui utilise le protocole HTTP (par défaut, le Port utilisé par HTTP est 80). Par exemple, le Port utilisé par le protocole HTTP peut être un paramètre de configuration de l'Extension d'Antémémoire Socks. Si Datagram~ALP = HTTP, alors le Datagramme IP transporte du trafic HTTP. # Si Datagramme IP ne transporte pas de trafic HTTP : Aucun traitement HTTP n'est effectué dans l'Extension d'Antémémoire Socks. Les données comprises dans le Datagramme IP Entrant sont relayées vers sa destination. Etant donné que le Datagramme Entrant appartient à une connexion Socks Sortante, les données comprises dans ledit Datagramme IP sont relayées dans un Datagramme IP Sortant appartenant à une connexion Socks Entrante. # (909) Stocke une information indiquant que le Datagramme IP sortant doit être envoyé sur une connexion Socks Entrante : # Outgoing~Cx = Entrant # (910) Appelle le Relais Socks. # Si le Datagramme IP transporte du trafic HTTP : # (908) Appelle le Gestionnaire de Connexion HTTP. GESTIONNAIRE DE CONNEXION HTTP Le composant Gestionnaire de Connexion HTTP de l'Extension d'Antémémoire Socks est, de préférence, un programme d'ordinateur fonctionnant sur le Système Routeur IP Socks. Ce composant est en charge de : # Achever et gérer la connexion HTTP, selon le protocole HTTP, # Récupérer des données HTTP (par exemple, une page WEB), appelées "données HTTP Sortantes", lorsque le Datagramme IP Entrant comprend une requête pour récupérer desdites données HTTP, # Construire un message HTTP appelé "message HTTP Sortant", comprenant lesdites données HTTP Sortantes, # Exécuter la mise en antémémoire locale des données HTTP (par exemple, une page WEB) récupérées à partir de systèmes WEB, dans le Système Routeur IP Socks. Le Gestionnaire de Connexion HTTP comprend un composant de Mise en antémémoire HTTP. L'invention est indépendante de ce composant de Mise en antémémoire HTTP. Celui-ci peut être un logiciel Proxy HTTP quelconque assurant une fonction de mise en antémémoire HTTP. L'invention ne repose pas sur la façon dont les données HTTP comprises dans le Datagramme IP Entrant sont traitées et mises localement en antémémoire par ce composant de Mise en Antémémoire HTTP. La Figure 10 montre la logique interne du composant de Gestionnaire de Connexion HTTP. Ce composant : # (1001) Récupère un Datagramme IP (qui est un Datagramme IP Entrant) transmis soit par le composant de Point d'Extrémité Entrant Socks, soit par le composant de Point d'Extrémité Sortant Socks. # (1002) Effectue la mise en antémémoire HTTP. Cette fonction est fournie par un composant de Mise en Antémémoire HTTP compris dans le Gestionnaire de Connexion HTTP. L'invention ne dépend pas de ce composant de Mise en Antémémoire HTTP qui peut être un logiciel Proxy HTTP quelconque offrant une fonction de mise en antémémoire HTTP. Fondamentalement, le composant de Mise en Antémémoire HTTP assure les fonctions de tout Proxy HTTP existant, assurant une mise en antémémoire HTTP, c'est-à-dire : # Achèvement et gestion de la connexion HTTP, selon le protocole HTTP, # Récupération de données HTTP (par exemple, une page WEB), appelées "données HTTP Sortantes", lorsque le Datagramme IP Entrant comprend une requête pour récupérer desdites données HTTP, # Construction d'un message HTTP, appelé "message HTTP Sortant", comprenant lesdites données HTTP Sortantes, # Exécution de la mise en antémémoire locale dans le Système Routeur IP Socks, des données HTTP (par exemple, une page WEB) récupérées de systèmes WEB. Ledit message HTTP Sortant est soit : # un message HTTP qui doit être envoyé sur une connexion Socks Entrante à un poste de travail. C'est par exemple un message HTTP comprenant une page WEB qui doit être envoyée au poste de travail d'un utilisateur final. Ce message HTTP Sortant est la réponse à une requête (une instruction GET), précédemment reçue du poste de travail utilisateur final afin de récupérer ladite page WEB. Ladite page WEB est récupérée par le composant de Mise en Antémémoire HTTP, soit depuis : # l'antémémoire locale, lorsque la page WEB requise est située dans l'antémémoire locale, soit # le système WEB destinataire indiqué dans la requête, lorsque la page WEB n'est pas située dans l'antémémoire locale. # Un message HTTP qui doit être envoyé sur une connexion Socks Sortante vers un Serveur Socks. C'est par exemple une réponse (une instruction GET), envoyée à un Serveur Socks pour récupérer une page WEB située sur un système WEB destinataire. Le composant de Mise en Antémémoire HTTP retourne au composant Gestionnaire de Connexion HTTP : # Ledit message HTTP Sortant comprenant les données HTTP Sortantes (par exemple, une page WEB). # Une indication de la direction (soit Entrante, soit Sortante) dudit message HTTP Sortant. Le message HTTP est envoyé à l'intérieur d'un Datagramme IP (appelé Datagramme IP Sortant), soit sur une connexion Socks Entrante (vers le poste de travail d'un utilisateur final), soit sur une connexion Socks Sortante (vers un Serveur Socks) # (1103) teste pour savoir si la direction du message HTTP Sortant, retourné par le composant de Mise en Antémémoire HTTP, est de nature entrante ou non. Cette indication est envoyée par le composant de Mise en Antémémoire HTTP avec le message HTTP Sortant. # Si la direction du message HTTP Sortant est entrante : # (1004) Stocke une information indiquant que le Datagramme IP Sortant, comprenant le message HTTP Sortant, doit être envoyé sur une connexion Socks Entrante : # ~Cx = Entrante Outgoing # (1005) Appelle le Relais Socks # Si la direction du message HTTP Sortant n'est pas Entrante : La direction du message HTTP Sortant est alors sortante # (1006) Stocke une information indiquant que le Datagramme IP Sortant, comprenant le message HTTP Sortant, doit être envoyé sur une connexion Socks Sortante : # Outgoing~Cx = Sortante # (1005) Appelle le Relais Socks RELAIS SOCKS Le composant Relais Socks de l'Extension de Mise en Antémémoire Socks est de préférence un programme d'ordinateur fonctionnant sur le Système Routeur IP Socks. Le composant Relais Socks est en charge de : # la mise à jour de la table de Connexion Socks (511) avec les caractéristiques des connexions Socks Sortantes, # le relayage des données entre les connexions Socks Entrantes et Sortantes, # la construction d'un Datagramme IP Sortant utilisant: # la table de Connexion Socks (511), # le message HTTP Sortant fourni par le Gestionnaire de Connexion HTTP, # les champs Adresse IP Source, Port Source, Adresse IP Destinataire et Port destinataire du Datagramme IP Entrant. La Figure 11 montre la logique interne du composant de Relais Socks. Ce composant : # (1101) Récupère : # Le Datagramme IP (le Datagramme IP Entrant), # L'indication (Incoming~Cx) concernant la direction de la connexion Socks à laquelle appartient le Datagramme IP Entrant. Ladite indication est fournie par le composant Gestionnaire de Connexion Socks. # L'indication (Outgoing~Cx) concernant la direction de la connexion Socks à laquelle appartient le Datagramme IP Sortant. Ladite indication est fournie par le Point d'Extrémité Entrant Socks, le Point d'Extrémité Sortant Socks ou le Gestionnaire de Connexion HTTP. # S'il y en a un, le message HTTP Sortant est passé par le Gestionnaire de Connexion HTTP. # (1102) Récupère tous les enregistrements venant de la table de Connexion Socks (1103). # (1104) Teste pour savoir si le Datagramme IP Entrant appartient à une connexion Socks Entrante. Le test utilise l'indication Incoming~Cx : Si Incoming~Cx = Entrante, alors le Datagramme IP entrant appartient à une connexion Socks Entrante. # Si le Datagramme IP entrant appartient une connexion Socks Entrante : le Datagramme IP entrant est par conséquent émis d'un poste de travail utilisateur final. # (1105) Teste pour savoir le Datagramme IP Sortant doit être envoyé sur une connexion Socks Sortante. Le test est effectué en utilisant l'indication Outgoing~Cx. Si Outgoing~Cx = Sortante, alors le Datagramme IP Sortant doit être envoyé sur une connexion Socks Sortante. # Si le Datagramme IP Sortant appartient à une connexion Socks Sortante : le Datagramme IP Sortant doit par conséquent être envoyé à un Serveur Socks, tandis que le Datagramme IP Entrant est émis à partir d'un poste de travail d'un utilisateur final. # (1106) Trouve l'enregistrement (appelé "record~R") dans la table de Connexion Socks, qui correspond à la connexion Socks Entrante à laquelle le Datagramme IP Entrant appartient. Cet enregistrement est identifié par (quatre conditions) : # In~Source~IP~Address = champ d'adresse IP Source (dans l'Entête IP) # In~Source~Port = champ de Port Source (dans l'Entête TCP) # In~Dest~IP~Address = champ d'adresse IP Destinataire (dans l'Entête IP) # In~Dest~Port = champ de Port Destinataire (dans l'Entête IP) # (1107) Teste pour savoir si "record R" comprend un sous-enregistrement Sortant. # Si "record R" ne comprend pas (encore) un sous-enregistrement Sortant : # (1108) Crée un sous-enregistrement Sortant à l'intérieur dudit enregistrement, dans la table de Connexion Socks (1103). Etant donné que la connexion Socks Sortante relaie la connexion Socks Entrante vers sa destination (un Serveur Socks), la destination de la connexion Socks Sortantes doit être la même que la destination de la connexion Socks Entrante (ledit Serveur Socks) : # Out Dest IP Address = In~Dest~IP~Address # Out Dest IP Port = In~Dest~Port Etant donné que l'Extension d'Antémémoire Socks dans le Système Routeur IP Socks achève la connexion Socks Entrante, l'originateur de la connexion Socks Sortante n'est pas l'émetteur de la connexion Socks Entrante, mais est le Système Routeur IP Socks. Comme toute connexion TCP/IP issue d'un dispositif TCP/IP, l'information source concernant la connexion Socks Sortante est récupérée de la pile TCP/IP comprise dans le Système Routeur IP Socks. # Out Source IP Address = Addresse IP Source (depuis la pile TCP/IP) # Out Source Port Champ Port Source (depuis la pile TCP/IP) "record R" comprend un sous-enregistrement Sortant (ayant été soit nouvellement créé en (1108), soit antérieurement créé à la réception d'un Datagramme IP antérieur). # (1109) Déduit l'information de source et de destination pour le Datagramme IP Sortant, à partir du sous-enregistrement Sortant compris dans l'enregistrement "record~R" # DT Source IP Address = Out Source IP Address # DT Source Port = Out Source Port # DT Dest IP Address = Out Dest IP Address # DT Dest Port = Out Dest Port # (1110) Construit le Datagramme IP Sortant comprenant des données Socks, selon les protocoles IP, TCP, et Socks, en utilisant : # DT~Source~IP~Address et DT~Dest~IP~Address qui sont les valeurs des champs Adresse IP Source (310) et Adresse IP Destination (311) dans l'entête IP. # DT Source Port et DT~Dest~Port qui sont les valeurs des champs Port Source (312) et Port Destinataire (313) dans l'entête TCP. # Le message HTTP, fourni par le Gestionnaire de Connexion HTTP, encapsulé avec des données Socks dans le champ de données de Niveau Application (309) . Les données Socks, comprises dans le Datagramme IP Entrant, qui doivent être relayées (par exemple, les données TCP (306)). # (1111) Appelle le composant Routeur IP pour envoyer le Datagramme IP Sortant vers sa destination. L'Extension d'Antémémoire Socks considère ensuite son travail terminé et attend le Datagramme IP Entrant suivant. # Si le Datagramme IP Sortant n'appartient pas à une connexion Socks Sortante (il appartient alors à une connexion Socks Entrante). Le Datagramme IP Sortant doit par conséquent être envoyé vers un poste de travail. Du fait que le Datagramme IP Entrant provient du poste de travail d'un utilisateur final, le Datagramme IP Sortant doit donc être considéré comme étant une réponse à ce Datagramme IP Entrant. # (1112) Déduit l'information source et destinataire du Datagramme IP Sortant, de l'Entête IP et l'Entête TCP du Datagramme IP Entrant. # DT Source IP Address = Adresse IP destinataire (Entête IP) # DT Source Port = Port destinataire (Entête TCP) # DT Dest IP Address = Adresse IP Source (Entête IP) # DT Dest Port = Port Source (Entête TCP) # (1110) Construit le Datagramme IP Sortant comprenant des données Socks, selon les protocoles IP, TCP, et le (s) protocole (s) Socks, en utilisant : # DT~Source~IP~Address et DT~Dest~IP~Address qui sont les valeurs des champs de l'Adresse IP Source (310) et de l'Adresse IP Destinataire (311) dans l'Entête IP. # DT~Source~Port et DT~Dest~Port qui sont les valeurs des champs Port Source (312) et Port Destinataire (313) dans l'Entête TCP. # Le message HTTP, fourni par le Gestionnaire de Connexion HTTP, encapsulé avec des données Socks, dans le champ de données de Niveau Application (309). # Les données Socks, comprises dans le Datagramme IP Entrant, devant être relayées (par exemple, les données TCP (306)). # (1111) Appelle le composant Routeur IP afin d'envoyer le Datagramme IP Sortant à sa destination. L'Extension d'Antémémoire Socks considère ensuite son travail comme terminé et attend le Datagramme IP Entrant suivant. # Si le Datagramme Entrant n'appartient pas à une connexion Socks entrante (il appartient alors à une connexion Sortante). Le Datagramme IP Entrant est par conséquent issu d'un Serveur Socks. # (1113) Teste pour savoir si le Datagramme IP Sortant doit être envoyé sur une connexion Socks Sortante. Le test est fait par utilisation de l'indication Outgoing Cx. Si Outgoing~Cx = Sortant, alors le Datagramme IP Sortant doit être envoyé sur une connexion Socks Sortante. # Si le Datagramme IP Sortant n'appartient pas à une connexion Socks Sortante (il appartient alors à une connexion Socks Entrante). Le Datagramme IP Sortant doit par conséquent être envoyé à un poste de travail, tandis que le Datagramme IP Entrant est originaire d'un Serveur Socks. # (1114) Trouve l'enregistrement (appelé "record~R") dans la table de Connexion Socks, qui correspond à la connexion Socks Sortante à laquelle appartient le Datagramme de IP Entrant. Etant donné que le sous-enregistrement Sortant est créé par le composant de Relais Socks avec l'information de source et de destination récupérée depuis un Datagramme IP sortant, ladite information de source et de destination doit être échangée pour traiter un Datagramme IP entrant. Par exemple, le Serveur Socks qui est le destinataire d'un Datagramme IP Sortant est la source d'un Datagramme IP Entrant. Cet enregistrement est ensuite identifié par (quatre conditions) : # Out~Source~IP~Address = champ d'Adresse IP Destinataire (dans l'Entête IP) # Out~Source~Port = champ de Port Destinataire (dans l'Entête TCP) # Out Dest IP Address = champ d'Adresse IP Source (dans l'Entête IP) # Out Dest Port - champ de Port Source (dans l'Entête TCP) # (1115) prend le sous-enregistrement Entrant, depuis "record R". # (1116) Déduit l'information de source et de destination à partir du Datagramme IP Sortant, depuis le sous-enregistrement Entrant compris dans l'enregistrement "record~R". Etant donné que le sous-enregistrement Entrant est créé avec une information de source et de destination récupérée à partir d'un Datagramme IP Entrant, ladite information de source et de destination doit être échangée pour traiter un Datagramme IP Sortant. Par exemple, le poste de travail d'un utilisateur final source d'un Datagramme IP Entrant devient destination d'un Datagramme IP Sortant. # DT Source IP Address = In Destination IP Address # DT~Source~Port = In~Destination~Port # DT~Dest~IP~Address = In~Source~IP~Address # DT Dest Port = In~Source~Port # (1110) Construit le Datagramme IP Sortant comprenant des données Socks, selon les protocoles IP, TCP et Socks, en utilisant: # DT Source IP Address et DT~Dest~IP~Address comme étant les valeurs des champs Adresse IP Source (310) et Adresse IP Destination (311) dans l'entête IP. # DT~Source~Port et DT~Dest~Port , comme étant les valeurs des champs Port Source (312) et Port Destinataire (313), dans l'entête TCP. *Le message HTTP, fourni par le Gestionnaire de Connexion HTTP, encapsulé avec des données Socks, dans le champ de données de Niveau Application (309). *Les données Socks comprises dans le Datagramme IP Entrant, devant être relayées (par exemple, les données TCP (306)). # (1111) Appelle le composant de Routeur IP pour envoyer le Datagramme IP Sortant à sa destination. L'Extension d'Antémémoire Socks considère ensuite le travail comme terminé et attend le Datagramme IP Entrant suivant. # Si le Datagramme IP Sortant appartient à une connexion Socks Sortante. Le Datagramme IP Sortant doit alors être envoyé à un Serveur Socks. Puisque le Datagramme IP Entrant provient d'un Serveur Socks, le Datagramme IP Sortant constitue, par conséquent, une réponse à ce Datagramme IP Entrant. # (1112) Déduit l'information de source et de destination concernant le Datagramme IP Sortant, à partir de l'Entête IP et l'Entête TCP du Datagramme IP Entrant. # DT Source IP Address = Adresse IP Destinataire (Entête IP) # DT~Source~Port = Port Destinataire (entête TCP) # DT~Dest~IP~Address = Adresse IP Source (entête IP) # DT Dest Port = Port Source (Entête TCP) # (1110) construit le Datagramme IP Sortant comprenant des données Socks, selon les protocoles IP, TCP et Socks, en utilisant : # DT~Source~IP~Address et DT Dest IP Address qui sont les valeurs des champs Adresse IP Source (310) et Adresse IP Destination (311) compris dans l'Entête IP. # DT Source Port et DT Dest Port qui sont les valeurs des champs Port Source (312) et Port Destinataire (313) compris dans l'Entête TCP. # du message HTTP, fourni par le Gestionnaire de Connexion HTTP, encapsulé avec des données Socks, dans le champ de données de Niveau Application (309). # des données Socks, comprises dans le Datagramme IP Entrant, devant être relayées (par exemple, les données TCP (306)). * # (1111) Appelle le composant Routeur IP afin d'envoyer le Datagramme IP Sortant vers sa destination. L'Extension d'Antémémoire Socks considère ensuite son travail comme terminé et attend le Datagramme IP Entrant suivant. AVANTAGES # Le temps de réponse du service HTTP est amélioré, car les requêtes pour récupérer des données HTTP (par exemple une page WEB), déjà mémorisées dans l'antémémoire du Système Routeur IP Socks, peuvent être satisfaites immédiatement. # L'utilisation des ressources du réseau est réduite, car il n'y a besoin d'aucun trafic entre le Système Routeur IP Socks et les systèmes WEB destinataires lorsque des données HTTP demandées (par exemple, une page WEB) sont déjà mémorisées dans l'antémémoire. # La mise en antémémoire HTTP est assurée dans un environnement Socks. Les postes de travail accèdent à des systèmes WEB situés à l'extérieur de l'Intranet en passant par des Serveurs Socks (et non en passant par des serveurs Proxy HTTP). # La configuration des postes de travail des utilisateurs finaux qui sont installés dans l'Intranet est très simple. Les postes de travail doivent seulement être configurés pour accéder des Serveur Socks. Les postes de travail n'ont pas à être configurés pour accéder des serveurs Proxy HTTP pour certains protocoles particuliers (par exemple, HTTP et FTP) et des Serveur Socks pour d'autres protocoles particuliers (par exemple Telnet). # La mise en antémémoire HTTP est assurée dans l'ossature Intranet par le Système Routeur IP Socks. Le temps de réponse et l'utilisation des ressources du réseau sont par conséquent optimisés parce que la mise en antémémoire HTTP est faite à proximité des postes de travail. Par exemple, le chemin suivi dans le réseau pour récupérer une page WEB est plus court (avec pour résultat un meilleur temps de réponse) comparé au chemin suivi lorsque la mise en antémémoire HTTP est faite sur les Serveurs Socks. # Il n'y a aucun impact sur les postes de travail des l'utilisateurs finaux. Le Système Routeur IP Socks est transparent vis à vis des postes de travail. Aucun logiciel spécifique n'est nécessaire sur ces postes de travail. Bien que l'invention ait été présentée et décrite de façon particulière en référence à un mode de réalisation préféré, il est évident que différents changements concernant la forme et les détails peuvent y être apportés, sans pour cela s'écarter de l'esprit et du champ de l'invention. REVENDICATIONS 1. Un procédé dans un dispositif de réseau (506), pour mettre en mémoire des données HTTP (Hyper Text Transfer Protocol) transportées dans un Datagramme IP (Internet Protocol), envoyé sur une connexion Socks établie sur une connexion de Transmission Control Protocol (TCP) entre un port source sur un dispositif source et un port destinataire sur un dispositif destinataire, ledit procédé comprend les étapes consistant à : # identifier : # le dispositif source, # le dispositif destinataire, # le port sur le dispositif source, # le port sur le dispositif destinataire, d'un Datagramme IP entrant. # déterminer (702,703) si le Datagramme IP entrant provient d'un client socks (407,501) ou d'un Serveur Socks (503) : Si le Datagramme IP entrant provient d'un client socks (407, 501): # terminer la connexion TCP (711) et la connexion Socks (802); # identifier (812) la connexion Socks (602) dans une table (601); # identifier (812) le protocole de niveau d'application (605) associé à ladite connexion socks (602) en se référant à ladite table (601), ladite table comprenant pour chaque connexion Socks (602) un protocole de niveau d'application (605); # déterminer (813) si ledit protocole de niveau application est HTTP ou non: Si ledit protocole de niveau application est HTTP: # déterminer si les données HTTP requises par le Datagramme IP entrant se trouvent dans une antémémoire locale dans le dispositif de réseau ou non: Si les données HTTP requises par le Datagramme IP entrant se trouvent dans une antémémoire locale: # construire (1110) un Datagramme IP sortant comprenant les données HTTP requises, ayant été récupérées depuis l'antémémoire locale ; # envoyer (1111) ledit Datagramme IP sortant au client socks originaire du Datagramme IP entrant. 2. Le procédé selon la revendication précédente, dans lequel: Si des données HTTP requises par le Datagramme IP ne sont pas dans l'antémémoire locale dans le dispositif de réseau : # identifier (1107) la connexion Socks sortante (604) associée à la connexion Socks (602) en se référant à la table (601), ladite table comprenant pour chaque connexion Socks (602) une connexion Socks sortante (604). # construire (1110) un Datagramme IP sortant avec l'information constituée dans le Datagramme IP entrant. # envoyer (1111) ledit Datagramme IP sortant sur ladite connexion Socks sortante. 3. Le procédé selon l'une quelconque des revendications précédentes, dans lequel ladite étape d'identification (812) de la connexion Socks (602) dans une table (601), comprend les étapes supplémentaires consistant à : # déterminer (803) si le Datagramme IP comprend un message pour établir une nouvelle connexion Socks, en particulier un message CONNECT Socks, ou non; Si le Datagramme IP entrant comprend un message pour établir une nouvelle connexion Socks, en particulier un message CONNECT socks : # définir une connexion Socks entrant entre la source de client socks du Datagramme IP entrant et le dispositif à réseau (506); # mettre à jour (805) la table (601) avec : # une identification de la connexion Socks; # une identification de la connexion Socks entrante associée ; # le protocole de niveau application associé à la connexion Socks. 4. Le procédé selon l'une quelconque des revendications précédentes, dans lequel ladite étape consistant à identifier la connexion Socks sortante (604) associée à la connexion Socks (602) en se référant à la table (601) comprend les étapes supplémentaires consistant à : # définir (1108) une connexion Socks sortante entre le dispositif de réseau (506) et le dispositif destinataire du Datagramme IP entrant; # associer (1108) dans la table (601) ladite connexion Socks sortante (604) à ladite connexion Socks (602) du Datagramme IP entrant. 5. Le procédé selon l'une quelconque des revendications précédentes dans lequel : si le Datagramme IP entrant provient d'un Serveur Socks (503): # achever la connexion TCP (706) et la connexion Socks (902); # identifier (905) la connexion Socks (602) dans la table (601); # identifier (906) le protocole de niveau application (605) associé à ladite connexion Socks en se référant à ladite table (601); # déterminer (907) si ledit protocole de niveau application est un protocole HTTP ou non : Si ledit protocole de niveau application est HTTP : # mettre en antémémoire (1002) les données HTTP comprises dans le Datagramme IP entrant dans l'antémémoire locale du dispositif à réseau; # identifier (1115) la connexion Socks entrante (603) associée à la connexion Socks (602) en se référant au table (601), ladite table comprenant pour chaque connexion Socks (602) une connexion Socks entrante (603). # construire (1110) un Datagramme IP sortant, avec l'information comprise dans le Datagramme IP entrant; # envoyer (1111) ledit Datagramme IP sortant sur la connexion Socks entrante. 6. Le procédé selon l'une des revendications précédentes, dans lequel ledit Datagramme IP comprend un champ d'Adresse IP Source (310) et un champ Adresse IP Destinataire (311) dans une entête IP (302) afin d'identifier le dispositif source et le dispositif destinataire, et un champ Adresse de Port Source (312) et un champ Adresse de Port Destinataire (313) dans une entête (305) à Transmission Control Protocol (TCP), afin d'identifier le port source et le port destinataire sur ledit dispositif source et le dispositif destinataire. 7. Le procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape consistant à déterminer si le Datagramme IP provient d'un client Socks (407,501) ou d'un Serveur Socks (503) comprend l'étape consistant à : # déterminer si la valeur du champ de Port Destinataire (313) compris dans le Datagramme IP est égale à la valeur d'un port destinataire sur un Serveur Socks ou si la valeur du champ Port Source (312) compris dans le Datagramme IP est égale à la valeur d'un port source sur un Serveur Socks. 8. Le procédé selon l'une quelconque des revendications précédentes, dans lequel ladite table (601) est de nature dynamique et comprend, pour chaque connexion Socks (602) : # une identification de la connexion Socks entrante (603); # une identification de la connexion sortante associée (604); # une identification (605) du protocole de niveau application utilisé dans le Datagramme IP utilisant ladite connexion Socks (602). 9. Le procédé selon l'une quelconque des revendications précédentes, dans lequel ladite table comprend : # pour identifier chaque connexion Socks entrant (603) : # une adresse de dispositif source entrant (606) identifiant le dispositif source de la connexion Socks entrante, # une adresse de port source entrant (607) identifiant le port source de la connexion Socks entrante, # une adresse de dispositif destinataire entrant (608) identifiant le dispositif destinataire de la connexion Socks entrante, # une adresse de port destinataire entrant (609) identifiant le port destinataire de la connexion Socks entrante, # pour identifier chaque connexion Socks sortante (604) : # une adresse de dispositif source sortant (610) identifiant le dispositif source de la connexion Socks sortante, # une adresse d'application source sortante (611) identifiant le port source de la connexion Socks sortante, # une adresse de dispositif destinataire sortant (612) identifiant le dispositif destinataire de la connexion Socks sortante, # une adresse d'application destinataire sortant (613) identifiant le port destinataire de la connexion Socks sortante. 10. Un dispositif de réseau, en particulier un routeur (506), comprenant des moyens adaptés pour mettre en oeuvre le procédé selon l'une quelconque des revendications précédentes. 11. Un support lisible par ordinateur, comprenant des instructions pour mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 9.