爱刨根知识网

  1. 首页 > 经验知识 > >

网站即时通讯功能,WEB即时通讯4大技术

生活百科生活经验

概述1996年IETF，除了默认长连接之外就是缓存处理、带宽优化和安全性等方面的不痛不痒的改进 。它一直保留着无状态、请求/响应模式，似乎从来没意识到这应该有所改变 。
好在html5的时代已经到来，为Web端即时通讯的实现带来了WebSocket和SSE（Server-sent Events）两种技术方案 。
Ajax短轮询：脚本发送的http请求传统的web应用要想与服务器交互，必须提交一个表单（form），服务器接收并处理传来的表单，然后返回全新的页面，因为前后两个页面的数据大部分都是相同的，这个过程传输了很多冗余的数据、浪费了带宽 。于是Ajax技术便应运而生 。
Ajax是Asynchronous javaScript and XML的简称，由Jesse James Garrett 首先提出 。这种技术开创性地允许浏览器脚本（js）发送迅速被大家所接受 。
Ajax的出现使客户端与服务器端传输数据少了很多，也快了很多，也满足了以丰富用户体验为特点的web2.0时代 初期发展的需要，但是慢慢地也暴露了他的弊端 。比如无法满足即时通信等富交互式应用的实时更新数据的要求 。这种浏览器端的小技术毕竟还是基于协议本身有所改变 。
Comet：一种hack技术以即时通信为代表的web应用程序对数据的Low Latency要求，传统的基于轮询的方式已经无法满足，而且也会带来不好的用户体验 。于是一种基于首次提出，并沿用下来 。
【网站即时通讯功能,WEB即时通讯4大技术】其实，服务器推很早就存在了，在经典的client/server模型中有广泛使用，只是浏览器太懒了，并没有对这种技术提供很好的支持 。但是Ajax的出现使这种技术在浏览器上实现成为可能，google的gmail和gtalk的整合首先使用了这种技术 。随着一些关键问题的解决（比如 IE 的加载显示问题），很快这种技术得到了认可，目前已经有很多成熟的开源Comet框架 。
以下是典型的Ajax和Comet数据传输方式的对比，区别简单明了 。典型的Ajax通信方式也是则不同，客户端与服务器端保持一个长连接，只有客户端需要的数据更新时，服务器才主动将数据推送给客户端 。
Comet的实现主要有两种方式，基于Ajax的长轮询（long-polling）方式和基于 Iframe 及 htmlfile 的流（）方式 。
有关Comet技术的详细介绍文章请参见：《Comet技术详解：基于端即时通讯方案》 。
1基于Ajax的长轮询（long-polling）方式浏览器发出XML在处理请求返回信息（超时或有效数据）后再次发出请求，重新建立连接 。在此期间服务器端可能已经有新的数据到达，服务器会选择把数据保存，直到重新建立连接，浏览器会把所有数据一次性取回 。
2基于 Iframe 及 htmlfile 的流（）方式Iframe是html标记，这个标记的src属性会保持对指定服务器的长连接请求，服务器端则可以不停地返回数据，相对于第一种方式，这种方式跟传统的服务器推则更接近 。
在第一种方式中，浏览器在收到数据后会直接调用JS回调函数，但是这种方式该如何响应数据呢？可以通过在返回数据中嵌入JS脚本的方式，如“script type="text/javascript"js_func(“data from server ”)/script”，服务器端将返回的数据作为回调函数的参数，浏览器在收到数据后就会执行这段JS脚本 。
但是这种方式有一个明显的不足之处：IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成，而且 IE 上方的图标会不停的转动，表示加载正在进行 。Google 的天才们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题，并将这种方法应用到了 gmail+gtalk 产品中 。
Websocket：未来的解决方案1如果说Ajax的出现是互联网发展的必然，那么Comet技术的出现则更多透露出一种无奈，仅仅作为一种hack技术，因为没有更好的解决方案 。Comet解决的问题应该由谁来解决才是合理的呢？浏览器，html标准，还是协议应首当其冲，是时候改变一下这个懒惰的协议的请求/响应模式了 。

推荐阅读


上一篇：真三国无双7和8哪个更好_2个版本对比

下一篇：有哪些好看的av,我们学会了AV观影模式