web长链接技术个人总结

目的

我个人的目的是为了实现web上的及时通信，即在网页上实现即时聊天的效果。这种最简单来理解的话，可以使用短链接来实现。

1、短链接：jquery/php/mysql

jquery

function link(){  $.ajax({    url:"link.php",data:{yourdata},type:"post",success:function(json){alert(typeof data);doingsomeing}});settimeout("link()",5000);}link();

php

<?php//数据库信息$data=$_POST['data'];$result=mysql_query("where $data ...");//根据上传来的信息比如时间等参数查询数据库echo json_encode($result);

上边的代码无法直接使用，只是整理大概的思路。即JS通过settimeout函数不断的重新执行即向后台发送请求，后台接收到请求后根据条件查询然后返回结果。

这种方法非常好理解，但是问题是，不断的请求浪费资源，且信息不是即时的。

2、长链接:jquery/php/mysql

var ajaxdata={

url:'',

data:'',

type:'',

timeout:30000,

success:function(json){

doingsomeing

$.ajax(ajaxdata);

},

error:function(){

$.ajax(ajaxdata);

}

};

$.ajax(ajaxdata);

php

<?php

...

$i=0;
set_time_limit(0);

while(true){

usleep(500000);//延迟0.5s
$i++;
$result=mysql_query();
if($result){
$this->ajaxReturn($result,"JSON");
break;
}

if($i>=$out_time){
$msg['success']='0';
$msg['text']='';
$this->ajaxReturn($msg,"JSON");
break;
}

}

我起初认为这种长链接 其实并没有真正的解决短链接的问题，因为有两个问题，

一、当success或者error之后，会重新再次建立新连接（这个在ajax上必然的，每当一个信息从PHP返回，则发起这个信息从发起到返回已经结束了，这个ajax请求会自动结束，必须重新发送一个新的请求）。

二、在php部分是每间隔多少时间去不断的请求数据库。等于把前端的短轮询搬到了服务器上。

新手的想法：我们真正想要达到的完美的长链接，应该是前端每30秒发送一次请求，然后php端跟mysql也建立长链接，mysql数据有更新之后，php返回给js。

这中间会牵涉到js的链接问题，apache中keepalive以及keepalivetimeout的设定，php connect mysql的方法，query的方法。

目前还在寻找方法中，以上仅仅为个人暂时的理解，本人新手。解决之后会再次更新。

3、comet

Ajax本身是无法满足即时通信等富交互式应用的实时更新数据的要求的。根本原因是这种浏览器端的技术毕竟还是基于http协议，http协议要求的请求/响应的模式也是无法改变的，除非http协议本身有所改变。

以即时通信为代表的web应用程序对数据的Low Latency要求，传统的基于轮询的方式已经无法满足，而且也会带来不好的用户体验。于是一种基于http长连接的“服务器推”技术便被hack出来。这种技术被命名为Comet，这个术语由Dojo Toolkit 的项目主管Alex Russell在博文Comet: Low Latency Data for the Browser首次提出，并沿用下来。

其实，服务器推很早就存在了，在经典的client/server模型中有广泛使用，只是浏览器太懒了，并没有对这种技术提供很好的支持。但是Ajax的出现使这种技术在浏览器上实现成为可能， google的gmail和gtalk的整合首先使用了这种技术。随着一些关键问题的解决（比如 IE 的加载显示问题），很快这种技术得到了认可，目前已经有很多成熟的开源Comet框架。

comet的实现主要有两种方式，

1）基于ajax的长轮询（longpoll）方式

即浏览器发出请求，服务器直到有的新的消息之后再次返回，按照ajax长轮询或者ajax长链接能够搜索到很多相关的文章，这里边有个比较严峻的问题就是，当使用长链接，PHP后台查询数据更新所用到的不断查询，会锁表导致其他丢该数据的更新请求操作无法进行。

我使用的mysql，尝试更换引擎类型无效。

使用服务器端的数据缓存，而放弃使用数据库则太服务器压力太大，而且吃力不讨好，放弃。下边方法2中的iframe会导致浏览器一直有个小圆圈儿转到表示正在加载，虽然部分浏览器支持htmlfile可以消除，但是不支持的浏览器则无法做到，所以综合考虑，还是使用websocket吧。

2）iframe和htmlfile的流（http streaming）方式

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 产品中。

4、Websocket---未来的解决方案

         如果说Ajax的出现是互联网发展的必然，那么Comet技术的出现则更多透露出一种无奈，仅仅作为一种hack技术，因为没有更好的解决方案。Comet解决的问题应该由谁来解决才是合理的呢？浏览器，html标准，还是http标准？主角应该是谁呢？本质上讲，这涉及到数据传输方式，http协议应首当其冲，是时候改变一下这个懒惰的协议的请求/响应模式了。

W3C给出了答案，在新一代html标准html5中提供了一种浏览器和服务器间进行全双工通讯的网络技术Websocket。从Websocket草案得知，Websocket是一个全新的、独立的协议，基于TCP协议，与http协议兼容、却不会融入http协议，仅仅作为html5的一部分。于是乎脚本又被赋予了另一种能力：发起websocket请求。这种方式我们应该很熟悉，因为Ajax就是这么做的，所不同的是，Ajax发起的是http请求而已。 

与http协议不同的请求/响应模式不同，Websocket在建立连接之前有一个Handshake（Opening Handshake）过程，在关闭连接前也有一个Handshake（Closing Handshake）过程，建立连接之后，双方即可双向通信。

综上所述，推荐websocket或者comet方法。