Le proxy
Comment ça marche ?
Principe de base
Le principe de base consiste à dire :
Lorsque je désire obtenir un document, je ne vais pas le demander à la source. Je vais le demander à mon serveur proxy. Celui-ci ira chercher le document à ma place et me le transmettra à sa réception. Au passage, il le gardera en mémoire "un certain temps", si bien que si un autre client redemande dans cette période le même document, le proxy n'aura pas besoin de retourner le chercher à la source. Ceci ne fonctionne correctement que pour les documents statiques, bien entendu. Pour les documents de type ASP, JSP ou PHP, la mise en tampon est à proscrire.
Ce type de fonctionnement, où le client s'adresse systématiquement au proxy pour obtenir une page quelconque sur le web a fait traduire "proxy server" par "serveur mandataire".
Les avantages
Optimisation de la bande passante
Imaginons un cas simple :
- Nous sommes dans un lycée technique, les étudiants qui sont dans un laboratoire, disposent chacun d'un poste informatique. Tous ces postes sont en réseau local, avec un accès à l'Internet partagé par un routeur NAT.
- Tous les étudiants doivent consulter un document, disons, chez Texas Instrument.
- Il y a 14 postes, il y aura 14 requêtes identiques vers le serveur de TI et 14 envois de documents identiques vers les clients.
- Nous remplaçons le routeur NAT par un serveur Proxy. Dans ce cas :
- La première requête sera transmise par le proxy vers le serveur de TI.
- Les 13 autres seront servies directement par le cache du proxy.
Un seul transfert de page depuis le serveur Texas Instruments vers le réseau local en remplace 14.
Surveillance et filtrage de l'accès au Net
Parmi nos 14 élèves, il y en aura bien un qui aura l'idée, en passant, d'aller faire un petit tour sur par exemple http://www.canalcharme.com (ou pire. N'y voyez pas de puritanisme de ma part, juste un souci d'efficacité dans le travail et une obligation légale de protection des mineurs ;-) )..
- Avec un routeur NAT, le filtrage va être difficile, parce que le seul moyen "simple" serait de filtrer au niveau de l'IP du serveur.
- Avec un proxy comme SQUID, qui travaille au niveau HTTP et qui "voit" donc passer les URI, il existera une foule de solutions qui permettront un filtrage :
- Par mot clé sur les URL.
- Par bannissement de domaines ou d'URI référencés dans une base de données
Les inconvénients
Parce qu'il y en a tout de même...
- La durée de vie du cache et les mauvais paramétrages entraînent que les documents reçus peuvent ne plus être à jour.
- A multiplier les proxy en chaîne, on amplifie ce problème et on court aussi le risque de recevoir des documents falsifiés. En effet, s'il est intéressant de monter un proxy en tête d'un réseau local, il faut savoir que les FAI peuvent en utiliser aussi, de façon plus ou moins transparente (nous verrons ça plus loin). Un serveur proxy, ça peut être piraté et "bricolé"...
Le client doit être au courant...
Il faut commencer par paramétrer son navigateur Internet pour qu'il fasse appel à un proxy. Nous comprendrons mieux pourquoi en analysant le réseau.
Pour Internet Explorer, c'est assez simple :
 |
Menu "Outils", commande "Options internet...", onglet "Connexions" :
Utilisez le bouton "Paramètres réseau..." |
 |
Ne faites pas confiance aux systèmes automatisés (dans la mesure du possible) et indiquez plutôt explicitement les paramètres du proxy :
Ne pas utiliser les adresses locales n'a pas beaucoup de sens. Ca ne semble fonctionner convenablement que pour la résolution des noms de type WINS. Le bouton "Avancé" nécessite un détour... |
 |
Il vous permet :
Ici, toutes les requêtes relatives à tous les hôtes du domaine "maison.mrs" ne seront pas adressées au proxy. Il n'y a en effet aucun intérêt à passer par le proxy pour l'ensemble des sites intranet, si les serveurs sont sur le même réseau local. |
Voilà. Si le proxy est bien configuré, ça devrait fonctionner...
Que se passe-t-il, en fait ?
Le plus souvent...
Un proxy est placé entre un réseau local privé et un accès Internet. La configuration est alors la suivante :
Le proxy dispose de deux adresses :
- L'une dans le réseau privé (192.168.0.253 dans l'exemple)
- L'autre sur le réseau du FAI (80.8.128.5 dans l'exemple)
Le proxy isole complètement le réseau privé de l'Internet. Il ne servira que de serveur mandataire pour les requêtes HTTP (éventuellement aussi FTP). Avec la floraison de services "webmail" proposée par les fournisseurs de services, cette configuration peut permettre l'accès aux trois services les plus utilisés sur le Net :
- Le surf (HTTP)
- Le téléchargement de fichiers (FTP)
- Le courrier, pris en charge par l'interface webmail du FAI.
Si l'on se contente de ces trois services, il n'est alors pas nécessaire d'installer de routeur NAT, le proxy suffit. Mais comprenons nous bien : Seuls les protocoles HTTP et FTP passeront, sauf cas de proxy plus particuliers, ce qui n'est pas l'objet de cette présentation.
Dans la démonstration qui suit :
Le montage adopté n'est pas obligatoirement le plus utile. Il n'y a d'ailleurs pas de connexion Internet mise en oeuvre ici. Ce montage est juste fait pour illustrer le travail du proxy, lorsqu'il est utilisé.
Notez bien que 192.168.0.251 (qui est en fait ma passerelle NAT vers le Net, bien que cette fonction ne serve pas ici), est également mon DNS, ça va se voir dans l'exemple.
Premier cas : Sans le proxy
Le client va demander la page d'accueil du site hébergé sur le serveur HTTP. Il va le faire directement :
No. Source Destination Protocol Info 4 192.168.0.10 192.168.0.251 HTTP GET / HTTP/1.1 6 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK 7 192.168.0.10 192.168.0.251 HTTP GET /tbm.htm HTTP/1.1 8 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK 9 192.168.0.251 192.168.0.10 HTTP Continuation 11 192.168.0.251 192.168.0.10 HTTP Continuation 16 192.168.0.10 192.168.0.251 HTTP GET /home.htm HTTP/1.1 18 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK 19 192.168.0.251 192.168.0.10 HTTP Continuation 23 192.168.0.10 192.168.0.251 HTTP GET /banniere.htm HTTP/1.1 24 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK 25 192.168.0.251 192.168.0.10 HTTP Continuation etc...
J'ai volontairement fait disparaître les trames SYN, ACK de TCP, qui ne nous apportent rien dans la compréhension de l'échange. Nous voyons clairement que l'échange se fait entre le client et le serveur HTTP.
Second cas : Avec le proxy
Nous paramétrons maintenant notre client pour qu'il utilise le proxy 192.168.0.253. Nous vidons le cache du navigateur et refaisons notre requête. Le proxy est également "tout neuf" son cache est parfaitement vide.
No. Source Destination Protocol Info 4 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/ HTTP/1.0 La requête a été faite au proxy et non pas à la cible qui est 192.168.0.251... Le proxy, cherche alors l'IP de la cible : (192.168.0.251 est aussi DNS dans l'exemple). 6 192.168.0.253 192.168.0.251 DNS Standard query A gw2.maison.mrs 7 192.168.0.251 192.168.0.253 DNS Standard query response A 192.168.0.251 Puis transmet la requête à la cible... 11 192.168.0.253 192.168.0.251 HTTP GET / HTTP/1.0 La cible répond au proxy : 13 192.168.0.251 192.168.0.253 HTTP HTTP/1.1 200 OK qui retransmet au client: 15 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK et ainsi de suite... 16 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/tbm.htm HTTP/1.0 18 192.168.0.253 192.168.0.251 HTTP GET /tbm.htm HTTP/1.0 20 192.168.0.251 192.168.0.253 HTTP HTTP/1.1 200 OK 22 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK 23 192.168.0.251 192.168.0.253 HTTP Continuation 25 192.168.0.253 192.168.0.10 HTTP Continuation 26 192.168.0.251 192.168.0.253 HTTP Continuation 28 192.168.0.251 192.168.0.253 HTTP Continuation 31 192.168.0.253 192.168.0.10 HTTP Continuation 35 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/banniere.htm HTTP/1.0 37 192.168.0.253 192.168.0.251 HTTP GET /banniere.htm HTTP/1.0 41 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/home.htm HTTP/1.0 46 192.168.0.253 192.168.0.251 HTTP GET /home.htm HTTP/1.0 48 192.168.0.251 192.168.0.253 HTTP HTTP/1.1 200 OK 49 192.168.0.251 192.168.0.253 HTTP Continuation 51 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK 52 192.168.0.253 192.168.0.10 HTTP Continuation 54 192.168.0.251 192.168.0.253 HTTP HTTP/1.1 200 OK 56 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK 57 192.168.0.251 192.168.0.253 HTTP Continuation etc...
Bien. Pour l'instant, c'est plutôt nettement plus compliqué et plus lourd qu'une requête directe.
Nous pouvons d'ailleurs suivre les événements à travers les logs du serveur SQUID :
192.168.0.10 TCP_MISS/200 1421 GET http://gw2.maison.mrs/ - DIRECT/192.168.0.251 text/html 192.168.0.10 TCP_MISS/200 4365 GET http://gw2.maison.mrs/tbm.htm - DIRECT/192.168.0.251 text/html 192.168.0.10 TCP_MISS/200 1513 GET http://gw2.maison.mrs/banniere.htm - DIRECT/192.168.0.251 text/html 192.168.0.10 TCP_MISS/200 4228 GET http://gw2.maison.mrs/home.htm - DIRECT/192.168.0.251 text/html etc...
Le TCP_MISS indique que le proxy n'a pas la réponse en cache et qu'il va donc la chercher à la source (DIRECT)
Mais maintenant, le cache du proxy n'est pas vide, il contient désormais ces documents. Nous allons le vérifier immédiatement en :
- Vidant le cache local du navigateur.
- Effectuant à nouveau la même requête.
No. Source Destination Protocol Info 4 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/ HTTP/1.0 6 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK 7 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/tbm.htm HTTP/1.0 8 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK 9 192.168.0.253 192.168.0.10 HTTP Continuation 11 192.168.0.253 192.168.0.10 HTTP Continuation 16 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/banniere.htm HTTP/1.0 18 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK 19 192.168.0.253 192.168.0.10 HTTP Continuation 24 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/home.htm HTTP/1.0 26 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK 27 192.168.0.253 192.168.0.10 HTTP Continuation etc...
Et là, nous constatons que le dialogue s'effectue uniquement entre le client et le proxy. Autrement dit, le proxy sert au client la totalité des requêtes, il n'y a plus aucun échange entre le proxy et le serveur HTTP.
Vérifions les logs :
192.168.0.10 TCP_MEM_HIT/200 1430 GET http://gw2.maison.mrs/ - NONE/- text/html 192.168.0.10 TCP_MEM_HIT/200 4374 GET http://gw2.maison.mrs/tbm.htm - NONE/- text/html 192.168.0.10 TCP_MEM_HIT/200 1522 GET http://gw2.maison.mrs/banniere.htm - NONE/- text/html 192.168.0.10 TCP_MEM_HIT/200 4237 GET http://gw2.maison.mrs/home.htm - NONE/- text/html etc...
TCP_MEM_HIT veut dire que non seulement la réponse est en cache (HIT) mais qu'elle est en mémoire (MEM). Il n'y a donc pas d'interrogation en amont (NONE).
Notez qu'il aurait pu se passer autre chose. Ici, la requête initiale et la seconde requête du client étaient séparées par un intervalle de temps très court. Si cet intervalle avait augmenté, le document ne se serait peut-être plus trouvé dans le cache mémoire, mais dans le cache disque, et il aurait pu se faire que le proxy aille s'assurer auprès du serveur source que son contenu local était encore valide. La stratégie est assez logique :
- Un document qui vient d'être téléchargé par le proxy a toutes les chances d'être toujours valide. Il est donc possible de le resservir directement, sans précautions particulières.
- Un document qui a été téléchargé il y a déjà quelques temps, risque d'avoir été modifié. Il convient donc de s'assurer d'abord auprès du serveur source que le document n'a pas été modifié depuis.
- Un document qui a été téléchargé il y a trop longtemps est détruit du cache du proxy. au prochain appel, il faudra le télécharger à nouveau.
Les notions de "vient d'être", "il y a déjà quelques temps" et "il y a trop longtemps" sont bien entendu subjectives et c'est à l'administrateur du proxy de les évaluer efficacement.
Il y a tout de même quelques exceptions à ces règles :
- Les documents "actifs" , nous l'avons déjà dit, tels que les pages PHP, ASP, JSP... ou qui viennent de scripts CGI
- Les documents "passifs", mais qui contiennent un champ "expire" dans leur en-tête. Ce champ, assez peu utilisé, permet au concepteur d'une page de forcer l'attitude d'un proxy à son égard.
Finalement...
- Lorsque la connexion entre le réseau local et le Net se fait par un lien facturé à la durée ou au volume transmis, le gain financier peut être appréciable .
- Lorsque la connexion au Net se fait par un lien à faible débit, le gain en temps peut également être appréciable.
- Nous ne le verrons pas ici dans le détail, mais les possibilités de contrôle d'accès au Net sont plus grandes et plus simples à mettre en oeuvre avec un proxy qu'avec un routeur. De même, la sécurité du réseau local est plus facilement assurée, si le serveur proxy n'est vraiment qu'un proxy.
- La solution du proxy n'est cependant pas la panacée et il convient de bien analyser toutes les solutions possibles à un problème donné avant d'en choisir une.