3

ここでベストプラクティスを探しています。ロード バランサー レベルで SSL 接続を処理するため、ロード バランサーから Web サーバーへのすべての接続は http です。すべての接続は http を介して行われるため、クライアントが Web サーバーに対してどのような接続を行っているかを知る方法はありません。現在、2 つの解決策があります。1 つは、ロード バランサーで URL 文字列にポート番号を追加して、リクエストの種類を判断できるようにすることです (例: http の場合は 80、https の場合は 443)。もう 1 つの解決策は、ロード バランサーが https 要求を取得するときに特別なヘッダーを追加して、Web サーバーが接続の種類を認識できるようにすることです。

両方のソリューションに短所がありますか? SSL を Web サーバー レベルではなくロード バランサー レベルで適用することに関するベスト プラクティスはありますか?

4

2 に答える 2

1

私はヘッダーの方がいいと思います。URL に何かを追加すると、わずかではありますが、アプリが使用するクエリ文字列パラメーターと衝突する可能性が生じます。カスタムヘッダーの方が簡単です。

3 番目のオプションは、ssl 接続を別のポート (たとえば 8080) にリダイレクトすることです。バックエンドでは、ポート 80 接続は最初は http であり、ポート 8080 接続は最初は 443 であることがわかります。その時点で両方のhttp。

于 2009-03-23T21:08:43.960 に答える
1

ヘッダーを使用することをお勧めします。Web サーバーへのすべてのリクエストはロード バランサーで発生しているように見えるため、関連する概念はクライアントの IP アドレスを決定することです (ログの目的で)。ここx-forwarded-forでは通常、ヘッダーが使用されます。

于 2009-03-24T19:53:23.523 に答える