Hallo!
Worum denn dann? Es ging daraum, bestimmte Dinge zu beschleunigen mit Hilfe eines Reverse-Proxy (Caching). Wenn ich das nicht will, wozu sollte ich dann einen Reverse-Proxy einsetzen?
Z.B. aus den Gründen die ich hier beschrieben habe: [pref:t=77938&m=450398]
*nochmal_durchles*
Hm. Vielleicht stehe ich ja etwas auf dem Schlauch aber in dem Posting geht es im Zusammenhang mit Reverse-Proxy um Caching.
Wo ist denn der Widerspruch?
Die Idee dort hat weniger mit Caching zu tun, mehr mit Optimierung der httpd-Prozesse für den jeweiligen Einsatz-Zweck. Statische Dokumente brauchen nur serh wenig und so laufen die über einen Webserver der nur wenig kann - dafür vergleichsweise schlanke Prozesse verwendet. Die dynamischen Dokumente brauchen meist mehr Module, und benötigen merh Funktionalität, wodurch die Prozesse um ein vielfaches größer werden können. Daher die Idee den ersten Webserver gleichzeitig als Reverse-Proxy einzusetzen, das heißt, er liefert selber statische Inhalte aus, und leitet Requests an dynamische Dokumente per ProxyPass an den 2. Webserver weiter, denn dann alle benötigten Module hat und dessen Prozesse erheblich größer sind als die des ersten Webservers/Reverse Proxys. Der 1. Webserver(Proxy) hört Port 80/443 an der Netzwerkkarte ab, der 2. Webserver(PHP...) hört Port 8080 auf localhost ab. Der Proxy reicht also Requests an localhost:8080 weiter.
Dadurch kann man die Ressourcen des Webservers besser ausnutzen.
Wenn Du einen Reverse-Proxy einsetzt - was verwendest Du dann? Apache(mod_proxy)? Oder Squid? Oder nochwas anderses?
Hast Du Erfahrung mit eine, Reverse-proxy in Zusammenhang mit SSL? Bei Apache kein Problem - aber bei Squid? Funktioniert das? Man könnte sich ja auch ein Szenario überlegen wie:
Squid an Netzwerkkarte Port 443, leitet Request weiter an:
-> Apache #1 (für statisches) an localhost:8080
oder
-> Apache #2 (für dynamisches) an localhost:8081
Was hälst Du davon? Wobei man in diesem Fall eigentlich keine 2 Webserver-Instanzen braucht, denn wenn sich die statischen Inhalte kaum ändern wird der Squid die meisten Inhalte ja selber cachen. Nur - soweit ich weiß darf man bei SSL gar nicht cachen, oder sowas? Aber da es ja auf dem eigentlichen Server passiert - warum nicht? Kann man das wohl so machen? Mein Problem ist hier, ich finde einfach nicht genügend Informationen wie man einen Squid für dieses Szenario konfiguriert. Zum einen bezieht sich fast die gesamte Doku auf "normale" Proxies, und das bisschen was sich auf reverse-proxies bezieht verliert kein Wort zumn Thema SSL.
Viele Grüße
Andreas