ブラウザからWebサイトへのSSL接続があると仮定します。
そのページからボタンを押すと、サイトの別の場所(別のページ)にいます。どのような状況で接続が再ネゴシエートされますか?
servlerリダイレクトで?前方?どんな流れ?
そして、この場合の正しい流れは何ですか?すべてのサイトがであることに注意してくださいHTTPS
。つまり、プレーンなHTTP
領域や外部リンク(追加など)はありません。
コンテナはTomcatになります。
2 に答える
通常、SSL/TLS 接続は、サーバーがクライアント証明書認証を要求した場合に再ネゴシエートされます (これは、コネクタでクライアント認証を無効にすることによって行われますがCLIENT-CERT
、webapp 内で認証を要求しますweb.xml
)。
それ以外の場合、HTTP 要求/応答は、ブラウザーによって作成された同時 TCP 接続の通常のプールの一部として交換されます (これは、SSL/TLS よりも HTTP 接続の再利用に関係しています)、通常のタイムアウト設定 (具体的ではありません) SSL/TLS へ)。最新のブラウザーは、SSL/TLS セッションを再利用して、それぞれに対して完全な SSL/TLS ハンドシェイクを行う必要がないようにする必要があります。SSL/TLS セッションにもタイムアウトがありますが、通常は十分な長さです。とにかく、新しい接続の再確立はブラウザによって透過的に行われます。
False Start は成功していないようですが、SSL/TLS ハンドシェイクによるオーバーヘッドを削減するためのさまざまなメカニズムもあります(サポートはブラウザーによって異なります) 。
Webページでそのボタンをクリックすると、接続が確立されます(つまり、サーバーへのGETまたはPOST)。HTTP1.1。WebページのHTMLや後続の画像、CSS、JSなどのすべてのリソースを取得するために、リクエスト全体でその接続を開いたままにします。ユーザーが開始したリクエスト間で接続を開いたままにしたい場合は、keepを調べることができます。 -生きています。https(またはhttp)に使用する必要があるかどうかについては、いくつかの論争があります。
キープアライブ設定にもかかわらず、ブラウザは、たとえば60秒のウィンドウで他の何かをクリックした場合に備えて、接続を一定期間開いたままにしようとする場合としない場合があります。上記のリンクは、これについてもう少し詳しく説明しています。
サーブレットのリダイレクトまたは転送には、接続を再ネゴシエートする意味や理由があってはなりません。ユーザーがボタンをクリックしたときに作成したものと同じものを使用します。