期望来自服务器端的一次性响应时的长轮询 vs websocket [英] Long-polling vs websocket when expecting one-time response from server-side

问题描述

我已经阅读了很多关于实时推送通知的文章.简历是 websocket 通常是首选技术，只要您不关心 100% 浏览器兼容性.然而，一篇文章指出

I have read many articles on real-time push notifications. And the resume is that websocket is generally the preferred technique as long as you are not concerned about 100% browser compatibility. And yet, one article states that

长轮询 - 可能当您与服务器，服务器正在后台做一些工作.

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

这正是我的情况.用户按下一个按钮，在服务器端启动一些复杂的计算，一旦答案准备好，服务器就会向客户端发送推送通知.问题是，我们能不能说对于一次性响应的情况，长轮询比websockets更好?或者，除非我们担心过时的浏览器支持，如果我打算从头开始这个项目，当涉及到推送协议时，websockets 应该总是优先于长轮询?

This is exactly my case. The user presses a button which initiates some complex calculations on server-side, and as soon as the answer is ready, the server sends a push-notification to the client. The question is, can we say that for the case of one-time responses, long-polling is better choice than websockets? Or unless we are concerned about obsolete browsers support and if I am going to start the project from scratch, websockets should ALWAYS be preferred to long-polling when it comes to push-protocol ?

推荐答案

问题是，我们可以说对于一次性响应的情况，长轮询是比 websockets 更好的选择?

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

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

Not really. Long polling is inefficient (multiple incoming requests, multiple times your server has to check on the state of the long running job), particularly if the usual time period is long enough that you're going to have to poll many times.

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

If a given client page is only likely to do this operation once, then you can really go either way. There are some advantages and disadvantages to each mechanism.

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

At a response time of 5-10 minutes you cannot assume that a single http request will stay alive that long awaiting a response, even if you make sure the server side will stay open that long. Clients or intermediate network equipment (proxies, etc...) just make not keep the initial http connection open that long. That would have been the most efficient mechanism if you could have done that. But, I don't think you can count on that for a random network configuration and client configuration that you do not control.

所以，这给您留下了几个我认为您已经知道的选项，但为了其他人的完整性，我将在此处进行描述.

So, that leaves you with several options which I think you already know, but I will describe here for completeness for others.

选项 1:

• 建立到服务器的 websocket 连接，您可以通过它接收推送响应.
• 发出 http 请求以启动长时间运行的操作.返回操作已成功启动的响应.
• 稍后接收 websocket 推送响应.
• 关闭 webSocket(假设此页面不会再次执行此操作).

选项 2:

• 发出 http 请求以启动长时间运行的操作.返回操作已成功启动的响应，并且可能是某种可用于未来查询的 taskID.
• 使用http长轮询"来等待"答案.由于这些请求可能会在收到响应之前超时"，因此您必须定期进行长时间轮询，直到收到响应.

选项 3:

• 建立 webSocket 连接.
• 通过 webSocket 连接发送消息以启动操作.
• 稍后收到操作完成的响应.
• 关闭 webSocket 连接(假设此页面不再使用它).

选项 4:

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

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

If you're looking at things purely from the networking and server efficiency point of view, then options 3 or 4 are likely to be the most efficient. You only have the overhead of one TCP connection between client and server and that one connection is used for all traffic and the traffic on that one connection is pretty efficient and supports actual push so the client gets notified as soon as possible.

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

From an architecture point of view, I'm not a fan of option 1 because it just seems a bit convoluted when you initiate the request using one technology and then send the response via another and it requires you to create a correlation between the client that initiated an incoming http request and a connected webSocket. That can be done, but it's extra bookkeeping on the server. Option 2 is simple architecturally, but inefficient (regularly polling the server) so it's not my favorite either.

这篇关于期望来自服务器端的一次性响应时的长轮询 vs websocket的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！