请教企业IM中TCP传输业务层需要分包吗（比如拉取员工信息）

技术场景：
做企业IM中，有拉取整个公司的员工信息，员工人数非常多大约10万人左右。因此，一次拉取的数据量大约为100000*1000 = 100M，那么这100M数据怎么返回，业务层需要分包吗？

我认为：
虽然100M数据对于一次业务请求的数据量是比较大的，但是在TCP传输的情况下还是可靠的，即便数据可能不完整，收完包之后做一次MD5校验也可以的。同时网络层也是有数据缓冲区的，不会出现数据send失败的情况。但是为在一篇文章中，看到企业微信在请求大批量数据的时候做了分包处理，即业务层分包，每次发送1000个员工数据，文章提到是因为这样发送更可靠，感觉这个理由不是很能说服我，反而增加逻辑。

参考的文章链接是：
企业微信客户端中组织架构数据的同步更新方案优化实战

请大佬指教: handshake
更新：
看完版主的回答之后，有一语点醒梦中人的感觉，感谢。
一：
开始认为文章中说的企业微信的数据拉取通道用的是TCP长连接，其实企业微信的那篇文章中并没有特别提到长短连接这一点，也可能是感觉没必要提所以没提吧。的确，我们现在在项目中拉取数据通道和实时消息通道用的还是同一个TCP长连接Socket，并没有单独提供http rest接口，这个需要优化的点我已明白。
二：
我们假定客户端与服务器只有一个TCP长连接通道，假定客户端每次都要全量拉取，那么拉取十万人数据分包100次有必要吗？

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


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

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


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

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

不管怎么说，楼主都有蛮干的嫌疑啊，先不管10万员工的公司有多少，发果真有，你也不可能一下子全拉下来啊。。。 完全可以按照实际的业务逻辑按需拉取呢，不然太傻逼太不经济了吧

引用：JackJiang 发表于 2018-01-09 12:14
你的问题很明了，但不得不说想法还停留在过去的PC端IM思维里。

遇到网络抖动的话，那么我们收到的事件包的时候必然就是不完整包了，就会报error，TCP重连，通道重新建立，重新再拉取一次。这其实又牵扯到另一个问题，我们自定义的二进制事件包，最大长度不超过多大才合适，才能保证发送成功率，1M 还是100M，怎么来衡量呢？

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

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

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

引用：JackJiang 发表于 2018-01-09 14:36
你还是没看懂我说的，不要试图用IM长连接通道来传你的数据，这种“拉”的数据，直接用http来实现。

我 ...

我是看了的，我明白了使用长连接来拉取消息不合适的。然后我说的是另一个问题，假定只有长连接通道，需要拉取100M的数据，业务层需要分包吗？帖子我更新过了

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

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

引用：JackJiang 发表于 2018-01-09 14:45
这种假设我给不了你答案。不过你对TCP协议的理解好像还不是特别准确，TCP通道实际就像自来水管一样源源不 ...

应该是我没表达清楚，等我理解好了再来分享一下

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