Comet现在已经过时了,服务器发送事件和WebSocket？

Question

或者服务器发送事件和WebSocket取代Comet技术？

Answer 1

我将从术语和历史角度来看待这个答案.

正如我在其他答案中所写,我们可以使用几个伞术语中的一个来指代可用于将事件从Web服务器异步发送到Web客户端的技术集(反之亦然)." 推技术 "术语已经使用了十五年(对于Push技术的短暂历史,你可以看到我多年前写的这篇旧白皮书 - 完全披露:我是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

HTTP和WebSockets都是Web协议.

如果您爆炸基于HTTP的推送机制,您可以识别:

• HTTP流媒体
• HTTP长轮询
• HTTP轮询

传统上," Comet "术语(由Alex Russell 于2006年合并)一直指HTTP流和HTTP轮询.但是考虑到HTTP Streaming的第一个实现可以追溯到2000年,远在Comet术语被创造出来之前(例子是Pushlets和Lightstreamer).

现在,WebSockets使实现Web Streaming变得更加简单,特别是对于"后向"通道(从浏览器发送到服务器的消息).有关HTTP上反向通道特性的更详细说明,请参阅我为CometDaily撰写的本文的最后部分:http://cometdaily.com/2011/07/06/push-technology-comet-and-websockets -10年-的历史-从- lightstreamers视角/

正如菲尔所指出的,Comet仍然是必要的,并且可能会持续更长时间,因为不仅有旧的浏览器(包括IE9,它不支持WebSockets ...),而且还有无限的网络中介说WS.例如,我们已经看到一些国家的某些移动运营商(例如Vodafone Italy)支持WSS但阻止WS.所以一个没有彗星"黑客"的世界仍然很遥远......让我个人补充说,我从未喜欢过应用于彗星的"黑客"一词(或者,从一个更正确的历史角度来看) view,应用于HTTP Streaming和HTTP Long Polling).在这些技术工作了12年之后,我可以说我们已经能够对它们进行过多的改进,以至于它们已经成为一种全面的技术,完全可靠并且每天都在许多关键的生产场景中使用(在金融,航空航天,和军事,仅举几个行业).

现在,让我们想象一下WebSockets得到普遍支持的世界,并且Comet不再是必需的.你到底得到了什么？好吧,只是一个双向传输,仅此而已......最重要的是你需要构建一切:消息传递协议(可能基于pub/sub),服务器端接口与服务器代码通信,以及一套很好的优化技术和算法来管理数据流,包括带宽管理,数据融合,自动限制,增量传输等.好消息是消息传递协议和优化机制都已经由好的Comet解决方案实现.因此,扩展前Comet服务器以支持WebSocket是我们所有供应商实现的自然演变.

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

Answer 2

Comet是一组技术原则/通信模式,通常使用HTTP长轮询实现.它使服务器能够按需将数据发送到浏览器(即服务器推送).当前的彗星实现需要客户端上的一些复杂的Javascript和服务器端的支持(对于长期持有的请求).

Server-Sent Events是一种标准(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.

Answer 3

我最初认为WebSockets实现了Comet.他们不是另类.然而,在经过一些讨论后,我后来更正并被"彗星"的创造者亚历克斯罗素所说服,事实并非如此.

正如@kanaka所说,Comet是一套模拟客户端和服务器之间双向通信的原则(服务器推送是解决方案的一半,现在由Server-Sent Events和Event Source API提供).

但是,Comet解决方案很糟糕,因为它们在Web浏览器中的工作方式不一致.出于这个原因,Alex Russell说:

接下来,Web套接字是Comet的一种形式吗？或者彗星只是HTTP黑客攻击？我要去做后一个定义.这句话和黑客应该一起骑车到日落.我是一个欢迎我们的非HTTP实时霸主.在某种程度上我们可以忘记旧的浏览器(并且上帝知道我正在做的事情:http://google.com/chromeframe),我们都可以加入"Web套接字"以及对任何特定伞的需求消失了.

因此,请关注这一点:我们如何让用户进入一个闪亮的新浏览器汽车？我们可以向他们提供哪些关于基于WebSockets的应用程序可以提供的丰富性和实时体验的建议？彗星是关于过去的.让我们的未来变得真实.

我现在和Alex在一起.但是,Comet-HTTP解决方案 - 在下列情况之前不会过时:

1. 浏览器支持是100%,我们不需要<IE10的回退.我不相信Firefox,Safari和Opera用户会成为一个问题.可能有一小部分用户忽略了Firefox等浏览器的自动更新提示,但并不多.
2. 反病毒制造商(如Avast!)开始支持HTML5网络技术并阻止其软件干扰连接.
3. 更新了一些Internet基础结构以确保WebSockets的支持.根据我通过端口443(一个安全的WebSocket连接)通过WSS连接的经验,通常意味着连接通过防火墙和代理,但我们希望始终支持WS over 80端口.