WEB端即时通讯：不用WebSocket也一样能搞定消息的即时性

版主注

本文中所描述的“真正实时的HTTP长连接” 实际上就是指Comet技术，有关Comet技术的更专业介绍请参见《Comet技术详解：基于HTTP长连接的Web端实时通信技术》。

前言

当前，随着HTML5的推广，在设计WEB端IM的方案时，越来越多的人正在考虑使用WebSocket技术，但在HTML5被众多浏览器广泛支持前，经典的WEB长轮询仍将是WEB端即时通讯等应用场景下不可回避的实现方案。

不过，很多人眼中的WEB端长轮询就是定时傻傻地去服务端拉消息，多数时候都是在做无用工（请参见此文：《WEB端即时通讯：经典长连接、长轮询（long polling）详解》），但本文要介绍的长连接方式与此有些区别，请继续耐心读完。

现在HTML5越来越普及，你也可以了解HTML5的WebSocket从而实现WEB端真正的即时通讯技术，可供参考的文章有《Socket.IO介绍：支持WebSocket、用于WEB端的即时通讯的框架》、《socket.io实现消息推送的一点实践及思路》。当然，HTML5及其支持的WebSocket相关技术不在本文讨论范围内。

更多资料

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通信协议细节》
《WebSocket详解（四）：刨根问底HTTP与WebSocket的关系(上篇)》
《WebSocket详解（五）：刨根问底HTTP与WebSocket的关系(下篇)》
《WebSocket详解（六）：刨根问底WebSocket与Socket的关系》
《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

一、WEB端即时通讯如何实现消息推送

通常有三种方式实现推送通道：

• WebSocket
• FlashSocket
• http轮询
  

其中1）和2）是用TCP长连接实现的，其消息的实时性很好理解，但这两种方案都存在一些局限性，因为浏览器的兼容性问题导致并不通用（即时通讯网注：目前一个封了WebSocket的开源工程Socket.io正致力于解决这些问题，详情请查看：http://www.52im.net/thread-190-1-1.html）。

3）才算是web端IM实现消息推送的“正统”方案，用http短连接轮询的方式实现“伪长连接”，既然是轮询，有朋友就对消息的实时性产生了质疑。本文就是要解答，web端IM使用http长轮询如何保证消息的绝对实时性。

二、对HTTP长轮询无法实现实时性的误解

什么是轮询？

举个栗子，在火车上想上洗手间，挤到洗手间旁，却发现洗手间有人，于是你只能回座位继续等。过了N分钟，又朝洗手间的方向挤过去，却发现洗手间还是有人，又只能回坐等。这么一而再，再而三的每隔N分钟去洗手间查看洗手间是否有蹲位，这就是轮询。

WEB端IM用轮询的方式拉取消息会存在什么问题？

WEB端IM每隔N分钟，轮询调用 “获取消息”接口，有可能出现消息的延时，某一时刻刚拉取完消息，突然又产生了一条新消息，这条消息就必须等到N分钟之后，再次发起“获取消息”轮询时，才有机会获取到。

减小轮询时间间隔是否能解决消息延时的问题？

减小轮询时间间隔的确可以缩短延时时间，但也不能保证消息绝对的实时，同时又会产生新的副作用，绝大部分的轮询调用，都没有消息返回，造成服务端极大的资源浪费。

很多人基于上述直觉，认为web端im使用http长轮询的方式拉取消息，会导致消息有延时，其实，web端im的http长轮询根本不是这么玩的。

三、HTTP长轮询到底该怎么玩？

1建立一条HTTP连接

web端im和web server之间建立一条http连接，专门用作消息通道，这条连接叫http消息连接【见下图】：

24步实现真正实时的HTTP长连接

1）没有消息到达的时候，这个http消息连接将被夯住，不返回，由于http是短连接，这个http消息连接最多被夯住90秒，就会被断开（这是浏览器或者web server的行为）。

2）在1）的情况下，如果http消息连接被断开，立马再发起一个http消息连接【见下图中的步骤1、2】：


3）在1）和2）的配合下，浏览器与web server之间将永远有一条消息连接在（极限情况下会出现情况4）），每次收到消息时，这个消息连接就能及时将消息带回浏览器页面，并且在返回后，会立马再发起一个http消息连接【见下图中的步骤1、2、3】：


4）如果消息到达时，上一个http消息连接正在返回，没有http消息连接可用（理论上http消息连接的返回是瞬时的，没有连接可用出现的概率极小），则将消息暂存入消息池中，下一个消息连接到达后（上一个消息连接返回后，根据2）和3）会立马返回新的消息连接，无等待时间），将消息带回，并又立刻返回生成新的消息连接【见下图中的步骤1、2、3、4、5、6、7】：


上述1-4就能够保证一直有一条http消息连接在，以保证WEB端IM消息推送的绝对实时性。

四、总结

WEB端IM通过http长轮询可以保证消息的绝对实时性。这种实时性的保证不是通过增加轮询频率来保证的，而是通过夯住http消息连接来保证的，在大部分时间没有实时消息的情况下，这个http消息连接对于web server的请求压力是90秒1次，能够大大节省了web服务器资源。

五、更多资料

WEB端IM资料精选：http://www.52im.net/forum.php?mod=collection&action=view&ctid=15
更多IM开发资料：http://www.52im.net/forum.php?mod=collection&action=view&ctid=10
更多技术合辑：http://www.52im.net/forum.php?mod=collection&op=all

全站即时通讯技术资料分类

[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.habadog.com/2015/04/28/webim-msg-ontime/）

一个http连接服务端故意不返回的情况下可以hold住90秒？这90秒是htt协议规定的吗？不是据说http超时是30秒吗？谁能给个解释？

如果真是像文中所说的能hold住90秒，而且没有额外负载的话，貌似真的可行！

引用：HelloKing 发表于 2016-05-11 13:55
一个http连接服务端故意不返回的情况下可以hold住90秒？这90秒是htt协议规定的吗？不是据说http超时是30秒 ...

HTTP 1.1里确实新增了KeepAlive特性，故计就是这个东西，但具体是不是90秒，可以写个servlet 去试一下。