Page 277 - Web性能权威指南
P. 277
• SSE 会给每个消息添加 5 字节，但仅限于 UTF-8 内容，参见 16.2 节“Event Stream
协议”。
• HTTP 1.x 请求（XHR 及其他常规请求）会携带 500~800 字节的 HTTP 元数据，
加上 cookie，参见 11.5 节“度量和控制协议开销”。
• HTTP 2.0 压缩 HTTP 元数据，这样可以显著减少开销，参见 12.3.8 节“首部压缩”。
事实上，如果请求都不修改首部，那么开销可以低至 8 字节！
记住，这里的开销数不包括 IP、TCP 和 TLS 分帧的开销，后者一共会给
每个消息增加 60~100 字节，无论使用的是什么应用协议，参见 4.7.4 节
“TLS 记录大小”。
17.3.3 数据效率及压缩
通过常规的 HTTP 协商，每个 XHR 请求都可以协商最优的传输编码格式（如对文
本数据采用 gzip 压缩）。类似地，SSE 局限于 UTF-8 文本数据，因此事件流数据可
以在整个会话期间使用 gzip 压缩。
而使用 WebSocket 时，情况要复杂一些：WebSocket 可以传输文本和二进制数据，
因此压缩整个会话行不通。二进制的净荷也可能已经压缩过了！为此，WebSocket
必须实现自己的压缩机制，并针对每个消息选择应用。
好在 HyBi 工作组正在为 WebSocket 协议制定以消息为单位的压缩扩展。只是这个
扩展尚未得到任何浏览器支持。因此，除非应用通过细致优化自己的二进制净荷实
现自己的压缩逻辑（参见 17.1.2 节的“使用 JavaScript 解码二进制数据”），同时也
针对文本消息实现自己的压缩逻辑，否则传输数据过程中一定会产生很大的字节
开销！
Chrome 和某些 WebKit 浏览器支持 WebSocket 协议压缩扩展的老版本
（以帧为单位压缩），参见 17.2.2 节“WebSocket 多路复用与压缩在现实中
的应用”。
17.3.4 自定义应用协议
浏览器是为 HTTP 数据传输而优化的，它理解 HTTP 协议，提供各种服务，比如认
证、缓存、压缩，等等。于是，XHR 请求自然而然就继承了所有这些功能。
相对来说，流式数据处理可以让我们在客户端和服务器间自定义协议，代价是错过
浏览器提供的很多服务：初次 HTTP 握手可以执行某些连接参数的协商，而一旦建
266 ｜ 第 17 章
