Page 75 - Web性能权威指南

那么建立完整的 TCP 和 TLS 连接需要三次往返即 168 ms，而恢复 TLS 会话需要
112 ms。当然，56 ms 是最乐观的数字，正常情况下延迟越长，性能损失越严重。

因为所有 TLS 会话都是在 TCP 之上完成的，因此 2.5 节“针对 TCP 的优化建议”
在这里也完全适用。如果说重用 TCP 连接对于非加密通信是一个重要的优化手段，
那么这个手段对运行在 TLS 上的应用同样至关重要。换句话说，只要能省掉握手，
就应该省掉。如果必须握手，那么还有一个可能的技巧：尽早完成。

第 1 章讨论过，我们不能指望延迟在将来能下降多少，因为光电信号的传输速度已
经是光速的一个非常小的常数因子了。不能让分组传播更快，但可以缩短传播距
离！尽早完成就是这么一个技巧，即通过把服务器放到离用户更近的地方（图 4-9），
让客户端与服务器之间往返延迟最少。

ெࡔ౨ሀ
Ԩںپ૙

ᆈࡔ୿ܘ

නԨ۫৙
Ԩںپ૙
ᇱ๔ޜခഗ

图 4-9：客户端连接的尽早完成

做到尽早完成的最简单方式，就是在世界各地的服务器上缓存或重复部署数据和服
务，而不要让所有用户都通过跨海或跨大陆光缆连接到一个中心原始服务器。当然，
这正是 CDN（Content Delivery Networks，内容分发网络）服务的内容：通过使用
本地代理服务器分流负载等手段降低延迟。

虽然 CDN 最常用于在全球优化分发静态资源，但其优点并不止于此。距离客户端
更近的服务器还可以缩短 TLS 会话，因为 TCP 和 TLS 握手的对象都是近处的服务
器，所以建立连接的总延迟就会显著减少。相应地，本地代理服务器则可以与原始
服务器建立一批长期的安全连接，全权代理请求与响应。

简言之，把服务器放到接近客户端的地方能够节约 TCP 和 TLS 握手的时间！大多数
CDN 提供商都提供这种服务，当然如果你愿意也可以以最小的成本部署自己的基础

传输层安全（TLS） ｜ 57