本文在编写时参考了博客作者“鹿呦呦”和在线课程“即时消息技术分析与实战”的相干材料，一并表示感谢。

1、引言

随着挪动互联网络的倒退，IM 技术的利用曾经不仅限于聊天利用自身，它早已融入各种利用状态中，比方：直播中的主播互动、联网游戏中的玩家互动、外卖 / 打车利用中的实时地位共享、在线教育利用中的互动白板等。

在这些格调迥异的利用场景下，IM 技术所出现进去的性能状态虽有不同，但“实时性”这个技术特色并无区别。

那么，对于技术门外汉来说，到底什么是 IM 的“实时性”？该如何了解它？这就是本文想要探讨的主题。

区别于弱小的原生利用，Web 端的 IM 零碎，在很长一段时间内想实现真正的“实时性”，是十分艰难的，因为无奈间接应用 UDP、TCP 通信协议，在 HTML5 中的 WebSocket 呈现之前，Web 端简直没有真正意义上的“双向实时通信”这种技术存在。

正因为如此，了解 Web 端即时通信技术的演进，也就自然而然能循序渐进地领会到 IM 零碎中的“实时性”了。所以本文将围绕 Web 端即时通讯技术，为你开展 IM“实时性”这个话题。

情谊提醒： 本系列文章侧重于实践概念的讲述，篇幅无限，点到即止，如需零碎、深刻、具体地学习 IM 技术的方方面面，请从此文动手：《新手入门一篇就够：从零开发挪动端 IM》（史诗级文章，适宜从入门到放弃）。

学习交换：

• 即时通讯 / 推送技术开发交换 5 群：215477170 [举荐]
• 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
• 开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK

（本文同步公布于：http://www.52im.net/thread-3143-1-1.html）

2、系列文章目录

《IM 开发疾速入门 (一)：什么是 IM 零碎？》
《IM 开发疾速入门 (二)：什么是 IM 零碎的实时性？》（* 本文）
《IM 开发疾速入门 (三)：什么是 IM 零碎的可靠性？(稍后公布)》
《IM 开发疾速入门 (四)：什么是 IM 零碎的一致性？(稍后公布)》
《IM 开发疾速入门 (五)：什么是 IM 零碎的安全性？(稍后公布)》
《IM 开发疾速入门 (六)：什么是 IM 零碎的的心跳机制？(稍后公布)》
《IM 开发疾速入门 (七)：如何了解并实现 IM 零碎音讯未读数？(稍后公布)》
《IM 开发疾速入门 (八)：如何了解并实现 IM 零碎的多端音讯漫游？(稍后公布)》

3、短轮询技术

在晚期的 Web 时代，技术的创造者们无奈预感现在各种选进的技术利用模式，他们认为数据只是用来“看”的，也数据的获取根本就是“申请 -> 响应”这种一问一答模式。包含咱们平时浏览的各种门户网站都是采纳的“申请响应”模式。

这种依赖于用户“被动”申请的数据获取模式，如果想实现 IM 零碎，是无奈即时取得最新的聊天音讯的，因为用户并不知道新音讯什么时候到来，而服务端也没有方法被动告诉用户。

在这个期间，尽管技术和思路都受过后技术水平的限度，但 IM 总不能不做吧。

于是，一种被称为“短轮询”的数据获取模式呈现了。在“短轮询”模式下，IM 客户端定时轮询服务端，以便让用户晓得是否有新的聊天音讯存在。

这种模式下，服务端收到申请后，即刻查问是否存在新音讯，有就返回给客户端，没有则返回空并立刻敞开连贯。

相较于后面用户须要“手动”去刷新页面的形式，这种模式只是将用户的“手动”变为“主动”而已，技术实质并没有产生任何实质性扭转。

短轮询这种模式，就好比旧时代一个期待重要邮件的人，他须要每天自已跑到邮局，被动去问是否有本人的函件，有就拿回家，如果没有，则第二天持续去问。一来一去，十分低效。

技术原理总结如下图所示：

短轮询这种模式有益处，也有害处。

益处是：

• 1）技术简略，容易实现；
• 2）可维护性强，因为它没什么简单的。

害处是：

• 1）因为无奈预知数据是否存在，所以少数申请是无用的，节约计算资源；
• 2）为了晋升实时性，高频率的申请会加大服务端的性能负载。

总结一下就是，短轮询这种模式对于 IM 技术大拿来说，显的十分 low，因为技术实现切实是简略粗犷。

4、长轮询技术

正如你所见，用短轮询技术来保障 IM 的实时性，的确难说优雅。不过，这难不倒无所不能的程序员，一种被称为“长轮询”的数据获取模式呈现了。

从技术上来说， 长轮询实现的 IM 相较于短轮询最大的改良在于： 短轮询状况下，服务端不论有没有新音讯，申请完结就会立刻断开连接。而长轮询时，如果本次申请没有新音讯产生，糨不会马上断开连接并返回，而是会将本次连贯“挂起”一段时间，如果在这段“挂起”工夫内有新的聊天音讯呈现，就能马上读取并立刻返回给客户端，接着完结本次连贯。一段时间后又会再次发动申请，如此周而复始。

长轮询这种模式，拿上节期待邮件的这个例子来说，就好比收信的人每天到邮局去问是否有函件，如果没有，他不马上回家，而是在邮局待上一段时间，如果这段时间过来了，还是没有，就先回家，接着第二天再来。

技术原理总结如下图所示：

长轮询的长处是：

• 1）相较于短连询，肯定水平升高了服务端申请负载；
• 2）相较于短连询，实时性有晋升，因为它是被动“等”音讯。

长轮询的毛病是：

• 1）长论询模式下，连贯“挂起”的这段时间内，服务端须要配合开启独自的音讯查问线程，依然存在无用功；
• 2）相较于短连询模式，在一次长轮询完结、下次轮询发动前的窗口期内，依然存在“实时性”盲区。

实际上，在 Web 端即时通讯技术里，长轮询有个业余的术语叫“Comet”，有趣味能够具体学习《Comet 技术详解：基于 HTTP 长连贯的 Web 端实时通信技术》。

5、轮询无奈实现真正的“实时性”

对于 Web 端即时通讯技术来说，下面提到的无论是短轮询，还是长轮询，它们都存在“实时性”盲区。

咱们回到上两节介绍的短轮询和长轮询技术原理图。

先看看短轮询这张图：

很显著，短轮询在每次轮询完结和下次轮询开始的间隔期内，是无奈感知到新音讯的，这也便造成了“实时性盲区”。换句话说，短轮询技术在“实时性盲区”内，无奈做到“实时”。

再来看看长轮询：

跟短轮询情理一样，长轮询在每次轮询完结和下次轮询开始的间隔期，仍然会造成“实时性盲区”。

要了解纠结轮询技术的实时性缺点，就得理解它们背地的技术——HTTP 协定了。

HTTP 协定设计的目标，就是为了实现“申请 – 响应”这种模式的数据交互，也就是众所周之的“短连贯”设计。而无论是短轮询还是长轮询，都跳不出 HTTP 的先天技术逻辑（申请 – 响应 – 断开）。

所以，归根到底，想要基于 HTTP 协定来实现 IM，要达到真正的“实时性”，是相当勉强的。因为 HTTP 设计的目标，就是用“短连贯”来简化传统 TCP 长连贯通信带来的复杂性，而 IM 的实时性恰好要用到的又是 TCP 的长连贯个性，所以这就是个悖论。

要真正实现 Web 端的 IM“实时性”，必定不能强行 HTTP 上做文章了，咱们须要新的技术。

6、WebSocket 让 Web 端 IM 真正的“实时性”变成可能

好消息是，HTML5 中带来了 WebSocket 技术。WebSocket 是真正的全双式双向通信技术（详见：《WebSocket 从入门到精通，半小时就够！》）。

下图上新式轮询技术跟 WebSocket 的比照图：

从上图能够看出：

• 1）轮询技术一问一答，在下一个申请发动之前，存在“实时性”盲区；
• 2）WebSocket 一旦建设连贯后，数据能够随时双向通信（即客户端能够随时向服务端发消息，服务端也能够随时告诉客户端有新音讯）。

举个例子就是： 轮询技术相当于传统的邮件传递办法（你得自已去邮局问有没有新邮件），而 WebSocket 相当于古代的电话零碎，只有你拨通后，随时能够实时收听到对方的声音，对方也能随时收听到你的声音。完满！

总结一下 WebSocket 的长处是：

• 1）真正的实时性：反对客户端与服务端真正的双向实时通信；
• 2）大幅升高负载：少了轮询技术中高频率无用的申请，可大大降低服务端 QPS 压力；
• 3）网络开销升高：一次连贯，随时应用，再也不必轮询技术中每次发动 HTTP 申请（随之而来的是每次 HTTP 的大量冗余协定头信息等）。

7、本文小结

本文以 Web 端即时通讯技术的演进为例，从短轮询到长轮询，再到 WebSocket，实践联系实际地解说了 Web 端 IM“实时性”的技术变迁，从而帮忙读者了解 IM 中“实时性”这个最为要害的技术特色。

附录：更多 Web 端即时通讯材料

《新手入门贴：史上最全 Web 端即时通讯技术原理详解》
《Web 端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《SSE 技术详解：一种全新的 HTML5 服务器推送事件技术》
《Comet 技术详解：基于 HTTP 长连贯的 Web 端实时通信技术》
《老手疾速入门：WebSocket 扼要教程》
《WebSocket 详解（一）：初步意识 WebSocket 技术》
《WebSocket 详解（二）：技术原理、代码演示和利用案例》
《WebSocket 详解（三）：深刻 WebSocket 通信协议细节》
《WebSocket 详解（四）：刨根问底 HTTP 与 WebSocket 的关系 (上篇)》
《WebSocket 详解（五）：刨根问底 HTTP 与 WebSocket 的关系 (下篇)》
《WebSocket 详解（六）：刨根问底 WebSocket 与 Socket 的关系》
《socket.io 实现音讯推送的一点实际及思路》
《LinkedIn 的 Web 端即时通讯实际：实现单机几十万条长连贯》
《Web 端即时通讯技术的倒退与 WebSocket、Socket.io 的技术实际》
《Web 端即时通讯平安：跨站点 WebSocket 劫持破绽详解 (含示例代码)》
《开源框架 Pomelo 实际：搭建 Web 端高性能分布式 IM 聊天服务器》
《应用 WebSocket 和 SSE 技术实现 Web 端音讯推送》
《详解 Web 端通信形式的演进：从 Ajax、JSONP 到 SSE、Websocket》
《MobileIMSDK-Web 的网络层框架为何应用的是 Socket.io 而不是 Netty？》
《实践联系实际：从零了解 WebSocket 的通信原理、协定格局、安全性》
《微信小程序中如何应用 WebSocket 实现长连贯 (含残缺源码)》
《八问 WebSocket 协定：为你疾速解答 WebSocket 热门疑难》
《疾速理解 Electron：新一代基于 Web 的跨平台桌面技术》
《一文读懂前端技术演进：盘点 Web 前端 20 年的技术变迁史》
《Web 端即时通讯基础知识补课：一文搞懂跨域的所有问题！》
《Web 端即时通讯实际干货：如何让你的 WebSocket 断网重连更疾速？》
《WebSocket 从入门到精通，半小时就够！》

 更多同类文章 ……

本文已同步公布于“即时通讯技术圈”公众号：

▲ 本文在公众号上的链接是：点此进入，原文链接是：http://www.52im.net/thread-3143-1-1.html