长期投票的不利方面? [英] Hard downsides of long polling?

问题描述

对于交互式Web应用程序，Websocket之类的东西越来越受欢迎.但是，由于客户端和代理世界并不总是完全兼容的，因此通常使用诸如"Socket.IO"之类的复杂框架，在任何情况下都可能隐藏几种不同的机制，从而可能会禁用其他机制.

For interactive web apps, things like Websockets are getting more popular. However, as the client, and proxy world is not always fully compliant, one usually use a complex framework like 'Socket.IO', hiding several different mechanisms for any case that may disable the other ones.

我只是想知道正确实施长时间轮询的不利之处，因为对于像node.js这样的当今服务器，它很容易实现，并且依赖受到良好支持的旧http技术(尽管长期轮询行为本身可能会中断它).

I just wonder what the downsides of a properly implemented long polling are, because with today's servers like node.js it is quite easy to implement and relies on old http technology which is well supported (despite the long polling behaveiour itself may break it).

从高级别的角度来看，长时间轮询(尽管有一些额外的开销，对于中等流量的应用程序来说是可行的)类似于WebSockets的真正推送行为，因为服务器实际上会在他愿意时发送答复(尽管有一些超时/心跳机制)

From an high level view, long polling (despite some additional overhead, feasable for medium traffic apps) resembles a true push behaviour as WebSockets do, as the server actually send it's answer whenever he likes (despite some timeout / heartbeat mechanism).

由于我猜想会有更多的TCP/IP确认，因此我们会有更多开销，但是没有像频繁轮询那样的持续流量.

So we have some more overhead due to the more TCP/IP acknowledgements I guess, but no constant traffic like frequent polling would do.

使用事件驱动的服务器，我们将没有线程开销来保持连接的阻塞.

And using an event driven server, we would have no thread overhead to keep the connections blocked.

那么还有其他不利的方面迫使诸如聊天之类的流量中等的应用程序使用WebSockets而不是长时间的轮询吗?

So is there any else hard downside that forces medium-traffic apps like chats to use WebSockets rather than long polling?

推荐答案

开销

每次都会创建一个新的连接，因此它将发送HTTP标头...包括可能很大的cookie标头.

Overhead

It will create a new connection each time, so it will send the HTTP headers... including the cookie header that may be large.

此外，仅检查是否有新东西"是另一种联系.连接意味着许多项目的工作，例如防火墙，负载平衡器，Web服务器等.也许，一旦您的IT基础结构具有多个检查员，建立连接是最耗时的事情.

Also, just "check if there is something new" is another connection for nothing. Connections implies the work of many items like firewalls, load balancers, web servers ... etc.. Probably, establish the connection is most time consuming thing as soon your IT infrastructure have several inspectors.

如果使用HTTPS，则一次又一次地执行最昂贵的操作，即TLS握手.一旦建立连接并且对称加密正常工作，TLS性能就很好，但是建立连接，密钥交换和所有爵士乐的过程并不快.

If you are using HTTPS, you are doing again and again the most expensive operation, the TLS handshake. TLS performance is good once the connection is established and the symmetric encryption is working, but the process of establishing the connection, key exchange and all that jazz is not fast.

此外，完成连接后，日志条目会写入某处，计数器会在某处递增，内存会消耗，对象也会创建...等等.等等.例如，当我们在以下情况下拥有不同的日志记录配置的原因在生产和开发中，是因为编写日志条目也会影响性能.

Also, when connections are done, log entries are written somewhere, counters are incremented somewhere, memory is consumed, objects are created... etc... etc.. For example, the reason why we have different logging configurations when in production and in development, is because writing log entries also affect performance.

长时间轮询的用户何时连接或断开连接?如果您在给定的时间进行检查...您应该等待多长时间才能再次检查以确保断开连接或连接的可靠时间?

When is a long polling user connected or disconnected? If you check for this at a given moment of time... what would be the reliable amount of time you should wait to double check, to ensure it is disconnected or connected?

如果您的应用程序只是广播内容，那么这可能是完全不相关的，但是如果您的应用程序是游戏，那么这可能是非常相关的.

This may be totally irrelevant if your application just broadcast stuff, but it may be very relevant if your application is a game.

这很重要.

由于每次都会创建一个新的连接，因此如果您具有负载平衡的服务器，则在轮询方案中，您将无法知道下一个连接将位于哪个服务器上.

Since a new connection is created each time, if you have load balanced servers, in a round robbin scenario you cannot know in which server the next connection is going to fall.

当知道用户的服务器时(例如使用WebSocket时)，您可以立即将事件推送到该服务器，服务器会将它们中继到连接.如果用户断开连接，则服务器可以立即通知该用户不再连接，并且当再次连接时可以再次订阅.

When a user's server is known, like when using a WebSocket, you can push the events to that server straight away, and the server will relay them to the connection. If the user disconnects, the server can notify straight away that the user is not connected anymore, and when connect again can subscribe again.

如果在为用户生成事件时用户所连接的服务器未知，则必须等待用户连接，这样您才能说:嘿，用户123在这里，请给我所有自该时间戳记以来的新闻"，是什么使它变得更加繁琐.长轮询并不是真正的推动技术，而是请求响应，因此，如果您计划采用EDA架构，则在某些时候您将不得不解决一定程度的阻抗问题，例如，您需要一个事件聚合器来为您提供给定时间戳记(用户最后一次请求新闻的时间)的所有事件.

If the server where the user is connected at the moment that an event for him is generated is unknown, you have to wait for the user to connect so then you can say "hey, user 123 is here, give me all the news since this timestamp", what make it a little bit more cumbersome. Long polling is not really push technology, but request-response, so if you plan for a EDA architecture, at some point you are going to have some level of impedance you have to address, like for example, you need a event aggregator that can give you all the events from a given timestamp (the last time that user connected to ask for news).

SignalR(我想它在.NET中与socket.io等效)，具有名为

SignalR (I guess it is the equivalent in .NET to socket.io) for example, has a message bus named backplane, that relay all the messages to all the servers, as key for scaling out. Therefore, when a user connect to other server, "his" pending events are there "as well"(!) It is a "not too bad approach", but as you can guess, affects the throughput:

限制

使用底板，最大消息吞吐量低于它 当客户端直接与单个服务器节点对话时.那是因为 底板将每个消息转发到每个节点，因此底板可以 成为瓶颈.此限制是否有问题取决于 应用程序.例如，以下是一些典型的SignalR场景:

Using a backplane, the maximum message throughput is lower than it is when clients talk directly to a single server node. That's because the backplane forwards every message to every node, so the backplane can become a bottleneck. Whether this limitation is a problem depends on the application. For example, here are some typical SignalR scenarios:

• 服务器广播(例如股票行情自动收录器):为此，背板可以很好地工作 方案，因为服务器控制邮件的传输速率 已发送.

• Server broadcast (e.g., stock ticker): Backplanes work well for this scenario, because the server controls the rate at which messages are sent.

客户端到客户端(例如，聊天):在这种情况下，背板可能 成为瓶颈 客户；也就是说，如果消息的速率随着 客户加入.

Client-to-client (e.g., chat): In this scenario, the backplane might be a bottleneck if the number of messages scales with the number of clients; that is, if the rate of messages grows proportionally as more clients join.

高频实时(例如实时游戏):没有背板 在这种情况下推荐使用.

High-frequency realtime (e.g., real-time games): A backplane is not recommended for this scenario.

对于某些项目，这可能是一个热门.

For some projects, this may be a showstopper.

某些应用程序仅广播常规数据，而其他应用程序则具有连接语义，例如多人游戏，因此将正确的事件发送到正确的连接很重要.

Some applications just broadcast general data, but others have a connection semantics, like for example a multiplayer game, and it is important to send the right events to the right connections.

长轮询是小型项目的理想解决方案，但对于需要高频率和/或分段事件发送的高可扩展性应用程序来说，这成为了沉重的负担.

Long polling is a good solution for small projects, but became a big burden for high scalable apps that need high frecuency and/or very segmented event sending.

这篇关于长期投票的不利方面?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！