标签: comet

我曾尝试阅读一些文章,但我对这些概念还不是很清楚.

有人愿意尝试向我解释这些技术是什么:

1. 长轮询
2. 服务器发送的事件
3. 的WebSockets
4. 彗星

我每次遇到的一件事是,服务器保持连接打开并将数据推送到客户端.如何保持连接打开,客户端如何获取推送数据？(客户端如何使用数据,也许某些代码可能会有帮助？)

现在,我应该将其中哪一个用于实时应用.我一直听说很多关于websockets(有socket.io [一个node.js库]),但为什么不用PHP？

我可以找到很多关于Long Polling如何工作的信息(例如,这个和这个),但没有关于如何在代码中实现它的简单示例.

我所能找到的只是依赖于Dojo JS框架的cometd,以及一个相当复杂的服务器系统.

基本上,我将如何使用Apache来处理请求,以及如何编写一个简单的脚本(例如,在PHP中),它将"长时间轮询"服务器以获取新消息？

该示例不必是可扩展的,安全的或完整的,它只需要工作!

关于websocket和HTTP有很多博客和讨论,许多开发人员和网站都强烈支持websockets,但我仍然无法理解为什么.

例如(websocket爱好者的参数):

HTML5 Web套接字代表了Web通信的下一个发展 - 一种全双工双向通信通道,通过Web上的单个插槽运行.(http://www.websocket.org/quantum.html)

HTTP支持流媒体:请求正文流(您在上传大文件时使用它)和响应正文流.

在与WebSocket连接期间,客户端和服务器每帧交换2个字节的数据,而连续轮询时则为8千字节的http头.

为什么这2个字节不包括tcp和tcp协议开销？

GET /about.html HTTP/1.1
Host: example.org

这是~48字​​节的http标头.

http chunked编码 - http://ru.wikipedia.org/wiki/Chunked_transfer_encoding:

23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0

• 因此,每个块的开销并不大.

这两个协议都可以在TCP上运行,因此所有与长期连接的TCP问题仍然存在.

题:

1. 为什么websockets协议更好？
2. 为什么要实现而不是更新http协议？

我已经阅读了一些关于这个主题的帖子,答案是彗星,反向ajax,http流,服务器推送等.

Gmail上的传入邮件通知如何运作？

如果没有客户端交互,GMail Chat如何能够发出AJAX请求？

我想知道是否有任何代码引用,我可以遵循写一个非常简单的例子.许多帖子或网站只是谈论这项技术.很难找到完整的示例代码.此外,似乎可以使用许多方法来实现彗星,例如Hidden IFrame,XMLHttpRequest.在我看来,使用XMLHttpRequest是一个更好的选择.您如何看待不同方法的优缺点？Gmail使用哪一个？

我知道它需要在服务器端和客户端都这样做.有没有PHP和Javascript示例代码？

当然我知道Ajax,但Ajax的问题​​是浏览器应经常轮询服务器以查找是否有新数据.这会增加服务器负载.

除了经常轮询服务器之外,还有更好的方法(甚至使用Ajax)吗？

我在SO和网上阅读了很多关于我的问题标题中的关键词的帖子,并从中学到了很多.我读到的一些问题与具体的实施挑战有关,而其他问题则侧重于一般概念.我只是想确保我理解为什么技术X是在技术Y上发明的所有概念和原因等等.所以这里:

Http Polling:基本上是AJAX,使用XmlHttpRequest.

Http Long Polling: AJAX但服务器保持响应,除非服务器有更新,一旦服务器有更新,它发送它然后客户端可以发送另一个请求.缺点是需要来回发送额外的头数据会导致额外的开销.

Http Streaming:类似于长轮询,但是服务器使用带有"Transfer Encoding:chunked"的标头进行响应,因此每次服务器发送一些数据时我们都不需要发起新的请求(因此节省了额外的头部开销).这里的缺点是我们必须"理解"并找出数据的结构,以区分服务器发送的多个块.

Java Applet,Flash,Silverlight:它们提供了通过tcp/ip连接到套接字服务器的能力,但由于它们是插件,开发人员不希望依赖它们.

WebSockets:它们是新的API,它试图通过以下方式解决上述方法的缺点:

• 与Java Applet,Flash或Silverlight等插件相比,WebSockets的唯一优势是WebSockets本身内置于浏览器中,不依赖于插件.
• WebSockets优于http流的唯一优势是您不必努力"理解"并解析收到的数据.
• WebSockets优于长轮询的唯一优势是消除额外的标头大小以及为请求打开和关闭套接字连接.

我还缺少其他重大差异吗？如果我重新询问或将SO上已有的许多问题合并到一个问题中,我很抱歉,但我只是想从SO和网络上有关这些概念的所有信息中完全理解.

谢谢!

我已经用javascript对服务器推送进行了一些研究,并且已经找到了普遍的共识,即我正在寻找的是"Comet"设计模式.在jQuery之上构建这个模式有什么好的实现吗？如果没有,这种模式是否有任何好的实现？无论这些问题的答案如何,从实施的角度来看,是否存在关于此模式的任何文档？

我一直在寻找在浏览器中实现类似gmail的消息传递的方法,并得出了Comet的概念.但是,我还没有找到一个很好的.NET实现,允许我在IIS中执行此操作(我们的应用程序是用ASP.NET 2.0编写的).

我找到的解决方案(或者可以想到的解决方案)需要为每个用户留下一个正在运行的线程 - 这样一旦收到消息就可以向他返回响应.当然,这根本不可扩展.

所以我的问题是 - 你知道Comet的ASP.NET实现以不同的方式工作吗？这甚至可以用于IIS吗？

我正在考虑使用PHP后端实现实时聊天,但我在讨论彗星的网站上遇到了这个评论:

我的理解是,对于Comet来说,PHP是一种可怕的语言,因为Comet要求你保持对每个浏览器客户端的持久连接.使用mod_php这意味着为每个不完全扩展的客户端占用Apache全职儿童.我认识Comet的人大多使用Twisted Python,它可以处理数百或数千个同时连接.

这是真的？或者是可以配置的东西？

我正在构建一个实时Web应用程序据我所知,最受欢迎的选择是短轮询和长轮询.测量一个优于另一个有什么优点和缺点？