(短い) 接続を保持しないための SSL ハンドシェイクのパフォーマンスを向上させるために、広く知られている 2 つの別個の機能があります。
非常に多くの短い接続セッションの場合、パフォーマンス オーバーヘッドの観点からどのメカニズムが好ましく、使用する必要がありますか?
サーバーがセッションIDをキャッシュする必要があることはわかっています。また、負荷分散の場合、セッションチケットは簡単に共有できますが、単一のポートでリッスンしている単一のサーバーがあり（負荷分散なし）、非常に多くのSHORT着信TLS接続セッションを受信するとします。
このシナリオでは、どのアプローチ (セッションまたはチケット) が望ましいでしょうか?
セッション ID を使用すると、サーバーは、ある時点で継続できる可能性のある以前のセッションを追跡する必要があります。これにより、サーバーが実行しなければならない余分な作業が発生します。
対照的に、セッションチケットは識別子ではなく、サーバーによって暗号化されたセッションデータです (サーバーだけが復号化できます)。クライアントがセッションを継続したい場合、クライアントはまだプレマスターシークレットを知っていますが、サーバーはもう知っていません. したがって、クライアントはセッションチケットをサーバーに送信し、サーバーだけがそのコンテンツを復号化できます。セッションを続行するために必要な情報がそこに含まれているため、サーバーは情報を保持せずにセッションを再開できます。追加の負荷はすべてクライアントで行われます (プレマスター シークレットとセッション チケットを保持することにより)。
この状況ではセッション ID のみが必要であり、RFC 5077 チケット発行 (まだ TLS 拡張である) とは異なり、セッション ID はほとんどの SSL 実装に組み込まれています。