Page 249 - Web性能权威指南

• 读取完部分数据后，我们必须自己标识数据的界限：应用代码必须定义自己的数
据格式，然后再缓冲并解析数据流，提取出相应的信息。
• 浏览器缓冲收到数据的方式也不相同：有的会立即释放，而有的只缓冲小响应，
对较大的响应块则立即释放。
• 浏览器允许递增读取的数据类型也不一样：有的允许 text/html，而有的只允许
application/x-javascript。

简言之，目前基于 XHR 的流实现起来既麻烦，效率又低。更糟糕的是，由于缺
乏规范，浏览器实现一家一个样。结论就是，在 Streams API 规范正式推出之前，
XHR 并不适合用来实现流式数据处理。

没有必要失望！虽然 XHR 满足不了我们的要求，我们还有其他办法，而
且是专门为流式数据处理设计的：Server-Sent Events 提供方便的流 API，
用于从服务器向客户端发送文本数据，而 WebSocket 则提供了高效、双向
的流机制，而且同时支持二进制和文本数据。

专有API和对XHR流的扩展
Firefox 和 Internet Explorer 都提供了定制的“XHR 流扩展”：

• Firefox 支持 moz-chunked-text 和 moz-chunked-arraybuffer；
• Internet Explorer 支持 ms-stream。

通过将 XHR 对象上的 responseType 属性设置为前述数据类型，这两个浏览器就可
以不缓冲整个响应，同时允许通过 XHR 对象递增地读取二进制响应。遗憾的是，
Chrome、Opera 及其他主流浏览器还没有类似的 API。因此，XHR 流对于跨浏览器
应用来说，仍然不可行。

15.7 实时通知与交付

XHR 提供了一种简单有效的客户端与服务器同步的方式：必要时，客户端可以向服
务器发送一个 XHR 请求，以更新服务器上的相应数据。然而，实现同样但相反的
操作却要困难一些。如果服务器的数据更新了，那怎么通知客户端呢？

HTTP 没有提供服务器向客户端发起连接的方式。因此，为实时接收通知，客户端
要么必须轮询服务器，要么就得利用流式传输让服务器推送通知。如前所述，主流
浏览器对 XHR 流的支持有限，那我们就只能使用 XHR 轮询了。

236 ｜ 第 15 章