Page 253 - Web性能权威指南
P. 253
固定，否则长轮询的延迟总是最短的。如果延迟是一个重要考虑因素，那么长轮询
就是最好方案。
从另一方面看，还需要更仔细地分析一下开销。首先，每次更新都会伴有相同的
HTTP 开销，即每次更新都需要一次独立的 HTTP 请求。如果更新频率很高，那么
长轮询又会导致比定时轮询更多的 XHR 请求！
长轮询通过最小化延迟可以动态适应更新频率，这种行为可能是也可能不是我们所
期望的。如果应用可以容许一定时间的延迟，那么定时轮询可能更有效。因为在更
新频率很高的情况下，定时轮询就是一个简单的“更新累积”机制，不仅能减少请
求次数，还能减少对手机电量的消耗。
实践中，并不是所有更新都具有相同的优先级或者延迟要求。因此，你可
以考虑采取混合策略：在服务器上累积低优先级的更新，同时对高优先级
消息则立即触发更新（参见 8.2 节的“内格尔及有效的服务器推送”）。
Facebook 的 Chat 使用了 XHR 长轮询
实际应用中，长轮询已经成为通过 XHR 交付实时通知的一个使用最广泛的方法。
虽然这种方法不一定最有效，但它简单、可靠，在任何支持 XHR 的浏览器中通
用。Facebook 流行的 Chat 应用就在 2008 年率先采用了这个简单的方法：
为了让一个用户从另一个用户那里取得消息，我们采用了这个方法：在
每个 Facebook 页面中加载一个 iframe，让这个 iframe 中的 JavaScript 发
送一个 HTTP GET 请求，并保持连接打开，直到服务器把数据返回客户
端再关闭连接。如果连接中断或超时，则重新建立连接。这个方法并没
有使用任何新技术，它只是 Comet（尤其是 XHR 长轮询）及 BOSH 的
一种新用法。
——Facebook Chat
Facebook Engineering Blog
今天，通过 Server-Sent Events 和 WebSocket 可以更有效地实现同样的功能。即使
如此，XHR 仍然是很多实时通信框架的常用备选方案。如果所有技术都不能用，
那么只有让长轮询顶上了！
15.8 XHR使用场景及性能
XMLHttpRequest 是我们从在浏览器中做网页转向开发 Web 应用的关键。首先，它
让我们在浏览器中实现了异步通信，但同样重要的是，它还把这个过程变得非常简
240 ｜ 第 15 章
