我读过很多关于实时推送通知的文章。简历是websocket通常是首选技术，只要您不关心100％的浏览器兼容性。然而，one article表示
长时间轮询 - 可能在您与之交换单个呼叫时 服务器和服务器正在后台做一些工作。
这正是我的情况。用户按下一个按钮，在服务器端启动一些复杂的计算，一旦答案准备就绪，服务器就会向客户端发送推送通知。问题是，我们可以说，对于一次性响应的情况，长轮询是比websockets更好的选择吗？ 或者除非我们担心过时的浏览器支持，如果我要从头开始启动项目，那么在推送协议方面，websockets总是应该首选长轮询？
答案 0 :(得分：13)
问题是，对于一次性回复的情况，我们可以说， 长轮询是比websockets更好的选择吗？
不是真的。长轮询是低效的（多个传入请求，多次服务器必须检查长时间运行的作业的状态），特别是如果通常的时间段足够长，以至于您不得不多次轮询。 / p>
如果给定的客户端页面只能执行一次此操作，那么您可以采用任何一种方式。每种机制都有一些优点和缺点。
在5-10分钟的响应时间内，即使您确保服务器端保持打开很长时间，您也不能假设单个http请求将在等待响应的情况下保持活动状态。客户端或中间网络设备（代理等）只是使初始http连接保持打开状态不长。如果你能做到这一点，那将是最有效的机制。但是，我认为您无法控制随机网络配置和您无法控制的客户端配置。
所以，这给你留下了一些我认为你已经知道的选项，但我会在这里描述其他人的完整性。
选项1：
选项2：
选项3：
选项4：
如果您纯粹从网络和服务器效率的角度来看待事物，那么选项3或4可能是最有效的。您只有客户端和服务器之间的一个TCP连接的开销，并且一个连接用于所有流量，并且该连接上的流量非常高效并且支持实际推送，因此客户端会尽快得到通知。
从架构的角度来看，我不是选项1的粉丝，因为当您使用一种技术发起请求然后通过另一种技术发送响应时，它似乎有点复杂，它需要您创建一个发起传入http请求的客户端与连接的webSocket之间的关联。这可以做到，但它在服务器上有额外的簿记。选项2在架构上很简单，但效率低（定期轮询服务器），所以它也不是我的最爱。
答案 1 :(得分：3)
有一个替代品不需要轮询或一直打开套接字连接。
它被称为web push。
Push API使Web应用程序能够接收从服务器推送给他们的消息，无论Web应用程序是在前台，还是当前加载到用户代理上。这使开发人员可以向选择加入的用户提供异步通知和更新，从而更好地与及时的新内容互动。
一些特权是