Chinaunix首页 | 论坛 | 博客
  • 博客访问: 453756
  • 博文数量: 153
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1575
  • 用 户 组: 普通用户
  • 注册时间: 2016-12-20 17:02
文章分类

全部博文(153)

文章存档

2017年(111)

2016年(42)

我的朋友

分类: JavaScript

2017-01-11 18:02:22

为什么实时Web这么重要?我们生活在一个实时(real-time)的世界中,因此Web的最终最自然的状态也应当是实时的。用户需要实时的沟通、数据和搜索。我们对互联网信息实时性的要求也越来越高,如果信息或消息延时几分钟后才更新,简直让人无法忍受。现在很多大公司(如Google、Facebook和Twitter)已经开始关注实时Web,并提供了实时**。实时Web将是未来最热门的话题之一。

实时Web的发展历史

  传统的Web是基于HTTP的请求/响应模型的:客户端请求一个新页面,服务器将内容发送到客户端,客户端再请求另外一个页面时又要重新发送请求。后来有人提出了AJAX,AJAX使得页面的体验更加“动态”,可以在后台发起到服务器的请求。但是,如果服务器有更多数据需要推送到客户端,在页面加载完成后是无法实现直接将数据从服务器发送给客户端的。实时数据无法被“推送”给客户端。
  为了解决这个问题,有人提出了很多解决方案。最简单(暴力)的方案是用轮询:每隔一段时间都会向服务器请求新数据。这让用户感觉应用是实时的。实际上这会造成延时和性能问题,因为服务器每秒都要处理大量的连接请求,每次请求都会有TCP三次握手并附带HTTP的头信息。尽管现在很多应用仍在使用轮询,但这并不是最理想的解决方案。
  后来随着Comet技术的提出,又出现了很多更高级的解决方案。这些技术方案包括永久帧(forever frame)、XHR流(xhr-multipart)、htmlfile,以及长轮询。长轮询是指,客户端发起一个到服务器的XHR连接,这个连接永不关闭,对客户端来说连接始终是挂起状态。当服务器有新数据时,就会及时地将响应发送给客户端,接着再将连接关闭。然后重复整个过程,通过这种方式就实现了“服务器推”(server push)。
  Comet技术是非标准的hack技术,正因为此,浏览器端的兼容性就成了问题。首先,性能问题无法解决,向服务器发起的每个连接都带有完整的HTTP头信息,如果你的应用需要很低的延时,这将是一个棘手的问题。当然不是说Comet本身有问题,因为还没有其他替代方案前Comet是我们的唯一选择。
  浏览器插件(如Flash)和Java同样被用于实现服务器推。它们可以基于TCP直接和服务器建立socket连接,这种连接非常适合将实时数据推给客户端。问题是并不是所有的浏览器都安装了这些插件,而且它们常常被防火墙拦截,特别是在公司网络中。
  现在HTML5规范为我们准备了一个替代方案。但这个规范稍微有些超前,很多浏览器都还不支持,特别是IE,对于现在很多开发者来说帮助不大,鉴于大部分浏览器还未实现HTML5的WebSocket,现行最好的办法仍然是使用Comet。

WebSocket

  WebSockethttp://dev.w3.org/html5/websockets)是HTML5规范()的一部分,提供了基于TCP的双向的、全双工的socket连接。这意味着服务器可以直接将数据推送给客户端,而不需要开发者求助于长轮询或插件来实现,这是一个很大的进步。尽管有一些浏览器实现了WebSocket,但由于一些安全问题没有解决,因此协议()仍然在修订之中。然而这不会阻碍我们的脚步,这些安全问题属于技术性问题,会很快被修复,WebSocket很快就会成为最终规范。与此同时,对于那些不支持WebSocket的浏览器,可以降级使用笨方法来实现,比如Comet或轮询。
  和之前的服务器推的技术相比,WebSocket有着巨大的优势,因为WebSocket是全双工的,而不是基于HTTP的,一旦建立连接就不会断掉。Comet所面对的现实问题就是HTTP的体积太大,每个请求都带有完整的HTTP头信息。而且包含很多没有用的TCP握手,因为HTTP是比TCP更高层次的网络协议。
阅读全文请点击:

阅读(1436) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~