Page 63 - Web性能权威指南

• 0 ms：TLS 在可靠的传输层（TCP）之上运行，这意味着首先必须完成 TCP 的“三
次握手”，即一次完整的往返。
• 56 ms：TCP 连接建立之后，客户端再以纯文本形式发送一些规格说明，比如它所运
行的 TLS 协议的版本、它所支持的加密套件列表，以及它支持或希望使用的另外一
些 TLS 选项。
• 84 ms：然后，服务器取得 TLS 协议版本以备将来通信使用，从客户端提供的加密
套件列表中选择一个，再附上自己的证书，将响应发送回客户端。作为可选项，服
务器也可以发送一个请求，要求客户端提供证书以及其他 TLS 扩展参数。
• 112 ms：假设两端经过协商确定了共同的版本和加密套件，客户端也高高兴兴地
把自己的证书提供给了服务器。然后，客户端会生成一个新的对称密钥，用服务
器的公钥来加密，加密后发送给服务器，告诉服务器可以开始加密通信了。到
目前为止，除了用服务器公钥加密的新对称密钥之外，所有数据都以明文形式
发送。
• 140 ms：最后，服务器解密出客户端发来的对称密钥，通过验证消息的 MAC 检
测消息完整性，再返回给客户端一个加密的“Finished”消息。
• 168 ms：客户端用它之前生成的对称密钥解密这条消息，验证 MAC，如果一切
顺利，则建立信道并开始发送应用数据。

新 TLS 连接要完成一次“完整的握手”需要两次网络往返。另外，还可以使
用“简短握手”，只需一次往返，详细信息请参见 4.3 节“TLS 会话恢复”。

协商建立 TLS 安全信道是一个复杂的过程，很容易出错。好在服务器和浏览器会替
我们做好这些工作，我们要做的就是提供和配置证书！

总之，尽管我们的 Web 应用不一定参与上述过程，但最重要的是知道每一个 TLS
连接在 TCP 握手基础上最多还需要两次额外的往返。这些都会增加实际交换数据之
前的等待时间！如果考虑不周，通过 TLS 交付数据很可能会引入几百甚至几千 ms
的网络延迟。

公钥与对称密钥加密的性能

公钥加密系统（http://en.wikipedia.org/wiki/Public-key_cryptography）只在建立 TLS
信道的会话中使用。在此期间，服务器向客户端提供它的公钥，客户端生成对称
密钥并使用服务器的公钥对其加密，然后再将加密的对称密钥返回服务器。服务
器继而用自己的私钥解密出客户端发来的对称密钥。

传输层安全（TLS） ｜ 45