三方外部接口服务：当app没有打开或者在后台运行，消息给到第三方外部接口服务，来通过手机操作系统自身的公共连接服务来进行操作系统级的“消息推送”，通过这种方式下发的消息一般会在手机的“通知栏”对用户进行提醒和展示
实时性：立马接受到消息，怎么保证消息的实时性是要解决的问题？可靠性：分为两块1.不丢消息：发送的消息不会丢失2.消息不重复：消息不会重复发送一致性：同一条消息在不能端接受的消息顺序是一致的。怎么解决消息的一致性？消息序号生成器安全性：消息数据的安全，"数据传输安全""数据储存安全"，"消息内容安全"，怎么保证消息的安全性？
整体分为：制订好消息内容、消息存储、未读消息的存储，需要建立高效的实时消息收发通道等消息存储：历史消息或者用于暂存离线消息，都需要对消息进行服务端存储。也会根据业务进行本地存储，消息内容：对消息进行分类（根据业务进行划分）消息发送通道：一般有两种
消息未读数：如果消息接收方当前不在线，还可以通过第三方操作系统级别的辅助通道，来实时地将消息通过手机通知栏等方式推送给接收方。但是三方服务通道受限制比较大，
总结
WebSocket：WebSocket是一种服务端推送的技术代表，不同于轮训的客户端推送，基于WebSocket实现的IM服务，客户端和服务端只需要完成一次握手，就可以创建持久的长连接，并进行随时的双向数据传输。当服务端接收到新消息时，可以通过建立的WebSocket连接，直接进行推送，真正做到“边缘触发”（当状态变化时，发生一个IO事件），也保证了消息到达的实时性。WebSocket的优点是：
ACK机制中的消息重传消息推给用户B的过程中丢失了怎么办？比如:
一般的解决方案是：服务端推送消息时携带一个SequenceID，SequenceID在本次连接会话中需要唯一，针对同一条重推的消息SequenceID不变，接收方根据这个唯一的SequenceID来进行业务层的去重，这样经过去重后，对于用户B来说，看到的还是接收到一条消息，不影响使用体验。
补救措施：消息完整性检查针对服务器宕机可能导致的重传失效的问题我们来分析一下，这里的问题在于：服务器机器宕机，重传这条路走不通了
有剋TCP协议本身的ACK机制为什么还需要业务层的ACK机制：
总结一下就是：发送方的应用层程序，调用send()方法返回成功的时候，数据实际是写入到了TCP的发送缓冲区，而非已经被接收方的应用层程序处理。怎么办呢？只能借助于应用层的ACK机制。
消息的一致性是很重要的，在我们的聊天过程和后续聊天记录的保存都需要保证正确的顺序，
解决网络的不确定性我们通过长连接来实现投递，“长连接”底层使用的TCP连接并不是一个真正存在的物理连接。我们需要用心跳机制维护，当网络出问题的时候，可能还维护这长连接，心跳机制：TCPKeepalive，应用层心跳，智能心跳，智能心跳。IM都采用了应用层心跳方案来解决连接保活和可用性探测的问题