谁做im即时通讯最好?

}

作者简介: 陈宜龙(),iOS 开发工程师,现任职于 LeanCloud,热爱开源与分享, 获得的 Star 数过万,也是多个开源项目的维护者,比如  等。

IM 已经成为当下 App 的必备模块,在不同垂直领域,技术实现不尽相同。究竟该如何选型?技术实现过程中,又该如何进行性能调优?本篇文章分为应用场景、技术实现细节、针对移动网络特点的性能调优三个部分,具体讲解IM即时通讯技术在社交、直播、红包等不同场景下的技术实现与性能调优。

需要注意,本文中所涉及到的所有 iOS 相关代码,均已 100% 开源(不存在 framework ),便于学习参考;本文侧重移动端的设计与实现,会展开讲,服务端仅仅属于概述,不展开;本文还将为大家在设计或改造优化 IM 模块,提供一些参考。

大规模即时通讯的技术难点

  • 如何在移动网络环境下优化电量、流量及长连接的健壮性?现在移动网络有 2G、3G、4G 各种制式,且随时可能切换和中断,移动网络优化可以说是面向移动服务的共同问题。
  • 如何确保IM系统的整体安全?因为用户的消息是个人隐私,所以要从多个层面来保证。
  • 如何降低开发者集成门槛?
  • 如何应对新iOS生态下的政策并结合新技术,比如 HTTP/2、IPv6、新的 APNs 协议等。

IM 服务的最大价值在于什么?可复用的长连接。一切高实时性的场景,都适合使用 IM 来做,比如:视频会议、聊天、私信、弹幕、抽奖、互动游戏、协同编辑、股票基金实时报价、体育实况更新;基于位置的应用(Uber、滴滴司机位置)、在线教育、智能家居等。

接下来,我们会挑一些典型场景进行介绍,并分析其中具体的技术细节。

IM 基本的发展历程是:轮询、长轮询、长连接。

下面挑选一些代表性的技术进行介绍:

  • 一般的网络请求:一问一答,如图1所示。
  • 轮询:频繁的一问一答,见图2。
  • 长轮询:耐心地一问一答,见图3,曾被Facebook早期版本采纳。

一种轮询方式是否为长轮询,是根据服务端的处理方式来决定的,与客户端没有关系。

短轮询很容易理解,那么,什么叫长轮询?与短轮询有何区别?长轮询和短轮询最大的区别是,短轮询去服务端查询时,不管服务端有没有变化,服务器就立即返回结果了。而在长轮询中,服务器如果检测到库存量没有变化话,将会把当前请求挂起一段时间(这个时间也叫作超时时间,一般是几十秒)。在这个时间内,服务器会检测库存量有没有变化,变化就立即返回,否则就等到超时为止。

我们可以看到,发展历史是这样:从长短轮询与长短连接,使用 WebSocket 来替代 HTTP。长短轮询到长短连接的区别主要有:

  1. 概念范畴不同:长短轮询是应用层概念,长短连接是传输层概念;
  2. 协商方式不同:一个 TCP 连接是否为长连接,是通过设置 HTTP 的 Connection Header 来决定的,且需要两边都设置才有效。
  3. 实现方式不同:连接的长短是通过协议来规定和实现的。而轮询的长短,是服务器通过编程的方式手动挂起请求实现的。

在移动端上长连接是趋势,其最大的特点是节省 Header。对比轮询与 WebSocket 所花费的 Header 流量即可窥其一二。

假设 Header 是 871 字节,我们以相同的频率 10W/s 去做网络请求,对比轮询与 WebSocket 所花费的 Header 流量。其中,Header 包括请求和响应头信息。出于兼容性考虑,一般建立 WebSocket 连接也采用 HTTP 请求的方式,从这个角度讲,无论请求如何频繁,都只需要一个 Header。

相同的每秒客户端轮询的次数,当次数高达 10W/s 的高频率时,Polling 轮询需要消耗 665Mbps,而 WebSocket 仅仅只花费了 ,网址


}

我要回帖

更多关于 开源im即时通讯 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信