对立介绍下一个 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，防止不必要的网络等待时间；反对断点续传。