实时Web的发展历史

传统的Web是基于HTTP的请求/响应模型的:客户端请求一个新页面,服务器将内容发送到客户端,客户端再请求另外一个页面时又要重新发送请求。后来有人提出了AJAX,AJAX使得页面的体验更加“动态”,可以在后台发起到服务器的请求。但是,如果服务器有更多数据需要推送到客户端,在页面加载完成后是无法实现直接将数据从服务器发送给客户端的。实时数据无法被“推送”给客户端。

 

为了解决这个问题,有人提出了很多解决方案。最简单(暴力)的方案是用轮询:每隔一段时间都会向服务器请求新数据。这让用户感觉应用是实时的。实际上这会造成延时和性能问题,因为服务器每秒都要处理大量的连接请求,每次请求都会有TCP三次握手并附带HTTP的头信息。尽管现在很多应用仍在使用轮询,但这并不是最理想的解决方案。

后来随着Comet技术的提出,又出现了很多更高级的解决方案。这些技术方案包括永久帧(forever frame)、XHR流(xhr-multipart)、htmlfile,以及长轮询。长轮询是指,客
户端发起一个到服务器的XHR连接,这个连接永不关闭,对客户端来说连接始终是挂起状态。当服务器有新数据时,就会及时地将响应发送给客户端,接着再将连接关闭。然后重复整个过程,通过这种方式就实现了“服务器推”(server push)。

Comet技术是非标准的hack技术,正因为此,浏览器端的兼容性就成了问题。首先,性
98 能问题无法解决,向服务器发起的每个连接都带有完整的HTTP头信息,如果你的应用需要很低的延时,这将是一个棘手的问题。当然不是说Comet本身有问题,因为还没有其他替代方案前Comet是我们的唯一选择。

 

浏览器插件(如Flash)和Java同样被用于实现服务器推。它们可以基于TCP直接和服务器建立socket连接,这种连接非常适合将实时数据推给客户端。问题是并不是所有的浏览器都安装了这些插件,而且它们常常被防火墙拦截,特别是在公司网络中。

现在HTML5规范为我们准备了一个替代方案。但这个规范稍微有些超前,很多浏览器都还不支持,特别是IE,对于现在很多开发者来说帮助不大,鉴于大部分浏览器还未实现HTML5的WebSocket,现行最好的办法仍然是使用Comet。

上一篇:(转)MySQL数据库命名规范及约定


下一篇:[Effective JavaScript 笔记]第17条:间接调用eval函数优于直接调用