首页 文章

长期民意调查的难点是什么？

提问于
浏览 次
13

对于交互式Web应用程序，Websockets等内容越来越受欢迎 . 但是，由于客户端和代理世界并不总是完全兼容，因此通常使用像“Socket.IO”这样的复杂框架，为任何可能禁用其他情况的情况隐藏几种不同的机制 .

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

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

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

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

那么还有其他任何困难的下行方式会迫使像聊天这样的中等流量应用使用WebSockets而不是长时间的轮询吗？

node.js networking websocket socket.io long-polling

1 回答

  • 13

    开销

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

    此外，只是“检查是否有新的东西”是另一个连接什么都没有 . 连接意味着许多项目的工作，如防火墙，负载 balancer 器，Web服务器等等 . 可能，一旦您的IT基础架构有多个检查员， Build 连接是最耗时的事情 .

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

    此外，当连接完成时，日志条目写在某处，计数器在某处递增，消耗内存，创建对象......等等 . 例如，我们在 生产环境 中使用不同的日志记录配置的原因在开发中，是因为写日志条目也会影响性能 .

    在场

    何时连接或断开长轮询用户？如果你在给定的时刻检查这个...那么你应该等待多长时间检查一次，以确保断开连接或连接的可靠时间是多少？

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

    不持久

    这是大问题 .

    由于每次都会创建一个新连接，如果您有负载 balancer 服务器，则在循环方案中您无法知道下一个连接将落在哪个服务器中 .

    当用户的服务器已知时，例如使用WebSocket时，您可以立即将事件推送到该服务器，服务器会将它们转发给连接 . 如果用户断开连接，服务器可以立即通知用户不再连接，再次连接时可以再次订阅 .

    如果用户在生成事件时连接的服务器未知，则必须等待用户连接，然后您可以说“嘿，用户123在这里，给我所有新闻，因为这个时间戳“，是什么让它变得有点麻烦 . 长轮询不是真正的推送技术，而是请求 - 响应，因此如果您计划EDA架构，在某些时候您将需要一定程度的阻抗，例如，您需要一个可以使用的事件聚合器为您提供来自给定时间戳的所有事件（用户最后一次连接以询问新闻） .

    SignalR（我猜它在.NET中与socket.io等效）例如，有一条名为backplane的消息总线，它将所有消息中继到所有服务器，作为扩展的关键 . 因此，当用户连接到其他服务器时，"his"挂起事件是"as well"（！）它是"not too bad approach"，但正如您所猜测的，会影响吞吐量：

    限制使用背板时，最大消息吞吐量低于客户端直接与单个服务器节点通信时的吞吐量 . 这是因为背板将每条消息转发到每个节点，因此背板可能成为瓶颈 . 此限制是否存在问题取决于应用程序 . 例如，这里是一些典型的SignalR场景：服务器广播（例如，股票代码）：背板适用于这种情况，因为服务器控制消息的发送速率 . 客户端到客户端（例如，聊天）：在这种情况下，如果消息数量与客户端数量成比例，则背板可能是瓶颈;也就是说，如果消息的速率随着更多客户端的加入而成比例增长 . 高频实时（例如，实时游戏）：不建议在这种情况下使用背板 .

    对于某些项目，这可能是一个停滞不前 .

    一些应用程序只是广播一般数据，但是其他应用程序具有连接语义，例如多人游戏，并且将正确的事件发送到正确的连接是很重要的 .

    恕我直言

    长轮询对于小型项目来说是一个很好的解决方案，但对于需要高频率和/或非常分段的事件发送的高可伸缩应用程序来说，这是一个很大的负担 .

    回复于

相关问题