Page 278 - Web性能权威指南
P. 278
立会话，所有后续客户端与服务器间的数据流对浏览器都将是不透明的。这样来看，
自定义应用协议的灵活性也有缺点，应用可能必须实现自已的逻辑来填充某些功能
空白，比如缓存、状态管理、元数据交付，等等。
初始的 HTTP Upgrade 握手可以让服务器利用既有的 HTTP cookie 机制来
验证用户。如果验证失败，服务器可以拒绝 WebSocket 升级。
利用浏览器和中间设备的缓存
使用常规 HTTP 有很多明显的优势。问自己一个简单的问题：客户端会不会因缓
存接收到的数据而受益？或者中间设备如果缓存数据，是否可以优化对该数据的
交付？
举个例子，WebSocket 支持二进制传输，因此应用可以流式传输任意图片而没有
开销！然而，由于图片是采用自定义协议交付的，它不会被保存到浏览器或任何
中间设备（如 CDN）的缓存中。结果，就可能给客户端造成不必要的下载，给来
源服务器带来相当高的流量。同样的道理也适用于视频、文本等数据格式。
因此，要根据应用选择合适的传输机制！一个简单但有效的策略，就是使用
WebSocket 交付无需缓存的数据，如实时更新和应用“控制”消息，后者再触发
XHR 请求通过 HTTP 协议取得其他资源。
17.3.5 部署WebSocket基础设施
HTTP 是专为短时突发性传输设计的。于是，很多服务器、代理和其他中间设备的
HTTP 连接空闲超时设置都很激进。而这显然是我们在持久的 WebSocket 会话中所
不愿意看到的。为解决这个问题，要考虑三个方面：
• 位于各自网络中的路由器、负载均衡器和代理；
• 外部网络中透明、确定的代理服务器（如 ISP 和运营商的代理）；
• 客户网络中的路由器、防火墙和代理。
我们没有权限控制客户网络的策略。事实上，某些网络甚至会完全屏蔽 WebSocket
通信，而这正是必须有备用机制的原因。类似地，我们也没有权限控制外部网络
中的代理。可是，这里可以借助 TLS ！通过建立一条端到端的加密信道，可以让
WebSocket 通信绕过所有中间代理。
使用 TLS 不会阻止中间设备超时断开空闲的 TCP 连接。可是，实践中，
WebSocket 会话协商的成功率越来越高，这样也有助于增加连接超时的
间隔。
WebSocket ｜ 267
