或服务器发送事件和WebSocket取代Comet技术？
答案 0 :(得分：19)
我将从术语和历史角度来看待这个答案。
正如我在this other answer中所写，我们可以使用几个总括性术语中的一个来指代可用于将事件从Web服务器异步发送到Web客户端（反之亦然）的技术集。 “推送技术”这个术语已经使用了十五年（对于Push技术的简短历史，您可以看到我多年前写的old white paper - 完全披露：我是创作者Lightstreamer）。现在，“ Web Streaming ”术语正在IT分析师中达成共识（参见Gartner，“应用和集成平台中的酷供应商，2012”，作者：Massimo Pezzini和Jess Thompson，2012年4月11日）。
重要的一点是，我们正在谈论基于Web的通信，即利用Web协议。有大量的消息传递协议和技术不是基于Web的（例如大多数MOM），我们不认为它们是Push Technology（或Web Streaming）的一部分。
话虽这么说，你可以区分Push技术（或Web Streaming）的两个子类别：
HTTP和WebSockets都是Web协议。
如果您爆炸基于HTTP的推送机制，您可以识别：
传统上，“ Comet ”一词（由Alex Russell在 2006 中加入）一直指的是HTTP Streaming和HTTP Polling。但是考虑到HTTP Streaming的第一个实现回到 2000 ，就在Comet术语被创造出来之前（例子是Pushlets和Lightstreamer）。
现在，WebSockets使实现Web Streaming变得更加简单，特别是对于“后向”通道（从浏览器发送到服务器的消息）。有关HTTP上反向通道特性的更详细说明，请参阅我为CometDaily撰写的本文的最后部分：http://cometdaily.com/2011/07/06/push-technology-comet-and-websockets-10-years-of-history-from-lightstreamers-perspective/
正如菲尔所指出的，Comet仍然是必要的，并且可能会持续多年，因为不仅有旧的浏览器（包括不支持WebSockets的IE9 ......），还有无数的网络中介不会说WS的。例如，我们已经看到一些国家的某些移动运营商（例如Vodafone Italy）支持WSS但阻止WS。所以一个没有彗星“黑客”的世界仍然很遥远......让我个人补充说，我从未喜欢过应用于彗星的“黑客”一词（或者，从一个更正确的历史角度来看） view，应用于HTTP Streaming和HTTP Long Polling）。在这些技术工作了12年之后，我可以说我们已经能够对它们进行过多的改进，以至于它们已经成为一种全面的技术，完全可靠并且在许多关键生产场景中每天都在使用（在金融，航空航天领域，和军事，仅举几个行业。）
现在，让我们想象一下WebSockets得到普遍支持的世界，Comet不再是必需的。你到底得到了什么？好吧，只是一个双向传输，仅此而已......最重要的是你需要构建一切：消息传递协议（可能基于pub / sub），服务器端接口与服务器代码通信，以及一套用于管理数据流的优化技术和算法，包括带宽管理，数据融合，自动限制，增量传输等。 好消息是，好的Comet解决方案已经实现了消息传递协议和优化机制。因此，扩展前Comet服务器以支持WebSocket是我们所有供应商实现的自然演变。
因此，简而言之，在不久的将来，WebSockets可能会使Comet传输过时，但需要吸收已在传统Comet服务器上实施和测试的所有更高层。
答案 1 :(得分：12)
Comet 是一组技术原则/通信模式，通常使用HTTP long-poll实现。它使服务器能够按需将数据发送到浏览器（即服务器推送）。当前的彗星实现需要客户端的一些复杂的Javascript和服务器端的支持（对于长期请求）。
服务器发送事件是一种标准（HTML5）浏览器API，用于启用此类随需应变服务器。您可以将服务器发送事件视为采用复杂Javascript所做的操作并将其推送到浏览器本身。
WebSockets 允许浏览器与支持WebSocket的服务器建立持久的全双工/双向连接。它不需要客户端继续向服务器定期发出HTTP请求，以便像AJAX / long-poll一样维护连接。建立连接后，与普通HTTP / HTTP长轮询的开销相比，每条消息的开销非常低（几个字节）。您可以使用WebSockets进行有效的服务器推送，但这只是一个应用程序。
还有一些基于AJAX / comet / WebSockets传输层构建的库，用于提供会话管理，频道，广播，pubsub等内容。 CometD 就是一个例子。 。另一个流行的例子是 Socket.IO 。如果WebSockets可用于底层传输，则它们都支持WebSockets，但如果WebSockets不可用，它们也支持标准的AJAX / long-poll。
答案 2 :(得分：9)
我最初认为WebSockets realise Comet. They’re not an alternative。然而，经过一些讨论后，我被“彗星”的创造者Alex Russell纠正并说服了，事实并非如此。
正如@kanaka所说，Comet是一套模拟客户端和服务器之间双向通信的原则（服务器推送是解决方案的一半，现在由Server-Sent Events和Event Source API提供）。 / p>但是，Comet解决方案很糟糕，因为它们在Web浏览器中的工作方式不一致。出于这个原因，Alex Russell说：
接下来，Web套接字是Comet的一种形式吗？或者彗星只是HTTP黑客攻击？我要去做后一个定义。这句话和黑客应该一起骑车到日落。我是一个欢迎我们的非HTTP实时霸主。在某种程度上我们可以忘记旧的浏览器（上帝知道我正在做的事情：http://google.com/chromeframe），我们都可以加入“Web套接字”，并且对任何特定保护伞的需求都会消失。 / p>
所以让我们关注一下：我们如何让用户进入一个闪亮的新浏览器汽车？我们可以向他们提供哪些关于基于WebSockets的应用程序可以提供的丰富性和实时体验的建议？彗星是关于过去的。让我们展望未来。
我现在和Alex在一起。但是，Comet-HTTP解决方案在下列情况之前不会过时：
答案 3 :(得分：0)
虽然WebSocket确实在最基本的层面上提供了在Web和HTTP上下文中客户端和服务器之间双向通信的方式，但它是一种简单的通信形式。
Comet在WebSocket上提供了更多功能（事实上，cometd甚至支持websocket），用于功能：