HTML5数据推送应用开发——1.7　决策、决策还是决策

前面两节从正反两方面探讨了数据拉取、SSE 和WebSocket，但怎么知道哪个更适用？这个问题很复杂，它是以应用的表现、用户对延迟的预期相关的商业决策、主机费用方面的商业决策以及用户和你的开发人员使用的技术为基础的。这里有一些你需要自行思考的问题。 • 服务端事件发生得有多频繁? 频率越高越适合用数据推送（不论SSE 还是WebSocket）。 • 客户端事件发生得有多频繁？ 如果事件触发的频率低于0.2 次/ 秒，尤其是低于1 次/ 秒，用WebSocket 比用SSE好。如果频率低于0.1 次/ 秒到0.2 次/ 秒左右，那用哪个都可以。 • 服务端事件是不是不但发生频率不高而且还发生在可预见的时刻？ 当这些事件的触发频率低于1 次/ 分钟，用数据拉取更好，因为它不需要保持一个套接口一直打开。需要注意大量客户端同时试图连接服务器的情况。 • 延迟问题有多关键？给个量化的数据。 半秒延迟是否会让用户烦躁？ 60 秒的延迟是否也不是什么问题？ 用户越介意延迟，数据推送比数据拉取就越有优势。 • 是否需要从服务端向客户端推送二进制数据？ 如果有大量的二进制数据，用WebSocket 比用SSE 更好（在这方面XHR 轮询也比SSE更好）。 如果是少量的二进制数据，可以对它进行编码，然后用SSE，区别（相对WebSocket）是会多几百字节。 • 是否需要从客户端向服务端推送二进制数据？ 用XMLHttpRequest10（比如Ajax，这是SSE 从客户端向服务端发送信息的方式）和用WebSocket 处理二进制数据没什么区别。 • 大部分的用户是用有线连接还是移动连接？ 使用LTE WiFi 路由器或者被限速的笔记本用户，视为移动连接用户；通过很强的WiFi连接到光纤上游连接的手机用户，视为有线连接用户。重要的是连接，而不是电脑性能或屏幕尺寸。 要知道，移动连接会有更多的延迟，尤其是当连接需要唤醒的时候。这使得在移动连接上使用数据拉取（轮询）方案比在有线连接上要糟糕。 同样，一个超载的WiFi 连接（比如在一个有很多人的咖啡馆）会丢失越来越多的数据包，其表现更像一个移动连接，而不是有线连接。 • 耗电量是否是移动用户关注的重点？ 需要在延迟和耗电量之间做出权衡。数据拉取（除非你知道数据什么时候出现，从而预知什么时候开始轮询）通常比数据推送（SSE 或WebSocket）要糟糕。 • 推送的数据是否相对来说比较小？ 一些3G 移动连接有一个专门的低电量模式，可以用来传输小数据（200 bit/s 到1000 bit/s）。但那不是重点，更重要的是一个大的消息会被分割成TCP/IP 片段发送，有一个片段丢失，就要重发。TCP 会确保按发送数据的顺序接收数据，所以这个丢失的数据包会阻碍整个数据的处理，同时也会阻塞后面数据的接收。所以，在不稳定的连接中（比如，移动连接，超载的WiFi 连接），发送的数据越大，需要发送的额外数据包就越多。 考虑一下用数据推送作为控制通道，告诉浏览器直接请求大文件，浏览器很有可能用自己的套接字处理，因此不会阻塞数据推送套接口（这之所以存在，是因为你认为延迟问题很重要）。 • 数据推送是Web 应用的次要特性还是主要特性？是否有开发者资源的短缺？ SSE 用起来简单，而且是简洁地运行在现有的基础设施上，比如Apache。这就节省了测试时间。项目越大，你拥有的开发人员越多，这个问题就越不重要。 想了解更多关于前面几节中讨论的技术细节，尤其是当效率和处理高负载是你首要关心的问题，我强烈推荐你看看Ilya Grigorik 写的《Web 性能权威指南》（人民邮电出版社）。 注10： 严格来说，XMLHttpRequest 的第2 版，参见http://caniuse.com/xhr2，IE9 以及更早的版本和Android 2.x都还没支持，但那些支持WebSocket 和SSE 的浏览器也没有，所以也不影响决策。