Page 275 - Web性能权威指南
P. 275
解决之道？建立一条端到端的安全通道。比如，使用 WSS ！在执行 HTTP
Upgrade 握手之前，先协商一次 TLS 会话，在客户端与服务器之间建立一条加密
通道，就可以解决前述所有问题。这个方案尤其适合移动客户端，因为它们的流
量经常要穿越各种代理服务，这些代理服务很可能不认识 WebSocket。
17.3 WebSocket使用场景及性能
WebSocket API 提供一个简单的接口，能够在客户端与服务器之间实现基于消息
的双向通信，可以是文本数据，可以是二进制数据： 把 WebSocket URL 传递给构
造函数，设置几个 JavaScript 回调函数，就好了——剩下的就全都由浏览器负责
了。再加上 WebSocket 协议提供的二进制分帧、可扩展性以及子协议协商，使得
WebSocket 成为在浏览器中采用自定义应用协议的最佳选择。
不过，就跟以前关于性能的讨论一样，虽然 WebSocket 协议的实现复杂性对应
用隐藏了，但何时以及如何使用 WebSocket，毋庸置疑会对性能产生巨大影响。
WebSocket 不能取代 XHR 或 SSE，而要获得最佳性能，我们必须善于利用它的
长处！
请参考 15.8 节“XHR 使用场景及性能”和 16.3 节“SSE 使用场景及性
能”，以了解各种传输机制的性能特点。
17.3.1 请求和响应流
WebSocket 是唯一一个能通过同一个 TCP 连接实现双向通信的机制（图 17-2），客
户端和服务器随时可以交换数据。因此，WebSocket 在两个方向上都能保证文本和
二进制应用数据的低延迟交付。
• XHR 是专门为“事务型”请求 / 响应通信而优化的：客户端向服务器发送完整
的、格式良好的 HTTP 请求，服务器返回完整的响应。这里不支持请求流，在
Streams API 可用之前，没有可靠的跨浏览器响应流 API。
• SSE 可以实现服务器到客户端的高效、低延迟的文本数据流：客户端发起 SSE 连
接，服务器使用事件源协议将更新流式发送给客户端。客户端在初次握手后，不
能向服务器发送任何数据。
264 ｜ 第 17 章
