HTML5数据推送应用开发——1.5　和WebSocket的对比

你可能听说过另一种叫做WebSocket 的HTML5 技术，它也能从服务端向客户端推送数据。那如何决定你是用SSE 还是WebSocket 呢？概括来说，WebSocket 能做的，SSE 也能做，反之亦然，但在完成某些任务方面，它们各有千秋。 WebSocket 是一种更为复杂的服务端实现技术，但它是真正的双向传输技术，既能从服务端向客户端推送数据，也能从客户端向服务端推送数据。 WebSocket 和SSE 的浏览器支持率差不多，大多数主流桌面浏览器两者都支持5。在Android 4.3 以及更早的版本中，系统默认浏览器两者都不支持，Firefox 和Chrome 则完全支持；Android 4.4 中，系统默认浏览器两者都支持；Safari 从5.0 开始支持SSE（iOS 系统从4.0 开始），但直到6.0 才正确地支持WebSocket（6.0 之前的Safari 所实现的WebSocket协议存在安全问题，所以一些主流浏览器已经禁用了基于这个协议的实现）。 与WebSocket 相比，SSE 有一些显著的优势。我认为它最大的优势就是便利：不需要添加任何新组件，用任何你习惯的后端语言和框架就能继续使用。你不用为新建虚拟机、弄一个新的IP 或新的端口号而劳神，就像在现有网站中新增一个页面那样简单。我喜欢把这称为既存基础设施优势。 SSE 的第二个优势是服务端的简洁。我们将在第2 章中看到，服务端代码只需几行。相对而言，WebSocket 则很复杂，不借助辅助类库基本搞不定（我试过，令人痛苦）。 因为SSE 能在现有的HTTP/HTTPS 协议上运作，所以它能直接运行于现有的代理服务器和认证技术。而对WebSocket 而言，代理服务器需要做一些开发（或其他工作）才能支持，在写这本书时，很多服务器还没有（虽然这种状况会改善）。SSE 还有一个优势：它是一种文本协议，脚本调试非常容易。事实上，在本书中，我们会在开发和测试时用curl，甚至直接在命令行中运行后端脚本。 不过，这就引出了WebSocket 相较SSE 的一个潜在优势：WebSocket 是二进制协议，而SSE 是文本协议（通常使用UTF-8 编码）。当然，我们可以通过SSE 连接传输二进制数据：在SSE 中，只有两个具有特殊意义的字符，它们是CR 和LF，而对它们进行转码并不难。但用SSE 传输二进制数据时数据会变大，如果需要从服务端到客户端传输大量的二进制数据，最好还是用WebSocket。 二进制数据和二进制文件 如果你正打算通过WebSocket 或SSE 传输二进制文件，停下来想想是否真的需要这么做。用HTTP 不是更好吗？免得重复造轮子（权限控制、加密、代理、缓存、长连接，等等）。如果你关心的是连接套接字的有效使用，好好看看HTTP/2.06。 我说“大量的二进制数据”意思是你需要在浏览器中实现一个二进制网络协议，比如SSH。如果只是想向用户推送一个新的横幅广告图片，最好的方式是通过SSE（或者WebSocket）推送图片的URL，然后让浏览器通过HTTP 获取图片。 WebSocket 相较SSE 最大的优势在于它是双向交流的，这意味向服务端发送数据就像从服务端接收数据一样简单。用SSE 时，一般通过一个独立的Ajax 请求从客户端向服务端传送数据。相对于WebSocket，这样使用Ajax 会增加开销，但也就多一点点而已7。如此一来，问题就变成了“什么时候需要关心这个差异？”如果需要以1 次/ 秒或者更快的频率向服务端传输数据，那应该用WebSocket。0.2 次/ 秒到1 次/ 秒的频率是一个灰色地带，用WebSocket 和用SSE 差别不大；但如果你期望重负载，那就有必要确定基准点。频率低于0.2 次/ 秒左右时，两者差别不大。 从服务端向客户端传输数据的性能如何？如果是文本数据而非二进制数据（如前文所提到的），SSE 和WebSocket 没什么区别。它们都用TCP/IP 套接字，都是轻量级协议。延迟、带宽、服务器负载等都没有区别，除非……呃？除非什么？ 当你在享用SSE 的既存基础设施优势，并在客户端和服务端脚本之间设了一个网络服务器，区别就显现出来了。一个SSE 连接不仅使用一个套接字，还会占用一个Apache 线程或进程，如果用PHP，它会为这个连接专门创建一个PHP 新实例。Apache 和PHP 会使用大量的内存，这会限制服务器所能支持的并行连接数。所以，要做到用SSE 在数据传输性能上和WebSocket 完全一样，需要写一个你自己的后端服务器，当然，那些在任何情况下都会用自己的服务器并使用Node.js 的人，会觉得这有什么稀奇的。第2 章会介绍怎么用Node.js 来做这些。 说一下WebSocket 在旧版本浏览器上的兼容。写这本书的时候，大约超过2/3 的浏览器支持这些新技术，移动端浏览器的支持率会低一些。依惯例，每当需要双向套接字时，就会用到Flash，并且WebSocket 的向后兼容通常是用Flash 来做，这已经相当复杂了，如果浏览器上没有Flash，情况更糟。概括来说，WebSocket 难兼容，SSE 易兼容。 注4： Kickstarter 是一个创意方案的众筹网站平台。—译者注 注5： IE 是个例外，即便IE11 都还不支持原生SSE，IE10 添加了WebSocket 支持。 注6： 参见http://en.wikipedia.org/wiki/HTTP_2.0，或者Ilya Grigorik 写的《Web 性能权威指南》（人民邮电出版社）。 注7： 在HTTP/1.1 中大概几百字节，如果请求中有大量的cookie 或其他东西，这个量会更多一些。在HTTP/2.0 中会少很多。