对立介绍下一个IM APP的方方面面，包含技术选型（包含通信形式，网络连接形式，协定抉择）和常见问题。

P2P还是服务器直达？

IM通信形式无非两种抉择：设施直连(P2P)和通过服务器直达。

1P2P形式

P2P多见于局域网内聊天工具，典型的利用有:飞鸽传书、天网Maze(你懂的)等。这类软件在启动后个别做两件事件：

进行UDP播送:发送本人信息和承受同局域网内其余端信息；开启TCP监听:期待其余端进行连贯。

具体的流程能够参考飞鸽传书源码。然而这种形式在有种种限度和不便:一方面它只适宜在线的点对点音讯传输，对离线，群组等业务反对不够。另一方面因为 NAT 的存在，使得不同局域网内机器互联难度大大回升，在某些网络类型(对称NAT)下无奈建设连贯。

2服务器直达形式

简直所有互联网IM产品都采纳服务器直达这种形式进行音讯传输，绝对于P2P的形式，它有如下的长处:

可能反对更多P2P无奈反对或反对不好的业务，如离线音讯，群组，聊天室服务；不便业务逻辑的拓展和新旧版本的兼容。

当然它也有本人的问题:服务器架构简单，并发要求高。

该抉择什么样的网络通讯技术？

IM支流网络通讯技术有两种:

基于TCP的长连贯；基于HTTP短连贯PULL的形式。

后者常见于WEB IM零碎(当然当初很多WEB IM都是基于WebSocket实现)，它的长处是实现简略，不便开发上手，问题是流量大，服务器负载较大，音讯及时性无奈很好地保障，对大规模的用户量反对不够，比拟适宜小型的IM零碎,如小网站的客户零碎。

基于TCP长连贯则可能更好地反对大批量用户，问题是客户端和服务器的实现比较复杂。当然也还有一些变种，如下行应用MQTT进行服务器告诉/音讯的下发，上行应用HTTP短连贯进行指令和音讯的上传。这种形式可能保障上行音讯/指令的及时性，然而在弱网络下上行慢的问题还是比较严重。晚期的来往就是基于这种形式。

协定如何制订？

IM协定抉择准则个别是：易于拓展，不便笼罩各种业务逻辑，同时又比拟节约流量。后一点的需要在挪动端IM上尤其重要。常见的协定有：XMPP、SIP、MQTT、公有协定。

1XMPP

长处：协定开源，可拓展性强，在各个端(包含服务器)有各种语言的实现，开发者接入不便；

毛病：毛病也是不少，XML表现力弱、有太多冗余信息、流量大，理论应用时有大量天坑。

2SIP

SIP协定多用于VOIP相干的模块，是一种文本协定，因为我并没有理论用过，所以不做评论，但从它是文本协定这一点简直能够判定它的流量不会小。

3MQTT

长处：协定简略，流量少；

毛病：它并不是一个专门为IM设计的协定，多应用于推送。

4公有协定

市面上简直所有支流IM APP都是是应用公有协定，一个被良好设计的公有协定长处非常明显。

长处：高效，节约流量(个别应用二进制协定)，安全性高，难以破解；

毛病：在开发初期没有现有样列能够参考，对于设计者的要求比拟高。

该如何设计公有通信协议？

1序列化与反序列化

挪动互联网绝对于有线网络最大特点是:带宽低，提早高，丢包率高和稳定性差，流量费用高。所以在公有协定的序列化上个别应用二进制协定，而不是文本协定。

常见的二进制序列化库有protobuf和MessagePack，当然你也能够本人实现本人的二进制协定序列化和反序列的过程，比方蘑菇街的TeamTalk。然而后面二者无论是可拓展性还是可读性都完爆TeamTalk(TeamTalk连Variant都不反对，一个int传输时固定占用4个字节)，所以大部分状况下还是不举荐本人去实现二进制协定的序列化和反序列化过程。

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零碎大抵的选型过程：服务形式，网络通讯协定，数据通信协定抉择、协定设计。然而理论开发过程中还有大量的问题须要解决。

1协定加密

为了保障协定不容易被破解，市面上简直所有支流IM都会对协定进行加密传输。常见的流程和HTTPS加密类似:建设连贯后，客户端和服务器进行进行协商，最终客户端取得一个以后Sessino的秘钥，后续的数据传输都通过这个秘钥进行加解密。个别出于效率的思考都会采纳流式加密，如RC4。而后期协商过程则举荐应用RSA等非对称加密以减少破解难度。

2疾速连贯（即掉线重连机制）

对iOS APP而言，因为没有真后盾的存在，APP每次启动根本都须要一次重连登录(短时间内切换除外)，所以如何疾速重连、重登就十分重要。

常见优化思路如下:

本地缓存服务器IP并定期刷新。合并局部申请。如加密和登录操作能够合并为同一个操作，这样就能够缩小一次不必要的网络申请来回的工夫；简化登录后的同步申请，局部同步申请能够推延到UI操作时进行，如群成员信息刷新。

3连贯放弃（即心跳机制）

个别APP实现连贯放弃的形式无非是采纳应用层的心跳，通过心跳包的超时和其余条件(网络切换)来执行重连操作。那么问题来了:为什么要应用应用层心跳和如何设计应用层心跳。家喻户晓TCP协定是有KEEPALIVE这个设置选项，设置为KEEPALIVE后，客户端每隔N秒(默认是7200s)会向服务器发送一个发送心跳包。即时通讯聊天软件app开发能够征询蔚可云。

但实际操作中咱们更多的是应用应用层心跳。起因如下:

KEEPALIVE对服务器负载压力比拟大(服务器大大是这么说的...)；socks代理对KEEPALIVE并不反对；局部简单状况下KEEPALIVE会生效，如路由器挂掉，网线(挪动端没有网线...)间接被拔除。

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

精简心跳包，保障一个心跳包大小在10字节之内；心跳包只在闲暇时发送；依据APP前后台状态调整心跳包距离 (次要是安卓)。

4音讯可达（即QoS机制）

在挪动网络下，丢包，网络重连等状况十分之多，为了保障音讯的可达，个别须要做音讯回执和重发机制。参考易信，每条音讯会最多会有3次重发，超时工夫为15秒，同时在发送之前会检测以后连贯状态，如果以后连贯并没有正确建设，缓存音讯且定时查看(每隔2秒查看一次，查看15次)。所以一条音讯在最差的状况下会有2分钟左右的重试工夫，以保障音讯的可达。

因为重发的存在，承受端偶然会收到反复音讯，这种状况下就须要接收端进行去重。通用的做法是每条音讯都戴上本人惟一的message id(个别是uuid)。

5文件上传优化

IM音讯(包含SNS模块)内蕴含大量的文件上传的需要，如何优化文件的上传就成了一个比拟大的主题。

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

将上传流程提前:音频提供边录边传。朋友圈的图片进行预上传，抉择图片后用户个别会进行文本输出，在这段时间内后盾就能够默默将选好的图片进行上传；提供闪电上传的形式:服务器依据MD5进行文件去重；优化和上传服务器的连贯(参考疾速连贯)，提供连贯重用的性能；文件分块上传:因为挪动网络丢包重大，将文件分块上传能够使得一个分组蕴含正当数量的TCP包，使得重试概率降落，重试代价变小，更容易上传到服务器；在分包的前提下反对上传的pipeline，防止不必要的网络等待时间；反对断点续传。