Page 73 - Web性能权威指南
P. 73
• 记录协议接收应用数据。
14
• 接收到的数据被切分为块：最大为每条记录 2 字节，即 16 KB。
• 压缩应用数据（可选）。
• 添加 MAC（Message Authentication Code）或 HMAC。
• 使用商定的加密套件加密数据。
以上几步完成后，加密数据就会被交给 TCP 层传输。接收端的流程相同，顺序相
反：使用商定的加密套件解密数据、验证 MAC、提取并把数据转交给上层的应用。
同样，值得庆幸的是以上过程都由 TLS 层帮我们处理，而且对大多数应用都是完全
透明的。不过，记录协议也带来了一些重要的限制，务必要注意：
• TLS 记录最大为 16 KB；
• 每条记录包含 5 字节的首部、 MAC（在 SSL 3.0、 TLS 1.0、 TLS 1.1 中最多 20 字节，
在 TLS 1.2 中最多 32 字节），如果使用块加密则还有填充；
• 必须接收到整条记录才能开始解密和验证。
有可能的话，应该自主选择记录大小，这也是一项重要的优化。小记录会因记录分
帧而招致较大开销，大记录在被 TLS 层处理并交付应用之前，必须通过 TCP 传输
邮
和重新组装。
电
4.7 针对TLS的优化建议
鉴于网络协议的分层架构，在 TLS 之上运行应用与直接通过 TCP 通信没有什么不
同。正因为如此，只需要对应用进行很少改动甚至不用改动就可以让它基于 TLS 通
信。当然，前提是你根据 2.5 节“针对 TCP 的优化建议”中的最佳实践去做了。
不过，你还应该关心 TLS 部署运维的一些方法，比如服务器的部署方式和地理位
置、TLS 记录及内存缓冲区大小、是否支持简短握手，等等。关注这些细节不仅能
大大改善用户体验，还能帮你节省运维成本。
4.7.1 计算成本
建立和维护加密信道给两端带来了额外的计算复杂度。特别地，首先有一个非对称
（公钥）加密，我们在 4.2 节“TLS 握手”中介绍过。然后，在握手期间确定共享密
钥，作为对后续 TLS 记录加密的对称密钥。
如前所述，公钥加密与对称加密相比，需要更大的计算工作量。因此，在 Web 发展
早期，通常都需要专门的硬件来进行“SSL 卸载”。好在现在不这样了。现代硬件突
传输层安全（TLS） ｜ 55
