WebSocket API为客户机和服务器之间的文本和二进制数据的双向、面向消息流提供了一个简单的接口:向构造函数传递一个WebSocket URL，设置几个JavaScript回调函数，然后我们就启动并运行了——其余的由浏览器处理。再加上WebSocket协议，它提供了二进制帧、可扩展性和子协议协商，WebSocket成为在浏览器中交付定制应用协议的完美工具。
然而，就像任何关于性能的讨论一样，尽管WebSocket协议的实现复杂性对应用程序是隐藏的，但它仍然对如何以及何时使用WebSocket有重要的性能暗示。WebSocket不是XHR或SSE的替代品，为了获得最佳性能，我们必须充分利用每种传输的优势!
要查看每个传输的性能特征，请参考XHR用例和性能以及SSE用例和性能。
请求和响应流
WebSocket是唯一允许在同一个TCP连接上进行双向通信的传输(图17-2):客户端和服务器可以随意交换消息。因此，WebSocket在两个方向上都提供了文本和二进制应用程序数据的低延迟交付。
图17-2。XHR, SSE, WebSocket的通信流程
XHR为“事务性”请求-响应通信进行了优化:客户机向服务器发送完整的、格式良好的HTTP请求，服务器以完整的响应响应。不支持请求流，在Streams API可用之前，没有可靠的跨浏览器响应流API。
SSE实现了基于文本数据的高效、低延迟的服务器到客户端的流化:客户端启动SSE连接，服务器使用事件源协议将更新流化到客户端。在初始握手之后，客户端不能向服务器发送任何数据。
传播和排队延迟
交换从XHR到SSE或WebSocket的传输不会减少客户端和服务器之间的往返!无论传输方式如何，数据包的传播延迟都是相同的。然而，除了传播延迟之外，还有排队延迟:消息在被路由到另一方之前必须在客户机或服务器上等待的时间。
在XHR轮询的情况下，排队延迟是客户端轮询间隔的函数:消息可能在服务器上可用，但直到下一个客户端XHR请求才能发送;请参阅XHR轮询的建模性能。相比之下，SSE和WebSocket都使用一个持久连接，这允许服务器在消息可用的时候就发送消息(以及客户端，在WebSocket的情况下)。
因此，对于SSE和WebSocket来说，“低延迟交付”是指消除消息排队延迟。我们还没有想出如何让WebSocket数据包的传输速度超过光速!
消息开销
一旦WebSocket连接建立，客户端和服务器通过WebSocket协议交换数据:应用消息被分成一个或多个帧，每个帧增加2到14字节的开销。而且，由于框架是通过自定义二进制格式完成的，因此UTF-8和二进制应用程序数据都可以通过相同的机制进行有效编码。与XHR和SSE相比如何?
SSE只增加了5字节的每条消息，但仅限于UTF-8内容;参见事件流协议。
HTTP / 1。x请求(XHR或其他)将携带额外的500-800字节HTTP元数据，加上cookie;参见测量和控制协议开销。
HTTP/2压缩HTTP元数据，这大大降低了开销;看到标题压缩。事实上，如果头在请求之间不改变，开销可以低至8字节!
请记住，这些开销数字不包括IP、TCP和TLS帧的开销，这些开销会增加每条消息60-100字节的综合开销，而与应用程序协议无关;参见优化TLS记录大小。
数据效率和压缩
每个XHR请求可以通过定期的HTTP协商来协商最佳的传输编码格式(例如，基于文本的数据的gzip)。类似地，由于SSE仅限于utf -8传输，所以可以通过在整个会话中应用gzip有效地压缩事件流数据。
使用WebSocket，情况会更加复杂:WebSocket可以传输文本和二进制数据，因此压缩整个会话没有意义。二进制有效负载可能已经被压缩了!因此，WebSocket必须实现自己的压缩机制，并有选择地将其应用于每个消息。
好消息是HyBi工作组正在为WebSocket协议开发每消息压缩扩展。然而，它还没有在任何浏览器中可用。因此，除非应用程序通过仔细优化其二进制有效负载(参见用JavaScript解码二进制数据)来实现自己的压缩逻辑，并为基于文本的消息实现自己的压缩逻辑，否则它可能会对传输的数据产生较高的字节开销!
Chrome和一些基于webkit的浏览器支持WebSocket协议压缩扩展的旧版本(每帧压缩);参见WebSocket多路复用和压缩。
自定义应用程序协议
浏览器针对HTTP数据传输进行了优化:它理解该协议，并提供广泛的服务，如身份验证、缓存、压缩等等。因此，XHR请求免费继承所有这些功能。
相比之下,流允许我们提供定制的客户端和服务器之间的协议,但代价的绕过许多浏览器提供的服务:最初的HTTP握手可以执行一些协商参数的连接,但是一旦建立了会话,所有进一步的客户端和服务器之间的数据流是不透明到浏览器。因此，交付自定义协议的灵活性也有其缺点，应用程序可能必须实现自己的逻辑来填补缺失的空白:缓存、状态管理、消息元数据的交付，等等!
初始的HTTP升级握手允许服务器利用现有的HTTP cookie机制来验证用户。如果验证失败，服务器可以拒绝WebSocket升级。
利用浏览器和中间缓存
使用常规HTTP具有显著的优势。问您自己一个简单的问题:客户机会从缓存接收到的数据中获益吗?或者，如果中介可以缓存资产，它是否可以优化资产的交付?
例如，WebSocket支持二进制传输，这允许应用程序流任意的图像格式而没有开销——好漂亮!然而，图像是在自定义协议中交付的这一事实意味着它不会被浏览器缓存或任何中介(例如CDN)缓存。因此，您可能需要向客户机进行不必要的传输，并向源服务器传输更多的流量。同样的逻辑也适用于所有其他数据格式:视频、文本等等。
因此，确保你为工作选择了合适的交通工具!解决这些问题的一个简单而有效的策略是使用WebSocket会话来传递非缓存数据，比如实时更新和应用“控制”消息，这可以触发XHR请求来通过HTTP协议获取其他资产。
部署WebSocket基础设施
HTTP为短时间和突发传输进行了优化。因此，许多服务器、代理和其他中介经常被配置为主动超时空闲HTTP连接，当然，这正是我们不希望看到的长时间WebSocket会话。为了解决这个问题，有三方面需要考虑:
路由器，负载平衡器，和代理在自己的网络
外部网络中的透明和显式代理(如ISP和运营商代理)
客户网络中的路由器、防火墙和代理
我们无法控制客户端网络的策略。事实上，一些网络可能会完全阻止WebSocket流量，这就是为什么您可能需要一个备用策略。类似地，我们无法控制外部网络上的代理。然而，这正是TLS可以帮助的地方!通过在安全的端到端连接上使用隧道，WebSocket通信可以绕过所有的中间代理。
使用TLS并不会阻止中间层对空闲TCP连接计时。然而，在实践中，它极大地提高了协商WebSocket会话的成功率，并且通常还有助于扩展连接超时间隔。
最后，还有我们自己部署和管理的基础设施，这通常也需要关注和调优。尽管责怪客户端或外部网络很容易，但问题往往是在家里。服务路径中的每个负载均衡器、路由器、代理和web服务器都必须进行调优，以允许长时间连接。
例如，Nginx 1.3.13+可以代理WebSocket流量，但默认为60秒超时!为了增加限制，我们必须明确地定义较长的超时:
location /websocket {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600;
proxy_send_timeout 3600;
}设置读取间隔60分钟的超时时间
在写之间设置60分钟的超时时间
类似地，在一个或多个Nginx服务器前安装一个负载均衡器也很常见，比如HAProxy。毫不奇怪，我们在这里也需要应用类似的显式配置。HAProxy,因为:
defaults http
timeout connect 30s
timeout client 30s
timeout server 30s
timeout tunnel 1h隧道的60分钟不活动超时
前面示例的问题是额外的“隧道”超时。在HAProxy中，连接、客户端和服务器的超时只适用于初始的HTTP升级握手，但是一旦升级完成，超时由隧道值控制。
Nginx和HAProxy只是在我们的数据中心运行的数百个不同的服务器、代理和负载平衡器中的两个。我们不能列举这些页面中所有的配置可能性。前面的示例只是说明了大多数基础设施需要自定义配置来处理长期存在的会话。因此，在实现应用程序保持生命值之前，首先要仔细检查基础设施。
长期会话和空闲会话占用所有中间服务器上的内存和套接字资源。因此，短超时通常被认为是安全、资源和操作方面的预防措施。部署WebSocket、SSE和HTTP/2(它们都依赖于长寿命会话)带来了各自的新操作挑战。
性能检查表
部署高性能WebSocket服务需要在客户端和服务器端进行仔细的调优和考虑。列入议程的标准的简短清单:
使用安全的WebSocket (WSS over TLS)进行可靠的部署。
密切关注polyfill 的性能(如有必要)。
利用子协议协商来确定应用程序协议。
优化二进制有效载荷以最小化传输大小。
考虑压缩UTF-8内容以最小化传输大小。
为接收到的二进制有效负载设置正确的二进制类型。
监视客户机上缓冲的数据量。
分割大型应用程序消息以避免线头阻塞。
在适用的情况下利用其他传输。
最后，但绝对不是最不重要的，优化移动!在手机上，实时推送可能是一个代价高昂的性能反模式，因为电池寿命总是非常宝贵。这并不是说WebSocket不应该在移动设备上使用。相反，它可以是一种高效的交通工具，但一定要考虑到它的要求:
保护电池
消除周期性和低效的数据传输
高效的服务器推送
消除不必要的应用程序保持活动