2 votes

squid reply_body_max_size ne fonctionne pas

J'ai été chargé de limiter la consommation de bande passante. J'ai configuré Squid en tant que proxy transparent et je bloque différents types de contenu, comme la vidéo, le x-flv.... Les acl de type de contenu semblent fonctionner correctement. J'ai également configuré le reply_body_max_size à 10 MB mais les téléchargements de gros fichiers continuent. Celui-ci est passé hier soir.

1331243510.997 621794 192.168.0.100 TCP_MISS/200 37603388 GET http://cache.pack.google.com/edgedl/chrome/mac/GoogleChrome-17.0.963.78.dmg - DIRECT/173.194.12.207 application/x-apple-diskimage

voici ma directive : (squid a été redémarré après le changement)

reply_body_max_size 10 MB

En lisant la documentation de Squid http://www.squid-cache.org/Doc/config/reply_body_max_size/ Il semble qu'il y ait un problème avec un autre serveur proxy Squid en aval. Je sais que le FAI qu'ils utilisent (Tachyon Systems) a un serveur proxy Squid intégré à leur modem.

Serait-ce la raison pour laquelle le paramètre reply_body_max_size ne fonctionne pas dans mon environnement ?

0 votes

Où se trouve votre proxy par rapport au client, au modem et à l'Internet ? Je pense que le modem est en fait en amont et ne serait pas affecté par le problème mentionné dans la documentation.

0 votes

Il est en amont. J'ai implémenté ce que proy a suggéré ci-dessous mais je n'ai pas encore testé. Plus à venir...

1voto

djluko Points 83

Comme le Documentation sur Squid dit, la directive de configuration reply_body_max_size fait en sorte que Squid cesse la transmission lorsque le corps de la réponse HTTP dépasse la taille spécifiée. Ceci est vérifié par Squid de deux façons : en utilisant l'en-tête HTTP Content-Length :, s'il est présent - dans ce cas, la réponse ne sera pas autorisée et un TCP_DENIED_REPLY sera écrit dans le journal. Ou, si l'en-tête HTTP Content-Length : n'est pas présent, alors la réponse sera autorisée, mais la connexion sera fermée lorsque reply_body_max_size sera atteint.

Dans le second scénario, il pourrait y avoir un effet d'entraînement potentiellement important pour tout cache en aval de vous. Si la transmission HTTP a été lancée sans en-tête HTTP Content-length : et que votre copie de Squid a ensuite interrompu la connexion lorsque la taille limite de la réponse a été atteinte, le cache en aval ne saura pas que la connexion a été interrompue avant l'envoi du corps de réponse complet. Cela pourrait entraîner le stockage d'une copie incomplète de l'objet dans le cache en aval. Cependant, d'après votre description, je ne pense pas que ce soit le cas ici, puisque vous parlez d'un proxy en amont géré par votre FAI.

À ce propos, je ne vois pas comment un proxy en amont pourrait affecter votre capacité à imposer une limite à la taille du corps de la réponse.

Une remarque sur la syntaxe de votre configuration. Vous avez spécifié :

reply_body_max_size 10 MB

Alors que je pense que ça devrait l'être :

reply_body_max_size 10 MB all

Notez le nom ACL "all" à la fin. La documentation de Squid place la liste des ACL entre crochets, ce qui tend à indiquer que ce paramètre est optionnel, et dans mes tests, j'ai trouvé que c'était le cas. Cependant, il existe une variation de cette syntaxe à certains endroits sur le net (et dans ce fil de discussion ci-dessus), où parfois le mot "allow" ou "deny" est également placé dans la ligne de configuration. Selon la documentation de Squid, et mes tests, ceci est incorrect. La syntaxe ci-dessus a été testée correctement pour moi.

Nb. tests effectués avec Squid 3.1.23 et Squid 3.5.0.2.

0voto

proy Points 1179

Vous devriez essayer d'appliquer cela à votre acl source. Par exemple, quelque chose comme ceci

acl localnet src 192.168.0.0/16
reply_body_max_size 52428800 deny localnet
http_access allow localnet

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X