Konfiguration des Proxyservers Squid

Seite: 3/12
(8696 Worte insgesamt im Text)
(31901 mal aufgerufen)  Druckerfreundliche Ansicht

OPTIONS WHICH AFFECT THE NEIGHBOR SELECTION ALGORITHM

Hier wird es schon etwas interessanter. Wenn Sie z.B. einen Provider haben, der eigene Proxy-Server für Sie bereitstellt, dann können Sie durch die zusätzliche Nutzung dieser externen Server einen enormen Geschwindigkeitsgewinn erreichen:

cache_peer

Mit der Anweisung:

cache_peer www-proxy.t-online.de parent 80 0 no-query no-digest default no-netdb-exchange

verwenden wir z.B. den Proxy-Server von T-Online (Achtung: dieser ist nur über T-Online-Accounts erreichbar).

  • Dieser Server soll als "Eltern"-Server (parent) immer befragt werden. Da T-Online keine "ICP-Queries" gestattet, muss als zweite Zahl eine 0 stehen. (Eine 7 wäre auch möglich - dann wird an den Proxy ein "Ping" gesendet. Dies entspricht aber nicht mehr dem aktuellen Standard. Wenn die Abfrage zum anderen Proxy aber nicht funktioniert [wie im obigen Beispiel], lässt er sich evtl. so austricksen.) Zusätzlich wird dies auch noch mit "no-query" explizit angegeben: stelle an diesen Host keine ICP-Querys.
  • "default" steht für einen Cache, der als "letzte Reserve" benutzt werden kann.
  • "no-netdb-exchange" schliesslich bedeutet, dass die Datenbanken dieser beiden Server nicht untereinander ausgetauscht werden sollen. (Dies lässt T-Online nicht zu.)
  • "no-digest" wir fordern auch keinen Auszug aus dem Cache des anderen Proxys an.

Alle Optionen, die hier möglich sind:
OptionErklärung
proxy-onlyDaten von diesem Cache sollen nicht zusätzlich noch einmal lokal gespeichert werden (etwa, weil dieser Cache schnell genug erreichbar ist).
weight=nWerden mehrere Caches angegeben, kann hiermit eine Gewichtung zwischen den unterschiedlichen Caches herbeigeführt werden. Die Zahl muss eine Ganzzahl sein. Höhere Werte führen zu einer höhren Gewichtung. Also wird ein Cache mit der Gewichtung 2 öfter befragt als einer mit der Standard-Gewichtung 1.
ttl=nNur sinnvoll, wenn die anderen Caches sich in einer Multicast-Gruppe befinden. Hiermit kann die TTL (Lebenszeit) von ICP-Anfragen an diese Hosts festgelegt werden. Damit lässt sich in Zusammenhang mit den anderen Werten hier eine schnelle Kaskadierung erreichen, da bei Hosts, die nicht schnell genug antworten einfach auf den nächsten Cache ausgewichen wird.
no-queryHiermit sollen keine ICP-Anfragen an diesen Host (Cache) gesendet werden. Nötig bei einigen Caches, die z.B. ICP-Anfragen gar nicht annehmen.
defaultDieser Cache soll die letzte Möglichkeit für Squid sein, eine Anfrage nicht direkt an die angeforderte Adresse zu senden. Wenn also andere Caches nicht erreicht werden können, wird dieser Cache befragt, bevor eine Anfrage an die vom Browser angeforderte Adresse gesendet wird. 'default' setzt auch ein 'no-query' für diesen Cache voraus.
round-robinHier werden mehrere Caches zusammengefasst und eine Anfrage an all die hier angegebenen Caches gleichzeitig versendet. ICP-Anfragen werden hierfür nicht benötigt.
multicast-responderDieser Cache ist ein Mitglied einer Multicast-Gruppe. Es werden zwar keine ICP-Anfragen an diesen Host gesendet - ICP-Anfragen von diesem Cache werden aber akzeptiert.
closest-onlyHier wird der Nachbar-Cache genutzt, welcher die kürzeste RTT (Round Trip Time - Antwortzeit) zum Originalserver hat.
no-digestVon diesem Cache werden keine Übersichten über dessen Cache angefordert. Damit kann Squid dann aber diesen Host nicht geziehlt aufgrund der vorhandenen Informationen ansprechen.
no-netdb-exchangeKeine Anfragen an die ICMP-RTT Datenbank des Nachbarcaches. In dieser Datenbank werden normalerweise Informationen über die auf anderen Servern vorgehaltenen Seiten gespeichert. Damit kann Squid nicht den Server anfragen, welcher die angeforderte Seite schon in seinem Cache hat.
no-delayNormalerweise werden Anfragen von anderen Caches so wie Anfragen von normalen Clients behandelt. Wenn dann ein Delay-Pool eingerichtet ist, der z.B. den Download bestimmter Seiten begrenzt, wird auch der anfragende Cache nur mit der entsprechenden Geschwindigkeit bedient. Mit dieser Option werden Anfragen dieses Caches nicht durch Delay-Pools beeinflusst: der Cache bekommt die volle Geschwindigkeit.
login=user:passwordWenn der andere Cache eine Authentifizierung verlangt, dann gibt man hier den Nutzernamen und das Passwort ein, welches an den Nachbar-Cache für die Authentifizierung gesendet werden soll.
login=PASSWenn die lokalen Nutzer sich am Nachbar-Cache anmelden sollen, dann führt diese Option zum Ziel: damit werden die Authentifizierungsdaten der Nutzer an den anderen Cache weitergeleitet. Dies funktioniert aber nur mit der Basic-Authentifizierung am lokalen Proxy. Um die Nutzer zu authentifizieren muss der Nachbar-Cache über diese Nutzer-Datenbank verfügen. Die Nutzerdaten (Name und Passwort) werden direkt an den anderen Cache weitergeleitet - man sollte diese Option also mit Vorsicht einsetzen.
login=*:passwordUm die Sache ein wenig sicherer zu machen und dem anderen Cache zwar nicht das Passwort aber den Nutzernamen zu übermitteln, können Sie auch ein 'default-Passwort' an den Nachbar-Cache übergeben. Sie können hinter dem '*' noch ein paar Informationen übermitteln, die dem Nachbar-Cache z.B. die Information darüber geben, welcher Proxy oder aus welcher Domain die Anfrage kam. Ansonsten gilt hier dasselbe wie für die "login=user:password" Nutzung.
connect-timeout=nnNach dieser Zeit wird der Nachbar-Cache als "Down" angesehen und die Anfrage an einen anderen Cache gestellt oder direkt geholt.
digest-URL=urlWenn Cache-Digests zugelassen sind, wird der Cach-Digest von diesem Nachbar-Proxy über die hier angegebene URL anstelle des Standardverfahrens angefordert.
allow-missNormalerweise schaut Squid zuerst in der Cache-Digest-Datenbank des Nachbar-Caches nach, ob dieser eine angeforderte Seite schon im Cache hat und stellt nur dann eine Anfrage an diesen Cache. Mit dieser Option wird dieses Verhalten abgeschaltet und Squid fragt den Nachbar-Cache auch dann, wenn dieser die Seite nicht in seinem Cache hat.
max-connDiese Angabe begrenzt die gleichzeitigen Verbindungen zu diesem Nachbar-Proxy.
htcpSquid sendet normalerweise nur ICP-Anfragen an Nachbar-Caches. Mit dieser Option wird Squid angewiesen statt dessen HTCP-Anfragen zu senden. Dazu sollte auch der icp_port auf 4827 gesetzt werden.
carp-load-factor=fSquid unterstützt Teile von CARP (Cache Array Routing Protocol) einem Protokoll, welches eine Erweiterung von ICP (Internet Cache Protocol) darstellt. Damit lassen sich ganze Cache-Farmen bilden und Client können mehrere Caches und deren Routing-Informationen in einem Array inkl. der Information der in ihrem Cache gespeicherten Daten sammeln. Wenn in einem Netzwerk mehr als 20MB an Traffic anfällt, dann sollte CARP anstelle von ICP (und entsprechend viele Caches) eingesetzt werden. Mit dieser Option teilt man Squid dann mit, dass der angegebene Cache Mitglied in einem solchen CARP-Verband ist.
Eine weitere Möglichkeit stellt die zusätzliche Verwendung des kommerziellen Programms "Webwasher" dar, welches an Schulen und Bildungseinrichtungen kostenlos eingesetzt werden darf. Wählen Sie bitte die Linux-Version und befolgen Sie anschliessend die ausführliche Anleitung zur Installation.

Hier müssen allerdings einige zusätzliche Regeln definiert werden, welche Squid anweisen, nur für Webseiten und nicht für FTP-Dateien bei Webwasher anzufragen. Die zugehörende Konfiguration lautet insgesamt (kann so in die squid.conf eingetragen werden):

cache_peer localhost parent 9090 7 proxy-only no-query default no-digest no-delay
acl ftp url_regex -i ftp://*
always_direct allow ftp

Wenn Sie den Webwasher laut Anleitung installiert haben, dann verhindert er je nach Einstellung zukünftig u.a Pop-Ups und Werbeeinblendungen.

cache_host_domain

Mit
cache_host_domain www-proxy.t-online.de .de

beschränken wir die Domains, nach denen der Proxy-Server von T-Online befragt wird, auf Domains aus Deutschland.

cache_stoplist

Die Anweisung
cache_stoplist cgi-bin ?

sagt man Squid, dass er URL's, die ein "cgi-bin" oder ein "?" enthalten direkt holen und nicht über andere Caches holen soll. Da es sich hierbei meist um Suchanfragen (z.B. in google) und damit um dynamisch generierte Webseiten handelt ist das auch in Ordnung.

no_cache

Um zu verhindern, dass Squid bestimmte Anfragen oder Webseiten überhaupt in seinem Cache zwischenspeichert, kann man hier eine oder mehrere ACLs setzen und mit der Direktive:

no_cache deny ACL-NAME
das Zwischenspeichern abschalten. Ein Beispiel, welches verhindert, dass Squid
a) dynamische Seiten und
b) die eigene Homepage
zwischenspeichert wollen wir hier einmal angeben:
acl QUERY urlpath_regex cgi-bin \?
acl HOMEPAGE dstdomain www.linux-schulserver.de
no_cache deny QUERY
no_cache deny HOMEPAGE

icp_query_timeout

Normalerweise setzt Squid automatisch einen Timeout von 2000 Milisekunden für ICP-Anfragen an einen Nachbar-Cache. Wenn Sie dieses Verhalten abschalten wollen, dann setzen Sie hier eine '0'.

icp_query_timeout 0

dead_peer_timeout

Hier geben Sie an, nach welcher Zeitspanne Squid einen Nachbar-Cache als "Down" ansehen und künftig keine Anfragen mehr an ihn stellen soll.

dead_peer_timeout 10 seconds

Dies ist der default-Wert. Squid sendet weiterhin Anfragen an diesen Host - wartet aber nicht mehr auf Antworten. Wenn dennoch eine Antwort kommt, nimmt Squid diesen Host wieder in die Anfrageliste auf und der Timeout wird wieder gesetzt.




Kommentare

Schultzi
13.09.06, 07:38
Super

Klasse

Andreas
24.11.06, 08:11
Spitzen Info´s

Hallo,

da ich gerade dabei bin, einen Squid zu installieren, haben mir die Infos sehr geholfen. Speziell die Delay Pools waren für mich ein wenig schwierig , aber mit der Erklärung hab ich es jetzt begriffen. :-) Auch die Tuning Tips sind sehr wertvoll .... Respekt !!!

Weiter so ...

Grüße

Andreas

Einen Kommentar hinzufügen



 Suchen:


 Umfrage

(Nur für angemeldete Benutzer)

Was wird hier am meisten vermisst?

[ Ergebnis | Umfragen ]

Stimmen: 621
Kommentare: 0

 Zitate

Lemma: Alle vernünftigen Betriebssysteme haben ein "X" im Namen.
Korollar: Aber kein "P" nach dem "X".

-- anonymous