移动端IM开发须要面对的技术问题

时间 2019-11-18

标签移动开发须要面对技术问题栏目无线繁體版

原文原文链接

一、前言

这两年多一直从事网易云信 iOS 端 IM SDK的开发，期间不断有兄弟部门的同事和合做伙伴过来问各类技术细节，干脆统一介绍下一个IM APP的方方面面，包括技术选型（包括通信方式，网络链接方式，协议选择）和常见问题。（原文连接：http://www.52im.net/thread-133-1-1.html）php

分享者：项望烽，毕业于浙江大学，目前是网易云信 iOS 端研发负责人。 html

二、学习交流

- 即时通信开发交流群： 215891622 [推荐]android

- 移动端IM开发推荐文章：《新手入门一篇就够：从零开发移动端IM》算法

三、P2P仍是服务器中转？

IM通信方式无非两种选择：设备直连(P2P)和经过服务器中转。编程

3.1 P2P方式

P2P多见于局域网内聊天工具，典型的应用有:飞鸽传书、天网Maze(你懂的)等。这类软件在启动后通常作两件事情：缓存

进行UDP广播:发送本身信息和接受同局域网内其余端信息；
开启TCP监听:等待其余端进行链接。

详细的流程能够参考飞鸽传书源码。可是这种方式在有种种限制和不便:一方面它只适合在线的点对点消息传输，对离线，群组等业务支持不够。另外一方面因为 NAT 的存在，使得不一样局域网内机器互联难度大大上升，在某些网络类型(对称NAT)下没法创建链接。

安全

3.2 服务器中转方式

几乎全部互联网IM产品都采用服务器中转这种方式进行消息传输，相对于P2P的方式，它有以下的优势:服务器

可以支持更多P2P没法支持或支持很差的业务，如离线消息，群组，聊天室服务；
方便业务逻辑的拓展和新旧版本的兼容。

固然它也有本身的问题:服务器架构复杂，并发要求高。微信

四、该选择什么样的网络通信技术？

IM主流网络通信技术有两种:网络

基于TCP的长链接；
基于HTTP短链接PULL的方式。

后者常见于WEB IM系统(固然如今不少WEB IM都是基于WebSocket实现)，它的优势是实现简单，方便开发上手，问题是流量大，服务器负载较大，消息及时性没法很好地保证，对大规模的用户量支持不够，比较适合小型的IM系统,如小网站的客户系统。

基于TCP长链接则可以更好地支持大批量用户，问题是客户端和服务器的实现比较复杂。固然也还有一些变种，以下行使用MQTT进行服务器通知/消息的下发，上行使用HTTP短链接进行指令和消息的上传。这种方式可以保证下行消息/指令的及时性，可是在弱网络下上行慢的问题仍是比较严重。早期的来往就是基于这种方式。

五、协议如何制定？

IM协议选择原则通常是：易于拓展，方便覆盖各类业务逻辑，同时又比较节约流量。后一点的需求在移动端IM上尤为重要。常见的协议有：XMPP、SIP、MQTT、私有协议。（更多关于即时通信应用的协议选择，请参见《如何选择即时通信应用的数据传输格式》：http://www.52im.net/thread-276-1-1.html）

5.1 XMPP

优势：协议开源，可拓展性强，在各个端(包括服务器)有各类语言的实现，开发者接入方便；
缺点：缺点也是很多，XML表现力弱、有太多冗余信息、流量大，实际使用时有大量天坑。

5.2 SIP

SIP协议多用于VOIP相关的模块，是一种文本协议，因为我并无实际用过，因此不作评论，但从它是文本协议这一点几乎能够判定它的流量不会小。

5.3 MQTT

优势：协议简单，流量少；
缺点：它并非一个专门为IM设计的协议，多使用于推送。

5.4 私有协议

市面上几乎全部主流IM APP都是是使用私有协议，一个被良好设计的私有协议优势很是明显。

优势：高效，节约流量(通常使用二进制协议)，安全性高，难以破解；
缺点：在开发初期没有现有样列能够参考，对于设计者的要求比较高。

5.5 结论

一个好的协议须要知足以下条件:高效，简洁，可读性好，节约流量，易于拓展，同时又可以匹配当前团队的技术堆栈。基于如上原则，咱们能够得出: 若是团队小，团队技术在IM上积累不够能够考虑使用XMPP或者MQTT+HTTP短链接的实现。反之能够考虑本身设计和实现私有协议。

六、该如何设计私有通讯协议？

6.1 序列化与反序列化

移动互联网相对于有线网络最大特色是:带宽低，延迟高，丢包率高和稳定性差，流量费用高。因此在私有协议的序列化上通常使用二进制协议，而不是文本协议。

常见的二进制序列化库有protobuf和MessagePack，固然你也能够本身实现本身的二进制协议序列化和反序列的过程，好比蘑菇街的TeamTalk。可是前面两者不管是可拓展性仍是可读性都完爆TeamTalk(TeamTalk连Variant都不支持，一个int传输时固定占用4个字节)，因此大部分状况下仍是不推荐本身去实现二进制协议的序列化和反序列化过程。

6.2 协议格式设计

基于TCP的应用层协议通常都分为包头和包体(如HTTP)，IM协议也不例外。包头通常用于表示每一个请求/反馈的公共部分，如包长，请求类型，返回码等。而包头则填充不一样请求/反馈对应的信息。

一个最简单的包头能够定义为：

 
         struct 
         PackHeader 
        
         { 
        
         int32_t     length_;     
         //包长度 
        
         int32_t     serial_;     
         //包序列号 
        
         int32_t     command_;    
         //包请求类型 
        
         int32_t     code_;       
         //返回码 
        
         };

以心跳包为例，假设当前的serial为1，心跳包的command为10，那么使用MessagePack作序列化时:length=4，serial=1，command=10，code=0，每一个字段各占一个字节，包体为空，仅须要4个字节。

固然这是最简单的一个例子，面对真正的业务逻辑时，包体里面会须要塞入更多地信息，这个须要开发根据本身的业务逻辑总结公共部分,如为了兼容加入的协议版本号,为了负载均衡加入的模块id等。

七、其余不可忽视的问题

上面的内容就是一个IM系统大体的选型过程：服务方式，网络通信协议，数据通讯协议选择、协议设计。可是实际开发过程当中还有大量的问题须要处理。

7.1 协议加密

为了保证协议不容易被破解，市面上几乎全部主流IM都会对协议进行加密传输。常见的流程和HTTPS加密类似:创建链接后，客户端和服务器进行进行协商，最终客户端得到一个当前Sessino的秘钥，后续的数据传输都经过这个秘钥进行加解密。通常出于效率的考虑都会采用流式加密，如RC4。而前期协商过程则推荐使用RSA等非对称加密以增长破解难度。

7.2 快速链接（即掉线重连机制）

对iOS APP而言，由于没有真后台的存在，APP每次启动基本都须要一次重连登陆(短期内切换除外)，因此如何快速重连、重登就很是重要。
常见优化思路以下:

本地缓存服务器IP并按期刷新。移动网络调优能够参考《iOS端移动网络调优的8条建议》；
合并部分请求。如加密和登陆操做能够合并为同一个操做，这样就能够减小一次没必要要的网络请求来回的时间；
简化登陆后的同步请求，部分同步请求能够推迟到UI操做时进行，如群成员信息刷新。

7.3 链接保持（即心跳机制）

通常APP实现链接保持的方式无非是采用应用层的心跳，经过心跳包的超时和其余条件(网络切换)来执行重连操做。那么问题来了:为何要使用应用层心跳和如何设计应用层心跳。众所周知TCP协议是有KEEPALIVE这个设置选项，设置为KEEPALIVE后，客户端每隔N秒(默认是7200s)会向服务器发送一个发送心跳包。

但实际操做中咱们更多的是使用应用层心跳。缘由以下:

KEEPALIVE对服务器负载压力比较大(服务器大大是这么说的...)；
socks代理对KEEPALIVE并不支持；
部分复杂状况下KEEPALIVE会失效，如路由器挂掉，网线(移动端没有网线...)直接被拔除。

移动端在实际操做时为了节约流量和电量通常会在心跳包上作一些小优化：

精简心跳包，保证一个心跳包大小在10字节以内；
心跳包只在空闲时发送；
根据APP先后台状态调整心跳包间隔 (主要是安卓)。

7.4 消息可达（即QoS机制）

在移动网络下，丢包，网络重连等状况很是之多，为了保证消息的可达，通常须要作消息回执和重发机制。参考易信，每条消息会最多会有3次重发，超时时间为15秒，同时在发送以前会检测当前链接状态，若是当前链接并无正确创建，缓存消息且定时检查(每隔2秒检查一次，检查15次)。因此一条消息在最差的状况下会有2分钟左右的重试时间，以保证消息的可达。

由于重发的存在，接受端偶尔会收到重复消息，这种状况下就须要接收端进行去重。通用的作法是每条消息都戴上本身惟一的message id(通常是uuid)。

7.5 文件上传优化

IM消息(包括SNS模块)内包含大量的文件上传的需求，如何优化文件的上传就成了一个比较大的主题。

常见有下面这些优化思路:

将上传流程提早:音频提供边录边传。朋友圈的图片进行预上传，选择图片后用户通常会进行文本输入，在这段时间内后台就能够默默将选好的图片进行上传；
提供闪电上传的方式:服务器根据MD5进行文件去重；
优化和上传服务器的链接(参考快速链接)，提供链接重用的功能；
文件分块上传:由于移动网络丢包严重，将文件分块上传可使得一个分组包含合理数量的TCP包，使得重试几率降低，重试代价变小，更容易上传到服务器；
在分包的前提下支持上传的pipeline，避免没必要要的网络等待时间；
支持断点续传。

（原文连接：http://www.52im.net/thread-133-1-1.html）

http://www.52im.net/forum.php?mod=collection&op=all