Page 64 - Web性能权威指南
P. 64
接下来，客户端与服务器间的通信就全都使用客户端生成的共享密钥加密，这就
是对称密钥加密。之所以这样设计，很大程度上是出于性能考虑，因为公钥加密
需要很大的计算量。为了演示两者的差别，假如你的电脑上安装了 OpenSSL，可
以试试以下两条命令：
• $> openssl speed rsa
• $> openssl speed aes
需要注意，这两条命令涉及的单位不能直接相比：RSA 测试会提供一个摘要表格，
列出不同密钥大小每秒的操作数，而 AES 性能通过每秒的字节数来度量。无论如
何，都不难看出 RSA 操作（完整的 TLS 握手）的数量，在推荐的 1024 或 2048
位的密钥长度下都很可能成为瓶颈。
实际的数值可能会因硬件、核心数量、TLS 版本、服务器配置、典型的服务负载，
以及其他因素不同而有很大差异。请大家不要轻信一些广告宣传或过时的测试报
告，最好还是在自己的硬件上运行上述测试。
4.2.1 应用层协议协商（ALPN）
理论上，网络上的任意两端都可以使用自定义的协议进行通信。为此，需要提前确
定使用什么协议、指定端口号（HTTP 是 80，TLS 是 443），并配置所有客户端和服
务器使用它们。然而在实践中，这种方法效率很低且很难做到。因为每个端口都必
须得到认可，而防火墙及其他中间设备通常只允许在 80 和 443 端口上通信。
于是，为了简化自定义协议的部署，我们往往必须重用 80 或 443 端口，再通过额
外的机制协商确定协议。80 端口是为 HTTP 保留的，而 HTTP 规范还专门为协商协
议规定了一个 Upgrade 首部。可是，使用 Upgrade 需要一次额外的往返时间，且由
于很多中间设备的存在，协商结果也不可靠。要了解更多信息，请参考 4.1 节中的
“Web 代理、中间设备、TLS 与新协议”。
12.3.9 节“有效的 HTTP 2.0 升级与发现”中有一个使用 HTTP Upgrade 的
实际例子。
解决办法不难想象，那就是使用 443 端口，这是给（运行于 TLS 之上的）安全
HTTPS 会话保留的。由于端到端的加密信道对中间设备模糊了数据，因此这种方式
就成为了一种部署任意新应用协议的可靠而快捷的方式。不过，虽然使用 TLS 保障
了可靠性，但我们还需要一种机制来协商协议。
作为 HTTPS 会话，当然可以利用 HTTP 的 Upgrade 机制来协商，但这会导致一次额
外的往返，造成延迟。那在 TLS 握手的同时协商确定协议可行吗？
46 ｜ 第 4 章
