19

还是服务器发送事件和 WebSocket 取代 Comet 技术？

4

4 回答 4

20

我将从术语和历史的角度来处理这个答案。

正如我在另一个答案中所写的那样，我们可以使用几个总括术语之一来指代可用于将事件从 Web 服务器异步发送到 Web 客户端（反之亦然）的一组技术。“推送技术”这个词已经使用了十五年（关于推送技术的简短历史，您可以查看我多年前写的这份旧白皮书——全面披露：我是 Lightstreamer 的创建者）。现在，“ Web 流”一词正在 IT 分析师中获得共识（参见 Gartner，“Cool Vendors in Application and Integration Platforms，2012”，作者 Massimo Pezzini 和 Jess Thompson，2012 年 4 月 11 日）。

重要的方面是我们正在谈论基于 Web 的通信，即利用 Web 协议。有大量不基于 Web 的消息传递协议和技术（例如大多数 MOM），我们不将它们视为推送技术（或 Web 流）的一部分。

话虽如此，您可以区分推送技术（或 Web 流）的两个子类别：

  • 基于HTTP
  • 基于WebSockets

HTTP 和 WebSocket 都是 Web 协议。

如果您分解基于 HTTP 的推送机制，您可以识别：

  • HTTP 流式传输
  • HTTP 长轮询
  • HTTP 轮询

传统上，“彗星”一词（由 Alex Russell 于2006 年创造）一直指 HTTP 流和 HTTP 轮询。但是考虑一下 HTTP 流的第一个实现可以追溯到2000 年，远在 Comet 术语被创造之前（例如 Pushlets 和 Lightstreamer）。

现在，WebSockets 使实现 Web 流式传输变得更加简单，特别是对于“反向”通道（从浏览器发送到服务器的消息）。有关 HTTP 反向通道特性的更详细说明，请参阅我为 CometDaily 撰写的这篇文章的最后部分：http: //cometdaily.com/2011/07/06/push-technology-comet-and-websockets -10 年的历史 - 从 lightstreamers 的角度来看/

正如 Phil 所指出的，Comet 仍然是必要的，而且可能还会持续几年，因为周围不仅有旧的浏览器（包括不支持 WebSockets 的 IE9……），而且还有无数不讲 WS 的网络中介. 例如，我们已经看到一些国家的一些移动运营商（例如意大利沃达丰）支持 WSS 但屏蔽了 WS。所以一个没有彗星“黑客”的世界还很遥远……让我补充一点，就个人而言，我从来不喜欢应用于彗星的“黑客”一词（或者，从更正确的历史观点来看，适用于 HTTP 流和 HTTP 长轮询）。在这些技术上工作了 12 年，我可以说我们已经能够对它们进行如此多的改进，以至于它们本身已经成为一项成熟的技术，

现在，让我们想象一个普遍支持 WebSocket 并且不再需要 Comet 的世界。你到底得到了什么？好吧，只是一个双向传输，仅此而已……在它之上，您需要构建所有内容：消息传递协议（可能基于 pub/sub），与服务器代码对话的服务器端接口，以及一套很好的优化技术和算法来管理数据流，包括带宽管理、数据合并、自动节流、增量交付等。好消息是消息传递协议和优化机制都已经被好的 Comet 解决方案实现了. 因此，扩展以前的 Comet 服务器以支持 WebSocket 是我们所有供应商都实施的自然演变。

因此，简而言之，在不远的将来，WebSockets 可能会使 Comet 传输过时，但需要吸收所有已经在传统 Comet 服务器上实现并经过良好测试的更高层。

于 2012-08-22T22:11:17.260 回答
15

Comet是一组技术原理/通信模式，通常使用 HTTP 长轮询来实现。它使服务器能够按需向浏览器发送数据（即服务器推送）。当前的 Comet 实现需要在客户端使用一些复杂的 Javascript，并在服务器端提供支持（对于长期持有的请求）。

Server-Sent Events是一个标准 (HTML5) 浏览器 API，用于启用这种随需应变的服务器推送。您可以将服务器发送事件视为使用复杂的 Javascript 完成的操作并将其推送到浏览器本身。

WebSockets允许浏览器与支持 WebSocket 的服务器建立持久的全双工/双向连接。它不需要客户端定期向服务器发出 HTTP 请求以维持连接，就像使用 AJAX/long-poll 一样。建立连接后，与普通 HTTP/HTTP 长轮询的开销相比，每条消息的开销非常低（几个字节）。您可以使用 WebSockets 进行高效的服务器推送，但这只是一个应用程序。

还有一些库构建在 AJAX/comet/WebSockets 传输层上，提供会话管理、频道、广播、发布订阅等功能。CometD就是一个例子。另一个流行的例子是Socket.IO。如果 WebSockets 可用于底层传输，两者都支持 WebSockets，但如果 WebSockets 不可用，它们也支持标准 AJAX/long-poll。

于 2012-08-22T18:58:12.763 回答
10

我最初以为WebSockets 实现 Comet。他们不是替代品。然而，经过一番讨论，我后来得到了“彗星”的创造者亚历克斯·拉塞尔的纠正和说服，事实并非如此。

正如@kanaka 所说，Comet 是一组用于模拟客户端和服务器之间的双向通信的原则（服务器推送是解决方案的一半，现在由服务器发送事件和事件源 API 提供）。

但是，Comet 解决方案是 hack，因为它们在 Web 浏览器中的工作方式不一致。出于这个原因，亚历克斯·拉塞尔说：

接下来，Web Sockets 是 Comet 的一种形式吗？或者 Comet 只是 HTTP 黑客？我会选择后一个定义。这句话和黑客应该一起骑到日落。我，一方面，欢迎我们的非 HTTP 实时霸主。在某种程度上我们可以忘记旧浏览器（上帝知道我正在尽我的一份力：http: //google.com/chromeframe），我们都可以使用“Web Sockets”以及对任何特定保护伞的需求消失了。

因此，让我们专注于这一点：我们如何让用户进入闪亮的新浏览器汽车？关于基于 WebSockets 的应用程序可以提供的丰富性和实时体验，我们可以向他们提供什么样的提议？彗星是关于过去的。让未来成为现实。

我现在和亚历克斯一起做这个。然而，Comet - HTTP 解决方案 - 不会过时，直到：

  1. 浏览器支持是 100%，我们不需要 < IE10 的后备。我不相信 Firefox、Safari 和 Opera 用户会成为问题。可能有一小部分用户忽略了 Firefox 等浏览器的自动更新提示，但并不多。
  2. 防病毒制造商（例如 Avast！）开始支持 HTML5 网络技术并停止他们的软件干扰连接。
  3. 更新了一些 Internet 基础设施以确保对 WebSockets 的支持。根据我的经验，通过端口 443（安全的 WebSocket 连接）通过 WSS 连接通常意味着连接通过防火墙和代理，但我们也希望始终支持通过端口 80 的 WS。
于 2012-08-22T19:18:43.650 回答
0

虽然 WebSocket 在最基本的层面上确实提供了一种在 Web 和 HTTP 的上下文中在客户端和服务器之间进行双向通信的方式，但它是一种简单的通信形式。

Comet 在 WebSocket 之上提供了更多的功能（事实上，cometd 甚至支持 websocket），对于特性：

  • 比如发布/订阅和通信渠道
  • 当 websocket 不可用时回退到旧客户端<->服务器通信技术
于 2012-08-22T18:17:52.070 回答