我正在配置 HTTPS 服务器的非粘性负载平衡集群。为了在以前的客户端重新连接到集群中的不同服务器时启用 TLS 会话恢复，我将根据RFC 5077在集群中的所有服务器上配置共享会话票证密钥。
在 RFC 中，“5.5. 票证保护密钥管理”部分建议：
应定期更换钥匙。
到目前为止，我的研究还没有就“定期”应该是什么达成任何共识。一些参考文献每天都提到，但没有任何理由。此外，在流行的实现（例如 Apache、nginx）中，独立（即非集群）服务器上的票证密钥似乎仅在进程重启时轮换，这可能非常罕见。
所以，我的问题本质上是：
RFC 4346是“每日”建议的来源：
建议会话 ID 生命周期的上限为 24 小时，因为获得 master_secret 的攻击者可能能够冒充受害方，直到相应的会话 ID 退休。
缺乏任何更好的指导，你可能会在 24 小时内过得很好。我不知道有任何研究或经验表明较短的时间对于当前的交通是必要的或适当的。
你也可以降低很多。当客户在几分钟内用数百个连接锤击您时，会话恢复可能很重要。但是，例如，必须每小时重新协商一次，这对客户端或服务器来说并不麻烦。您节省了不断重新协商的 CPU 开销，但在“每个连接”和一个小时 - 或 30 分钟 - 在某些情况下甚至 5 分钟之间存在巨大差距。
具体回答您的观点：
证书有效期不包括在内（因为 24 小时远低于他们的关注范围）。客户端会话缓存时间很有趣，但遗憾的是，您可能无法使用 - 这可以追溯到我所说的查看您的客户端在可用时利用恢复的频率。
我的个人建议- 您可以玩 1 到 12 个小时的时间段，您可能会发现它们都为您提供了所需的性能提升，但在某些时候会出现收益递减（恢复使用）。找到一种记录恢复和新谈判的方法，并根据您自己的流量统计数据构建您的案例。
在 CloudFlare，我们每小时轮换一次。*
关于第二个问题，您需要考虑 UA 支持。使用长寿命的会话票证，例如 24 小时，您遇到损坏的客户端实现的可能性要小得多。但是，正如我们所发现的那样，对于较短的操作系统（在客户和用户等方面提供了一些极好的帮助），您会开始看到不完整或不正确的 RFC 5077 支持的操作系统。
正如这个错误所描述的，当 IE 和 .NET 的底层加密库 (SChannel) 尝试处理NewSessionTicket我们的边缘发送的消息时，它们都会犹豫不决。我们一直在与 Microsoft 密切联系以寻求修复，但有时当您积极实施新的安全协议和程序时，您必须解决此类情况。
总之，尽可能低，但要留意客户端问题。如果我不得不猜测，它们可能比微软更广泛。
* 该链接讨论了我们的 Keyless SSL 实施，但对我们的标准 HTTPS 终止有效