ICAP: concept et mise en uvre du rseau intelligent du Web

Amar Nezzari
France Telecom R&D Direction des services Multimdias Internet et intranet
42, rue des Coutures 14066 Caen Cedex 4
amar.nezzariATfrancetelecom.com
date: 25 septembre 2003

Christophe Wolfhugel
France Telecom Transpac
40 rue Gabriel Cri, 92240 Malakoff
wolfAToleane.net

Rsum
Les fournisseurs de services Internet sont de plus en plus souvent confronts des contraintes lies la croissance du
nombre de postes connects et des services Internet de plus en plus volus. Pour y faire face les ISP ont souvent recours
des solutions logicielles proxy pour rendre leur service. Ces solutions sont bien souvent incompatibles en termes de
performances avec la multiplication des accs et conomiquement rdhibitoires en termes de retour sur investissements.
Pour rsoudre cette quation technico-conomique, le protocole iCAP (Internet Content Adaptation Protocol) semble tre
la solution bien adapte ce contexte. Ce protocole a t cre sur l'initiative de Network Appliance en collaboration avec
France Telecom R&D au sein de l'IETF. Il repose sur des changes simples entre un client et un serveur iCAP agissant sur
des requtes ou des rponses http. La mise en oeuvre d'iCAP ouvre le champ de nombreuses applications en cur de
rseau transparentes d'un point de vue de l'utilisateur et totalement scurises. Le transfert d'une partie de l'intelligence
applicative des postes client vers le cur de rseau ouvre la voie de nouvelles conceptions de services alliant scurit et
performances (filtrage, anti-virus, compression de donnes). Plusieurs types d'architectures iCAP et non iCAP pour des
services de filtrage d'URLs sont proposes et compares. Dans tous les cas de figures une solution iCAP permet de doubler
les performances par rapport des solutions classiques base de chanage de proxy. Cette solution a t mise en uvre de
faon oprationnelle par France Telecom dans le cadre du projet E-Lorraine, qui vise fournir des services de filtrage de
contenus et d'URL's pour des accs Internet tous les lyces de la rgion.

Mots clefs
Caches, iCAP, Internet, Filtrage, Proxy.

Introduction

Les fournisseurs de services Internet et gestionnaires de rseaux dentreprise sont de plus en plus confronts des
contraintes lies la croissance du nombre de postes connects et des services Internet de plus en plus volus.
Lutilisation de solutions logicielles base de proxy est bien souvent ncessaire la fourniture de ces nouveaux
services. Les solutions classiques sont bien souvent incompatibles avec les objectifs de performances et de cot imposs par
les clients et oprateurs. Pour rsoudre cette quation technico-conomique, le protocole ouvert iCAP semble tre la
solution adapte ce contexte car il offre une interoprabilit totale entre les services et la nature des rseaux (Internet et
Intranet) d'une part et permet des fonctionnalits d'adaptation et de transformation des contenus Web d'autre part.

2
2.1

Quest-ce quiCAP ?
Dfinition

Le protocole iCAP pour Internet Content Adaptation Protocol a initialement vu le jour suite aux travaux mens par Network
Appliance [1] co-fondateur en dcembre 1999 avec Akamai de l'iCAP forum [2]. Ces travaux visaient offrir une solution
alternative la plate-forme de services de proxy-cache et de transformation pour les mobiles propose par Inktomi.
L'objectif du forum est de standardiser les changes entre les quipementiers reprsentatifs des architectures du Web
(serveurs, caches, rpartiteurs de charges, routeurs, etc...) d'une part et les systmes de transformation de contenus (filtrage,

adaptation, insertion, etc) d'autre part. France Telecom R&D particip activement aux efforts de standardisation
l'IETF en tant que membre associ et partenaire technologique de Network Appliance. Aujourd'hui, le protocole iCAP est
dfini par la norme IETF (soumis en novembre 2000) et relatif la RFC 3507. Cette RFC n'est pas un standard Internet mais
une RFC "Informationnel" en attendant les recommandation du groupe OPES [3].

2.2

Principe

Le principe du protocole iCAP (Figure 1) repose sur une base simple puisque : toute requte http correspond une rponse
http provenant d'un serveur Web ou d'un cache. Pour offrir un service de transformation de contenus il suffit de modifier
soit la requte, soit la rponse. Le rle du protocole iCAP n'est pas d'effectuer lui-mme la transformation des contenus, il se
limite raliser le lien entre des clients iCAP et des serveurs iCAP . D'un point de vue fonctionnel, le protocole iCAP
est particulirement bien adapt http mme si d'autres protocoles tels que FTP, SMTP, SSL font aujourd'hui l'objet
d'implmentations sur des services lis au filtrage de mail ou la scurisation des transactions. Les clients iCAP se
situent essentiellement au niveau des caches qui peuvent tre de type logiciel ou matriel pour rendre sans dgradation de
qualit de service les fonctions spcifiques telles que le contrle anti-virus, filtrage, etc... et amliorer les performances.
Serveurs
WEB
Modification
de requte

Clients

Modification
de rponse

Cache

Figure 1 - Principe de base d'iCAP

En ce qui concerne le serveur iCAP il est quant lui situ au niveau du serveur d'application (Figure 2). D'un point de
vue implmentation l'appel d'un service iCAP se fait par l'intermdiaire d'un cache selon 4 modes (mode pr-cache et
post-cache en modification de requte ou de rponse) en raison de la configuration classique du cache entre le poste
client et le serveur de contenus de type proxy explicite ou transparent. Ces modes d'appels aux services sont tous dfinis au
niveau de la norme iCAP, ils sont utiliss par exemple dans le cas d'un service de filtrage d'URL en mode modification de
requte pr-cache ou un service de filtrage de contenus de type anti-virus en mode modification de rponse prcache (voir annexe exemples de transactions iCAP ). On voit donc que le protocole iCAP peut tre interprt au mme
niveau qu'une API de type rseau qui permet un quipement situ en cur de rseau de faire appel un serveur externe
agissant sur des flux entre client et serveur. De ce fait un serveur iCAP peut lui-mme tre connect des services iCAP
diffrents sans modifier l'architecture grce l'utilisation proxy-cache qui permet au protocole iCAP de grer l'appel aux
services.
Les principaux avantages apports par une architecture iCAP sont qu'elle permet de sparer les fonctions proxy et services,
de concevoir une architecture de services distribus en toile remplaant ainsi une architecture de chanage de proxies,
l'utilisation d'ACL (Accs Control List) qui conditionnent les appels aux services par des paramtres tels que les types
objets, @IP source, @IP destination etc. de cacher les traitements effectus par les services iCAP, enfin de distribuer par
le proxy-cache des traitements vers diffrents serveurs d'applications. Pour amliorer les performances au niveau des
traitements des services iCAP, l'utilisation des rgles des ACL permet en autre de grer les appels aux services iCAP en
fonction des paramtres http. Dans ces conditions le proxy-cache ne renverra au service iCAP que les objets ayant besoin
d'un traitement spcifique. Le proxy-cache permet aussi de rduire la charge sur les services par la fonction de cache des
rponses iCAP en plus du cache des rponses HTTP. Ces performances restent toutefois trs dpendantes de celles des
services iCAP donc de la puissance des serveurs applicatifs d'une part et des proxies-caches utiliss d'autre part. Il est
noter que tous ces services iCAP, compte tenu de leur architecture, offrent l'avantage d'une solution de services centraliss,
permettant ainsi de dporter une grande partie de l'intelligence applicative des postes clients en cur de rseau sans
configuration spcifique des paramtres de connexion des clients (proxy, browser, @IP, etc.) ni du rseau d'accs IP.

1: Modification requte client " pr cache"

3: Modification rponse serveur "pr cache"

2: Modification requte client "post-cache"

4: Modification rponse serveur "post-cache"

Clients

Cache

Serveur
WEB

Serveur ICAP

Service 1

Service 2

Service 3

Figure 2 Modes dappel aux services iCAP

Mise en uvre diCAP

La mise en uvre du protocole iCAP ouvre le champ de nombreuses applications en cur de rseau compltement
transparentes d'un point de vue de l'utilisateur final. Le transfert d'une partie de l'intelligence applicative des postes client
vers le cur de rseau ouvre la voie de nouvelles conceptions de services alliant scurit et performance la fois tout en
rduisant fortement les investissements en quipements. Malgr des dbuts difficiles surtout face des solutions base
d'API, la liste des applications et des produits compatibles avec le protocole iCAP ne cesse de crotre ce qui permet
maintenant d'envisager des dploiements oprationnels dans de nombreux cas de figure. Nous trouvons aujourd'hui des
clients iCAP sur un grand nombre de proxy-cache (Network Appliance, BlueCoat, Array Networks), implments sur des
machines spcialises, ainsi que des logiciels en OpenSource tel que Squid par exemple. Mme si la majorit des services
iCAP viss repose sur des applications lies la scurit des contenus (anti-virus), des services lis au filtrage de contenus
Web trouve notamment un large cho pour des applications pour le Grand Public et pour les Entreprises. A titre d'exemple
France Telecom dans le cadre du projet E-Lorraine a dploy un service iCAP de filtrage de contenus et d'anti-virus sur un
rseau IP de 200 sites gographiquement rpartis.

3.1

Architecture base de proxy-cache logiciel non-iCAP

De nombreuses applications client/serveur utilisent des architectures base de proxy-cache non-iCAP pour rendre des
services de filtrage ou anti-virus par exemple. Le principe de fonctionnement repose sur une architecture utilisant un proxycache qui dispose d'une API (Application Programmation Interface) permettant le dveloppement de briques logicielles
spcifiques pour rendre des services. Le plus connu et l'un des plus utilis est le proxy-cache Traffic-Server d'Inktomi, l'API
interne permet de dialoguer avec les services (Figure 3) externes. La solution reste propritaire, ce qui prsente un
inconvnient pour les volutions fonctionnelles des services d'une part, et tout ajout ou modification des services ncessite
une modification de l'automate d'tat de Traffic-Server d'autre part. Les logiciels de traitement de contenus anti-virus ou
filtrage sont disponibles auprs des diteurs, cependant ceux-ci n'ont jamais t utiliss simultanment sur le mme proxycache.

Anti-virus Filtrage

Cache
Client
Client

Serveur Web

Clients
API

Traffic Server

Figure 3 - Architecture proxy-cache logiciel non-iCAP

Il n'existe ce jour que trs peu d'informations faisant rfrence la stabilit, aux performances et la fiabilit dun systme
dans une telle configuration. Si l'on souhaite avec ce type d'architecture proposer plusieurs services fortement diffrencis le
chanage de proxy-cache s'impose, rendant le cot de la solution prohibitif pour obtenir des performances optimales.

3.2

Architecture base de proxy-cache matriel non-iCAP

Pour palier aux inconvnients en terme de performances lis au proxy-cache logiciel, certains constructeurs comme
BlueCoat, avant d'intgrer un client iCAP, ont propos des solutions base de proxy-cache matriels (Figure 4). Le principe
de fonctionnement reste le mme que pour une architecture base de proxy-cache logiciel, ceci prs qu'il ne dispose pas
vraiment d'une API (Application Programmation Interface). En effet, il intgre une grammaire et une syntaxe qui permettent
d'agir sur des requtes http provenant d'un client. Toutes ces rgles sont bases sur l'criture d'expressions rgulires, sur les
noms de host des serveurs Web, leur adresse IP ou encore sur les noms des utilisateurs et/ou les noms de groupes auxquels
ils appartiennent.

Cache
Client
Client

Serveur Web

Clients

Anti-virus

Filtrage

Autres

Figure 4 - Architecture proxy-cache matriel non-iCAP

La solution reste aussi propritaire, et restreinte principalement la manipulation et la rcriture d'URL, d'enrichissement
de contenus Web, rorganisation des paramtres passs en ligne de commande dans la requte http ou suppression de
certains headers . Ces types de proxy-caches matriels sont capables de grer une base de donnes embarque pour
effectuer du filtrage de contenus sur la base des produits WebSense et SmartFilter par exemple. Il est possible de crer un
ensemble de rgles pour dfinir des profils simples d'activation du filtrage. Cette association est effectue la connexion sur
le cache, lors de l'authentification de l'utilisateur. Cependant, la syntaxe ne permet pas d'agir sur le contenu des rponses
provenant des serveurs Web d'origine, mais seulement sur les headers retourns dans cette rponse. Pour implmenter
des services de type anti-virus, les constructeurs comme BlueCoat mettent en uvre un chanage de proxy. En effet, le
cache est chan un autre proxy (en gnral un serveur sur lequel tourne le module d'anti-virus) qui est lui-mme chan au

cache (une rgle de routage spcifique vitant alors que le systme boucle). Le cache passe donc la requte du client vers le
proxy anti-virus, qui la retourne au travers du cache pour rechercher le contenu sur Internet. Cette action n'est pas cache et
la rponse est directement envoye au module anti-virus.

3.3

Etude comparative d'une solution iCAP et non-iCAP

Aprs une description fonctionnelle des architectures base de proxy-cache, nous nous proposons dans ce paragraphe de
montrer l'intrt d'une architecture de services utilisant le protocole iCAP par rapport des solutions utilisant le chanage de
proxy. Pour notre tude de performance, nous avons choisi un service de filtrage d'URL qui permet d'interdire ou d'autoriser
l'accs des URL de sites Web en fonction de critres dfinis par l'administrateur sous la forme d'une liste thmatique
(sport, loisir, sexe, ). Le logiciel de filtrage retenu est celui de l'diteur allemand WebWasher, il permet l'analyse en temps
rel des URL demandes par l'utilisateur et la compare une base de donnes contenant plusieurs millions d'URL
rfrences dans une cinquantaine de thmes. En ce qui concerne les proxy-caches nous avons opt pour une solution
Network Appliance et ralis cette tude en laboratoire sur une plate-forme de tests spcifique. Nous avons envisag deux
scnarii de tests spcifiques, pour le premier correspond une charge du systme 500 requtes http/s, le second 1000
requtes http/s et ce pendant 8 heures.
3.3.1

Solution non-iCAP

La solution non-iCAP est base sur une architecture de ferme de caches Network Appliance (Figure 5) avec la fonction de
filtrage active et assure via une version allge du logiciel de filtrage de WebWasher dite in the box car intgre sur
les caches. Dans cette configuration, seule la fonction de filtrage DynaBLocator de WebWasher est prsente. Il s'agit d'une
base de plusieurs millions d'URLs catgorises suivant une cinquantaine de thmes. Chaque thme peut tre autoris ou
interdit via l'interface d'administration des caches NetApp.

Switchs

Client

Load Balancing

Ferme de caches avec logiciels

de filtrage Webwasher
intgrs

Back to Back

Client

Clients

Figure 5 - Architecture de tests non-iCAP

Les fonctionnalits du logiciel de filtrage in the box permettent outre le filtrage des URLs , une mise jour automatique
de la base des URLs, une re-direction des URLs filtres vers une URL de redirection permettant d'indiquer les raisons du
filtrage et enfin la possibilit d'utiliser les rsultats de catgorisation avec les ACL du cache. Sur cette solution, on peut
noter en particulier l'absence de gestion d'une liste d'URLs personnalises. Cette solution a pour inconvnient d'associer 1
logiciel de filtrage 1 cache, contrairement une solution iCAP qui permet d'associer n logiciels de filtrage 1 cache.
3.3.2

Solution iCAP

La solution iCAP quant elle est base aussi sur une ferme de caches Network Appliance (Figure 6), mais la diffrence de
la solution prcdente sur une ferme de serveurs hbergeant les logiciels de filtrage. Ici, les services de filtrage dialoguent
avec les caches selon le protocole iCAP dcrit prcdemment.

Ferme de services de
filtrage WebWasher

Switchs

Load Balancing

Ferme de caches

ICAP
Client

Back to Back

Client

Clients

Figure 6 - Architecture de tests avec iCAP

Dans cette configuration nous utilisons la version out of the box de WebWasher. Cette version intgre toutes les
fonctionnalits de WebWasher (Dynablocator, filtrage des publicits, filtrage sur liste personnalise d'URLs, filtrage sur
mots cls, etc.). L'utilisation du protocole iCAP permet d'une part d'tre indpendant des choix de partenaire effectu par
Network Appliance pour assurer le service de filtrage, et d'autre part d'ajouter de nouveaux services iCAP (modification de
requte ou l'adaptation de rponse http, dtection de virus, etc..).
3.3.3

Analyse des performances

Les tests de performances raliss sur les architectures dcrites aux paragraphes 3.3.1 et 3.3.2 ont pour objectif dvaluer et
comparer la capacit en charge d'une architecture compose d'une ferme de caches et d'une ferme de services iCAP. Pour
ces tests nous nous plaons dans les conditions suivantes :
-

les clients, les caches, les serveurs WebWasher et les serveurs de contenus sont sur le mme commutateur Ethernet
(100 Mb/s) ;
le cache est dans mis des conditions ralistes (taux de succs de l'ordre de 20%, taille de document suivant une
distribution raliste) mais avec des serveurs trs proches (temps de rponses faibles) qui disposent de 72 Go de
donnes ;
la ferme de serveurs WebWasher est mise dans les conditions les plus pessimistes c'est dire qu'il y a une requte
ICAP vers le serveur pour chaque requte cliente (pas de cache des rponses ICAP), la proximit des serveurs
WebWasher du point de vue des caches est raliste et ne peut tre interprte comme tant des conditions
avantageuses pour les tests. La proximit des serveurs de contenus en mode modification de requte n'avantage en
rien les serveurs WebWasher qui n'interagissent qu'avec les caches. Dans des conditions ralistes, ce seront les
mme temps de rponses ICAP qui seront mesurs ;
le filtrage par URL repose sur des algorithmes de recherche dans des arbres ou tables hashs. L'utilisation de noms
d'URL spcifiques aux tests peut simplifier le travail de ces algorithmes. Or la latence perue par le client est
surtout induite par la gestion des connexions. Ceci a pu tre vrifi en complexifiant le service WebWasher par des
tests sur des expressions rgulires et ce sans dtrioration de la QoS.

On constate que l'ajout d'un service ICAP une ferme de caches apporte une dgradation aux capacits en charge de la
ferme. La dgradation mesure est dans nos conditions la plus pessimiste. Enfin, l'algorithme de distribution de charge entre
les 2 serveurs WebWasher est du type Least Usage Based . Sur le tableau ci-dessous (Figure 7) nous avons reprsent les
rsultats des tests de performances par rapport au paramtre [nombre de requtes/s / dbit en Mb/s]. Nous avons compar les
rsultats thoriques issus des donnes constructeurs, les rsultats exprimentaux ainsi que des extrapolations partir des
rsultats prcdents. La valeur mise en vidence dans ce tableau est celle qui semble rpondre au premier scnario, c'est
dire supportant une charge de 500 requtes par secondes. Par manque de donnes concernant une architecture de caches
compose de 2 caches C2100, nous ne pouvons donner de valeurs. Cependant, nous supposons qu'une telle architecture avec
au moins 4 serveurs WebWasher serait thoriquement en mesure de tenir une charge de plus de 1000 requtes par secondes.
Cette supposition serait valider par des exprimentations supplmentaires. On constate que le comportement des serveurs
en cas de surcharge se dgrade (la charge supporte peut chuter temporairement quelques requtes par seconde ). Aussi, il
est important de sur dimensionner la ferme de serveurs de manire ce que les caches soient le seul goulot
d'tranglement en cas de surcharge de l'architecture mise en place. Les rsultats indiquent q'une solution base sur ICAP
dote d'une architecture compose de 2 fermes de services prsente des performances meilleures (plus du double) qu'une
solution de services intgrs sur le proxy cache. Si l'on double dans un mme temps le nombre de serveurs, on double dans

un mme le dbit et le nombre de requtes/s. Par consquent la solution iCAP est de loin la plus adapte de par ses
performances et ses capacits d'volution tant au niveau du dimensionnement qu'aux niveau services.

Ferme de Caches Network Appliance

Ferme WebWasher

Requtes s-1 / Mbit s-1

C1105

2*C1105

C2100

Pas de serveur

C/D tho: 360/33

C/D exp: 460/28

C/D extra: 920/56

C/D tho: 1000/90

Webwasher Intgr
NetApp

C/D exp: 110/7

C/D extra: 220/14

C/D extra: 280/18

C/D exp: 250/16

C/D extra: 250/16

C/D extra: 250/16

C/D exp: 310/19

C/D extra: 310/19

C/D extra: 310/19

WebWasher sur IBM

server P3 1Ghz 512Mo
(M1)
WebWasher sur IBM
server Bi-pro 1Ghz
(M2)
WebWasher sur
M1+M2

C/D exp: 450/26

WebWasher sur
2*(M1+M2)

C/D extra: 450/26

C/D extra: 500/29

C/D extra: 500/29
C/D extra: 900/52

C/D extra: 900/52

Figure 7 Tableau de synthse des performances

3.4

Application au projet E-Lorraine

Le Conseil Rgional de Lorraine a lanc le projet E-Lorraine [4] en 1999 afin de donner aux tablissements scolaires de
sa responsabilit accs des services utilisant les nouvelles technologies, dont lInternet. En 2002 le projet devient ELorraine Haut-Dbit afin de marquer lvolution des technologies de raccordement et des dbits associs. La plupart des
lyces publics, privs, EREA et agricoles ainsi que les CFA de Lorraine accdent lIntranet E-Lorraine par des liaisons de
raccordement haut dbit (xDSL, liaisons spcialises, ) et disposent pour leur activit de navigation sur lInternet dun
service centralis mettant en uvre la technologie iCAP afin de rendre deux services :
-

du filtrage dURL avec un logiciel du march ;

un contrle antivirus sur les objets visualiss.

La mise en uvre de ces technologies en contexte oprationnel permet deffectuer des observations fort intressantes sur les
usages et les performances. Une maquette de laboratoire, mme avec dexcellents outils de simulations donnerait des
rsultats moins pertinents.
La navigation se fait en chanant des postes utilisateurs, ou plus souvent des proxy-cache dtablissements la plateforme de navigation centralise (Figure 8) qui est compose de caches Network Appliance (les clients iCAP) et de serveurs
Intel Linux pour rendre le service de filtrage dURL et de contrle anti-virus.

2 serveurs mutualiss
pour le filtrage dURL

Switchs

Load Balancing

Ferme de caches

ICAP
Client

Back to Back

Client

Clients ou Proxy
dtablissement

4 serveurs ddis par cache

pour le contrle anti-virus

Figure 8 - Architecture des services iCAP du service E-Lorraine

Le trafic constat aux heures de pointe de cette installation est de lordre de 400 URL par seconde pour un dbit rseau
correspondant compris entre 30 et 40 Mbit/s.
3.4.1

Performances filtrage dURL vs. Contrle anti-virus

Comme prvu, le filtrage dURL est trs performant et peu consommateur de ressources. Les machines aujourdhui
dployes sur ce service permettraient sans aucun problme dabsorber de 3 4 fois plus de trafic puisque le traitement a
effectuer chaque requte est en effet fort simple :
-

peu de donnes sont transfres entre le client et le serveur iCAP (la requte de lutilisateur final plus la requte au
protocole iCAP) et en retour la rponse qui dans 90% des cas sera un ok pour afficher la page ;
la recherche dans les bases de classification dURL est trs rapide ( condition d'avoir fait le choix dune grande
quantit de mmoire sur les serveurs) ;
les requtes renvoyes aux caches sont elles-mmes caches, ainsi deux utilisateurs accdant aux mmes URL dans
un temps rapproch ne donnerons lieu qu une seule requte iCAP.

Le contrle anti-virus est au contraire bien plus exigeant puisquil faut transfrer au serveur iCAP lintgralit de lobjet afin
de pouvoir lanalyser, puis ventuellement le rparer et dans ce cas renvoyer le contenu modifi. La charge due au logiciel
anti-virus dpend de deux critres :
-

la taille de lobjet ;
dans le cas darchives (du zip ou du tar.gz ) le facteur le plus pnalisant est le nombre de fichiers analyser
une archive contenant des milliers de fichiers va prendre plusieurs minutes.

Pour la navigation courante les temps de traitement sont fort heureusement faibles et ne se voient pas la navigation. Le
tableau ci-dessous (Figure 9) donne quelques indications chiffres sur nos observations.
Echantillon : environ 16,1 millions
dobjets.
Tous objets confondus
100,0 %
Objet < 32 Ko
96,7 %
32 Ko <= Objet < 128 Ko
3,0 %
128 Ko <= Objet < 1 Mo
0,2 %
Objet >= 1 Mo
0,1 %

Dure moyenne du traitement en secondes

ICAP + Transfert
Filtrage dURL
Antivirus
1,10
0,002
1,04
0,002
1,49
0,001
8,17
0,001
83,08
0,001

Figure 9 - Temps de traitement des requtes HTTP et iCAP

0,05
0,04
0,15
0,80
4,52

3.4.2

Utilit des diverses fonctions cache

Le proxy-cache assure par dfinition en plus de sa fonction de mandataire une fonction de cache : un contenu dj charg
peut tre propos nouveau un utilisateur qui le demande ultrieurement. A ce cache dobjets sajoute un cache des
rponses iCAP aussi bien pour le contrle anti-virus que pour le filtrage dURL. Nous observons, toujours sur le mme
chantillon de 16 millions dobjets les diffrents taux de cache pour les requtes iCAP :
-

le nombre de requtes iCAP filtrage dURL dont la rponse tait dj dans le cache ;
le nombre de requtes iCAP anti-virus dont la rponse tait dj dans le cache.

La rpartition des valeurs obtenues selon la taille des objets nest pas surprenante :
Echantillon : environ 16,1
millions dobjets.
Tous objets confondus
Objet < 32 Ko
32 Ko <= Objet < 128 Ko
128 Ko <= Objet < 1 Mo
Objet >= 1 Mo

Pourcentage de transactions qui ont trouv une

rponse en cache
iCAP anti-virus
iCAP filtrage
30,5 %
89,2 %
31,2 %
89,4 %
11,2 %
82,1 %
15,2 %
76,4 %
14,1 %
73,4 %

Figure 10 - Taux de succs dans le cache

La baisse des taux de succs lorsque la taille de lobjet augmente sexplique par deux lments :
3.4.3

les objets de grande taille sont consults par moins dutilisateurs ;

lchantillon nest plus forcment significatif en taille (quelques milliers dobjets seulement dont la taille est
suprieure 1 Mo).
Partage de charge et dimensionnement

Les clients iCAP peuvent proposer plusieurs algorithmes de partage de charge pour leurs requtes. Ces lments sont
particulirement importants pour un service trs consommateur comme le contrle anti-virus. Nous avons essay deux des
solutions proposes par Network Appliance :
-

round-robin : le NetCache envoie les requtes iCAP en squence chacun des serveurs dclars ;
least usage : par une mthode qui est peu documente le NetCache dtermine quel serveur iCAP est le moins
charg et le plus apte rpondre dans les meilleurs dlais.

Les rsultats obtenus montrent que le round-robin fonctionne bien, mais ne tolre pas qu'un ou plusieurs serveurs iCAP
de la ferme ne rpondent plus ou seulement trs lentement (lors de l'utilisation de logiciels compliqus comme un moteur
anti-virus, il arrive tout simplement quun serveur iCAP ne rponde plus du tout !). Il est prfrable alors dutiliser
lalgorithme least usage , dont nous tudions actuellement les dtails d'implmentation sur le client iCAP. Lexprience
confirme galement quil faut trs largement prvoir les ressources adquates sur les serveurs iCAP afin dviter un
croulement du systme. Ainsi pour le contrle anti-virus, dans la plupart des situations un seul serveur suffit pour traiter
toute la vrification anti-virus dun NetCache (soit environ 90 objets par seconde). Il arrive cependant ponctuellement quil
soit ncessaire dutiliser la puissance de deux voire trois machines afin de ne pas crouler le systme et conserver de bons
temps de rponse, cest notamment le cas lors dun afflux de tlchargements de fichiers plus volumineux qu lhabitude.

3.4.4

Comparaison avec une solution non iCAP

Des expriences passes pour rendre des services similaires, mais sans lusage du protocole iCAP nous permettent de
constater le progrs et les bnfices de cette nouvelle technologies notamment par rapport une solution de chanage de
proxy :
-

pour des services iCAP en modification de requte, comme le filtrage dURL, la nouvelle architecture est sans
comparaison possible avec les anciennes : plus simple, beaucoup plus performante et plus conomique (pour les
quipements) ;
pour le service iCAP en modification de rponse quest le service anti-virus, l galement les progrs sont visibles :
la solution est plus performante, plus fiable et plus simple exploiter il serait cependant vain de croire que cela
permet de rduire de faon trs importante le nombre de machines anti-virus ncessaires, ce traitement est trs
coteux en temps de calcul et en entres-sorties, que ce soit avec ou sans iCAP.

Conclusions

L'mergence du protocole iCAP est aujourd'hui une ralit puisque tous les constructeurs de caches intgrent cette
technologie sur leurs quipements et que l'on trouve de plus en plus de services compatibles tels que le filtrage de contenus,
d'URL, antivirus, etc... La solution iCAP est de loin plus performante et plus volutive qu'une solution base de chanage de
proxy traditionnel, de plus elle allie la fois scurit et confort d'utilisation ce qui augmente le potentiel de son
dveloppement. Aujourd'hui fort de ces atouts, France Telecom exploite cette technologie de faon oprationnelle. Enfin,
son intgration en cur de rseau offre un brassage plus riche des flux d'information, permettant ainsi un fonctionnement
statistique et un apprentissage plus fiable des usages pour le dveloppement terme de nouveaux services forte valeur
ajoute.

Annexe : exemple de transaction iCAP

Mode Modification de requte http "GET" : lexemple ci-dessous illustre laction dun serveur iCAP qui va modifier lURL
qui lui est soumise lURL accde est http://www.origin-server.com/ et lURL qui est retourne au cache est
http://www.origin-server.com/modified-path.
Requte iCAP
REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0
Host: icap-server.net
Encapsulated: req-hdr=0, null-body=170
GET / HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain
Accept-Encoding: compress
Cookie: ff39fk3jur@4ii0e02i
If-None-Match: "xyzzy", "r2d2xxxx"
Rponse iCAP
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: req-hdr=0, null-body=231
GET /modified-path HTTP/1.1
Host: www.origin-server.com
Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1)
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress
If-None-Match: "xyzzy", "r2d2xxxx"

Rfrences
[1]
[2]
[3]
[4]

Network Appliance, Akamai. ICAP Internet Content Adaptation Protocol. IETF Internet Draft, Mars 2000.
Site Web officiel iCAP, http://www.i-cap.org.
Evaluating the ICAP protocol regarding the OPES callout protocol requirements. IETF Internet Draft, Juin 2002.
Site Web du projet E-Lorraine Haut-Dbit : http://www.e-lorraine.net/.