Après avoir vu comment Squid fonctionnait dans les grandes lignes, on s’intéresse maintenant à son installation et à son démarrage. Les explications qui suivent concernent l’installation du serveur sur une distribution Ubuntu 10.04 LTS.

6. Installation

Pour l’installation de Squid, on utilise ici le gestionnaire de package apt. Il est toutefois possible de compiler les sources du serveur manuellement pour bénéficier d’une plus grande flexibilité à l’exécution. Pour installer la dernière version de Squid, il suffit donc d’ouvrir un terminal et de taper la commande suivante :

L’installation de Squid se lance alors et voici les différents répertoires créés à l’issue de la procédure :

/usr/sbin/ – Contient l’exécutable

/etc/squid3/ – Contient le fichier principal de configuration squid.conf

/var/log/squid3/ – Contient les fichiers de log access.log & cache.log

/var/spool/squid3/ – Contient les données de cache persistées par Squid sur le disque.

Il y a deux façons de démarrer Squid :

La première permet de démarrer Squid en tâche de fond. La seconde permet de spécifier des options de démarrage et de lancer le processus dans le terminal avec par exemple un niveau de débug de 1 (les entrées du fichier cache.log sont alors directement affichées dans la console).

Pour plus d’informations sur les options de lancement de Squid, l’utilisateur peut lancer Squid avec l’option –help.

7. Configuration de Squid

Toute la configuration de Squid est par défaut stockée dans le fichier principal /etc/squid3/squid.conf. Ce fichier contient tous les paramètres de lancement de Squid ainsi qu’une description assez complète de chacun d’eux. Squid peut également être lancé avec un autre fichier de configuration grâce à l’option -f. La configuration du serveur peut également être répartie sur plusieurs fichiers qui sont référencés au sein d’un fichier principal.

Voici la définition de quelques options de configuration basiques :

http_port : permet de définir le port sur lequel se lance Squid. Par défaut, Squid se lance sur le port 3128. Il est également possible de définir plusieurs ports.

cache_dir : permet d’indiquer à Squid où stocker les données mises en cache sur le disque. Squid est conçu pour travailler en mémoire afin de charger plus rapidement les données mises en cache. Toutefois, lorsque la mémoire est insuffisante ou que le serveur doit être stoppé, Squid va basculer les données en cache mémoire sur le disque afin de pouvoir en charger d’autres ou les recharger par la suite. Pour mettre en place cette politique de remplacement des données en cache lorsque la mémoire est insuffisante, Squid utilise un algorithme de type LRU (Least Recently Used). Les données les moins sollicitées sont écrites sur le disque pour libérer de la mémoire. L’option cache_dir permet de spécifier au serveur où stocker les données de cache sur le disque et de quelle façon. Le premier argument correspond à l’emplacement disque, le second à l’espace alloué (100 Méga-octets dans l’exemple ci-dessous), le troisième au nombre de répertoires racine, et le dernier au nombre de sous-répertoires. Cette arborescence permet de constituer un index rapide d’accès.

http_access, icp_access : cette option permet de restreindre l’accès HTTP et ICP en spécifiant des règles de contrôle d’accès (ACls pour access control lists). Chaque requête HTTP ou ICP provoque la vérification de ces règles d’accès. Cet aspect lié à la sécurité est un des points très importants dont il faut se soucier dès l’installation et la mise en route de Squid. Cette partie n’est pas traitée dans cet article mais on donne ci-dessous les paramètres par défaut contenus dans le fichier de configuration qui restreignent l’utilisation du serveur au poste local :

Un des avantages de Squid est qu’il peut mettre en cache les résolutions DNS et ainsi traiter les requêtes plus rapidement. Deux paramètres peuvent être configurés pour influer sur la durée de ce cache :

positive_dns_ttl : permet de définir la limite supérieure au-delà de laquelle le serveur invalidera une résolution DNS positive mise en cache. Par défaut cette option est positionnée à 6 heures (360 minutes). Cette valeur doit être plus grande que celle de l’option negative_dns_ttl.

negative_dns_ttl : permet de définir la durée pendant laquelle une résolution DNS négative sera gardée en cache. La valeur minimale est de 1 seconde et il n’est pas recommandé d’aller au-delà de 10 secondes.

Les options qui suivent peuvent également être assez utiles pour afficher des traces de debug et comprendre certains fonctionnements internes de Squid :

log_mime_hdrs : permet d’afficher les en-têtes HTTP des requêtes et des réponses dans les logs d’activité.

debug_options : cette option permet d’afficher les différentes informations de debug de Squid. Le système de log du serveur est décomposé en sections. Il est donc possible de paramétrer le niveau de log de chacune de ces sections en fonction de ce que l’on souhaite étudier. Il existe 93 sections et 10 niveaux de debug, de 0 à 9, 9 étant le plus précis. Voici une configuration qui permet d’avoir un peu plus d’informations sur les traitements réalisés par Squid en interne (attention toutefois car les fichiers de log peuvent très vite devenir volumineux) :

Le fichier de configuration de Squid comporte un peu plus de 300 options qui permettent de finement paramétrer le serveur. Pour appliquer une modification faite dans le fichier de configuration, il est toutefois nécessaire de redémarrer le serveur. Il faut également penser à toujours garder une version stable du fichier de configuration, une solution pouvant être de le mettre sous une version de contrôle pour pouvoir annuler toute modification aux effets indésirables.

8. Les fichiers de log

En dehors du fichier de configuration qui permet de paramétrer Squid, d’autres fichiers d’importance permettent de surveiller l’activité du serveur. Il s’agit des fichiers de log. Le premier d’entre eux est le fichier cache.log qui contient les informations propres au lancement et à l’arrêt du serveur. Il répertorie également les problèmes majeurs rencontrés par le serveur et affiche certaines informations de configuration. On donne ici le contenu du fichier de log suite au démarrage du serveur :

2011/05/01 21:44:19| Process ID 4434

2011/05/01 21:44:19| With 1024 file descriptors available

2011/05/01 21:44:19| Performing DNS Tests…

2011/05/01 21:44:19| Successful DNS name lookup tests…

2011/05/01 21:44:19| DNS Socket created at 0.0.0.0, port 33957, FD 5

2011/05/01 21:44:19| Adding domain home from /etc/resolv.conf

2011/05/01 21:44:19| Adding domain home from /etc/resolv.conf

2011/05/01 21:44:19| Adding nameserver 192.168.1.1 from /etc/resolv.conf

2011/05/01 21:44:19| Unlinkd pipe opened on FD 10

2011/05/01 21:44:19| Local cache digest enabled; rebuild/rewrite every 3600/3600 sec

2011/05/01 21:44:19| Swap maxSize 102400 + 8192 KB, estimated 8507 objects

2011/05/01 21:44:19| Target number of buckets: 425

2011/05/01 21:44:19| Using 8192 Store buckets

2011/05/01 21:44:19| Max Mem size: 8192 KB

2011/05/01 21:44:19| Max Swap size: 102400 KB

2011/05/01 21:44:19| Version 1 of swap file with LFS support detected…

2011/05/01 21:44:19| Rebuilding storage in /var/spool/squid3 (CLEAN)

2011/05/01 21:44:19| Using Least Load store dir selection

2011/05/01 21:44:19| Set Current Directory to /var/spool/squid3

2011/05/01 21:44:19| Loaded Icons.

2011/05/01 21:44:19| Accepting HTTP connections at 0.0.0.0, port 3128, FD 12.

2011/05/01 21:44:19| Accepting ICP messages at 0.0.0.0, port 3130, FD 13.

2011/05/01 21:44:19| HTCP Disabled.

2011/05/01 21:44:19| Ready to serve requests.

2011/05/01 21:44:19| Done reading /var/spool/squid3 swaplog (4 entries)

2011/05/01 21:44:19| Finished rebuilding storage from disk.

2011/05/01 21:44:19| 4 Entries scanned

2011/05/01 21:44:19| 0 Invalid entries.

2011/05/01 21:44:19| 0 With invalid flags.

2011/05/01 21:44:19| 4 Objects loaded.

2011/05/01 21:44:19| 0 Objects expired.

2011/05/01 21:44:19| 0 Objects cancelled.

2011/05/01 21:44:19| 0 Duplicate URLs purged.

2011/05/01 21:44:19| 0 Swapfile clashes avoided.

2011/05/01 21:44:19| Took 0.02 seconds (164.98 objects/sec).

2011/05/01 21:44:19| Beginning Validation Procedure

2011/05/01 21:44:19| Completed Validation Procedure

2011/05/01 21:44:19| Validated 33 Entries

2011/05/01 21:44:19| store_swap_size = 124

2011/05/01 21:44:20| storeLateRelease: released 0 objects

On trouve dans ce fichier beaucoup d’informations allant du nombre de descripteurs de fichiers ouverts jusqu’à la mémoire allouée. Il est possible de se référer à la documentation officielle pour obtenir plus de détails sur ce fichier.

Un autre fichier de log qui s’avère plus utile dans l’exploitation de Squid est le fichier access.log. Ce dernier répertorie tous les accès faits au serveur, c’est-à-dire toutes les requêtes HTTP reçues et la façon dont elles ont été traitées. Le format de ce fichier est paramétrable via l’option access_log du fichier squid.conf. Le format natif d’une entrée de log est le suivant :

time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type

1 – time : le temps UTC (en ms) auquel la requête a été reçue.

2 – elapsed : le temps de traitement par le serveur de la requête (en ms). Ce temps de traitement diffère selon le mode utilisé (connecté ou déconnecté) :

– Pour TCP, il s’agit du temps écoulé entre le moment où le serveur a reçu la requête et le moment où il a répondu au client.

– Pour UDP, il s’agit du temps calculé entre le moment où le serveur prévoit de répondre au client et le moment où il lui répond effectivement.

3 – remotehost : l’adresse IP du client. Cette donnée peut être cachée pour rendre les logs anonymes.

4 – code/status : le code résultat de la transaction. Ce champ est composé de deux entrées séparées par un slash : le code de statut de Squid et le code HTTP de la réponse du serveur d’origine. La plupart de ces codes sont détaillés plus bas.

5 – bytes : la taille de la donnée livrée au client.

6 – method : la méthode utilisée pour récupérer la ressource (GET, HEAD, etc.).

7 – URL : l’URL de la ressource demandée.

8 – rfc931 : les informations utilisateurs (désactivé par défaut).

9 – hierarchy code : un code permettant de savoir comment la requête a été traitée. Ce code peut être suivi par l’adresse IP vers laquelle la requête a été redirigée.

10 – type : le type de contenu issu du header HTTP de la réponse (Les échanges ICP ne contiennent pas cette information).

Voici un exemple d’une entrée du fichier acces.log :

1308514407.655 3 127.0.0.1 TCP_HIT/200 13342 GET http://www.web-caching.com/ – NONE/- text/html

Le format de ce fichier est également paramétrable pour être compatible avec certains analyseurs de log.

Concernant le code de statut renvoyé par Squid pour chaque requête, on donne ici les principaux d’entre eux. Les codes préfixés par ‘TCP_’ font référence aux requêtes reçues sur le port HTTP, les codes préfixés par ‘UDP_’ faisant eux référence aux requêtes reçues sur le port ICP. Si l’option de logging ICP log_icp_queries n’est pas activée, aucune activité concernant les échanges ICP n’est visible dans les logs :

TCP_HIT : une copie valide de l’objet demandé a été trouvée dans le cache.

TCP_MISS : l’objet demandé n’a pas été trouvé dans le cache.

TCP_REFRESH_HIT : l’objet demandé a été trouvé dans le cache mais est considéré comme périmé. La requête IMS a renvoyé un code 304-Not Modified et la ressource mise en cache est retournée.

TCP_REFRESH_FAIL_HIT : l’objet demandé a été trouvé dans le cache mais est considéré comme périmé. La requête IMS a échoué et le contenu périmé a été délivré au client.

TCP_REFRESH_MISS : l’objet demandé a été trouvé dans le cache mais est considéré comme périmé. La requête IMS a retourné le nouvel objet.

TCP_DENIED : l’accès a été refusé pour cette demande.

UDP_HIT : une copie valide de l’objet a été trouvée dans le cache.

UDP_MISS : l’objet demandé n’était pas dans le cache.

UDP_DENIED : l’accès a été refusé pour cette demande.

UDP_INVALID : une requête invalide a été reçue.

Le fichier de log store.log est aussi très utile pour décrire l’activité d’écriture sur le disque de Squid. Dans ce log, il est possible de voir quels objets ont été stockés ou rechargés.

L’activité de log de Squid est centrale dans l’utilisation qui est faite du serveur. Elle permet en premier lieu de comprendre comment le serveur se comporte et par la suite de diagnostiquer certains problèmes. De nombreux outils de reporting gravitent autour des logs de Squid pour en faciliter l’exploitation. On peut citer par exemple Calamaris ou Webalyzer.

9. Connexion à Squid en ligne de commande

Nous allons maintenant voir comment se connecter à Squid. Pour commencer, nous allons utiliser des outils en ligne de commande permettant de se connecter rapidement à Squid et lui envoyer nos premières requêtes. Pour tester le serveur cache fraîchement installé, nous allons utiliser deux outils, squidclient et curl qui permettent de générer des requêtes HTTP. Pour les installer, il suffit d’ouvrir un terminal et d’entrer les commandes suivantes :

Avant toute chose, assurons-nous que le serveur tourne et affichons les logs du fichier access.log :

On ouvre maintenant un deuxième terminal pour interroger le serveur :

Les options -s et -v permettent ici de voir la requête formulée et envoyée à Squid et de ne pas afficher le contenu HTML de la réponse. On obtient alors dans le premier terminal une entrée similaire à celle-ci :

1308512906.049 1048 127.0.0.1 TCP_MISS/200 13333 GET http://www.web-caching.com – DIRECT/66.147.242.92 text/html

Si l’on récidive, on obtient une nouvelle entrée dans le fichier de log :

1308514407.655 3 127.0.0.1 TCP_HIT/200 13342 GET http://www.web-caching.com/ – NONE/- text/html

Le premier appel montre que la ressource n’était pas présente dans le cache (TCP_MISS/200) et que la requête a été envoyée au serveur d’origine (DIRECT/66.147.242.92). Lors de la seconde tentative, le cache est sollicité et cette fois l’objet est trouvé, Squid renvoie un code TCP_HIT/200 signifiant que l’objet a été trouvé et qu’il est encore valide. Aucune connexion n’est alors faite avec le serveur d’origine (NONE/). On note également que le temps écoulé pour traiter la requête est passé de 1048ms à 3ms.

Pour afficher les informations envoyées par le serveur, il est possible d’utiliser curl ou les outils embarqués dans la plupart des navigateurs web récents. Par exemple, la réponse envoyée par l’hôte www.web-caching.com contient les informations suivantes :

HTTP/1.1 200 OK

Date: Sun, 19 Jun 2011 21:21:18 GMT

Server: Apache

Last-modified: Sat, 02 Jan 2010 15:59:08 GMT

Etag: « 19dc05b-3264-47c30917ceb00 »

Accept-ranges: bytes

Content-length: 12900

Cache-control: max-age=604800

Expires: Sun, 26 Jun 2011 21:21:18 GMT

Connection: close

Content-type: text/html

On observe ici plusieurs directives HTTP évoquées dans la première partie de l’article consacrée à Squid. Les directives Last-modified et Etag permettent à Squid de mettre le contenu en cache (dans cet exemple la directive Expires n’est fournie que pour assurer la rétrocompatibilité avec HTTP/1.0) et la directive max-age permet de contrôler la validité de la ressource à chaque appel.

Utilisons maintenant la même option dans la requête pour forcer le rechargement de la page :

Le fichier access.log affiche une nouvelle entrée:

1308599419.054 419 127.0.0.1 TCP_REFRESH_UNMODIFIED/200 436 HEAD http://www.web-caching.com/ – DIRECT/66.147.242.92 text/html

Squid est ici forcé de revalider son entrée qui n’est pourtant pas périmée. Le serveur retourne un code 304-Not Modified et la version en cache est renvoyée au poste client.

Pour forcer Squid à récupérer à nouveau le contenu auprès du serveur source, il faut procéder ainsi :

Le log d’accès affiche une nouvelle entrée :

1308520569.183 350 127.0.0.1 TCP_CLIENT_REFRESH_MISS/200 437 HEAD http://www.web-caching.com/ – DIRECT/66.147.242.92 text/html

Le code TCP_CLIENT_REFRESH_MISS indique ici que le serveur cache a dû recontacter le serveur d’origine sur demande du client.

Il est également possible d’interroger Squid pour récupérer la version mise en cache et potentiellement périmée depuis un certain temps sans avoir à se connecter au serveur. Pour cela on dispose des directives only-if-cached et max-stale. Si la ressource n’a pas été mise en cache, avec l’utilisation de la directive only-if-cached, un code 504-Gateway timeout est renvoyé au client. Voici un exemple d’utilisation de la directive max-stale :

On commence par récupérer une ressource éligible au cache :

Voici la réponse qui nous est renvoyée :

HTTP/1.0 200 OK

Date: Mon, 20 Jun 2011 22:00:12 GMT

Server: Apache/2.2.3 (CentOS)

Vary: Cookie,User-Agent

Cache-Control: max-age=3600

Expires: Mon, 20 Jun 2011 23:00:12 GMT

Content-Type: text/html; charset=utf-8

X-Cache: MISS from eu6.squid-cache.org

Age: 137

X-Cache: HIT from localhost

X-Cache-Lookup: HIT from localhost:3128

Via: 1.0 eu6.squid-cache.org (squid/3.1.4-BZR), 1.0 localhost (squid/3.0.STABLE19)

Proxy-Connection: keep-alive

Il y a deux informations importantes ici, l’âge de la ressource dans le cache (137, ce qui signifie que la ressource était déjà présente dans le cache avant la requête) et max-age qui a pour valeur 3600 secondes soit 1 heure. La ressource sera donc considérée comme périmée par Squid dans 3463 secondes.

Passé ce délai et considérant que la ressource est périmée depuis 600 secondes, on envoie la requête suivante au serveur :

On obtient de Squid la réponse suivante :

1308607159.201 2 127.0.0.1 TCP_MEM_HIT/200 456 HEAD http://wiki.squid-cache.org/ – NONE/- text/html

Ici on spécifie au proxy cache que l’on est prêt à accepter la ressource si elle n’est pas périmée de plus de 4000 secondes, on reçoit donc la version mise en cache précédemment et périmée depuis.

Cette fois, on précise que seule une réponse périmée de moins de 400 secondes est acceptée :

On obtient alors la réponse suivante :

1308607212.878 341 127.0.0.1 TCP_MISS/200 446 HEAD http://wiki.squid-cache.org/ – DIRECT/77.93.254.178 text/html

Dans ce cas, l’objet est trop ‘vieux’ pour être retourné au client et Squid le récupère auprès du serveur d’origine.

Nous venons de couvrir ici une utilisation basique de Squid à travers des outils en ligne de commande. Ces outils peuvent être très utiles pour comprendre le comportement du serveur et pour diagnostiquer certains problèmes. Nous allons voir dans la prochaine partie comment configurer le navigateur internet pour se connecter à Squid.

10. Configurer son navigateur pour se connecter à Squid

Configurer son navigateur pour se connecter à internet en passant par un proxy est relativement simple. Il existe pour cela plusieurs façons de procéder. La première est une configuration locale qui permet rapidement de mentionner à son navigateur l’adresse et le port du proxy. Généralement, ces informations sont accessibles depuis le panneau d’administration du navigateur. La seconde manière de procéder revient à effectuer une configuration globale, celle-ci étant bien plus adaptée aux réseaux de petite et moyenne envergure. Connue sous le nom de proxy auto-config (PAC), elle consiste à mettre à disposition via un serveur tiers un fichier PAC contenant toute la configuration de connexion d’un poste client. Ce fichier contient une liste de règles permettant au navigateur de savoir quelle est l’adresse du proxy auquel se connecter et quand s’y connecter.

10.1 Configuration basique

La configuration locale est sensiblement la même sur chaque navigateur, seul le moyen d’y accéder pouvant différer. Pour y parvenir, il suffit d’ouvrir le panneau d’administration du navigateur et de renseigner dans la rubrique connexion l’adresse et le port du proxy à utiliser.

Il est généralement possible de renseigner, dans cette même partie, une liste d’hôtes pour lesquels on ne souhaite pas passer par le proxy. Il peut typiquement s’agir de serveurs disponibles sur l’intranet.

10.2 Configuration avancée avec un fichier PAC

La méthode de configuration externalisée a l’avantage de recharger la politique de connexion à chaque lancement de celui-ci. Si certaines règles d’accès changent ou si un nouveau proxy cache est mis en place, il suffit à l’administrateur du réseau de modifier le fichier PAC en conséquence et celui-ci est alors rechargé lorsque les utilisateurs ouvrent à nouveau leur navigateur.

Chaque URL entrée par l’utilisateur est alors sujette à un examen du navigateur pour savoir comment récupérer la ressource. Ce fichier est écrit en JavaScript et est utilisé pour diriger au bon endroit la requête de l’utilisateur. Voici un exemple de fichier PAC basique :

Dans ce fichier de configuration, plusieurs fonctions JavaScript peuvent être utilisées pour élaborer des règles de routage. La plupart sont décrites à cette adresse .

Conclusion

Après avoir étudié les aspects basiques d’utilisation de Squid, il faut garder à l’esprit que l’utilisation du cache HTTP est une chose qui n’est pas systématiquement ou suffisamment considérée par les administrateurs d’applications Web. Beaucoup de sites échappent donc aux serveurs de cache. Le fait que certaines machines intermédiaires puissent conserver une image de leurs sites et délivrer du contenu potentiellement périmé dissuade la plupart d’entre eux d’étudier sérieusement les problématiques de mise en cache.

De plus, grand nombre de sites ne permettent tout simplement pas de faire de la mise en cache. Certaines applications à contenu dynamique ou les sites de commerce en ligne ne peuvent par exemple pas y prétendre pour des raisons de sécurité évidentes.

Les performances réalisées par ce type de serveur, qui peuvent être très intéressantes, concernent donc principalement les sites d’informations. La mise en place d’un tel serveur doit toutefois reposer sur une étude approfondie de l’architecture réseau et des besoins et habitudes des utilisateurs.

Bibliographie

Squid : Optimising Web Delivery

Main Page – Squid User’s Guide

HTTP/1.1: Header Field Definitions

Mnot’s blog http://www.mnot.net/blog

Web-caching.com: Web Caching and Content Delivery Ressources