websocket - 期望来自服务器端的一次性响应时的长轮询与 websocket

Question

我读过很多关于实时推送通知的文章。并且简历是 websocket 通常是首选技术，只要您不关心 100% 的浏览器兼容性。然而，one article指出

Long polling - potentially when you are exchanging single call with server, and server is doing some work in background.

这正是我的情况。用户按下一个按钮，在服务器端启动一些复杂的计算，一旦答案准备好，服务器就会向客户端发送推送通知。问题是，我们可以说对于一次性响应的情况，长轮询比 websockets 更好吗？
或者除非我们担心过时的浏览器支持，并且如果我要从头开始项目，在推送协议(protocol)方面，websockets 应该总是优于长轮询？

Answer 1

The question is, can we say that for the case of one-time responses, long-polling is better choice than websockets?

并不真地。长轮询效率低下(多个传入请求，您的服务器必须多次检查长时间运行的作业的状态)，特别是如果通常的时间段足够长以至于您将不得不进行多次轮询。

如果给定的客户端页面可能只执行一次此操作，那么您真的可以选择任何一种方式。每种机制都有一些优点和缺点。

在 5 到 10 分钟的响应时间内，您不能假设单个 http 请求会在等待响应的时间内保持事件状态，即使您确保服务器端会保持打开那么长时间。客户端或中间网络设备(代理等)只是不要让初始 http 连接保持打开那么长时间。如果您可以这样做，那将是最有效的机制。但是，我认为您不能指望您无法控制的随机网络配置和客户端配置。

所以，这给你留下了几个我认为你已经知道的选项，但我将在这里描述以供其他人使用。

选项1:

建立与服务器的 websocket 连接，您可以通过该连接接收推送响应。

发出 http 请求以启动长时间运行的操作。返回操作已成功启动的响应。

一段时间后收到 websocket 推送响应。

关闭 webSocket(假设此页面不会再执行此操作)。

选项 2:

发出 http 请求以启动长时间运行的操作。返回操作已成功启动的响应，并且可能是某种可用于将来查询的 taskID。

使用http“长轮询”来“等待”答案。由于这些请求可能会在收到响应之前“超时”，因此您必须定期进行长轮询，直到收到响应为止。

选项 3:

建立 webSocket 连接。

通过 webSocket 连接发送消息以启动操作。

稍后收到操作完成的响应。

关闭 webSocket 连接(假设该页面不再使用它)。

选项 4:

与选项 3 相同，但使用 socket.io 而不是普通的 webSocket 来为您提供心跳和自动重新连接逻辑，以确保 webSocket 连接保持事件状态。

如果您纯粹从网络和服务器效率的角度来看问题，那么选项 3 或 4 可能是最有效的。您只有客户端和服务器之间的一个 TCP 连接的开销，并且一个连接用于所有流量，并且该连接上的流量非常有效并且支持实际推送，因此客户端会尽快得到通知。

从架构的角度来看，我不喜欢选项 1，因为当您使用一种技术发起请求然后通过另一种技术发送响应时，它似乎有点令人费解，并且它需要您在客户端之间创建关联发起了一个传入的 http 请求和一个连接的 webSocket。可以这样做，但它是服务器上的额外簿记。选项 2 在架构上很简单，但效率低下(定期轮询服务器)，所以它也不是我最喜欢的。