Tout savoir
Définition
- Squid est un logiciel qui part du principe, que dans un même lieu
les gens vont souvent voir les mêmes choses sur Internet. Il est donc judicieux d'éviter
de rechercher à l'autre bout de la planète une page 5 fois de suite. C'est pourquoi on
utilise un mandataire (un intermédiaire), qui au nom du "client" WWW va faire la recherche. Si un second client demande
la même page, le mandataire va reprendre la page, qu'il a déjà cherchée,
dans un stock qu'il s'est constitué, et cela dans un temps bien plus court que celui
nécessaire normalement.
- Pour une définition plus complète, la page du projet
Renater-Cache est un excellent point de départ
- SquidGuard (page locale) à voir absolument. C'est un outil qui permet d'établir des règles de filtrage
sur les accès à certaines catégories d'URLs.
- http://stargate.ac-nancy-metz.fr/linux/cache/ Une page très complète d'explications.
Evolution de notre configuration
- Changement de la version de squid sur cache.univ-tlse1.fr. Elle tourne depuis le 2 Mai 2003. C'est la 2.5 Stable3. Il a fallu
modifier de nombreux paramètres pour régler le problème de parenté. Nous avons été obligé de le faire, car l'ancienne version bloquait
quand le fichier access.log dépasse les 2 Go.
- Changement de la machine cache.univ-tlse1.fr. Elle tourne depuis le 4 Décembre 2001. Le trafic ayant été multiplié par
10 par rapport à juillet 1999, il devenait indispensable d'augmenter la puissance. C'est un bi-pentium III à 1Ghz avec
1.1 Go de RAM et 3*73 Go de disques en RAID 5 dont 20 Go sont réservés à Squid. L'OS est un Linux RedHat 7.2
en kernel 2.4.x (ce qui nous évite les problèmes de filedescriptor). Le filesystem utilisé est le reiserfs.
Squid est en version 2.3 stable 5. La version 2.4 ne nous convient pas, car elle gère mal la
parenté avec un cache non ICP.
- Changement de la machine cache.univ-tlse1.fr. Elle tourne depuis le 17 juillet 1999. C'est un pentium II
400 Mhz avec 256 Mo de RAM et 32 Go de disque dont 12 Go réservés à Squid. L'OS est un Linux RedHat 6.0
en kernel 2.2.x (ce qui nous évite les problèmes de filedescriptor).
- Depuis le 9 Avril 1999, cache.univ-tlse1.fr et cache2.univ-tlse1.fr tournent avec les versions 2.2 STABLE x de squid.
- Depuis le 15 Mars 1999, un second cache, plus particulièrement dédié au personnel
a été mis en place sur la machine cache2.univ-tlse1.fr dotée de 256 Mo de RAM et de
9 Go de disque, dont 2Go pour Squid, sur une Linux Redhat 5.2 . La version de Squid qui tourne est la 2.2 Devel 2.
- Depuis le 5 Octobre 1998 Squid tourne en version 2.0 avec 128 Mo de RAM
(dont 80 Mo pour squid) et 11 Go de disque dur (dont 3.5 Go pour Squid) sur un Linux Redhat 5.0 noyau 2.0.35.
Le 23 Octobre 1 Go a été ajouté. Le taux actuel de réussite (en nombre de
requêtes) est proche de 50%.
- Depuis le 28 janvier 1998 Squid tournait en version 1.1.x avec 128 Mo de RAM
(dont 80 Mo pour squid) et 3Go de disque dur (dont 1.7 Go pour Squid). Le taux
de réussite était approximativement de 35%.
- Jusque là la version 1.1.16 NOVM de Squid puis la 1.1.18 NOVM
tournait sur un pentium 166 sous Linux Redhat 4.2 avec 64 Mo de RAM (dont 20 Mo occupés par Squid)
et 3 Go de disque (dont 700 Mo pour Squid). On obtenait alors un taux de 30% de cache.
Linux a été patché afin de pouvoir bénéficier de 1024 filedescriptor par process.
Configuration
- Aller le chercher
- Les directives de compilations sont
- ./configure --enable-snmp --enable-err-language=French --enable-cache-digests --enable-icmp --enable-async-io=64 --enable-heap-replacement --enable-auth-modules="LDAP,PAM,NCSA"
Ceci nous permet
- de faire une surveillance snmp
- d'avoir des messages d'erreurs en français
- de dialoguer entre nos 2 caches plus efficacement qu'avec ICP
- de bénéficier d'un "calcul de distance" entre le serveur et le cache
- de faire des écritures asynchrones (plus performantes)
- de pouvoir modifier la politique d'élimination des anciens objets cachés
- de choisir une éventuelle politique d'identification
- make
- make install
- make install-pinger
- Faites attention de bien définir les droits d'accès (misc_access et http_access)
de nombreux caches sont ainsi ouverts et susceptibles d'être utilisés par des personnes
mal intentionnés pour se camoufler.
- Attention aussi aux fichiers de configuration qui datent un peu. La ligne
acl Safe_ports port 80 88 81 21 443 563 70 210 1025-65535
doit remplacer la dangereuse ligne
acl Dangerous_ports port
Certains plaisantins utilisaient des caches ouverts pour se connecter à
des ports sendmail (pour du SPAM) ou des ports telnet.
Utilisation
- Pour bénéficier du cache il suffit
- soit de définir comme serveur proxy cache.univ-tlse1.fr et comme port 3128
pour tous les services hormis socks
- soit de définir l'automatic proxy configuration avec pour valeur http://cri.univ-tlse1.fr/proxy.pac
Vous pouvez lire ici l'utilisation
Un exemple de proxy.pac est disponible Ici
- Pour joindre la personne responsable du cache :
cachemaster@univ-tlse1.fr
Surveillance
- Nous utilisons pour surveiller le cache l'outil mrtg en version 2.9.7 en mode rrdtool http://www.rrdtool.org
après avoir utilisé la 8.7.5 dont nous avions modifié le fichier
SNMP_util.pm afin d'en faciliter l'utilisation
- Il est important de rajouter les informations complémentaires dans la configuration de Squid
- acl manag_snmp src xxx.xxx.xxx.xxx/255.255.255.0
- acl snmppublic snmp_community public
- http_access allow manager manag_snmp
- snmp_access allow snmppublic manag_snmp
- snmp_access deny all
- Il faut aussi penser que le port est défini par la ligne
Hiérarchie
Les petits plus
- Redirecteurs :
Afin d'augmenter la rapidité des connexions
et limiter l'utilisation du WWW, nous avons mis en place un redirecteur
(dans squid.conf chercher la ligne redirector):
- Squirm qui
permettait de réécrire les URLs avant de les envoyer à Squid. Squirm est une version plus rapide et
plus puissante de redirector (voir plus bas). Il utilise un fichier squirm.patterns en perpétuelle évolution du fait
des nouveaux bandeaux de pubs et des nouveaux sites "non souhaitables".
- SquidGuard (page locale) successeur de squirm, à voir absolument.
- redirector de Ian Lea est écrit en Perl. C'était
le premier redirecteur que nous avons utilisé
- On peut lui préférer
JunkBuster qui en fait n'est pas un
redirecteur au sens Squid, mais plutôt un second proxy qui va s'emboiter sur Squid.
- Jesred successeur de squirm
- Prefetch : Plusieurs outils permettent d'optimiser la bande passante. Généralement ce sont des
outils de préfetching. Ils sont de 2 ordres : ce qui rapatrient la nuit et ceux qui "devancent" l'utilisateur en allant chercher directement les pages qui
"suivent" la page WWW qu'un utilisateur va regarder.
- Wcol qui devance l'utilisateur est totalement compatible
ICP (voir la documentation de Squid)
- Prefetch petit script
développé à pasteur
- Statistiques : Pour établir des statistiques nous avons utilisé plusieurs outils :
- Pwebstats qui est un outil généraliste
qui analyse les logs www, ftp et cache. Il a été abandonné (sauf pour l'analyse du
web).
- A l'heure actuelle nous travaillons avec Prostat qui
est beaucoup plus parlant.
- Nous utilisons aussi MRTG pour
voir son utilisation et vérifier la valeur LRU dans le temps. Il faut avouer
qu'il sert à toutes les sauces. Certains en profitent mieux que nous : Ici par exemple
Historique
L'Université des sciences sociales de Toulouse 1 s'est dotée
depuis Octobre 1997 d'un dispositif de cache WWW, suite d'une longue lignée
d'outils d'optimisation :
- CERN
HTTPD l'ancêtre, ses fonctions très basiques
m'ont permis de me "faire la main".
- Harvest dont il existe une
version professionnelle a
apporté un grand nombre d'innovations :
- les transferts interrompus par l'utilisateur peuvent
être poursuivis par le cache
- des connexions simultanées sur un même site
prennent le même circuit et ne prennent donc pas x fois
une partie de la bande passante. Cela permet aussi, si quelqu'un
a déjà commencé à charger 90% d'une page,
qu'une autre personne chargeant la même d'avoir 90% du
transfert déjà effectué
- hiérarchie de caches permettant d'optimiser au niveau national les effets.
- l'utilisation de la mémoire en plus du disque dur
permet d'accélérer les transferts.
- cache des résolutions DNS
- puis pour finir : Squid pour les raisons
suivantes :
- Harvest passant dans le domaine professionnel, la version freeware
n'était plus maintenue
- les URL dont le port :80 est précisé ne sont plus
stockées 2 fois (1 sans le port, l'autre avec)
- les URL sont stockées en minuscule (même avantages que
ci-dessus)
- implémentation du if-modified-since qui évite de
recharger une page si elle n'a pas changé
- relayage de la methode HTTP PUT
- La version 1.1.x permet en plus
- d'identifier l'appelant par RFC 931 (identd)
- les écritures asynchrones sur disque
- une accélération des opérations sur les filesystems.
- d'enlever les expires abusifs (ceux de microsoft...)
- des process de réécriture des URL permettent de modifier en
temps réel les transferts
- La version NOVM n'utilise pas la mémoire en tant que cache et
que zone d'index. Pour tourner sur des machines moins pourvues.
Ces trois versions sont présentes en France
- Chez nous
- et dans beaucoup d'universités françaises
- La version 2.0 (ex 1.2) améliore encore les choses
- Support des liaisons persistantes HTTP 1.1
- Support FTP intégré (et non plus par programme externe)
- Répertoire de swap indépendants
- Encore moins d'utilisation mémoire
- Gestion et surveillance SNMP
- Gestion des URNs
- Ecritures asynchrones sur les disques
- Routage basé sur les numéros AS
- Le partage entre caches de "Digests" c'est à dire les résumés de leur contenu
- Gestion plus intelligente des serveurs FTP (liens, possibilité de choisir entre la lecture directe et le téléchargement des fichiers)
- La version 2.3 introduit quelques notions supplémentaires
- Support du protocole WCCP 1.0 (dont cette URL chez CISCO(http://www.cisco.com/warp/public/732/Tech/switching/wccp/) qui permet d'intercepter au niveau d'un routeur les transactions HTTP
- Support d'autres types d'algorithme de remplacement que le LRU tel le LFU/GDSF qui semble plus efficace
quand il y a un très grand nombre de requêtes. (voir pour celà
ce benchmark
- Gestion d'autres types de disques
- Intégration des processus DNS qui ne sont plus externes
- La version 2.4
- Ajout de nouveaux types de stockage (diskd)
- Correction du bug de 2 GigaOctets pour le fichier access.log
- La version 2.5
- Dernière version stable, et seule version maintenue
