Flux Applicatifs HTTP

Ecole d’Ingénieurs de Genève HES-SO Session 2001
Laboratoire de transmission de données
Flux Applicatifs
Cache Web
ISA Server 2000
LDAP
GAIO Pascal
Filière Télécommunication
Professeur de diplôme : M. Eric Jenny

Travail en collaboration avec M. Laurent Dutheil de Pictet&Cie
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Introduction
Ce mémoire est divisé en trois parties bien distinctes.
Les chapitre 1,2 et 3, traiteront du cache Web standard, c’est-à-dire lorsque n’importe
qui se connecte sur Internet. Le but sera de déterminer quelles données seront stockées
chez le client et ce que le serveur Web garde comme informations après son passage.
Nous regarderons diverses commandes http qui modifient le comportement du cache
du côté client.
Dans une seconde partie, j’utiliserai un logiciel appelé ISA Server 2000 (Internet
Security and Acceleration Server 2000) en tant que proxy et serveur de cache.
Ainsi je regarderai ce qu’apporte de plus d’ajouter un proxy entre un client et un
serveur, par rapport à une connexion directe entre les deux. L’installation d’un logiciel
comme ISA Server, devrait théoriquement accélérer les accès aux sites Web. Mais est-
ce vraiment un gain important ou est-ce simplement une mascarade comme la plupart
des logiciels qui se disent accélérateurs d’accès aux sites alors qu’ils ne font que de
charger en cache les liens sur les pages que l’on visite pendant que l’utilisateur ne fait
rien ? Ce logiciel ISA Server 2000 fonctionne-t-il sur le même principe ? Nous
démontrerons dans les chapitres 4,5 et 6 comment ISA Server 2000 fait pour accélérer
les accès aux pages sur Internet.
Dans une troisième partie, nous allons regarder les possibilités des annuaires LDAP.
Pour cela, il va falloir étudier comment construire un annuaire et par la suite, étudier
les principes qu’offre le protocole LDAP (chapitre 7 et 8). Ensuite nous allons étudier
les 2 principales applications des annuaires LDAP. Soit les références sur d’autres
serveurs (referall chapitre 9) et la copie de base de données (replication chapitre 10).
Dans une dernière étape consacrée au protocole LDAP, j’utiliserai un Firewall Check
Point afin de gérer des accès à un serveur Web. Ces accès seront définis sur un
annuaire LDAP. Pour mon étude, j’ai utilisé le serveur LDAP iPlanet Directory Server
5.0 pour la gestion de l’annuaire.
Flux Applicatif 2
Remerciements
A mes parents, qui m’ont soutenu tout au long de mon diplôme.
A M.Litzistorf, qui ma permis de faire ce diplôme dans son laboratoire.
A M.Dutheil, qui m’a indiqué les points importants à étudier lors de notre entretien.
A M.Jenny, professeur de diplôme qui m’a assisté durant ces trois mois.
A M.Garcia, qui m’a aidé lors de la mise en place des annuaires LDAP.
A tous mes collègues de diplôme pour leur aide apportée durant ces trois mois.
A tous ceux avec qui j’ai pu discuter et qui m’ont apporté leurs idées.
Convention Typographique
Tous les textes en italique sont des mots en Anglais.
Tous les textes soulignés sont des liens vers des sites
Flux Applicatif 3
Table des Matières
Chapitre 1 : Le cache Web.......................................................................... 6

1.1 Qu’est-ce que le cache ..............................................................................................................................................7
1.1.1 Les recherches d’informations..........................................................................................................................7
1.1.2 Les programmes à disposition..........................................................................................................................8
1.2 Le cache vu par le client...........................................................................................................................................9
1.2.1 Localisation du cache.........................................................................................................................................9
1.2.2 Suppression du cache....................................................................................................................................... 11
1.2.3 L’historique........................................................................................................................................................ 12
1.2.4 Le menu déroulant ............................................................................................................................................ 13
1.3 Que se passe-t-il réellement lorsque j’accède à un site sur Internet ? ............................................................ 16
1.4 Différence entre une connexion au site avec cache ou sans cache. ................................................................ 19
1.5 Rafraîchissement des pages ................................................................................................................................... 22
1.6 Voir le cache des autres utilisateurs de la même machine ............................................................................... 24
Chapitre 2 : Gestion du cache d’Internet Explorer.................................... 27

2.1 Option Never ............................................................................................................................................................ 28
2.2 L’option Automatically........................................................................................................................................... 29
2.3 L’option Every time you start internet Explorer ................................................................................................ 32
2.4 L’option Every visit to the page ............................................................................................................................ 35
2.5 Résumé de toutes les options d’ Internet Explorer ............................................................................................. 36
Chapitre 3 : Le cache vu par le serveur Web............................................ 37

3.1 Installation du serveur Web................................................................................................................................... 37
3.2 Commandes HTTP.................................................................................................................................................. 39
3.3 L’onglet HTTP Headers ......................................................................................................................................... 40
3.4 Principales commandes HTTP.............................................................................................................................. 41
3.4.1 Commande no-cache ........................................................................................................................................ 42
3.4.2 Commande max-age ......................................................................................................................................... 43
3.5 Les fichiers LOG ............................................................................................................................................... 44
3.6 Conclusion ................................................................................................................................................................ 45
Chapitre 4 : ISA Server Première Partie .................................................. 46

4.1 Configuration requise............................................................................................................................................. 46
4.2 Le mode cache................................................................................................................................................... 47
4.3 Le mode Firewall .................................................................................................................................................... 47
4.4 Le mode Integrated ................................................................................................................................................. 48
4.5 Choix décidé pour l’installation............................................................................................................................ 48
4.6 Différents modes de mise en cache ...................................................................................................................... 49
4.6.1 http Caching....................................................................................................................................................... 50
4.6.2 Active Caching................................................................................................................................................... 51
4.7 HTTP 1.0 VS HTTP 1.1......................................................................................................................................... 52
Flux Applicatif 4
Chapitre 5 : ISA Server Deuxième Partie ................................................. 54

5.1 Introduction.............................................................................................................................................................. 54
5.2 Fonctionnement du Serveur ISA ........................................................................................................................... 55
5.3 Test avec un seul client et une carte Ethernet sur ISA ...................................................................................... 56
5.4 Mode http Header Frequently............................................................................................................................... 57
5.4.1 Commande max-age envoyée par le serveur Web....................................................................................... 57
5.4.2 Cache présent valide sur le client et sur ISA avec rafraîchissement F5................................................... 58
5.4.3 Cas où le serveur Web envoi un no-cache ..................................................................................................... 60
5.4.4 Cache présent sur le client et sur ISA avec rafraîchissement ENTER...................................................... 63
5.5 Mode http Header Normally ................................................................................................................................ 63
5.5.1 Aucun cache présent sur le client mais présent sur ISA............................................................................. 64
5.5.2 Cache présent sur le client et présent sur ISA.............................................................................................. 65
5.5.3 Les autres cas ..................................................................................................................................................... 66
5.5.4 Différences entre les modes http Caching .................................................................................................... 67
5.6 Mode Active Caching ............................................................................................................................................ 68
5.7 Ajout d’un deuxième client .................................................................................................................................. 69
5.8 Fonctionnement du serveur ISA avec 2 cartes Ethernet .................................................................................. 70
5.9 Server Web Down................................................................................................................................................... 71
5.10 Les principales commandes HHTP rencontrées .......................................................................................... 72
5.11 Les fichiers LOG ............................................................................................................................................... 73
5.12 Qu’a-t-on gagné avec ISA ? ............................................................................................................................ 74
Chapitre 6 : Reverse Proxy........................................................................ 75

6.1 Installation de ISA Server en mode Reverse Proxy........................................................................................... 76
6.2 Tests en mode Reverse Proxy................................................................................................................................ 78
6.2.2 Connexion de deux clients sur le serveur Web............................................................................................ 80
6.3 Conclusion ................................................................................................................................................................ 81
Chapitre 7 : LDAP Principes .................................................................... 82

7.1 Les concepts de LDAP ........................................................................................................................................... 83
7.2 Les principes de LDAP .......................................................................................................................................... 83
7.3 Les annuaires LDAP ............................................................................................................................................... 85
7.4 Les choix effectués.................................................................................................................................................. 86
7.4.1 Installation du serveur iPlanet......................................................................................................................... 87
7.4.2 Installation du client ......................................................................................................................................... 87
7.5 Création de l’annuaire LDAP................................................................................................................................ 87
7.5.1 Architecture Annuaire EIG ............................................................................................................................. 88
7.5.2 Architecture Annuaire Elèves ......................................................................................................................... 88
7.5.3 Architecture Annuaire Professeurs ................................................................................................................ 89
7.5.4 Création de membres ........................................................................................................................................ 89
7.6 Conclusion ................................................................................................................................................................ 91
Chapitre 8 : LDAP Protocole .................................................................... 92

8.1 Structure de la trame du protocole LDAP ........................................................................................................... 93
8.1.1 Le champ Type.................................................................................................................................................. 93
8.1.2 Le champ Length............................................................................................................................................... 95
8.1.3 Le champ Content............................................................................................................................................. 96
8.2 Etude détaillée du paquet Search Response........................................................................................................ 97
8.3 Accès à un annuaire .............................................................................................................................................. 100
8.4 Recherches de données dans l’annuaire............................................................................................................ 101
8.5 Ajout d’un utilisateur............................................................................................................................................ 102
8.6 Delete d’une branche de l’annuaire .................................................................................................................... 103
8.7 Server LDAP Down............................................................................................................................................... 104
8.8 Connexion avec Size Limit limité....................................................................................................................... 105
8.9 Déconnexion de l’annuaire .................................................................................................................................. 107
8.10 Conclusion......................................................................................................................................................... 107
Flux Applicatif 5
Chapitre 9 : LDAP Referral .................................................................... 108

9.1 Syntaxe d’un Referral........................................................................................................................................... 109
9.2 Les types de referrals ........................................................................................................................................... 109
9.3 Comment ajouter un referral avec iPlanet ........................................................................................................ 111
9.4 Etude d’un referral au niveau du protocole...................................................................................................... 111
9.5 Conclusion......................................................................................................................................................... 112
Chapitre 10 : LDAP Réplication ............................................................. 113

10.1 Le fichier LDIF................................................................................................................................................. 113
10.2 Réplication entre serveur ................................................................................................................................ 114
10.2.1 La réplication totale (Méthode 1) .................................................................................................................. 114
10.3 Etude de protocole de la réplication totale................................................................................................... 115
10.4 Etude de protocole de la réplication des modifications ............................................................................. 120
10.5 Conclusion......................................................................................................................................................... 123
Chapitre 11 : Application LDAP............................................................. 124

11.1 Création d’un compte utilisateur ................................................................................................................... 125
11.2 Accès au serveur Web par le client ............................................................................................................... 126
11.3 Analyse d’une connexion sur le serveur Web............................................................................................. 127
11.4 Connexion avec password erroné.................................................................................................................. 131
11.5 Connexion avec un login erroné .................................................................................................................... 132
11.6 Reconnexion au serveur Web ......................................................................................................................... 133
11.7 Conclusion......................................................................................................................................................... 133
Chapitre 12 : Bibliographie..................................................................... 134
Flux Applicatif 6
Chapitre 1 : Le cache Web
1.1 Qu’est-ce que le cache
Le cache (aussi appelé antémémoire) est l'espace sur le disque dur et dans la mémoire
vive (RAM) de notre ordinateur où notre navigateur enregistre les copies des pages
Web consultées récemment. Le navigateur se sert du cache comme mémoire à court
terme. Au lieu de télécharger une image d'un site que l’on vient de visiter, il charge
l'image enregistrée du cache (chapitre 1.2.1), ce qui accélère la navigation.
Le cache est donc un système conçu pour améliorer le rendement de l’utilisation
d'Internet en réduisant les accès au réseau.
1.1.1 Les recherches d’informations
Avant de commencer à étudier les diverses fonctionnalités des caches, j’ai essayé de
trouver de la documentation sur le sujet. Cependant, je savais que cela allait être
difficile du fait qu’Internet Explorer 5.0 / 6.0 est un produit de la gamme Microsoft et
la documentation que j’allais trouver serait maigre (Microsoft gardant certaines
données secrètes à l’utilisateur). Après plusieurs jours de recherches, les informations
collectées étaient très basiques. Les renseignements qui en ressortent sont : « comment
vider le cache », « limiter la taille du cache » ou « effacer les cookies », mais rien ne
montre à quels endroits sont stockés les informations du cache mis à part ceux visibles
par tout le monde à travers l’explorateur Windows (Internet Temporary Files par
exemple).
C’est donc par une méthode de scrutation des dossiers et des registres que j’ai
recherché les emplacements de ces caches. Cette méthode n’est cependant pas la
meilleure parce qu’elle est longue et pénible.
C’est pourquoi certains logiciels ont été créés afin de faciliter la tâches des utilisateurs.
Leurs caractéristiques seront énoncées au chapitre 1.1.2.
Les sites où les informations sont les meilleures à ce sujet restent :

http://www.microsoft.com/
http://technet.com
http://www.msdn.microsoft.com/
www.crackinguniversity2000.it (qui propose une série d’informations importantes et
permet aussi d’accéder à des livres sur Internet)
http://www.mnot.net/cache_docs (qui propose un document intéressant pour une
première étude du cache)
Une liste plus complète se trouve dans la bibliographie (chapitre 12)
Flux Applicatif 7
1.1.2 Les programmes à disposition
Afin de nous aider à mieux comprendre les phénomènes de cache sur les machines
possédant Internet Explorer 5.0 (Netscape n’étant pas traité dans mon diplôme), nous
avons à disposition plusieurs outils trouvés sur Internet afin de trier les informations
du cache. Au niveau du cache, il n’y a pas de différences majeures entre Internet
Explorer 5.0 et ses versions supérieures.
En effet, certains logiciels nous permettent de voir directement les cookies qui sont
présents dans notre cache tandis que d’autres nous permettent uniquement de
visualiser les fichiers qui s’y trouvent.
J’ai donc téléchargé plusieurs de ces logiciels qui me semblaient intéressants et les ai
comparés.
Voici donc la liste des logiciels trouvés et une appréciation sur leurs caractéristiques.
Nom du Adresse du site

programme
Internet http://www.icmasterdata.com/ice.html
Cache
Explorer
Commentaire : Le plus complet de tous. Il nous permet de voir en même temps les
noms des sites visités, les cookies, l’emplacement sur le disque et les dates d’accès
sur un même écran.
UnMozify http://www.evolve.co.uk/unmozify/
Commentaire : intéressant par le fait qu’il nous permet de visualiser toutes les pages
consultées. Il nous permet aussi de voir l’heure d’accès aux pages d’un site et de
mettre en archive les pages consultées. Ainsi on pourra consulter des pages d’un site
même après avoir vidé le cache.
Cache http://www.webknacks.com/download.htm
Auditor
Commentaire : Version Shareware. Pas très utile à moins de l’utiliser pour trier les
caches en fonctions des types de données stockées (son, image, text, etc…)
Cache Sentry http://www.mindspring.com/~dpoch/enigmatic/cachesentry.html

Commentaire : Peu intéressant. Possibilité d’effacer les données en cache, y compris
les cookies (option ajoutée dans Internet Explorer 6.0). Les fichiers que l’on doit
enlever sont paramétrables suivant des critères de taille ou de temps d’inactivité dans
le cache.
Rappel : Un cookie est un petit fichier texte envoyé par un serveur sur notre
ordinateur lors de la connexion sur le site. Ce petit fichier enregistre un
certain nombre d'informations du client, qui pourront être relues et
modifiées ultérieurement si notre ordinateur se connecte à nouveau au
serveur qui a créé le cookie en question. Il sert en quelque sorte à
identifier l’ordinateur qui se connecte au site.
Flux Applicatif 8
1.2 Le cache vu par le client
Dans ce chapitre, je vais montrer ce qui se passe au niveau du cache du côté client.
En effet, lorsqu’un client se connecte sur un site en tapant l’url correspondant, le
serveur Web va envoyer certaines informations concernant la page à afficher outre la
page en question. Ces données vont être stockées sur le disque dur du client.
1.2.1 Localisation du cache
Afin de pouvoir localiser le contenu du cache du côté client, il faut permettre à

l’explorateur Windows, d’afficher les fichiers systèmes ainsi que les fichiers cachés
qui se trouvent sur le disque.
Pour cela, il faut aller sous Tools -> Folder options -> View -> Files and Folders et
cocher Show hidden files and folders et enlever la croix sur Hide protected operation
system files.
Lorsque le client se reconnecte sur une page qui se trouve en cache sur son disque dur,
il faut que la machine sache où se trouvent ces données.
En parcourant les répertoires, on voit que ces données sont stockées sous :
C:/Documents and Settings/Userx/Local Settings/Temporary Internet Files
Userx est l’administrator dans mon cas . Sinon c’est le nom de l’utilisateur en cours
qui est présent.
Flux Applicatif 9
Cependant ce chemin peut être modifié. En effet, lorsque l’on accède aux propriétés
d’Internet Explorer, nous avons plusieurs possibilités, dont une est celle qui concerne
le chemin où seront stockés les données.
(dans la barre de menu cliquer sur tools et Internet Options)
En cliquant sur settings, on peut modifier l’emplacement du fichier où seront stockées

les données du cache.
L’utilisateur peut en faisant la même opération, visualiser les fichiers stockés dans le
cache ou bien modifier les paramètres de mise en cache (voir chapitre 2).
Dans mon mémoire, je ne parlerai que du cache au niveau http. Cependant, il faut
savoir qu’au niveau du cache ftp, le comportement est identique à celui http. Lors de
l’étude LDAP, j’ai constaté que les données transmises au niveau de la base de
données n’étaient pas stockées chez le client.
J’en déduis que pour le protocole http et ftp le fonctionnement du cache est
sensiblement le même, tandis que pour le protocole LDAP, il n’y a pas de mise en
cache des données.
Flux Applicatif 10
1.2.2 Suppression du cache
Les données qui se trouvent dans ce répertoire Temporary Internet Files, peuvent être
supprimées. Si le cache est supprimé, cela aura pour conséquence le téléchargement
complet des pages visitées auparavant et dont les fichiers ont été effacés par cette
opération.
Pour effacer le contenu du cache, il suffit d’exécuter la procédure suivante.
Une fois cliqué sur Delete Files, il

suffit de cliquer sur ok. Si l’on
active l’option Delete all offline
content, plus aucune page ne
pourra être vue même celles qui
étaient visibles offline.
Cette opération a pour effet, de vider le cache. La comparaison ci-dessous montre bien
que les fichiers du cache ont été vidés.
Avant Après
Flux Applicatif 11
Cependant, comme on peut le constater, tous les fichiers textes, images, html etc…
correspondant aux pages où l’on s’est connecté se sont effacés à l’exception des
cookies.
Les cookies ici présents doivent malheureusement être effacés manuellement.

Dans la version 6.0 d’Internet Explorer, il y a une option supplémentaire qui nous
permet d’effacer les cookies automatiquement, de la même manière que l’on efface le
contenu du cache.
Il existe pourtant encore une trace des passages sur les sites après avoir tout effacé
dans ce répertoire. En effet, à chaque fois que l’on visite un url, un historique des
pages visitées est remis à jour.
1.2.3 L’historique
L’historique est présent afin de stocker les pages visitées lors des anciennes sessions.
Il permet non seulement de savoir l’url tapé mais aussi sur quelles pages du site et à
quelle heure, l’utilisateur s’y est connecté. De plus il nous permet de savoir quelles
sont les recherches qui ont été effectuées sur un moteur de recherche. (www.google.ch
par exemple)
Le répertoire en question se trouve sous :

C:\Documents and Settings\userx\Local Settings\History
Userx est l’administrator dans mon cas . Sinon c’est le nom de l’utilisateur en cours
qui est présent.
Voilà ce que l’on peut y voir :
En cliquant sur l’icône History, il

apparaît une fenêtre à gauche dans
laquelle est stockée l’historique des
sites visités.
A l’intérieur de ce répertoire, il
y a pour chaque jour de l’année
un sous répertoire afin de savoir à
quelle période les sites ont été
visités. Le nombre de jours de
stockage est configurable dans les
options d’Internet Explorer. Pour
effacer l’historique, il suffit de cliquer
sur Clear History dans la fenêtre
« Internet Options » (voir figure de la page précédente)
Flux Applicatif 12
Je peux donc aller voir pour chaque jour, les pages consultées pour chaque utilisateur.
Lorsque l’on accède à un site, ce répertoire est donc remis à jour.

Ce n’est cependant pas le seul a être mis à jour en ce qui concerne l’historique.
En effet, lorsque l’on navigue sur Internet, nous avons un menu déroulant qui nous
facilite la tache, afin de ne pas taper entièrement l’url à chaque fois que l’on veut
accéder à une page.
1.2.4 Le menu déroulant
Ce menu déroulant est la copie conforme de l’historique et est stocké dans les registres
Windows contrairement à l’historique, qui lui est stocké sur le disque dur de
l’utilisateur. Ces registres sont accessibles en faisant
start -> run et en tapant regedt32.
Dans les registres de Windows, ils se trouvent sous le registre

HKEY_CURRENT_USER on Local Machine
et sous HKEY_CURRENT_USER -> Software -> Microsoft -> Internet Explorer ->
TypedURLs
Flux Applicatif 13
Les deux listes

Sont identiques
Une deuxième option existe dans ce menu déroulant. Cela s’appelle la saisie semi-
automatique. Son principe consiste à taper plusieurs lettres et les sites visités avec ces
premières lettres apparaissent dans le menu.
Contrairement au cas d’avant, ces données sont directement issues de l’historique. En

effet, lorsque j’accède à celui-ci, je vois les urls où je me suis connecté ainsi que les
pages du même site que j’ai visité.
Ce sont ces pages qui s’affichent lorsque je commence à taper le premières lettres,
dans le menu déroulant.
En résumé, les données issues de la saisie semi-automatique sont tirées de l’historique
tandis que les données du menu déroulant sont tirées des registres de Windows.
Flux Applicatif 14
Les deux urls correspondent exactement. Il en est de même pour tous les autres.
Ces paramètres de la saisie semi-automatique, peuvent être modifié dans Tools ->
Internet options -> Content -> Personnal informations -> AutoComplete
Flux Applicatif 15
1.3 Que se passe -t-il réellement lorsque j’accède à un site sur

Internet ?
Ici je résumerai les chapitres vu précédemment en faisant une démonstration de ce qui

se passe lorsque je me connecte sur un site.
Je ne traiterai pas de l’analyse de protocole qui sera vu dans les chapitres suivants mais
simplement aux emplacements du cache après avoir visité une page.
Prenons l’exemple d’une connexion au site eig.unige.ch

Je fais l’hypothèse que les caches, l’historique et les registres soient vides.
Dans Internet Explorer, je tape l’adresse eig.unige.ch et j’obtiens ma page.
L’étude de protocole montrera comment les paquets sont transmis entre le client et le serveur
Web. Dans l’état des choses, on peut simplement dire qu’un échange de données au niveau
http est présent.
Get Request
Response (Data)
Client Server Web
Flux Applicatif 16
Mais voici réellement ce qui c’est passé sans que l’on s’en aperçoive.
Dans l’historique, apparaît la page que j’ai visité.

Donc dans today j’aurais ma page www.eig.unige.ch
J’aurai si j’ouvre le répertoire, toutes les pages sous-jacentes du site.
Je vois donc la première page de mon site car je n’ai été que sur celle-ci.
Ensuite, dans le Temporary Internet Files, je trouverai les fichiers chargés lors de
l’accès à la page.
Œ Œ • Ž •
Œ Avec la date d’expiration des fichiers dans le cache (sert à tester la validité du fichier
local)
• Avec la date de la dernière modification de la page (sert au serveur à savoir s’il y a eu
modification sur la page entre la dernière connexion et l’heure courante)
Ž Avec la date du dernier accès fait par le client
• Avec la date de la dernière vérification faite par le client sur la page
Flux Applicatif 17
Un dernier endroit où se stockent des informations lorsque j’accède à un site, se trouve

dans les registres de Windows.
Lorsque je vais voir le registre concerné, je ne voit rien. Il est vide.
En effet, il faut savoir que les données des registres se modifient uniquement lorsque
la page en question est quittée. Il faut que l’on ferme Internet Explorer pour que les
valeurs soient affectées. Le simple fait de quitter le site et accéder à une autre page ne
suffit pas.
C’est donc uniquement lorsque je quitterai Internet Explorer que mes registres seront
mis à jour.
Je ferme donc simplement la fenêtre du browser et le site www.eig.unige.ch apparaît
dans le registre.
Flux Applicatif 18
1.4 Différence entre une connexion au site avec cache ou sans

cache.
A première vue, il est normal de penser que lorsque je me connecte à un site avec les
fichiers de la page dans mon cache, l’affichage de celle-ci se fasse plus rapidement du
fait qu’elle est chargée localement. Cependant à la suite de plusieurs essais, il s’est
avéré que cela n’était pas toujours le cas.
En effet il existe encore des requêtes entre le client et le serveur Web afin de vérifier si
des modifications ont été faites sur le site.
De plus ces temps de réponses sont sensibles à la charge sur le réseau. Il se peut que
notre page se trouve déjà en cache et que celle-ci mette plus de temps à se charger que
si l’on accède au site pour la première fois car la réponse du serveur Web est tardive.
C’est pourquoi dans les options d’Internet Explorer, nous pouvons sélectionner divers
modes de chargement de la page en fonction du cache. Ceux-ci seront détaillés dans le
chapitre 2.
Les tests effectués, concernent les charges engendrées sur le réseau lorsque le client
possède ou non le cache et le temps que l’on met pour charger la page entièrement.
Cette partie consistera à se connecter sur le site www.microsoft.com
Tests dans le cas où aucun cache n’est présent sur le disque.

Essai N° Nombres de Bytes envoyés Bytes reçus Bytes échangés Temps de
paquets chargement
1 338 19641 226965 246606 12.00 sec
2 336 18674 229141 247815 13.16 sec
3 296 17376 199843 217219 4.04 sec
4 302 17947 200429 218376 4.45 sec
5 303 18196 200052 218248 3.61 sec
6 292 16509 199843 216352 4.43 sec
Bytes envoyés = client -> serveur et bytes reçus = client <- serveur
Tests dans le cas où le cache est présent sur la machine de l’utilisateur

Remarque : Dans le cas où la date d’expiration du fichier est toujours valide dans le
cache (test du champ Expires voir chapitre 1.3), la machine ne fait
aucune requête vers le site en question et charge tout localement. Le
temps de chargement ainsi que la charge sur le réseau sera nulle. La
validité des fichiers est définie par le programmeur du site.
Flux Applicatif 19
Date d’expiration encore valide :

paquets chargement
n 0 0 0 0 0
Date d’expiration dépassée :

paquets chargement
1 113 14598 29936 44534 7.17 sec
2 118 15783 30163 45946 5.89 sec
3 105 14422 25076 39498 3.41 sec
4 104 14530 20624 35154 4.18 sec
5 120 15249 30167 45416 3.33 sec
6 81 5361 14380 19741 5.95 sec
Nous voyons très bien ici, que le cache joue un rôle important dans le nombre de bytes
échangés entre le client et le serveur.
En regardant plus attentivement, les échanges entre le client et le serveur Web, on
s’aperçoit que lors du premier accès (sans cache du côté client), le serveur Web dit au
client de stocker en cache les données transmises. Lors d’un prochain accès, suivant le
résultat du test du champ Expires, les données seront chargées du cache ou non.
Voici un organigramme qui montre comment est géré le cache du côté client.
Fichiers stockés dans

le cache expirés ?
www.microsoft.com
Oui. Echange de données avec le serveur Web
Server Web
Non. Fichiers
encore valides
Alors chargement
de la page depuis
le cache
Flux Applicatif 20
Une fois les premiers tests effectués, nous pouvons voir que si le cache est présent ou
non sur le disque cela change quelques données.
En effet, on peut voir que les bytes échangés sont réduit de 80 % si la page est
présente dans le cache.
Cette réduction est due en partie au client avec un gain de 20% sur les bytes envoyés et
surtout grâce au serveur qui a un gain de 85% environ sur ses bytes envoyés. Suivant
les pages sur lesquelles on se connecte, ces valeurs vont varier. Par exemple, lors
d’une connexion au site www.hotmail.com, le gain sur les bytes échangés est de 65%
(75% client, 60% serveur).
Gain total Gain par Gain par

Site testé
de bytes le client le serveur
www.hotmail.com 80 % 20 % 85 %
www.microsoft.com 65 % 75 % 60 %
Cette variation dépend de la quantité des données à transmettre. En effet, plus cette
quantité est importante, plus le nombre de bytes envoyés avec un cache présent chez
l’utilisateur sera réduit. Ainsi le gain sera augmenté.
Je voulais faire une étude plus réaliste du gain en temps, mais le réseau « Internet » de
l’école étant quasiment identique en prestation que le réseau « Intranet » , je ne
voyais aucune différence au niveau d’un éventuel gain de temps. C’est pourquoi je
n’ai pas été plus loin dans cette étude.
Cependant, malgré le gain de bytes échangés, le temps d’accès à la page n’en n’est pas
réduit. En effet, ce temps de réponse est en fonction de la charge du réseau, qui elle est
très variable. Pour le site de Microsoft, nous n’avons aucun gain de temps malgré un
grand gain de bytes échangés. Au contraire lors de l’accès au site de Hotmail, le temps
de réponse est réduit de moitié. Ceci prouve bien qu’une étude sur le temps de réponse
ne peut pas être juste dans le cas où l’on accède à des sites sur Internet.
Flux Applicatif 21
1.5 Rafraîchissement des pages
Lorsque l’on a déjà la page d’un site dans le cache, nous pouvons y accéder grâce à
l’historique (chargement toujours effectué depuis le cache), en tapant soit l’adresse
(chargement de la page dépendant des dates d’expirations) ou lorsque l’on y est déjà,
faire un refresh de la page pour voir si des modifications ont été faites sur celle-ci.
Cependant, le comportement du cache n’est pas le même dans tout les cas.
En effet, lorsque je suis sur une page et je fais un refresh avec la touche F5, le client va
faire une requête au serveur Web pour savoir si des modifications sont intervenues
depuis son dernier accès.
Les dates d’expiration dans ce cas n’ont plus lieu d’être.
L’échange sera du type :
Cache Refresh avec F5

client Pas de
requête
Get Request
If modified since (Last Modified)
Server Web
Response OK ou Not modified
Client
Une requête sera automatiquement faite sur le serveur pour savoir si une modification
est intervenue.
La réponse retournée par le serveur sera soit Not modified (pas de modification sur le
serveur Web) et la page sera chargée depuis le cache du client, soit OK (modification
sur le serveur Web entre le dernier accès et l’heure courante) et les nouvelles données
seront transmises par le serveur Web.
Un deuxième moyen de rafraîchir une page est de retaper l’url en question. On peut
même penser à quitter Internet Explorer et revenir. C’est une forme de
rafraîchissement.
Dans ce cas, les dates de validité des fichiers sont nécessaires. En effet, lorsque le
client possède déjà la page dans son cache et que celui-ci entre un url et presse
ENTER, alors ces dates vont être testées. Si elles sont encore valides, la page sera
chargée du cache sinon une requête sera faite au serveur.
Flux Applicatif 22
L’échange sera du type :
Refresh avec ENTER
Client
Les fichiers stockés
dans le cache sont-ils
encore valides ?
Test du champ Expires
Oui
Get Request
Non If modified since (Last Modified)
Cache
client Response OK ou Not modified
Server Web
Dans les deux cas énoncés précédemment, si la page n’a pas été modifiée sur le
serveur Web, aucune donnée utile ne sera renvoyée au client. Cependant il existe un
moyen de recharger la page entièrement et que toutes les données soient retransmises
par le serveur Web même si aucune modification n’a eu lieu sur celui-ci. Il suffit de
taper la touche Shift et F5.
Cache
Refresh avec Shift + F5
client Pas de
requêtes
Get Request
Pragma : no-cache
Response OK Server Web

Client Pragma : no-cache
La réponse du serveur Web sera ici toujours OK.

On voit que le client envoi un paramètre pragma : no-cache.
Cette commande est présente, afin que le browser et le serveur Web sachent qu’il ne
faut pas tenir compte du cache de l‘utilisateur. Il faut considérer qu’aucun cache (no-
cache) n’est présent du côté client même si ce n’est pas le cas.
Flux Applicatif 23
1.6 Voir le cache des autres utilisateurs de la même machine
Une question vient à l’esprit lorsque plusieurs utilisateurs sont sur une même machine
à des moments différents. Est-ce qu’il se peut que l’un bénéficie du cache de l’autre ?
Pour répondre à cette question, j’ai fait un test en me connectant au site
www.hotmail.com et j’ai testé la charge du réseau lorsque le cache est présent ou non
sur le disque dur de la machine, mais à un autre endroit que dans le cache de
l’utilisateur qui à la session courante. Par exemple, dans le cache d’un autre utilisateur.
Tests dans le cas où le cache n’est pas présent dans le répertoire de

l’administrateur et l’on se connecte sans cache chez le user
Essai N° Nombres Bytes envoyés Bytes Bytes échangés Temps de
de paquets reçus chargement
1 146 6296 33476 39772 3.45 sec
2 143 6269 33314 39610 3.42 sec
3 150 6582 33422 40004 12.75 sec
4 146 6673 33366 40039 4.51 sec
5 149 6458 34008 40466 7.35 sec
6 147 6350 33477 39827 3.48 sec
Tests dans le cas où le cache est présent dans le répertoire de

l’administrateur et l’on se connecte sans cache chez le user
Essai N° Nombres Bytes envoyés Bytes Bytes échangés Temps de
de paquets reçus chargement
1 150 6491 33460 39951 3.87 sec
2 157 7743 33471 41214 16.75 sec
3 159 7205 33576 40781 14.05 sec
4 158 7110 34619 41736 9.36 sec
5 154 6685 33514 40199 3.21 sec
6 160 7515 33983 41498 7.46 sec
A l’aide de ces mesures on se rend bien compte qu’un autre utilisateur qui possède
déjà le cache de la page accédée, n’affecte en rien les performances de l’utilisateur
avec la session courante.
De ce fait l’utilisateur connecté ne fera aucun gain de temps ni de charge sur le réseau
si un autre utilisateur local possède dans son cache la page demandée.
J’en conclus donc que le cache soit présent ou non chez un autre utilisateur connecté
sur la même machine ne change en rien dans le cache de l’autre utilisateur. Ils sont
donc complètement indépendants.
Afin de vérifier cela, je vais essayer de me connecter sur un utilisateur existant et de

voir son cache depuis le compte administrateur (sur la même machine).
Flux Applicatif 24
Lorsque je me connecte sur la machine avec le compte administrateur, j’ai la

possibilité de voir tous les fichiers des utilisateurs sans restriction aucune.
C’est pourquoi, normalement, lorsque je vais voir sous C:/Documents and
Settings/Administrator/Local Settings/Temporary Internet Files, je dois voir mes
fichiers stockés dans le cache.
En outre lorsque je vais voir sous C:/Documents and Settings/Userx/Local
Settings/Temporary Internet Files, je dois voir les fichiers stockés dans le cache du
Userx.
Cache de l’administrateur Cache de UserX
En regardant bien les deux caches, on constate qu’ils sont identiques.
En réalité, le répertoire C:/Documents and Settings/userx/Local Settings/Temporary

Internet Files est remapé vers le répertoire identique mais qui appartient au compte
courant.
Ceci est certainement fait pour des questions de confidentialité. De ce fait même en
ayant les droits ou en s’étant procuré les droits administrateur, il est impossible de voir
le cache d’un autre utilisateur.
Pour mieux comprendre ce phénomène, j’ai fait une représentation graphique des
différents cas présentés tout au long de ce sous-chapitre.
Cache user X Cache user Y Cache user Z
Si j’essaye depuis le compte

Machine A administrateur de visualiser le
cache d’un utilisateur, je verrai
toujours le cache du compte
courant
Connexion Administrateur Cache Administrateur
Flux Applicatif 25
De plus, j’ai essayé de me connecter depuis une machine distante sur une machine
dont je connaissais le mot de passe de l’administrateur et j’ai regardé le cache d’un
utilisateur.
J’ai remarqué que le même phénomène se produisait.
Soit que je voyais le cache de la personne qui était connectée en ce moment sur la
machine sur laquelle est effectuée la requête.
Machine A Machine B
Connexion à distance
Compte administrateur
Caches identiques, on a une
image du cache de la machine A

Cache Cache
retourné visualisé
(Local) (Distant)
En outre j’ai essayé de partager le répertoire Internet Temporary Files où est stocké le
cache d’un utilisateur. Lorsque je me connecte à distance sur cet utilisateur pour
visualiser le contenu de ce fichier, j’obtiens le même résultat que précédemment. Soit
que le répertoire est remapé et c’est le contenu de ma machine qui s’affiche.
A la suite de ces diverses études, j’en conclu finalement que le cache est indépendant
entre chaque utilisateur et en plus, un utilisateur ou administrateur n’a pas le droit de
voir le cache d’un autre.
Cependant, ces résultats me surprennent. En effet, j’imagine mal dans le réseau d’une
entreprise, qu’aucune personne ne puisse voir le cache de la personne connectée sur
une machine.
De ce fait je pense que l’on peut changer ces caractéristiques mais étant donné
qu’aucune documentation à ce sujet n’est présente sous la moindre forme sur Internet
et que sans doute Microsoft garde ses nouvelles plus ou moins secrètes, je ne
m’attarderai pas plus sur ce problème. De plus cela ne nous apprendrai pas grand
chose sur le comportement du cache. C’est pourquoi je laisserai cette étude en l’état.
(M.Dutheil étant du même avis).
Flux Applicatif 26
Chapitre 2 : Gestion du cache d’Internet Explorer
Lorsque l’on se connecte à un site pour la première fois, les documents sont mis en cache
chez le client. Par la suite les données seront chargées entièrement ou partiellement en
fonction des paramètres dans le cache
Pour mes tests j’ai utilisé Internet Explorer 5.0 et 6.0. Il se comporte au niveau du cache,
exactement de la même façon.
Diverses options d’Internet Explorer nous permettent de modifier le comportement du cache

chez le client et ceci indépendamment de la configuration du serveur Web distant.
Pour y accéder, ouvrir Internet Explorer et aller sous tools -> Internet Options -> Settings
Plusieurs options s’offrent à nous :
En changeant ces 4 options,

on modifie les propriétés du
cache ce qui a pour effets
plusieurs modifications du
comportement du cache.
Celles-ci seront énoncées plus
loin dans ce chapitre.
Dans les chapitres qui suivront, je vais traiter toutes les options d’Internet Explorer (au
nombre de quatre) dans le détail. Ainsi pour chaque option, je ferai une analyse de protocole
dans le cas où le cache est présent sur le disque et dans le cas où il ne l’est pas.
Flux Applicatif 27
2.1 Option Never
Cette option est assez simple à comprendre.

En effet, sans le cache, la page est chargée normalement comme tout autre option.
Au contraire, si le cache est présent sur le disque, alors les données de la page seront
toujours rechargées localement.
Sans cache Avec cache
Get Request Pas de requête sur

le serveur web
Response OK
X
Server Web Server Web
Client Mise en Client Chargement depuis
cache le cache
Comme on peut le constater, l’option Never, ne charge qu’une seule fois la page. Une
fois que celle-ci s’y trouve, elle sera toujours chargée depuis le cache. Dans le cas où
la page aurait changé de forme, des liens ne fonctionneront peut-être plus, des
nouveautés ne seront pas perçues ou des images ne seront pas remises à jour.
La page sera toujours chargée depuis le cache.
Flux Applicatif 28
2.2 L’option Automatically
Cette option est celle qui vient par défaut lorsque l’on installe Internet Explorer.
En regardant les principes de celle-ci, nous nous rendons bien compte qu’il est normal
par rapport aux autres de l’avoir mise par défaut.
En effet si lors de la première connexion au site, la page se met dans le cache comme
avec les autres options, une fois que l’on se reconnecte au site, cette option va regarder
la validité des fichiers se trouvant dans le cache (chapitre 1.3).
Si l’on se reconnecte simplement avant que la date d’expiration du fichier soit

dépassée (champ Expires), alors les fichiers sont chargés entièrement du cache de
l’utilisateur. Dans le cas contraire le client va demander au serveur Web si des
modifications sont intervenues sur la page accédée.
Fichiers stockés dans le

cache expirés ?
(champ Expires)
Oui
fichiers
expirés
Client
Get request www.eig.unige.ch
If-Modified-Since: Tue, 08 May 2001 12:30:10 GMT
Response
OK si le fichier a été modifié après la dernière Server Web
connexion du client et envoi des DATAs. Sinon Not
Modified et la page sera chargée depuis le cache de
l’utilisateur. Les dates de validité (champ Expires par
Non. Fichiers
encore valides exemple) seront changées.
Alors chargement
de la page depuis
le cache
Je vais maintenant détailler un peu plus une séquence Request – Response afin de voir
les données qui sont transmises en plus de celles pour afficher la page.
Tous les paquets Request et Response vu, sont de la même forme que ceux présenté
dans les pages suivantes.
Flux Applicatif 29
Détails d’un paquet GET Request :
Voici les principaux paramètres concernant le cache que l’on retrouve dans ce paquet.
GET /images/supix.gif
Dans ce paquet, je vais accéder au fichier supix.gif du serveur Web
Referer: http://www.eig.unige.ch/
On envoie l’adresse du site où se trouve le fichier.
If-Modified-Since : Fri, 04 Feb 2000 19:02:16 GMT
Le client envoie dans la requête, la date de la dernière modification du fichier

connue par lui-même.
Connection: Keep-Alive
Ce type de connexion est très répandu. En effet lors d’une connexion à un site,
le client et le serveur vont transférer des données. Lors de cet échange, il se
peut que la connexion doive être coupée en raison d’un mauvais mot de passe
rentré ou d’une redirection sur une autre page. Dans le cas où le mode Keep-
Alive est activé, cette connexion reste active. Ce qui a pour but de diminuer le
trafic sur le réseau. Ce mode est donc très intéressant lorsque beaucoup de
personnes se connectent en même temps sur le site.
Flux Applicatif 30
Détails d’un paquet Response :
Voici les principaux paramètres concernant le cache que l’on retrouve dans ce paquet.
HTTP/1.1 304 Document not modified

Last-Modified: Fri, 04 Feb 2000 19:02:16 GMT
Date: Mo 01 Oct 2001 19:4 4:09 GMT
Les fichiers n’ayant pas été modifiés sur le site depuis la dernière visite, la réponse du
serveur Web sera du type Document not modified.
De ce fait les données seront chargées du cache. Celles-ci seront cependant remises à
jour avec une date de validité qui aura changé.
Ceci a pour objectif d’avoir une réduction du trafic dans le cas où le client est en train
de naviguer et revient souvent sur cette même page.
Si cependant, le serveur Web a subi des modifications entre temps, alors la réponse de
celui-ci sera OK et les données de la page seront transmises au client.
La question qui me viens à l’esprit est : comment fait le serveur à savoir si le client a
déjà les données de la page en cache ou non ?
Pour le savoir, il suffit de comparer 2 analyses de protocoles (avec une autre option) et
de voir la différence lorsque le client possède le cache ou non.
On s’aperçoit vite que lors du premier paquet GET request lorsque le cache est
présent, une ligne de commande est présente en plus.
If-Modified -Since: Tue, 08 May 200112:30:10 GMT

If-Modified-Since: Tue, 08 May 200112:30:10 GMT
Response
Ok ou Not modified suivant la date du paquet Server Web
Client précédent
Cette ligne de commande demande au serveur Web si la page que le client à visité a
été modifiée ou non. Or si le client pose cette question c’est qu’il possède déjà le cache
dans sa machine. Dans le cas contraire, il ne la posséderait pas.
Flux Applicatif 31
2.3 L’option Every time you start internet Explorer
Lorsque le client se connecte au site, il doit pour la première fois ouvrir Internet
Explorer. A partir de ce moment, toute page visitée pour la première fois, après
réouverture d’Internet Explorer sera remise en cache. Si sans avoir fermé la fenêtre de
navigation je revisite une page, alors celle-ci sera entièrement chargée du cache.
Ici je fais l’exemple comme pour toutes les autres options, en me connectant au site
www.eig.unige.ch
Lors du premier accès au site, les données sont mises en cache.
Si par exemple, je quitte cette page et je navigue, tout se passe comme si c’était la
première fois que je consultais les pages. C’est au moment où je me reconnecte sur
l’url déjà tapé, que les propriétés de cette option, vont se faire remarquer.
En effet, comme on peut voir avec l’analyse de protocole suivante, je n’ai aucun
paquet http qui passe entre le client et le serveur suite à la reconnexion au site sans
avoir quitter au préalable Internet Explorer.
Flux Applicatif 32
Cette option, a pour objectif de charger automatiquement les pages depuis le cache
lorsque je garde Internet Explorer ouvert. Aucune demande ne sera donc faite au
serveur Web.
Cependant, lorsque que je ferme Internet Explorer et le rouvre, pour aller consulter la
même page, les données seront à nouveau stockées dans le cache mais comme pour
l’option automatically, la validité des fichiers va être testée pour le renvoi par le
serveur Web de données plus récentes.
En résumé, lorsque l’on quitte Internet Explorer, les données d’un url sont toujours en
cache, celui-ci se comporte exactement comme l’option Automatically . Ce n’est que
lorsque l’on garde Internet Explorer ouvert que l’option joue un rôle en chargeant
automatiquement les données du cache (comme l’option Never).
Voir page suivante pour une représentation graphique du fonctionnement de cette

option.
Flux Applicatif 33
Résumé de l’option Every time you start internet Explorer
Client
www.eig.unige.ch
Est-ce que le fichier est

stocké dans le cache ?
Oui Non
Est-ce que Internet Explorer a été

Non
quitté entre le dernier accès et
maintenant ?
Oui
Est-ce que les fichiers dans le

Non Server Web
cache sont encore valides ?
Oui
Affichage de la
page depuis le
cache
Flux Applicatif 34
2.4 L’option Every visit to the page
Cette option, comme son nom l’indique va recharger les données de la page à chaque
fois que l’on visite la page en question même si les données sont déjà stockées dans le
cache.
Au contraire des autres options, celle-ci ne testera pas des heures de validité dans le
cache mais regardera chaque fois s’il y a des modifications sur la page.
Sans cache Avec cache
Si j’essaye de me connecter un certain nombre de fois sur la page, j’obtiendrai toujours

l’analyse de droite (Avec cache).
Cache
Aucune requête
pour savoir s’il y
a un cache valide
Client
If-Modified-Since: Tue, 08 May 200112:30:10 GMT
Response
Ok ou No t modified suivant la date du paquet Server Web
précédent
Flux Applicatif 35
2.5 Résumé de toutes les options d’Internet Explorer
Dans ce chapitre j’essayerai de résumé brièvement toutes ces options et ces principes.
Pour avoir plus de détails sur chaque option, se référer au chapitre concerné.
Option Fonctionnalités
Lorsque l’on accède pour la première fois au site, les
Never
données de la page seront mises en cache. Lors d’un
prochain accès, les pages seront réaffichées depuis le
Chapitre 2.1
cache et ne seront pas remises à jour.
prochain accès, le client va regarder la validité des
fichiers qui se trouvent dans le cache à l’aide de
l’heure de validité de ceux-ci (champ Expires). S’ils
Automatically
sont encore valides alors la page sera affichée depuis le
cache. Dans le cas contraire, le client va demander
Chapitre 2.2
pour chaque fichier, si celui-ci a été modifié ou non
(champ Last Modified ) et suivant le résultat, les
données dans le cache seront modifiées ou non.
Cependant, lorsque le client se sera reconnecté sur la
page, une nouvelle heure de validité sera présente.
prochain accès, dans le cas ou Internet Explorer n’a
Every time you pas été fermé, la page concernée sera entièrement
start Internet Explorer chargée depuis le cache (idem option Never). Dans le
cas contraire, donc si Internet Explorer a été fermé
Chapitre 2.3 entre-temps, le client va devoir recharger le cache de la
page en demandant au serveur Web si les fichiers se
trouvant sur la page ont été modifiés (champ Last
Modified) ou non (idem mode Automatically).
Every visit to the page
prochain accès, le client demandera au serveur Web si
les fichiers se trouvant sur la page ont été modifiés ou
Chapitre 2.4 non (champ Last Modified ). Il n’y a pas dans ce cas
d’heure de validité.
Flux Applicatif 36
Chapitre 3 : Le cache vu par le serveur Web
Ce chapitre contrairement au précédent ne traitera que du serveur Web. En effet je vais

montrer certaines commandes lors de la création du site qui affecte le cache du côté client. De
plus, je vais présenter ce que l’on peut trouver comme traces ol rs d’un accès au serveur par
n’importe quel client.
Avant de regarder les commandes propres au cache, il faut créer notre site.
Pour cela, j’ai récupéré la page du site du laboratoire de transmissions de données. Pour
récupérer le fichier, il suffit simplement de faire un save as de la page.
Une fois cette opération terminée, je vais installer le serveur Web.
3.1 Installation du serveur Web
Le serveur Web que j’ai créé (Machine Vectra 11 , IP = 129.194.187.52) se trouve sur
une machine Windows 2000 Professional. Je vais donc devoir installer IIS 5.0 pour
gérer mon site Web.
Pour cela, il suffit d’installer un nouveau composant Windows depuis le CD
d’installation de la version Windows 2000 Server par exemple.
Ensuite, il faut que je configure IIS. Je dois donc définir la page par défaut de mon
site. Les paramètres du site sont accessibles sous : IIS -> Vectra11 -> Default Web
Site -> Properties. Sous l’onglet Documents, j’insérerai la première page de mon site.
Flux Applicatif 37
En cliquant sur Properties, et en

allant sous l’onglet Documents, on
obtient la fenêtre suivante.
Nous avons donc ici la première

page de notre site qui s’appelle
tdd.htm
De plus, il faut indiquer le répertoire où se situe cette page. Dans notre cas il se trouve
sous c:\site .
Dans l’onglet Home Directory, donner le chemin de l’emplacement sur le disque de la

première page du site.
Maintenant que nous avons installé le serveur Web, il nous suffit de le gérer. Le but ici
est de regarder les commandes http que l’on peut avoir sur le serveur Web. De ce fait,
je ne m’attarderai pas sur des problèmes d’authentifications sur le serveur Web.
Flux Applicatif 38
3.2 Commandes HTTP
Plusieurs méthodes sont possibles afin d’envoyer des commandes pour stocker en
cache les données depuis le serveur.
La première consiste à mettre des commandes directement dans la page html. Ceci est
donc du ressort du programmateur de la page.
Pour cela, on utilise des Meta Tag qui sont plus ou moins semblables aux entêtes http.
Cependant je ne les étudierai pas dans mon mémoire.
Une deuxième méthode (celle que j’étudierai) est celle qui nous permet depuis IIS de
mettre des entêtes HTTP personnalisées sur le site Web.
En effet, dans ces entêtes, il nous suffit de taper les commandes HTTP et le tour est
joué. Cette méthode est plus facile à mettre en œuvre c’est pourquoi j’ai décidé de
l’étudier.
Ces commandes peuvent être insérées sous l’onglet HTTP Headers dans les propriétés
du site Web. (voir chapitre 3.3)
Les commandes principales concernant la mise en cache se trouvent dans la RFC 2616
chapitre 13 et 14 principalement.
Flux Applicatif 39
3.3 L’onglet HTTP Headers
C’est l’endroit où l’on rentre les commandes http. Pour cela, il faut cliquer sur add et
rentrer les commandes.
Dans la fenêtre qui nous apparaît, il faut taper cache-control dans le premier champ et
le type de commande que l’on veut.
Par exemple : cache-control et max-age = 120
Voici donc l’apparition d’une nouvelle

commande http sur notre page.
Toutes les commandes peuvent être tapées une par une par cette méthode. Cependant,
en ce qui concerne les commandes pour l’expiration du cache comme max-age, sur ce
même onglet, nous avons la possibilité de choisir des dates d’expirations de façon plus
simple sans connaître les commandes http.
Flux Applicatif 40
En effet, on peut avoir les paramètres Expire Immediately, Expire after ou Expire.
Pour cela, cliquer sur la case Enable Content Expiration dans la figure dans la figure
de la page précédente.
Expire immediatelly est identique à taper : Cache-control : max-age = 0
Expire after est identique à taper : Cache-control : max-age = xxxx
Expire est identique à taper : Expire : Thu 13 Dec 2001 18 :00 :00 GMT
Elle est présente pour simplifier la commande max-age. En effet, la valeur de max-age
étant en seconde, il est plus facile de rentrer une date que de devoir calculer le nombre
seconde qu’il y a d’ici la date d’expiration choisie.
3.4 Principales commandes HTTP
Voici une liste des principales commandes HTTP utilisées.
- no-cache : Le serveur Web force le browser ou le proxy à ne pas mettre en

cache les données qu’il envoie. Ainsi à chaque fois que l’on se
connecte au site, la page sera entièrement rechargée et il n’y
aura aucune donnée présente dans le cache. Malheureusement
cette commande affecte la charge du réseau de façon négative,
du fait qu’à chaque fois qu’une requête est émise sur le serveur,
celui-ci devra renvoyé ses données intégralement. Elle sera
décrite plus précisément au chapitre 3.4.1.
- max-age : Cette valeur nous renseigne sur la durée de la validité de la page.

Elle est définie en seconde. C’est une des commandes les plus
souvent utilisées. Elle sera décrite plus précisément au chapitre
3.4.2.
- public : Normalement une page avec un contenu authentifié ne peut pas

être cachée. Cependant si cette commande est présente, cela veut
dire que la page peut être mise dans le cache si le client accepte
cela.
- private : Cette commande ne permet pas à d’autres utilisateurs de

s’emparer du cache. Par exemple, si on a un proxy (ISA) voir
chapitre 5 entre le client et le serveur, celui-ci ne pourra pas
avoir dans son cache les pages du site.
- must-revalidate : Il se peut que la configuration d’un browser soit faite de manière

à ne pas recharger le contenu à chaque accès au site (option
Never par exemple). Avec cette commande, le serveur force le
client à recharger les données à chaque fois que l’on veut
accéder au site.
Flux Applicatif 41
- proxy-revalidate : Idem que must-revalidate mais pour un serveur proxy.
- expire : Est identique à max-age mais cette fois-ci on rentre directement

une date et une heure au lieu de donner un temps en seconde.
- pragma : Cette commande sert lorsque le serveur a beaucoup de données à

envoyer. En effet afin de ne pas envoyer par exemple no-cache
pour chaque fichier, on rentre une seule fois lors du premier
accès pragma : no-cache et pour la suite du transfert, le client
sait qu’aucune donnée ne doit être mises en cache.
3.4.1 Commande no-cache
Comme énoncé dans le chapitre 3.4, cette commande a pour but de forcer le browser
ou le proxy à ne pas mettre en cache les données. Pour vérifier cela, j’ai fait une étude
de protocole et voici ce que j’ai pu en tirer.
Cache
client
vide
Get Request
Response OK
Client Cache -control : no-cache
Server Web
Si l’on regarde l’état du cache après cette opération, on constate qu’il est bel et bien
vide.
Cette commande est souvent utilisée sur des sites qui demandent une authentification.
Typiquement, ce sont les sites de messagerie ou les sites sécurisés où cette commande
est le plus fréquemment utilisée.
Flux Applicatif 42
3.4.2 Commande max-age
C’est la commande la plus couramment utilisée de toutes celles énoncées au chapitre

3.4. En effet, elle permet de définir une date de validité des fichiers stockés dans el
cache. C’est cette date qui va déterminer si le browser va ou non faire une requête sur
le serveur pour savoir si des données ont été modifiées sur le site précédemment
consulté (elle va affecté le champ Expires dans le cache du côté client voir page 1.3).
De la même manière que pour la commande no-cache, je vais regarder ce qui c’est
réellement passé
Cache
client
présent
Get Request
Response OK ou Not modified

Client Cache -control : max-age = 120
Server Web
La différence avec la commande no-cache, c’est que maintenant des données sont
stockées dans le cache. Cependant, la date d’expiration des fichiers sera de 120
secondes. Ce qui correspond donc a 2 minutes. Ainsi lorsque l’on regarde notre cache
on s’aperçoit que la date d’expiration du fichier sera de 2 minutes plus vieille que celle
de la date du dernier accès.
Si le serveur Web répond Not modified, cela veut dire que le fichier n’a pas été
modifié depuis le dernier accès. Donc le champ Last Modified ne changera pas.
Au contraire si le serveur Web répond OK, il a donc modifié des données sur la page
accédée, alors ce champ Last Modified aura une nouvelle valeur.
Type de réponse Last Modified Expires Last Accessed

Avant de se connecter 5 Novembre 12h00 18 Novembre 15h00 18 Novembre 14h58
Not Modified 5 Novembre 12h00 18 Novembre 15h32 18 Novembre 15h30
OK 18 Novembre 15h30 18 Novembre 15h32 18 Novembre 15h30
Flux Applicatif 43
3.5 Les fichiers LOG
Il est normal que lorsque les clients se connectent sur le serveur Web, ils laissent une
trace de leur passage.
Ainsi à l’aide d’IIS , nous pouvons avoir un fichier log qui nous servira pour savoir qui
s’est connecté.
Ces fichiers log sont au nombre de 4 et le format peut être choisi dans l’onglet Web
Site.
Pour activer la fonction de

Login , valider cette case
Nous pouvons aussi choisir quelles seront les données affichées dans ce fichier.
Une liste avec des choix multiples peut être modifiée dans Extended Properties
Cependant, ces fichiers log ne servent pas vraiment. Certes ils nous renseignent sur qui
s’est connecté sur notre site mais ces renseignements ne sont pas trop importants pour
l’administrateur, si ce n’est pour des détections d’intrusions. Pour cela, il faudrait
installé un firewall ou un proxy afin de surveiller beaucoup mieux qui se connecte sur
notre serveur.
C’est pourquoi je ne m’attarderai pas plus sur ces fichiers log.
Flux Applicatif 44
3.6 Conclu sion
Avec ce deuxième chapitre, nous avons pu montrer les emplacements du cache du côté
client ainsi que les commandes qui doivent être écrites du côté serveur afin que le
cache soit plus ou moins contrôlé.
Cependant, le cache qui a aussi un rôle de réduction de temps d’accès aux pages, n’est
pas vraiment efficace suivant les commandes http présentent sur une page html. C’est
pourquoi lors d’une seconde phase, nous étudierons le phénomène d’accélération des
accès aux sites grâce au cache avec un logiciel appelé ISA (Internet Security and
Acceleration) qui lui a la fonctionnalité de réduire le temps d’accès aux pages. Dans
quelle mesure ? A quel prix ? Toutes ces questions seront traitées dans les chapitres
suivants (voir chapitre 4 à 6).
Flux Applicatif 45
Chapitre 4
ISA Server
Première Partie
Lors du chapitre précédent, nous avons pu constater que le cache d’un utilisateur n’était pas
visible par quelqu’un d’autre. De ce fait aucune machine ne bénéficiera du cache de la page
visitée qui est déjà stockée chez un autre utilisateur.
Le logiciel ISA (Internet Security and Acceleration) propose un Firewall ainsi qu’un serveur
de cache réuni en un seul logiciel.
Dans mon diplôme, je ne m’attarderai pas sur les fonctionnalités du Firewall, mais me
concentrerai uniquement sur la partie cache et proxy.
Ainsi à l’aide de ce logiciel, nous pourrons faire bénéficier un autre utilisateur du cache
présent sur une autre machine. Les accès à Internet, devraient théoriquement, être plus rapide.
C’est pourquoi dans les chapitres 5 et 6, je vais tester les différentes possibilités qu’offre ce
logiciel, afin d’améliorer ce phénomène. Dans ce premier chapitre je résumerai brièvement les
possibilités qu’offre ISA Server. Pour ne pas charger cette partie, j’ai fait un guide d’ISA
Server beaucoup plus complet en annexe, une théorie sur les possibilités de ce logiciel serait
trop volumineuse. De plus, cela ne nous apporterait pas beaucoup sur la compréhension de ce
logiciel au niveau traitement des données reçues et analyses de protocole.
Si l’on regarde la documentation sur le site de Microsoft (fondateur du logiciel), on s’aperçoit
que plusieurs avantages devraient être tiré en installant dans notre réseau un serveur ISA.
Les différentes améliorations énoncées sont :
• Réduction de la bande passante du réseau

• Réduction du temps d’accès aux pages
• Rafraîchissement automatique des pages
• Réduction de l’utilisation du processeur et du réseau
4.1 Configuration requise
• PII 300 MHz

• Windows 2000 Server Service Pack 1
(dans le cas ou le Service Pack 2 est installé, il faut installer le Hotfix Q301625 à
l’adresse : http://support.microsoft.com/support/kb/articles/Q301/6/25.ASP )
• 256 Mo de mémoire vive
• Partition formatée en NTFS
Selon le nombre d’utilisateurs et la place que l’on réserve dans le cache, il faut
augmenter respectivement la taille de la mémoire vive et la taille du disque dur.
Flux Applicatif 46
Ce logiciel, nous offre plusieurs possibilités d’utilisation selon le type d’installation.
Les trois modes proposés sont : .
- Le mode cache (Chapitre 4.2)

- Le mode Firewall (Chapitre 4.3)
- Le mode Integrated (Chapitre 4.4)
4.2 Le mode cache
Ce mode est celui que nous allons utilisé. En effet, il nous servira à faire la
comparaison entre une connexion avec un serveur de cache et l’étude précédente qui
était de se connecter simplement à un serveur Web. Ainsi nous pourrons constater la
différence entre ces deux modes et voir si ce logiciel est un investissement intéressant
pour les entreprises et si oui dans quelles mesures.
Les temps d’accès sont-ils vraiment améliorés et de combien ? Les utilisateurs dans le
réseau peuvent-ils bénéficier du cache des autres ? Toutes ces questions seront traitées
dans le chapitre 5.
Internet
Client
Server ISA
mode Cache
4.3 Le mode Firewall
Ce mode d’installation ne sera pas traité dans l’étude d’ISA. En effet, le but est de
tester la problématique du cache et non de la sécurité des utilisateurs qui se trouvent
derrière celui-ci, ni de la sécurité du serveur lui-même.
Lorsque l’on installe le Firewall et le mode cache, il est préférable de les installer
chacun sur une machine différente.
Internet
Client
Server ISA Server ISA

mode Cache mode Firewall
Flux Applicatif 47
4.4 Le mode Integrated
Ce mode est un mixte des deux. Il permet non seulement de stocker le cache des
utilisateurs comme dans le mode cache, il permet aussi d’avoir les propriétés du
Firewall installées sur la même machine. Si l’on veut installer un vrai Firewall et non
simplement un filtre, il faut installer les deux modes séparément. Cependant, si l’on
veut juste faire un filtrage des paquets, on peut utiliser le mode integrated . Lorsque
l’on veut publier notre site sur Internet depuis l’intérieur du réseau, nous sommes
forcés d’avoir au moins le mode Integrated à disposition si l’on veut un minimum de
sécurité. En effet, lors de la publication du site Web, il faut des filtres pour ne pas
laisser pénétrer tout le monde dans le réseau.
Internet
Client
Server ISA
mode Integrated
4.5 Choix décidé pour l’installation
L’installation doit se faire avec le CD Standard Edition si possible. Etant donné que
dans le laboratoire de transmission de données, la version disponible est Entreprise
Edition, je suis obligé d’installer celle-ci.
Cela ne pose pas de problème si ce n’est que cette version a un coût beaucoup plus
cher par rapport à la version Standard.
Lorsque l’installation commencera, je choisirai le mode Standalone, car je n’ai qu’un

seul serveur ISA.
Ensuite je n’utiliserai que le mode cache. L’étude du cache étant la partie essentielle
de ce rapport.
Au début, j’ai utilisé une seule carte ethernet. C’est la configuration qui est
recommandée dans tout les documents trouvés sur ISA Server.
Par la suite j’utiliserai une deuxième carte et je verrai la différence. Voir Annexe
Guide d’ISA Server.
Maintenant je suis prêt pour me lancer dans l’installation du logiciel.
Pour plus de détails consulter le guide d’ISA Server en annexe.
Une fois que l’on a installé le logiciel, nous avons plusieurs moyens de mettre en
cache les données reçues par le serveur Web.
Flux Applicatif 48
4.6 Différents modes de mise en cache
Avec ISA Server installé en mode cache, nous avons la possibilité de stocker des pages
d’une façon dynamique. En effet, il est possible qu’ISA fasse des requêtes sur le
serveur Web sans qu’aucun client fasse de demande. Ce mode s’appelle Active Cache.
Bien sûr, le mode cache par défaut n’a pas cette option. Il est simplement configuré
pour que toutes les pages qui traversent ISA, soient stockées avec une date de validité
plus ou moins grande selon les paramètres choisis. Ce mode s’appelle HTTP Cache.
Un troisième mode de cache qui est l’Advanced Caching ne sera pas traité avec une
étude de protocole particulière. Celui-ci permet de créer certaines règles sur les
fichiers qui nous arrivent. Par exemple, de ne pas stocker les pages plus grandes que x
bytes.
Un dernier mode de mise en cache, est la mise en cache automatique mais non plus en
fonction des paramètres d’Active Caching. Cette fois il faut rentrer directement une
heure, une date et le site sur lequel on veut charger la page.
Pour finir un mode Scheduled Caching, nous permet de dire à ISA d’aller charger une
page à une date donnée.
En résumé les différents mode de mise en cache sont :
• Http Caching
• Active Caching
• Advanced Caching
• Scheduled Caching
Afin d’accéder à ces options, sous Cache Configuration, cliquer sur Properties.
Pour plus de détails sur les modes Advanced Caching et Scheduled Caching, consulter
l’annexe Guide d’ISA Server.
Flux Applicatif 49
4.6.1 http Caching
C’est le mode par défaut d’ISA Server. Lorsqu’un client effectue une requête sur le
serveur Web, il doit passer par le proxy. Celui-ci va alors regarder dans son cache, s’il
possède la donnée recherchée. Si tel est le cas, il regarde si cette donnée est encore
valide ou non. Suivant le résultat de ce test, il va aller rechercher les données sur le
serveur Web et va envoyer depuis son cache les données au client. Le temps de
stockage peut varier suivant la configuration du serveur ISA. Voir guide d’ISA Server
en annexe.
Non
Internet
Client Serveur ISA Serveur Web
Request Date de Request

Stockage
Response Valide ?
Oui
Stockage des
données.
Response Avec date de Response
validité suivant
Les paramètre de
http Caching
Flux Applicatif 50
4.6.2 Active Caching
Lorsque le client accède à un site Web, les pages en questions sont mises en cache
suivant les paramètre de http Cache. Cependant ces fichiers peuvent arriver à
expiration. C’est pourquoi ce type de cache est présent. Si une page est modifiée
souvent, alors il serait dommage qu’à chaque fois que le client se connecte sur celle -ci,
il doive la recharger. Or avec Active Caching, c’est le serveur qui fera la requête
automatiquement sans qu’aucune requête ne soit émise par un client.
La fréquence de mise à jour des pages peut être gérer. Voir guide d’ISA server en
annexe.
Internet
Client Serveur ISA Serveur Web

Request Request
Response Response
Temps
d’expiration
de la page
Request
Remise à jour
Aucuns paquets du cache Response
Flux Applicatif 51
4.7 HTTP 1.0 VS HTTP 1.1
Lorsque le client se connecte sur un serveur Web à travers ISA, il doit utiliser une
connexion de type proxy. Il faut donc modifier une option dans Internet Explorer.
Elle s’effectue sous l’onglet Advanced.
Il faut sélectionner Use http 1.1 through proxy connections au lieu de Use http 1.1.
Ainsi on voit qu’Internet Explorer, peut être utilisé de 4 manières différentes. La
première est celle qui consiste à ne cocher aucune des deux cases énoncées
précédemment, le browser utilise alors le protocole HTTP 1.0 pour communiquer avec
le serveur Web. Si la première case uniquement est cochée, cela signifie que l’on
utilise le protocole HTTP 1.1. Si l’on coche uniquement la deuxième case, nous
utiliserons alors le protocole HTTP 1.1 à travers le proxy et le protocole HTTP 1.0
pour une requête sans proxy.
Si les deux cases sont cochées, alors le protocole HTTP 1.1 sera toujours utilisé.
Flux Applicatif 52
Voici un tableau qui résume les différents choix.
Mode choisi Protocole Protocole Protocole

HTTP 1.0 HTTP 1.1 HTTP 1.1
utilisé utilisé à travers
le proxy
Use http 1.1 X

Use http 1.1 through proxy connections X
ü X X
Use http 1.1 ü
Use http 1.1 through proxy connections X
X ü X
Use http 1.1 X
Use http 1.1 through proxy connections ü
ü X ü
Use http 1.1 ü
Use http 1.1 through proxy connections ü
X ü ü
Mais pourquoi utiliser HTTP 1.1 et non pas 1.0 ?

La réponse est simple, le protocole HTTP 1.0 ne défini pas de commande en ce qui
concerne la mise en cache des données. Dans la norme HTTP 1.0, les champs cache-
control : no-cache, max-age, public, private etc… n’existaient pas. Ils ont été ajoutés
dans la norme HTTP 1.1.
Pour connaître les modifications entre HTTP 1.0 et HTTP 1.1, consulter l’adresse :
http://groups.yahoo.com/group/http-wg/message/8289
Tout ces champs auront une influence sur le comportement du cache et donc du
serveur ISA. Nous les verrons plus en détails dans les chapitres 5 et 6.
Flux Applicatif 53
Chapitre 5
ISA Server
Deuxième Partie
5.1 Introduction
Dans les chapitres qui vont suivre, je vais essayer de présenter les différents modes de
fonctionnement du serveur ISA avec pour chacun des tests. Une étude de protocole
sera faite afin de comprendre le fonctionnement du logiciel.
La première partie servira à comprendre les principes de fonctionnement avec un seul
client connecté sur le serveur de cache. Nous montrerons ainsi la différence avec la
partie cache Web (chapitre 1 et 2). Nous comparerons une connexion avec ou sans
proxy.
Une deuxième partie sera consacrée à ajouter un deuxième client afin de lui faire
bénéficier du cache d’un autre utilisateur. Pour rappel, ceci n’était pas possible avec un
cache Web traditionnel (chapitre 1).
Toutes ces mesures se feront avec une seule carte Ethernet.
Une troisième étude se fera avec la même configuration client mais avec 2 cartes
Ethernet. Ainsi nous verrons les problèmes de routage entre cartes et regarderons ce
que cela apporte de plus au niveau de la sécurité.
Une quatrième et dernière étude, portera sur le reverse proxy. Celui-ci étant souvent
utilisé, nous essayerons d’expliquer ses principes.
Flux Applicatif 54
5.2 Fonctionnement du Serveur ISA
Afin de mieux comprendre le fonctionnement du serveur ISA, j’ai trouvé un schéma

sur Internet à l’adresse :
www.microsoft.com/technet/prodtechnol/isa/proddocs/isadocs/CMT_Cache.gif qui
montre bien le fonctionnement du serveur ISA.
A l’aide de cette figure très importante pour la compréhension, nous pouvons effectuer
les tests nécessaire à la compréhension des transferts de données entre les différentes
machines.
Il faudra donc toujours garder cette figure à l’esprit.
Flux Applicatif 55
5.3 Test avec un seul client et une carte Ethernet sur ISA
L’architecture du réseau lorsque l’on installe une seule carte Ethernet est la plus
simple. En effet, le réseau a la typologie suivante :
Client
Internet
Serveur Web
Serveur ISA
Afin de mieux comprendre le transfert de données entre les différentes machines, je

vais remettre le dessin a plat. Cependant il faudra bien tenir compte que l’on utilise
qu’une seule carte ethernet.
En effet, lorsque l’on utilise une seule carte Ethernet, il faut savoir que le serveur ISA
récupère les données du client pour les renvoyer via la même carte sur le serveur Web.
Flux Applicatif 56
5.4 Mode http Header Frequently
5.4.1 Commande max-age envoyée par le serveur Web
Lorsque je me connecte pour la première fois, je ne possède aucun cache local.

Le serveur ISA a aussi son cache vide.
Get Request Get Request

From Client Via ISA Server
to Server Web to Server Web
Proxy Connection :
Client
Keep-Alive Serveur Web
Serveur ISA
Response OK Response OK
Via ISA Server From Server Web
to Client to ISA Server
Cache-Control : max-age = 900 Cache -Control : max-age = 900
Expires : Wed, 17 Oct 2001 15:44:44 GMT Expires : Wed, 17 Oct 2001 15:44:44 GMT
Date : Wed, 17 Oct 2001 15:29:44 GMT Date : Wed, 17 Oct 2001 15:29:44 GMT
Last Modified : Wed, 17 Oct 2001 12:05:41 GMT Last Modified : Wed, 17 Oct 2001 12:05:41 GMT
Données utiles de la page Données utiles de la page
Lors de cette première étude, nous voyons tout de suite les modifications, suite au
proxy installé, entre le client et le serveur Web.
En effet, maintenant le client envoie le paramètre Proxy Connection.
Quand au serveur ISA il modifie un champ http. Le champ Source Adress est remplacé
par un Via .
En ce qui concerne les réponses, on voit que l’on a simplement un Source Adress qui
est remplacé par un Via . Sinon la réponse du serveur Web au serveur ISA est tout à
fait identique à la réponse du serveur ISA au client.
Ici le paramètre max-age est présent (voir chapitre 3.4.2). La différence entre la Date
et Expires est exactement la valeur de max-age. En effet, 900 secondes = 15 minutes =
15h44 – 15h29 (Date – Expires).
Maintenant une date d’expiration est valide. Si l’on refait un requête sur la page, alors
aucun paquet ne devrait sortir du client tant que les fichiers ne sont pas expirés du côté
client.
En effet, aucune requête ne part du client au cas où le rafraîchissement de la page se

fait avec ENTER. Cependant, si F5 est tapé, alors une requête sur le serveur ISA est
faite. (voir différence entre les modes de rafraîchissement au chapitre 1.5).
C’est pourquoi le deuxième test effectué sera de faire un rafraîchissement de la page

avec F5 sur une page qui est encore en cache et valide du côté client.
Flux Applicatif 57
5.4.2 Cache présent valide sur le client et sur ISA avec

rafraîchissement F5
Ici le client qui effectue le rafraîchissement, envoie dans son paquet http Get Request,
le paramètre Last Modified. Dans mon cas il vaut : 17 Oct 12h05. Ainsi le serveur
Web va regarder cette date pour savoir si une modification est intervenue.

Client
If modified Since If modified Since
(Last Modified ) (Last Modified)
Proxy Connection : Serveur ISA Serveur Web
Keep-Alive
I
Response Not Modified Response Not Modified
Cache -Control : max-age = 900 Cache-Control : max-age = 900
Expires : 25 Oct 15h15 Expires : 25 Oct 15h15
Date : 25 Oct 15h00 Date : 25 Oct 15h00
Last Modified : 17 Oct 12h05 Last Modified : 17 Oct 12h05
Ici, Last Modified , nous donne la date d’expiration des fichiers dans le cache. Le
serveur renvoie le paramètre Not modified et renvoi la même date (Last Modified)
qu’auparavant. Ce qui est normal vu qu’aucune modification n’est intervenue sur la
page consultée.
Si cette modification est parvenue entre temps, alors le serveur Web envoie un OK et
retransmet les données modifiées, et le paramètre Last Modified aura une nouvelle
valeur.
Flux Applicatif 58
Une question qui vient à l’esprit est : Comment se fait-il que du côté ISA je sois avec
le http cache en mode Frequently et que le client envoie un paramètre If modified
Since (Last modified) ? En effet, lorsque l’on se trouve en mode Frequently, le cache
ne doit jamais être valide ni du côté ISA ni du côté client.
La réponse est simple. Il suffit de lire la petite remarque lorsque l’on configure les
différentes options du mode http Caching.
Mettre en cache
les données à
moins que la
source indique
l’expiration de la
page.
De ce fait, si le serveur Web envoie une date d’expiration, celle-ci prendra le dessus
sur le type d’option du serveur ISA. C’est-à-dire que si le serveur Web envoie un max-
age = 900, et que le serveur ISA est configuré pour avoir un cache qui expire
immédiatement, les données du serveur Web, forcent alors à avoir une validité des
fichiers dans le serveur ISA et chez le client, de 900 secondes.
Flux Applicatif 59
5.4.3 Cas où le serveur Web envoi un no-cache
Le cas précédent, montrait comment réagissait le serveur ISA lorsque le serveur Web
envoyait un paramètre max-age = xxx. Maintenant je vais regarder le cas où le serveur
Web envoie un no-cache.
Ce qui devrait maintenant se passer, c’est que le serveur ISA devra toujours recharger
les données du serveur Web du fait qu’il ne les possédera pas dans son cache vu la
commande http no-cache envoyée.
Voyons si tel est bien le cas :
Premier accès sans le cache du côté client mais avec le cache du côté ISA.

Proxy Connection : Keep-Alive
Client
Serveur Web
Serveur ISA
Response OK ou Not Modified Response OK ou Not Modified

Cache -Control : no-cache Cache-Control : no-cache
Expires : 7h00 Expires : 7h00
Date : 7h00 Date : 7h00
Last Modified : Date Last Modified : Date
Age = 0
Comme on peut le constater à l’aide de ce diagramme en flèche, lorsque le serveur

Web envoie un no-cache, le serveur ISA renvoi ce même paramètre au client.
Cependant, un champ est ajouté. C’est le champ Age. Sa valeur nous renseigne
simplement sur la différence entre le temps courant et le temps du dernier accès.
Age = heure courante – heure du dernier accès
Je n’ai malheureusement pas trouvé d’algorithme pour le calcul de ce champ Age. La

formule ci-dessus étant la seule trouvée, je considère ce champ comme très simple à
calculer.
Cette commande Age peut servir lorsque l’on cascade plusieurs serveurs ISA. Ainsi le
serveur pourra savoir si les données qui lui sont transmises sont encore valides ou non.
Flux Applicatif 60
Il pourra les accepter ou les rejeter suivant les critères de mise en cache de chacun des
serveur ISA cascadé.
En ce qui concerne le client, cette commande n’affecte en rien l’affichage de la page.
Elle est transparente.
Cependant il se peut que le serveur Web était configuré au préalable avec la

commande max-age et que l’administrateur du site décide de changer avec la
commande no-cache.
Cela pose un petit problème au niveau du proxy. En effet, celui-ci ayant dans son
cache les données, lorsque le client demande la page, c’est le proxy qui va la lui
renvoyé. Les paramètres de mise en cache envoyés seront donc les anciennes valeurs.
Ainsi ce n’est qu’au deuxième accès que la modification sera prise en compte.
Le champ cache control sera à nouveau présent avec max-age = 900 et avec cache
control = no-cache.
Ainsi les données stockées dans le cache de l’utilisateur, n’auront pas une expiration
immédiate comme avec no-cache mais celle-ci sera de 15 minutes (max-age = 900
secondes).
Voici donc en réalité ce qui se passe :
Client
Serveur ISA Serveur Web
Get Request données de la Get Request

pas de cache page stockée
If Modified Since (Last Modified)
Response OK
les données cache control = 900
données de la données de
de la page Not Modified la page
page stockée
sont stockées data non prise en compte car Not cache control : no-cache demandée
Modified envoyé par le serveur Web :
validité du cache cache control = no-cache J'ai reçu Not Modified
selon ISA = 900 sec alors prends les données
qui sont dans mon cache
et je t'envoie ausi les
données du serveur Web
pour que tu les stockes.
données de la
page envoyée
Une fois que j'ai envoyé

les données au client, je
remets à jour mon cache
selon les entêtes http
envoyées par le serveur
Web
Flux Applicatif 61
Lors de la réponse du serveur ISA au client, celui-ci envoi les nouvelles données
concernant la mise en cache du côté client. Mais le serveur ISA envoi aussi son
ancienne valeur du cache. En effet, si le serveur Web envoi un Not modified au serveur
ISA, alors celui-ci croit que la page n’a pas été modifiée et le paramètre no-cache ne
sera pris en compte que lors de la prochaine connexion au site.
Si l’on regarde le cache du côté client, on s’aperçoit que la date d’expiration des
fichiers est bel et bien de 15 minutes. Cependant lors de la prochaine connexion, le
paramètre no cache sera envoyé tout seul. Ce n’est donc que lors d’une deuxième
connexion au site que les dates d’expiration du cache seront correctes.
La raison de tout ceci est que si l’on avait entré ces modifications dans la page html en
code pur, le serveur Web aurait renvoyé un OK pour dire que la page était modifiée et
dans ce cas, les dates de validité auraient été modifiées correctement.
C’est un des problème que l’on peut rencontrer lorsque l’on utilise cette méthode au
lieu de programmer en html pur les pages Web.
Si maintenant, j’ai reçu la commande no-cache du serveur ISA correctement, et

j’accède à nouveau au site, le client n’enverra plus les même paramètres au serveur
ISA.

Proxy Connection : Keep-Alive Pragma : no-cache
Client
Pragma : no-cache Serveur Web
Serveur ISA
Response Not Modified Response OK

Cache Control : no-cache Cache Control : no-cache
Expires : 7h54 Expires : 7h54
Date : 7h54 Date : 7h54
Last Modified : Date Last Modified : Date
Data transmises mais pas mises Data transmises mais pas mises
en cache localement en cache dans ISA
Le client n’ayant pas les données de la page demandée dans le cache, car ayant reçu la
commande no-cache lors du dernier accès, il renvoie le paramètre pragma : no-cache
au serveur ISA. Celui-ci en faisant la requête successive, fera de même du fait que lui
non plus n’a plus la page en cache.
Flux Applicatif 62
5.4.4 Cache présent sur le client et sur ISA avec

rafraîchissement ENTER
Lors du chapitre 5.4.2, nous avons vu le cas où le client rafraîchissait sa page en tapant
sur la touche F5. Mais que se passe-t-il si maintenant si je tape le nom du site
entièrement et je fais ENTER ?
Avant de répondre en faisant une étude de protocole, il faut savoir que comme pour le
cache Web classique (sans le serveur ISA), Internet Explorer va tester si les fichiers
stockés dans le cache sont encore valides ou non.
Si la réponse est non, alors le comportement lorsque l’on tape ENTER sur Internet
Explorer est identique à lorsque l’on tape F5. Si ISA est en mode Frequently, il faudra
à chaque fois rechargé la page. Ainsi pour voir l’analyse de protocole, se référer au
chapitre 5.4.2 (Cache présent valide sur le client et sur ISA avec rafraîchissement F5)
Client
Serveur Web
Serveur ISA
Oui
Non
Est-ce que les données
dans mon cache sont Idem Chapitre 5.4.2
encore valides ?
5.5 Mode http Header Normally
Lors des chapitres précédents, nous avions regardé les paquets qui traversaient le
serveur ISA lors d’un accès par un client sur un serveur Web. Cependant dans le mode
Frequently, les pages n’étaient pas stockées dans le cache d’ISA. En fait ISA ne jouait
que le rôle de proxy et non de cache. Maintenant, je vais regarder ce qui se passe
lorsque le serveur ISA possède les données de la page dans son cache.
Normalement du fait que les pages sont accessibles sur le serveur ISA, aucune requête
ne devrait sortir de celui-ci.
Flux Applicatif 63
5.5.1 Aucun cache présent sur le client mais présent sur ISA.
Le premier cas que je vais regardé est celui où le serveur ISA possède le cache de la
page accédée par le client. Imaginons que le client ne la possède plus car il a effacé le
contenu de son cache.
Get Request GGeett Reeqquuesstt

From Client VViiaa ISSA A SSeerrvveerr
to Server Web ttoo SSeerrvveerr W
Webb
Proxy Connection : Keep-Alive IIff mmoddififiieed SSiinnccee (EExppiireess))
Client
Serveur Web
Serveur ISA
Response OK RReesspoonnssee N Noott M Moddiifiieed

Via ISA Server FFrroom m SSeerrvveer W Weeb
to Client ttoo IISSAA SSeerrvveerr
Cache -Control : max-age = 60 CCachee-C
a c h Connttrrooll:: mmaaxx--aaggee == 600
Expires : 9h31 EExxppirrees :: 199hh3311
Date : 9h30 DDaatte ::1199h3300
Last Modified : Date LLaasst M Mooddiiffiieedd : D
Daattee
Age = 0 AAucun s do néess ttrraannssm
u c une s d o n né e misiseess ssii
Data transmises et mise aauccuunneess mmoodiifficicaatiioonnss ssuurr llee ssiitte
en cache localement avec date
d’expiration = 9h31
Si le cache du client n’est pas présent, alors le serveur ISA va automatiquement, et

seulement si les fichiers ne sont plus valides, demander au serveur Web s’il y a eu des
modifications depuis le dernier accès sur la page.
Dans le cas où les données sont encore valides, alors ISA renvoi les données
directement au client depuis sont cache, sans passer par le serveur Web.
Si les fichiers stockés dans le cache de ISA ne sont plus valides et qu’aucune
modification n’est advenue, alors le cas énoncé à la page précédente est correct.
Dans le cas où la page a été modifiée entre temps, alors le serveur Web répondra OK
au lieu de Not modified et il transmettra les données modifiées.
On remarque que quelque soit la réponse du serveur Web au serveur ISA, celui-ci
répondra au client OK. Ce qui est tout à fait normal car le client ne possédant aucune
donnée dans son cache, il faut que le serveur ISA les lui envoi.
Flux Applicatif 64
5.5.2 Cache présent sur le client et présent sur ISA.
Lorsque que le cache est présent chez le client, deux cas se présentent, Le premier est
lorsque le cache est présent et encore valide, le deuxième lorsqu’il ne l’est plus.
Dans le premier des cas, si le cache est encore valide chez le client alors les données
seront chargées depuis le cache local. Deuxième cas, elles seront chargées depuis le
serveur ISA.
Client
Serveur Web
Serveur ISA
Oui
Est-ce que les données Aucun paquet tant que la date

dans mon cache sont d’expiration des fichiers du
encore valides ? serveur ISA n’est pas dépassée.
Idem cas 5.5.1
Non
Non
Fichiers stockés
Get Request dans le cache
From Client encore valides ?
to Server Web
Proxy Connection : Keep-Alive Oui
If modified Since (Last Modifie d)
Response Not Modified

Via ISA Server
to Client La différence entre la date d’expiration
Expires : 12h49 (Expires) et la date courante (Date) est
Date : 12h34 égale à la date d’expiration dans les
Last Modified : Date paramètres du serveur ISA. En effet en
Age = 157 mode Normally, le temps d’expiration
Aucune donnée transmise d’une page est de 15 minutes.
12h49 – 12h34 = 15 minutes
Ici l’Age représente la durée de stockage de la page sur le serveur ISA depuis son
dernier accès au site
Flux Applicatif 65
5.5.3 Les autres cas
Les deux cas traités dans le chapitre précédent, sont les seuls où l’on peut voir le
comportement du mode Normally . En effet, dans les autres cas, le serveur Web envoi
une commande de type cache-control = xxx, et c’est cette commande qui prend alors
le dessus.
Donc, si ISA reçoit une commande HTTP de ce type, le mode Normally réagi
identiquement au mode Frequently ainsi qu’à tout les autres modes. C’est pourquoi je
ne ferai pas d’autres tests pour des modes de mise en cache.
Afin de voir le fonctionnement du cache dans d’autres cas, se référer au chapitre 5.4
(mode Frequently).
Flux Applicatif 66
5.5.4 Différences entre les modes http Caching
Nous avons pu voir le comportement de 2 modes de mise en cache. Les autres modes
fonctionnent identiquement à ceux-ci mais avec une durée de mise en cache différente
(stockage de la page dans le serveur ISA variant suivant la configuration du serveur
ISA).
Par contre ce que l’on peut dire c’est que suivant le mode de configuration du serveur
ISA, les requêtes se feront ou non sur le serveur Web.
Pour comprendre le phénomène, il faut toujours faire référence à la figure du chapitre

5.2, qui résume le fonctionnement du cache du serveur ISA. Je vais cependant le
résumé succinctement suivant les deux cas testés.
Client
Serveur Web
Serveur ISA
Est-ce que je possède Get Request Est-ce que je possède Get Request
la page en cache ? Non la page en cache ? Non
Oui Oui
Est-ce que la page est Est-ce que la page est

encore valide ? Non encore valide ? Non
Oui Oui
Chargement de la page Envoi des données

localement de la page au client
Stockage de la page Response

dans le cache
Au niveau de la requête sur la page, les cases teintées de gris, sont les cas où le mode
Frequently peut se trouver. Dans le mode Normally, tous les cas peuvent être
possibles.
Ici bien sûr on suppose que le serveur Web, n’envoie aucun type de commandes
spéciales sur la mise en cache des données. (voir chap 5.10)
Flux Applicatif 67
5.6 Mode Active Caching
Ce mode de mise en cache ne fonctionne pas sur le principe du client qui fait une
requête au serveur ISA, comme pour les autres modes.
En effet, ce mode de mise en cache se fait automatiquement sans l’intervention du
client.
Pour ce mode de mise en cache, je n’ai utilisé que le mode Frequently. Les autres
modes étant identiques sur le principe de fonctionnement, si ce n’est que la fréquence
des requêtes sur le serveur Web sera réduite.
De plus, toutes les autres options vont réactualiser les pages dans le cache suivant des
critères que ne peut régler l’administrateur avec le simple CD d’installation du
logiciel.
Les critères de rafraîchissement des pages sont : fréquentation du site, délai
d’expiration, charge du réseau.
Cependant, lorsque l’on est en mode Frequently, on sait que le rafraîchissement

automatique par le serveur ISA, se fera environ à la moitié de son délai d’expiration.
Client
Serveur Web
Serveur ISA
Get Request
Via ISA Server
Aucun paquet n’est transmis Active Caching Request
dans ce mode c’est le serveur Connection : Keep-Alive
ISA qui gère seul le If modified Since (Expires)
rafraîchissement des pages.
Response Not modified
Expire : 14h23
Date : 14h21
Cache control : max-age = 120
Comme on peut le remarquer, ici le serveur ISA fait une requête sur le serveur Web.
La requête étant faite pour remettre à jour le cache, alors celui-ci envoi une commande
Active Caching Request. Le serveur qui reçoit cette commande, réagi de la même
façon qu’auparavant et donne l’information au serveur ISA s’il y a eu des
modifications sur la page qu’il accède.
La commande max-age dit au serveur ISA, que les données seront stockées et retenues
comme valide pendant 120 secondes. Du fait que l’on se trouve en mode Frequently ,
chaque moitié de ce temps (60 secondes), le serveur ISA ira redemander au serveur
Web si des modifications ont eu lieu.
Flux Applicatif 68
5.7 Ajout d’un deuxième client
Tous les tests effectués jusqu’à présent étaient basés entre un échange
client - serveur ISA - serveur Web. Mais maintenant, je vais rajouter un deuxième
client afin de voir si celui-ci peut bénéficier du fait que quelqu’un d’autre soit déjà allé
visiter la page qu’il demande. Normalement, le serveur ISA ayant déjà en cache la
page, celui-ci ne devrait faire aucune requête vers l’extérieur.
Pour rappel lorsqu’au début de mon diplôme je me connectais sur un serveur Web
directement, un autre utilisateur, sur la même machine, ne pouvait pas bénéficier de
mon cache.
Cache du
site Web
du client A
Echange uniquement si les
Client A fichiers ne sont plus valides
dans le cache d’ISA.
Serveur Web
Serveur ISA
Client B
Get Request GGeett RReeqqueesstt

From Client B VViiaa IISSAA SSeerrvverr
to Server Web tto SSeerrveerr WWeebb
Proxy Connection : Keep-Alive IIff m
modifi d SSiinnccee ((EExxppiirreess))
o dif ied
Response OK RReessppoonnsse N Noott mmooddiffiieedd

Via ISA Server FFrroom
m SSeerrvveerr W Weebb
to Client B tto IISA A SSeerrvveerr
Cache-Control : max-age = 120 CCaacchhee--C Coonnttrrooll :: maaxx--aaggee == 112200
Expires : 15h31 EExxppiirreess ::1155hh331
Date : 15h29 DDaatee :: 115hh2299
Last Modified : Date LLaasstt M Moodiiffieedd :: D Daattee
Age = 0 AAu unes données ttrraannsm
u cu n e s d o n né e miisseess
Données de la page transmise
Proxy connection : Keep-Alive
On remarque bien dans le diagramme en flèche, que le nouveau client peut bénéficier
du fait qu’un autre utilisateur soit déjà allé visiter le site sur lequel il veut se connecter.
On peut donc en tirer la conclusion que lorsque l’on a plusieurs clients connectés sur
le serveur ISA, tous peuvent bénéficier du cache des différentes pages visitées par le
autres.
Flux Applicatif 69
5.8 Fonctionnement du serveur ISA avec 2 cartes Ethernet
Tous les tests intéressants au niveau d’une configuration avec une seule carte Ethernet
étant conclus, je vais maintenant rajouter une deuxième carte Ethernet. Ce qui aura
pour effet d’isoler les deux parties du réseau.
Au préalable il me faudra configurer la table de routage du serveur ISA afin que les
deux cartes communiquent et vice-versa.
Pour se faire, il suffit de dire à une des cartes , de donner l’adresse du gateway comme
l’adresse IP de la deuxième carte.
Adresse IP interne 10.0.0.20 Adresse IP externe 129.194.184.99

Subnet Mask 255.255.0.0 Subnet Mask 255.255.252.0
Default Gateway 129.194.184.99 Default Gateway 10.0.0.20
Preferred DNS 129.194.184.212
Alternate DNS 129.194.4.6
ISA Server
Avec cette configuration la table de routage se met toute seule à jour et de façon
permanente.
Ainsi avec ce type de configuration, tout paquet qui arrivera vers le serveur ISA sera
toujours redirigé vers le serveur Web mais avec une adresse source qui ne sera plus la
même que l’adresse qui servira à recevoir les données du client.

From Client From Server ISA
10.0.0.1 Adr IP
Client To Server Web 129.194.184.99 Serveur Web
Serveur ISA To Server Web
Response Response
From Server ISA From Server Web
Adr IP 10.0.0.20 To Server ISA
To Client 10.0.0.1 Adr IP
129.194.184.99
Au niveau de l’étude de protocole, celle -ci se fait de la même manière, avec les mêmes
commandes que lorsque l’on avait une seule carte.
Malheureusement, en rajoutant une carte, des questions de sécurité sont résolues mais
l’accès au serveur Web est beaucoup plus lent. Ces ralentissements sont très
difficilement calculables car ils sont très variables. L’ordre de grandeur reste
cependant en secondes.
Flux Applicatif 70
En effet Windows 2000 ne gère pas très bien les 2 cartes Ethernet ensemble. M.Borsa
aussi diplômant, a rencontré pas mal de problèmes avec une configuration présentant 2
cartes Ethernet. Pour ma part j’en ai rencontrés aussi, car lorsque l’on modifie certains
paramètres (passage du mode proxy en mode standard par exemple sur le browser), le
système ne fonctionne plus. Soit il faut attendre longtemps, soit booter les machines
client et serveur.
Ma configuration étant simple (peu de machines), cela ne pose pas trop de problèmes.
Cependant d’un instant à l’autre, le système devient instable sans aucune modification
de ma part.
5.9 Server Web Down
Il peut arriver que le serveur Web tombe en panne ou soit en réfection. De ce fait,
personne ne peut plus accéder à une page du site. Cependant avec le serveur ISA, si le
serveur Web est down, alors il va envoyer les données stockées dans son cache aux
clients.
Get Request Tentatives

From Client de connexion
To Server Web
Client If modified Since (Expires) Serveur Web
Serveur ISA
Response OK Pas de
From ISA Server réponse
To Client
Expires : 15h30
Date : 15h30
Age : 118
Cache control : max-age = 120
Messages d’erreurs
Données de la page transmises
Warning : 111 ISA Server. Some of this informations may be out of date
because of network problems. An attempt to reposnd this r equest from a remote
location was unsuccessful. The response has an expired version of the object
found in the cache.
Warning : 110 ISA Server. Some of this informations may be out of date
Lorsque le serveur Web est tombé, le serveur ISA, s’il possède les pages en cache,
peut envoyé les données de celles-ci à un client. Par contre comme on peut voir, un
message d’erreur est envoyé afin de communiquer au client qu’il y a un problème
réseau et que les données envoyées peuvent être périmées.
Pour le client, c’est comme si rien ne s’était passé. Pour lui, le serveur est toujours
accessible. Ces warnings sont présents surtout lorsque l’on cascade des serveurs ISA.
Une entreprise possédant un serveur ISA peut refuser d’afficher des pages périmées.
Flux Applicatif 71
5.10 Les principales commandes HHTP rencontrées
Certaines commandes http ont été découvertes grâce à l’utilisation du serveur ISA et
de la connexion proxy.
Ces commandes supplémentaires perçues sont au nombre de six.
Commande Explication
Cette commande signifie que lorsqu’on se connecte sur le
Proxy connection : Keep-Alive serveur ISA en mode proxy la connexion se fait en mode
keep -alive.
Cette commande est présente uniquement lors de
l’utilisation d’un proxy ou d’un gateway.
Elle fait simplement l’intermédiaire entre le client et le
Via serveur Web. Avec cette méthode on peut savoir du côté
serveur Web si la demande vient d’un client ou si elle a été
redirigée comme avec un serveur proxy.
(voir chapitre 14.45 RFC 2616)
Cette commande nous renseigne sur la date d’expiration du
Expire fichier.
Cette commande nous renseigne sur la date de connexion
Date au site.
Cette commande nous donne la différence entre l’heure
courante et l’heure de la dernière connexion. Cette valeur
sert uniquement au serveur ISA. Ainsi le client peut savoir
Age
si les données envoyées par le serveur ISA sont récentes ou
non.
Cette commande est envoyée par le serveur ISA lorsque
celui-ci veut remettre à jour son cache de façon
Active Caching Request
automatique. Cette commande n’a pas d’influence sur la
réponse du serveur Web.
Il existe cependant plusieurs commandes http qui font que le serveur ISA ne mettra
pas en cache les données. Ce sont souvent celles qui concernent les problèmes
d’authentification.
Ces commandes sont :
• Cache control : no-cache

• Cache control : private
• Pragma : no-cache
• www-authenticate
• set-cookie
voir page :
http://www.microsoft.com/TechNet/prodtechnol/isa/proddocs/isadocs/cmt_cachewhat.asp
Flux Applicatif 72
Lorsque l’on se connecte à un site avec un de ces paramètres sur le serveur Web, alors
les données ne seront pas stockées dans le cache ISA. Cette étude a déjà été menée
lorsque l’on se connectait sur le serveur Web et celui-ci nous retournait une commande
cache control : no-cache. C’est pourquoi je ne la referai pas ici.
5.11 Les fichiers LOG
Comme lorsque l’on était dans la configuration Client - Serveur Web (chapitre 3.5),
des fichiers log peuvent être créés. Même si ceux-ci ont plus d’informations que les
fichiers log sur IIS, ils restent pauvres. C’est pourquoi je ne les étudierai pas en détail.
En effet, ce que l’on peut en tirer comme informations se trouve dans une liste que
l’on peut configurer.
Elle se trouve sous : Monitoring dans la fenêtre principale du serveur ISA
En cliquant sur Properties et en allant dans

l’onglet Fields, nous pouvons choisir les différents
paramètres à afficher dans le fichier log.
Flux Applicatif 73
5.12 Qu’a-t-on gagné avec ISA ?
Avec l’installation d’un tel logiciel, nous remarquons que les données transférées entre
le serveur de cache ISA et le serveur Web sont diminuées. En effet, les données étant
stockées dans le serveur ISA, lorsqu’un client se connecte sur une page, alors celui-ci
se verra envoyer les données directement depuis ce serveur. Certes des requêtes
existent entre le serveur ISA et le serveur Web mais c’est juste pour savoir si des
fichiers ont été modifiés depuis le dernier accès sur la page et si le serveur ISA
possède dans son cache la page demandée.
Il faut savoir que généralement, le client se trouve dans un réseau local avec des
liaisons à 10 ou 100 Mbits/s. Ce chiffre est de beaucoup supérieur à la liaison physique
entre le serveur ISA et le serveur Web.
De ce fait lorsque le serveur ISA possède les données dans le cache, celles-ci sont très
rapidement chargées (vitesse du réseau local).
Les résultats que je trouve sont faussés par le fait que je ne simule que 2 clients et non
un réseau complet de clients. Par faute de temps, je ne pourrai pas tester le cas plus
réel en simulant un nombre plus grand de clients.
De plus, le réseau de l’EIG étant très rapide, je ne vois pas de différence lorsque je me
connecte sur un site Web avec ou sans le serveur ISA.
Ce que je constate c’est qu’en rajoutant une deuxième carte Ethernet sur le serveur
ISA, cela ralenti beaucoup le système.
Par contre, je peux faire une étude sur le gain de trafic.

Lorsque je me connecte à un site pour la première fois, ce gain est nul c’est comme si
je n’avais pas de serveur ISA. Par contre si les données, une fois transmises, sont
stockées dans le cache, alors lors de mon prochain accès mon gain sera de 100% par
rapport à l’échange entre ISA Server et le Web Server (aucun paquet échangé).
A cause des problèmes énoncés tout au long de ce chapitre, je n’irai pas plus loin dans
l’étude de gain de temps avec ISA. Il faut savoir que dans un cas réel le serveur ISA
devrait avoir un bon rendement au niveau du gain de temps. Mais de toute façon il est
sûr qu’un gain important au niveau du trafic est perçu (0 paquet sortant du serveur ISA
si le cache est encore valide ou quelques paquets de demande si la page a été modifiée
dans le cas où le cache ISA est expiré).
Une chose importante que l’on a avec le serveur ISA, est que l’adresse source que ce
soit avec une configuration d’une ou deux cartes Ethernet, ne sera jamais celle du
client mais toujours celle du serveur ISA.
Flux Applicatif 74
Chapitre 6 : Reverse Proxy
Lors des chapitres précédents, nous avons toujours testé le cas où le serveur Web se trouvait
hors de l’entreprise. Maintenant, je vais tester le cas où le serveur Web se trouve à l’intérieur
de l’entreprise avec une adresse privée, et un client se connecte sur celui-ci via l’adresse
publique du proxy. Le fait d’accéder à un serveur interne depuis l’extérieur s’appelle donc
reverse proxy.
Le but de cette fonction est d’isoler le serveur Web interne de l’entreprise par rapport à
l’extérieur. En effet, souvent les serveurs font l’objet d’attaques de personnes mal
intentionnées. A l’aide de cette fonction de reverse proxy, on fait croire au client qu’il se
connecte sur une adresse IP pour accéder à la page de l’entreprise, mais avec la fonction NAT
(Network Adress Translator), l’adresse du serveur Web n’est pas celle que le client tape.
Client
IP : 129.194.184.206
MASK 255.255.252.0 IP : 10.0.0.1
GATEWAY : 129.194.184.3 MASK 255.255.255.0
GATEWAY : 10.0.0.20
IP : 129.194.184.99 IP : 10.0.0.20
MASK 255.255.252.0 MASK 255.255.255.0
GATEWAY : 10.0.0.20 GATEWAY : 129.194.184.99
Internet
Server ISA Server Web

mode
Reverse Proxy
IP : 129.194.184.203
MASK 255.255.252.0
GATEWAY : 129.194.184.3
Client
ISA Server, nous permet de réaliser cette fonction de reverse proxy. Dans un cas réel, il
faudrait installer un Firewall afin que personne n’accède au serveur Web interne sans
s’authentifier. La fonction NAT du serveur ISA devrait être aussi installée.
Cependant pour installer la fonction NAT et/ou Firewall sur le serveur ISA qui se trouve
installé en mode cache, il faudrait installer le mode Integrated (voir chapitre 4.4).
C’est pourquoi ISA propose un service de publication du serveur Web interne simplifié.
Afin de l’installer correctement, il faut lui donner quelques paramètres. Voici en résumé les
paramètres à entrer.
Pour plus d’informations concernant l’installation du reverse proxy, voir le livre

« Configuring ISA Server 2000 » à partir de la page 612 chapitre « Publishing Services to the
Internet ».
Flux Applicatif 75
6.1 Installation de ISA Server en mode Reverse Proxy
Tout d’abord, il faut ouvrir ISA Management. Ensuite sous Netserver1 et properties,
on obtient une fenêtre
En cliquant sur Add, il faut rajouter la règle qui dit sur quelle adresse IP, le serveur
ISA va écouter les requêtes des clients. Les paramètres à choisir sont les suivants :
Champs Paramètres
Server Netserver1
IP Adress 129.194.184.99
Display Name Optionnel, nous permet de rentrer un nom plus
représentatif que le nom de la machine.
Authentification Integrated, Basic, Client Certificate. Ce champ nous
permet de dire comment le client doit s’authentifier sur le
serveur ISA pour accéder au serveur Web.
Server Certificate Si le mode d’authentification doit demander un certificat,
il faut entré ici le nom du certificat.
Dans cette fenêtre, on peut aussi

donner le nombre de connexion
TCP possibles sur le serveur ISA.
Les différents paramètres que l’on
peut régler sont visibles dans la
fenêtre à droite.
Flux Applicatif 76
Maintenant que nous avons dit sur quelle adresse IP les clients se connectent, il faut
encore pouvoir diffuser les données du serveur Web vers l’extérieur. Pour cela il faut
aller dans Publishing -> Web Publishing Rules -> New.
Ensuite, il suffit de suivre les instructions qui apparaissent à l’écran. Cependant,

lorsque l’on nous demande si l’on veut rejeter les demandes (Discard the request) ou
rediriger vers un serveur Web interne (Redirect the request to this internal Web server
(name or IP address)), il faut indiquer cette deuxième option et donner l’adresse du
serveur Web comme dans la capture
ci-dessous.
Adresse
du serveur
Web interne
Maintenant le serveur Web est prêt à être vu par les clients externes à l’entreprise. Il
reste à effectuer quelques tests afin de voir la différence entre une connexion en mode
proxy et en mode reverse proxy.
Flux Applicatif 77
6.2 Tests en mode Reverse Proxy
Deux tests seront effectués dans ce mode de fonctionnement d’ISA serveur. Le

premier, consistera simplement à ce qu’un client externe de l’entreprise se connecte
sur le serveur Web interne. Le second sera simplement le fait qu’un deuxième client se
connectera en même temps que le premier et nous verrons comment le serveur ISA
gère cela. Est-ce que le cache peut-être partagé avec le mode reverse proxy, comme il
l’est avec le mode proxy ?
Toutes ces questions seront traitées dans les différentes études qui suivront.
6.2.1 Connexion d’un client sur le serveur Web interne
Lorsque le client se connecte sur le serveur Web d’une entreprise, il doit taper
www.domaine.ch par exemple. Dans mon cas, pour simplifier la chose, je n’ai pas mis
de serveur DNS (donc pas d’ Active Directory, ni de création de domaine). C’est
pourquoi lorsque celui-ci se connecte sur le serveur, il devra taper l’adresse IP pour s’y
connecter. Soit 129.194.184.99. Le serveur ISA se chargera de router la requête vers le
serveur Web interne.
Get Request
From Client
to 129.194.184.99
Client
Serveur Web
Serveur ISA
Connexion impossible
Il faut une
authentification pour
exécuter la requête
OK
On tape les données du Login et Get Request
login et du password et password Via ISA 10.0.0.20
éventuellement du acceptés Host 10.0.0.1
domaine If modified Since (Last Modified)
(voir chapitre 11.3 partie Referer http://129.194.184.99
codage Base 64)
Response Response
Not Modified ou OK Not Modified ou OK
Date : Date Date : Date
Cache control : max-age = 60 Cache control : max-age = 60
Flux Applicatif 78
Lors de cette première acquisition, nous remarquons que plusieurs commandes http
sont venues s’ajouter à celles précédemment utilisées en mode proxy.
Celles-ci sont :
Commandes Fonctionnalités
Host Cette commande indique simplement le nom ou l’adresse que
l’on veut atteindre
Voir RFC 2616 chapitre 14.23
Referer Cette commande sert au serveur Web pour savoir à qui il doit
répondre.
Voir RFC 2616 chapitre 14.36
En ce qui concerne la commande Referer, elle est toujours présente dans le paquet
http, mais elle nous aide à mieux comprendre le principe du Reverse Proxy. C’est
pourquoi je l’ai décrite ici. On la retrouve également dans le mode proxy.
On voit donc que le serveur ISA, demande d’abord une authentification de différents
types suivant sa configuration. Le client entre le login et le password (Codage en Base
64). Si le login et le password sont corrects, alors il envoie une requête au serveur
Web pour savoir si la page a été modifiée ou non. Il rajoute dans les commandes le
champ Host et Referer comme énoncé ci-dessus. La réponse du serveur est simple. Il
dit simplement au serveur ISA si la page a été modifiée et l’heure de la connexion,
avec bien sûr le champ http concernant la validité de la page max-age = xxx ou autre.
Dans le cas où le login et le password sont erronés, alors le serveur ISA refuse l’accès
et affiche au bout de trois erreurs, une page indiquant que la connexion est impossible.
Le principe que j’avais exposé pour le proxy qui concerne la validité des fichiers sur
ISA est aussi valable en reverse proxy.
C’est pourquoi je ne traiterai pas tous les cas possibles comme je l’ai fait en mode
proxy.
Je pense que l’acquisition de la page précédente, suffit à la compréhension du reverse
proxy.
Il reste un point à faire. C’est celui, où plusieurs clients accèdent à la même page en
même temps.
Flux Applicatif 79
6.2.2 Connexion de deux clients sur le serveur Web
Maintenant, je vais simuler un deuxième client qui se connecte sur le même serveur
Web au même moment que le premier client.
Les deux clients qui se connectent, doivent s’authentifier. Une fois cette étape passée,
le serveur Web ou le Serveur ISA (suivant les paramètres du cache de ISA) doit
retourner les données au client.
La première requête arrive au serveur Web, si les données ne sont pas dans le cache.
Cependant, si ISA possède les données de la page dans son cache mais expirées, il va
tout de même demander au serveur Web si les données ont été modifiées.
Si oui elles sont renvoyées et stockées dans le cache. Sinon le serveur Web envoie Not
modified.
Si l’on admet qu’ISA ne possède pas la page en cache, alors la première requête du
premier client aura une réponse du serveur.
La requête du deuxième client n’ira pas jusqu’au serveur Web mais s’arrêtera au
serveur ISA puisqu’entre temps, ISA aura stocké la page accédée par le premier client
dans son cache.
Dans le cas où les données dans le cache d’ISA sont encore valides, celles-ci seront
entièrement chargée depuis ISA (comme pour le proxy) et aucune requête ne sera faite
au serveur Web.
Get Request Œ
from client A
Client A To Server Web Serveur ISA Serveur Web
Œ
Get Request • Login et Password Première requête
from client B Client A et Client B qui arrive
To Server Web OK Get Request
If modified Since (Date)
Client B
Response Œ Response Œ
OK ou not modified OK ou not modified
à la première requête à la première requête
Response •
OK ou not modified
à la deuxième requête
Comme on peut s’apercevoir avec la figure de la page précédente, une seule

requête arrivera jusqu’au serveur Web. Les autres s’arrêteront au serveur ISA et les
pages demandées seront chargées depuis le cache de celui-ci.
Flux Applicatif 80
6.3 Conclusion
L’étude d’ISA à montré qu’il est possible simplement avec le mode cache, de créer un
serveur de cache, un proxy et un reverse proxy.
Ce dernier étant néanmoins restreint du fait qu’aucune sécurité « sévère » n’est
implémentée sur le serveur ISA lorsque l’on installe uniquement le mode cache. Dans
le cas ou l’on installe le mode integrated, alors le serveur devient beaucoup plus sûr au
niveau des accès (IP Packet Filtering actif).
Ce type de serveur (au niveau cache) est intéressant lorsque la connexion vers
l’extérieur n’a pas un trop gros débit utile. En effet, plus le débit utile est grand, plus le
gain que l’on aura avec un serveur de ce type sera petit.
Les diverses fonctionnalités d’ISA sont faciles d’utilisation. Il est malheureusement

dommage que les différents modes de mise en cache aient des paramètres plus ou
moins fixes et que l’on ne puisse pas les modifier à sa guise.
Il est aussi dommage qu’ISA ne permette pas de stocker diverses pages comme celles
avec les champs décrit au chapitre 5.10. Ceci étant compréhensible d’un point de vue
sécurité mais pour un logiciel qui se dit aussi Firewall, il serait intéressant que
l’administrateur du serveur ISA puisse accéder à ces données sans pour autant que
d’autres utilisateurs puissent y accéder.
En ce qui concerne son installation, elle est très simple. Il suffit de suivre les
indications qui apparaissent à l’écran et le tour est joué.
Pour conclure, je dirai que même si ce logiciel a plus de fonctionnalité au niveau du

Firewall qu’au niveau du cache, il reste un logiciel simple et intéressant pour des
entreprises avec un connexion à Internet pas trop rapide. J’imagine typiquement ce
logiciel pour une entreprise possédant RNIS ou ADSL avec un maximum de 1000
employés. Même si les tests de Microsoft disent que le serveur ISA peut supporter
plus, j’estime qu’au delà, une connexion vers l’extérieur plus rapide est conseillée.
Flux Applicatif 81
Chapitre 7 : LDAP Principes
Il y a encore quelques années, lorsqu’une entreprise possédait une base de donnée, elle devait
la tenir à jour régulièrement. Ce phénomène s’est compliqué avec l’arrivée de plusieurs bases
de données au sein d’une même entreprise. Imaginons par exemple, que celle -ci se divise en
départements, que chacune possède une base de données identique (par exemple de clients) et
que celui-ci change d’adresse. Celle-ci doit être modifiée dans chacun des serveurs et de façon
manuelle.
Maintenant, si plusieurs entreprises sont sur des systèmes d’exploitations différents et qu’elles
se partagent des bases de données, il n’est pas possible de faire une duplication de la base. Il
faut reprendre la base de données à zéro et ajouter une par une les données inscrites.
C’est pourquoi est né le protocole LDAP (Lightweight Directory Access Protocol). Il permet
de gérer les modifications de données dans la base et de faire en sorte que celles-ci se
répercutent sur les autres serveurs même sur les systèmes d’exploitations différents. Il permet
aussi de copier des bases de données complètes (Replication) ou d’aller consulter une autre
base de données distante (Referral).
De plus ce protocole s’applique donc à tout système d’exploitation. Le serveur LDAP ainsi
que le browser du côté client peuvent parfaitement fonctionner sous Windows, Linux ou Unix.
Avec LDAP, nous ne parlerons plus de base de données mais d’annuaire. Sa fonction
première est de retourner un ou plusieurs attributs d’un objet suivant des critères de recherche.
Un annuaire LDAP peut être représenté sous forme d’un arbre de la manière suivante.
o=eig
ou = telecommunication ou = informatique
cn = TE3 cn = TE2 cn = IN3 cn = IN2
uid = pgaio
Lorsque l’on recherche une donnée dans l’annuaire LDAP, celle-ci prendra un temps quasi
nul. En effet, nous n’avons pas besoin de scruter l’annuaire comme on le fait avec une base de
données pour trouver la valeur recherchée. Cet fois, l’emplacement de la valeur recherchée est
connue car à l’arborescence de l’annuaire.
Cependant, l’annuaire LDAP est beaucoup moins performant en écriture.
Le protocole LDAP utilisé pour accéder à ce type LDAP

d’annuaire, se situe au dessus de TCP. TCP
IP
ETHERNET
Flux Applicatif 82
7.1 Les concepts de LDAP
Le protocole LDAP définit une communication entre client et serveur. Il fournit à

l’utilisateur, des commandes pour se connecter, se déconnecter, rechercher, comparer,
créer, modifier ou effacer des données dans l’annuaire.
La plupart des logiciels serveurs LDAP proposent également un protocole de

communication serveur/serveur permettant ainsi l’échange de données entre annuaires
(Replication par exemple).
Ils permettent aussi de faire référence à d’autres serveurs dans le cas où la valeur
recherchée ne se trouverait pas sur le serveur en question (Referral)
Le protocole LDAP est normalisé et défini par la RFC 2251. Dans sa version 3, il
définit la communication serveur/serveur ainsi que les referrals. En ce qui concerne la
réplication, la RFC n’a pas encore été crée mais un semblant de RFC est présent à
l’adresse http://globecom.net/ietf/draft/draft-merrells-ldup-model-01.txt.
Dans la version 2 du protocole, il n’était pas possible de faire des referral ainsi que de
la replication. (voir l’adresse ci-dessous pour les différence entre LDAP V2 et V3).
http://developer.novel.com/research/devnotes/1998/august/02/d980802_.pdf
Le protocole LDAP utilise le format de codage Basic Encoding Rule (BER).

Nous verrons plus tard, que la syntaxe ASN1 entre aussi en jeu.
7.2 Les principes de LDAP
Un annuaire LDAP a des attributs normalisés. Lorsque l’on crée notre annuaire, nous
le créons sous forme d’un arbre. Ce qui facilite la recherche dans l’annuaire. Chaque
entrée de l’annuaire aura un DN (Distinguish Name) unique, qui correspondra à
l’endroit où se trouve l’objet en question.
Exemple d’annuaire :
o = entreprise
ou = Genève ou = Vaud
cn = Carouge cn = Meyrin cn = Pully cn = Ouchy

uid = d
uid = d
uid = b
uid = b
uid = d
uid = x
uid = y
uid = b
uid = x
uid = a
uid = c
uid = e
uid = c
Flux Applicatif 83
Ainsi grâce à cette arborescence, nous pouvons directement donner le dn d’une

personne. Si je recherche par exemple le uid = d , l’annuaire me retournera deux
valeurs :
dn : uid=d, cn=Carouge, ou=Genève, o=entreprise
dn : uid=d, cn=Ouchy, ou=Lausanne, o=entreprise.
les noms d’attributs les plus communs sont :

Attribut Définition Commentaire
o Organization Généralement en haut de
l’arbre
ou Organization Unit Généralement en dessous de
l’Organization.
cn Group Ces groupes peuvent être créés
où l’on veut dans l’annuaire.
C’est uniquement ici que l’on
peut ajouter des membres.
uid User C’est là où l’on rentre les
données des utilisateurs. Où ils
sont créés.
D’autres attributs existent, cependant, je ne les énoncerai pas ici. Pour les consulter, se
référer au très bon document sur le site :
http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap-livre.html
Plusieurs données sont présentes à chaque niveau de l’annuaire. En effet, on ne peut

pas rajouter tous les attributs optionnels à l’organisation. Par exemple, on ne pourra
pas ajouter le mail à l’organisation.
Ces attributs sont classés dans un tableau toujours à cette même adresse. En voici un
petit résumé.
L’attribut général s’appelle ObjectClass. Sans cette classe, on ne pourrait pas ajouter
par exemple, un utilisateur. C’est elle qui va gérer toutes les possibilités d’entrées dans
l’annuaire LDAP.
Type d’attribut Attributs optionnels possibles
Mail
Mobile
ObjectClass : inetOrgPerson
Défini les entrées pour les personnes Postal Adress
Common Name (obligatoire)
Surname (obligatoire)
Telephone Number
ObjectClass : organizationalUnit
Défini les entrées pour les Organization Unit Postal Adress
Description
Telephone Number
ObjectClass : organization Postal Adress
Défini les entrées pour les organisations Description
BusinessCategory
Flux Applicatif 84
7.3 Les annuaires LDAP
Un annuaire est une base de données spécialement optimisée pour la recherche, le

survol et la lecture rapide d'informations.
Les annuaires contiennent de manière générale des informations descriptives
caractérisées par des attributs (nom, mail, téléphone etc…) et proposent des filtres de
recherche.
Les annuaires sont configurés pour répondre en un temps quasi nul à de grands
volumes de requêtes d'interrogations ou de recherches.
Ils peuvent en outre avoir des fonctions de replication ou de referral.
Ainsi les commandes qui peuvent être effectuées seront définies dans le tableau de la
page suivante.
Opération LDAP Description

Search Recherche dans l’annuaire d’objets à partir de critères
Compare Comparaison d’un contenu de deux objets
Add Ajout d’une entrée
Modify Modification du contenu d’une entrée
Delete Suppression d’une entrée
Rename (Modify DN) Modification du DN d’une entrée
Bind Connexion au serveur
Unbind Déconnexion
Abandon Abandon d’une opération en cours
Extended Opérations étendues (LDAP Version 3)
Lors d’une recherche d’une donnée, celle-ci peut s’effectuer sur plusieurs niveau de
l’annuaire. Le champ scope défini cette profondeur.
Il peut contenir trois valeurs :
o=eig
Scope = base
uid = toto
Flux Applicatif 85
o=eig
Scope = onelevel search
uid = toto
o=eig
Scope = subtree
uid = toto
7.4 Les choix effectués
Il existe diverses possibilités concernant le serveur et le client à utiliser.

A la suite de la discussion avec M.Dutheil, j’avais le choix entre OpenLDAP ou
iPlanet comme serveur.
M.Garcia ancien étudiant de l’école d’Ingénieurs de Genève, travaillant maintenant
dans une entreprise informatique et ayant fait des projets sur LDAP, m’a conseillé le
serveur iPlanet. C’est pourquoi ma décision finale a été de choisir ce serveur pour la
gestion de mon annuaire.
En ce qui concerne le choix du client, il y avait aussi deux possibilités. Soit le logiciel
sur une base JAVA ou un soft tournant sur Windows uniquement. Mon choix c’est
finalement porter sur le premier, car le client qui tournait sous Windows ne me
permettait pas de faire des recherches dans l’annuaire. De plus la version freeware que
l’on trouve sur Internet du logiciel tournant sur Windows est limitée.
Flux Applicatif 86
7.4.1 Installation du serveur iPlanet
Tout d’abord, il faut charger le logiciel iPlanet Directory Server 5.0 sur le site
www.iplanet.com
Ensuite, il faut le décompresser et pour finir l’installer. Je ne décrirai pas l’installation
dans ce chapitre car elle est plus que basic. Il suffit juste d’indiquer les mots de passe à
utiliser et le nom de l’administrateur qui peut se connecter sur ce serveur en plus du
Directory Manager qui est un « super administrateur ». C’est lui qui peut modifier des
données dans l’annuaire et à distance via le browser du client.
7.4.2 Installation du client
Deux logiciels sont à notre disposition, le premier est un browser LDAP sur un plate-
forme JAVA.
Il suffit de le télécharger à l’adresse http://www.iit.edu/~gawojar/ldap . Pour
l’installation, il suffit de suivre le guide d’installation fourni sur le site. De plus il nous
faudra télécharger JAVA. Toute la procédure est indiquée dans le document.
Ce logiciel se nomme : LDAP Browser/Editor 2.8.1
Le deuxième programme à disposition est un software de Softerra. Il suffit de le

télécharger à l’adresse : http://www.softerra.com/ et de choisir le lien download.
Aucune installation n’est requise. Il suffit de lancer l’application.
Ce logiciel se nomme : Softerra LDAP Browser/Editor 1.0
Après avoir installé les deux logiciels et les avoir comparé, j’estime que le premier est
sensiblement meilleur, car il permet de rechercher une donnée dans l’annuaire auquel
on se connecte.
7.5 Création de l’annuaire LDAP
Maintenant que nous avons tout les

logiciels à disposition, nous sommes prêts à
ral
créer notre annuaire. fer
Re
Voici l’architecture choisie :
Server iPlanet
Eleves
Connexion sur l'annuaire
Client LDAP Re
fer
Server iPlanet ral
EIG
Server iPlanet
Professeurs
Flux Applicatif 87
7.5.1 Architecture Annuaire EIG
o=eleves o=eig o=professeurs
Referral sur le Referral sur le

serveur eleves ou = telecommunication ou = informatique serveur professeurs
Liste des membres Liste des membres

dynamiques du dynamiques du
serveur élèves (TE3) serveur élèves (IN3)
+ +
professeurs (TE3) professeurs (IN3)
7.5.2 Architecture Annuaire Elèves
o=eleves
cn = IN3 cn = TE3 ou = Liste d'élèves
Liste des Liste des

membres membres
statiques statiques
uid = PGaio (XX)
(X) (XX)
uid = DCotte (X)
uid = PLogean (XX)
uid = MPasquali (XX)
uid = YSouchon (XX)
uid = SBorsa (XX)
uid = SBancal (X)
Liste d'élèves
Flux Applicatif 88
7.5.3 Architecture Annuaire Professeurs
o=professeurs
cn = IN3 cn = TE3 ou = Liste des professeurs
Liste des Liste des

membres membres
statiques statiques
(X) (XX)
uid = EJenny (X) + (XX)
uid = GLitzistorf (XX)
Liste des professeurs
7.5.4 Création de membres
Maintenant que nous avons créé nos annuaires, il reste à ajouter des membres dans des
groupes. En effet, un élève appartient à une classe bien définie (TE3 ou IN3 en
l’occurrence) et de même pour un professeur.
Cependant le fait de créer des membres posent quelques problèmes. Nous pouvons
créer des membres statiques ou dynamiques. Il faut savoir que l’ajout d’un membre
statique peut se faire uniquement d’un point de vue local. C’est-à-dire, que l’utilisateur
qui va être choisi doit se trouver dans l’annuaire de la machine en question. Nous ne
pouvons donc pas faire un referral sur un autre serveur et créer un membre statique
d’un groupe local qui se trouve sur une machine distante.
Referall
serveur iPlanet LOCAL Liste d'élèves
sur le serveur iPlanet
o=eig
DISTANT
uid = PGaio
uid = DCotte
ou = telecommunication ou = informatique uid = PLogean
uid = MPasquali
uid = YSouchon
uid = SBorsa
uid = SBancal
cn = TE3
Membre STATIQUE IMPOSSIBLE
Flux Applicatif 89
A cause de cette restriction, j’ai dû créé des membres dynamiques. Cependant, deux
configurations sont possibles avec les membres dynamiques. La première consiste à
créer sur le serveur distant des groupes de membres statiques. Ainsi la gestion des
membres ne se fera pas sur le serveur local.
serveur iPlanet LOCAL Referral

o=eig
serveur iPlanet DISTANT
o=eleves
cn = TE3 cn = TE3 ou = Liste des élèves
Membres Dynamiques Liste des

membres
statiques uid = PGaio
(X) uid = DCotte
uid = PLogean
uid = MPasquali
uid = YSouchon
uid = SBorsa
Membres statiques uid = SBancal
Comme on peut le voir sur ce schéma, nous avons à l’intérieur du serveur distant, une
liste d’élèves en vrac, avec la création d’un groupe de membres statiques
correspondant aux élèves de la TE3. A l’aide d’un referral sur le serveur o=eleves, je
pourrai créer des membres dynamique du groupe TE3 distant sur mon serveur local.
Cependant cette architecture a une restriction. L’administration des membres se fait

sur le serveur distant. Il se peut que si cette base de données soit commune à plusieurs
entreprises, l’administrateur de celle-ci ne veuille pas s’amuser à gérer les différents
annuaires. C’est pourquoi, une deuxième architecture propose de créer des membres
dynamiques d’une façon plus précise en indiquant le nom (uid) de la personne qui sera
membre du serveur local.
serveur iPlanet LOCAL Referral

o=eig
serveur iPlanet DISTANT
o=eleves
cn = TE3 ou = Liste des élèves
uid = PGaio
uid = DCotte
uid = PLogean
Membres Dynamiques uid = MPasquali
uid = YSouchon
avec lien sur un uid précis uid = SBorsa
uid = SBancal
Flux Applicatif 90
Avec cette seconde architecture, l’administrateur local, peut gérer les membres de
l’annuaire distant.
Pour ma part je considère la première solution comme la plus simple au niveau de la
gestion des membres. Certes le fait que l’administrateur distant ne veuille pas gérer les
membres des autres est un problème mais il me semble que dans une entreprise
sérieuse, la gestion des utilisateurs ne doit pas poser de problèmes de ce genre.
7.6 Conclusion
Dans ce chapitre, j’ai exposé quelques principes de LDAP. Cependant l’objectif

principal est de comprendre le protocole qui est utilisé pour un échange de données
dans l’annuaire. C’est pourquoi la théorie sur LDAP ne sera pas plus détaillée. Pour
plus de renseignements sur LDAP au niveau théorique, se référer aux très bons
documents aux adresses :
http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap-livre.html
http://www.cru.fr/ldap/tutorial/tutorial_ldap.pdf .
Lors des chapitres suivants, je montrerai comment mettre en place un referral

(chapitre 9) ainsi qu’une replication (chapitre 10) et ce que cela implique au niveau du
protocole.
Cependant avant d’étudier ces applications, il faut d’abord étudier et comprendre le
protocole LDAP. Pour cela, je ferai plusieurs tests entre un client et un serveur iPlanet
(chapitre 8).
Flux Applicatif 91
Chapitre 8 : LDAP Protocole
Dans ce chapitre, je vais présenter le protocole LDAP à un niveau beaucoup plus approfondi.
Je ne me contenterai pas d’énoncer ces principes comme au chapitre 7, mais j’irai dans l’étude
au niveau hexadécimal du protocole.
En effet, la première partie de ce chapitre consistera à comprendre comment le protocole
LDAP est transmis. Comme pour TCP ou IP, j'essayerai de faire ressortir la structure de la
trame du protocole LDAP.
Par la suite j’étudierai un simple échange LDAP lorsque l’on accède à un annuaire.
Je ferai aussi une étude sur le comportement d’un referral.
Pour terminer, je ferai une réplication entre deux serveurs et regarderai toujours au niveau du
protocole, ce que cela engendre comme trafic.
Cependant, avant de regarder attentivement les paquets qui sont transmis, regardons comment
se passe un échange entre client et serveur LDAP.
Connexion TCP
Bind Request (0)
Bind Response (1)
Search Request (3)
Search Response (4)

Client
Search Response Simple (5)
Server iPlanet
Lorsque l’on initialise la connexion avec l’annuaire, une connexion TCP est tout d’abord
établie. Ensuite c’est une connexion LDAP qui est établie par le biais des paquets Bind
Request et Bind Response. Une fois connecté, le client fait une recherche (Search Request) sur
le serveur LDAP et celui-ci lui renvoie les données avec Search Response. Une fois que le
serveur a envoyé toutes les données, alors celui-ci envoi Search Response Simple pour dire
qu’il a fini d’émettre.
Le numéro inscrit à côté de ces paquets est le numéro d’application LDAP.
Tout les paquets seront décrits en détail dans les chapitres suivants.
Flux Applicatif 92
8.1 Structure de la trame du protocole LDAP
Comme énoncé dans le chapitre précédent, le protocole LDAP se situe au dessus de la

couche TCP.
En regardant plus attentivement un paquet LDAP, on s’aperçoit que les données

transmisent à l’intérieur de ceux-ci sont en réalité issues de la structure du langage
ASN1 (Abstract Syntax Notation 1) et ensuite codés en BER (Basic Encoding Rules).
Ainsi chaque paquet de type ASN1 (donc chaque paquet LDAP) est composé d’un
champ type (Type) suivi d’un champ longueur (Length), suivi d’un champ contenu
(Content).
Type Length Content
Dans le cas où le champ Length est nul (00), le champ Content ne sera pas transmis.
8.1.1 Le champ Type
Le champ Type est défini sur 8 bits et de la manière suivante :
7 6 5 4 3 2 1 0
Primitive
Type Class Tag Value
Construct
Les deux premiers bits de ce champ type contiennent des informations sur le type des
informations qui seront transmises. Voici les différents cas possibles :
Bit N°7 Bit N°6 Type Class Commentaires

Ce type de classe peut
être Primitif ou
0 0 Universal construit. C’est ici que
l’on défini le type de
données à transmettre.
Ce type est spécifique
à une application.
0 1 Application
Dans mon cas au
serveur iPlanet.
Ces deux types sont les plus répandus dans le standard LDAP. Cependant, il en existe
encore deux qui sont plus spécifiques aux programmeurs d’une entreprise.
Flux Applicatif 93
Bit N°7 Bit N°6 Type Class Commentaires

Ce type est spécifique
à une entreprise.
1 0 Private
Application
entièrement privée.
Ce type permet
d’ajouter une
1 1 Context Specific
application de type
privé.
Le type de classe Universal est le seul à être normalisé. Dans le tableau ci-dessous, je
vais énoncés quelque unes des valeurs possibles. Pour voir toutes les valeurs possibles,
consulter le site http://people.ne.mediaone.net/wasser/ASN1/BasicEncodingRules.html
Suivant les types de ces valeurs, ceux-ci seront alors définis comme primitifs (0) ou
construits (1). Cela affectera la valeur du bit N°5 du champ Type.
Un type primitif contient une seule valeur dans son champ Content, tandis que le type
Construit, peut contenir plusieurs valeurs à la suite.
Primitif
Type Tag Type des données
construit
Universal 1 Primitif Boolean
Universal 2 Primitif Integer
Universal 3 Primitif Bit String
Universal 4 Primitif Octet String
Universal 5 Primitif Null
Universal 6 Primitif Object Identifier (OID)
Universal 10 Primitif Enumerated
Universal 16 Construit Sequence
Universal 17 Construit Set
Il nous reste maintenant, à définir la valeur du champ Tag Value. Cette valeur est
simplement la valeur soit universal soit de l’application utilisée. Par exemple, si je
veux faire une application LDAP de type Search Request ces 8 bits seront :
7 6 5 4 3 2 1 0
0 1 0 0 0 0 1 1
}
Type Application Primitif Application N°3 Search Request
Flux Applicatif 94
Avec le tableau de la page précédente, nous voyons que LDAP à défini des numéros
d’applications pour chacune de ses requêtes ou réponses.
En effet, voici les commandes LDAP les plus courantes.
Voir RFC 1777 (LDAP Version 2) et RFC 2251 (LDAP Version 3)
Numéro de Nom de l’application

l’application
0 Bind Request
1 Bind Response
2 Unbind Request
3 Search Request
4 Search Response
5 Search Response Simple
6 Modifiy Request
7 Modify Response
8 Add Request
9 Add Response
10 Del Request
11 Del Response
14 Compare Request
15 Compare Response
16 Abandon Request
19 Search Response Reference
23 Extended Request
24 Extended Response
8.1.2 Le champ Length
le second champ présent dans une structure de type ASN1 est le champ Length . Celui-
ci à priori nous indique simplement la longueur des données du champ Content.
Cependant, si ce champ est plus petit que 128 bits, alors la valeur hexadécimale du
champ Length sera de la longueur du champ Content. Si le nombre de bits dépassent
cette valeur alors le champ Length indiquera 81 en hexadécimal et la longueur du
champ content sera définie dans l’octet suivant. Il se peut cependant que le champ
Content soit d’une longueur indéfinie. Dans ce cas le champ Length indiquera toujours
la valeur 80 en hexadécimale. Ce cas peut se produire lorsque l’on transmet le sommet
d’un arbre sans savoir qui se trouve en dessous ou lorsque le décodage n’arrive pas à
ce faire.
Length ≤ 128 Bits Codage normal en hexadécimal

Length > 128 bits Valeur de codage = 81 en hexadécimal et suite du codage
de la longueur sur le prochain octet.
Valeur de codage = 82 en hexadécimal et suite du codage
Length > 256 Bits
de la longueur sur les deux prochains octets.
Flux Applicatif 95
8.1.3 Le champ Content
C’est le champ où les données sont transmises réellement. La structure de ce champ

est la suivante :
Si l’on a le type primitif comme Type Class, alors dans le champ Content, il y aura
uniquement, la donnée correspondant à ce type.
Au contraire, si on a le type construit, cela veut dire que dans ce champ, plusieurs
valeurs seront transmises.
Ainsi avec le type primitif on a :
Type Length Content
Tandis qu’avec le type construit on aura :
Type Length Content
Type Length Content Type Length Content
Grâce à cette encapsulation, plusieurs données de même type (Application ou

Universal), pourront être insérées l’une derrière l’autre. Ceci aura pour effet, un gain
de temps et de trafic.
Maintenant que nous avons décrit toutes les possibilités qu’offre LDAP au niveau de
son protocole, il reste à étudier un paquet pour que l’explication soit plus parlante.
Pour cela j’ai choisi un paquet Search Response que je détaillerai de fond en comble.
Il faut bien se rendre compte que la structure de ce paquet est la même que pour un
autre. C’est pourquoi je n’en étudierai qu’un seul.
Flux Applicatif 96
8.2 Etude détaillée du paquet Search Response
Ce paquet est la réponse au paquet Search Request.

Nous avons dans ce paquet toutes les données transmises par le serveur lors d’un accès
à distance sur l’annuaire.
Voici ce que l’analyseur nous donne :

(Je ne détaillerai que le protocole LDAP)
Source Adresse Destination Adresse
Annuaire LDAP Client LDAP

129.194.187.52 129.194.184.203
TCP :
Length 96 bytes
Source port : 389
Destination port : 4300
LDAP : ProtocolOP : SearchResponse (4)

LDAP : Message ID
LDAP : ProtocolOp = SearchResponse
LDAP : Object Name = cn=te3,ou=telecommunication,o=filiere,o=eig
LDAP : Attribute Type = objectclass
LDAP : Attribute Value = top
LDAP : Attribute Value = groupofuniquenames
Maintenant, si l’on regarde ce qui correspond en hexadécimal, nous aurons :

30 5E 02 01
LDAP : Message ID
04
64 59 04 2B
63 6E 3D 54 45 33 2C 6F 75 3D 74 65 6C 65 63 6F 6D 6D 75 6E 69 63
61 74 69 6F 6E 2C 6F 3D 66 69 6C 69 65 72 65 2C 6F 3D 65 69 67
30 2A 30 28 04 0B 6F 62 6A 65 63 74 63 6C 61 73 73
31 19 04 03 74 6F 70
04 12 67 72 6F 75 70 6F 66 75 6E 69 71 75 65 6E 61 6D 65 73
Flux Applicatif 97
Pour comprendre à quoi correspondent exactement ces valeurs hexadécimales

représentées au dessous des champs LDAP, se référer aux pages suivantes qui
montrent dans le détail, quelles sont les informations contenues dans chaque paquet.
La toute première valeur en hexadécimal est de 30. Ce n’est pas un hasard, c’est
comme cela que l’on reconnaît que les données qui suivent sont du type ASN1.
Regardons plus en détail ces parties de paquets. Il faut toujours tenir d’œil, la forme
d’une trame : Type, Lenght, Content

30 5E 02 01
LDAP : Message ID
04
Structure de la Data en hexadécimal

Décodage
trame
30 00 1 1000
Type Univeral (00) de type construit (1)
et de type Sequence (10000 = 16)
Length 5E Length = 94 bytes restant à transmettre
Type 02 Donnée de type Integer
Content Length 01 De longueur = 1 byte
Content 04 Message ID

64 59 04 2B
63 6E 3D 54 45 33 2C 6F 75 3D 74 65 6C 65 63 6F 6D 6D 75 6E 69 63
61 74 69 6F 6E 2C 6F 3D 66 69 6C 69 65 72 65 2C 6F 3D 65 69 67

Décodage
trame
64 01 1 00100
Type Application (01) de type construit (1)
et le choix N°4= SearchResponse
Length 59 Length = 89 bytes restant à transmettre
Type 04 Donnée de type Octet String
Length 2B De longueur = 43 bytes
63 6E 3D 54 45 33 2C 6F 75
Content 3D 74 65 6C 65 63 6F 6D 6D
cn=te3,ou=telecommunication,o=filiere,o=eig
Content 75 6E 69 63 61 74 69 6F 6E
2C 6F 3D 66 69 6C 69 65 72
65 2C 6F 3D 65 69 67
Flux Applicatif 98

30 2A 30 28 04 0B 6F 62 6A 65 63 74 63 6C 61 73 73
Structure de la trame Data en

Décodage
hexadécimal
00 1 1000
Type 30 Univeral (00) de type construit (1)
Length 2A Length = 42 bytes restant à transmettre
00 1 1000
Type 30 Univeral (00) de type construit (1)
Length 28 De longueur = 40 bytes
Content
Length 0B De longueur = 11 bytes
Content
6F 62 6A 65 63 74
Content objectclass
63 6C 61 73 73

31 19 04 03 74 6F 70
04 12 67 72 6F 75 70 6F 66 75 6E 69 71 75 65 6E 61 6D 65 73

Décodage
trame
00 1 10001
Type 31 Universal (00) de type construit (1) et de type
Set (10001 = 17)
Length 19 Length = 19 bytes restant à transmettre
Content Length 03 De longueur = 3 bytes
Content 74 6F 70 TOP
Length 12 De longueur = 3 bytes
Content
67 72 6F 75 70 6F 66 75 6E
Content groupofuniquenames
69 71 75 65 6E 61 6D 65 73
A l’aide de ces captures, on remarque bien que la suite Type, Length, Content est bel et
bien respectée. Ensuite suivant le type de données à transmettre, le codage va être
différent (Application Search Request(63), Application Search Response (65), etc…).
De plus lorsque l’on veut transmettre plusieurs données de même type, il n’est pas
nécessaire de renvoyer un nouveau paquet entier avec le champ type = universal ou
Application par exemple. C’est le cas dans le dernier paquet traité.
Flux Applicatif 99
8.3 Accès à un annuaire
Lorsque j’accède à un annuaire, je dois me connecter sur celui-ci. Je dois tout d’abord
effectuer une connexion TCP classique, puis une connexion LDAP.
Pour cela, deux paquets servent à la connexion. Le paquet Bind Request qui demande
la connexion et le paquet Bind Response qui répond à la requête avec des paramètres
suivant le résultat de la requête.
Connexion TCP
Bind Request (0)
Bind Response (1)

Client
Server iPlanet
Dans le paquet Bind Request, plusieurs informations sont envoyées par le client.
En effet, celui-ci envoie aussi la version du protocole choisi, le nom de la personne qui
se connecte sur l’annuaire et le type d’authentification sur le serveur. Il faut juste
savoir que l’on peut se connecter sur le serveur en anonyme ou en authentifié, ce qui
impliquera des restrictions sur les possibilités de gestion de l’annuaire. Les options
avancées d’authentification servent lors de l’accès par d’autres serveurs pour une
réplication par exemple.
En ce qui concerne le paquet Bind Response, celui-ci renverra juste l’état de la

réponse. Elle peut être de type success, protocol Error, ou encore bien d’autres
valeurs.
Toutes les valeurs possibles sont décrites dans la RFC 2251.
Dans le cas où le serveur ne peut pas être atteinte, la connexion TCP n’arrivera pas à
s’établir et de ce fait aucun paquet LDAP ne sera émis. Il faut obligatoirement que la
connexion TCP soit ouverte pour que le premier paquet Bind Request soit émis.
Flux Applicatif 100

8.4 Recherches de données dans l’annuaire
Une fois connecté correctement, il faut que le serveur LDAP envoie les données au
client. Comme pour tout échange LDAP client-serveur, c’est le client qui commence
l’échange.
SearchRequest (3)
SearchResponse (4)
SearchResponseSimple (5)
Client
Server iPlanet
Le client qui fait la requête, envoie cette fois-ci beaucoup plus de données au serveur.
En effet, si l’on regarde la RFC 1777 ou 2251 qui définit exactement les champs
transmis, on s’aperçoit que les plus importants sont :
LDAP: ProtocolOp: SearchRequest (3)
SearchRequest ::= LDAP: MessageID
[APPLICATION 3] SEQUENCE { LDAP: ProtocolOp = SearchRequest
baseObject LDAPDN, LDAP: Base Object = o=eleves, o=eig
scope ENUMERATED { }, LDAP: Scope = Single Level
sizeLimit INTEGER (0 .. maxInt), LDAP: Deref Aliases = Always Deref Aliases
timeLimit INTEGER (0 .. maxInt), LDAP: Size Limit = No Limit
} LDAP: Time Limit = No Limit
baseObject est le nom de l’annuaire sur lequel on se connecte. Typiquement o=eig

scope est le niveau de la recherche (voir chapitre 7.3)
size Limit est la taille limite des données que le client est prêt à recevoir
time Limit est le temps maximum que peut attendre le client pour recevoir les données.
Le serveur a maintenant reçu la requête de la part du client., il est prêt à lui envoyer les
données. Il le fait simplement en indiquant, le chemin de la donnée dans l’arbre. Si par
exemple un user (uid) est dans l’annuaire Elèves et dans la classe TE3.
o=Elèves
cn = TE3
uid = toto
Le serveur renverra uid=pgaio, cn=TE3, o=Elèves
Une fois que le serveur a renvoyé toutes les données qui se trouvent chez lui, il envoi
un paquet Search Response Simple au client pour lui dire que la transaction est
terminée.
Dans ce paquet est envoyé le paramètre success.
Flux Applicatif 101

8.5 Ajout d’un utilisateur
Lorsque je me connecte sur mon serveur iPlanet par le biais du client LDAP, j’ai la
possibilité d’ajouter de nouveaux utilisateurs dans le cas où je me connecte en tant que
« Super Manager ». En effet, une seule personne est apte à modifier des données dans
l’annuaire LDAP. Dans mon cas, il s’appelle Directory Manager (nom par défaut dans
le serveur iPlanet 5.0).
Ainsi une fois connecté avec ce login et son mot de passe correspondant, je peux
ajouter un utilisateur. Dans le cas où je me connecte sous un autre compte valide, je ne
pourrai que consulter les données de l’annuaire.
J’ajoute donc un utilisateur, et vois ce que j’obtient au niveau du protocole.
Add Request (8)
Add Response (9)
SearchRequest (3)
SearchResponse (4)
Client
Server iPlanet
Si l’on regarde de plus prêt les paquets Add Request et Add Response voici ce que l’on
obtient.
LDAP: ProtocolOp: AddRequest (8) LDAP: ProtocolOp: AddResponse (9)

LDAP: MessageID LDAP: MessageID
LDAP: ProtocolOp = AddRequest LDAP: ProtocolOp = AddResponse
LDAP: Object Name = cn=gaio, o=eleves, o=eig LDAP: Result Code = Success
LDAP: Attribute Type = objectclass
LDAP: Attribute Value = top
LDAP: Attribute Value = person
LDAP: Attribute Type = sn
LDAP: Attribute Value = pascal
On voit très bien ici que le nouveau compte a été créé dans l’annuaire à l’emplacement
cn=gaio, o=eleves, o=eig et que les champs entrés lors de l’activation du compte sont
sn=pascal et cn=gaio. Ces deux champs sont ceux à remplir obligatoirement lors de la
création de l’utilisateur.
En ce qui concerne la réponse du serveur, elle dit simplement que le nouvel utilisateur
a été ajouté.
Les paquets suivants (Search) sont présents afin d’afficher physiquement la nouvelle
valeur entrée sur le browser du client.
Flux Applicatif 102

8.6 Delete d’une branche de l’annuaire
Lorsque l’on effectue maintenant un effacement d’une donnée de l’annuaire (personne

qui quitte l’entreprise par exemple), cela se passe de la même manière que lorsque l’on
ajoute un nouvel utilisateur. Bien sûr, il s’agit ici de l’enlever et pas de l’ajouter mais
le principe au niveau protocole est identique.
Del Request (10)
Del Response (11)
Client
Server iPlanet
LDAP: ProtocolOp: DelRequest (10) LDAP: ProtocolOp: DelResponse (11)
LDAP: MessageID LDAP: MessageID
LDAP: ProtocolOp = DelRequest LDAP: ProtocolOp = DelResponse
LDAP: Object Name = cn=gaio, o=eleves, o=eig LDAP: Result Code = Success
Lors de l’opération Del Request, le client envoie simplement le dn (cn=gaio, o=eleves,

o=eig) de l’utilisateur auquel il faut enlever l’entrée dans l’annuaire.
Contrairement à l’ajout, il n’y a pas besoin de faire un search car il n’y a pas de
données à afficher. Lorsque l’on effectue cette opération la donnée disparaît
physiquement dans l’annuaire.
Nous avons aussi la possibilité d’effacer directement toute une branche de l’annuaire.
Afin que le client puisse effacer toutes les données de l’arbre, il faut qu’il connaisse
toutes les données se trouvant dans la branche. Pour cela, le client va effectuer un
search Request sur toute la branche et effacer une par une toutes les données qui s’y
trouvent. Pour finir il effacera le haut de la branche. Ici la branche o=eleves contient
une seule donnée (uid = pgaio).
Search Request (3)

search des données se trouvant dans la branche
Search Response (4)

o=eleves
Search Response (4)

uid = pgaio
Search Response Simple (5 )
Del Request (10)

uid = pgaio
Client
Del Response (11)
Server iPlanet
Del Request (10)
o=eleves
Del Response (11)
Flux Applicatif 103

8.7 Server LDAP Down
Il se peut que le serveur LDAP soit hors service (machine éteinte ou serveur arrêté)
pour diverses raisons. De ce fait, plus personne ne devrait pouvoir consulter des
données dans celui-ci. Nous avons vu dans le chapitre 5 concernant ISA Server ce qui
se passait au niveau protocole lorsqu’un serveur Web était hors service. Voyons
comment cela se passe avec un serveur LDAP.
Il faut rappeler que pour atteindre un serveur LDAP il faut d’abord établir une
connexion TCP puis une connexion LDAP. De ce fait si j’essaye de me connecter sur
le serveur alors que celui-ci est éteint, c’est au niveau TCP que la connexion
n’aboutira pas (après plusieurs essais de connexion).
TCP SYN
TCP SYN
TCP SYN
Client
Server iPlanet
Maintenant, je prends le cas où l’on est connecté depuis un moment sur l’annuaire
LDAP via le browser du client et que le serveur s’arrête brusquement.
Les connexions TCP et LDAP sont établies.
Si l’on essaye d’atteindre une donnée voici ce qui arrive.
Search Request (3)
Search Request (3)
Search Request (3)
Search Request (3)
Search Request (3)

Client
Server iPlanet
De la même manière qu’avant, le paquet Search Request va se répéter jusqu’à 5 fois
car aucune réponse n’est envoyée par le serveur iPlanet (down)
Remarque :
La fréquence entre deux paquets Search Request est toujours multipliée par deux entre
chaque paquet.
Paquet Search Request Time Différence des fréquences

des paquets
Numéro 1 0.1 sec 0
Numéro 2 0.4 sec + 0.3 sec
Flux Applicatif 104

8.8 Connexion avec Size Limit limité
Il est possible de se connecter avec des paramètres spéciaux sur le serveur iPlanet. En
effet, le client peut demander à ce que le serveur ne lui envoie pas toutes les données
de son annuaire lors de la connexion. C’est le but du paramètre Size Limit. Il permet de
limiter les données transmises par le serveur LDAP. Prenons l’exemple d’un annuaire
qui contient 500 données. Moi client, je ne veux pas que le serveur me retourne ses
500 données, car je perdrai du temps. Ainsi je lui dit de m’envoyer uniquement 50
éléments de son annuaire.
Il faut bien voir que c’est le client qui envoit ce paramètre au serveur lorsqu’il se
connecte sur l’annuaire et fait sa première recherche.
Mais voyons au niveau du protocole comment cela se passe.
Pour ma part j’ai configuré le client pour qu’il n’accepte qu’une seule donnée (Size
Limit = 1)
Bind Request (0)
Bind Response (1)
SearchRequest (3)
Size Limit = 0x00000001
SearchResponse (4)
success
Client SearchRequest (3) Server iPlanet

Size Limit = 0x00000001
SearchResponse (4)
Size Limit Exceeded
Après cette étude de protocole, on constate que le serveur LDAP a envoyé deux
données malgré que le paramètre Size Limit est de 1. Cela vient du fait que ce
paramètre affecte le nombre de données transmises par niveau de l’annuaire.
Ainsi, si j’ai un annuaire qui est construit de façon « horizontal», alors une seule
donnée par niveau sera retournée au client (voir figure de la page suivante)
Flux Applicatif 105

o=eig Niveau 0
Niveau 1
Niveau 2
uid = dcotte
Seules les données en gras seront retournées au client. Le reste sera ignoré.
La priorité des données envoyées sont en fonction de l’ordre alphabétique.
Lorsque le serveur veut envoyer une autre donnée se trouvant sur le même niveau de
l’arbre, celui-ci se refuse de le faire ayant reçu le paramètre Size Limit = 1 du client.
Par contre, il peut envoyer plusieurs données sur un niveau différent. Ainsi le serveur
LDAP envoi un message d’erreur au client en lui disant Size Limit Exceeded . Ce
message inclus dans le paquet Search Reponse Simple indique que les données
transmises ont étés faites correctement mais qu’il a envoyé la capacité maximale
requise par le client.
Pour mieux comprendre le phénomène du Size Limit par niveau, prenons le cas où Size
Limit = 2.
o=eig Niveau 0
Niveau 1
Niveau 2
2 uid trouvés 2 uid trouvés 2 uid trouvés
Ici on se rend bien compte que le paramètre Size Limit n’est valable que pour un seul
niveau et pas pour tout l’arbre.
Flux Applicatif 106

8.9 Déconnexion de l’annuaire
Lorsque l’on se déconnecte de l’annuaire, le client envoie un Unbind Request. Le

serveur n’est pas obligé de répondre. Il sait que la connexion avec le client est
terminée. Par la suite la déconnexion au niveau TCP se fait de façon standard à l’aide
de ACK.
Il se peut parfois que ce soit le serveur qui ferme la connexion. Ceci pour plusieurs
raisons par exemple quand l’administrateur le force à redémarrer. Dans ce cas c’est le
serveur qui envoie la commande Unbind Request. Le client comprend qu’il doit fermer
la connexion.
Mais généralement c’est le client qui se déconnecte de l’annuaire et c’est donc lui qui
envoie cette commande.
Unbind Request
Client
Server iPlanet
Ainsi la connexion est terminée.
8.10 Conclusion
Dans ce chapitre, nous avons vu les différents paquets ainsi que les différents
paramètres qui sont transmis à l’intérieur. Il est évident que lorsque l’on regarde la
RFC 2251 ou 1777, cela correspond exactement à ce que l’on a au niveau de
l’analyseur de protocole. Ce qui facilite grandement la compréhension des différents
paquets émis.
Ce que l’on peut constater, c’est que c’est toujours le client qui effectue les opérations
d’ajout, d’effacement des données ou autre chose encore. Le serveur n’est là « que
pour répondre ». A chaque Request du client, le serveur effectue l’opération et répond
par un paquet Response s’il doit transmettre une donnée et un paquet Response Simple
lorsqu’il a terminé de transmettre ses données.
Je constate donc que le protocole LDAP n’est pas très compliqué et qu’il fonctionne
sur un échange de Question-Réponse. De plus les commandes utilisées pour les
applications LDAP sont très faciles à comprendre et selon moi très explicites. En effet,
pour effacer une donnée, on a un paquet Del Request, pour ajouter une donnée, un
paquet Add Request. Je pourrai tous les citer, mais cela sera à chaque fois la même
chose. Des mots simples pour une meilleure compréhension, voilà que je retiens de
plus frappant du protocole LDAP.
Flux Applicatif 107

Chapitre 9 : LDAP Referral
Il se peut certaines fois que des données ne soient pas toutes stockées dans un même annuaire
et que le serveur renvoie au client l’adresse d’un autre serveur LDAP où il peut aller chercher
l’information demandée.
Ce principe de renvoie de référence s’appelle un Referral.
Ce mécanisme est assez simple à comprendre mais il faut tenir compte de plusieurs
restrictions.
Lorsque l’on fait un referral d’un serveur vers un autre, la branche sur laquelle on accède doit
porter le même nom et être du même type (o, ou , cn, etc…) que d’où part le renvoi de
référence.
o=eig

nom incorrect
type incorrect
t
incorrect
rrec rect
Referral
Ref
al inco incor e
cor rral
ferr ype rec
Re é et t t
érron
nom
cn = classe ou = IN2 cn = IN2
cn = IN3 cn = IN2 uid=dcotte cn = sbancal uid=dcotte cn = sbancal
Un autre problème qui peut se créer avec ces referrals, c’est le cas où l’on ne fait pas attention
et plusieurs referrals sont présents sur le même serveur. Il peut y avoir un interblocage.
Annuaire A
Re
ral
fer
fer
ral
Re
INTERBLOCAGE
Referral
Annuaire B Annuaire C
Flux Applicatif 108

9.1 Syntaxe d’un Referral
Un referral LDAP contient un url qui sera renvoyé au client. Les informations
transmises dans ce referral sont :
- Host Name du serveur à contacter

- Port sur lequel il faut se connecter (port LDAP = 389 par défaut)
- DN pour savoir sur quel base il doit se connecter
Par exemple, un client qui recherche la liste d’élèves aura deux moyens de l’atteindre.
Soit en se connectant sur le serveur des élèves, soit en se connectant au serveur de
l’eig qui fera un referral sur le serveur des élèves.
Dans ce cas, le serveur renverra au client la référence du serveur élèves avec la

syntaxe : ldap://129.194.184.203:389/o=eleves.
Ici le port par défaut du protocole LDAP est 389. Il est cependant possible comme
pour HTTP (port 80), de modifier le numéro de port à sa guise.
9.2 Les types de referrals
Il existe plusieurs types de referrals. Le plus couramment utilisé est le smart referral.
Il consiste simplement à renvoyer au client l’adresse d’un second serveur sur lequel il
pourra trouver la donnée.
o=eig
Serveur A

Referral
Ici le client fait la recherche de

dn : uid=dcotte, cn=IN2, ou=informatique, o=eig
sur le Serveur A de l’eig cn = IN2 Serveur B
uid=dcotte cn = sbancal
Flux Applicatif 109

Le deuxième type de referral est le default referral. Lorsque que le client recherche
une donnée et que le serveur ne la possède pas, alors il renverra au client l’adresse
d’un autre serveur sur laquelle il pourra éventuellement trouver l’information
recherchée.
Default Referral
o=eig o = eig
cn = IN3 cn = IN2
cn = TE3 cn = TE2
Serveur A Serveur B
Smart Referral
pas d'informations Information
trouvées sur le dn trouvée
recherché
cn = IN2
Ici le client fait la recherche de
dn : uid=dcotte, cn=IN2, ou=informatique, o=eig
sur le Serveur A de l’eig
uid=dcotte cn = sbancal
Serveur C
Information
retournée
au client
Default Referral
Contrairement au smart referral, le serveur questionné, ne donnera plus l’adresse d’un

autre serveur où la donnée se trouve à coup sûr. En effet, il renvoie au client, une
adresse fixe d’un serveur LDAP. Le client va ainsi interrogé ce serveur pour savoir s’il
sait où la donnée se trouve. Il pourra soit la lui transmettre si elle est présente
localement, soit renvoyer un smart referral au client pour lui indiquer où elle se
trouve. C’est ce cas que j’ai montré dans le schéma ci-dessus.
Un default referral pourra à nouveau être émis depuis ce deuxième serveur LDAP.
Tout les scénarios sont possibles.
C’est toujours le client qui, une fois reçu le referral, va se connecter sur un autre
serveur.
Le principe de default referral ne sera pas étudié dans ce chapitre. Seul le smart
referral fera l’objet d’une étude détaillée.
Flux Applicatif 110

9.3 Comment ajouter un referral avec iPlanet
Maintenant que nous avons vu comment fonctionne un referrral, il reste à le mettre en

place sur le serveur iPlanet. Cette marche à suivre est uniquement valable pour le
serveur iPlanet Directory Server 5.0.
Cette description est aussi décrite dans l’annexe B.
Voici la procédure à suivre lorsque l’on veut ajouter un referral
1. Dans la console Directory Server, sélectionner l’onglet directory.

2. Choisir dans l’annuaire, quelles données seront appelées depuis un autre serveur.
3. Double cliquer sur cette donnée. (cliquer sur le bouton Advanced ).
4. Cliquer sur la cellule indiquant l’attribut « Object class » et cliquer sur Add Value.
5. Sélectionner referral dans la liste qui apparaît et cliquer sur OK.
6. Cliquer sur Add Attribute.
7. Sélectionner ref dans la liste qui apparaît et cliquer sur OK.
L’attribut ref apparaît dans la boîte de dialogue
8. Dans la cellule correspondant, entrer la valeur du referral.
ldap://HostName:Port/dn (voir chapitre 9.1 pour la syntaxe)
9. Cliquer sur OK pour sauvegarder les changements.
9.4 Etude d’un referral au niveau du protocole
Lorsque l’on se connecte sur un serveur et que celui-ci renvoie au client un referral,
c’est le client qui se connecte sur le serveur référencé.
Connexion TCP
Bind Request (0)
Bind Response (1)
Search Request (3)
Search Response Reference (19)

Server iPlanet
129.194.187.52
Connexion TCP
Client Bind Request (0)
Bind Response (1)
Search Request (3)
Search Response (4)

Server iPlanet
référencé
129.194.184.203
Flux Applicatif 111
Par rapport à un simple recherche, on voit qu’un paquet Search Response Reference
est envoyé par le serveur iPlanet.
Voici de quoi est composé ce paquet :
LDAP: ProtocolOp: SearchResponse Reference (19)

LDAP: MessageID
LDAP: ProtocolOp = SearchResponse Reference
LDAP: Referral Server = ldap://129.194.184.203:389/o=eleves
Comme on peut le constater, le serveur envoie simplement l’adresse sur lequel le

client doit se connecter.
Ainsi le paquet important ici, est le paquet Search Reponse Reference. C’est là où
l’adresse du serveur référencé va être transmis.
Search Request
sur o=eleves
Search Response Reference

ldap://129.194.184.203:389/o=eleves
Search Response Simple
Server iPlanet
Search Request
Client sur o=eleves
Search Response
uid=dcotte , uid = sbancal

Server iPlanet
référencé
9.5 Conclusion
Dans ce chapitre, j’ai défini comment mettre en œuvre les referrals et comment ils
fonctionnent. Il faut bien avoir à l’esprit que le serveur LDAP ne fait qu’indiquer au
client sur quel autre serveur LDAP il peut trouver l’information. Il n’est en aucun cas
responsable de rediriger la recherche. Il faut aussi bien comprendre que lors d’un
referral, les types des attributs (o, ou, cn, etc..) doivent être identiques entre les deux
serveurs. Il faut aussi que les noms correspondent.
Le principe de referral est assez simple dans son concept, c’est pourquoi je n’irai pas
plus loin dans son analyse.
J’ai, dans la mise en place des referalls, eu un problème sur le serveur iPlanet. En
effet, lorsque je crée le referall sur un autre serveur, le browser d’iPlanet, ne
fonctionne plus. En effet, la souris passe du sablier à la flèche et le serveur iPlanet est
bloqué. Si je me connecte distance avec un autre browser LDAP, le referall s’effectue
correctement.
J’en déduis que le browser proposé avec le serveur iPlanet à un bug. En effet, la
version utilisée pour mon diplôme a été téléchargée depuis Internet. Peut-être que la
version payante n’a pas ce problème. Il faudrait tester cela.
Flux Applicatif 112

Chapitre 10 : LDAP Réplication
Le principe du referral est de partager les annuaires. Ainsi chacun des serveurs LDAP dans le
réseau, ont plusieurs informations mais pas la totalité.
Cependant, une fois que nous avons créé notre annuaire, il faut faire en sorte que la totalité
des données soient sauvegardées sur une autre machine au cas où un problème surgirait. Le
referral ne faisant qu’un lien sur un autre serveur, il faut trouver un moyen de copier les
données d’une database. C’est pourquoi le protocole LDAP a défini une norme appelée
Replication.
La réplication peut se faire uniquement entre serveurs.
Cette norme est en partie définie dans la RFC 2830.

Ainsi on peut copier une partie ou l’intégralité de l’arbre sur un autre serveur LDAP.
Auparavant il était possible de le faire mais en sauvegardant l’annuaire sous forme d’un
fichier texte LDIF.
Concernant la configuration des serveurs pour effectuer une réplication, consulter l’annexe
Tutorial iPlanet.
10.1 Le fichier LDIF
Ce type de transfert à l’aide d’un fichier de type LDIF, peut être considéré comme une
forme de réplication. En effet, le fait de stocker les informations de l’annuaire et de les
transférer sur un autre serveur peut s’assimiler à ce que fait la réplication de type
LDAP. Soit de copier l’intégralité ou une partie de l’annuaire sur un autre serveur
LDAP.
Lorsque l’on sauvegarde une base de données sous la forme LDIF, celui-ci sera sous
forme de texte. Ce qui n’est pas très pratique pour modifier des données, une
représentation graphique de la base de données est plus facile à gérer.
Sauvegarde des données Copie des données

dans un fichier LDIF sur un autre serveur
Server iPlanet Server iPlanet

répliqué
Afin de faciliter la tache des utilisateurs, il a été mis en place un protocole pour
communiquer entre serveur. Ce protocole n’est pas encore sous forme de RFC. Il est
toujours à l’état expérimental.
Flux Applicatif 113

10.2 Réplication entre serveur
C’est le second moyen de faire de la réplication. Le premier étant, le transfert avec un

fichier LDIF de manière plus archaïque.
Même si la première méthode est encore utilisée, la réplication entre serveurs prend de
plus en plus d’ampleur.
Il existe cependant deux modes de réplication.

- La réplication totale (envoi de la base de données entière)
- La réplication des modifications uniquement (envoi des modifications entre le
dernier accès à la base de données)
Le serveur iPlanet, permet ces deux modes.
10.2.1 La réplication totale (Méthode 1)
Connexion TCP
Bind Request
BindResponse
Search Request
Search Reponse

Extended Request
répliqué
Extended Response
Deux paquets supplémentaires apparaissent dans cet échange par rapport à un accès
standard. Ce sont les paquets Extended Request et Response. Nous verrons par la suite
que dans les paquets Search Request et Response, des données concernant la
configuration des serveurs seront transmises. Tous ces paquets seront décrits dans le
détail au niveau du protocole dans le chapitre 10.3.
Flux Applicatif 114

10.2.2 Réplication des modifications (Méthode 2)
Lorsque l’on fait ce type de réplication, seul les données modifiées dans l’annuaire
entre la dernière réplication effectuée et l’heure courante, seront transmises.
Extended Request
Extended Reponse
Add Request
Add Response
Extended Request

Extended Response
répliqué
Lors du transfert de données, un paquet Add Request est présent, c’est là que l’on
envoie la donnée à ajouter dans l’annuaire distant.
Tous ces paquets seront décrits au niveau protocole de façon approfondie au chapitre
10.4.
10.3 Etude de protocole de la réplication totale
Si l’on regarde de plus prêt chaque paquet, on s’aperçoit qu’un échange au niveau de
la configuration est transmise entre serveurs. Ces paramètres sont transmis à travers
des OID (Object Identifier). Ces OIDs sont standardisés et définis sur le site
http://www.alvestrand.no/objectid/. Pour trouver un OID particulier, taper le numéro
de celui-ci avec .html à la suite de l’adresse donnée auparavant.
Il faut savoir qu’un OID est une suite de numéro séparé par des points qui servent à
définir un standard.
Par exemple, l’OID 2.16.840.1.113730.3 veut dire :
2 - ISO/ITU-T jointly assigned OIDs

2.16 - Joint assignments by country
2.16.840 – USA
2.16.840.1 - US company arc
2.16.840.1.113730 - Netscape Communications Corp .
2.16.840.1.113730.3 - Netscape LDAP
Flux Applicatif 115

Maintenant que nous avons tous les éléments en main, nous pouvons comprendre les
paquets transmis ainsi que leurs attributs.
Si l’on regarde la figure du chapitre 10.2.1, on voit que les 3 premiers paquets ne
changent pas lors d’un échange traditionnel. Cependant à partir du paquet Search
Request, nous avons des choses intéressantes à étudier.
Search Request
LDAP : Attribute Type : objectclass
LDAP : Attribute Value : supportedcontrol
LDAP: Attribute Value : supportedextension

répliqué
Le serveur qui possède les données va demander au serveur qui les recevra (serveur
repliqué), quels sont les objectclass qu’il accepte.
Ainsi dans le paquet suivant, le serveur repliqué va envoyé sous forme d’OIDs les
paramètres objectclass qu’il accepte.
Search Response
Attribute Type = supportedcontrol
2.16.840.1.113730.3.4.2
2.16.840.1.113730.3.4.3
2.16.840.1.113730.3.4.4
2.16.840.1.113730.3.4.5
1.2.840.113556.1.4.473
2.16.840.1.113730.3.4.9
2.16.840.1.113730.3.4.16
2.16.840.1.113730.3.4.15
2.16.840.1.113730.3.4.17
2.16.840.1.113730.3.4.14
1.3.6.1.4.1.1466.29539.12
2.16.840.1.113730.3.4.13
2.16.840.1.113730.3.4.18
Attribute Type = supportedextension
2.16.840.1.113730.3.5.7
Server iPlanet 2.16.840.1.113730.3.5.8
Server iPlanet
2.16.840.1.113730.3.5.3 répliqué
2.16.840.1.113730.3.5.5
2.16.840.1.113730.3.5.6
2.16.840.1.113730.3.5.4
Je ne définirai pas tout ce que les serveurs acceptent comme attributs. Il faut savoir
que ce sont des standards. Pour consulter les différents OIDs voir les annexes, où j’ai
synthétisé tous les OIDs utilisés dans ces échanges.
Flux Applicatif 116

Le paquet suivant est de type Search Response Simple. Il est présent juste pour
informer le serveur que les informations envoyées par le paquets Search Response sont
terminées.
Extended Request
LDAP: Request Name = 2.16.840.1.113730.3.5.3

LDAP: Request Value = 16.840.1.113730.3.6.2
LDAP: Control Type = 2.16.840.1.113730.3.4.2

répliqué
L’extended Request, est composée de 3 champs. Si l’on traduit les OIDs, voici ce que
ce paquet renvoie comme informations :
Le champ Request Name = iPlanet Start Replication Request Extended Operation

Le champ Request Value = iPlanet Total Update Replication Protocol Identifier
Le champ control type = Manage DSA IT LDAPv3 contro l
Si l’on interprète cela, ce paquet est présent pour initialiser la réplication.

Le paquet control type = Manage DSA veut dire que l’on communique entre serveurs.
Le protocole LDAP défini un DSA comme une communication entre serveurs.
Extended Reponse (success)

LDAP: Response Name = 2.16.840.1.113730.3.5.4

répliqué
Response Name = iPlanet Replication Response Extended Operation
La connexion pour la réplication est effectuée correctement.
Flux Applicatif 117

Ensuite des couples de paquets Extended Request et Response sont présents afin de
transmettre les données au consommateur.
Extended Request

répliqué
Request Name = iPlanet Replication Entry Request Extended Operation

Dans les paquets Exetended Request, les données se trouvant dans l’annuaire sont
transmises avec les heures de création.
Extended Reponse
(success)

répliqué
Les données envoyées dans le paquet précédent ont été reçues correctement.
Extended Request
LDAP : Control Type = 2.16.840.1.113730.3.4.2

répliqué
Request Name = iPlanet End Replication Request Extended Operation
Control Type = Manage DSA IT LDAPv3 control
Flux Applicatif 118

Le serveur envoi avec ce paquet un commande au serveur consommateur pour finir la

réplication.
Extended Response
Success

répliqué
Le serveur consommateur confirme la fin de la transaction.
En résumant cette échange, voici ce qui se passe.
Connexion TCP
Bind Connexion
Search Request
Quelles sont les attributs que tu supportes ?
Search Response
Voici les attributs que je supporte
Search Reponse Simple

Fin des données à envoyer
Extended Request
Server iPlanet Voilà ce que j'ai dans mon annuaire Server iPlanet
répliqué
Extended Response
Ok Success j'ai reçu tes données
Extended Request
J'ai fini d'envoyer des données ; on se quitte
Connexion Connexion
close Extended Response close
Success
Cette partie traitait de l’envoi de la database complète. Il faut savoir que l’architecture
des deux bases de données (une sur chaque serveur) qui effectuent la réplication
doivent avoir la même architecture.
Cependant, le trafic généré avec une réplication totale est très grand. Cela peut aller
jusqu’au Giga Bytes. C’est pourquoi il est préférable parfois d’utiliser la deuxième
méthode qui consiste à n’envoyer que les modifications qui ont été faites sur la
database après la dernière réplication.
Flux Applicatif 119

10.4 Etude de protocole de la réplication des modifications
Une fois la connexion TCP effectuée, le premier couple de paquets LDAP présent est
de type Extended Request et Response. C’est ensuite que les paquets deviennent plus
intéressants.
Si aucune modification n’a eu lieu sur le serveur, alors aucun paquet à part ’louverture
et la fermeture de la connexion de réplication ne seront présents.
Dans mon cas, j’ai ajouté un utilisateur (uid = dcotte). Voilà ce que l’on constate au
niveau du protocole.
Add Request
Divers Attributs Transmis concernant l'utilisateur
Abandon Request

répliqué
Les attributs transmis sont ceux que l’on peut voir dans les propriétés de l’utilisateur
dans la console iPlanet.
LDAP: Object Name = uid=dcotte,o=replication

LDAP: Attribute Type = objectClass
LDAP: Attribute Value = top
LDAP: Attribute Value = person
LDAP: Attribute Value = organizationalPerson
LDAP: Attribute Value = inetorgperson
LDAP: Attribute Type = givenName
LDAP: Attribute Value = denis
LDAP: Attribute Type = cn
LDAP: Attribute Value = denis cotte
LDAP: Attribute Type = uid
LDAP: Attribute Value = dcotte
LDAP: Attribute Type = sn
LDAP: Attribute Value = cotte
LDAP: Attribute Type = creatorsName
LDAP: Attribute Value = cn=directory manager
LDAP: Attribute Type = modifiersName
LDAP: Attribute Value = cn=directory manager
LDAP: Attribute Type = createTimestamp
LDAP: Attribute Value = 20011121182718Z
LDAP: Attribute Type = modifyTimestamp
LDAP: Attribute Value = 20011121182718Z
LDAP: Attribute Type = nsUniqueId
LDAP: Attribute Value = 496ebc01-1dd211b2-80d4c7d8-970540e8
LDAP : ProtocolOp = AbandonRequest

LDAP : Message ID
Flux Applicatif 120

Pour avoir la définition des différents attributs, consulter le document Tutorial iPlanet
en annexe.
Comme on peut le constater, à la fin de ce paquet, il y a une commande de type

Abandon Request. Celle-ci est présente lorsque l’on a fini de transmettre les données à
mettre à jour. En effet, dans ce cas, une seule donnée est mise à jour. Si maintenant, je
crée cinq utilisateurs et que je remets à jour le serveur consommateur, ce n’est que
lorsque j’aurai transmis les données du cinquième utilisateur que cette commande
apparaîtra.
Add Request
DATA utilisateur 1
Add Request
DATA utilisateur 2
Add Request
DATA utilisateur 3
Add Request
DATA utilisateur 4
Add Request
Server iPlanet DATA utilisateur 5 Server iPlanet
répliqué
Abandon Request
Ensuite comme pour la plupart des paquets Request, une réponse est envoyée par le
consommateur.
Add Response
Success

répliqué
La réponse à ce paquet nous indique si les données ont été reçues correctement ou non.
Comme lors d’une déconnexion LDAP (Unbind Request), il n’y a pas de réponse à la
commande Abandon Request. Les deux parties savent qu’elles doivent arrêter là le
transfert des données.
Flux Applicatif 121

Afin de conclure la réplication, deux paquets sont envoyés de la même manière que
pour l’initialisation mais cette fois-ci pour conclure l’échange..
Extended Request
LDAP : Control Type = 2.16.840.1.113730.3.4.2

répliqué
Request Name = iPlanet End Replication Request Extended Operation
Control Type = Manage DSA IT LDAPv3 control
Le serveur envoi avec ce paquet une commande au serveur consommateur afin de

terminer la réplication.
Extended Response
Success

répliqué
Le serveur consommateur confirme la fin de la transaction.
Un dernier paquet encore présent sert à terminer la connexion LDAP.

En effet, la réplication étant terminée, il n’y a plus besoin de transmettre des données,
alors les deux serveurs quittent leur connexion.
Unbind Request

répliqué
A l’aide de cette commande, les serveurs savent que la connexion doit être terminée.
Il n’y a pas besoin de réponse à ce paquet. Chacun sait ce qu’il doit faire quand il émet
ou reçoit ce paquet.
Flux Applicatif 122

On peut résumé l’échange de données entre les deux serveurs de la manière suivante.
Extended Request
début de la réplication
Extended Response
ok je suis prêt
Add Request
voici un nouvel utilisateur ajoute-le dans ta liste
Abandon Request
c'est fini. C'était la dernière donnée à ajouter
Add Response
ok success
Server iPlanet Extended Request Server iPlanet

J'ai fini d'envoyer des données ; on se quitte répliqué
Extended Response
Success
Connexion Connexion
close Unbind Request close
je me deconnecte
10.5 Conclusion
Dans ce chapitre, nous avons vu comment faire une réplication. Il ne faut pas oublier
que normalement, le but de la réplication est de sauvegarder toutes les données
régulièrement. C’est pourquoi lors de l’installation de la réplication sur le serveur
iPlanet nous avons une option de configuration pour la fréquence des réplications entre
serveurs. Il faut savoir aussi que cela engendre un trafic assez grand car l’annuaire
atteint parfois 1 Giga Bytes dans les grandes entreprises. C’est pourquoi la réplication
se fait généralement la nuit.
Pour ma part, j’ai utilisé le logiciel iPlanet Directory Server 5.0 pour effectuer les tests
de réplication. Il se peut que d’autres logiciels aient des options différentes de celles
proposées ici.
En effet, un serveur LDAP n’est pas défini comme une norme et l’utilisateur peut créer
son annuaire comme il l’entend. Les logiciels ont eux aussi différentes possibilités.
Ce logiciel peut soit répliquer uniquement les modifications soit tout l’annuaire.
Il offre par contre la possibilité de gérer les heures où l’on veut faire la réplication.
Après avoir passé 3 semaines sur ce logiciel, je le considère comme bon pour faire de
la réplication car il n’est pas trop compliqué à utiliser et fonctionne relativement bien.
Flux Applicatif 123

Chapitre 11 : Application LDAP
Dans les chapitres précédents, nous avons vu les possibilités offertes par un annuaire LDAP.
Cependant, cela ne nous sert pas à grand chose si cette annuaire n’est pas dédié à une
application particulière.
C’est pourquoi, nous avons décidé d’utiliser l’annuaire LDAP dans un cas plus réel.
Tout d’abord, nous voulions faire une authentification d’un client sur un routeur Cisco.
Malheureusement, ceux que nous avons dans le laboratoire (Cisco 2600) ne supportent pas le
protocole LDAP.
Nous avons donc décidé d’utiliser le Firewall Check Point afin que lorsque l’on accède à un
serveur Web, celui-ci va aller contrôler le login et le password du client qui s’y connecte sur
le serveur LDAP.
Voici l’architecture que nous avons utilisée :
Firewall
Check Point
V 4.1
SP5 IIS 5.0
Win NT 4 SP2
IE 6.0 Server Win 2k
SP2 Server
Win 2k Pro IP Machine = 129.194.184.82
IP Machine = 10.0.0.1 IP Machine = 10.0.0.2
IP = 129.194.184.206
Internet
Client
Firewall Check Point Server Web
IP Web par translation (NAT)
129.194.186.210
Server LDAP
iPlanet Directory Server 5.0
IP Machine = 10.0.0.3
iPlanet 5.0
SP2
Win 2k Pro
Une configuration du Firewall est nécessaire afin que celui-ci accède au serveur LDAP pour
authentifier le client. En annexe, j’ai fait un tutorial qui explique comment configurer le
Firewall (Annexe C).
La connexion entre le Firewall et le serveur Web était déjà effectuée précédemment par
M.Borsa (diplômant dans le laboratoire), je n’ai fait que reprendre ce que lui avait déjà fait.
Flux Applicatif 124

11.1 Création d’un compte utilisateur
Une fois que l’on a configuré correctement le Firewall, il nous faut créer un compte
utilisateur sur le serveur iPlanet. C’est avec ce compte que l’on se connectera au
serveur Web qui se trouve derrière le Firewall.
Pour cela, j’ai créé une nouvelle base de donnée appelée o=firewall, et j’ai créé un
utilisateur appelé pgaio.
Avec gaio comme nom et pascal comme prénom, ce qui correspond par défaut à un
uid=pgaio. Cet uid peut être modifié lors de la création de l’utilisateur. Voir captures
ci-dessous.
Login = pgaio
Password = labotd
Pour installer une nouvelle base de données ainsi que pour ajouter un nouvel
utilisateur, se référer à l’annexe C.
Flux Applicatif 125

11.2 Accès au serveur Web par le client
L’utilisateur pgaio étant maintenant créé, il va pouvoir se connecter sur le serveur

Web. L’adresse de celui-ci étant une adresse privée (ip = 10.0.0.2), c’est le Firewall
qui va s’occuper de translater l’adresse privée en une adresse publique (ip =
129.194.186.210) comme décris dans l’annexe C.
Le client se connectant sur le serveur Web, reçoit une demande d’authentification

grâce à la règle insérée dans le Firewall.
Ainsi il recevra une fenêtre de ce style :
Il suffira au client de rentrer son login et password correspondant à l’entrée sur

l’annuaire LDAP et il pourra entrer sur le site.
Flux Applicatif 126

11.3 Analyse d’une connexion sur le serveur Web
Les requêtes du client qui se connecte sur le serveur Web, vont être interceptées par le
Firewall (protocole http uniquement).
Le Firewall va lui répondre en lui disant que la connexion est impossible car il doit
s’identifier.
Firewall
Check Point
V 4.1
SP5 IIS 5.0
Win NT 4 SP2
IE 6.0
Server Win 2k
SP2
Server
Win 2k Pro
IP Machine = 129.194.184.82
IP = 129.194.184.206
Get Request
129.194.186.210
Reponse
Unauthorized authentification requise
Client
Get Request 129.194.186.210
login et password Firewall Check Point Server Web
IP Web par translation (NAT)
129.194.186.210
Server LDAP
iPlanet 5.0
SP2
Win 2k Pro
Si l’on analyse le paquet Response de façon plus rigoureuse, on remarque que

plusieurs paramètres sont envoyés par le serveur lorsque celui-ci veut une
authentification.
HTTP: Response (to client using port 2268)

HTTP: Protocol Version = HTTP/1.0
HTTP: Status Code = Unauthorized 401
HTTP: Reason = Unauthorized
HTTP: WWW-Authenticate = Basic realm="FW-1. Reason: no user"
Le message « FW-1 Reason: no user » venant de la commande realm, est celui qui
nous apparaît dans la boîte de dialogue (voir page précédente), lorsque le serveur nous
demande une authentification.
C’est le browser (dans mon cas Internet Explorer 6.0) qui va afficher la boîte de
dialogue pour que l’utilisateur s’authentifie correctement à l’aide des champs
mentionnés ci-dessus.
Maintenant que la boîte de dialogue a été ouverte, le client doit entrer les données pour
s’authentifier sur le Firewall à travers l’annuaire LDAP.
Flux Applicatif 127

Si l’on regarde le paquet où sont transmis le login et le password du client, on

s’aperçoit qu’ils sont codés.
HTTP: GET Request (from client using port 2269)

HTTP: Protocol Version = HTTP/1.0
HTTP: Authorization = Basic cGdhaW86bWlsYW4=
Ce login et ce password sont transmis dans le paquet Authorization = Basic

cGdhaW86bWlsYW4=.
Ces informations sont codées en base64. Le principe de ce codage est assez simple. Il
suffit de transformer toutes les données ASCII en binaire, de regrouper les données par
groupe de 6, de les transformer en hexadécimal et de les coder suivant la table
suivante :
Séquence Caractères
0 … 25 «A » … «Z »
26 … 51 «a » … «z» Codage Base 64
52 … 61 « 0 » … «9 »
62 «+»
63 «/ »
Il faut savoir que le caractère « = » détermine la fin du codage en Base 64
Exemple :
Le login et le password que j’ai tapé sont :
Login = pgaio
Password = labotd
Si l’on code le login en binaire on obtient :

Ajout de
Lettre p g a i o 0 pour
HEXA ASCII 70 67 61 69 6F compléter
Binaire 8 bits 01110000 01100111 01100001 01101001 01101111 les
Binaire 6 bits 011100 000110 011101 100001 011010 010110 111100
Codage en Hexa 28 6 29 33 26 22 60
Codage Base 64 c G d h a W 8
Ce type de codage est assez pénible à effectuer manuellement. Un convertisseur

Base64 est disponible à l’adresse suivante : http://www.wc.cc.va.us/dtod/base64 .
De plus une table de codage Base64 est disponible à l’adresse :
http://www.freesoft.org/CIE/RFC/1521/7.htm . La table ASCII est disponible à
l’adresse : http://www.asciitable.com/ .
Flux Applicatif 128

Le client envoie son login et son password via le protocole http. Le Firewall va
chercher dans l’annuaire LDAP si les données entrées par l’utilisateur sont correctes
via le protocole LDAP.
Pour cela il va rechercher dans l’annuaire (défini lors de la configuration du Firewall),
s’il existe un uid=pgaio.
Si oui l’annuaire lui renvoie le chemin où il peut le trouver (uid=pgaio,o=firewall).
Ensuite il va se connecter à l’annuaire avec le password et le login que l’utilisateur a
taper en envoyant la commande Bind Request. L’annuaire accepte ou non la connexion
à l’annuaire. S’il l’accepte, cela veut dire que le password correspond bien au login et
la réponse sera Bind Response = success.
Firewall
Check Point
V 4.1
SP5 IIS 5.0
Win NT 4 SP2
SP2 Server
IP = 129.194.184.206
Internet
Sea
Client rch
Req
ue
Firewall Equ st o=f Server Web
ality irew
Check Point ma all (w
tch
Sea uid= hole s IP Web par translation (NAT)
pga ubtre 129.194.186.210
uid uid= rch R io e)
=p pga espo
io,o n
gaio
,o= =fire se
firew B wall
all ; ind R
aut e
hen quest
tific
atio
Bin n sim
dR ple
esp = la
suc ons bot
ces e d
s
Server LDAP
iPlanet 5.0
SP2
Win 2k Pro
Si la réponse du serveur LDAP est success, alors le client sera authentifié correctement
et une connexion sera ouverte entre le client et le serveur Web à travers le Firewall.
Cet échange ne nous intéresse pas trop.
Flux Applicatif 129

Il faut savoir que le protocole utilisé est uniquement du http et est le même (au niveau
http) que lors d’une connexion client serveur.
HTTP HTTP
Response Response
Data du site web Data du site web
Client Firewall Server Web

CheckPoint
L’échange est maintenant terminé. Le client ayant reçu les données correctement.
Flux Applicatif 130

11.4 Connexion avec password erroné
Il se peut que l’utilisateur qui se connecte sur le serveur Web, se trompe en tapant son
password lors de l’authentification. L’objectif de ce chapitre est de montrer comment
réagi le Firewall et le serveur LDAP lorsqu’un tel cas se produit.
Jusqu’à ce que le client arrive à la fenêtre d’authentification, le principe est identique.
J’utilise toujours l’utilisateur pgaio pour me connecter. Son password correct est
labotd. Cependant il se trompe et tape obaltd.
C’est une fois que le client a entré son login et son password erroné que des choses
intéressantes arrivent.
En effet, le Firewall fait toujours la requête sur le serveur LDAP pour savoir s’il existe
un utilisateur appelé pgaio.
Mais cette fois-ci lorsque le Firewall essayera de se connecter avec le password erroné
(obaltd), le serveur LDAP renverra dans son paquet Bind Response la valeur Invalid
Credentials qui correspond à une erreur de type password erroné.
Firewall
Check Point
V 4.1
SP5 IIS 5.0
Win NT 4 SP2
SP2 Server
IP = 129.194.184.206
Internet
Sea
Client rch
Req
ue
Firewall Equ st o=f Server Web
ality ire
Check Point ma wall (w
tch IP Web par translation (NAT)
uid= hole s
Se pga ubtr 129.194.186.210
uid= arch R io ee)
uid pga espo
=p io ,o= nse
gaio firew
,o=
firew Bin all
Par la suite, le Firewall proposera all ; d Re
aut que
hen st
d’entrer à nouveau le password et refera Bin
tific
atio
n sim
Inva d Res
la même opération d’authentification lid C pon
red se
ple
=o
balt
d
jusqu’à trois fois. Cette valeur peut-être ent
ials
modifiée dans les propriétés du Firewall

mais cela ne nous apporte pas plus pour
comprendre le phénomène que l’on Server LDAP
essaye de se reconnecter une ou
plusieurs fois sur le serveur Web. IP Machine = 10.0.0.3
iPlanet 5.0
SP2
Win 2k Pro
Flux Applicatif 131

11.5 Connexion avec un login erroné
Maintenant, il se peut que le login que tape l’utilisateur soit lui aussi erroné. A
première vue et sans faire d’étude de protocole, je dirai que lorsque le Firewall essaye
de trouver l’uid correspondant, le serveur LDAP lui renverra directement une erreur et
l’échange s’arrêtera là.
Pour la partie connexion cela se passe toujours de la même façon jusqu’à ce que
l’utilisateur entre son login erroné et son password.
J’utilise toujours l’utilisateur toto pour me connecter mais cette fois-ci il entre le login
ogaio au lieu de pgaio. Son password est correct (labotd).
En réalité lorsque le Serveur LDAP ne trouve pas de donnée correspondante au login

entré, alors celui-ci ne renvoie pas de message d’erreur. Il n’indique rien. La
commande Search Response Simple success est directement envoyée. La valeur
success ici veut dire que la commande Search Request à bien été traitée.
Firewall
Check Point
V 4.1
SP5 IIS 5.0
Win NT 4 SP2
SP2 Server
IP = 129.194.184.206
Internet
Client
Firewall Server Web
Sea
Check Point rch
Req IP Web par translation (NAT)
u
Equ est o= 129.194.186.210
ality firew
ma all (w
tch
Sea
rch uid= hole s
Res oga ubtr
io ee)
pon
suc se
ces Simp
s le
L’échange s’arrête ici et le Firewall demande à

nouveau d’entrer le login et le password et le
phénomène se reproduit jusqu’à trois fois avant Server LDAP
d’afficher une page d’erreur si l’authentification
n’aboutit pas.
iPlanet 5.0
SP2
Win 2k Pro
Flux Applicatif 132

11.6 Reconnexion au serveur Web
Il est normal qu’un utilisateur navigue sur Internet et qu’il revienne plusieurs fois sur
le site authentifié. Il est clair que le rôle du cache est toujours valide en ce qui
concerne les échanges http (voir chapitre 1, 2 et 3 et plus particulièrement le chapitre
1.5 pour l’étude du cache Web). Cependant en ce qui concerne les login et password,
je constate que ceux-ci sont pendant un certain temps, stockés dans le Firewall.
Ainsi si j’accède au site Web pour la deuxième fois après un certain temps, le Firewall
ne testera pas le login et le password entré par l’utilisateur à travers le serveur LDAP
car ces données sont stockées localement. Je ne peux malheureusement pas tester ce
temps de stockage en cache des utilisateurs, car le laboratoire ne possède pas la licence
LDAP pour le Firewall Check Point. Ainsi sans cette licence, je peux utiliser le
protocole LDAP pour accéder à un serveur LDAP, par contre je ne peux pas gérer cet
accès. Par exemple, je ne peux pas modifier les options qui font que les données de
l’utilisateur, une fois authentifié sur le serveur LDAP, seront stockées pendant un
certain temps dans la base de données du Firewall.
11.7 Conclusion
L’annuaire qui doit servir à valider l’accès à un site Web nécessitant une
authentification de l’utilisateur a donc été créé avec succès. La mise en œuvre est assez
rapide mais la gestion n’a pas pu se faire à cause de ce manque de licence. Cependant,
nous avons vu comment était transmis les données entre les différentes machines
(annuaire LDAP – Firewall – Client). L’accès fonctionne correctement et si le serveur
LDAP ne fonctionne plus, personne ne pourra se connecter au serveur Web.
Flux Applicatif 133

Chapitre 12 : Bibliographie
Tous les documents avec une étoiles sur le côté, sont des documents indispensables à la bonne
compréhension du sujet.
Partie Cache Web
Site consultés :
http://www.isoc.org/isoc/whatis/conferences/inet/96/proceedings/a4/a4_3.htm
Site très complet qui nous présente le cache de façon complète. Assez compliqué à
comprendre mais très intéressant.
http://www.alianwebserver.com/informatique/internet/http/default.htm#Gestion%20de
s%20caches
Site très intéressant sur les principes http, cache et Internet. Très intéressant mais ne
rentre, malheureusement, pas beaucoup dans les détails.
Partie ISA Server
Livre consulté :
* Configuring ISA Server 2000

De DR. Thomas W. Shinder , Debra LittleJohn Shinder et Martin Grasdal
Chez SYNGRESS
Livre en Anglais mais très facile à comprendre. Il présente les points les plus
importants du logiciel et est très détaillé lorsqu’il s’agit de configurer un élément du
serveur ISA.
Très bon livre.
Sites consultés :
* http://microsoft.supinfo.com/articles/isa/
Site qui nous renseigne sur les possibilités d’ISA et de configuration du logiciel selon
ce que l’on veut faire. Très utile. C’est un résumé du livre que j’ai consulté.
* http://www.adsl-facile.com/Dossiers/ISAServer/
Document très intéressant qui montre comment configurer ISA Server et qui décrit ces
fonctionnalités. C’est une sorte de tutorial. Très bon document.
* http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/isa/
proddocs/isadocs/CMT_CacheAbout.asp
Présentation du fonctionnement du cache d’ISA Server. Très bon document
Flux Applicatif 134

Partie LDAP
Livre consulté :
Construire un annuaire d’entreprise avec LDAP

De Marcel RIZCALLAH
Chez Eyrolles
Livre qui présente les possibilités de LDAP. Bon pour les principes LDAP au niveau
des annuaires. Au niveau des referrals, c’est correct, mais au niveau réplication, pas
beaucoup d’informations.
En général, bon livre pour débuter avec LDAP mais ne rentre pas assez dans les
détails.
Sites consultés :
http://www.iit.edu/~gawojar/ldap/index.html
Site qui permet de télécharger le browser LDAP sous java
http://globecom.net/ietf/draft/draft-merrells-ldup-model-01.txt
Sorte de RFC sur la réplication
http://asn1.elibel.tm.fr/en/biblio/asn1-presentation_fichiers/frame.htm
Site complet sur l’ASN1. Très intéressant.
http://www.vijaymukhi.com/vmis/ber.htm
Site qui permet d’avoir des informations sur le codage ber afin de décoder l’ASN1
utilisé dans le protocole LDAP
* http://cui.unige.ch/eao/www/memoires/Hugentobler/certnum.html
Exemple concret de décodage de l’ASN1 sur un certificat.
* http://people.ne.mediaone.net/wasser/ASN1/BasicEncodingRules.html
Site très bon pour la compréhension du codage ber (le site le plus complet sur le sujet)
http://database.sarang.net/database/ldap/presentation/index.htm
Présentation sous forme de slide de LDAP en général. Très bon pour comprendre les
principes
* http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap.html
Très bon document. Tutorial LDAP très complet.
* http://www.cru.fr/ldap/tutorial/tutorial_ldap.pdf
Très bon document. Tutorial LDAP très complet.
* http://www.alvestrand.no/objectid/
Seul site trouvé qui décrit précisément tout les OIDs. Unique inconvénient, le site n’a
pas été remis à jour depuis 1998.
Flux Applicatif 135

http://www.ldapzone.com/cgi-bin/01/index.cgi
Forum LDAP. Site généralement fréquenter par des programmateurs LDAP.
http://www.crackinguniversity2000.it/Paper/LDAP-FAQ-23.htm
Réponse à des questions standard sur LDAP
http://www.ldapguru.com/
Site qui propose d’importantes informations à tous les niveaux LDAP.
http://listes.cru.fr/wws/arc/ldap-fr/2001-11/thrd1.html#00001
Forum LDAP du site cru.fr. Réponse généralement dans la demi-journée qui suit la
question.
http://docs.univ-nancy2.fr/ldap/
section LDAP de l’université de Nancy. Très intéressant mais malheureusement les
applications créées sont très souvent sous Linux.
http://developer.novel.com/research/devnotes/1998/august/02/d980802_.pdf
Très bon document qui montre les différences entre le protocole LDAP Version 2 et la
version 3.
RFC :
* http://www.hotldap.com/standards/index.html
Liste de toutes les RFC faisant référence au protocole LDAP
http://www.crackinguniversity2000.it/Paper/LDAP-RFCs.htm
Idem. Liste de toutes les RFC. La présentation est moins claire mais il y a beaucoup
plus d’informations sur les RFC. Une description est faite pour chacune des RFC
présentées.
Partie Firewall Check Point
Sites consultés :
www.allasso.fr/base/docs/1967035335.PDF
Site qui montre les possibilités offertes par le Firewall Check Point
* http://support.checkpoint.com/kb/docs/public/firewall1/4_1/pdf/opsec_fw.pdf
Site qui présente comment configurer LDAP avec le Firewall Check Point. La
démonstration est faite avec un serveur LDAP Novell. Voir les annexes pour iPlanet
Liste des RFCs utilisées
N° 2616 HTTP 1.1

N° 2251 LDAP Version 3
N° 1777 LDAP Version 2
N° 2830 LDAP V3 Extension
Flux Applicatif 136

Conclusion
Ces trois mois passés dans le laboratoire, afin de réaliser mon travail de diplôme,
m’ont permis d’apprendre la gestion d’un projet sur une durée beaucoup plus longue
que j’en avais l’habitude. J’ai pu me rendre compte de la difficulté à gérer ce type de
projet sur plusieurs mois.
En ce qui concerne le travail effectué pendant ces trois mois, je pense que les résultats
obtenus correspondent aux objectifs fixés.
En effet, en ce qui concerne la partie qui consistait à étudier le cache Web, après
diverses difficultés, j’ai enfin pu faire ressortir les différents endroits où le cache était
stocké en utilisant le browser Internet Explorer 5.0 et 6.0. Mais certaines données
stockées ne seront jamais visibles, Microsoft gardant des données secrètes à
l’utilisateur (stockage de plusieurs informations en RAM).
Par la suite en installant ISA Server, j’ai constaté que le gain au niveau des échanges
de données n’était pas négligeable. En effet, lorsque le serveur ISA possède les
données d’une page dans son cache, aucun paquet n’est transmis entre ISA et le
serveur Web. Ainsi il n’y aura aucun trafic sortant et tout se fera localement. De ce fait
les accès sur cette page se feront très rapidement (vitesse du réseau local). Le test du
gain de temps n’a pas pu être fait.
Par la suite j’ai pu mettre en œuvre un reverse proxy et j’ai pu constater qu’au niveau
http, le mode proxy ou reverse proxy fonctionne de la même manière.
Pour moi le logiciel ISA Server est un bon investissement dans le cas où le flux sortant
pour les connexions à Internet n’est pas très élevé.
Pour finir, j’ai pu mettre en place un annuaire LDAP et regarder les principales
fonctionnalités du protocole LDAP. J’ai pu démontrer comment fonctionnait un
referall et surtout comment fonctionnait une réplication entre serveurs.
De plus j’ai pu mettre en œuvre une petite application qui permet à un Firewall Check
Point d’authentifier un client à travers un annuaire LDAP.
Je considère donc que j’ai atteint les objectifs fixés et je pense que les résultats
obtenus, correspondent aux attentes qui m’étaient demandées tout au long de mon
diplôme.
Je remercie donc Messieurs Litzistorf et Jenny pour m’avoir confié un sujet si

intéressant.
GAIO Pascal
Flux Applicatif 137

Table des Matières
Chapitre 1 : Le cache Web.......................................................................... 1

1.1 Qu’est-ce que le cache ..............................................................................................................................................7
1.1.1 Les recherches d’informations..........................................................................................................................7
1.1.2 Les programmes à disposition..........................................................................................................................8
1.2 Le cache vu par le client...........................................................................................................................................9
1.2.1 Localisation du cache.........................................................................................................................................9
1.2.2 Suppression du cache....................................................................................................................................... 11
1.2.3 L’historique........................................................................................................................................................ 12
1.2.4 Le menu déroulant ............................................................................................................................................ 13
1.3 Que se passe-t-il réellement lorsque j’accède à un site sur Internet ? ............................................................ 16
1.4 Différence entre une connexion au site avec cache ou sans cache. ................................................................ 19
1.5 Rafraîchissement des pages ................................................................................................................................... 22
1.6 Voir le cache des autres utilisateurs de la même machine ............................................................................... 24
Chapitre 2 : Gestion du cache d’Internet Explorer.................................... 27

2.1 Option Never ............................................................................................................................................................ 28
2.2 L’option Automatically........................................................................................................................................... 29
2.3 L’option Every time you start internet Explorer ................................................................................................ 32
2.4 L’option Every visit to the page ............................................................................................................................ 35
2.5 Résumé de toutes les options d’ Internet Explorer ............................................................................................. 36
Chapitre 3 : Le cache vu par le serveur Web............................................ 37

3.1 Installation du serveur Web................................................................................................................................... 37
3.2 Commandes HTTP.................................................................................................................................................. 39
3.3 L’onglet HTTP Headers ......................................................................................................................................... 40
3.4 Principales commandes HTTP.............................................................................................................................. 41
3.4.1 Commande no-cache ........................................................................................................................................ 42
3.4.2 Commande max-age ......................................................................................................................................... 43
3.5 Les fichiers LOG ............................................................................................................................................... 44
3.6 Conclusion ................................................................................................................................................................ 45
Chapitre 4 : ISA Server Première Partie .................................................. 46

4.1 Configuration requise............................................................................................................................................. 46
4.2 Le mode cache................................................................................................................................................... 47
4.3 Le mode Firewall .................................................................................................................................................... 47
4.4 Le mode Integrated ................................................................................................................................................. 48
4.5 Choix décidé pour l’installation............................................................................................................................ 48
4.6 Différents modes de mise en cache ...................................................................................................................... 49
4.6.1 http Caching....................................................................................................................................................... 50
4.6.2 Active Caching................................................................................................................................................... 51
4.7 HTTP 1.0 VS HTTP 1.1......................................................................................................................................... 52
Chapitre 5 : ISA Server Deuxième Partie ................................................. 54
Flux Applicatif 138

5.1 Introduction.............................................................................................................................................................. 54
5.2 Fonctionnement du Serveur ISA ........................................................................................................................... 55
5.3 Test avec un seul client et une carte Ethernet sur ISA ...................................................................................... 56
5.4 Mode http Header Frequently............................................................................................................................... 57
5.4.1 Commande max-age envoyée par le serveur Web....................................................................................... 57
5.4.2 Cache présent valide sur le client et sur ISA avec rafraîchissement F5 ................................................... 58
5.4.3 Cas où le serveur Web envoi un no-cache ..................................................................................................... 60
5.4.4 Cache présent sur le client et sur ISA avec rafraîchissement ENTER...................................................... 63
5.5 Mode http Header Normally ................................................................................................................................ 63
5.5.1 Aucun cache présent sur le client mais présent sur ISA............................................................................. 64
5.5.2 Cache présent sur le client et présent sur ISA.............................................................................................. 65
5.5.3 Les autres cas ..................................................................................................................................................... 66
5.5.4 Différences entre les modes http Caching .................................................................................................... 67
5.6 Mode Active Caching ............................................................................................................................................ 68
5.7 Ajout d’un deuxième client .................................................................................................................................. 69
5.8 Fonctionnement du serveur ISA avec 2 cartes Ethernet .................................................................................. 70
5.9 Server Web Down................................................................................................................................................... 71
5.10 Les principales commandes HHTP rencontrées .......................................................................................... 72
5.11 Les fichiers LOG ............................................................................................................................................... 73
5.12 Qu’a-t-on gagné avec ISA ? ............................................................................................................................ 74
Chapitre 6 : Reverse Proxy........................................................................ 75

6.1 Installation de ISA Server en mode Reverse Proxy........................................................................................... 76
6.2 Tests en mode Reverse Proxy................................................................................................................................ 78
6.2.2 Connexion de deux clients sur le serveur Web............................................................................................ 80
6.3 Conclusion ................................................................................................................................................................ 81
Chapitre 7 : LDAP Principes .................................................................... 82

7.1 Les concepts de LDAP ........................................................................................................................................... 83
7.2 Les principes de LDAP .......................................................................................................................................... 83
7.3 Les annuaires LDAP ............................................................................................................................................... 85
7.4 Les choix effectués.................................................................................................................................................. 86
7.4.1 Installation du serveur iPlanet......................................................................................................................... 87
7.4.2 Installation du client ......................................................................................................................................... 87
7.5 Création de l’annuaire LDAP................................................................................................................................ 87
7.5.1 Architecture Annuaire EIG ............................................................................................................................. 88
7.5.2 Architecture Annuaire Elèves ......................................................................................................................... 88
7.5.3 Architecture Annuaire Professeurs ................................................................................................................ 89
7.5.4 Création de membres ........................................................................................................................................ 89
7.6 Conclusion ................................................................................................................................................................ 91
Chapitre 8 : LDAP Protocole .................................................................... 92

8.1 Structure de la trame du protocole LDAP ........................................................................................................... 93
8.1.1 Le champ Type.................................................................................................................................................. 93
8.1.2 Le champ Length............................................................................................................................................... 95
8.1.3 Le champ Content............................................................................................................................................. 96
8.2 Etude détaillée du paquet Search Response........................................................................................................ 97
8.3 Accès à un annuaire .............................................................................................................................................. 100
8.4 Recherches de données dans l’annuaire............................................................................................................ 101
8.5 Ajout d’un utilisateur............................................................................................................................................ 102
8.6 Delete d’une branche de l’annuaire .................................................................................................................... 103
8.7 Server LDAP Down............................................................................................................................................... 104
8.8 Connexion avec Size Limit limité....................................................................................................................... 105
8.9 Déconnexion de l’annuaire .................................................................................................................................. 107
8.10 Conclusion......................................................................................................................................................... 107
Chapitre 9 : LDAP Referral .................................................................... 108
Flux Applicatif 139

9.1 Syntaxe d’un Referral........................................................................................................................................... 109

9.2 Les types de referrals ........................................................................................................................................... 109
9.3 Comment ajouter un referral avec iPlanet ........................................................................................................ 111
9.4 Etude d’un referral au niveau du protocole...................................................................................................... 111
9.5 Conclusion......................................................................................................................................................... 112
Chapitre 10 : LDAP Réplication ............................................................. 113

10.1 Le fichier LDIF................................................................................................................................................. 113
10.2 Réplication entre serveur ................................................................................................................................ 114
10.2.1 La réplication totale (Méthode 1) .................................................................................................................. 114
10.3 Etude de protocole de la réplication totale................................................................................................... 115
10.4 Etude de protocole de la réplication des modifications ............................................................................. 120
10.5 Conclusion......................................................................................................................................................... 123
Chapitre 11 : Application LDAP............................................................. 124

11.1 Création d’un compte utilisateur ................................................................................................................... 125
11.2 Accès au serveur Web par le client ............................................................................................................... 126
11.3 Analyse d’une connexion sur le serveur Web............................................................................................. 127
11.4 Connexion avec password erroné.................................................................................................................. 131
11.5 Connexion avec un login erroné .................................................................................................................... 132
11.6 Reconnexion au serveur Web ......................................................................................................................... 133
11.7 Conclusion......................................................................................................................................................... 133
Chapitre 12 : Bibliographie..................................................................... 134
Flux Applicatif 140

Flux Applicatifs HTTP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Flux Applicatifs HTTP

Uploaded by

Copyright:

Available Formats

Ecole d’Ingénieurs de Genève HES-SO Session 2001

Laboratoire de transmission de données

Professeur de diplôme : M. Eric Jenny

Ce mémoire est divisé en trois parties bien distinctes.

A mes parents, qui m’ont soutenu tout au long de mon diplôme.

A M.Litzistorf, qui ma permis de faire ce diplôme dans son laboratoire.

Tous les textes en italique sont des mots en Anglais.

Table des Matières

Chapitre 1 : Le cache Web.......................................................................... 6

Chapitre 2 : Gestion du cache d’Internet Explorer.................................... 27

Chapitre 3 : Le cache vu par le serveur Web............................................ 37

Chapitre 4 : ISA Server Première Partie .................................................. 46

Chapitre 5 : ISA Server Deuxième Partie ................................................. 54

Chapitre 6 : Reverse Proxy........................................................................ 75

Chapitre 7 : LDAP Principes .................................................................... 82

Chapitre 8 : LDAP Protocole .................................................................... 92

Chapitre 9 : LDAP Referral .................................................................... 108

Chapitre 10 : LDAP Réplication ............................................................. 113

Chapitre 11 : Application LDAP............................................................. 124

Chapitre 12 : Bibliographie..................................................................... 134

Chapitre 1 : Le cache Web

1.1 Qu’est-ce que le cache

1.1.1 Les recherches d’informations

Les sites où les informations sont les meilleures à ce sujet restent :

1.1.2 Les programmes à disposition

Nom du Adresse du site

Cache Sentry http://www.mindspring.com/~dpoch/enigmatic/cachesentry.html

1.2 Le cache vu par le client

1.2.1 Localisation du cache

Afin de pouvoir localiser le contenu du cache du côté client, il faut permettre à

C:/Documents and Settings/Userx/Local Settings/Temporary Internet Files

En cliquant sur settings, on peut modifier l’emplacement du fichier où seront stockées

1.2.2 Suppression du cache

Pour effacer le contenu du cache, il suffit d’exécuter la procédure suivante.

Une fois cliqué sur Delete Files, il

Les cookies ici présents doivent malheureusement être effacés manuellement.

Le répertoire en question se trouve sous :

Voilà ce que l’on peut y voir :

En cliquant sur l’icône History, il

Lorsque l’on accède à un site, ce répertoire est donc remis à jour.

1.2.4 Le menu déroulant

start -> run et en tapant regedt32.

Dans les registres de Windows, ils se trouvent sous le registre

Les deux listes

Contrairement au cas d’avant, ces données sont directement issues de l’historique. En

1.3 Que se passe -t-il réellement lorsque j’accède à un site sur

Ici je résumerai les chapitres vu précédemment en faisant une démonstration de ce qui

Prenons l’exemple d’une connexion au site eig.unige.ch

Dans Internet Explorer, je tape l’adresse eig.unige.ch et j’obtiens ma page.

Client Server Web

Dans l’historique, apparaît la page que j’ai visité.

J’aurai si j’ouvre le répertoire, toutes les pages sous-jacentes du site.

Un dernier endroit où se stockent des informations lorsque j’accède à un site, se trouve

1.4 Différence entre une connexion au site avec cache ou sans

Cette partie consistera à se connecter sur le site www.microsoft.com

Tests dans le cas où aucun cache n’est présent sur le disque.

Tests dans le cas où le cache est présent sur la machine de l’utilisateur

Date d’expiration encore valide :

Date d’expiration dépassée :

Fichiers stockés dans

Oui. Echange de données avec le serveur Web

Gain total Gain par Gain par

1.5 Rafraîchissement des pages

L’échange sera du type :