HTTPはアプリケーションプロトコルであり、HTTPアプリケーション（パフォーマンスを除く）に影響を与えることなく、基になるTCP接続を閉じて再度開くことができます。
HTTP1.1を使用することにより、永続的な接続を使用しますが、サーバーまたはクライアントは接続をいつでも閉じることができます。
セキュリティのために、HTTPはSSL/TLS経由のTCPを使用します。
私の理解では、SSLはアプリケーションとよく似た働きをしています。少なくとも、これはTCPがSSLを「見る」方法です。
セキュリティで保護された接続が確立された後に、元のTCPソケットがある時点で閉じると、SSLセッションが無効になり、当事者がsslハンドシェイクを開始するはずですか？
または、基になるTCP接続がTLSセッションと無関係ですか？http persistent connectionおよびssl session
ありがとうございます！
これは、SSLセッションが無効になり、当事者がsslハンドシェイクを開始する必要があることを意味しますか？
はい、SSL/TLSセッションは終了し、ハンドシェイクを再確立する必要があります。 TLSには、セッションを再開するためのメカニズムが含まれています（まだいくつかの操作が実行されますが、完全なハンドシェイクはありません）。ただし、すべてのアプリケーションでサポートされているわけではありません。
レジュームに関する技術的な詳細については、http://ietf.org/rfc/rfc2246.txt、F.1.4を参照してください。
http://publib.boulder.ibm.com/httpserv/ihsdiag/ihs_performance.html#SSL：
SSLセッションが安全な通信のために、クライアントとWebサーバ間の論理接続です。 SSLセッションの確立中、公開鍵暗号は、クライアントとサーバとの間で共有秘密マスター鍵を交換するために使用され、暗号のような通信の他の特性が決定される。セッションでの後のデータ転送は、SSLハンドシェイク中に作成された共有鍵を使用して、対称鍵暗号方式で暗号化および復号化されます。
共有キーの生成は、CPUを大量に消費します。すべてのTCP接続で共有キーが生成されないようにするために、複数の接続で同じSSLセッションを再利用する機能があります。クライアントは、後続のハンドシェイクで同じSSLセッションを再利用するように要求する必要があり、サーバーにはSSLセッション識別子がキャッシュされている必要があります。これらの要件が満たされた場合、後続のTCP接続のハンドシェイクでは、サーバーのCPUが大幅に少なくなります（一部のテストでは80％減）。一般的に使用されているすべてのWebブラウザは、同じSSLセッションを再利用できます。しかし、カスタムWebクライアントには必要なサポートがないことがあります。
@Eugene：セキュリティーの詳細が交換されているため（アルゴリズムなど）、SSLピアの部分にはセキュリティで保護されたチャネル（暗号化/復号化）の確立に必要な情報があります。この部分は理解しています。 tcp接続は、暗号化されたブロックを取得し、それらをソケット経由で送信します。どのようにTCP接続を閉じると、以前に合意されたSSLの関係者（クライアント/サーバー）のセキュリティの詳細が無効になるのですか？この部分は分かりません。詳細を教えてください。 – Cratylus
@ user384706技術的な観点から、SSL/TLSはUDP（UDPの場合はDTLSという名前の変更を使用する）、名前付きパイプ、ピジョンメールなど（UDPの場合は一度実装しました）メッセージベースの通信チャネルを介して）。ただし、特定の攻撃を防止するためには、基盤となるチャネルの切断が自動的にSSL接続を無効にすることに同意しています。一般的には、クライアント側とサーバー側の両方の通信を実装し、SSL機能を制御する場合（たとえば、コンポーネントを使用している場合など）は、これを行う必要はありません。 –
@Eugene：TLSセッションが無効になったと考えるのがベストプラクティスですか？どんなRFCによっても義務付けられているわけではありませんし、TLS RFCによって暗示されているわけでもありません。 – Cratylus