长时间投票的不利因素？

Question

我只是想知道正确实现长轮询的缺点是什么，因为对于今天的Node.js这样的服务器来说，它很容易实现，并且依赖于得到很好支持的旧http技术（尽管长轮询行为本身可能会破坏它）。

从高层来看，长轮询（尽管有一些额外的开销，但对于中等流量的应用程序来说是可行的）类似于WebSockets的真正推送行为，因为服务器实际上在他喜欢的时候发送它的答案（尽管有一些超时/心跳机制）。

因此，我想由于更多的TCP/IP确认，我们有一些更多的开销，但没有像频繁轮询这样的恒定流量。

Answer 1

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

而且，仅仅“检查是否有新的东西”是另一个毫无意义的连接。连接意味着许多项目的工作，如防火墙、负载平衡器、web服务器等。可能，一旦您的IT基础设施有了几个检查人员，建立连接是最耗时的事情。

如果您使用的是HTTPS，那么您正在一次又一次地执行最昂贵的操作，TLS握手。一旦建立了连接并且对称加密工作，TLS性能很好，但是建立连接、密钥交换和所有jazz的过程并不快。

这才是大不了的。

由于每次都会创建一个新的连接，如果您有负载平衡的服务器，在循环robbin场景中，您无法知道下一个连接将落在哪个服务器上。

当用户的服务器是已知的，比如使用WebSocket时，您可以直接将事件推送到该服务器，然后服务器将它们中继到连接。如果用户断开连接，服务器可以立即通知用户不再连接，当再次连接时，可以再次订阅。

>

服务器广播（例如股票报价器）：背板在这种情况下工作得很好，因为服务器控制消息发送的速率。

客户端到客户端（例如，聊天）：在这种情况下，如果消息数量与客户端数量成比例，则背板可能是一个瓶颈；也就是说，如果消息的速率随着更多客户机的加入而成比例地增长。

高频实时（例如，实时游戏）：这种情况下不建议使用底板。