Page 264 - Web性能权威指南
P. 264
为简化跨浏览器部署，SockJS 等流行的库都提供了类似 WebSocket 对象的实现，
并更进一步实现了支持 WebSocket 的自定义服务器，以及各种备用传输方案。自
定义服务器和客户端构成了所谓的“无缝备用”：性能虽然差强人意，但应用的
API 不变。
其他库，比如 Socket.IO 走得甚至更远，除提供多套后备传输机制，还实现了心
跳检测、超时、自动重连等功能。
在选择 Socket.IO 这样的腻子脚本或“实时框架”时，一定要留心其底层实现，
以及客户端和服务器的配置：保证尽可能利用原生 WebSocket 接口以求最佳性能，
然后确保备用传输机制能满足你的性能要求。
17.1.1 WS与WSS
WebSocket 资源 URL 采用了自定义模式：ws 表示纯文本通信（如 ws://example.
com/socket），wss 表示使用加密信道通信（TCP+TLS）。为什么不使用 http 而要自
定义呢？
WebSocket 的主要目的，是在浏览器中的应用与服务器之间提供优化的、双向通信机
制。可是，WebSocket 的连接协议也可以用于浏览器之外的场景，可以通过非 HTTP
协商机制交换数据。考虑到这一点，HyBi Working Group 就选择采用了自定义的
URL 模式。
使用自定义的 URL 模式虽然让非 HTTP 协商成为可能，但实践中还没有既
定标准可以作为建立 WebSocket 会话的替代握手机制。
17.1.2 接收文本和二进制数据
WebSocket 通信只涉及消息，应用代码无需担心缓冲、解析、重建接收到的数据。比
如，服务器发来了一个 1 MB 的净荷，应用的 onmessage 回调只会在客户端接收到全
部数据时才会被调用。
此外，WebSocket 协议不作格式假设，对应用的净荷也没有限制：文本或者二进制数
据都没问题。从内部看，协议只关注消息的两个信息：净荷长度和类型（前者是一
个可变长度字段），据以区别 UTF-8 数据和二进制数据。
浏览器接收到新消息后，如果是文本数据，会自动将其转换成 DOMString 对象，如
果是二进制数据或 Blob 对象，会直接将其转交给应用。唯一可以（作为性能暗示和
优化措施）多余设置的，就是告诉浏览器把接收到的二进制数据转换成 ArrayBuffer
而非 Blob：
WebSocket ｜ 253
