同一节点第二次握手更快？TLS 会话恢复会影响测速
同一节点第二次握手更快？TLS 会话恢复会影响测速
用同一个网站连续测试机场节点时，第二次往往比第一次快。除了网络波动，TLS 会话恢复和连接复用也会影响结果：客户端可能利用前一次握手得到的信息，减少后续握手工作，甚至直接复用已有连接。
如果把“第一次冷启动”和“第二次热连接”混在一起比较，就可能错误地把缓存收益归到某个节点上。
会话恢复是什么
RFC 8446 说明，TLS 1.3 可以使用先前连接建立的预共享密钥进行会话恢复。恢复连接仍要完成安全检查，但握手路径和计算工作可能与首次完整握手不同。
curl 也会在同一次命令处理多个 URL 时尽量复用连接；独立运行两次 curl 通常不能直接共享同一个连接缓存。因此，浏览器连续刷新、单条 curl 多 URL 和两次独立 curl 的结果不能混为一谈。
设计冷、热两组测试
冷启动组： 完全退出测试浏览器或每次运行独立 curl，等待短暂间隔，再记录 time_connect、time_appconnect 和 time_total。
curl -o NUL -sS -w "tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" https://example.com/
热连接组： 在同一浏览器会话中连续访问同一目标，或使用能明确复用连接的测试工具，记录第二次及后续请求。
在 macOS 或 Linux 上将 NUL 换为 /dev/null。保持目标、节点、网络和时间窗口一致。
不要直接相减得出绝对结论
time_appconnect 是从请求开始到 TLS 握手完成的累计时间，不是纯 TLS 耗时。粗略查看握手增量可以观察 time_appconnect - time_connect，但 DNS、代理握手、连接复用和实现差异仍会影响数值。
如果第二次明显更快，应记录它属于热连接结果；如果第一次在多个时段都慢，才继续检查路由、丢包或入口负载。浏览器开发者工具还可能显示来自缓存的资源，需选择实际发起网络请求的条目。
机场推荐的验收方式
分别报告冷启动和连续使用表现，每组至少做几次交替测试，并记录失败。用户首次打开应用更接近冷启动，持续浏览更接近热连接；两类体验都有价值。
评论