你的问题很明了，但不得不说想法还停留在过去的PC端IM思维里。


现在的主流IM（基本上就是说的移动端IM了）都是http短连接配合IM实时通道一起用的：
像你这种拉取大量数据的情况，肯定优先使用http短连接的方式（即由服务端提供Http rest接口向你提供数据），因为http服务属标准服务，负载均衡和业务拆分都很简单，想怎么玩都可以。

而IM实时通道传输这种大量数据肯定不是最佳选择，比如你的数据传输遇到移动网络突然抖动跳变，那数据就没法继续，是做断点续传呢还是怎么滴怎么滴，先不说把服务端的负载给拉的很高，你这客户端体验、代码复杂度都是另一个级别了。


以上不知我说的你是否理解，你可以参考这两篇文章，一看就明白了：
《谈谈移动端 IM 开发中登录请求的优化》
《移动端IM登录时拉取数据如何作到省流量？》

这两篇文章你读完，应该就豁然开朗了。其实微信的那篇文章，是你自已把它理解成了长连接通道传输了。

引用：x931609201 发表于 2018-01-09 14:30
遇到网络抖动的话，那么我们收到的事件包的时候必然就是不完整包了，就会报error，TCP重连，通道重新建立 ...

你还是没看懂我说的，不要试图用IM长连接通道来传你的数据，这种“拉”的数据，直接用http来实现。

我在2楼写了那么多，你没有看吧，没看就真的救不了你。。。。

引用：x931609201 发表于 2018-01-09 14:43
我是看了的，我明白了使用长连接来拉取消息不合适的。然后我说的是另一个问题，假定只有长连接通道，需要 ...

这种假设我给不了你答案。不过你对TCP协议的理解好像还不是特别准确，TCP通道实际就像自来水管一样源源不断没有起点也没有终点，你只要让对方知道你的逻辑起点和逻辑终点在什么地方就行了，底层的分包那是协议栈自已解决。

引用：x931609201 发表于 2018-01-09 15:15
应该是我没表达清楚，等我理解好了再来分享一下