Page 272 - Web性能权威指南

并确认要在商定连接中使用的扩展。下面我们就来看一个 Upgrade 的例子。

WebSocket 多路复用与压缩在现实中的应用
截止到 2013 年年中，WebSocket 的多路复用还没有得到任何主流浏览器支持。类
似地，对压缩扩展的支持也很有限：谷歌 Chrome 和最新的 WebKit 浏览器可能会
向服务器发送“x-webkit-deflate-frame”扩展。然而这个 deflate-frame 是基于该标
准的过时版本实现的，将来可能会被抛弃。

压缩扩展的早期版本是“逐帧”压缩，这对要分成多个帧的大消息显然不是最佳
方法。最新版本已经修改为以消息为单位压缩，这是好消息。坏消息是，以消息
为单位压缩还是实验性的，目前尚未得到主流浏览器支持。

结果，就是应用需要密切关注传输的数据类型，并在可行的情况下采用自己的压
缩方案。换句话说，至少在所有主流浏览器原生支持 WebSocket 之前，你要考虑
这个方案。这对移动应用尤为重要，因为移动应用中的每个字节都可能给用户带
来不必要的成本。

17.2.3 HTTP升级协商

WebSocket 协议提供了很多强大的特性：基于消息的通信、自定义的二进制分帧层、
子协议协商、可选的协议扩展，等等。换句话说，在交换数据之前，客户端必须与
服务器协商适当的参数以建立连接。
利用 HTTP 完成握手有几个好处。首先，让 WebSockets 与现有 HTTP 基础设施兼
容：WebSocket 服务器可以运行在 80 和 443 端口上，这通常是对客户端唯一开放
的端口。其次，让我们可以重用并扩展 HTTP 的 Upgrade 流，为其添加自定义的
WebSocket 首部，以完成协商。

• Sec-WebSocket-Version
客户端发送，表示它想使用的 WebSocket 协议版本（“13”表示 RFC 6455）。如
果服务器不支持这个版本，必须回应自己支持的版本。

• Sec-WebSocket-Key
客户端发送，自动生成的一个键，作为一个对服务器的“挑战”，以验证服务器
支持请求的协议版本。

• Sec-WebSocket-Accept
服务器响应，包含 Sec-WebSocket-Key 的签名值，证明它支持请求的协议版本。

WebSocket ｜ 261