2009-03-23 7 views
3

Suchen Sie nach Best Practice hier. Wir beschäftigen uns mit der SSL-Verbindung auf unserer Load-Balancer-Ebene und daher ist die gesamte Verbindung von unserem Load-Balancer zu unseren Webservern http. Damit haben wir keine Möglichkeit zu sagen, welche Art von Verbindung der Client zu unserem Webserver herstellt, da die gesamte Verbindung über http erfolgt. Wir haben derzeit 2 Lösungen, eine davon ist, dass der Load Balancer eine Portnummer in die URL-Zeichenkette einfügt, so dass wir die Art der Anfrage bestimmen können (z. B. 80 für http und 443 für https). Die andere Lösung ist, dass der Load Balancer bei der HTTPS-Anforderung einen speziellen Header anfügt, damit der Webserver den Verbindungstyp kennt.Ermitteln Sie die SSL-Verbindung hinter einem Load Balancer

Sehen Sie Nachteile in beiden Lösungen? Gibt es Best Practices in Bezug auf SSL, das auf der Load-Balancer-Ebene statt auf der Webserver-Ebene angewendet wird?

Antwort

1

Ich würde den Header bevorzugen, denke ich. Durch Hinzufügen von etwas in der URL wird die Möglichkeit geschaffen, wie auch immer Sie mit einem Abfragezeichenfolgenparameter kollidieren, den eine App verwenden möchte. Ein benutzerdefinierter Header wäre einfacher.

Eine dritte Option könnte sein, ssl-Verbindungen zu einem anderen Port umleiten, sagen 8080, so am Back-End wissen Sie, dass Port 80-Verbindungen waren http zu beginnen, und Port 8080-Verbindungen waren 443 zu beginnen, sogar obwohl sie beide an diesem Punkt http sind.

1

Ich empfehle die Verwendung der Kopfzeile. Ein verwandtes Konzept ist das Bestimmen der IP-Adresse des Clients (für Protokollierungszwecke), da alle Anforderungen an Ihren Webserver vom Load Balancer stammen. Üblicherweise wird hier der x-forwarded-for Header verwendet.