EP1495619A1 - Dispositif et procede de compression de donnees a la volee - Google Patents

Dispositif et procede de compression de donnees a la volee

Info

Publication number
EP1495619A1
EP1495619A1 EP03740571A EP03740571A EP1495619A1 EP 1495619 A1 EP1495619 A1 EP 1495619A1 EP 03740571 A EP03740571 A EP 03740571A EP 03740571 A EP03740571 A EP 03740571A EP 1495619 A1 EP1495619 A1 EP 1495619A1
Authority
EP
European Patent Office
Prior art keywords
compression
module
request
data
indication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP03740571A
Other languages
German (de)
English (en)
Inventor
Karel Mittig
Eric Maschio-Esposito
Amar Nezzari
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1495619A1 publication Critical patent/EP1495619A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to on-the-fly data compression tools used on networks, and in particular on the Internet. These tools aim to optimize the flow or “bandwidth” and thus increase the speed of information display at the level of the Internet customer.
  • these tools allow a reduction in the loading time of content, that is to say a better perception of the quality of service (QoS) and also a reduction in costs when the connection is billed by volume.
  • QoS quality of service
  • Booster Web which respond to this problem, but none correspond to a real offer at the heart of the network, which can be easily applied to different types of users.
  • Boosters with clients require the installation of a specific module on the client's workstation. This local module on plug'in will actually modify the structure of the messages exchanged between the client and the booster. Communication using the usual HTTP (Hypertext Transport Protocol) protocol is replaced by a proprietary protocol.
  • HTTP Hypertext Transport Protocol
  • TCP boosters modify the structure of messages, others are content to modify the logic for resuming TCP sending by adapting it to the response time of the network such as mobile phones for example.
  • Clientless boosters do not modify http port 80 messages, they use standard headers. But it is then essential to declare them in the properties of browsers as we would for a classic cache. In addition, some boosters also have a "cache" function and others claim to comply with the ICP protocol (communication protocol between caches). These solutions therefore require intervention on the software installed on the user's computer and are therefore far from being transparent to the user. It is proposed according to the invention to resolve this drawback, that is to say to propose a tool and a method of compressing data on the fly which is transparent to the Internet user, that is to say which does not require intervention on the computer or the local network thereof.
  • This object is achieved according to the invention thanks to a method of on-the-fly compression of data supplied by a server of a collective network such as the Internet in response to a request from a consultation terminal, in which method a data compression module, and a redirection module provided for receiving data supplied by the server and redirecting them to the compression module, this redirection module also being provided for receiving data from the compression module and redirecting them towards the consultation terminal, method according to which an indication concerning an aptitude for decompression of the terminal is examined in the request and a compression is performed in the compression module, on the data requested by the request and supplied by the server, which is adapted to the indications of suitability contained in the request.
  • a device for compressing data on the fly in a collective network such as the Internet comprising a compression module and a redirection module, this redirection module being designed to receive data supplied by a server in response to a consultation request sent by a consultation terminal, and redirect this data to the compression module, this redirection module also being intended to receive data supplied back by the compression module and redirect them to the terminal of consultation, this device further including means for examining, in a request for consultation of data sent by a terminal, an indication concerning a decompression ability of the terminal considered, and means for controlling compression by the compression module which is adapted to the indication of capacity for decompression contained in the request.
  • FIG. 1 is a simplified diagram of a data compression assembly according to the invention
  • FIG. 2 is another simplified diagram of an assembly according to the invention.
  • FIG. 3 shows in detail this same assembly according to the invention
  • FIG. 4 shows in detail an iCAP server according to a variant of the invention
  • FIG. 5 is a flowchart representative of a method according to a variant of the invention.
  • FIG. 6 is a flowchart of data and instructions according to a variant of the invention.
  • the device described below uses a data exchange protocol intended to allow modifications of content on the Internet, a protocol called iCAP - Internet Content Adaptation Protocol -.
  • the device of FIG. 1 is architecture around two modules 10 and 20 of the iCAP type, namely a cache 10 of the client iCAP type and a content modification server 20, of the iCAP server type to
  • proxy cache 10 configured in the browser of the user 30 (but it could just as easily be a proxy proxy operating in transparent mode in the context of an ISP - Internet Service Provider -).
  • the cache 10 then sends an HTTP request to an original web server 40, containing this page.
  • the web server 40 returns the requested page to cache 10.
  • Cache 10 now acting as an iCAP client redirects this response to the aforementioned iCAP server 20, passing it the full page.
  • the iCAP server 20 then processes this request by calling on a content modification service integrated into the server, then responds to cache 10 by returning the result of the processing: the modified page (or not as will be seen below).
  • the cache 10 returns the response from the iCAP server 10 to the end user 30 and also stores this response.
  • the cache 10 of the “iCAP client” type is currently available on the market in an industrial version.
  • iCAP offers two main modes (“Request Modification” and “Response Modification”) which are based on the HTTP protocol.
  • iCAP The role of iCAP is not to perform the content transformation itself. It is just limited to connecting "iCAP clients” (web caches, routers, etc.) with “iCAP servers”, the latter being responsible for the transformation.
  • the iCAP forum http://www.i-cap.org was created in December 1999 under the leadership of the companies Network Appliance and Akamai. Its objective is to standardize, through the iCAP protocol (Internet Content Adaptation, Protocol), the exchanges between equipment representative of Web architectures (Web servers, caches, load balancers, routers ...) and content transformation systems .
  • the ICAP 1.25 specification is the most recent. It has already been the subject of several implementations in the context of value-added file transformation services, here are some examples:
  • iCAP Internet-Draft "iCAP the internet content adaptation protocol” http: //www.ietf.orq/internet-drafts/draft-elson-opes-icap-00 .txt) in the Open Proxy Extensible Services Working Group.
  • iCAP Internet-Draft
  • Anti-virus software publishers benefiting from their expertise in network solutions installing on FireWall (curtain of fire) or proxies (proxy) offer a port of their services on iCAP. We are also seeing the appearance of new commercial players in the field of content filtering.
  • the main steps of the compression service are as follows: a) the client 30 sends a request to a Web server 40. This request possibly passes through redirection equipment, here the cache 10. b) the server 40 transmits its response to client 30 via cache 10. c) the redirection service 10 (iCAP client) redirects the response to the iCAP server 20. This server will be referred to below by the more general expression “compression module 20” in order to qualify the main function of this server. d) the response from the server 40 is if possible compressed and / or optimized by the compression module 20. e) the compression module 20 returns the request to the redirection module 10. f) the redirection module 10 returns the response to the client 30. g) the client browser 30 automatically decompresses the document received before displaying it.
  • This compression system (without a specific client or local module - or plug-in -) offers the advantage of not intervening on the software installed on the user's computer 30 (or on the mobile phone or any other consultation terminal used).
  • This compression service also does not modify the network and protocol layers, which avoids possible incompatibilities with other types of services or equipment that would be located between the compression service and the end user.
  • FIGS 3 and 4 show in more detail the preferred device described here.
  • the compression module 20 (or iCAP content transformation module) is broken down into an administrator module 22, a flow adapter module 23, and a service module or sub-module 25 dedicated specifically to compression tasks. Datas.
  • the function of the flow adapter 23 is to adapt the content between the redirection module (iCAP client 10) and the service module 25.
  • Such a stream adapter 23 is preferably provided to adapt the data streams also for a series of other additional service modules, implementing services other than compression, these modules can for example be content filtering modules or anti-virus filtering modules.
  • the adapter 23 is located in the compression module 20, on the one hand, in the client 10 - server 20 direction, adapt the files so that they can be directly used for the file transformation services, and on the other hand, in the server 20 - client 10 direction, ensure the integrity of the transformed file and possibly its reconstruction.
  • the adapter 23 makes it possible to formalize the exchanges between the redirection module 10 (iCAP client) and the service module 25 (file transformation service) by adapting the iCAP streams to make them compatible with the compression service module. 25, as well as with other modules corresponding to file transformation services, without it being necessary to develop an iCAP layer at the level of these services. This then makes it possible to define file transformation services, modular, scalable and independent of the iCAP layers.
  • the present compression set is therefore capable of dynamically taking into account the particularities of customers and thus of adapting compression on the fly.
  • the browser 30 announces, in the header of this request, all the characteristics qualifying this browser.
  • the compression module 20 (iCAP server) will then test the existence of an "Accept-encoding" line in the http request. If this line does not exist, this means that the browser 30 does not accept any compressed page. The compression module 20 must then return the pages without modifying them.
  • the server 20 must look at the value of the types of compressed elements which are accepted by browsers to choose a good encoder or submodule of compression.
  • the service module 25 modifies the content of the header to be returned to the client 30, compresses the data, and returns it to the browser 30 via the redirection module 10.
  • the service module 25 specifically carrying out the compression of content, therefore operates here natively in “response modification” mode.
  • the procedure described here is carried out using a compression module 20 conforming to the architecture shown in FIG. 4, but comprising several service modules 25 integrated in the same server iCAP 20, these different service modules 25 each corresponding to a compression of a different type of object.
  • the objects passed are, more generally, objects corresponding to the various http headers relating to the client 10, to the server 20, and to the content supplied.
  • the compression module 20 searches in the request-client header for the string "Accept Encoding", making it possible to know whether the content can be compressed. If the value is not equal to "gzip” or “deflate” or if the chain does not exist, no compression is performed (go to point I below).
  • the compression module 20 searches in this same header for a string “User-Agent” making it possible to know the minimum version of browser used by the client. If the value extracted is not at least equal to 4 (major version number of browsers), no compression is performed (go to point I).
  • This operation fulfills a referral module function.
  • the stream is redirected to a compression sub-module 25 most suitable for the type of declared content.
  • a “Content-Type: text.html” indication in the data returned by the server indicates that the content is of type HTML - Hypertext Markup Language - (text).
  • the first bytes of the content are compared with the following bytes: it may be that a poor implementation of a Web server 40 introduces coding errors and it is then necessary to ensure that the content is indeed text. If the content is not of HTML type, it is not modified (passage to point I below).
  • the class diagram in Figure 6 shows the generalization and dependency links between server classes and specific service classes.
  • the complete class diagram of a preferred iCAP zipper is the logical fusion of this diagram with that of an iCAP flow adapter as described above.
  • the CicapServiceZip class is the child class of the ClcapService iCAP service class. It contains the functionality used for compressing objects.
  • the CicapGlobalsService class is the abstract child class of the class of definitions of constants and variables common to the service classes. It is not instantiable.
  • the CIcapErrorService class defines specific error constants for the service. It is not instantiable.
  • the compression mechanisms provided by the service described here may act differently depending on the content to be processed.
  • This service finds an immediate application for any Internet connectivity from mobile terminals (a PC - personal computer - or a PDA - pocket digital assistant - via a GPRS terminal - General Packet Radio Service - or CSD - Circuit Switched Data).
  • mobile terminals a PC - personal computer - or a PDA - pocket digital assistant - via a GPRS terminal - General Packet Radio Service - or CSD - Circuit Switched Data.
  • ISP Internet service provider
  • This service also finds its effectiveness in the connections of nomadic users with their corporate Intranet. Indeed, it is through connections of PSTN (Switched Telephone Network) that they recover data from the Intranet, and, as such, compression on the fly offers a gain in relative bandwidth and a reduction in download time for new information.
  • PSTN Switchched Telephone Network
  • the iCAP or iCAP Zipper compressor described here has the primary advantage of saving bandwidth and improving the quality of service offered.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L’invention concerne un procédé de compression à la volée de données fournies par un serveur (40) d’un réseau collectif tel qu’Internet en réponse à une requête d’un terminal de consultation (30), dans lequel procédé on fournit un module de compression de données (20), et un module de redirection (10) prévu pour recevoir des données fournies par le serveur (40) et les rediriger vers le module de compression (20), ce module de redirection (10) étant également prévu pour recevoir des données depuis le module de compression (20) et les rediriger vers le terminal de consultation (30), procédé selon lequel on examine dans la requête une indication concernant une aptitude à la décompression du terminal (30) et on effectue dans le module de compression (20), sur les données demandées par la requête et fournies par le serveur (40) une compression qui est adaptée aux indications d’aptitude contenues dans la requête.

Description

DISPOSITIF ET PROCEDE DE COMPRESSION DE DONNEES A LA VOLEE
L'invention concerne les outils de compression de données à la volée utilisés sur les réseaux, et en particulier sur Internet. Ces outils visent à optimiser le flux ou « bande passante » et augmenter ainsi la vitesse d'affichage des informations au niveau du client internaute.
Pour le client, ces outils permettent une réduction du temps de chargement des contenus, c'est à dire une meilleure perception de la qualité de service (QoS) et également une réduction des coûts lorsque la connexion est facturée au volume.
Il existe à ce jour plusieurs solutions d'accélération de flux sur le réseau internet, appelées Booster Web, qui répondent à cette problématique, mais aucune ne correspond à une réelle offre en cœur de réseau, applicable de manière simple à différents types d 'utilisateurs.
Les Booster avec client nécessitent l'installation d'un module particulier sur le poste du client. Ce module local on plug'in va en fait modifier la structure des messages échangés entre le client et le booster. A la communication selon le protocole habituel HTTP (Hypertext Transport Protocol) se substitue un protocole propriétaire.
Les Booster « TCP » modifient la structure des messages, d'autres se contentent de modifier la logique de reprise d'envoi TCP en l'adaptant au temps de réponse du réseau comme les téléphones mobiles par exemple.
Les Booster sans client ne modifient pas les messages http port 80, ils utilisent des entêtes classiques. Mais il est alors indispensable de les déclarer dans les propriétés des navigateurs comme on le ferait pour un cache classique. De plus, certains boosters possèdent aussi une fonction « cache » et d'autres annoncent être conformes au protocole ICP (protocole de communication entre caches). Ces solutions nécessitent donc d'intervenir sur les logiciels installés au niveau de l'ordinateur de l'internaute et sont donc loin d'être transparentes pour l'utilisateur. On se propose selon l'invention de résoudre cet inconvénient, c'est à dire de proposer un outil et un procédé de compression de données à la volée qui soit transparent pour l'internaute, c'est à dire qui ne nécessite pas d'intervention sur l'ordinateur ou le réseau local de celui-ci. Ce but est atteint selon l'invention grâce à un procédé de compression à la volée de données fournies par un serveur d'un réseau collectif tel qu'internet en réponse à une requête d'un terminal de consultation, dans lequel procédé on fournit un module de compression de données, et un module de redirection prévu pour recevoir des données fournies par le serveur et les rediriger vers le module de compression, ce module de redirection étant également prévu pour recevoir des données depuis le module de compression et les rediriger vers le terminal de consultation, procédé selon lequel on examine dans la requête une indication concernant une aptitude à la décompression du terminal et on effectue dans le module de compression, sur les données demandées par la requête et fournies par le serveur une compression qui est adaptée aux indications d'aptitude contenues dans la requête.
On propose également selon l'invention un dispositif de compression de données à la volée dans un réseau collectif tel que le réseau Internet, comprenant un module de compression et un module de redirection, ce module de redirection étant prévu pour recevoir des données fournies par un serveur en réponse à une requête de consultation émise par un terminal de consultation, et rediriger ces données vers le module de compression, ce module de redirection étant également prévu pour recevoir des données fournies en retour par le module de compression et les rediriger vers le terminal de consultation, ce dispositif incluant en outre des moyens pour examiner, dans une requête de consultation de données émise par un terminal, une indication concernant une aptitude à la décompression du terminal considéré, et des moyens pour commander une compression par le module de compression qui est adaptée à l'indication d'aptitude à la décompression contenue dans la requête. D'autres caractéristiques, buts et avantages de l'invention apparaîtront mieux à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur lesquelles :
- la figure 1 est un schéma simplifié d'un ensemble de compression de données selon l'invention ;
- la figure 2 est un autre schéma simplifié d'un ensemble selon l'invention ;
- la figure 3 représente de manière détaillée ce même ensemble selon l'invention ; - la figure 4 représente de manière détaillée un serveur iCAP conforme à une variante de l'invention ;
- la figure 5 est un organigramme représentatif d'un procédé selon une variante de l'invention ;
- la figure 6 est un organigramme de données et d'instructions selon une variante de l'invention.
Le dispositif décrit ci-après utilise un protocole d'échange de données destiné à permettre des modifications de contenus sur l'intemet, protocole appelé iCAP - Internet Content Adaptation Protocol -.
Le dispositif de la figure 1 est architecture autour de deux modules 10 et 20 de type iCAP, à savoir un cache 10 du type iCAP client et un serveur 20 de modification de contenu, du type serveur iCAP à
« modification de réponse » selon la terminologie énoncée par le protocole iCAP.
Lorsqu'un utilisateur demande, par l'intermédiaire d'un logiciel navigateur fonctionnant sur son ordinateur personnel 30, à accéder à une page Web, les étapes suivantes sont mis en oeuvre dans le dispositif de la figure 1.
D'abord une requête HTTP est envoyée vers le cache 10, également appelé « proxy cache 10 », configuré dans le navigateur de l'utilisateur 30 (mais ce pourrait tout aussi bien être un proxy cache fonctionnant en mode transparent dans le cadre d'un ISP - Internet Service Provider -).
Le cache 10 envoie alors une requête HTTP à un serveur Web d'origine 40, contenant cette page. Le serveur Web 40 renvoie la page demandée au cache 10.
Le cache 10 agissant maintenant comme client iCAP redirige cette réponse vers le serveur iCAP 20 précédemment mentionné, en lui faisant passer la page complète. Le serveur iCAP 20 traite alors cette demande en faisant appel à un service de modifications de contenus intégré au serveur, puis répond au cache 10 en renvoyant le résultat du traitement : la page modifiée (ou non comme on le verra par la suite).
Enfin, le cache 10 retourne à l'utilisateur final 30 la réponse du serveur iCAP 10 et stocke également cette réponse.
Le scénario que nous décrivons ici se déroule lorsque le cache 10 ne possède pas déjà le document demandé en mémoire, dans le cas contraire il répond immédiatement à l'utilisateur en renvoyant la page qu'il a précédemment stockée (c'est à dire soit la page originale, soit la page modifiée si la modification de celle-ci s'est avérée opportune).
Le cache 10 de type « client iCAP » est à ce jour disponible sur le marché dans une version industrielle.
Le principe du protocole iCAP repose sur une base simple : à toute requête HTTP correspond une réponse provenant d'un serveur Web ou d'un cache : il suffit donc de transformer soit la requête, soit la réponse pour offrir un service de transformation de contenu. iCAP propose deux modes principaux (« Request Modification » et « Response Modification ») qui sont basés sur le protocole HTTP.
Le rôle d'iCAP n'est pas d'effectuer lui-même la transformation de contenu. Il se limite juste à relier des « iCAP clients » (caches Web, routeurs....) avec des « iCAP serveurs », ces derniers étant responsables de la transformation.
Le iCAP forum (http://www.i-cap.org) a été créé en décembre 1999 sous l'impulsion des sociétés Network Appliance et Akamai. Son objectif est de standardiser, au travers du protocole iCAP (Internet Content Adaptation, Protocol), les échanges entre les équipements représentatifs des architectures du Web (serveurs Web, caches, load balancers, routeurs...) et les systèmes de transformation de contenu. La spécification ICAP 1.25 est la plus récente. Elle a déjà fait l'objet de plusieurs implémentations dans le cadre des services à valeur ajoutée de transformation de fichiers dont voici quelques exemples :
- filtrage de virus - filtrage de contenu
Le protocole iCAP a aussi été soumis le 27 novembre 2000 à l'IETF (Internet-Draft « iCAP the internet content adaptation protocol » http://www.ietf.orq/internet-drafts/draft-elson-opes-icap-00.txt) dans le Working Group (groupe de travail) Open Proxy Extensible Services. II n'existe pas beaucoup d'implémentations techniques de services utilisant le protocole iCAP. Seuls les éditeurs de logiciel d'Anti-virus bénéficiant de leur savoir-faire en solutions réseaux s'installant sur des FireWall (rideau de feu) ou des proxies (mandataire) proposent un portage de leurs services sur iCAP. On voit aussi l'apparition de nouveaux intervenants commerciaux dans le domaine du filtrage de contenu.
Mais pour toutes les autres applications éventuellement envisagées, l'investissement de départ reste lourd et coûteux. Ceci explique encore pourquoi les services à valeur ajoutée utilisant iCAP tardent à sortir. Utilisant ici le protocole ICAP et notamment le fait de récupérer des flux provenant des serveurs WEB via un module de redirection iCAP, ici constitué par le cache 10, on met en œuvre un procédé de compression à la volée particulièrement avantageux.
Le fonctionnement du présent outil de compression iCAP, ou « ICAP Zipper », peut se représenter simplement par le schéma générique de la figure 2.
Les étapes principales du service de compression sont les suivantes : a) le client 30 émet une requête à destination d'un serveur Web 40. Cette requête passe éventuellement par un équipement de redirection, ici le cache 10. b) le serveur 40 transmet sa réponse au client 30 par l'intermédiaire du cache 10. c) le service de redirection 10 (client iCAP) redirige la réponse vers le serveur iCAP 20. On dénommera ci-après ce serveur par l'expression plus générale « module de compression 20 » afin de qualifier la fonction principale de ce serveur. d) la réponse du serveur 40 est si possible compressée et/ou optimisée par le module de compression 20. e) le module de compression 20 renvoie la requête au module de redirection 10. f) le module de redirection 10 renvoie la réponse au client 30. g) le navigateur client 30 décompresse automatiquement le document reçu avant de l'afficher.
La décompression automatique des données du côté client est une fonctionnalité définie dans le protocole HTTP 1.1 (Standard IETF défini par la RFC 2616). Cette fonctionnalité se retrouve ainsi dans la majorité des navigateurs actuels qui intègrent un mécanisme de décompression de type gzip (Internet Explorer - marque déposée - de Microsoft, version 4 et supérieures, Netscape Communicator (marque déposée) de Netscape, version 4 et supérieures).
Ce système de compression (sans client spécifique ni module local - ou plug'in -) offre l'avantage de ne pas intervenir sur les logiciels installés au niveau de l'ordinateur 30 de l'internaute (ou au niveau du téléphone mobile ou de tout autre terminal de consultation utilisé).
Ce service de compression ne modifie pas non plus les couches réseaux et protocolaires, ce qui évite les incompatibilités éventuelles avec d'autres types de services ou d'équipements qui seraient situés entre le service de compression et l'utilisateur final.
Les figures 3 et 4 représentent de manière plus détaillée le dispositif préférentiel décrit ici. Sur ces figures, le module de compression 20 (ou module iCAP de transformation de contenu), se décompose en un module administrateur 22, un module adaptateur de flux 23, et un module de service ou sous-module 25 dédié spécifiquement aux tâches de compression des données. L'adaptateur de flux 23 a pour fonction d'adapter les contenus entre le module de redirection (client iCAP 10) et le module de service 25.
Un tel adaptateur de flux 23 est préférentiellement prévu pour adapter les flux de données également pour une série d'autres modules de services supplémentaires, mettant en œuvre des services autres que la compression, ces modules pouvant par exemple être des modules de filtrage de contenu ou des modules de filtrage anti-virus.
L'adaptateur 23 est situé dans le module de compression 20, pour d'une part, dans le sens client 10 - serveur 20, adapter les fichiers pour qu'ils puissent être directement utilisés pour les services de transformation de fichier, et d'autre part, dans le sens serveur 20 - client 10, assurer un contrôle d'intégrité du fichier transformé et éventuellement sa reconstitution.
L'adaptateur 23 permet de formaliser les échanges entre le module de redirection 10 (client iCAP) et le module de service 25 (service de transformation de fichier) grâce à une adaptation des flux iCAP pour les rendre compatibles avec le module de service de compression 25, ainsi qu'avec d'autres modules correspondant à des services de transformation de fichier, sans qu'il soit nécessaire de développer une couche iCAP au niveau de ces services. Ceci permet alors de définir des services de transformation de fichiers, modulaires, évolutifs et indépendants des couches iCAP.
Ainsi, on récupère les flux provenant des serveurs Web via un adaptateur de contenus iCAP et on les convertit ensuite au format Zip, qui est un format de décompression habituel. On voit clairement sur la figure 4 que le module de service 25 est structurellement intégré à la couche iCAP, ce qui signifie que le module de service 25, c'est à dire la partie spécifique au service de compression, est ici très simple à réaliser, notamment en adoptant l'architecture fonctionnelle d'un adaptateur de flux iCAP tel que précédemment décrit. Le service ou procédé général décrit ici va donc permettre de compresser les contenus http, par exemple les objets encodés au format htm, html, pour optimiser les taux de transfert et ce en cœur de réseau et de manière transparente pour le client. Pour mettre en œuvre ce service, on met en place une détection des capacités du navigateur 30 à décoder un contenu compressé.
La connaissance de ces propriétés différentie particulièrement le présent compresseur iCAP (ou l'iCAP Zipper) des autres systèmes de Booster, qui ne sont valables que pour un type de client donné ou une configuration réseau particulière.
Le présent ensemble de compression est de ce fait capable de prendre dynamiquement en compte les particularités des clients et ainsi d'adapter la compression à la volée. Lors de l'envoi d'une requête http vers un serveur Web 40, le navigateur 30 annonce, dans l'entête de cette requête, l'ensemble des caractéristiques qualifiant ce navigateur.
Le module de compression 20 (serveur iCAP) va alors tester l'existence d'une ligne « Accept-encoding » dans la requête http. Si cette ligne n'existe pas, cela signifie que le navigateur 30 n'accepte aucune page compressée. Le module de compression 20 doit alors renvoyer les pages sans les modifier.
Si cette ligne existe, le serveur 20 doit regarder la valeur des types d'éléments compressés qui sont acceptés par les navigateurs pour choisir un bon encodeur ou sous-module de compression.
Le module de service 25 modifie alors le contenu de l'entête à retourner au client 30, compresse les données, et les retourne au navigateur 30 via le module de redirection 10.
Le module de service 25 réalisant spécifiquement la compression de contenus, fonctionne donc ici nativement en mode « modification de réponse ».
La procédure de compression exécutée dans ce dispositif d'ensemble, mise en œuvre selon une méthode « Data Analysis » de la classe CicapServiceZip, est la suivante, ici détaillée selon une série d'étapes A) à I) également représentées sur le diagramme de la figure 6.
La procédure décrite ici est réalisée à l'aide d'un module de compression 20 conforme à l'architecture représentée sur la figure 4, mais comportant plusieurs modules de service 25 intégrés dans le même serveur iCAP 20, ces différents modules de service 25 correspondant chacun à une compression d'un type d'objet différent.
On fait abstraction ici des étapes relatives à la préparation des différents objets passés au module de compression 20. On précise simplement que l'entête de la requête de consultation initialement émise par le terminal 30 se voit transmise au module de compression 20, par le module de redirection 10, associée aux données fournies par le serveur 40 en réponse à une telle requête.
Les objets passés sont, plus généralement, des objets correspondant aux différentes entêtes http relatives au client 10, au serveur 20, et au contenu fourni.
A) Le module de compression 20 recherche dans l'entête de requête- client la chaîne « Accept Encoding », permettant de savoir si le contenu peut être compressé. Si la valeur n'est pas égale à « gzip » ou « deflate » ou si la chaîne n'existe pas, aucune compression n'est effectuée (passage au point I ci-après).
B) Le module de compression 20 recherche dans cette même entête une chaîne « User-Agent » permettant de connaître la version minimale de navigateur utilisé par le client. Si la valeur extraite n'est pas au moins égale à 4 (numéro de version majeure des navigateurs), aucune compression n'est effectuée (passage au point I).
C) Cette opération remplit une fonction de module d'aiguillage. En fonction de l'entête de réponse http (renseignée par le serveur Web d'origine) et plus précisément de la chaîne « Content-Type », on redirige le flux vers un sous-module de compression 25 le plus adapté pour le type de contenu déclaré. Par exemple, une indication « Content-Type :text.html » dans les données renvoyées par le serveur, permet de savoir que le contenu est de type HTML - Hypertext Markup Language - (texte).
D) Cette opération est réalisée au niveau du module de service 25 (sous-module de compression) : on recherche dans l'entête de réponse http la chaîne « Content-Encoding », permettant de savoir si le contenu est déjà compressé. La compression ne se fait pas si cette chaîne est présente et si une de ces deux valeurs (« gzip » ou « deflate ») est présente (dans ce cas passage au point I).
E) on compare les premiers octets du contenu avec les octets suivants : il se peut qu'une mauvaise implémentation d'un serveur Web 40 introduise des erreurs de codage et il faut alors s'assurer que le contenu est bien du texte. Si le contenu n'est pas de type HTML, il n'est pas modifié (passage au point I ci-après).
F) On appelle une fonction de compression « compress » qui retourne le contenu compressé dans un tampon (buffer) auquel il est nécessaire d'ajouter les octets suivants : 1 F 8B 08 00 00 00 00 00, qui définissent le début d'entêté d'une compression de type gzip.
Il est également nécessaire alors de modifier les deux premiers octets 00 03 à la. fin de l'entête de compression gzip.
G) On remplace le contenu dans un objet pIcapSocketDataResponseContent par le contenu de ce buffer.
H) On modifie et on ajoute, en fin de l'entête de réponse, la ligne « Content-Encoding : gzip ».
I) On envoi la réponse (modifiée ou non) au client iCAP 10.
Le diagramme de classes de la figure 6 montre les liens de généralisation et de dépendance entre les classes du serveur et les classes spécifiques du service.
Le diagramme de classe complet d'un compresseur iCAP (iCAP Zipper) préférentiel est la fusion logique de ce diagramme avec celui d'un adaptateur de flux iCAP tel que décrit précédemment. La classe CicapServiceZip est la classe fille de la classe de services iCAP ClcapService. Elle contient les fonctionnalités utilisées pour la compression des objets.
La classe CicapGlobalsService est la classe abstraite fille de la classe de définitions de constantes et de variables communes aux classes du service. Elle n'est pas instanciable.
La classe CIcapErrorService définit les constantes d'erreur spécifiques pour le service. Elle n'est pas instanciable. Les mécanismes de compression fournis par le service décrit ici peuvent agir différemment en fonction des contenus à traiter.
Ces mécanismes peuvent agir pour réduire le volume des données échangées (compression des données) avec ou sans pertes. Ils peuvent également optimiser les données échangées par réorganisation des données.
Pour favoriser l'essor d'iCAP et étendre la gamme de services de transformation de contenus en cœur de réseau, on propose donc ici un service de compression à la volée en cœur de réseau qui se traduit par une accelaration du téléchargement de pages Web et généralement de contenus sur http.
Ce service trouve une application immédiate pour toute connectivité à Internet depuis des terminaux mobiles (un PC - ordinateur personnel - ou un PDA - assistant digital de poche - via un terminal GPRS - General Packet Radio Service - ou CSD - Circuit Switched Data).
Il n'est cependant pas limité aux seuls opérateurs mobiles et peut être applicable à tout fournisseur d'accès Internet (FAI).
Il permet alors non seulement d'augmenter la qualité de service perçue par l'utilisateur final, mais aussi d'optimiser la bande passante du FAI sur la portion la plus critique : entre le point d'accès internet et l'utilisateur.
Ce service trouve également son efficacité dans les connections d'utilisateurs nomades avec leur Intranet d'entreprise. En effet, c'est au travers de connexions de type RTC (Réseau Téléphonique Commuté) qu'ils récupèrent des données d'Intranet, et, à ce titre, la compression à la volée offre un gain en bande passante relative et une réduction du temps de téléchargement des nouvelles informations non négligeables.
Enfin, du point de vue d'un fournisseur de service, le compresseur iCAP ou iCAP Zipper décrit ici présente l'intérêt primordial d'une économie en bande passante et d'une amélioration de la qualité de service offerte.

Claims

REVENDICATIONS
1. Procédé de compression à la volée de données fournies par un serveur (40) d'un réseau collectif tel qu'intemet en réponse à une requête d'un terminal de consultation (30), dans lequel procédé on fournit un module de compression de données (20), et un module de redirection (10) prévu pour recevoir des données fournies par le serveur (40) et les rediriger vers le module de compression (20), ce module de redirection (10) étant également prévu pour recevoir des données depuis le module de compression (20) et les rediriger vers le terminal de consultation (30), procédé selon lequel on examine dans la requête une indication concernant une aptitude à la décompression du terminal (30) et on effectue dans le module de compression (20), sur les données demandées par la requête et fournies par le serveur (40), une compression qui est adaptée à l'indication d'aptitude contenue dans la requête.
2. Procédé selon la revendication 1 , caractérisé en ce qu'on ne met en œuvre aucune compression dans le cas où l'indication de la requête révèle une inaptitude du terminal (30) à la décompression.
3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce que l'on recherche dans la requête une indication d'aptitude concernant l'un quelconque de plusieurs types de décompression, et on met en œuvre celui des types de compression qui correspond spécifiquement à l'indication d'aptitude contenue dans la requête.
4. Procédé selon la revendication 3, caractérisé en ce que le module de compression (20) comporte des moyens pour mettre en œuvre lesdits plusieurs types de compressions, et en ce que la recherche d'indications concernant les différents types de compressions est effectuée par le module de compression (20).
5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le module de compression (20) et le module de redirection (10) sont prévus pour échanger des données selon le protocole ICAP - Internet Content Adaptation Protocol.
6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le module de redirection (10) est un module de mémorisation de masse prévu pour fournir plusieurs fois des données mémorisées dans ce module (20) en réponse à plusieurs requêtes demandant ces mêmes données, sans avoir à interroger, entre ces requêtes, un serveur (40) ayant initialement fourni ces données.
7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le module de compression (20) inclut plusieurs sous- modules dédiés chacun à la compression d'un type d'objet différent, et en ce qu'on identifie dans les données à compresser la présence d'objets ayant l'un quelconque de ces différents types, puis on dirige chaque objet ainsi identifié vers un module spécifiquement dédié à la compression du type de l'objet considéré.
8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la requête de consultation est une requête du type
HTTP - HyperText Transport Protocol.
9. Dispositif de compression de données à la volée dans un réseau collectif tel que le réseau Internet, comprenant un module de compression (20) et un module de redirection (10), ce module de redirection (10) étant prévu pour recevoir des données fournies par un serveur (40) en réponse à une requête de consultation émise par un terminal de consultation (30), et rediriger ces données vers le module de compression (20), ce module de redirection (10) étant également prévu pour recevoir des données fournies en retour par le module de compression (20) et les rediriger vers le terminal de consultation (30), ce dispositif incluant en outre des moyens (20) pour examiner, dans une requête de consultation de données émise par un terminal (30), une indication concernant une aptitude à la décompression du terminal considéré (30), et des moyens (20) pour commander une compression par le module de compression (20) qui est adaptée à l'indication d'aptitude à la décompression contenue dans la requête.
10. Dispositif selon la revendication 9, caractérisé en ce que les moyens (20) prévus pour examiner une indication d'aptitude à la décompression dans la requête sont prévus pour ne commander aucune compression dans le cas où cette indication révèle une inaptitude du terminal (30) à la décompression.
11. Dispositif selon la revendication 9 ou la revendication 10, caractérisé en ce que les moyens (20) prévus pour examiner une indication d'aptitude à la décompression dans la requête sont prévus pour rechercher dans la requête des indications d'aptitude concernant plusieurs types de décompression, et commander celui des types de compression qui correspond spécifiquement à l'indication d'aptitude contenue dans la requête.
12. Dispositif selon la revendication 11 , caractérisé en ce que le module de compression (20) comporte des moyens pour mettre en œuvre lesdits plusieurs types de compressions, et en ce que la recherche d'indications concernant plusieurs types de compression est effectuée par le module de compression (20).
13. Dispositif selon l'une quelconque des revendications 9 à 12, caractérisé en ce que le module de compression (20) et le module de redirection (10) sont prévus pour échanger des données selon le protocole ICAP - Internet Content Adaptation Protocol.
14. Dispositif selon l'une quelconque des revendications 9 à 13, caractérisé en ce que le module de redirection (10) est un module de mémorisation de masse prévu pour fournir plusieurs fois des données mémorisées dans ce module (20) en réponse à plusieurs requêtes demandant ces mêmes données, sans avoir à interroger, entre ces requêtes, un serveur ayant initialement fourni ces données.
15. Dispositif selon l'une quelconque des revendications 9 à 14, caractérisé en ce que le module de compression (20) inclut plusieurs sous- modules dédiés chacun à la compression d'un type d'objet différent, et en ce qu'il comprend des moyens pour identifier dans les données à compresser la présence d'objets ayant l'un quelconque de ces différents types, puis pour diriger chaque objet ainsi identifié vers un module spécifiquement dédié à la compression du type d'objet considéré.
16. Dispositif selon l'une quelconque des revendications 9 à 15, caractérisé en ce qu'il est prévu pour traiter des requêtes du type HTTP - HyperText Transport Protocol.
EP03740571A 2002-04-05 2003-04-04 Dispositif et procede de compression de donnees a la volee Withdrawn EP1495619A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0204248A FR2838268A1 (fr) 2002-04-05 2002-04-05 Dispositif de compression de donnes a la volee de mise en oeuvre facilitee
FR0204248 2002-04-05
PCT/FR2003/001074 WO2003085927A1 (fr) 2002-04-05 2003-04-04 Dispositif et procede de compression de donnees a la volee

Publications (1)

Publication Number Publication Date
EP1495619A1 true EP1495619A1 (fr) 2005-01-12

Family

ID=28052133

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03740571A Withdrawn EP1495619A1 (fr) 2002-04-05 2003-04-04 Dispositif et procede de compression de donnees a la volee

Country Status (4)

Country Link
EP (1) EP1495619A1 (fr)
AU (1) AU2003260725A1 (fr)
FR (1) FR2838268A1 (fr)
WO (1) WO2003085927A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112804271B (zh) * 2021-04-15 2021-07-20 中国气象科学研究院 数据压缩方法、装置、终端及计算机可读存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185625B1 (en) * 1996-12-20 2001-02-06 Intel Corporation Scaling proxy server sending to the client a graphical user interface for establishing object encoding preferences after receiving the client's request for the object
AU2001279021A1 (en) * 2000-07-28 2002-02-13 Remote Communications Inc. System and method for serving compressed content over a computer network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03085927A1 *

Also Published As

Publication number Publication date
WO2003085927A1 (fr) 2003-10-16
FR2838268A1 (fr) 2003-10-10
AU2003260725A1 (en) 2003-10-20

Similar Documents

Publication Publication Date Title
CA2778215C (fr) Systeme et procedes permettant une diffusion multimedia efficace a l'aide d'une memoire cache
US7543018B2 (en) Caching signatures
EP1376410B1 (fr) Procédé de gestion d'informations de contexte par serveur intermédiaire
WO2007123470A2 (fr) Procédé et appareil pour passerelle de message électronique
Fox A framework for separating server scalability and availability from Internet application functionality
EP1381978B1 (fr) Dispositif et procede d'echange de flux entre un dispositif client et un serveur
CA2830750C (fr) Procede et dispositif d'extraction de donnees d'un flux de donnees circulant sur un reseau ip
EP1495619A1 (fr) Dispositif et procede de compression de donnees a la volee
FR2880966A1 (fr) Procede de navigation automatique en mode interposition
EP3818676A1 (fr) Identification de protocole d'un flux de données
EP1471714B1 (fr) Procédé et système de redirection sur détection d'erreur de résolution DNS
WO2008145901A1 (fr) Procede et dispositif d'interface entre les protocoles udp ou tcp et sctp
FR2858152A1 (fr) Gestion automatique de champ d'en-tete dans une reponse
EP1515522A1 (fr) Procédé d'insertion d'informations de filtrage thématique de pages HTML et système correspondant
WO2003036888A1 (fr) Procede d'envoi d'un contenu vers au moins un terminal et serveurs pour la mise en oeuvre du procede
FR2918527A1 (fr) Procede et dispositif d'insertion d'une adresse dans une requete
EP2171966B1 (fr) Gestion de sessions multi-flux entre un terminal et un serveur
FR2853177A1 (fr) Procede et systeme de controle d'acces a des sites internet
EP1212703B1 (fr) Procede et dispositif de telechargement de fichiers
FR2808640A1 (fr) Dispositif de supervision de terminaux
EP1843518B1 (fr) Procédé de protection d'adrresse de messagerie, système et dispostifs associes
EP3866432B1 (fr) Transmission de flux de données adaptable
Buchanan et al. WWW and HTTP
WO2004077199A2 (fr) Dispositif et procede de mise en communication de modules de mise en œuvre d’un bouquet de services et plate-forme de mise en œuvre d’un bouquet de services correspondante
WO2005015876A1 (fr) Dispositif de personnalisation du traitement de communications

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20041102

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20060411