Proxy und Webcache - Datenbremse oder Turbolader?

Ein Proxy ist allgemein eine Software, die ein Netzwerk von einem anderen Netzwerk abtrennt, indem sie Anfragen aus dem internen Netzwerk stellvertretend nach außen erledigt.

Viele Internet-Anbieter verwenden Proxy-Server, auf denen sie alle angefragten Webseiten und Grafiken speichern, so daß die nächste Abfrage einer Seite nicht mehr neu aus dem Internet geholt werden muß, sondern von der Festplatte des Proxy-Server. Dieses Verfahren nennt sich "Webcache" und geht für den Benutzer wesentlich schneller als die Seite selbst aus dem Internet zu holen.

also, was und wie denn nun? einer sagt, proxies müssen eingeschaltet sein, der andere sagt, proxies um gottes willen aus.

Wenn die Client-Software (Webbrowser, FTP-Client, etc) mit der Nutzung des Proxy zurechtkommt, sollte man dies auch auf jeden Fall nutzen. Die Webbrowser kommen inzwischen so ziemlich immer mit den Webcaches zurecht, FTP-Clients kommen nur mit FTP-Proxies zurecht, nicht mit Webcaches.

Allgemein reduzieren Webcaches die verbratene Netzlast und sorgen so dafür, daß man mit geringerer Bandbreite und Internet-Anbindung länger mehr Leute bedienen kann als man dies sonst tun könnte. Dies betrifft die Webserver wie auch die Browser im Netz, es geht einfach alle an.

Wer einen Webcache nutzt, reduziert Netzlast und sorgt dafür, daß man selbst und andere weniger warten müssen. Warum sollten sich täglich 3 Millionen Leute die blöden Navigationsleisten von microsoft.com neu holen, wenn die Dinger doch auch schon "um die Ecke" im Cache abgelegt sind?

Wer jetzt meint, die Browsercaches könnten das auch schon erledigen, kennt nicht den Unterschied zwischen Browsercache und Webcache: Webcaches sind aufwendig entwickelte Datenbanken, die von hunderten von Leuten gleichzeitig genutzt werden können, Browsercaches oft nur sehr schmalbrüstig entwickelte "Abspeicherer". Moderne Webcaches wie z.B. Squid laufen oft nicht nur an jeweils einer Stelle, sondern können auch noch untereinander z.B. innerhalb eines Providernetzwerkes verbunden werden: das spart noch einmal Zeit, Traffic und somit auch Geld.

In der Firma läuft unser Internetzugang auch über einen gemeinsamen Webcache. Wenn der Chef gerade bei sich eine tolle Seite gefunden hat, kann er in die Produktion gehen, die URL eintippen und die Seite ist dort dann in 2 Sekunden fertig da - weil die Daten dafür ja bereits im Netzwerk liegen. Ein Browsercache könnte dies nicht leisten, ebenso wäre die ISDN-Leitung mit der Aufgabe überfordert.

Da Provider unter sich auch nur nach "Traffic" (Menge transferierter Daten in einem bestimmten Zeitraum) abrechnen, lohnt es sich auch für Provider direkt, Webcaches anzubieten. Mit einem Webcache von 500 Mb Plattenplatz kann man aller Erfahrung nach etwa 30% der angeforderten Daten aus dem Cache heraus holen. Vom Arbeitsaufwand her ist ein Squid auch mit einer Stunde Arbeitsaufwand komplett eingerichtet.

Alter Käse?

Bei den üblichen Webcaches muß man auch eine Menge im Quelltext verkonfigurieren, damit die Daten nicht aktualisiert werden. In der normalen Konfiguration kann man derartige Dinge nicht einstellen, man muß da also doch schon richtig Energie reinstecken.

Die Webcaches schauen nach einer bestimmten Verweilzeit der Daten im Cache beim nächsten Zugriff nach, ob sich die Daten auf dem Server nicht inzwischen geändert haben, ebenso wird alle x Zugriffe eine Seite neu geholt. Als Serveradministrator und Webautor kann man auch für seine Dokumente vorgeben, daß diese immer oder ab einem bestimmten Zeitpunkt neu geholt werden sollen.
Das Problem "ein Webcache liefert dir immer alte Daten" ist normalerweise einfach falsch, es wird sehr viel Aufwand getrieben, aktuelle Daten zu halten.

Die Onlinedienste germany.net und metronet haben vor einiger Zeit Probleme mit ihren Webcaches gehabt bzw. haben diese teilweise noch noch - offensichtliche Sachen wie "die täglich aktuellen Seiten der Tagesschau" wurden durch die Webcaches z.B. mal zwei Wochen lang NIE aktualisiert, was den Webcaches allgemein einen schlechteren Ruf eingebracht hat.