Page 61 - Web性能权威指南

为了建立加密的安全数据通道，连接双方必须就加密数据的密钥套件和密钥协商一
致 。TLS 协议规定了一套严密的握手程序用于交换这些信息，相关内容将在 4.2 节
“TLS 握手”中介绍。握手机制中设计最巧妙的地方，就是其使用的公钥密码系统
（也称“非对称密钥加密”），这套系统可以让通信双方不必事先“认识”即可商定共
享的安全密钥，而且协商过程还是通过非加密通道完成的。

握手过程中，TLS 协议还允许通信两端互相验明正身。在浏览器中，验证机制允许
客户端验证服务器就是它想联系的那个（比如，银行），而不是通过名字或 IP 地址伪
装的目标。这个验证首先需要建立“认证机构信任链”（Chain of Trust and Certificate
Authorities）。此外，服务器也可以选择验证客户端的身份。比如，公司的代理服务器
可以验证所有雇员，每位雇员都应该有公司签发的独一无二的认证证书。

除了密钥协商和身份验证，TLS 协议还提供了自己的消息分帧机制，使用 MAC
（Message Authentication Code，消息认证码）签署每一条消息。MAC 算法是一个单
向加密的散列函数（本质上是一个校验和），密钥由连接双方协商确定。只要发送
TLS 记录，就会生成一个 MAC 值并附加到该消息中。接收端通过计算和验证这个
MAC 值来判断消息的完整性和可靠性。

上述三种机制为 Web 通信构建了一个安全的环境。所有现代 Web 浏览器都支持多
种加密套件，能够验证客户端和服务器，并能对每条记录进行消息完整性检查。

Web 代理、中间设备、TLS 与新协议

HTTP 良好的扩展能力和获得的巨大成功，使得 Web 上出现了大量代理和中间设
备：缓存服务器、安全网关、Web 加速器、内容过滤器，等等。有时候，我们知
道这些设备的存在（显式代理），而有时候，这些设备对终端用户则完全不可见。
然而，这些服务器的存在及成功也给那些试图脱离 HTTP 协议的人带了一些不便。
比如，有的代理服务器只会简单地转发自己无法解释的 HTTP 扩展或其他在线格
式（wire format），而有的则不管是否必要都会对所有数据执行自己设定的逻辑，
还有一些安全设备可能会把本来正常的数据误判成恶意通信。

换句话说，现实当中如果想脱离 HTTP 和 80 端口的语义行事，经常会遭遇各种部
署上的麻烦。比如，某些客户端表现正常，另一些可能就会异常，甚至在某个网
段表现正常的客户端到了另一个网段又会变得异常。

为解决这些问题，出现了一些新协议和对 HTTP 的扩展，比如 WebSocket、SPDY
等。这些新协议一般要依赖于建立 HTTPS 信道，以绕过中间代理，从而实现可靠
的部署，因为加密的传输信道会对所有中间设备都混淆数据。这样虽然解决了中
间设备的问题，但却导致通信两端不能再利用这些中间设备，从而与这些设备提
供的身份验证、缓存、安全扫描等功能失之交臂。

传输层安全（TLS） ｜ 43