Http被设计成了一个单向的通信的协议,即客户端发起一个request,然后服务器回应一个response。这让服务器很为恼火:我特么才是老大,我居然不能给小弟发消息。。。

轮询

  老大发火了,小弟们自然不能无动于衷,为了能及时获得老大的消息,小弟们只好每隔一段时间跑去老大那里问问,有没有新的指示发出。这便是最早实现实时获得服务器数据的技术轮询(Polling)。

  客户端通过ajax不停去向服务器获得数据,检查是否有新的数据更新。这种使用轮询实现一种伪实时的状态很容易,但效率偏低,一般而言,这种实时获得的数据,本身数据量不是非常大,而通过这种反复地发起request的方式,往往造成的可能是http的header信息比数据本身还多,而且大多数时候获得的数据都是重复无用的。(据说最早还有通过不断刷新客户端页面,来实现web实时通信的情况~ 我想应该木有哪个客户会受得了这种体验。)

Comet

  “不值啊!咱哥几个每天跑来跑去。拿到的都是一堆没用的数据。”

  于是大家坐在一起想,有什么好办法能不用老是跑腿又可以获得新的信息及时行动呢?小的们灵机一动,下次我们跑去老大那里等着,等他老人家下了命令再回来。这就是基于 AJAX 的长轮询(long-polling)方式实现的一种comet方式。因为ajax的调用是异步的,我们可以在页面加载完毕之后,发起一个request请求,服务器端会阻塞request直到有数据传递或超时(timeout)才返回。客户端处理完服务器返回的信息后,再次发出请求,重新建立连接。这样周而复始。

  基于 AJAX 的long-polling

  另外还有一种comet模型,他的名字玄乎比长轮询邪乎的多。。。叫The forever iframe technique。这名儿听起来就高大上很多。其实就是在页面中隐藏一个iframe标签,然后将这个iframe的 SRC 属性设为对一个长连接的请求,服务器端就能源源不断地往客户端输入数据。但是这种方法有一个很明显的问题,各个浏览器会一直显示页面加载没有完成,如果用户是个强迫症,他一定会分分钟关掉页面的。TAT......

 forever iframe技术

  不管怎么样comet技术第一次实现了真正的实时通信,而且能支持大量用户,小的们从此总是能准确地获得老大的消息了。但是comet不会是一个没有副作用的解决方案,由于长期占用连接,让web丧失了无状态高并发的特点,大量消耗了服务器带宽和资源。

WebSocket登场

  “跑来跑去真是麻烦诶~http肿么这么麻烦呀。咱们和老大之间整个新协议吧。”  

  这个想法在小弟们中炸开了锅!!! 在大家的千呼万唤中,WebSocket协议登场了。哈哈哈哈哈~让我来拯救各位吧~~~~

  WebSocket协议是HTML5定义的一种新协议,它实现了浏览器与服务器全双工通信(full-duplex)。通过浏览器发出websocket连线请求,然后服务器发出回应,建立一个联系的通道。小的们只用发个信息问老大:“首长好~”,老大回一个信儿:“同志们辛苦了!”这样握手(handshaking)就完成了,websocket连线完成,通过websocket,我们可以完成真正的实时通信了。

  websocket允许通过JavaScript建立与远程服务器的连接,从而实现客户端与服务器间双向的通信。在websocket中有两个方法:  

    1、send() 向远程服务器发送数据

    2、close() 关闭该websocket链接

  websocket同时还定义了几个监听函数    

    1、onopen 当网络连接建立时触发该事件

    2、onerror 当网络发生错误时触发该事件

    3、onclose 当websocket被关闭时触发该事件

    4、onmessage 当websocket接收到服务器发来的消息的时触发的事件,也是通信中最重要的一个监听事件。

  websocket还定义了一个readyState属性,这个属性可以返回websocket所处的状态:

    1、CONNECTING(0) websocket正尝试与服务器建立连接

    2、OPEN(1) websocket与服务器已经建立连接

    3、CLOSING(2) websocket正在关闭与服务器的连接

    4、CLOSED(3) websocket已经关闭了与服务器的连接

  websocket的url开头是ws,如果需要ssl加密可以使用wss,当我们调用websocket的构造方法构建一个websocket对象(new WebSocket(url))的之后,就可以进行即时通信了。

  

  哈哈哈哈哈哈~老大通过websocket发话了:

    晚上请吃饭!

  小弟们赶紧行动起来~

总结

  相比comet技术,websocket不仅节约了header的问题(websocket的head信息只有短短的2个字节)。更加重要的是是通信的稳定性,comet在遇到网络问题之后,想要在不刷新页面的情况下恢复通信,非常困难,而websocket中提供了onclose函数来处理断开网络后的情况,这为我们与服务器的通信提供了可靠的保障。在github上有一个js库(https://github.com/joewalnes/reconnecting-websocket)就是通过这种方式来处理websocket断网重连。

  websocket端口,一个隧道就可能通过你的浏览器建立。这样做很可能最终绕过防火墙,并且允许访问内部内容。所以安全问题,也是websocket现在面临的一大隐患。

最新文章

  1. CYQ.Data V5 从入门到放弃ORM系列:教程 - Log、SysLogs两个日志类使用
  2. Unity3d中Update()方法的替身
  3. Nginx for Windows 使用笔记
  4. mysql++的release版本当机的问题
  5. php ajax json jquery 记录
  6. [翻译]创建ASP.NET WebApi RESTful 服务(9)
  7. NGUI监听事件
  8. 路由页面缓存开启 以及 keep-alive 给你埋下的坑
  9. Linux sftp 另外一台机器时,出现:receive message is too long
  10. Java基本数据类型和长度
  11. Metrics-server插件安装配置
  12. 王之泰201771010131《面向对象程序设计(java)》第六周学习总结
  13. 线程简述(Thread)
  14. 一致性hash(整理版)
  15. JSP用户登录页面
  16. rpc、socket、mq
  17. 奇怪的bug,不懂Atom在添加markdown-themeable-pdf,在配置好phantomjs的情况下报错
  18. ASP.NET WebForm 与 IE10、IE11
  19. 变量不加 var 声明——掉进坑中,无法自拔!
  20. [转]Android 如何根据网络地址获取网络图片方法

热门文章

  1. C# DateTime与时间戳转换
  2. Restful资源文章
  3. 如何一步一步用DDD设计一个电商网站(七)—— 实现售价上下文
  4. JS核心系列:浅谈函数的作用域
  5. UML课程复习重点
  6. ABP文档 - Javascript Api - AJAX
  7. PHP数据类型之间的强制转换
  8. System.FormatException: GUID 应包含带 4 个短划线的 32 位数(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)。
  9. 协议森林17 我和你的悄悄话 (SSL/TLS协议)
  10. 解构C#游戏框架uFrame兼谈游戏架构设计