https通信の基礎となるSSLセッションの存続期間について、同僚の間で熱心な（しかし友好的な）議論があります。
通常のブラウザを使用してサーバーへのhttps接続を確立すると、基盤となるSSLが非対称暗号化を使用してセッション（共有シークレットを含む）を作成し、残りの通信は（より高速な）対称暗号化を使用して暗号化されます。
問題は次のとおりです。同じサーバーへの後続のhttps要求（リンクをクリック）で、セッションキーを確立するための非対称暗号化のオーバーヘッドを回避して、古いsslセッションが再度使用されますか？または、sslセッションを確立するための新しい非対称暗号化sslハンドシェイクが必要ですか？
言い換えると、SSLセッションはhttpsリクエスト間で存続しますか、それともhttpsリクエストの終了で終了しますか？
私たちはここにたくさんの落とし穴があるので、いくつかの権威ある情報源への言及は高く評価されるでしょう。
Chromeでこれをテストしました：
https://www.americanexpress.comに移動します。netstatは次のことを示しています。
$ netstat -n -p tcp|grep 184.86.149.155
tcp4 0 0 10.177.78.58.50311 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50310 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50309 184.86.149.155.443 ESTABLISHED
Webサイト上の他のリンクに移動すると、netstatは次のことを示します。
$ netstat -n -p tcp|grep 184.86.149.155
tcp4 0 0 10.177.78.58.50311 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50310 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50309 184.86.149.155.443 ESTABLISHED
セッションは存続しました。ブラウザのタブを閉じて再度開くと、別の接続が開かれました。
$ netstat -n -p tcp|grep 184.86.149.155
tcp4 0 0 10.177.78.58.50398 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50311 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50310 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50309 184.86.149.155.443 ESTABLISHED
最近のブラウザは、httpと同じキープアライブタイムアウトを利用しているように見えます。これらのタイムアウトはここで見ることができます：
http://gabenell.blogspot.com/2010/11/connection-keep-alive-timeouts-for.html
http://www.ietf.org/rfc/rfc2818.txtのセクション2.2およびhttp://www.ietf.org/rfc/rfc2616.txtのセクション8.1を参照してください。
本質的に、クライアントが永続的な接続を維持している間、SSLセッションは維持されるべきです（SHOULD）。
一般的なブラウザでの持続的接続の実装の詳細については、http：//en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsersを参照してください。
ブラウザがセッションの再開をサポートし、サーバーがセッションをキャッシュしている場合、接続間でセッションを続行できる可能性があります。GNUTLSはこれをサポートしており、ここでデモを見ることができます。