我读过很多关于实时推送通知的文章。总结一下，只要您不关心 100% 的浏览器兼容性，websocket 通常是首选技术。但是，一篇文章指出
长轮询 - 可能当您与以下对象交换单个呼叫时
服务器，服务器正在后台做一些工作。
这正是我的情况。用户按下一个按钮，在服务器端启动一些复杂的计算，一旦答案准备好，服务器就会向客户端发送推送通知。问题是，我们是否可以说，对于一次性响应的情况，长轮询是比 websocket 更好的选择？
或者除非我们担心过时的浏览器支持，并且如果我要从头开始该项目，那么在推送协议方面，websockets 应该始终优先于长轮询？
问题是，我们是否可以说，对于一次性响应的情况，
长轮询是比 websocket 更好的选择吗？
并不真地。长轮询效率低下（多个传入请求，您的服务器必须多次检查长时间运行作业的状态），特别是如果通常的时间段足够长，您将不得不轮询多次。
如果给定的客户端页面只可能执行一次此操作，那么您实际上可以采用任何一种方法。每种机制都有一些优点和缺点。
当响应时间为 5-10 分钟时，您不能假设单个 http 请求将保持活动状态等待响应那么长时间，即使您确保服务器端将保持打开那么长时间。客户端或中间网络设备（代理等）只是不让初始 http 连接保持打开那么长时间。如果你能做到的话，这将是最有效的机制。但是，我认为您不能指望您无法控制的随机网络配置和客户端配置。
因此，这给您留下了几个选项，我认为您已经知道这些选项，但为了其他人的完整性，我将在这里进行描述。
选项1：
- 与服务器建立 websocket 连接，您可以通过该连接接收推送响应。
- 发出 http 请求来启动长时间运行的操作。返回操作已成功启动的响应。
- 一段时间后收到 websocket 推送响应。
- 关闭 webSocket（假设此页面不会再这样做）。
选项2：
- 发出 http 请求来启动长时间运行的操作。返回操作已成功启动的响应，并且可能返回某种可用于将来查询的任务 ID。
- 使用http“长轮询”来“等待”答案。由于这些请求可能会在收到响应之前“超时”，因此您必须定期进行长轮询，直到收到响应。
选项 3：
- 建立 webSocket 连接。
- 通过 webSocket 连接发送消息以启动操作。
- 一段时间后收到操作完成的响应。
- 关闭 webSocket 连接（假设此页面不再使用它）。
选项 4：
- 与选项 3 相同，但使用 socket.io 而不是普通的 webSocket 来为您提供心跳和自动重新连接逻辑，以确保 webSocket 连接保持活动状态。
如果您纯粹从网络和服务器效率的角度来看问题，那么选项 3 或 4 可能是最有效的。客户端和服务器之间只有一个 TCP 连接的开销，并且该连接用于所有流量，并且该连接上的流量非常高效并且支持实际推送，因此客户端会尽快收到通知。
从架构的角度来看，我不喜欢选项 1，因为当您使用一种技术发起请求，然后通过另一种技术发送响应时，它看起来有点复杂，并且它要求您在客户端之间创建关联发起传入的 http 请求和连接的 webSocket。这是可以做到的，但需要在服务器上进行额外的记账。选项 2 架构简单，但效率低下（定期轮询服务器），因此它也不是我最喜欢的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
