Page 77 - Web性能权威指南
P. 77
此外，如果客户端和服务器都支持会话记录单，则所有会话数据都将保存在客户端，
上述步骤就都不需要了（问题一下子就简单了很多）！不过，由于会话记录单还是
相对新的 TLS 扩展，并非所有客户端都支持它。实践中，为了取得最优结果，应该
做好两手准备：在支持的客户端中使用会话记录单，而在不支持的客户端中使用会
话标识符。这两种手段不会相互干扰，而是会很好地协同工作。
4.7.4 TLS记录大小
所有通过 TLS 交付的应用数据都会根据记录协议传输（图 4-8）。每条记录的上限
为 16 KB，视选择的加密方式不同，每条记录还可能额外带有 20 到 40 字节的首部、
MAC 及可选的填充信息。如果记录可以封装在一个 TCP 分组内，则还会给它增加
相应的 IP 和 TCP 字段，即 20 字节的 IP 首部和 20 字节的 TCP 首部（无选项）。结
果，每条记录的大小就变成了 60 到 100 字节。由于 MTU 通常为 1500 字节，因此
分组占比最小的情况下只相当于帧大小的 6%。
记录越小，分帧浪费越大。但简单地把记录增大到上限（60 KB）也不一定好！如
果记录要分成多个 TCP 分组，那 TLS 层必须等到所有 TCP 分组都到达之后才能解
密数据（图 4-10）。只要有 TCP 分组因拥塞控制而丢失、失序或被节流，那就必须
将相应 TLS 记录的分段缓存起来，从而导致额外的延迟。实践中，这种延迟会造成
浏览器性能显著下降，因为浏览器倾向于逐字节地读取数据。
图 4-10：WireShark 的截图，其中 11 211 字节的 TLS 记录被分成了 8 个 TCP 段
小记录会造成浪费，大记录会导致延迟。因此，记录到底多大合适没有唯一“正
确”的答案。不过对于在浏览器中运行的 Web 应用来说，倒是有一个值得推荐的做
法：每个 TCP 分组恰好封装一个 TLS 记录，而 TLS 记录大小恰好占满 TCP 分配的
传输层安全（TLS） ｜ 59
