Comet：基于 HTTP 长连接的“服务器推”技术 Notes

这篇文章主要描述了HTTP的服务器推的技术。名词Comet是现在世界上对服务器推技术的一个称呼。 

1. 基于Flash的。Flash提供了XMLSocket类，通过和JavaScript的结合，实现Comet 

2. 基于Java Applet的。文中说到这样做是可以的，缺点就是：浏览器要装JRE插件，而且applet得到数据后无法去更新网页。这个应该是有办法的，我记得之前在google上搜索过applet和javascript通信的方法的。 

3. 基于Ajax的长轮询方式。这是我关注的一个方法。之前我用的都是一个Ajax查询，服务器返回，然后更新界面。Ajax的查询是定时发出的。如文中所说，这样做的缺点就是，由于是循环定时发出的ajax查询，所以，有可能在下次查询的之前，用户已经开始对当前数据进行操作了，而事实上，现在数据已经发生了变化而客户端不知道。简言之，这种方式用户看到的和操作的不是实时数据。最好不是客户端去定时查询，而是服务器端数据更改了，推给客户端。所以，文中用了这个方法 -- AJAX长轮询方式。说来很土，这种方法就是服务器端收到了AJAX请求后，一直不返回，直到有数据发生了更新或超时。这样，客户端的AJAX请求会一直被阻塞直到服务器返回。如果是超时返回，则客户端立马再建一个链接。很明显，这是用长连接的方式模拟“服务器推”的效果。为什么要设置超时呢？一直阻塞这不是挺好么？这是因为网络上现在有些路由器会对时间过长的连接做抛弃导致的。 

所以，这种方法不是一个新的做法，而是一种变相的比较搓的做法。有一点文中没有提到的就是，AJAX的请求和HTTP请求一样，虽然是发生在后台，但是如果后台没有返回的话，请求会阻塞其他请求，也就是说，如果AJAX的请求没返回，此时在页面上点链接，浏览器会没有反应的。我想，为了解决这个问题，只能把发出AJAX请求的JS代码放在一个单独的Frame里面，然后定义这是一个隐藏的Frame，这样，就不会阻塞其他Frame，也就是我们的界面了。 

4. 第四种方法更粗暴，就是定义一个iframe，当然这个iframe是隐藏的，界面上不可见。然后把这个iframe的src设成一个长连接请求。服务器端收到这个请求，一直阻塞直至数据发生更新或超时。这样做的缺点就是，由于服务器端一直不返回，所以浏览器会认为这个iframe一直都没有加载完，所以，在浏览器的界面中，会一直显示加载中的信息。对于这个问题，据说google解决了，因为他们的gtalk和gmail用的就是这种技术。 

这个方法的好处就是不需要用到AJAX，直接设置iframe的src为一个不返回的HTTP请求即可。本质上，和方法3，使用AJAX的差不多。 

具体看文章本身吧，见附件1。文章中还提到了，目前的HTTP都不是针对这种长连接的HTTP请求的，因为HTTP的请求链接一向都是短而快的。现在已经有一些HTTP服务器，比如Jetty，在对长连接这一块做优化。 

另外值得一提的是，文章提到了一个open source的项目 -- pushlet，这是一个Comet的实现，可以参考这个项目的网站，上面有很多Demo，演示Comet技术的，即客户端无需手动刷新，界面会自动刷新。