Begriffsbestimmung

Ein reverse Proxy (auch Http-Accelerator genannt) ist ein Proxy, der vor einen Webserver geschaltet wird und an dessen Stelle auf das Port http hört. Damit verfolgt man im allgemeinen 3 mögliche Ziele:

• Performancesteigerung. Der Proxy kann Webinhalte cachen und ggf. direkt liefern. Da er im allgemeinen schneller als ein Webserver ist, können damit Durchsatzsteigerungen erreicht werden.
• Sicherheit. Der Webserver kann im internen Netz hängen und ist damit nach außen unsichtbar.Mit Acl's können Url's geprüft und ggf. bereits vom Proxy zurückgewiesen werden.
• Lastverteilung. Squid kann so konfiguriert werden, daß er seine Anfragen auf auf mehrere Webserver verteilt.

Es gibt ein paar Dinge, die beim Einsatz eines reverse Proxy zu beachten sind:

• Eine Performancesteigerung ist natürlich nur dann zu erzielen, wenn der Webserver cachebare Inhalte liefert. Ein reiner Wiki-Server wird dies z.B. nicht tun.
• Anfragen, die vom Proxy direkt beantwortet werden, erscheinen natürlich nicht in den Logfiles des Webservers sondern nur nur im Logfile des Proxies. Dies muß bei statistischen Auswertungen der Zugriffe berücksichtigt werden.

Squid als reverse Proxy

Squid eignet sich als reverse Proxy. Die Konfiguration ist relativ einfach:

• Der Squid bekommt die Ip, die vorher der Webserver hatte.
• http_port: 80
• emulate_httpd_log on. Damit wird das Format auf Apache umgestellt - nützlich für Auswertungen. Webalizer kann dieses Format, Calamaris kann es nicht.
• Acl's nach Bedarf.
• Accelerator Options:
  • httpd_accel_single_host on. (Bei einem Webserver)
  • httpd_accel_uses_host_header on.Muß on sein, sonst gehen virtual hosts nicht! (Bei einem Webserver)
  • httpd_accel_port xx. Kann ein willkürliches Port sein, auf welches der Webserver hören muß. Muß bei acl safe_ports eingetragen werden. Man kann auch Port 80 verwenden, wenn man sicher stellte, daß es zu keinen Konfusionen mit http_port kommt. Nicht mit http_port verwechseln!
  • httpd_accel_host localhost (ggf. die äußere Ip verwenden)
  • httpd_host ip-webserver

Der Webserver muß ebenfalls entsprechend konfiguriert sein. Überall wo früher die äußere Ip stand, muß jetzt die innere Ip und ggf. das httpd_accel_port stehen (wenn man Port 80 verwendet, ist dies Default).

Erfahrungsbericht: http://pasadena.wr.usgs.gov/stans/slashdot.html

OffeneFrage Weiß jemand ein Konfigurationsbeispiel für Lastverteilung?

Hinweise / Warnungen

• Natürlich können beide Prozesse auch auf der gleichen Maschine laufe; der Webserver ist dann localhost:80, der Proxy ist äußere Ip: 80.
• Nicht vergessen, den Squid in den Runleveln auch zu starten!
• Bei der Fehlersuche muß der Squid mit einbezogen werden.
• Webalizer zeigt die Statistik für alle (virtuellen) Server hinter dem Proxy und auch gleich die Cache-Hits an.

Reverse Proxy und https

• Eigentlich sollte Squid https direkt an den dahinterstehenden Server weiterleiten. Uneigentlich tut er dies aber nicht. Abhilfe: Mit 'redir' https direkt weiterleiten.

Tricks

• Squid kennt den Parameter 'refresh_pattern'. Mit Optionen wie 'override-expire' lassen sich für bestimmte Arten von Webseiten Cache-Attribute erzwingen. Das ist zwar gegen den Html-Standard, kann aber deutlich helfen, die Hitrates für den Cache zu erhöhen. Wenn man das tut, sollte man allerdings sorgfältig auf etwaige Seiteneffekte achten.

siehe auch ProxyServer (beide Seiten lieber zusammenfassen?), AnonProxy