comet的那些事儿

现在想试着翻译一下国外的文章，最近看到comet，它是一种长时间保持Http请求允许服务器传送数据到浏览器的web应用模式。

历史

早期的JAVA Applet

嵌入Java Applet到浏览器中可能创造了两种持久性的会话，使用了TCP的套接字（Socket）在服务器和浏览器中进行持久连接。只要浏览器保持这个applet,这个套接字能够保持监听。甚至这个通知可以以任何形式传输，如文本和二进制数据，同时被这个applet解码。

第一个comet应用

即使不知道comet，然而Comet框架出现在2000年，如Pushlets,Lightstreamer和KnowNow。 Pushlets是由van den Broecke写的，是第一个开源的框架。Pushlets是基于服务端的Java servlets和客户端的JavaScript库。Bang Networks是由网景的创始人Marc Andreessen开发的，创造了整个web的标准。在2001年4月，Chip Morningstar开始开发一个基于Java的使用了两个Http套接字来保持他设计的传统的http服务端和Douglas Crockford设计的客户端；一个基础的系统在2001年6月形成。这个客户端和服务端采用了基于状态软件的传递信息的方式，并同意Crockford的建议称以JSON的形式。在整个系统中，客户库，以JSON作为通信方式和服务端，组成了正式的应用框架，其中的一部分被收购了并被Sun公司、亚马逊、EDS 和Volkswagen使用。
在2004年，Selenium Remote Control开源了！它使用了一种Comet技术在浏览器中来获取远程命令的请求。浏览器会把最后的结果返回给命令，并在相同的TCP/IP请求中获取下一条命令。如果在没有监听到命令它就会一直等待直到有一条命令然后回复。它和Selenium-RC比较类似，把浏览器变成了Sockct监听器。Selenium2是每个浏览器真正的socket监听器，所以Comet技术并没有被使用。
在2006年3月，软件工程师Alex Russell在他的个人博客上编写了Comet的规则。这些规则主要针对Ajax。
在2006年，一些应用程序将这些技术应用得更广泛：如Meebo的多协议web版聊天应用能够让用户通过浏览器连接到AOL, 雅虎, 和微软聊天平台；谷歌在Gmail、JotSpot添加web版聊天应用，基于Comet的实时协同文档编辑。新的Comet公司和企业兴起，如基于JAVA的ICEfaces JSF框架。其它在传输上基于java-applet代替了纯JavaScript实现的应用。

实现

comet应用想要消除一页一页的网页模式的限制并提供两种持续的交互来进行轮询，还在服务端和客户端使用了一种持久的HTTP连接。由于浏览器和代理端没有针对服务端进行设计，而几种实现这方面的技术得到了发展，每个都有不同的优点和缺点。其中最大的障碍就是HTTP1.1的具体协议，它倡导客户端能够在打开不同的连接时保持。所以，在为了实时交互中保持一种连接对于浏览器自身的不足上有一定不好的影响。浏览器可能会在等待之前的请求的结果的时候阻碍发送新的请求，如，我们发送很多的图片。它只是不同的主机的别名能够为实时的信息创造不同的服务名。它的策略是一个局域分享的应用。
不同的方法实现Comet主要形成了流和长轮询两种主要的方式。

流

一个请求使用流的Comet来为所有Comet事件打开从客户端浏览器到服务器的单向持久连接。在连接没有断开时，每次服务端发送新的请求这些请求在客户端不端被处理和编译。

隐藏的框架

实现动态的web应用的技术是是使用隐藏的HTML框架元素（一个内部的框架，可以允许在网站中嵌入一个HTML元素到另一种元素中）。这种隐藏的框架元素能被分为不同的部分。当传递了event事件，这个框架元素一般会包含很多的script标签，包括了在浏览器中扩展的JS代码。因为浏览器逐步编译HTML页面，每个脚本元素会在浏览器中被扩展，浏览器能够包含1-2kb大小的文件。
框架的一个优点就是它能能够在每个共同的浏览中使用。而它的两个使用下降的原因：一是没有回复错误的处理方法，二是不能获取请求过程中的路径。

XMLHttpRequest

XMLHttpRequest(XHR)，主要在浏览器到服务器的交互中使用了Ajax，同时它也能在服务器到浏览器Comet通信中为了XHR产生传统的数据格式数据。并在每次交互中使用浏览器化的JS代码，在每次它接受数据时浏览器就会释放它的状态。

长轮询的Ajax

上述的所有以流传输的浏览器都有副作用。这就促使了Comet开发者实现不同的复杂的流的传输中，同时根据浏览器来进行交互。由于Comet应用使用了长轮询，使得在浏览器在运行中，每个支持XHR的浏览器中实现更加简单。长轮询需要客户端在服务端中轮询每个事件。浏览器对服务端使用了Ajax的请求，服务端会一直保持监听直到有新的数据传递到浏览器，它还会完整的回复到浏览器。浏览器会初始化一个新的轮询请求来获取持久的事件。一些特殊的技术实现长轮询包括了以下技术：

XMLHttpRequest长轮询

在大多数情况下，XMLHttpRequest长轮询像任何的XHR的标准使用一样。浏览器会异步请求服务器，它会等待有效的数据在回复之前。这些回复能够在客户端扩展的时候包含编码数据（如XML或JSON）或者JavaScript脚本。在回复后，浏览器会创建并发送另一个XHR来等待下一个事件。浏览器经常在服务器保持一个请求来等待下一个事件发生的时候回复。

脚本标记长轮询

任何的Comet在子域中使用，但是上述的传输方式不能在不同的二级域（SLDs）中使用，因为浏览器的安全机制来阻碍跨站脚本攻击。如果二级域服务于网络主页面，Comet服务器会定位到另一个SLD,Comet事件不能通过使用这些交互机制来改变主页面的HTML和DOM。这个问题能够通过在一个或所有源数据前创造一个代理的服务器来避免。
不像框架（iframe）或XmlHttpRequest，脚本（Script）标签能够被任何URI指定，回复中的JavaScript代码会在当前的html文档中扩展。这样会对所有的服务器造成一个潜在的安全问题，然而数据提供者能够使用Jsoup来避免这些风险。
一个长轮询的Comet交互能够通过动态地新建script元素来创建，并且对Comet服务端设置源，然后再返回JavaScript和一些事件。每当脚本（Script）请求完成时，浏览器就会在XHR长轮询中打开一个新的任务。这种方式有跨浏览器的优点当允许可以跨域实现时。

译文： *https://en.wikipedia.org/wiki/Comet_(programming)*