Page 74 - Web性能权威指南

飞猛进的发展为减小这种损失提供了强力支持，原先需要专门硬件来做的工作，今
天直接通过 CPU 就能完成。Facebook、谷歌等大公司都通过 TLS 向数百万用户提
供服务，相关的计算工作通过软件和普通的计算机就能完成。

今年（2010 年）1 月份，Gmail 切换为默认使用 HTTPS。在此之前，它只是
一个选项，而现在所有用户都在使用 HTTPS 在浏览器与谷歌之间随时随地
安全地收发邮件。为做到这一点，我们并没有部署额外的机器，也没有专用
硬件。在我们的前端机器上，SSL/TLS 计算只占 CPU 负载的不到 1%，每个
连接只占不到 10 KB 的内存，以及不到 2% 的网络资源。很多人认为 SSL/
TLS 占用了很多 CPU 时间，我们希望上述几个数字（首次公开）能消除人
们的顾虑。

如果你现在不想往下再看了，那只需要记住一件事：SSL/TLS 计算已经不是
问题了。

——Adam Langley（谷歌）
我们已经大规模部署了 TLS，既使用了硬件也使用软件负载均衡器。我们发
现当前基于软件的 TLS 实现在普通 CPU 上已经运行得足够快，无需借助专
门的加密硬件就能够处理大量的 HTTPS 请求。我们使用运行于普通硬件上
的软件提供所有 HTTPS 服务。

——Doug Beaver（Facebook）
尽管如此，像 4.3 节“TLS 会话恢复”中介绍的技巧对优化性能依旧很重要，它能
帮你减少计算损失和 TLS 握手期间的公钥加密延迟。CPU 也不应该处理本不该处理
的计算。

说到优化 CPU 周期，一定别忘了把你的 SSL 库升级到最新版本，在此基
础上再构建 Web 服务器和代理服务器！最新版的 OpenSSL 在性能方面有
了明显的提升，而你系统中默认的 OpenSSL 库很有可能已经过时了。

4.7.2 尽早完成（握手）

建立连接的延迟体现在每个 TLS 连接上，包括新连接和恢复的连接，因此是优化的
重点。我们知道 TCP 连接首先要经过 2.1 节描述的“三次握手”，两端要通过一次
完整的往返交换 SYN/SYN-ACK 分组。其次，4.2 节介绍的“TLS 握手”在完整的
情况下，需要两次额外的往返，或在 4.3 节描述的“TLS 会话恢复”的情况下，需
要一次额外的往返。
最差的情况，在实际交换应用数据之前，建立 TCP 和 TLS 连接的过程要经过三次往
返！以前面纽约的客户端连接伦敦的服务器为例，每次往返耗时 56 ms（见表 1-1），

56 ｜ 第 4 章