WSGI アプリケーションを展開するための一般的な構成には、リバース プロキシとして機能する汎用 Web サーバー (nginx など) の背後にある WSGI サーバー (uWSGI や Gunicorn など) が含まれます。リバース プロキシを使用する主な理由の 1 つは、静的ファイルを効率的に提供するためです。他に理由はありますか?
アプリケーションに Python コードのみが含まれ、静的コンテンツは考慮しないとします。この場合、リバース プロキシが必要なのはなぜでしょうか。uWSGI と Gunicorn はそれぞれ、クライアントとインターフェイスできる非同期 HTTP サーバーを既に提供しています。
WSGI HTTP サーバーを外部に直接公開したほうがよい実用的なケースはありますか?
答え1
本格的なリバースプロキシでは、より多くの設定オプションがあります。
- リライト
- 場所
- サーバ
- https
- ヘッダーのクリーンアップ
- 期限切れ
- 圧縮
- ....
負荷分散を行うことができる
- proxy_cacheを使うことができます
- アプリケーションサーバーがダウンしている場合でも、カスタムエラーページを実装できます。
- WAFを実装することができます
- 脆弱性に対してホットパッチを適用できる（場合によっては）
ボーナスポイント
- 次の設定 (nginx) を使用すると、100,000 リクエスト/秒 (平均的なハードウェア) でクライアントを満足させることができます。
。
location /perftest/ {
return 200;
}
答え2
リバース プロキシを使用することによる追加の利点。
あなたにとって有益となる可能性のある他のメリットも得られる可能性があります。
- インターネットから情報を隠すことができます（Webサーバーのバージョン、アプリサーバー、データベースサーバー、API）
- 1 つのドメインの背後に複数の Web サーバー テクノロジを実装できます (Linux tomcat + Windows IIS など)
- https/SSL 接続を終了し、内部 http サービスにマップできます。
- すべてのログを一元管理できます。
- すべてのDDOS対策を一元管理できます
- Web サーバー層から ID 管理を実装できます。
セキュリティ上の利点
- 内部サーバーは上記のように隠されています。
- ホスト上のソフトウェア ファイアウォール (DMZ と呼ばれる) に頼ることなく、内部のアプリケーション サーバーとデータベース サーバーをインターネットからルーター/ファイアウォールで保護できます。
- すぐに修正できないサーバーを、既知の問題 (Web アプリケーション ファイアウォール) や既知の攻撃パターンから保護できます。