comet 异步请求技术中相关关键字解释 (新手向)

最近想在产品中加入即时通信的功能.BS架构的程序.实现方式不外乎两大标准下的各类奇淫技巧.

这两大标准就是 HTML5 HTML4

为啥这两个呢..由于HTML5里面有websocket.这个完全颠覆http请求的东西,使得请求再也不是无状态的.

固然websocket目前支持不是很好.也没办法.看着好东西无法用.这是一种何种的煎熬....搞得我老是想在产品里面内嵌chromeFrame.而后强制给客户装上.哈哈...固然客户没准会和我拼命呢...

没办法,在现有的需求中基本上,实现思路只有一个了.也就是第一个让我头疼了一阵的关键词

"轮询"

这词看上去很高级的样子,其实就是写个ajax间隔一段时间不断向服务器请求内容.这活谁都干过.

而后我就想啊.若是用轮询实现,那也显得过低级了吧.怎么着.咱得弄个高级点的技巧显摆显摆..因而,查了一番资料,一个更加装逼的词语蹦到了偶的眼前

"长轮询"

看,变长了果真不同了.这个词还伴随着一个英文

"comet"

其实原理很简单.以往的web请求,服务器处理请求后要当即返回,尽管超时的时间也能到达30秒这么多(并非说用了comet才能够容许链接在服务器等待,我也可让链接在服务器端sleep).可是链接只能存在于本次请求中.没法保持住.而comet容许链接请求过来后被保持住(保存起来,如session里面).当我须要的时候,读出来再返回给客户端数据.因此这种状况的所谓的"长"长在了服务器端.

长轮询比轮询的好处在于,若是像是即时通信,聊天室一类的应用,轮询并不能保证每次查阅服务器必定有数据须要返回,因此会形成不少没用的请求到达服务器.而长轮询由于链接保持在了服务器,须要的时候激活就能够.因此就省去了不少没用的请求.

长轮询适合那些数据反映须要及时,可是数据量不大的场景.好比站内消息.其实聊天室不是多么适合.由于人多的时候.长轮询和轮询没啥区别.因此,对于服务器与浏览器交互密集型的实时场景.长轮询并不能减小多余的请求.

长轮询使用ajax实现浏览器响应.其实也可使用隐藏的iframe来作.毕竟那个奇葩的IE是咱们不得不兼容的.

用iframe 模拟ajax请求的这种 叫作 "iframe streaming"

对于交互密集型实时场景.还有没有办法优化.还真有.

对于 Servlet3 的 AsynContext 关闭有两种状况.一种是正常的complete.另外一种就是dispatch.

complete很容易理解.完成后.浏览器继续请求一次.这叫长链接.

若是不complete.而dispatch到自身.数据会返回到客户端.可是链接并不须要再次请求.dispatch后的请求仍然能够继续返回到客户端.

因此这种请求方式只须要客户端发起一次请求就能够了.

可是.好事多磨.对于前台来讲.因为链接被dispatch.ajax会报错.(听说FF仍是op.容许ajax继续处理请求,我试验的chrome,报错了,若是谁成功了,必定告诉我.)

可是.咱们可使用隐藏的iframe来接收这些请求.就能够正常使用了.固然.浏览器的加载按钮会一直转啊转啊..

我我的比较喜欢dispatch这种方式.奇淫技巧很唬人啊.适合忽悠刚入职的小朋友们哈哈..