websocket 拒绝连接原因_Web应用架构WebSocket用例，性能和性能检查列表

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来说，“低