Product
Wöchentliches Produkt-Update: Tipps zur Konfiguration der SSL-Terminierung auf Cloud Load Balancern
Wir halten Sie gerne jede Woche darüber auf dem Laufenden, was bei Mailgun passiert. Manchmal befinden sich die Projekte, an denen wir arbeiten, jedoch alle in der Forschungs- und Entwicklungsphase, sodass wir nicht viel berichten können. Das war diese Woche der Fall, daher gibt es keinen großen Bericht. Das bedeutet jedoch nicht, dass wir nicht fleißig waren. Da die Kundschaft von Mailgun genau wie wir aus dem Entwicklungsbereich kommt, möchten wir unsere Erkenntnisse aus einer alltäglichen Wartungsaufgabe teilen: dem Hinzufügen einer SSL-Terminierung zu unseren Cloud Load Balancern, die den Datenverkehr von Control Panel und Website abwickeln. Wir haben einige interessante Dinge herausgefunden, insbesondere im Hinblick auf die Leistung, die in Ihrer eigenen Anwendung von Nutzen sein könnten. Falls das nicht Ihr Fall ist, keine Sorge – schauen Sie nächste Woche wieder vorbei, um mehr über neue Funktionen und Verbesserungen zu erfahren.
Hinzufügen von SSL-Terminierung zu Rackspace Cloud Load Balancern
Eine häufige Anforderung an SaaS-Anbieter (wie Mailgun und viele aus unserer Kundschaft) ist die Verfolgung von Sitzungen nach IP-Adresse. Wenn Datenverkehr durch einen Load Balancer geleitet wird, gibt es verschiedene Möglichkeiten, um sicherzustellen, dass die ursprüngliche IP-Adresse erhalten bleibt. In der Vergangenheit haben wir einen F5 Load Balancer verwendet, der eine $remoteaddr-Variable übergibt, die wir in unserer nginx-Konfiguration genutzt haben. Diese Variable war die aus Socket-Optionen entnommene Adresse des Clients. Als wir kürzlich zu Rackspace Cloud Load Balancern gewechselt sind, um den Datenverkehr für unsere Website und unser Control Panel abzuwickeln, haben wir festgestellt, dass Cloud Load Balancer die IP des Load Balancers für $remoteaddr bereitstellen, anstelle der IP-Adresse des Clients. Wir brauchten also eine andere Möglichkeit, diese Informationen zu erhalten.
Cloud Load Balancer können eine X-Forwarded-For-Kopfzeile mit dem IP-Wert des Clients hinzufügen. Diese Option funktioniert jedoch nicht für SSL, das wir für unser Control Panel verwenden. Warum sollte das nicht funktionieren? Einfach. Um der über SSL gesendeten Datei eine Kopfzeile hinzuzufügen, muss der Load Balancer die Datei zunächst entschlüsseln. Standardmäßig ist ein Load Balancer dafür nicht ausgestattet, und die Kopfzeile wird nicht hinzugefügt. Glücklicherweise bieten Cloud Load Balancer eine SSL-Terminierungsoption, mit der Sie den SSL-Datenverkehr entschlüsseln können, bevor er an die Zielserver weitergeleitet wird. Sie bietet gewisse Vorteile bei der Verringerung der Last auf den Anwendungsservern. Damit es funktioniert, müssen Sie lediglich die SSL-Terminierung für Ihren Load Balancer aktivieren und ihm einen privaten SSL-Schlüssel sowie ein Zertifikat bereitstellen.
Das ist tatsächlich ein hervorragendes Beispiel für die Trennung von Zuständigkeiten. Anstatt alle SSL-bezogenen Dinge in Ihren Server-Konfigurationsdateien zu verwalten, lagern Sie diese auf den Load Balancer aus – und es funktioniert einfach.
Eine wichtige Sache, die Sie beachten sollten, ist, dass nach der Aktivierung der SSL-Terminierung der gesamte HTTPS-Datenverkehr, der durch den Load Balancer kommt, zu HTTP wird. Es mag offensichtlich erscheinen, doch dieses kleine Detail wird sehr häufig vergessen. Wir sind beim Testen in unserer Staging-Umgebung selbst auf dieses Problem gestoßen. Die Lösung besteht in der Verwendung der X-Forwarded-Proto-Kopfzeile, die der Load Balancer für HTTPS-Datenverkehr auf „https“ setzt. Hier ist ein gutes Beispiel dafür, wie dies in nginx umgesetzt wird.
Ein überraschendes Leistungsergebnis bei der Verwendung der SSL-Terminierung
Vor der Umsetzung der Änderung wollten wir sicherstellen, dass die Leistung bei der Nutzung der SSL-Terminierung nicht leidet. Um dies zu überprüfen, haben wir einige Leistungstests in unserer Staging-Umgebung durchgeführt und unerwartete Ergebnisse erhalten: Load Balancer mit SSL-Terminierung schnitten im Durchschnitt tatsächlich besser ab als Load Balancer ohne diese Funktion.
Für diesen Test haben wir einen GET-Aufruf für drei verschiedene URLs durchgeführt:
GET /cpGET /cp/logGET /cp/domains[/list]
Jeder GET-Aufruf rief HTML-Seiten mit und ohne alle eingebetteten Ressourcen ab, d. h. die HTML-Datei wurde geparst und HTTP/HTTPS-Anfragen für alle in der Datei referenzierten Bilder, Java-Applets, JavaScript-Dateien, CSS-Dateien usw. gesendet.
Zwar gab es einen Fall, in dem die Leistung mit SSL langsamer war, doch im Durchschnitt war die Leistung überraschenderweise besser: Die durchschnittliche Ladezeit verringerte sich von 3.957 Millisekunden auf 3.811 Millisekunden, was einem Rückgang von 3,7 % entspricht. Nicht schlecht, wenn man bedenkt, dass die SSL-Terminierung den Übertragungsprozess einer Datei vom Client zum Server und zurück um zusätzliche Schritte erweitert.
Das war es für diese Woche. Wir hoffen, dass Sie diese Informationen nützlich finden, wenn Sie das nächste Mal eine SSL-Terminierung zu Ihren Load Balancern hinzufügen müssen. Bis nächste Woche.
Viel Erfolg beim E-Mail-Versand,
Ihr Mailgun-Team
