【问题标题】:Persistent upstream Comet style connections持久的上游彗星式连接
【发布时间】:2011-06-25 20:36:45
【问题描述】:

有很多方法可以建立持久的下游连接。例如,您可以使用隐藏的 iframe;或者一个复杂的 XHR 模型,它利用 onreadystate 通过您的应用程序推送部分信息,同时保持连接。但是,我一直无法找到一种方法来以同样的精神持续上游。

如果您在上游推送中使用Connection: Keep-Alive,那么您实际上不会每次都断开连接并重建;那挺好的。您甚至可以在 GET 查询中编码您的上游推送,该查询将返回一个空文档

但是,即使它很接近,您仍然无法获得持久、长轮询下游连接所获得的性能、低延迟和吞吐量。

除非,也就是说,有另一种方法可以做到这一点。

这里有一些关于这种类型的解决方案是什么样子的理论;

  • 或许能够将mixed/multipart 流发布到带有边界条件的服务器。
  • 也许能够进行分块传输,每个后续块都是新数据。

值得注意的是,尽管 HTML5 或 Flash 可能实现这一点,但如果在当今流行的浏览器生态系统中无需插件即可实现这一目标将非常有用。我的愿望之一是能够在客户端和服务器之间流畅地实现 Knuth 的协程。

有人对此有任何见解吗?谢谢。

~克里斯。

【问题讨论】:

    标签: javascript ajax cross-browser xmlhttprequest comet


    【解决方案1】:

    在 Web 浏览器中进行“真正的”双向通信的唯一方法是使用 WebSockets。这是他们的主要优势 - 您可以在没有 HTTP 开销的情况下进行上游和下游通信。

    如果您的下游连接是通过长轮询传递的,那么您的上游连接将是常规的旧 HTTP 请求。

    但是,除非您有很多请求,否则我会考虑您是否正在尝试优化实际上不需要优化的东西。即使是当今最小的可用服务器,每秒也能处理数千个 HTTP 请求。而且由于大多数实时客户端应用程序监听的次数多于发送的次数,因此对下游连接的快速写入将真正影响服务器性能。在上游方面,只要您使用“Connection: Keep-Alive”来避免套接字设置/拆卸的开销,大多数应用程序在迁移到 WebSockets 后会看到微不足道的性能优势。

    (我为构建WebSync的公司工作。)

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-12-02
      • 2011-07-07
      • 2012-01-08
      • 1970-01-01
      • 2011-06-10
      • 2011-03-13
      • 2011-11-16
      • 1970-01-01
      相关资源
      最近更新 更多