Comet - Wikipedia（中文）
Comet
在web 开发中，Comet是一个新词来描述一种web app模型，长连接的HTTP请求，允许web Server推送数据到浏览器，而不用浏览器显式地请求。Comet是一个实现这种交互的多种技术的涵盖性术语。这些方法依赖于浏览器的默认特性，就像JavaScript，而不是非默认的插件。
在理论上，Comet方法不同于原始的web 模型，原始的web模型中浏览器请求一个完整的web页面，或者一个web页面的块。然而，实践上，Comet app一般使用长轮询的Ajax来检测server上是否有新的信息。这个概念早于这个新词的产生，也叫做Ajax Push,? Reverse Ajax,? Two-way-web, Http Streaming, 和HTTP server push。
Implementation
Comet是一个试图消除页面到页面跳转web模式和传统轮询的限制的涵盖性术语，像Comet一样的app通过持续的HTTP连接，提供实时的交互（可能不是一个长期持续的HTTP连接），给web app任命的浏览器提供更新。既然浏览器和代理不是设计成带有server event的，web app开发人员尝试了一些非计划的副作用来实现Comet一样的行为，每一种都有优点和缺点。实际上，HTTP 1.1规范声明一个浏览器不应该和一个web server同时有超过2个的连接。然而，为实时事件保持一个打开连接对浏览器的可用性有副作用。当它加载的时候可能被阻塞而不能发出一个新的请求，例如，一系列图片。为实时信息创建一个不同的主机名，就是同一台物理server的别名，可以实现这一点。
实现Comet的具体的方法分成两个范畴：streaming（流）和long polling（长轮询）。
Streaming
在一个app中使用streaming Comet，浏览器为所有的Comet事件，打开一个单独的和server的连接，在浏览器端被递增的处理。每一次server发送一个新的事件，浏览器解释它，但是两端都不关闭连接。实现streaming Comet的具体技术包括以下这些。
Hidden IFrame
动态web app一个简单技术是使用hidden IFrame HTML元素（一个内联框架，允许一个网站将一个HTML文件嵌入另一个）。这个不可见的IFrame作为长条的块发送，显式地声明它是无限长时间（有时叫做“永远的框架”）。随着事件发生，这个iframe逐步地填充script脚本，包含将在浏览器中执行的JavaScript。因为浏览器逐步地渲染HTML页面，每个script标签随着被接收到会被执行。
IFrame的一个好处是它可以工作在每种普通的浏览器中。这种技术的两种下滑趋势是缺乏一种可信任的错误处理方法，和不可能跟踪请求调用过程的状态。
XMLHttpRequest
XMLHttpRequest(XHR) 对象，是Ajax app用于浏览器-server通信的主要工具，也可以暂时用于服务器-浏览器Comet消息传送，通过一些不同的方式。
在1995年，Netscape Navigator增加一个特点叫做“server push”，允许服务器发送一个图片或HTML页面的新版本给浏览器，作为一个多部分HTTP响应的一个部分，使用multipart/x-mixed-replace content类型。自从2004年，基于Gecko的浏览器就如FireFox给XHR加入了多部分响应，它就因此可被用于一种streaming Comet传输。在服务器端，每个消息被编码成多部分响应的一个单独部分，在客户端，随着每个信息到达，提供给XHR onreadystatechange函数的回调函数会被调用。这个功能只被包含在基于Gecko的浏览器中，即使有讨论将它加入Webkit。
不是创建一个多部分的响应，依赖浏览器透明地解析每个事件，它也可能为一个XHR响应生成一个客户数据格式，用浏览器端JavaScript解析每个事件，只是依赖于浏览器每次接收新数据时打开onreadystatechange回调。
Ajax with long polling
以上streaming传输没有一个工作在所有的现代浏览器而不或多或少产生消极的副作用——迫使Comet开发者实现复杂的streaming传输，在根据浏览器的不同而转换它们。因此许多Comet app选择long polling，更容易在浏览器端实现，工作，在每个支持XHR的浏览器中。顾名思义，long polling需要客户端向服务器轮询一个事件（或者一组事件）。浏览器向服务器提出一个Ajax风格的请求，它会一直保持打开直到服务器有新的数据向浏览器发送，是以一种复杂的响应发送。浏览器为了获得随后的事件，初始化一个新的long polling请求。
实现long polling的具体技术包含以下这些。
XMLHttpRequest long polling
在很大程度上，XMLHttpRequest long polling 就像任何XHR标准的使用那样工作。浏览器向服务器提出一个异步请求，在响应之前等待数据可用。响应可以包含编码数据（一般是XML或者JSON）或者将被客户端执行的JavaScript。在响应过程的结尾，浏览器创建并发送另一个XHR，来等待下一个事件。这样浏览器总是保持比服务器多一个请求，随着每个事件发生而被答复。
Scripte tag long polling
任何Comet传输能跨子域工作，由于浏览器的设计防止跨站点脚本攻击的安全策略，以上传输没有一个可以用于跨不同的二级域（SLDs）。那就是，如果主页从一个SLD提供服务，Comet服务器位于另一个SLD，Comet事件不能使用这些传输修改主页的HTML和DOM。这个问题可以通过在一方或双方资源前创建代理服务器来避免。使他们好像是源自同一个域。然而出于复杂性和性能的原因，这个通常不受欢迎。
不像IFrame或者XMLHttpRequest对象，script 标签能在任何URL，和在响应中将在当前HTML文件执行的JavaScript代码中被指向。这就给包含的双方server产生一个潜在的安全风险，即使数据提供者的风险可以通过使用JSONP被避免。
一个long polling Comet传输能通过动态创建script元素而被创建，设置他们的source给Comet服务器的地址，正如它的有效载荷，随着一些事件发送回JavaScript(JSONP)。每次script请求完成，浏览器打开一个新的，正如在XHR long polling的情况。这个方法有可以跨浏览器和跨域实现的优点。
History
早期Java applets
略
First Comet applications
在2006年3月，软件工程师Alex Russell在他自己博客的帖子中创造了术语Comet，这个新的术语。
在2006年，不是真正使用术语Comet，一些应用暴露这些技术给更广泛的观众: Meebo的多协议基于web的聊天应用使用户可以通过浏览器联系AOL、Yahoo和Microsoft聊天平台；Google给Gmail加入基于web的聊天；JotSpot， 被Google需要而建立，创建了基于Comet实时交互的文件编辑；基于Comet的聊天是Renkoo事件计划的中心。新的Comet公司和企业解决方案被创建，就如基于Java的ICEfaces框架（即使他们喜欢术语“Ajax Push”），其他从前使用基于Java-applet的传输，取代纯JavaScript的实现。
Alternatives
Browser-native技术是Comet术语所固有的。可以从多方面尝试改进non-polling HTTP通信。
References
略
External links
??? ? ? ? ? Comparison of several comet server implementations
