IM服务器端和消息接受设备之间的关系

IM服务器端和消息接受设备之间维护一条tcp长连接（准备使用websocket）tcp全双工能力，可以同时接受和发送数据。当对放不在线的时候，可以通过三方操作系统辅助通道，重点在于维护可靠的长连接，可靠的长连接，

IM 服务端和接收方能较为精确地感知这个长连接的可用性，当由于网络原因连接被中断时，能快速感知并进行重连等恢复性操作。

通过这个长连接投递的消息不能出现丢失的情况，否则会比较影响用户体验

消息未读数：如果消息接收方当前不在线，还可以通过第三方操作系统级别的辅助通道，来实时地将消息通过手机通知栏等方式推送给接收方。但是三方服务通道受限制比较大，

总结

消息的发送方通过发送通道来把消息提交到 IM 服务端。

IM 服务端接收到发送的消息后，会进行消息的存储以便于后续历史消息的查看，消息的存储从实现上可以分为：消息内容存储、消息索引存储、最近联系人列表存储。

IM 服务端接收到发送的消息后，还会针对接收方进行未读数的变更，以提醒用户查看未读的消息，消息未读数的实现上一般分为：用户维度的总未读和会话维度的会话未读。

IM 服务端进行完消息存储和未读变更后，会通过接收通道把消息推送给接收方，接收通道一般是通过 IM 服务端和消息接收方之间维护的长连接来实现，还会使用第三方操作系统级别的辅助通道，来提升“自建的长连接不可用“时，实时触达的能力

轮询和长连接，

为了解决消息的实时到达问题
短轮询场景：早起使用的方式，一般是"请求响应式"的模式,y一般的请求都是这种请求响应式，不太适合实时性要求比较高的场景，采用"短轮询"，来定期、高频地轮训服务器的消息会给服务器造成的压力比较大，而且即费电又费流量
长轮询场景：短轮询模式下，服务端不管本轮有没有新消息产生，都会马上响应并返回。而长轮询模式当本次请求没有获取到新消息时，并不会马上结束返回，而是会在服务端“悬挂（hang）”，等待一段时间；如果在等待的这段时间内有新消息产生，就能马上响应返回。这种场景用于对实时性要求比较高，但是整体用户量不太大。但是长轮询还是有问题的，长轮询在超时时间内没有获取到消息时，会结束返回，没有解决无效请求，而且对后段的压力并没有减少
不管是短轮询还是长轮询都是基于HTTP 协议实现的，由于 HTTP 是一个无状态协议，同一客户端的多次请求对于服务端来说并没有关系，也不会去记录客户端相关的连接信息。

WebSocket：WebSocket 是一种服务端推送的技术代表，不同于轮训的客户端推送，基于 WebSocket 实现的 IM 服务，客户端和服务端只需要完成一次握手，就可以创建持久的长连接，并进行随时的双向数据传输。当服务端接收到新消息时，可以通过建立的 WebSocket 连接，直接进行推送，真正做到“边缘触发”（当状态变化时，发生一个 IO 事件），也保证了消息到达的实时性。
WebSocket 的优点是：

支持服务端推送的双向通信，大幅降低服务端轮询压力；

数据交互的控制开销低，降低双方通信的网络开销；

Web 原生支持，实现相对简单