33

为了提高不保留（短）连接的 SSL 握手性能，有两个众所周知的独立功能：

  • TLS 会话 ID
  • TLS 会话票证

如果有很多短连接会话，在性能开销方面哪种机制更可取并且应该使用？

我知道服务器需要缓存会话 ID，在负载平衡的情况下会话票证也很容易共享，但是我们假设有一个服务器在单个端口上侦听（无负载平衡）并且它接收到非常多的 SHORT 传入 TLS 连接会话。

那么在这种情况下，哪种方法（会话或票证）更可取？

4

3 回答 3

22

当服务器发送“Server Hello”消息时，它可以包含一个会话标识符。客户端应将其存储并呈现在下一个会话的“Client Hello”消息中。如果服务器在其缓存中找到相应的会话并接受恢复会话，它将发送回相同的会话标识符，并继续进行简短的 SSL 握手。否则，它将发出一个新的会话标识符并切换到完全握手。这种机制在 RFC 5246 中有详细说明。它是最常见的机制，因为它从 SSL 的早期版本开始就存在。

在完整 SSL 握手的最后一次交换中，服务器可以包含一个“新会话票证”消息（未在图片中描述的握手中表示），该消息将包含完整的会话状态（包括客户端和客户端之间协商的主密钥）服务器和使用的密码套件）。因此，这个状态被一个只有服务器知道的密钥加密和完整性保护。这个不透明的数据被称为会话票。详细信息位于取代 RFC 4507 的 RFC 5077 中。

票证机制是 TLS 扩展。客户端可以通过在“Client Hello”消息中发送一个空的“Session Ticket”扩展来宣传其支持。如果支持，服务器将在其“Server Hello”消息中以空的“Session Ticket”扩展名进行回答。如果其中一个不支持此扩展，它们可以回退到 SSL 中内置的会话标识符机制。

RFC 5077 确定了票证优于会话标识符的情况。主要改进是避免需要维护服务器端会话缓存，因为整个会话状态由客户端而不是服务器记住。会话缓存在内存方面可能很昂贵，并且当请求在服务器之间进行负载平衡时，可能难以在多个主机之间共享。

于 2014-03-06T11:43:41.607 回答
16

使用会话 ID，服务器需要跟踪可以在某个时间点继续的先前会话。这导致服务器必须做一些额外的工作。

相比之下，session-ticket 不是标识符，而是由服务器加密的会话数据（并且只有服务器可以解密它）。当客户端想要继续会话时，它仍然知道预主密钥，但服务器不再知道。因此客户端将会话票证发送到服务器，并且只有服务器能够解密其内容。继续会话所需的任何信息都包含在其中，因此服务器可以在不保留任何信息的情况下恢复会话。所有额外的负载都在客户端上完成（通过保持 pre-master 机密和会话票证）。

于 2015-05-23T14:07:42.860 回答
0

在这种情况下，您只需要会话 ID，并且它们内置于大多数 SSL 实现中，这与 RFC 5077 票证不同，后者仍然是 TLS 扩展。

于 2013-11-12T21:52:54.900 回答