私の理解では、HTTPキープアライブヘッダーは、通信の次のパケットが同じ接続を介して送信されるかどうか、つまり、WebアプリがSSLで実行され、キープアライブが有効になっている場合(たとえば60秒間)を示します。次に:
-すべてのクライアント/サーバー通信は同じ接続を介して行われます
-60秒間非アクティブになった後のクライアントサーバー通信は、SSLハンドシェイクを再開し、要求と応答を続行します。
また、これはユーザーのセッション無活動タイムアウトにどのように関連付けられていますか?
通信の次のパケットが同じ接続を介して送信されるかどうか
ほぼ正確ではありません。このレベルの通信では「パケット」はなく、データストリームのみです。 HTTP-Keep-aliveは、HTTP応答の直後に接続を閉じるのではなく、より多くの要求のために開いたままにすることで、1つだけではなく、同じTCP/TLS接続で複数のHTTP要求を許可します。
HTTPキープアライブヘッダーが指示する
いいえ、それは何も指示しません。クエリにConnection: keep-alive
を追加する(またはHTTP/1.0ではなくHTTP/1.1を暗黙的に使用する)ことで、クライアントはサーバーが応答後にTCP接続を閉じないように丁寧に要求していますサーバーは同意する場合としない場合があります。
すべてのクライアント/サーバー通信は同じ接続を介して行われます
必ずしも。ブラウザとサーバーの間で複数のTCP/TLS接続が並行して開かれている可能性があります。
非アクティブ状態が60秒間続いた後のクライアントサーバー通信は、SSLハンドシェイクを再開し、要求と応答を続行します。
クライアントとサーバーはいつでもアイドル接続を閉じる(つまり、未処理の応答がない)ことを決定でき、両方に独立した設定とタイマーがあります。接続が閉じられ、クライアントが新しいリクエストを作成したい場合は、新しいTCP接続を作成する必要があり、HTTPSの場合、これに加えて既存のSSLセッションを再開する必要がありますTCP接続、または新しいSSLセッションに対して完全なTLSハンドシェイクを行うため。
また、これはユーザーのセッション無活動タイムアウトにどのように接続されていますか?
これはまったく無関係です。ユーザーセッションはアプリケーションレベルで管理されます。 HTTPキープアライブは、HTTPプロトコルレベルで管理されます。 1つのTCP接続(複数のHTTPリクエストを使用)内で複数のユーザーセッションを保持できます。また、ユーザーセッションを複数のTCP接続(両方の後と並列接続の両方)。
永続的な接続(HTTPキープアライブ)を有効にすることのセキュリティリスクは何ですか?
なにもない。