问题描述
嗯，有很多关于 websockets 的信息.技术本身是惊人的，这一点是毫无疑问的.在我开始在我的应用程序中使用它们之前，我只希望社区回答这些问题:
Well, there's a lof of information about websockets. The technology itself is amazing, there's no doubt in this fact. And before i will start using them in my app i just want the community to answer these questions:
...为了保持在线状态，应用程序可以在 WebSocket 上发送 keep-alive 消息，以防止它因空闲超时而被关闭..."
……理想情况下，WebSocket 的未来版本将支持超时发现，因此它可以告诉应用程序保持活动消息的周期……"
"...ideally a future version of WebSocket will support timeout discovery, so it can either tell the application the period for keep-alive messages..."
这感觉就像似曾相识.早些时候，我们不得不每隔 %period_time% 轮询一次服务器以获取所需的更新信息.使用 websockets，我们必须使用 keep-alive 消息 每隔 %period_time% 轮询一次 websocket 服务器，以确保互联网连接仍然有效/websocket 服务器仍在工作.利润是多少?
This feels like deja vu. Earlier we had to poll the server once a %period_time% to get the needed updated information. With websockets we have to poll the websocket server once a %period_time% with keep-alive messages to make sure the internet connection is still alive / the websocket server is still working. What's the profit?
关于这些保持活动的消息的另一件事.Websocket 协议的优势在于使用的流量比 HTTP(S) 少.如果我们发送 keep-alive 消息，流量优势似乎就消失了.或者也许不是?
And another thing regarding these keep-alive messages. Websocket protocol has an advantage of using less traffic than HTTP(S). If we send keep-alive messages, it seems like the traffic advantage dissapears. Or maybe not?
如果我使用 websockets，我应该如何处理我的应用程序中的网络中断?我的意思是互联网连接突然丢失时的真实情况(我的意思是没有发生navigator.offline"事件).我应该使用某种 setTimeout 函数来查找保持活动的消息还是有更好的方法来处理这种情况?
How should i handle the loss of internet in my app if i use websockets? I mean the real situation when the internet connection is suddenly lost (i mean no "navigator.offline" event has happened). Should i use some kind of setTimeout-function to look for keep-alive messages or is there a better way to handle this situation?
REST 让我们清楚地了解应用程序的工作方式以及请求的外观.在 websocket 驱动的应用程序中执行此操作的最佳方法是什么?我应该只拥有(比如说)带有 request.action 字段的 JSON 编码消息吗?应用程序应该如何执行 PUT 请求?REST 模型中有 URL 资源来处理这个问题，所以我应该使用这些方法的组合还是可能更简单?
REST gives us a clear understanding of how an app should work and how the requests should look like. What's the best way of doing this in websocket-powered apps? Should i just have (say) JSON-encoded messages with request.action field it it? And how should the app perform PUT-requests? There are URL-resources in REST model to handle this, so should i use combination of these approaches or maybe is there smth simplier?
推荐答案
我认为通过了解 WebSockets 的真正目的，您的大部分问题都可以得到澄清.WebSockets 的主要目的不是为了替换任何已经存在且运行良好的东西.例如，它不是设计为 AJAX 的低开销版本.目的是在浏览器和服务器之间提供双向、低延迟、全双工的通信通道.它的真正目的是启用一个新的 Web 应用程序域或改进当前滥用 HTTP 以实现双向通信的应用程序.
I think most of your questions can be clarified by understanding the real purpose of WebSockets. WebSockets was not primarily designed to replace any of the the things that are already in place and working well. For example, it was not designed to be a low-overhead version of AJAX. The purpose is to provide a bidirectional, low latency, full duplex, communication channel between the browser and server. It's real purpose is to enable a new domain of web applications or to improve current ones that are abusing HTTP to achieve bidirectional communication.
考虑到这一点，让我评论您的要点:
With that in mind let me comment on your bullet points:
定期 WebSockets ping/pong 消息的目的有两个:防止通道因 TCP 超时而关闭，以及更快地检测通道何时关闭(这在历史上是 TCP 的弱点).HTTP/AJAX 轮询的目的是绕过 HTTP 不是双向的这一事实(即客户端轮询以给服务器发送数据的机会).WebSocket ping/pong 帧的长度通常为 2 个字节.HTTP/AJAX 轮询需要完整的标头、cookie 等，对于每个请求/响应，这些信息的总数很容易超过 1 千字节.即使您每秒通过 WebSockets 发送 10 次 ping/pong，您仍然不太可能与每 2 秒的 HTTP/AJAX 轮询的开销进行比较.但是，请注意，应用程序无法发送 ping/pong 消息.这是在浏览器和服务器之间.
The purpose of periodic WebSockets ping/pong messages is two-fold: to keep the channel from being closed by TCP timeout and to more quickly detect when the channel is closed (this is historically a weakness of TCP). The purpose of HTTP/AJAX polling is to get around the fact that HTTP is not bidirectional (i.e. the client polls to give the server the opportunity to send data back). WebSocket ping/pong frames are generally 2 bytes long. HTTP/AJAX polling requires full headers, cookies, etc which can easily total over a kilobyte for each request/response. Even if you send a ping/pong 10 times a second over WebSockets you are still unlikely to even compare to the overhead of HTTP/AJAX polling every 2 seconds. However, note that applications do not have the ability to send ping/pong messages. This is between the browser and server.
如果您失去 Internet 连接，您将收到一个 onclose 事件.如果您的浏览器没有为您发送 ping/pong 消息，那么在您尝试在网络连接中断后发送消息之前，您可能不会收到 onclose.
If you lose the Internet connection, you will receive an onclose event. If your browser is not doing ping/pong messages for you then you may not receive an onclose until you try to send a message after the network connection goes down.
我不会用 WebSockets 替换可用的 RESTful 服务.您将进行大量映射工作，但收益可能很少(同样，WebSockets 并非旨在取代已经运行良好的内容).我可以设想两种情况的组合:REST 用于状态传输，WebSockets 用于事件通知.例如.服务器发送一个 WebSocket 消息，指示发生了一些变化"，这会触发客户端执行 REST 请求以找出更改.
I wouldn't replace a working RESTful service with WebSockets. You would be doing a lot of mapping work for probably very little benefit (again, WebSockets is not designed to replace what's already working well). I can envision situations where you might have a combination of both: REST for state transfer, WebSockets for event notification. E.g. the server sends a WebSocket message indicating "something changed" which triggers the client to do a REST request to find out the change.
更新:
澄清:您可以在 WebSockets 上执行 REST，但这在哲学上是不匹配的.REST 是一种对底层传输系统没有意见的架构风格.它是一个受约束的架构:客户端-服务器"、无状态"、可缓存"、分层系统"、按需代码"和统一接口".WebSockets 不受这些限制；它是一个通用的消息传输系统.您可以将 WebSockets 限制为 RESTful，但在您深入了解 REST 和 WebSockets 并且可以确定何时这样做是正确的之前不要这样做.
Clarification: you could do REST over WebSockets but it's a mismatch in philosophy. REST is an architecture style that is un-opinionated about the underlying transport system. It is a constrained architecture: "client-server", "stateless", "cacheable", "layered system", "code on demand", and "uniform interface". WebSockets is constrained by none of those; it is a generic message transport system. You could constrain WebSockets to be RESTful but don't do that until you understand both REST and WebSockets intimately and can identify when it's right to do so.
这篇关于网络套接字.失去互联网、保持活动的消息、应用程序架构等的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！