版主注本文中所描述的“HTTP长连接、长轮询(long polling)” 实际上就是指Comet技术,有关Comet技术的更专业介绍请参见《Comet技术详解:基于HTTP长连接的Web端实时通信技术》。 前言在HTML5发布之前,基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,极大地增强了程序的实时性和交互性。在HTML5被众多浏览器广泛支持前,此种方式仍将是WEB端即时通讯等应用场景下,不可回避的实现方案。 现在HTML5越来越普及,你也可以了解HTML5的WebSocket从而实现WEB端真正的即时通讯技术,可供参考的文章有《Socket.IO介绍:支持WebSocket、用于WEB端的即时通讯的框架》、《socket.io实现消息推送的一点实践及思路》。当然,HTML5及其支持的WebSocket相关技术不在本文讨论范围内。 感谢本文原作者“hoojo”的分享。 更多资料Web端即时通讯新手入门贴: 《新手入门贴:详解Web端即时通讯技术的原理》 Web端即时通讯技术盘点请参见: 《Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE》 关于Ajax短轮询: 找这方面的资料没什么意义,除非忽悠客户,否则请考虑其它3种方案即可。 有关Comet技术的详细介绍请参见: 《Comet技术详解:基于HTTP长连接的Web端实时通信技术》 《WEB端即时通讯:HTTP长连接、长轮询(long polling)详解》 《WEB端即时通讯:不用WebSocket也一样能搞定消息的即时性》 《开源Comet服务器iComet:支持百万并发的Web端即时通讯方案》 有关WebSocket的详细介绍请参见: 《WebSocket详解(一):初步认识WebSocket技术》 《WebSocket详解(二):技术原理、代码演示和应用案例》 《WebSocket详解(三):深入WebSocket通信协议细节》 《Socket.IO介绍:支持WebSocket、用于WEB端的即时通讯的框架》 《socket.io和websocket 之间是什么关系?有什么区别?》 有关SSE的详细介绍文章请参见: 《SSE技术详解:一种全新的HTML5服务器推送事件技术》 更多WEB端即时通讯文章请见: http://www.52im.net/forum.php?mod=collection&action=view&ctid=15 长连接、长轮询概述用通俗易懂的话来说,长连接、长轮询就是客户端不停的向服务器发送请求以获取最新的数据信息。这里的“不停”其实是有停止的,只是我们人眼无法分辨是否停止,它只是一种快速的停下然后又立即开始连接而已。 长连接、长轮询多用在什么样的情况下长连接、长轮询一般应用与WebIM、ChatRoom和一些需要及时交互的网站应用中。其真实案例有:WebQQ、Hi网页版、Facebook IM等。 如果你对服务器端的反向Ajax感兴趣,可以参考这篇文章 DWR 反向Ajax 服务器端推的方式:http://www.cnblogs.com/hoojo/category/276235.html 相关技术优缺点对比轮询:客户端定时向服务器发送Ajax请求,服务器接到请求后马上返回响应信息并关闭连接。 优点:后端程序编写比较容易。 缺点:请求中有大半是无用,浪费带宽和服务器资源。 实例:适于小型应用。 长轮询:客户端向服务器发送Ajax请求,服务器接到请求后hold住连接,直到有新消息才返回响应信息并关闭连接,客户端处理完响应信息后再向服务器发送新的请求。 优点:在无消息的情况下不会频繁的请求,耗费资源小。 缺点:服务器hold连接会消耗资源,返回数据顺序无保证,难于管理维护。 实例:WebQQ、Hi网页版、Facebook IM。 长连接:在页面里嵌入一个隐蔵iframe,将这个隐蔵iframe的src属性设为对一个长连接的请求或是采用xhr请求,服务器端就能源源不断地往客户端输入数据。 优点:消息即时到达,不发无用请求;管理起来也相对方便。 缺点:服务器维护一个长连接会增加开销。 实例:Gmail聊天 Flash Socket:在页面中内嵌入一个使用了Socket类的 Flash 程序JavaScript通过调用此Flash程序提供的Socket接口与服务器端的Socket接口进行通信,JavaScript在收到服务器端传送的信息后控制页面的显示。 优点:实现真正的即时通信,而不是伪即时。 缺点:客户端必须安装Flash插件;非HTTP协议,无法自动穿越防火墙。 实例:网络互动游戏。 长连接、长轮询的技术原理所谓长连接,就是要在客户端与服务器之间创建和保持稳定可靠的连接。其实它是一种很早就存在的技术,但是由于浏览器技术的发展比较缓慢,没有为这种机制的实现提供很好的支持。所以要达到这种效果,需要客户端和服务器的程序共同配合来完成。通常的做法是,在服务器的程序中加入一个死循环,在循环中监测数据的变动。当发现新数据时,立即将其输出给浏览器并断开连接,浏览器在收到数据后,再次发起请求以进入下一个周期,这就是常说的长轮询(long-polling)方式。 如下图所示,它通常包含以下几个关键过程: <ignore_js_op> 通讯时序参见上图,大致是按照如下方式进行: > 1. 轮询的建立 建立轮询的过程很简单,浏览器发起请求后进入循环等待状态,此时由于服务器还未做出应答,所以HTTP也一直处于连接状态中。 > 2. 数据的推送 在循环过程中,服务器程序对数据变动进行监控,如发现更新,将该信息输出给浏览器,随即断开连接,完成应答过程,实现“服务器推”。 > 3. 轮询的终止 轮询可能在以下3种情况时终止:
> 4. 轮询的重建 浏览器收到回复并进行相应处理后,应马上重新发起请求,开始一个新的轮询周期。 代码实现范例1普通轮询 Ajax方式【客户端代码片段】:
客户端实现的就是用一种普通轮询的结果,比较简单。利用setInterval不间断的刷新来获取服务器的资源,这种方式的优点就是简单、及时。缺点是链接多数是无效重复的;响应的结果没有顺序(因为是异步请求,当发送的请求没有返回结果的时候,后面的请求又被发送。而此时如果后面的请求比前面的请求要先返回结果,那么当前面的请求返回结果数据时已经是过时无效的数据了);请求多,难于维护、浪费服务器和网络资源。 【服务器端代码】:
服务器端实现,这里就模拟下程序监控数据的变化。上面代码属于SpringMVC 中controller中的一个方法,相当于Servlet中的一个doPost/doGet方法。如果没有程序环境适应servlet即可,将方法体中的代码copy到servlet的doGet/doPost中即可。 【服务器端在进行长连接的程序设计时,要注意以下几点】: 1. 服务器程序对轮询的可控性 由于轮询是用死循环的方式实现的,所以在算法上要保证程序对何时退出循环有完全的控制能力,避免进入死循环而耗尽服务器资源。 2. 合理选择“心跳”频率 从图1可以看出,长连接必须由客户端不停地进行请求来维持,所以在客户端和服务器间保持正常的“心跳”至为关键,参数POLLING_LIFE应小于WEB服务器的超时时间,一般建议在10~20秒左右。 3. 网络因素的影响 在实际应用时,从服务器做出应答,到下一次循环的建立,是有时间延迟的,延迟时间的长短受网络传输等多种因素影响,在这段时间内,长连接处于暂时断开的空档,如果恰好有数据在这段时间内发生变动,服务器是无法立即进行推送的,所以,在算法设计上要注意解决由于延迟可能造成的数据丢失问题。 4. 服务器的性能 在长连接应用中,服务器与每个客户端实例都保持一个持久的连接,这将消耗大量服务器资源,特别是在一些大型应用系统中更是如此,大量并发的长连接有可能导致新的请求被阻塞甚至系统崩溃,所以,在进行程序设计时应特别注意算法的优化和改进,必要时还需要考虑服务器的负载均衡和集群技术。 【代码执行情况】: <ignore_js_op> 上图是返回的结果,可以看到先发出请求,不一定会最先返回结果。这样就不能保证顺序,造成脏数据或无用的连接请求。可见对服务器或网络的资源浪费。 2普通轮询 iframe方式
这里的客户端程序是利用隐藏的iframe向服务器端不停的拉取数据,将iframe获取后的数据填充到页面中即可。同ajax实现的基本原理一样,唯一不同的是当一个请求没有响应返回数据的情况下,下一个请求也将开始,这时候前面的请求将被停止。如果要使程序和上面的ajax请求一样也可以办到,那就是给每个请求分配一个独立的iframe即可。 下面是程序执行时返回的结果: <ignore_js_op> 其中红色是没有成功返回请求就被停止(后面请求开始)掉的请求,黑色是成功返回数据的请求。 3长连接iframe方式
这个轮询方式就是把刚才上面的稍微改下,每个请求都有自己独立的一个iframe,当这个iframe得到响应的数据后就把数据push到当前页面上。使用此方法已经类似于ajax的异步交互了,这种方法也是不能保证顺序的、比较耗费资源、而且总是有一个加载的条在地址栏或状态栏附件(当然要解决可以利用htmlfile,Google的攻城师们已经做到了,网上也有封装好的lib库),但客户端实现起来比较简单。 <ignore_js_op> 如果要保证有序,可以不使用setInterval,将创建iframe的方法放在load事件中即可,即使用递归方式。调整后的代码片段如下:
这种方式虽然保证了请求的顺序,但是它不会处理请求延时的错误或是说很长时间没有返回结果的请求,它会一直等到返回请求后才能创建下一个iframe请求,总会和服务器保持一个连接。和以上轮询比较,缺点就是消息不及时,但保证了请求的顺序。 4ajax实现长连接
上面这段代码就是才有Ajax的方式完成长连接,主要优点就是和服务器始终保持一个连接。如果当前连接请求成功后,将更新数据并且继续创建一个新的连接和服务器保持联系。如果连接超时或发生异常,这个时候程序也会创建一个新连接继续请求。这样就大大节省了服务器和网络资源,提高了程序的性能,从而也保证了程序的顺序。 <ignore_js_op> 写在最后现代的浏览器都支持跨域资源共享(Cross-Origin Resource Share,CORS)规范,该规范允许XHR执行跨域请求,因此基于脚本的和基于iframe的技术已成为了一种过时的需要。 把Comet做为反向Ajax的实现和使用的最好方式是通过XMLHttpRequest对象,该做法提供了一个真正的连接句柄和错误处理。当然你选择经由HTTP长轮询使用XMLHttpRequest对象(在服务器端挂起的一个简单的Ajax请求)的Comet模式,所有支持Ajax的浏览器也都支持该种做法。 基于HTTP的长连接技术,是目前在纯浏览器环境下进行即时交互类应用开发的理想选择,随着浏览器的快速发展,html5将为其提供更好的支持和更广泛的应用。在html5中有一个websocket 可以很友好的完成长连接这一技术,网上也有相关方面的资料,这里也就不再做过多介绍。 全站即时通讯技术资料分类[1] 网络编程基础资料: 《TCP/IP详解 - 第11章·UDP:用户数据报协议》 《TCP/IP详解 - 第17章·TCP:传输控制协议》 《TCP/IP详解 - 第18章·TCP连接的建立与终止》 《TCP/IP详解 - 第21章·TCP的超时与重传》 《理论经典:TCP协议的3次握手与4次挥手过程详解》 《理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程》 《计算机网络通讯协议关系图(中文珍藏版)》 《NAT详解:基本原理、穿越技术(P2P打洞)、端口老化等》 《UDP中一个包的大小最大能多大?》 《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》 《NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战》 《NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战》 >> 更多同类文章 …… [2] 有关IM/推送的通信格式、协议的选择: 《为什么QQ用的是UDP协议而不是TCP协议?》 《移动端即时通讯协议选择:UDP还是TCP?》 《如何选择即时通讯应用的数据传输格式》 《强列建议将Protobuf作为你的即时通讯应用数据传输格式》 《移动端IM开发需要面对的技术问题(含通信协议选择)》 《简述移动端IM开发的那些坑:架构设计、通信协议和客户端》 《理论联系实际:一套典型的IM通信协议设计详解》 《58到家实时消息系统的协议设计等技术实践分享》 >> 更多同类文章 …… [3] 有关IM/推送的心跳保活处理: 《Android进程保活详解:一篇文章解决你的所有疑问》 《Android端消息推送总结:实现原理、心跳保活、遇到的问题等》 《为何基于TCP协议的移动端IM仍然需要心跳保活机制?》 《微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)》 《微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)》 《移动端IM实践:实现Android版微信的智能心跳机制》 《移动端IM实践:WhatsApp、Line、微信的心跳策略分析》 >> 更多同类文章 …… [4] 有关WEB端即时通讯开发: 《新手入门贴:史上最全Web端即时通讯技术原理详解》 《Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE》 《SSE技术详解:一种全新的HTML5服务器推送事件技术》 《Comet技术详解:基于HTTP长连接的Web端实时通信技术》 《WebSocket详解(一):初步认识WebSocket技术》 《socket.io实现消息推送的一点实践及思路》 >> 更多同类文章 …… [5] 有关IM架构设计: 《浅谈IM系统的架构设计》 《简述移动端IM开发的那些坑:架构设计、通信协议和客户端》 《一套原创分布式即时通讯(IM)系统理论架构方案》 《从零到卓越:京东客服即时通讯系统的技术架构演进历程》 《蘑菇街即时通讯/IM服务器开发之架构选择》 《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》 《微信技术总监谈架构:微信之道——大道至简(演讲全文)》 《如何解读《微信技术总监谈架构:微信之道——大道至简》》 《快速裂变:见证微信强大后台架构从0到1的演进历程(一)》 《17年的实践:腾讯海量产品的技术方法论》 >> 更多同类文章 …… [6] 有关IM安全的文章: 《即时通讯安全篇(一):正确地理解和使用Android端加密算法》 《即时通讯安全篇(二):探讨组合加密算法在IM中的应用》 《即时通讯安全篇(三):常用加解密算法与通讯安全讲解》 《即时通讯安全篇(四):实例分析Android中密钥硬编码的风险》 《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》 《理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)》 《微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解》 《来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享》 >> 更多同类文章 …… [7] 有关实时音视频开发: 《即时通讯音视频开发(一):视频编解码之理论概述》 《即时通讯音视频开发(二):视频编解码之数字视频介绍》 《即时通讯音视频开发(三):视频编解码之编码基础》 《即时通讯音视频开发(四):视频编解码之预测技术介绍》 《即时通讯音视频开发(五):认识主流视频编码技术H.264》 《即时通讯音视频开发(六):如何开始音频编解码技术的学习》 《即时通讯音视频开发(七):音频基础及编码原理入门》 《即时通讯音视频开发(八):常见的实时语音通讯编码标准》 《即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述》 《即时通讯音视频开发(十):实时语音通讯的回音消除技术详解》 《即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解》 《即时通讯音视频开发(十二):多人实时音视频聊天架构探讨》 《即时通讯音视频开发(十三):实时视频编码H.264的特点与优势》 《即时通讯音视频开发(十四):实时音视频数据传输协议介绍》 《即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况》 《即时通讯音视频开发(十六):移动端实时音视频开发的几个建议》 《即时通讯音视频开发(十七):视频编码H.264、V8的前世今生》 《简述开源实时音视频技术WebRTC的优缺点》 《良心分享:WebRTC 零基础开发者教程(中文)》 >> 更多同类文章 …… [8] IM开发综合文章: 《移动端IM开发需要面对的技术问题》 《开发IM是自己设计协议用字节流好还是字符流好?》 《请问有人知道语音留言聊天的主流实现方式吗?》 《IM系统中如何保证消息的可靠投递(即QoS机制)》 《谈谈移动端 IM 开发中登录请求的优化》 《完全自已开发的IM该如何设计“失败重试”机制?》 《微信对网络影响的技术试验及分析(论文全文)》 《即时通讯系统的原理、技术和应用(技术论文)》 《开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀》 >> 更多同类文章 …… [9] 开源移动端IM技术框架资料: 《开源移动端IM技术框架MobileIMSDK:快速入门》 《开源移动端IM技术框架MobileIMSDK:常见问题解答》 《开源移动端IM技术框架MobileIMSDK:压力测试报告》 《开源移动端IM技术框架MobileIMSDK:Android版Demo使用帮助》 《开源移动端IM技术框架MobileIMSDK:Java版Demo使用帮助》 《开源移动端IM技术框架MobileIMSDK:iOS版Demo使用帮助》 《开源移动端IM技术框架MobileIMSDK:Android客户端开发指南》 《开源移动端IM技术框架MobileIMSDK:Java客户端开发指南》 《开源移动端IM技术框架MobileIMSDK:iOS客户端开发指南》 《开源移动端IM技术框架MobileIMSDK:Server端开发指南》 >> 更多同类文章 …… [10] 有关推送技术的文章: 《iOS的推送服务APNs详解:设计思路、技术原理及缺陷等》 《Android端消息推送总结:实现原理、心跳保活、遇到的问题等》 《扫盲贴:认识MQTT通信协议》 《一个基于MQTT通信协议的完整Android推送Demo》 《求教android消息推送:GCM、XMPP、MQTT三种方案的优劣》 《移动端实时消息推送技术浅析》 《扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别》 《绝对干货:基于Netty实现海量接入的推送服务技术要点》 《移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)》 《为何微信、QQ这样的IM工具不使用GCM服务推送消息?》 >> 更多同类文章 …… [11] 更多即时通讯技术好文分类: http://www.52im.net/forum.php?mod=collection&op=all (原文链接:http://www.cnblogs.com/hoojo/p/longPolling_comet_jquery_iframe_ajax.html) |