📚 课程目录第4章会话管理优化

4. 会话管理优化：减少会话缓存大小、禁用会话票据、使用无状态会话恢复

说到 TLS 握手，很多人只盯着握手阶段的延迟和计算开销。但真正跑过嵌入式产品的工程师都知道，会话管理才是内存消耗的隐形杀手。我早期做的一个智能网关项目，设备跑着跑着就 OOM 了，查来查去，发现是 TLS 会话缓存把堆给撑爆了。从那以后，我对会话管理这块就特别敏感。

说白了，TLS 会话管理的核心目标就一个：让后续握手更快，同时少占内存。但嵌入式环境里，内存是硬约束，我们得在「快」和「省」之间找平衡。这一章，我就把三种常用的优化手段掰开揉碎讲清楚。

4.1 会话缓存：能省则省

先看最基础的东西——会话缓存。TLS 握手完成后，服务端和客户端都会缓存会话参数（比如主密钥、密码套件、随机数）。下次重连时，直接复用这些参数，跳过完整的握手流程。

但问题来了：默认的会话缓存有多大？ 拿 mbedTLS 举例，默认配置下每个会话条目大约占用 200~300 字节。如果你不限制数量，缓存条目会无限增长。我见过一个项目，设备同时维持 500 个连接，会话缓存直接吃掉 150KB 内存——这在 MCU 上简直是灾难。

核心原则： 嵌入式设备上，会话缓存不是越大越好，而是「够用就好」。根据你的并发连接数，精确计算缓存条目上限。

具体怎么做？我建议分三步走：

限制最大条目数：mbedTLS 中通过 MBEDTLS_SSL_CACHE_MAX_ENTRIES 宏控制。比如你的设备最多同时处理 10 个客户端，那就设成 10 或 15，留点余量就行。
设置超时时间：会话缓存不是永久有效的。mbedTLS 默认超时是 3600 秒，对嵌入式设备来说太长了。我一般设成 300~600 秒，够用且不浪费。
禁用不必要的缓存：如果设备只做单向通信（比如传感器上报数据），根本不需要缓存。直接关掉，能省一大块内存。

下面是一个 mbedTLS 的配置示例，展示了如何裁剪会话缓存：

// 在 mbedtls_config.h 中配置
#define MBEDTLS_SSL_CACHE_C            // 启用缓存模块
#define MBEDTLS_SSL_CACHE_MAX_ENTRIES  10  // 最多缓存 10 个会话
#define MBEDTLS_SSL_CACHE_TIMEOUT      300 // 超时时间 300 秒

// 如果不需要缓存，直接注释掉上面的宏
// #undef MBEDTLS_SSL_CACHE_C

小技巧： 如果你用 FreeRTOS，可以把会话缓存放在专用的内存池里，而不是用堆。这样既能避免碎片，又能精确控制内存占用。

4.2 会话票据：功能虽好，但别滥用

会话票据（Session Ticket）是 RFC 5077 定义的机制。它把会话状态加密后交给客户端保存，服务端不存任何状态。下次连接时，客户端把票据发回来，服务端解密后直接恢复会话。

听起来很完美对吧？但嵌入式环境里，会话票据也有代价：

票据本身占空间：一个典型的 TLS 1.2 会话票据大约 200~400 字节。如果客户端数量多，这些票据在网络传输和存储上都会产生开销。
加解密开销：服务端需要维护一个票据密钥，每次恢复会话都要做一次对称加解密。对低性能 MCU 来说，这可能是负担。
密钥管理麻烦：票据密钥需要定期轮换，否则有安全风险。嵌入式设备上做密钥轮换，复杂度不低。

我个人习惯是：如果设备只做服务端，且并发连接数不多（比如小于 50），直接用会话缓存就够了，没必要开票据。 只有当你需要做负载均衡，或者客户端频繁重连且服务端内存极度紧张时，才考虑会话票据。

避坑指南： 我曾经在一个项目里同时开启了会话缓存和会话票据，结果两个机制互相干扰，导致会话恢复失败率飙升。后来查文档才发现，mbedTLS 默认优先使用票据，缓存只在票据无效时才生效。如果你两个都开，一定要搞清楚优先级关系。

禁用会话票据的方法很简单，在 mbedTLS 中注释掉以下宏：

// 在 mbedtls_config.h 中
// #define MBEDTLS_SSL_SESSION_TICKETS   // 注释掉这行即可禁用

4.3 无状态会话恢复：终极省内存方案

如果你觉得会话缓存和票据都不够极致，那可以试试无状态会话恢复。说白了，就是服务端完全不保存任何会话状态，所有信息都交给客户端。

怎么做？核心思路是：把会话参数编码到客户端 hello 消息的扩展字段里。服务端收到后，直接解码并恢复会话。整个过程不需要查缓存，不需要解密票据，纯计算操作。

这种方案的好处很明显：

零内存占用：服务端不需要分配任何会话缓存。
天然支持水平扩展：多个服务端实例之间不需要同步会话状态。
恢复速度快：省去了查缓存和加解密的步骤。

但缺点也有：

实现复杂：需要自己编码/解码会话参数，还要处理完整性校验。
安全性要求高：会话参数不能泄露，必须加密或签名。
兼容性差：不是所有 TLS 库都支持，需要自己动手改。

下面是一个简化的无状态会话恢复流程示意图：

在 mbedTLS 中实现无状态会话恢复，需要自己实现回调函数。下面是一个简化的示例：

// 自定义会话恢复回调
static int my_session_save(void *ctx, mbedtls_ssl_session *session,
                           unsigned char *buf, size_t *len) {
    // 将 session 编码到 buf 中
    // 注意：这里需要做加密和完整性校验
    return mbedtls_ssl_session_save(session, buf, len);
}

static int my_session_load(void *ctx, mbedtls_ssl_session *session,
                           const unsigned char *buf, size_t len) {
    // 从 buf 中解码 session
    // 注意：这里需要做解密和完整性校验
    return mbedtls_ssl_session_load(session, buf, len);
}

// 配置时注册回调
mbedtls_ssl_config conf;
mbedtls_ssl_config_init(&conf);
mbedtls_ssl_config_defaults(&conf, MBEDTLS_SSL_IS_SERVER,
                            MBEDTLS_SSL_TRANSPORT_STREAM, 0);

// 注册无状态会话恢复回调
mbedtls_ssl_conf_session_tickets_cb(&conf,
                                    my_session_save,
                                    my_session_load,
                                    NULL);

经验之谈： 无状态会话恢复虽然省内存，但实现起来坑不少。我建议先在开发板上跑通基本流程，再用模糊测试工具（比如 AFL）压一下，看看有没有内存越界或逻辑漏洞。安全无小事，尤其是自己手写的编解码逻辑。

4.4 三种方案对比

说了这么多，到底该选哪种？我整理了一张对比表，方便你根据项目需求做决策：

方案	内存占用	实现复杂度	恢复速度	适用场景
会话缓存	中等（取决于条目数）	低（库自带支持）	快（查表即可）	并发连接数少，内存相对充裕
会话票据	低（服务端无状态）	中（需管理票据密钥）	中（需加解密）	需要负载均衡或客户端频繁重连
无状态恢复	极低（零内存占用）	高（需自实现编解码）	快（纯计算）	内存极度受限或需要水平扩展

我个人建议的选型策略是：

内存大于 256KB：直接用会话缓存，省心省力。
内存 64KB~256KB：考虑会话票据，或者限制缓存条目数。
内存小于 64KB：别犹豫，上无状态会话恢复。虽然实现麻烦，但这是唯一能跑起来的方案。

重要提醒： 不管你选哪种方案，一定要做压力测试。我见过一个项目，开发时一切正常，上线后设备运行一周，会话缓存碎片化导致内存分配失败。后来加了内存池和定期清理机制才解决。嵌入式开发，测试永远不嫌多。

好了，会话管理优化就讲到这里。记住一个核心原则：在嵌入式世界里，没有最好的方案，只有最适合你硬件条件的方案。 动手之前，先算清楚你的内存预算，再决定走哪条路。