4

RFC 6265 をスキャンしましたが、次の回答が見つかりませんでした。

1 つの Web アプリケーションに対して複数のサーバーの前に単純なラウンド ロビン ロード バランサーを配置したいと考えています。ロード バランサはスティッキー セッションを提供しません。そのため、クライアントは通常、連続するリクエストで 1 つのアプリサーバーから別のアプリサーバーにバウンスします。

最初の接続では、クライアントには SID がなく、たとえばサーバー A にランダムにルーティングされます。
サーバー A は、セッション cookie である nonce で応答します。

次の接続で、クライアントはサーバー A からの SID を HTTP ヘッダーに含めます。今回は、クライアントは、たとえばサーバー B にランダムにルーティングされます。サーバー B は、発行したどの SID とも一致しない (希望があります!) SID を認識します。何が起こるのですか？サーバー B は単に「悪い」SID を無視するか、文句を言うか、または要求を無視しますか?

アイデアは、セッション Cookie をまったく使用したくないということです。粘着性のすべての複雑さを避けたい. しかし、私のサーバーはおそらくセッション Cookie を生成することも知っています。

サーバーがセッション Cookie を無視する (または、できれば設定しない) ようにするにはどうすればよいですか?

4

1 に答える 1

5

これに対する答えは、サーバーで実行されているアプリケーションによって大きく異なると思います。その塩に値するロードバランサーにはスティッキーセッションがありますが、プール内のすべてのサーバーが集中型データベースを介して同じセッション状態にアクセスできる限り、それらなしでの操作を実行できます。

セッションIDについて話しているので、アプリケーションが機能するためにセッション状態に依存していると思います。この場合、リクエストが「不正な」セッションIDで着信した場合、そのリクエストは破棄される可能性が高く、ユーザーはログインを求められます。この場合も、正確な動作はアプリによって異なります。セッションCookieを完全に無効にすると、IDがなくてもログインプロンプトが表示される可能性があるため、問題はさらに悪化する可能性があります。

ロードバランサーでの複雑さを本当に避けたい場合は、すべてのサーバーがすべてのセッションからの要求を処理できるメカニズムを導入する必要があります。通常、これは一元化されたデータベースまたはその他の共有ストレージの形式を取ります。これにより、サーバーがその特定の要求を処理するかどうかに関係なく、セッション状態を維持できます。

セッション状態を維持することは、負荷分散の（しゃれを意図した）こだわりの1つですが、セッションCookieを単に無視または回避することは解決策ではありません。

于 2012-07-30T21:09:39.453 に答える