Eine typische Konfiguration zum Bereitstellen einer WSGI-Anwendung umfasst einen WSGI-Server (wie uWSGI oder Gunicorn) hinter einem Allzweck-Webserver (wie nginx), der als Reverse-Proxy fungiert. Ein Hauptgrund, den ich für einen Reverse-Proxy kenne, ist die effiziente Bereitstellung statischer Dateien. Gibt es noch andere Gründe?
Angenommen, meine Anwendung umfasst nur Python-Code und kümmert sich nicht um statische Inhalte. Warum sollte ich in diesem Fall den Reverse-Proxy wollen? uWSGI und Gunicorn stellen bereits einen asynchronen HTTP-Server bereit, der mit den Clients kommunizieren kann.
Gibt es praktische Fälle, in denen es für mich besser wäre, den WSGI-HTTP-Server direkt der Außenwelt zugänglich zu machen?
Antwort1
Sie haben mehr Konfigurationsmöglichkeiten mit einem vollwertigen Reverse-Proxy wie
- umschreiben
- Standorte
- Server
- https
- Header-Bereinigung
- läuft ab
- gzip
- ....
Sie können Lastenausgleich durchführen
- Sie können proxy_cache verwenden
- Sie können benutzerdefinierte Fehlerseiten implementieren, selbst wenn Ihre App-Server ausgefallen sind
- Sie können eine WAF implementieren lassen
- Sie können (manchmal) Hotpatches gegen Schwachstellen durchführen
BONUSPUNKT
- Mit dem folgenden Setup (nginx) können Sie Clients mit 100.000 Anfragen/Sekunde (auf durchschnittlicher Hardware) beeindrucken:
.
location /perftest/ {
return 200;
}
Antwort2
Zusätzliche Vorteile der Verwendung eines Reverse-Proxys.
Es können weitere Vorteile erzielt werden, die für Sie von Nutzen sein KÖNNTEN.
- Sie können Informationen vor dem Internet verbergen (Webserverversion, App-Server, Datenbankserver, API).
- Sie können mehrere Webserver-Technologien hinter einer Domäne implementieren (Linux Tomcat + Windows IIS usw.)
- Sie können https/SSL-Verbindungen beenden und internen http-Diensten zuordnen.
- Sie können die gesamte Protokollierung zentralisieren.
- Sie können die gesamte DDOS-Prävention zentralisieren
- Sie können die Identitätsverwaltung auf der Webserverebene implementieren.
Sicherheitsvorteile
- Interner Server wird wie oben ausgeblendet.
- Sie können Ihre internen App-Server und Datenbankserver per Router/Firewall vom Internet aus schützen, ohne auf Software-Firewalls auf dem Host zurückgreifen zu müssen (DMZ genannt).
- Sie können einen Server schützen, der nicht sofort vor bekannten Problemen (Web Application Firewall) oder bekannten Angriffsmustern repariert werden kann.