Cache Web: un état de l'art des techniques et prototypes

HAL Id: hal-01293217

https://hal.archives-ouvertes.fr/hal-01293217

Submitted on 24 Mar 2016

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

Cache Web: un état de l’art des techniques et prototypes

Jean-Christophe Mignot

To cite this version:

Jean-Christophe Mignot. Cache Web: un état de l’art des techniques et prototypes. [Rapport de

recherche] CNRS; Ecole Normale Supérieure de Lyon; INRIA; UCBL. 1999. �hal-01293217�

Laboratoire de l’Informatique du

Parallélisme

École Normale Supérieure de Lyon

Unité Mixte de Recherche CNRS-INRIA-ENS LYON

n

o

5668

SPI

Ca he Web: un état de l'art

des te hniques et prototypes

Jean-Christophe Mignot

Novembre1999

Resear hReport N o

RR1999-52

École Normale Supérieure de

Lyon

46 Allée d’Italie, 69364 Lyon Cedex 07, France

Téléphone : +33(0)4.72.72.80.37

Télécopieur : +33(0)4.72.72.80.80

Adresse électronique :

des te hniques et prototypes

Jean-Christophe Mignot

Novembre 1999

Abstra t

Thispaperpresentsasurveyofthestate-of-the-artte hniquesandprototypes

forWeb a hes. Thebasi prin iplesare presented,themostimportant

hard-waresandsoftwaresapproa hesaredes ribed.

Thiswork was partiallysupported bytheFren h MinistryofIndustry within

theCHARMProje t, ontra tn o

99.2.93.0116

Keywords: Web a hes,distributedsystems

Résumé

Cedo umentprésenteunétatdel'artdesprototypesette hniquesdes a hes

WEBa tuelles.Lesprin ipauxmatériels etlogi ielsdisponiblessurlemar hé

sontprésentés.Lesprin ipalesappro hesdédiéesauxma hinesparallèlessont

dé rites.

Ce travail a été partiellement nan é par le ministère de l'Industrie dans le

adredu ontratCHARM, onventionn o

99.2.93.0116

L'explosionde l'utilisationde l'Internet rée desérieux hallengespourles

prestatairesdeservi esInternetetlesopérateursréseaux.Auneheuredepointe,

l'a èsàundo umentoulasoumissiond'unerequêteàunmoteurdere her he

peutprendreuntemps onsidérablequi onstitueunfreinàl'utilisation

intera -tivede l'Internet, unphénomènesouventdésignésouslenom de"WorldWide

Wait".

Ce problème est prin ipalement lié à un a roissement quasi exponentiel

de la demande en bande passante suite àla multipli ation des utilisateurset

à labanalisation des informations multimédia.Malheureusement, même si les

solutionsbaséessurdessatellitespermettentdesgainsimportantssurles

solu-tionsterrestres,augmenterlabandepassantedesréseauxlonguedistan en'est

possiblequ'au prixd'investissements onsidérables.Dansun futurpro he,des

solutionsdetypeADSL(Asymmetri DigitalSus riberLine)etMMDS

(Mi ro-waveMultiwaveDistributionSystem)permettrontdesdébitsélevésenutilisant

respe tivementdesbou leslo alestéléphoniquesouhertziennes.

Lesutilisateurs nepourront béné ier des performan esa rues de es

ré-seauxquesilesinformationsa édéessonthébergéessurunserveurdire tement

onne téàlabou lelo alehautdébit.Ce iimpliquequedesfon tionsde a he

Internetdoiventêtreimplantéesdanslatêtederéseauparunserveur

susam-mentpuissantpourqu'ilne onstituepasàsontourungouletd'étranglement.

Ce besoinen puissan e est tout parti ulièrement sensibleave l'avènement de

do uments in luantdes ux audioet vidéoet lamultipli ationdes requêtesà

"valeur ajoutée" né essitant l'évaluation de s ripts et de méthodes

d'indexa-tion.Un serveurde a hedeforte apa ité,extensible,etàhautedisponibilité

apportera auxabonnés d'une bou le haut débit un onfort d'utilisation a ru

en réduisant les temps d'attente et en leur orant la possibilité d'utiliser des

appli ations in luant des éléments multimédia ri hes (audio, vidéo, et .). Ces

avantagespourlesutilisateurs onstituent unevaleurajoutée trèsintéressante

pourlesopérateurset lesprestataires deservi eInternet.Pourlesexploitants

des bou les lo ales haut débit, il faut souligner les é onomies de bande

pas-santesur lesliaisonsave ladorsaleInternetinduites parle a heWEBet les

fon tionnalitésd'indexation.

Dèsle début des années 90, lespremières étudesétaientmenéessur la

a-ra térisation du tra en réseau que e soit en LAN ou sur l'Internet et sur

l'impa t des a hes.Lesbuts étaientdéjà euxqui nouspréo upent

a tuelle-ment:détournerla hargedesserveurssur hargés(désignésdanslalittérature

anglophone par"hot spots"), réduirel'utilisation de la bande passante du

ré-seau,diminuerlestempsdelaten edevenantrédhibitoirespourlesutilisateurs

et aussiprotéger le réseau des lientsqui bou lentpar erreur et génèrent des

requêtesrépétitives([12, 1℄).

Denombreusesétudesontété onsa réesàl'analysedesspé i itésdutra

Web(voir[5,6,16℄).Danzig,S hwarzetHall([17℄)montrentquel'utilisationde

a heshiérar hiquespourraitpermettrederéduiredemoitiélabandepassante

utiliséeparlestransfertsftplonguedistan e,diminuantainside21%la harge

duNSFNET.BraunetClay([8℄)présententdesrésultatssimilaires on ernant

le tra WEB. Alonzo et Blaze ([4℄) et Munz et Honeyman ([28℄) montrent

que on ernantlesréseauxlo aux,letypede a heutiliséestimportant( a he

Danslasuitede etteintrodu tion,nousdé rivonsendétails lesnotionsde

serveur proxy et de a he. La se tion 2 dé rit les prin ipaux outils de a he

utilisant l'appro he "boite noire". La se tion 3 dé rit les prin ipaux logi iels

disponibles sur le mar hé et leurs parti ularités. La se tion 4 est dédiée aux

logi ielsde a heparallèles.Lase tion5abordelesproblèmesposésparl'étude

desperforman esdesoutilsde a heWEB.

1.1 Les proxies

Lepremierrled'unproxy(mandataireenfrançais)estdepermettrel'a ès

à l'Internet depuis un réseau derrière une ma hine oupe-feu (voir Figure 1).

Typiquement, dans un réseau sé urisé, toutes les ma hines sont reliées entre

ellesmaisuneseuleest onne téeàl'Internetet les ommuni ationsave ette

ma hine sont restreintes et ontrlées. Le but est de protéger l'intérieur du

réseaud'éventuellesattaquesvenuesdel'extérieur(voir[25℄).

de news

Serveur

Clients à

l’intérieur du

réseau sécurisé

Serveur

HTTP

Serveur

Gopher

distant

Serveur

distant

ftp

distant

Serveur

distant

WAIS

LAN sécurisé par le coupe-feu

HTTP

Serveur proxy

coupe-feu

sur la machine

HTTP

Gopher

WAIS

NTTP

FTP

Fig. 1: Proxy et réseau sé urisé : le serveur proxy est exé uté soit sur une

ma hine oupe-feu ( asprésenté surlagure),soit surune ma hine duréseau

ayant un a ès à Internet, soit sur n'importe quelle ma hine du réseau ayant

la possibilité d'a éder au monde extérieur par l'intermédiaire d'une ou he

logi ielleadho ommeSOCK

Un proxyest unserveurHTTPspé ialqui esttypiquement exé utésur une

ma hine oupe-feu.Leproxyattendunerequêteissuesduréseausé urisé,

trans-metlarequêteauserveurdistantàl'extérieurduréseaulo al,litlaréponseet

la renvoie à l'initiateur de larequête. Il rend don le oupe-feu perméable de

manièresûre,sans réerdetroudesé uritéquipermettraitàd'éventuelspirates

d'a éderàl'intérieurduréseaulo al.

Pourles lientsWeb, lesmodi ationsàapporterpourleurfairesupporter

les proxiessontminimes. Iln'est pasné essaire de re ompilerune versiondes

lientsave une librairiede oupe-feu :un lient standardpeutêtre onguré

adaptéesà haquetypede mur oupe-feu. C'est d'autantplusintéressantque

laplupartdes lientsdu ommer enesontpasfournisave le odesour e.

Iln'estpasné essairepourlesutilisateursdedisposerde lientsftp,Gopher

et WAIS spé ialement modiés pour passer à travers un mur oupe-feu. Un

simple lientWebetunserveurproxysusent.L'utilisationd'unproxypermet

aussi de standardiser la forme des requêtes ftp et Gopher entre lients par

rapportàunesituation où haque lientauraitsonpropregestionnairedeftp

ouGopher.

Un proxy permet au programmeurde lientsWeb de ne pas avoiràgérer

touslesproto olesduréseaupourse onsa reràdesspé i ationsdu lientplus

importantes.Ilestpossibleden'utiliserquedes lient"légers"nere onnaissant

queleproto oleHTTP,lesautresproto olesétantgérésdemanièretransparentes

parleproxy.L'utilisationduproto oleHTTPentre lientetproxynefaitperdre

au unefon tionnalitéàl'utilisateurpuisqueftp,Gopheretlesautresproto oles

duWebsontparfaitementreprésentésdanslesméthodesHTTP.

Les lient n'ayant pas de DNS peuvent quand même avoir a ès au Web,

l'adresse IP duproxyest laseuleinformation dontils ont besoin. Lesréseaux

utilisant un espa e d'adresses privé ( omme les réseaux de lasse A omme

10.*.*.*) peuvent quand même a éder à l'Internet pour autant que le proxy

soitvisible auxdeuxréseaux,parexemplepardeuxinterfa esdistin tes.

L'utilisationdesproxiespermetunenregistrementdehautniveaudes

tran-sa tionsdes lientsin luantl'adresseIP du lient,ladate, letemps, l'URL,le

nombre d'o tets et les odes retournés.Tousles hamps et méta-informations

destransa tions HTTPpeuventêtreenregistrés.Ce i n'estpaspossibleave les

enregistrements des niveaux IP et TCP. Il est en outre possible de ltrer les

transa tionsdes lientsauniveauduproto oledel'appli ation.Leproxypeut

ontrlerl'a èsauxservi esdesdiérentes méthodes,leshtes, lesdomaines,

et .

D'unemanièregénérale,lesdéveloppeursn'ontau uneraisondedévelopper

une version oupe-feu deleur lientWeb. Ave l'utilisationdes proxies,ils ont

unein itation:lespossibilitésde a he.Enn,unproxyestplussimpleà

on-gurer qu'une ou he logi ielle de ommuni ation omme SOCK et fon tionne

quellequesoitlaplate-forme.

1.2 Les a hes

L'idée de base des a hes est simple : enregistrer les do uments olle tés

sur le réseau dans un  hier lo al de manière àne pas avoiràse re onne ter

auxserveurslorsderequêtesultérieuresauxmêmesdo uments.Ceprin ipeest

illustréparlesguresFig.2etFig.3.

LaFigure2illustrelamanièredontledo umentdemandé estré upéré sur

le serveur distant (some_host.far.away)puis enregistré lo alement sur le

ser-veurproxy(www_proxy.my.domain)pouruneutilisationultérieure.LaFigure3

illustreunsu èsde a hesurleproxy:undo umentdemandéétaitdéjà

enre-gistré dansle a he, 'estlaversionenregistréequi est fournie audemandeur,

il n'estpasné essairedesere onne terauserveurdistant.

Dansla plupart des as, le mêmeproxyest utilisé partoutes lesma hines

d'un réseau lo al. Cette situation d'intermédiaire obligatoire pour toutes les

Serveur

proxy

Serveur

distant

GET full-URL HTTP/1.0

Client

HTTP/1.0 200 Document follows

HTTP

Tout protocole supporté

www_proxy.my.domain

some_host.far.away

Réponse

Requête

Cache

Fig.2:leprin ipedes a hes:premièrerequête

demandésparles lients.Notonsque ettepossibilitéestintéressantemêmepour

lesma hinesquinené essitentpasd'êtrederrièreun oupe-feuandediminuer

lestempsd'a èsetderéduirel'utilisationdelabandepassante disponible.Le

a hepermetd'avoira èsàdesressour es ommelessitesftpouGophermême

quand eux- i sont en panne. Les a hes peuvent aussi servir pour ee tuer

des démonstrations en des lieux oùInternet n'arrive pas,ou en ore, pour lire

tranquillement,et"oline",desdo umentspréalablement hargésdansle a he.

Notons que es as peuventdemander une ongurationparti ulière du a he

spé iantdenepasvérierlafraî heurdesdo umentsdélivrés(version1.1 de

HTTP).

Serveur

proxy

Serveur

distant

GET full-URL HTTP/1.0

Client

HTTP/1.0 200 Document follows

HTTP

www_proxy.my.domain

some_host.far.away

Cache

Fig.3:leprin ipedes a hes:requêtessuivantes

Les a hes sont plus e a es sur un proxy que hez haque lient.

L'uti-lisationdes disques en est diminuéepuisqu'une seule opie des do umentsest

a hée.Le a hage desdo umentssouventréféren ésparplusieursutilisateurs

est plus e a e ar le gestionnaire de a he peut mieux prédire quels

do u-mentsdoiventêtregardéslongtempsdansle a heet quelsdo umentsdoivent

êtrerapidementenlevés.

Ilestpossiblede olle terautomatiquement ertainespagesdepuisleurs

ser-veursd'origine.Onutilisesouventletermedepré- hargement(pre-fet hingen

anglais)pourdésigner etteméthode.Lamiseen÷uvredupré- hargementest

detemps est-ilpossibledegarderundo umentdans le a hetout enassurant

qu'ilsoitàjour?Lagestiondel'expirationdesdo umentsaétépressentiedans

leproto oleHTTPqui ontientunentêted'objetspé iantladated'expiration.

Cependant très peu de serveursfournissenta tuellement ette information et

tantque etétatdefaitpersisterailfaudrautiliserdesheuristiques ommepar

exemple utiliser unestimateur grossierdu temps àvivre ("time to live",

sou-venttrouvédans lalittératuresousla formeTTL)desobjets.Demanièreplus

importante, les do uments olle tés sur le WEB sont souvent des do uments

"vivants"etleurae terunedated'expirationn'estpastoujoursfa ile.Un

do- ument peut resterin hangé pendant très longtemps puisdevenir subitement

modié très fréquemment. Ce hangementpeutne pasavoirété pressentipar

l'auteurdespages.Ilneseradon pasreétédemanièrepré isedanslesdates

d'expirations envoyées ave les versions pré édentes du do ument. Si la date

d'expiration envoyée ave la versioninitiale était, par exemple, d'un mois, et

si après un ertain temps, elle passe à un jour, tous les a hes ayant reçu la

premièreversionvontêtrein orre tementinformés.

Quandil est essentielque laversiondudo ument soit àjour, il est

né es-saire de se onne ter au serveur d'origine pour haque requête de type GET.

Le proto oleHTTPimplémente uneméthode nomméeHEADqui permetde ne

ré upérer quel'entêted'undo ument.Elle permetde vériersiledo umenta

été modié depuis le dernier a ès.Cependant, dans le as où le do ument a

été modié, ee tuer une se onde onnexion au serveurserait ine a e ar le

sur oût pourl'établissementd'une onnexion esttrèslourd. Leproto oleHTTP

adon été enri hi parunentêtede requêteIf-modied-sin e qui rend possible

de faire unGET onditionnel.La requête est la même ex epté qu'ilfaut y

ad-joindre ladate du do ument a hé.Si le do umentn'a pasété modié depuis

lesdateetheurefournies,iln'estpasretournéau lient,seulssontrenvoyéesles

méta-informations importantes de l'entête de l'objet, ommela nouvelledate

d'expiration. Si le do ument a été modié, la nouvelle version est retournée,

omme pour un GET normal.Le GET onditionnel permet d'optimiser ertains

outils ommelesoutilsdemirroring.Le mirroring(de l'anglaismirror,miroir)

est uneméthodequi onsisteàdupliquersystématiquementunensemblede

- hiers prédéterminédepuis un site d'origine. On parle de sites miroirs, ou de

miroirs,pourdésignerles opies. Cetteméthodeestlaméthodelaplusutilisée

pourdupliquer delourdes ar hives omme ertainssites ftp. Lesmiroirs sont

entièrement réa tualisés régulièrement o asionnant de longues opérations de

transfert. Rien ne garantitqu'un miroir soit àjour, la réa tualisation étantà

la hargedes administrateursdumiroir. Un serveurproxy- a hepourrait

fa i-lementêtre utilisé pour automatiserlerafraî hissementd'unmiroir,

régulière-ment,pendantlespériodesd'ina tivitédes lients,enplusdesrafraî hissements

o asionnésparlesréa tualisationsexpli ites.

Laplupartdesserveursa tuelsimplémententlesGET onditionnels.Deplus,

leproto oleHTTPestdénide tellemanièrequesi un hampdel'entêted'une

requêten'estpasre onnu,il esttoutsimplementignoré.Don ,siunutilisateur

demande,ave unGET onditionnel,undo umentàunserveurn'implémentant

pas ettefon tionnalité,le hampdel'entête orrespondantesttoutsimplement

ignoréetledo umententierestretourné.

Le mé anisme de a he est basé sur les disques. Il est don par essen e

et le a hesontsurlamêmema hine,àl'utilisation"oline"duWEB.

1.3 Avantages et in onvénients des a hes

Lesavantagesgénéralementre onnusdel'utilisationdesproxies- a hessont:

 lestempsderéponse endurésparlesutilisateurssontdiminués,

 labandepassante onsomméeparlesutilisateursestdiminuée,

 lesserveurssur hargéssontsoulagés,

 les lientsbuggésnepeuventpasperturberl'ensembleduréseau.

Dans la pratique, les hoses peuvent être un peu diérentes. Des études

ré entes(voir[35℄)ontmontréquel'utilisationd'un a heneréduitpastoujours

lestemps deréponsedu téutilisateur.En eet,si leserveurde proxy- a he

estsaturé,sestempsderéponsepeuventêtretrèslongs,enparti ulierpluslongs

queletempsné essairepoura éderaudo umentdire tementdepuisleserveur

d'origine.Sideplus,ledo umentn'estpasdansle a he,etqu'ilfautnalement

leré upérersurleserveurd'origine,l'intérêtdu a hepeutsemblermoindre.De

plus,ladéterminationdelataille optimaledu a hepeutêtredi ileetinuer

surlesperforman esdemanièrenonnégligeable.

La ohéren e des informations fournies par un a he peut être

probléma-tique : siles objets a hésrestentlongtemps dansle a he, le lientrisque de

sevoirservirune vieilleversion,si lesobjets a hésrestentpeu detempsdans

le a he, il y a peu de han es qu'ilsservent àun autre lient. Si ladernière

versiondu proto ole HTTPpermet de résoudre en partie le problème, les

ver-sionsantérieuresnefournissaientau unmoyendespé ierladuréedevalidité

desobjets.A tuellement,laplupartdesserveursnefournissentpasdeduréede

validitépré iseauxpagesqu'ilsserventet il fautdon utiliserdesheuristiques

pourdéterminerladuréedeséjourdansle a he.La ohéren edesinformations

fournies parles a hes est don de typefaible. Despropositions ontété faites

qui permettraientdegarantirauWebune ohéren eforte([10℄).

1.4 Les diérents dispositifs

Denombreuxoutilsde a hesontdisponibles.Deuxappro hessontutilisées:

 Appro hepropriétaire: lama hine de a hea hetée est inter alée entre

leréseaulo al et l'a èsàInternet. C'estelle quigère lesdo uments

re-çus de manière transparente pour les utilisateurs et administrateurs. Il

yapeu/pas depossibilitédevisualisation desperforman eset

d'optimi-sation. La modularité est faible. La littérature se limite le plus souvent

auxdo umentsdu onstru teuretpeud'informationssontfourniessurle

fon tionnementinternedelama hine.

 Appro he logi ielle : le a he est réalisé par un des nombreux logi iels

de a he disponibles sur le mar hé. Les hoix matériels et les réglages

du logi iel sont à la harge de l'administrateur et peuvent être modié

àtout moment. Si unlogi iel libre est utilisé, il peut être modié à

vo-lonté pour améliorer les performan es, visualiser ertainesdonnées, et .

Denombreusesétudessontpubliées on ernantlefon tionnementdes

dif-férents logi ielsde a he disponibles, leurs performan es et lesmanières

L'appro he propriétaire est basée sur la fourniture d'une ma hine lef en

mains pourle a he. Onqualie souvent e typede ma hine de"boite noire".

D'unemanièregénérale,onappelle"boitenoire"undispositifdontle

fon tion-nementinterne estmasquéàl'utilisateur.L'idée est similaireà elledu

"plug-and-play" : soulagerl'utilisateur de onnaissan es et de manipulations dontil

n'auraitpasbesoin.Appliquéaudomainedes a hesWEB, eladonneun

dis-positifquel'onbran hesurleréseauetquel'onmanipuleàl'aided'unlogi iel

fourni. Une fois le dispositif bran hé et onguré, tout devrait mar her

auto-matiquementetl'utilisateurnedevraitplusavoiràsepréo uperdudispositif

installé.

Citons parmilesprin ipaux outilsdisponibles a tuellementles"Ca he

En-gine"delaso iétéCISCO(www. is o. om/warp/publi /751/ a he),les

ma- hines "Ca heFlow" de la so iété Ca he Flow In . (http://www. a heflow.

om)ou en orelesma hines DynaCa hede laso iétéInfolibria (http://www.

infolibria. om/produ ts/f-prod.htm).

Le prin ipal avantage de ette appro he réside ertainement dans l'aspe t

" lef en main" de l'outil. Si leslogi iels omme Squid peuventdemander une

ertaine expertise informatique pourêtre mis en ÷uvre, lesma hines dédiées

se présentent sous forme d'un équipement à installeret du logi iel de gestion

asso ié.

Lesprin ipauxin onvénientsde etyped'outilsrésidentdansleursmanques

deexibilitéetdevisibilité.Sileslogi ielsde a hepeuventêtrefa ilement

mo-diéspour orrigerdesimperfe tionsous'adapterauxévolutionsd'un ontexte

parti ulier,lesma hinesde type"boitenoire"sontlaplupart dutemps gées.

Ellesnepourrontdon pasêtreadaptéesauxéventuelsnouveauxproto olesde

ommuni ation,auxenri hissementsdesstandards,et .Deplus,laplupartdu

temps,en asd'augmentationdunombrede lientsàservir,laseulepossibilité

oerte par le onstru teur est d'a heter le modèle supérieur dans la gamme.

Dans le ontexteduWEB, oùles te hniques évoluentàunrythmesoutenuet

où le nombre d'utilisateurs roit onstamment, e manque de exibilité peut

semblerrédhibitoire.

Lesseulesintera tionsave lematérielsont ellesrendues possiblesparles

logi ielsfournis.Orleslogi ielsfournisn'implémententpastoujourstoutesles

fon tionnalitésquel'onpourraitattendred'un a hetantauniveaudela

on-guration du a he que de la visualisation de ses résultats. Ce manque de

vi-sibilité a pour onséquen e d'augmenter la di ulté à analyser nement les

performan es de lama hine et à optimiser sonutilisation. Cette di ulté est

en ore renfor éepar laréti en e des onstru teursà fournirdes détails sur le

fon tionnementinternedeleursma hines.

D'unpoint devuemoins te hnique,lalogique propriétaireadoptéepar es

solutionssemblealleràl'en ontredel'évolutiondumar hé.Unorganismeayant

a quisunema hinedemarquelambdanepourramainteniretenri hirson

sys-tèmequ'ave dumatériellambda,auxprixxésetimposésparle onstru teur.

Les performan es obtenues par de tels systèmes sont très variables et

dif- ilement omparables du fait du manque de standards pour l'évaluation de

performan e des a hes WEB (voir plus loin, se tion 5). Les performan es

annon ées par les onstru teurs ne sont pas ables. Début Mars 1999, le

tes-tout onstru teur dans des onditions les plus réalistes possible (voir [14℄,

http://bakeoff.ir a he.net/bakeoff-01). Seuls quelques onstru teurs se

sontportésvolontaires,tousn'ontpasa eptélapubli ationdeleursrésultats.

Les résultats sont variés et il est souvent di ile de dire qu'unema hine est

meilleure qu'une autre : toutes ont des for es et des faiblesseset répondentà

des exigen esdiérentes.Leseul onstru teurdeboites noirespourles a hes

WEB à avoir a epté la parti ipation au bake-oet la publi ation de ses

ré-sultat est InfoLibria. A titre d'exemple, les prix des ma hines InfoLibria-Let

InfoLibria-S, utilisées pendant le bake-o, étaient respe tivement de $200.000

et de$130.000.

En on lusion, e type de ma hine n'est pas intéressant pour des études

expérimentales omme ellesquiserontmenéesdansle adreduprojetCHARM

dufaitdeleurmanquedetransparen eetd'ouverture.Ilest ertainementplus

adaptéaumar hétrès on urrentieldesISPdeparlasimpli itéd'utilisationet

larapiditédemise en÷uvre.

3 Les logi iels

Dans ettepartie nous dé rivonsles prin ipaux logi iels disponibles sur le

mar hé.Certainssontgratuits,d'autrespayants.L'oreenlamatièreévoluetrès

rapidementetdenouveauxlogi ielsde a heapparaissentrégulièrement.Nous

ne serons don pasexhaustifs mais her herons pluttà dégager lesprin ipes

debaseutilisésa tuellementparlesdiérentes solutionslogi ielles.

Lepremierproxy- a heàvoirlejourfutleCERNHTTPD(voir[25,26℄)

dé-veloppéparleWorldWideWebConsortium(http://www.w3.org).Ceserveur

sourait de quelqueserreurs de on eption (un pro essus par requête,

utilisa-tiondusystème de hierUnixinadaptée),parti ulièrementsensiblesquandle

serveurétaittrès hargé.Ilestpossibledebâtirunehiérar hiede a heave le

CERN HTTPD mais de manièrelimité. LeHarvest Ca he aété misau point

pourpalliersesdéfauts.

Le Harvest Ca he([13℄), devenu parla suite le Squid a he ([37℄), logi iel

gratuit de a he hiérar hique, est le logi iel de a he leplus utilisé de partle

mondeetleplusétudié.Lapartiequisuitest onsa réeàsaprésentation.Squid

alevéquelquesproblèmess ientiquesetnombredesolutionsontétéproposées,

faisantévoluerle a hehiérar hiqueSquidversun a hedistribué.Lapartie3.4

dé rit lesévolutionslespluspertinentes proposéespourSquid.

3.1 Présentation de Squid

Squid est,de loin, le logi iel de a hele plus utilisé au monde, 'est aussi

sansdouteleplusvieux.Ilest utilisésurquasitotalité duréseauuniversitaire

français,RENATER.Ilrésultedutravail onjointdesuniversitésdeCalifornie

duSudetduColorado.LenominitialduprojetétaitleHarvestProje tGroup.

Cegroupeainitiéla ampagne" a henow"desensibilisationàl'utilisationdes

a hes sur le WEB (voir http://squid.nlanr.net).Son immensesu ès est

sans doute tout autant dû àsa gratuité qu'à sesperforman es, nettement au

montrersonsu ès,maismieuxen ore,voi iunejusti ationde e hoixissue

delapageWEBdeRENATER:"Lesdeuxserveurs a helesplusrépandus(il

yaaussiSpinneretLagoonmaisvouspouvezvoiràYahoos'ilyenad'autres)

sontleserveur du onsortiumW3(ex-serveurCERN) et Harvest. Nous avons

hoisi e dernier,bienplusperfe tionnéetmieux maintenu."Ilestànoterque

Squid est non seulementutilisé pour les serveurs universitairesmais que

RE-NATER souhaiteaussifaireparti iperlesprestatairesInternet ommer iauxà

lastratégiede a hes oopérantsauniveaudelaFran e.

3.2 Fon tionnement de Squid

Squidutilise unestru turehiérar hiquede a hes oopérants omme

repré-sentéeFigure4et5anderéduirelademandeenbandepassante surlesliens

grandedistan eetdediminuerla hargesurlesserveursd'informationInternet.

Lesé he sde a hesontrésolusgrâ eaux a hessituésplushautsdansla

hié-rar hie.Enplusdelarelationls-père,le a heutiliselanotiondefratrie :les

frèressontles a hesdemême niveaudans lahiérar hie.Ils sontutiliséspour

répartirla hargede a he.Chaque a hedanslahiérar hiedé ide

indépendam-ment deré upérer laréféren edemandée depuislesite d'origine oudepuisles

a hespèreoufrèresenutilisantunproto olederésolutiontrèssimplenommé

ICP. Leprin ipede fon tionnementest dé rit endétails dans lasuitede ette

se tion.

Client

Client

Client

Site d’origine

Racine du cache

ICP

ICP

ICP

ICP

HTTP

HTTP

HTTP

ICP

ICP

Feuilles du cache

Fig.4:L'ar hite turehiérar hiqueetles ommuni ationsdeSquid

Le texte de l'URL est d'abord analysé. Si il ontient une des haînes de

rar hiede a hes.Cettepossibilitéestoertepourfor erle a heàrésoudreles

URLnon a hables(" gi-bin")etlesURLlo alesdire tementdepuisleserveur

d'origine. De la même manière, si le nom de domaine de l'URL orrespond à

une entrée d'un listeparamétrablede haînesde ara tères, alorsla référen e

est résoluevialeparentdédiéà edomaine.

Sinon,quandun a hereçoitunerequêtepouruneURLquié houe,il

ee -tueunappeldepro éduredistanteàtoussesfrèresetparentsandedéterminer

sil'unpeutrépondreàlarequête.Sioui,le a heré upèrel'objetdepuislesite

quiaréponduleplusrapidement.Uneoptionpermetd'enrlerlesited'origine

danslepro essusderésolution delarequête.Quand etteoptionest

position-née,le a heenvoieun"hit"auportUDPe ho( eluiquirépondaux"ping"des

utilisateursUnix)duserveurd'origine.Quand ettema hinerenvoie emessage,

ilestvuparle a he ommeun"hit"identiqueà euxquepourraitretournerun

desfrèresoupèreen asdesu ès(lefrèreoupèrepossèdel'objetlo alement).

Cetteoptionpermet deretrouverl'objetdepuissonsiteserveurdansle asoù

elui- iestpluspro hequen'importelequeldesfrèresoupère.

Un a herésoutuneréféren eave lepremierfrère,pèreousited'originequi

retourneunpaquet"Hit"ouave lepremierpèrequiretourneunpaquet"Miss"

dansle asoùtousles a hesé houentetoùleserveurd'originen'apasrenvoyé

deréponse avant2s.Cependant,le a henevapasattendrelandutime-out

duserveurd'origine,ilva ommen eràtransmettredèsquelesparentsetfrères

auront tousrépondu.Le but de e proto ole est de résoudre lesréféren es en

utilisantla sour elapluse a e.Ce proto oleest bien une heuristique ar si

une réponse rapide àun "ping" indique une faible laten e, labande passante

peutêtreunfa teurplusimportantdansle asdesobjetsvolumineux.

Quandunobjetest ré upérédepuissonsite d'origine,len÷udl'ayant

ol-le té le opie dans son a he lo al et le transmet au n÷ud ls demandeur.

Celui- i, àsontour, opie le do umentdans son a he lo al et letransmet au

n÷ud ls demandeur. Ce pro essus est réitéré jusqu'au lient demandeur de

l'objet.

LesauteursdeSquidpré onisentdans[12℄den'utiliserquetroisniveauxde

a hes pour n'ajouter que peu de laten e par rapport à un a ès sans a he.

Le seul as où le a he ajoute un délaide laten e notoire est quand son père

est enpanneet quelelsnelesait pasen ore.Dans e as,lesréféren esaux

objetssontdiéréesde2s,letime-outdu a hepère-vers-ls,etSquidn'attendra

temporairement plus de réponse de e n÷ud. Quand on augmente la hauteur

de lahiérar hie, len÷udra ine devientresponsable d'un nombre roissantde

lientsetpeutdevenirungouletd'étranglement.Ilestre ommandédeterminer

lahiérar hielàoùlabandepassante estabondante.

Les requêtes entre les n÷uds du a he hiérar hique utilisent le proto ole

ICP(InternetCa heProto ol).Ceproto ole(voir[23,39,38,40℄),initialement

développé pour le Harvest a he, est un proto ole léger orienté datagramme,

i.e.ilsepeutquelemessageenvoyén'atteignejamaissondestinataireetau un

heminde onnexionn'estétablientrel'émetteuretleré epteurpourd'éventuels

Denombreusesétudessesontintéresséesàl'améliorationdesperforman es

de Squid. L'unedespremièresa étéproposéeparPoveyet Harrisondans [29℄

et l'idée de base reprise dans de nombreuses appro hes ([18, 35, 33, 21, 36℄).

Elleseproposederésoudrelesproblèmesapparusave l'utilisationdeSquidà

grandeé helle.Eneet,siSquidrépond orre tementauxattentesderédu tion

d'utilisation delabande passante duréseauet de diminution dela hargedes

"hotspots",lestempsdelaten eutilisateursnesontpasfor émentréduits.

Ilapparaîtàl'utilisationquesilenombred'utilisateursdeSquiddevient

im-portant,les a hesdesn÷udsintermédiairesdeviennentrapidementsur hargés

et onstituent des goulets d'étranglement. La gure 5 permet de mieux

om-prendrelepro essus.Lesn÷udsmarqués"CN"représententlesn÷uds lients,

euxmarqués "L1", les a hesde niveau1, euxmarqués "L2",les a hes de

niveau 2, "L3", le derniern÷ud de lahiérar hie. L'espa e disque onsa ré au

a heestreprésentéparlesdisquesmarqués"C".Pourqu'unn÷udmaintienne

untauxdesu èsoptimal,etfournisselemaximumderédu tiondestransferts

redondants,son a helo aldoit ontenirl'interse tiondes ontenusdetousses

a hesls.Pourlesn÷udsL2etL3,lesespa esdisquerequispeuventêtretrès

importants. En théorie ([29℄), les n÷uds intermédiaires devraient avoir un

es-pa e de sto kage proportionnel au nombre totald'utilisateurs pour maintenir

untauxdesu ès eno tets(byte hitrate) onstant.Si lataille des a hesest

insusante,le tauxd'é he de a heaugmente ainsi quela onsommation de

bande passante,et . L'e a ité del'appro hehiérar hique diminuedon ave

lenombred'utilisateursetlatailledes hiers, equiestpluttmaladaptéaux

évolutionsdumar hé.

L3

H

L2

H

CN

CN

CN

L1

H

CN

CN

CN

L1

H

L2

H

CN

CN

CN

L1

H

CN

CN

CN

L1

H

1

3

2

Serveur d’origine

1

2

3

4

5

6

7

8

9

10

11

C

C

C

C

C

C

C

C

C

C

C

C

C

C

C

C

C

C

C

Fig.5:Répartitiondesdonnéesdans un a hehiérar hique. Latransa tion de

gau heestunsu èsde a hesurlepremierpère, ellededroite uné he

Un autre problème apparu ave Squid est elui de la maintenan e de la

hiérar hie. En eet, haquen÷uddoitmaintenir desinformations surla

lo a-lisation de tous les voisins an de pouvoir rediriger les requêtes vers eux. Si

ette tâ he est simplequand les diérentes ma hines de lahiérar hie sont

rendra par exemple très ompliqué pour les administrateurs de tenir ompte

des ajouts et suppressionsde serveurs a he.Le problèmeest similaire à elui

de la maintenan e des tables de orrespondan e nom-adresse des serveurs de

l'Internetrésolua tuellementparl'utilisationduDomainNameSystem(DNS,

voir[2℄).

L'utilisationduproto oleICP asouventété ritiquée(voir[18,33,35℄).Ce

proto oleesttypiquementutiliséentrelesn÷udsdelahiérar hiede a hespour

interroger leurs ontenus. Les messages ICP sonttransmis via UDP. Un

mes-sageest onstitué d'unentêtede 20o tets et d'uneURL.Un a heenvoie un

message"ICP_QUERY"àsesvoisins.Ceux- i répondentparun"ICP_HIT"

ou"ICP_MISS" pour indiquerlaprésen eou l'absen ede l'objetnommé par

l'URLdansleurs a hes.Leproblèmevientprin ipalementde emoded'é hange

enquestion/réponse.LesrequêtesICPsonttraitéestrèsrapidementetletemps

delaten eest trèslégèrementsupérieurauround-trip timeduréseau.Mais es

temps peuventêtre très longs pour desserveursdistants. Outre lesproblèmes

liésaux onditionsduréseau,ICPestpeuextensible.Danslaplupartdes

on-gurations, l'interrogationde nvoisinsest réaliséeen envoyantn requêtes ICP.

Au une optimisation n'est mise en ÷uvre. La bande passante utilisée et les

hargesCPUinduitesparleproto olesontd'autantplusgrandesquelenombre

de n÷uds est grand. Une étude expérimentale utilisant Squid ([18℄) a mis en

éviden e une rédu tionimportante desperforman esinduiteparICP pourun

nombredevoisinsaussipetitque4etenutilisantunréseaurapideà100Mb/s.

Enn, le oût des sauts dans la hiérar hie de a he n'est pas négligeable

ontrairementàl'idée souventadmise(voir[35℄ pourune étudeexpérimentale

et [30℄ pourune appro heformelle). Aussi bien lessu ès sur les a hes

inter-médiairesquelesé he ssubissentdes délaisadditionnelsdusàlapropagation

enmode"store-and-forward"desrequêtesdansle a hehiérar hique. Deplus,

quand lesn÷udsintermédiaires doiventservirungrandnombrede lients

dis-tribuéssurunlargeterritoire,lesdélaisduréseaupeuventêtretrèsimportants

et don diminuerl'intérêt,pourl'utilisateur,dessu èssurles a hesdistants.

3.4 Les solutions a tuelles

Pour pallier es problèmes, les solutions a tuelles proposent de ne pas

a- herles do uments au niveaude tous les n÷uds intermédiaires. En revan he,

es n÷udspeuventsto kerdestables ontenantdesinformationsrelativesàla

pla e des pages a hées. Un exemple est représenté Fig. 6 où les "H"

repré-sententlestablesdelo alisation(Hintenanglais).L'arrangementhiérar hique

du a hepermet de traiterlesre her hese a ementet de répartir la harge

surlesdiérentsn÷uds.Onparlede a hesdistribuésparoppositionaux a hes

hiérar hiques pré édents,on trouveaussil'expression"séparation desdonnées

etdesméta-données".Lesdiérentessolutionsproposéesvarientessentiellement

parlamanièredontlesrequêtessonttraitéesetparladiusiondesinformations

danslahiérar hie.

3.4.1 Distributed a he

Dans le système proposé par Povey et Harrison ([29℄), seules les feuilles

par l'important espa e de sto kage né essaire pour les n÷uds intermédiaires

est don levé.Unerequête esttransmisedels enpère ommeave Squid(les

ommuni ationave les frèresnesontpasutilisées),sauf quedans le as d'un

su ès de a he,len÷udintermédiaire neretourne plusledo ument, maisun

pointeurréférençantledo umentdansunautre n÷udfeuilleoùl'émetteurira

le her her.Quandunn÷udfeuillerapatrie/détruitundo ument,ileninforme

lesn÷udsintermédiairesparmessages.

Leprin ipal avantagede ette méthode parrapport àSquid est dene pas

exigerd'immensesespa esdisquessur lesn÷udsupérieursdelahiérar hie.De

plus,lagestiondelahiérar hiedu a heestsimpliéepuisquelesn÷udsn'ont

plusà onnaîtrelalo alisationdeleursvoisins.Enn,lesauteurssoulignentla

fa ilitéave laquelleleursystèmepourraitêtreadaptépourprendreen ompte

ladupli ation detypemiroir(mirroring).Lesauteurs ontréaliséune étudede

performan e du Distributed Ca he basée sur une simulation pour diérentes

stru turesdelahiérar hie.Leurétudemetenéviden eungaindeperforman e

minimeparrapportàSquid.D'autresauteurs([31℄)ontmontrédansuneétude

théorique desrésultats similaires.Les auteurs duDistributedCa he on luent

àlasupérioritédeleurappro hedufaitdesoné onomieet desasimpli ité.

L3

H

L2

H

CN

CN

CN

L1

H

CN

CN

CN

H

L1

L2

H

CN

CN

CN

L1

H

CN

CN

CN

L1

H

Serveur d’origine

1

2

3

4

1

2

3

4

C

C

C

C

C

C

C

C

C

C

C

C

Fig.6:Répartitiondedonnéesdansun a hedistribué.Latransa tiondegau he

est unsu ès de a heet le do umentest ré upéré dansun a hevoisin, elle

dedroiteuné he

3.4.2 Le a he de l'Université duTexas

Tewari, Dahlin, Vin et Kay ([35℄) proposent un s héma où les feuilles du

a hehiérar hique, enséestypiquementreprésenter unISP, a hentles

do u-mentsissusdel'Internettoutenayantunetabledelo alisationdesdo uments

du a he(voirFig.6). Ces hémareprésentedèlementlaréalitéoùlesISPne

sontpasprêtsàfourniruna èsdire tàInternetaux lientsmaispréfèrentleur

imposer detraverserleur a he.Ledesign proposétient omptede ladistan e

des a hesentreeux:lestablesdelo alisationnegardentqueles opieslesplus

lo alisation.Sil'objetn'estnidansson a helo alnidanssatablede

lo alisa-tion,larequêteesttransféréeausited'origine.Sil'objetestdansle a he,ilest

transféré.Silatabledelo alisationindiquequ'undesn÷udsfeuilleal'objet,la

requêteluiesttransféréeetle a heretournel'objet.Lahiérar hieestseulement

utiliséepourmainteniretpropagerlesinformationsdelo alisation.

L'originalité de ette appro he est de ombiner une hiérar hie extensible

des tables de lo alisation ave le a hage de es tables près des lients. Les

auteurs arment obtenirdes temps de réponse améliorés d'un fa teur 1:27 à

2:30parrapportàun a hehiérar hique lassique.Lesauteursproposentaussi

de ombiner desalgorithmesde "push"aux a hesan dediminuer lestemps

delaten edessu èssurdes a heséloignés.

3.4.3 CRISP

PourCRISP(voir[21,20℄),lesauteursproposentunealternativeàla

stru -ture hiérar hique et à la diusion des interrogations aux autres a hes. Les

a hesCRISPsont onstituésd'une olle tiondeserveursde a heet d'un

ser-vi e ommundelo alisation.Lesserveursde a hepartagentlesrépertoiresde

leur a hesvialeservi edelo alisation.Ceservi epeutêtreinterrogéenunseul

messageparlesdiérentsserveurspour onnaîtrele ontenudesautres a hes.

En as desu ès (l'objet a été trouvédans l'union desdiérentsrépertoires),

l'objetest transmisdire tementparleserveurde a he.En as d'é he ,le

ser-veurd'origine est onta té. Le servi ede lo alisation est maintenu àjour par

lesserveursde a hequil'informentdesobjetsré upérésetdesobjetsdétruits.

Lesserveurspeuventêtre onguréspourdupliquertoutoupartiedurépertoire

global an d'équilibrerles oûts, laten es et su ès de a heen fon tion dela

tailleetdeladispersiongéographiquedu a he olle tif.Danslaversioninitiale,

leservi edelo alisationest onstituéd'unensembledeserveursdelo alisation.

A haqueserveurest ae téunsous-ensembledel'espa edesURLgrâ eàune

fon tiondeha hage.

Ceprin ipeest pro hede eluide CARP(voirplusloinet [36℄)et est

par-ti ulièrementadapté aux besoins des prestataires de servi e Internet dont les

serveurs béné ient a priori d'une bonne onne tivité. Une se onde versiona

étédéveloppéepourrépondreauxexigen esdesserveursgéographiquement

dis-tants.Dans etteversion,lerépertoireglobalestdupliquésur ertainsserveurs

delo alisationdemanièreasyn hrone.Lesrequêtessonttraitéeslo alementet

la ohéren e durépertoiren'estpas assurée.Notons que edernier point

n'af-fe te pas lavalidité du a he mais sa performan e. En eet, si une mauvaise

entréedurépertoireglobaldupliquéestutilisée,l'erreurestparlasuite orrigée

et leserveurd'origine onta té.Une troisièmeversiondeCRISPpermetde

ré-duirele oûtdeladupli ationdurépertoireglobal.L'idéedebaseestderepérer

un sous-ensemble du ontenu du a he qui permettra d'obtenir le plus grand

nombrede su èset de nedupliquerque esentréessur lesdiérentsserveurs

de lo alisation.Lesauteurs onttestéslesdiérentes versionsdeCRISP ontre

diérentes versionsdeSquid(voir[19℄) mettantenéviden elas alabilitéet la

Pour Ca he Digest ([33℄, http://squid.nlanr.net/Squid/Ca heDigest),

lesauteursproposentqueles a hespuissenté hangerdestablesdeleur

onte-nus.Sile a heApossèdeune opiedelatabledu a heB,il onnaîtles

do u-mentssus eptiblesd'êtredansB.Ilpeutdon dé iderderé upérerunobjetdu

a heBsansavoirà onta ter elui- i auparavant.LesrequêtesICP de Squid

sontenquelquesorterempla éespardes onsultationsdetables,nettementplus

rapides.

Lestablessontbaséessurleshash- odedesURL desdo uments.Les

olli-sionsétantautoriséesdans estables(elles sontsupposéesrares),ellespeuvent

indiquer unsu ès de a he alors que ledo ument her héne s'y trouvepas.

Le résultat deleur onsultation est don moins pré isque elui obtenu parla

batteriederequêtesICPdeSquid.Enrevan he,lesdélaisasso iésauxrequêtes

ICP sontéliminés.Les tempsde réponse des lients sontdon diminuéset les

besoinsenbandepassantepeuventêtreaméliorés.Lestablessonté hangéesvia

HTTP.La olle tiondetables est maintenueàjour parl'utilisation des entêtes

d'expirationdesrequêtesHTTPasso iéesà haquetable.Une versiondeCa he

Digest aétéinsérée dansSquid.Comparésauxrésultats obtenusave ICP, les

résultatsexpérimentauxdeCa heDigestmettentenéviden eunediminutionde

lalaten epourlesutilisateursetunediminutiondelabandepassante

onsom-mée.Enrevan he,on onstateuna roissementdel'espa emémoire onsommé,

lenombredefauxsu èsde a heestimportantet lesn÷udsdu a hedoivent

avoir des onnexions permettant des transferts rares mais volumineux (1Mo

touteslesheures).

3.4.5 CARP

Dénien ollaborationparl'UniversitédePennsylvanieetMi rosoft,CARP

(Ca heArrayRoutingProto ol,voir[36℄)estunproto olepermettantde

répar-tirl'espa edesURLentrelesdiérentsserveursd'un a hefaiblement ouplé.

Leproto oledénitunestru turedetabled'appartenan eàlalistedesproxies

du a heetunefon tiondeha hageasso iée.Lafon tiondeha hagepermetde

déterminer lequeldesproxiesdela listedevrait êtrele possesseur del'URL si

elleaété a hée.Lafon tiondeha hagerempla eenquelquesortelesrequêtes

ICP, les Ca hes Digests et autres tables de lo alisation.Quand un lientveut

unobjet,ilsait immédiatementoùaller le her herenha hantl'URL.Un

ser-veurne a he queles do uments répondant àsa fon tionde ha hage, évitant

ainsi lesdoublons. Le omportementd'untel systèmeàune grande é helleoù

lestemps de réponsepeuventêtre très variablesn'estpas lair : larépartition

desURLest indépendantede la onne tivité duréseau.Lagestiondelatable

d'appartenan e à la liste des proxies du a he pourrait être problématique à

grandeé helle,delamêmemanièrequelahiérar hiedeSquid.

3.4.6 SUMMARYCACHE

Pour Summary Ca he ([18℄), Fan, Cao, Almeida et Broderproposent que

touslesserveurs a heaientunrésumédesURL a héesparlesautresserveurs.

Lesrésuméssontmisàjourpériodiquementetutilisentunereprésentation

é o-nomique.Lesrésumésnesontdon pastoujoursàjouretpeuventgénérerdeux

a héparunautreserveurn'étaitpasindiquédanslerésuméetquele

deman-deur est alléleré upérerauprèsduserveurd'origine.Un fauxsu ès apparaît

quand unobjet ensé être dans un ertain a he n'y est pas. L'erreur est

fa- ilement déte tée, le serveur d'origine est onta té mais le temps de laten e

utilisateurest altéré.Danslesdeux as, lavaliditédu a hen'estpasae tée,

seuls sont on ernésles taux desu ès et tra inter-proxy. Les résumés sont

implémentés sousforme deltresdeBloom([7℄) quipermettentune

représen-tation peu oûteuse ave un faible taux d'erreurs (faux su ès de a he). Les

résumés sontmodiés quandle pour entagede tauxd'erreur dépasseun seuil

hoisiparl'utilisateur.

3.4.7 Vers des a hes entièrement auto-adaptatifs

Ré emment,Zhang,FloydetJa obsonontproposél'utilisationd'une

orga-nisationdes a hesWeb entièrementauto-adaptativebaséesurdesgroupesde

diusion (voir[27, 42℄). Ces travauxn'ont pour l'instant donné lieu àau une

implémentation.

4 Les a hes parallèles

Les études portant spé iquement sur les a hes WEB parallèles sont

en- oreraressinoninexistantes.LesétudesportantsurlesserveursHTTPparallèles

sontplusnombreuses([9,43℄).Lestravauxrelatifsauxserveursvidéoparallèles

peuventaussiêtreintéressantspourledomaine des a hesparallèles([22, 15℄)

surtoutdansle adreduprojetCHARM.

Ilest on evabled'implémenterlaplupartdes a hesprésentésdansla

se -tion3surun lusterdema hines.LesauteursdeCRISP([21℄)estimentquela

premièreversiondeleuralgorithme(PartitionedSyn hronousDire tory)

pour-rait être implémentée sur un luster de proxies ave su ès. Le proto oleICP

pourraitaussiêtreutilisé arlaplupartdesrepro hesquiluiontété faitssont

surtoutappli ables auxréseaux grande distan e. Les auteurs de Squid notent

dans([12℄)quelesproblèmesposésparl'implémentationduHarvestCa hesont

lesmêmesque euxquiontétérésolusauparavantdansledomainedessystèmes

de hiersdistribués.L'ar hite tureduHarvestCa heestd'ailleurstrèspro he

de elleduAlexlesystem([11℄).

Une proposition a même été faite ([34℄) pour rempla er le proto ole HTTP

parlesystèmede hiersdistribuésAFS(AndrewFileSystem).Ilest lairque

lessystèmesde hiersdistribuésfournissentdemeilleursrésultatsentermede

a he, dupli ation, gestionet sé urité quele Web a tuel. La raison prin ipale

pourlaquelledessystèmes ommeAFSn'ontpasétéréutiliséstientsansdouteà

leurlourdeuretàleurmanqued'ouverture.Maisuneraisonplusfondamentale

est que les systèmes de  hiers sont de mauvaises abstra tions pour les

sys-tèmes d'informationa tuels. Ils réunissentun ensemble de fon tionnalités qui

lesrendentrédhibitoirespour ertainesappli ationsetlaseulemanièrede

mo-dier esfon tionnalitésest demodierlesystèmed'exploitationoudefournir

desmé anismes permettantauxappli ations despé ier letypede

omporte-mentattendu.Parexemple,ladiusionparot(streamingenanglais)n'apas

tionnerdes ara téristiquesprédénies(parexemplevoirunevidéostreamée):

le hoixàla arteparmiunensembled'outilsdisponibles surlemar héplutt

qu'un système de  hiers omnipotent. En revan he, dans le adre d'un a he

en luster,le hoixd'un systèmede hierstelAFSest toutàfait on evable.

C'est l'optionretenueparlesauteurs d'unprototypeauNCSAdé rit i-après.

Katz,ButleretM Grath(voir[24℄)duNationalCenterforSuper omputing

Appli ations (NCSA) ont développé un serveur HTTP parallèle et leurs hoix

sontreprésentatifsde nombreux travauxsur le domaine. Ils proposent

d'utili-serun luster de serveursHTTP ongurés àl'identique. Un ontrleur entral

distribuelesrequêtesauxdiérentsn÷udsdemanière ir ulaire.Ce ontrleur,

appeléaussidistributeurde harge,estuneversionduBerkeleyInternetName

Domainmodiépourae terunmêmenom(dutypewww.n sa.edu)aux

dié-rentesma hinesdu luster.Lesystèmede hiersparallèleASFestutilisépour

maintenir un ensemble de do uments ohérentsentre les n÷uds.ASF permet

aux serveurs HTTP de voir le système de  hiers omme lo al,quelle que soit

salo alisationee tive.Un systèmede a he opie les hiersdemandéssurle

disquelo al.Lesdonnéesontaussiétédupliquéesàl'intérieurdeASFanqu'en

asdedéfaillan ed'undesserveurslesdonnéessoienten oredisponibles...Ilest

ànoter queBINDet ASF étantportablessur n'importe quelleplate-forme,le

lusterainsiforméestmodulabletantauniveaudunombredema hinesquede

leurstypes.Unproblèmeliéàl'utilisationduround-robinDNSestque elui- i

ne tient pas ompte de la harge des serveurs : un serveursur hargé re evra

autant de requêtes que les autres.Un système similaire est proposé par IBM

Ressear h.IlestbasésurunSP-2ouun lusterdeRS6000etfaitaussio ede

serveurmultimédia.Ilutilise unrouteur TCPpourdistribuerlesrequêtesvers

lesdiérentsn÷uds duserveur,lesystème de  hiers multimédia TigerShark

et le système de  hiers parallèle Calypso pour le sto kage des données (voir

http://www.resear h.ibm. om/webvideopourdeplusamplesinformations).

5 Mesure de performan e de a hes WEB

Plusieurstypesdemesurespeuventêtre onsidéréespourévaluerles

perfor-man esd'un a heWEB.Lesmesureslesplusutilisées on ernentletempsde

délivran e des objets ontenus dans le a he et le nombre d'URL servies par

se onde. Mais on peut aussi s'intéresser aux nombre maximal de onnexions

simultanées possibles,àlarelation entretemps deréponseet harge,àla

rela-tionentre tauxde su èset hargeou en oreàlafraî heurdesdo uments.Un

problème ré urrent pour l'analyse des performan es des a hes Web est elui

posé parla reprodu tion de onditions réalisteslors dutest. Le plussouvent,

lasolutionretenuereposesurl'utilisationdetra esréelles olle téessoitauprès

de prestataires de servi es Internet, soit auprèsd'universités, le plus souvent

améri aines.Les hiersdetra esréellessontutiliséspourgénérerunprolde

requêtessemblableà eluidesutilisateursréels.Denombreux hiersdetra es

sontdisponiblessurleWeb. Denombreuxserveursproxy- a hepermettentde

générerlestra esd'utilisationdeleurs lients.Leformatdetra eadopté omme

standardde faitest eluide Squid.Les onstru teursde a he(matériel ou

lo-gi iel) proposent des outils permettant d'évaluerles performan es d'un a he

al ulantla omplexité desalgorithmesmisen÷uvre.Dans ette optique,

Ro-driguez, Ross et Biersa k (voir par exemple [31℄) ont omparé les oûts des

onnexions et des transferts de données pour des a hes hiérar hiques et des

a hesdistribués.Ilsproposentensuiteunmodèlehybridepermettantde

béné- ierdumeilleurdesdeuxalgorithmes.Malheureusement,deparla omplexité

et lenombredesmé anismesmis en÷uvre,detellesanalysesrestentlimitésà

desmodèlesdelaréalitétrèssimpliés.

Ontrouvedanslalittératuredenombreusesdes riptionsdeproto oles

d'ana-lyse réalisés sur des plates-formes expérimentales. Les mesures sont souvent

réaliséesmanuellement, au oup par oup, sansque soient développésd'outils

logi ielspouranalyserlesperforman esdu a heWEBautomatiquement.

Atitred'exemple, ledispositifmis enpla epouranalyserlesperforman es

du Summary Ca he ([18℄) utilise 10 Spar -20 onne tés par un réseau

Ether-netà100 Mb/sreprésenté parlagure7. Quatrestationssont onguréesen

proxy- a he,quatreautresstationssontutiliséespoursimulerla harge, ha une

exé utant30pro essus lient.Les lientsse onne tentauxdiérentsproxieset

émettentdes requêtessanstempsd'attente entre elles.Lataille desdo ument

demandés suit une distribution de Pareto ave = 1:1 et k =3:0. Deux

sta-tionssontutilisées ommedesserveurs, ha uneave 15serveurs onne téssur

diérents ports. Chaqueserveur "fork" un nouveau pro essus pour gérerune

nouvellerequête HTTP.Le pro essus attend 1savantde répondreàla requête

andesimulerlalaten eduréseau.Lesexpérien essontréaliséespourdestaux

desu èsde25%et 45%.

Processus

clients

Processus

serveurs

Réseau local

Machines proxy-cache

Machines serveurs

Machines clientes

Fig.7:Ar hite turepourl'analysedeperforman ede a heWeb

Souventdestra esréellessontutiliséespourgénérerune hargeréaliste.Ilest

ependantànoterqu'ilfautprendresesmesuresave beau oupdepré autions:

lestra esgénéréespardesutilisateursautravailpeuventêtretrèsdiérentesde

elles généréespardesutilisateurs(éventuellementlesmêmes)àlamaison.Le

tauxpotentieldesu èsd'un hierdetra eestdon àprendreen onsidération

lorsdel'évaluationdesrésultats.C'estunedesraisonspourlesquellesdesoutils

ontétémisaupointquipermettentdefairevarierletauxdesu èsasso iéaux

Cao ont développé le Wins onsin Proxy Ben hmark ([3℄) pour l'analyse des

performan esduSummaryCa he.Lastru tureutiliséeesttoujours elle

repré-sentéeFig.7.Le Wins onsinProxyBen hmark omprendunpro essusmaître

qui gère l'ensemble du test, despro essus lientqui génèrentlesrequêtes, des

pro essusserveurquisimulentlesserveursdepagesWebexistantssurleréseau.

Lesauteursproposentunproto oledetestetune manièredel'interpréter.Les

limitationsde eproduitsonten oregrandes:le onditional-GETn'estpaspris

en ompte,les onnexionspersistantesnon plus,et .Le premiertest àgrande

é helleindépendant,organiséparleNLANR(NationalLaboratoryforApplied

NetworkResear h),datedudébutdel'année1999.Ildevraitsereproduiresur

labasededeuxtestsparan.C'estle"bake-o"dé ritplusendétails i-après.

5.1 Le premier bake-o

Début Mars 1999, le premier "bake-o" a été organisé par le groupe

Ir- a he (NLANR) pour tester les produits de a he HTTP à l'aide d'un outil

ouvert et indépendant de tout onstru teur dans des onditions les plus

réa-listes possible (voir [14℄, http://bakeoff.ir a he.net/bakeoff-01, http:

//polygraph.ir a he.net).

Lesoutilslogi ielsduWebPolygraph,polysrvet poly tlontété utilisés.

Ils permettent respe tivement de simuler des serveurset des lients.Le a he

estsituéentreles lientsetlesserveurssimulés.Pendantl'expérien e,poly tl

envoieau a heunotderequêtesrépondantà ertains ritères,polysrvrépond

auxrequêtesenvoyéesparle a he.L'expérien eestdé oupéeentroisphases:

unephasededémarrage(remplissagedes a hes),unephasedepleinrégimeet

unephased'arrêt.Lesmesuressontee tuéespendantlaphasedepleinrégime.

Lesoutilspolysrvet poly tlpermettentdefairevarierlataille desréponses,

laproportiond'URL a hables,lestempsdelaten edesserveurs,lapopularité

desobjets,et .Lebutestdepouvoirsimulerdestauxde hargesreprésentatifs

desutilisateursduréseau.

Iln'existepasdemesureabsoluedesperforman esd'un a heWeb.D'au uns

atta herontleplusd'importan eaudébitensortie,d'autresàlarédu tiondela

bandepassante,d'autresautauxdesu èsobtenu,d'autresenn autemps de

réponse auxrequêtes.Lesauteursdutestpré onisentauxévaluateursdebaser

leur hoix sur une sommepondérée des diérentes valeurs obtenues. Le hoix

despondérationsétantlaisséauxévaluateursenfon tionsdeleursbesoins.

Cependant esoutilssemblenten oredi iles d'a ès,enattestentles

pro-blèmesren ontréslorsdel'étuderéaliséeparNetworkComputingmagazine(voir

[41℄)etlesréa tionsdel'équiped'ir (voir[32℄ethttp://polygraph.ir a he.

net/slidespourl'utilisation de Polygraph). De nombreuxparamètres sontà

prendre en ompte, de nombreux résultats à interpréter et il faut en ore un

expert enmesuredeperforman epourmettreen÷uvre untest ohérent.

Il est à noter que e test ne on erne que le proto ole HTTP et que les

standardsré ents,enparti ulier euxutiliséspourleste hniques destreaming

(RTSP, RTP), ne sont pas pris en ompte. Ils ne sont de toute manière pas

Dans e do umentnousavonstentédeprésenterunétatdel'artdes a hes

Web.Loindeprétendreàl'exhaustivité,nousavonsplusparti ulièrementinsisté

surlefon tionnementdesdiérentslogi ielsa tuels,surlesraresétudes

on er-nantles a hesWebparallèleset surlamanièred'estimerleurperforman e.

Lasuitede nostravauxprévoit lamiseau pointd'un a heWeb parallèle.

La plupart des algorithmes de a heprésentés ontété intégrésdans Squid. Il

est don probable que dans la suite de nos travaux Squid soit utilisé et que

lesanalyses deperforman esqui serontmenéess'inspirerontdubake-o.Sans

préjuger des travaux de re her he qui vont suivre, la mise au point du a he

Webparallèlefortement ouplépourras'appuyersurlestravauxréalisésdansle

domaine dessystèmes de hiers distribués, desserveurswebparallèles et des

serveursvidéosparallèles.

Denombreuxobjetsmultimédianesontpas a hésparleslogi ielsa tuels,or

leurimportan edevientdeplusenplusgrande.Nousnousatta heronsparsuite

àtrouverdessolutionsnovatri espourpallier esinsusan esparti ulièrement

pourlesvidéosstreaméesdutypeRealVideo.

De même, les  hiers volumineux ne sont pas a hés du fait de la pla e

tropimportante qu'ilso uperaienten a he. Nousétudierons les impa tsdes

méthodesutilisantdesmiroirsàhautdébitanderéduirelespénalitésendurées

parlesutilisateursdetels hiers.

Lespossibilitésd'indexationsdesdo umentssto késdansle a heoule

mi-roirsontaprioritrèsintéressantes.Ellesfournirontauxutilisateursunmoyende

[1℄ Mar Abrams,CharlesR.Standridge,GhalebAbdulla,StephenWilliams,

andEdwardA.Fox.Ca hingproxies:limitationsandpotentials.In

Pro ee-dings of the 4th International WWWConferen e, Boston,MA,De ember

1995. http://www.w3.org/pub/Conferen es/WWW4/Papers/155/.

[2℄ PaulAlbitz andCri ket Liu. DNSandBIND in anutshell. O'Reillyand

Asso iates,1992.

[3℄ Jussara Almeida and Pei Cao. Wis onsin proxy ben hmark 1.0. http:

//www. s.wis .edu/~ ao/wpb1.0.html,1997.

[4℄ MatthewAlonso,Raphael Blaze. Dynami hierar hi al a hing for

large-s aledistributed lesystems. InPro .of theTwelvthInt.Conf.on

Distri-butedComputingSystems,june1992.

[5℄ M.ArlittandC.Williamson. Webserverworkload hara terization:The

sear hforinvariants.InPro .oftheSIGMETRICSConf.onMeasurement

and Modeling of Computer Systems, may 1996. http://www. s.usask.

a/proje ts/dis us/VOIR.html.

[6℄ AzerBestavros,RobertL.Carter,MarkE.Crovella,CarlosR.Cunha,

Ab-delsalamHeddaya,and SulaimanA. Mirdad. Appli ation-leveldo ument

a hingintheInternet.InPro eedingsofthe2ndInternationalWorkshopin

DistributedandNetworkedEnvironments(IEEESDNE'95),Whistler,

Bri-tish Columbia, June 1995. http:// s-www.bu.edu/fa ulty/best/res/

papers/sdne95.ps.

[7℄ BurtonBloom. Spa e/timetradeosin hash odingwithallowableerrors.

Communi ationsof ACM,13(7):422426,july1970.

[8℄ Hans-WernerBraunandKimberlyClay. Webtra hara terization:an

assessmentoftheimpa tof a hingdo umentsfromNCSA'swebserver.In

Pro . ofthe Se ondInternational WorldWideWebConferen e,O t.1994.

[9℄ Ri hard B. Bunt, Derek L. Eager, Gregory M. Oster, and Carey L.

Williamson. A hieving load balan e and ee tive a hing in lustered

Web servers. InPro eedings of the 4th International WebCa hing

Work-shop,April1999. http://www.ir a he.net/Ca he/Workshop99/Papers/

bunt-final.ps.gz.

[10℄ Pei Cao and Chengjie Liu. Maintaining strong a he onsisten y in the

world wideweb. IEEE Transa tions on Computers,47(4) :445457,april

1998.

[11℄ Vin entCate.Alex,agloballesystem.InPro .oftheUsenixFileSystems

Workshop,pages111,may1992.

[12℄ AnawatChankhundthod,PeterB.Danzig,ChunkNeerdaels,S hwartz

Mi- healF.,andKurtJ.Worrel. AHierar hi alInternetObje tCa he.

Te h-ni alreport,UniversityofSouthCaliforniaandDept.ofComputerS ien e,

UniversityofColorado,Boulder,1995.

[13℄ Anawat Chankhunthod, Peter B. Danzig, Chu k Neerdaels, Mi hael F.

S hwartz,and KurtJ Worrell. A Hierar hi al Internet Obje t Ca he. In

Pro . 1996 USENIXte hni al onferen e,SanDiego,CA,Jan1996.

[14℄ CClaveleira. Évaluationdesperforman esdes a heshttp,le1 er

bake-o.

neousappli ationandserverenvironments. MultimediaToolsand

Appli a-tions,4:279312,1997.

[16℄ PeterDanzig,KatiaObra zka,and AnantKumar. An Analysis of

Wide-Area Name Server Tra : A study of the Domain Name System. In

1992 ACM SIGCOMM Pro eedings, pages 281292, 1992. http://www.

atarina.us .edu/danzig/dns.ps.Z.

[17℄ PeterB.Danzig,Ri hardS.Hall,andMi healF.S hwartz. A asefor

a- hingleobje tsinsideinternetworks.Te hni alreport,Dept.ofComputer

S ien e,UniversityofColorado,Boulder,1993.

[18℄ L. Fan, P. Cao, J. Almeida, and A. Broder. Summary Ca he : A

s a-lable Wide-Area Web Ca he Sharing Proto ol. In Pro eedings of the

ACM SIGCOMM'98 onferen e, pages 254265,September 1998. http:

//www. s.wis .edu/~ ao/papers/summary a he.html.

[19℄ SyamGadde,JeChase,andMi haelRabinovi h. Dire torystru turesfor

s alable internet a hes. Te hni al Report Te hni al Report CS-1997-18,

DepartmentofComputerS ien e,DukeUniversity,November1997.

[20℄ SyamGadde,JeChase,andMi haelRabinovi h.Redu e,Reuse,Re y le:

An Approa h to Building LargeInternet Ca hes. In The SixthWorkshop

on Hot Topi s on Operating Systems, may 1997. http://www. s.duke.

edu/ari/ risp/.

[21℄ Syam Gadde, Je Chase, and Mi hael Rabinovi h. A taste of rispy

Squid. In Pro eedings of the Workshop on Internet Server Performan e

(WISP'98),June1998. http://www. s.duke.edu/ari/ risp/.

[22℄ D. JamesGemmel, Harri kM.Vin,DilipD. Kandlur, P.Venkat Rangan,

and Lawren e A. Rowe. Multimedia Storage Servers: A Tutorial. IEEE

Computer,pages4049,may1995.

[23℄ Internet a he proto ol spe i ation 1.4, 1994. http://ex alibur.us .

edu/i pdo /i p.html.

[24℄ Eri DeanKatz,Mi helleButler,andRobertM Grath. AS alableHTTP

Server: TheNCSA Prototype. InPro . of the FirstInternational

Confe-ren e on the World-Wide Web. CERN, Geneva (Switzerland), may 1994.

http://www. ern. h/PapersWWW94/ekatz.ps.

[25℄ Ari Luotonen and Kevin Altis. World-wide web proxies. Computer

Networks and ISDN Systems 27, 27(2), 1994. http://www1. ern. h/

PapersWWW94/luotonen.ps.

[26℄ AriLuotonen,HenrikFrystykNielsen,andTimBerners-Lee.Statusofthe

W3Chttpd,June1996. http://www.w3.org/Daemon/Status.html.

[27℄ S ott Mi hel, Khoi Nguyen, Adam Rosenstein, Lixia Zhang, Sally Floyd,

and Van Ja obson. Adaptive Web a hing : towards a new global

a hing ar hite ture. Computer Networks And ISDN Systems,

30(22-23) :21692177, November 1998. http://www.elsevier.nl/ as/tree/

store/ omnet/sub/1998/30/22-23/2052.pdf.

[28℄ D.MuntzandP.Honeyman.Multi-level a hingindistributedlesystems

-or-your a heain'tnothin' but trash. InPro . of the USENIX Winter

the 20thAustralianComputer S ien e Conferen e,Sydney, Australia,Feb

1997.

[30℄ P. Rodriguez,K.W. Ross,and E. W. Biersa k. Distributing

Frequently-ChangingDo umentsintheWeb:Multi astingandHierar hi alCa hing.

In Sele ted papers of the 3rd International a hing workshop, Computer

NetworksandISDNSystems,pages22232245,1998.

[31℄ PabloRodriguez,ChristianSpanner,andErnstW. Biersa k.Web a hing

ar hite tures:hierar hi alanddistributed a hing. dontknowwhere

pu-blished.

[32℄ Alex Rousskov. Wat hdog : Network Computing Review. http://

polygraph.ir a he.net/Wat hdog/net omp.html,1999.

[33℄ Alex Rousskov and Duane Wessels. Ca he digests. In Pro eedings of the

3rdInternationalWWWCa hingWorkshop,June1998.http://www-sor.

inria.fr/mirrors/w w98/31/rousskovnlanr.net.ps.

[34℄ MirjanaSpasojevi ,Mi Bowman,and AlfredSpe tor. Using awide-area

lesystemwithintheworld-wideweb.InSe ondInternationalWorld-Wide

WebConferen e,Chi ago,Illinois,O tober1994.

[35℄ R.Tewari,M.Dahlin,H.M..Vin,andJ.S.Kay.BeyondHierar hies:Design

ConsiderationsforDistributed Ca hing onthe Internet. UTCSTe hni al

reportTR98-04,UnivofTexasatAustin,Austin,TX78712-1188,feb1998.

[36℄ Vinod Valloppollil and Keith W. Ross. Ca he Array Routing

Proto- ol v1.1. Internet Draft, http://ds1.interni .net/internet-drafts/

draft-vinod- arp-v1-03.txt,feb1998.

[37℄ Duane Wessels. Squid internet obje t a he. http://squid.nlanr.net/

Squid,Nov.1998.

[38℄ DuaneWesselsandK.Clay.Appli ationofInternet a heproto ol(ICP),

version2. RFC2187,September1997.

[39℄ Duane Wessels and K. Clay. Internet a he proto ol (ICP), version 2.

RFC2186,September1997.

[40℄ DuaneWesselsandK.Clay.ICPandtheSquidWeb a he.IEEEJournal

on Sele ted Areas in Communi ation, 16(3) :345357, April 1998. http:

//www.ir a he.net/~wessels/Papers/i p-squid.ps.gz.

[41℄ GregoryYerxa. SpeedyPerforman e,Ro k-BottomPri e PutSquid

Free-wareonTop. NetworkComputing, pages8491,may1999.

[42℄ Lixia Zhang,Sally Floyd, and Van Ja obson. AdaptiveWeb a hing. In

Pro eedings of the1997 NLANRWeb Ca he Workshop,June1997. http:

//ir a he.nlanr.net/Ca he/Workshop97/Papers/Floyd/floyd.ps.

[43℄ H.Zhu,T.Yang,Q.Zheng,D. Watson,O.H.Ibarra,andT.Smith.

Adap-tativeloadsharing for lustered digitallibrary servers. Te hni al report,