这里有很多关于websocket的信息。毫无疑问，这项技术本身是惊人的。在我开始在我的应用程序中使用它们之前，我只想让社区回答以下问题：
"。。。为了保持存在，应用程序可以在WebSocket上发送保持活动的消息，以防止它因空闲超时而关闭"
"。。。理想情况下，WebSocket的未来版本将支持超时发现，因此它可以告诉应用程序保持活动消息的周期"
-
这感觉似曾相识。早些时候，我们不得不在%period_time%轮询服务器一次，以获得所需的更新信息。对于websocket，我们必须使用保持活动消息每隔%period_time%轮询websocket服务器一次，以确保互联网连接仍然有效/websocket服务仍然工作。利润是多少？
关于这些保持活力的信息还有另一件事。Websocket协议的优点是使用比HTTP（S）更少的流量。如果我们发送保活信息，流量优势似乎就消失了。或者可能没有？
-
如果我使用websockets，我应该如何处理应用程序中互联网的丢失？我指的是互联网连接突然断开时的真实情况（我的意思是没有发生"navigator.online"事件）。我应该使用某种setTimeout函数来查找保持活动的消息吗？或者有更好的方法来处理这种情况吗？
-
REST让我们清楚地了解了应用程序应该如何工作以及请求应该是什么样子。在支持websocket的应用程序中，最好的方法是什么？我应该只拥有（比如）带有request.action字段的JSON编码消息吗？应用程序应该如何执行PUT请求？REST模型中有URL资源来处理这个问题，所以我应该使用这些方法的组合吗？或者可能有smth simpler吗？
我认为您的大多数问题都可以通过理解WebSockets的真正用途来澄清。WebSockets的主要设计目的并不是取代任何已经就位并且运行良好的东西。例如，它并没有被设计成AJAX的低开销版本。目的是在浏览器和服务器之间提供双向、低延迟、全双工的通信通道。它的真正目的是启用web应用程序的一个新领域，或者改进当前滥用HTTP来实现双向通信的应用程序。
考虑到这一点，让我评论一下你的要点：
-
定期WebSockets乒乓消息的目的有两个：防止通道因TCP超时而关闭，并更快地检测通道何时关闭（这在历史上是TCP的弱点）。HTTP/AAJAX轮询的目的是绕过HTTP不是双向的这一事实（即客户端轮询为服务器提供发回数据的机会）。WebSocket乒乓帧通常为2字节长。HTTP/AAJAX轮询需要完整的标头、cookie等，每个请求/响应的总大小可以轻松超过千字节。即使你通过WebSockets每秒发送10次乒乓球，你仍然不太可能与每2秒HTTP/AAJAX轮询的开销相比。但是，请注意，应用程序不具备发送乒乓消息的能力。这是在浏览器和服务器之间。
-
如果您失去了Internet连接，您将收到一个onclose事件。如果您的浏览器没有为您发送乒乓球消息，那么在网络连接断开后尝试发送消息之前，您可能不会收到onclose。
-
我不会用WebSockets取代一个正在工作的RESTful服务。您将做大量的映射工作，但可能收效甚微（同样，WebSockets并不是为了取代已经运行良好的东西而设计的）。我可以设想这样的情况：REST用于状态传输，WebSockets用于事件通知。例如，服务器发送一条WebSocket消息，指示"发生了更改"，从而触发客户端执行REST请求以查找更改。
更新：
澄清：您可以在WebSockets上执行REST，但这在哲学上是不匹配的。REST是一种对底层传输系统没有意见的体系结构风格。它是一个受约束的体系结构："客户端-服务器"、"无状态"、"可缓存"、"分层系统"、"按需代码"one_answers"统一接口"。WebSockets不受这些约束；它是一个通用的消息传输系统。你可以将WebSockets限制为RESTful，但在你深入了解REST和WebSockets并确定何时这样做是正确的之前，不要这样做
我在太空船动作游戏中使用了websocket来支持多人游戏。Websockets是一项非常酷的技术，但我也发现它令人沮丧地不可预测——这可能只是我作为一个新手犯了一些错误。如果我解决了更多的错误，我可能会放一个链接，但它崩溃得太多了，所以我现在没有在实时服务器上使用它。
我想这将使它成为一款不适合生产的应用程序，但假设我不明白为什么其他更有经验的人会做得不好。