Man kann Squid zusammen mit einer Firewall verwenden, um interne Netzwerke durch den Einsatz eines Proxy-Cache nach außen zu schützen. Die Firewall verweigert allen Clients mit Ausnahme von Squid den Verbindungsaufbau zu externen Diensten. Alle WWW-Verbindungen müssen dann durch den Proxy aufgebaut werden.
Im Falle einer Firewall-Konfiguration mit einer DMZ würde man dort den Proxy einsetzen. Bei einer solchen Konfiguration ist es wichtig, dass alle Rechner in der DMZ ihre Protokolldateien an Rechner innerhalb des gesicherten Netzwerks senden. Eine Möglichkeit der Einrichtung eines so genannten „transparenten“ Proxys wird in Abschnitt 33.6, „Konfiguration eines Transparenten Proxy“ behandelt.
Man kann mehrere Proxys so konfigurieren, dass Objekte zwischen ihnen ausgetauscht werden können; so lässt sich die Systemlast reduzieren und die Wahrscheinlichkeit steigern, ein bereits im lokalen Netzwerk vorhandenes Objekt zu finden. Möglich sind auch Cache-Hierarchien, so dass ein Cache in der Lage ist, Objektanfragen an Caches der gleichen Hierarchie weiterzuleiten oder einen übergeordneten Cache zu veranlassen, die Objekte von einem anderen Cache im lokalen Netzwerk oder direkt aus der Quelle herunterzuladen.
Die Wahl der richtigen Topologie für die Cache-Hierarchie ist sehr wichtig, da Netzwerkverkehr insgesamt nicht erhöht werden soll. In einem großen Netzwerk bietet es sich an, für jedes Subnetz einen Proxy-Server zu konfigurieren und diesen dann mit einem übergeordneten Proxy zu verbinden, der wiederum mit dem Proxy-Cache vom ISP verbunden wird.
Die gesamte Kommunikation wird vom ICP (engl. Internet Cache Protocol) gesteuert, das auf dem UDP-Protokoll aufgesetzt ist. Der Datenaustausch zwischen Caches geschieht mittels HTTP (engl. Hyper Text Transmission Protocol) basierend auf TCP.
Um den besten Server für die gewünschten Objekte zu finden, schickt ein Cache an alle Proxys der gleichen Hierarchie eine ICP-Anfrage. Die Proxys werden mittels ICP-Antworten mit dem Code „HIT“ auf die Anfragen reagieren, falls das Objekt gefunden wurde oder, falls nicht, mit dem Code „MISS“. Im Falle mehrerer HIT-Antworten wird der Proxy-Server einen Server für das Herunterladen bestimmen. Diese Entscheidung wird unter anderem dadurch bestimmt, welcher Cache die schnellste Antwort sendet oder welcher näher ist. Bei einer nicht zufrieden stellenden Antwort wird die Anfrage an den übergeordneten Cache geschickt.
![]() | Tipp |
|---|---|
Zur Vermeidung einer mehrfachen Speicherung von Objekten in verschiedenen Caches des Netzwerks werden ebenfalls ICP-Protokolle verwendet, wie zum Beispiel CARP (engl. Cache Array Routing Protocol) oder HTCP (engl. Hyper-Text Cache Protocol). Je mehr Objekte sich im Netzwerk befinden, desto leichter wird es, das Gesuchte zu finden. | |
Nicht alle im Netzwerk verfügbaren Objekte sind statisch. Es existieren viele dynamisch generierte CGI-Seiten, Zugriffszähler oder verschlüsselte SSL-Dokumente für eine höhere Sicherheit. Aus diesem Grund werden solche Objekte nicht im Cache gehalten: Bei jedem neuen Zugriff hat sich das Objekt bereits wieder verändert.
Für alle anderen im Cache befindlichen Objekte stellt sich jedoch die
Frage, wie lange sie dort bleiben sollen. Für diese Entscheidung werden
alle Objekte im Cache verschiedenen Stadien zugeordnet.
Durch Header wie Last modified
(„zuletzt geändert“) oder Expires
(„läuft ab“) und dem entsprechenden Datum informieren sich
Web- und Proxy-Server über den Status eines Objekts. Es werden auch andere
Header verwendet, die zum Beispiel anzeigen, dass ein Objekt nicht
zwischengespeichert werden muss.
Objekte im Cache werden normalerweise aufgrund fehlenden Speichers ersetzt, und zwar durch Algorithmen wie LRU (engl. Last Recently Used), die zum Ersetzen von Cache-Objekten entwickelt wurden. Das Prinzip besteht im Wesentlichen darin, zuerst die am seltensten gewünschten Objekte zu ersetzen.