如何实现Websockets？

Question

• 如何实施Websockets？
• 这项新技术背后的算法是什么（与Long-Polling相比）？
• 在表现方面，他们怎么能比Long-Polling更好？

我问这些问题是因为here we have a sample code of Jetty websocket implementation (server-side)。

  

如果我们等待足够长的时间，会发生超时，导致   在客户端上留言。

这肯定是我在使用长轮询时遇到的问题。它会停止进程以防止服务器过载，不是吗？

Answer 1

  

如何实施Websockets？

webSockets实现如下：

1. 客户端使用请求上的“upgrade”标头向服务器发出HTTP请求
2. 如果服务器同意升级，则客户端和服务器交换一些安全凭证，现有TCP套接字上的协议从HTTP切换到webSocket。
3. 现在有一个连接客户端和服务器的持久开放TCP套接字。
4. 任何一方都可以随时在此打开的套接字上发送数据。
5. 所有数据必须以非常具体的webSocket数据包格式发送。

因为只要双方都同意，套接字就会保持打开状态，这样服务器就会在有新内容发送时向客户端“推送”信息。这通常比使用客户端驱动的Ajax调用更有效，客户端必须定期轮询新信息。并且，如果客户端需要向服务器发送大量消息（可能类似于多玩家游戏），那么使用已经打开的套接字向服务器发送快速消息也比Ajax调用更有效。

由于启动了webSockets的方式（从HTTP请求开始然后重新调整该套接字），它们与现有的Web基础结构100％兼容，甚至可以在与现有Web请求相同的端口上运行（例如端口80或443）。这使得跨源安全性更加简单，并使客户端或服务器端基础结构上的任何人不必修改任何基础结构以支持webSocket连接。

  

这项新技术背后的算法是什么（与之相比）   长轮询）？

本文中有关于webSocket连接算法和webSocket数据格式如何工作的非常好的摘要：Writing WebSocket Servers。

  

在表现方面，他们怎么能比Long-Polling更好？

就其本质而言，长轮询是一种黑客行为。它的发明是因为发送给客户端的服务器启动的数据没有更好的选择。以下是步骤：

1. 客户端从客户端发出新数据的http请求。
2. 如果服务器有一些新数据，它会立即返回该数据，然后客户端发出另一个要求更多数据的http请求。如果服务器没有新数据，那么它只挂起连接一段时间而不提供响应，使请求保持挂起（套接字打开，客户端正在等待响应）。
3. 如果在请求仍处于暂挂状态的任何时间，服务器获取一些数据，则它将该数据形成一个响应并返回一个待处理请求的响应。
4. 如果暂时没有数据进入，那么最终请求将会超时。此时，客户端将意识到没有返回新数据，它将启动新请求。
5. 冲洗，起泡，重复。返回的每个数据或待处理请求的每个超时之后都是来自客户端的另一个ajax请求。

因此，虽然webSocket使用一个长期存在的套接字，客户端或服务器可以将数据发送到另一个，但长轮询包括客户端询问服务器“你还有更多数据吗？”一遍又一遍，每个都有一个新的http请求。

长时间轮询在正确完成后工作，它在服务器基础设施，带宽使用，移动电池寿命等方面效率不高......

  

我想要的是对此的解释：Websockets保持的事实   C / S之间的开放连接与Long Polling等待并不完全相同   处理？换句话说，为什么Websockets不会使服务器过载？

在客户端和服务器之间维护一个开放的webSocket连接是服务器做的一件非常便宜的事情（它只是一个TCP套接字）。一个不活动但开放的TCP套接字不占用服务器CPU，只占用很少的内存来跟踪套接字。正确配置的服务器一次可以容纳数十万个开放套接字。

另一方面，进行长轮询的客户端，即使没有新信息发送给它的客户端，也必须定期重新建立连接。每次重新建立新连接时，都会有一个TCP套接字拆除和新连接，然后是要处理的传入HTTP请求。

以下是关于缩放主题的一些有用的参考：

• 600k concurrent websocket connections on AWS using Node.js
• Node.js w/1M concurrent connections!
• HTML5 WebSocket: A Quantum Leap in Scalability for the Web
• Do HTML WebSockets maintain an open connection for each client? Does this scale?

Answer 2

关于网络套接字，长轮询和其他方法的非常好的解释：

In what situations would AJAX long/short polling be preferred over HTML5 WebSockets?

漫长投票 - 请求→等待→回复。像AJAX那样创建与服务器的连接，但保持活动连接打开一段时间（不长），在连接期间打开客户端可以从服务器接收数据。由于超时或数据eof，客户端必须在连接关闭后定期重新连接。在服务器端，它仍被视为与AJAX相同的HTTP请求，除了请求的答案现在或将来某个时间由应用程序逻辑定义。在所有主流浏览器中都受支持。

WebSockets - 客户端↔服务器。创建与服务器的TCP连接，并根据需要保留它。服务器或客户端可以轻松关闭它。客户端通过HTTP兼容的握手过程，如果成功，则服务器和客户端可以随时双向交换数据。如果应用程序需要在两种方式中频繁地进行数据交WebSockets确实有数据框架，包括屏蔽从客户端发送到服务器的每条消息，因此数据只是加密。支持图表（非常好）

总的来说，套接字比长轮询具有更好的性能，你应该使用它们而不是长轮询。