图片、音视频消息上传优化

通常图片、音视频等多媒体消息相对于文本消息会大很多，因此，多媒体消息在网络传输、实时触达等方面相需要有更多的优化。本文就针对如何使图片、视频、语音等多媒体消息发送得又快又稳进行相关分析。

多上传接入点

国内目前的固网宽带运营商构成复杂，且用户宽带向来呈现出“南电信北联通”的分布现状。而在移动网络下，移动、电信、联通三足鼎立，再加上还有教育网和海外两大网络体系，整体网络结构更加复杂，跨运营商网络访问的高延迟和不稳定性一直是个无法解决的老大难问题。

对于传输数据更多的视频、图片等多媒体消息来说，如果出现用户跨运营商来上传文件，多次 RTT（Round-Trip-Time，往返时延）带来的用户体验会更差。因此，要提升多媒体消息的上传性能和成功率，我们首先要从接入点着手。

典型的优化方法：

针对不同的主流运营商提供不同的上传接入点 IP，然后通过运营商 DNS 解析，让用户能通过本运营商的上传接入点来快速上传图片和视频；
进一步，相应后端的图片上传存储服务，也可以部署在多线机房，这样上传服务也能快速地把文件流提交给存储层，从而避免从接入点到存储服务的跨网开销，也能解决其他运营商的用户下载图片时需要跨网的问题。

当然多个接入点 IP 在管理和使用上会比较复杂。在实际应用中需要更多地注意。

上传链路优化

在上传普通文本消息时，一般会设计负载均衡层、接入服务层、业务逻辑层，另外，多媒体消息在上传时，在业务逻辑层后面一般还有一个用于文件存储的服务。因此，如果多媒体消息也通过文本消息的通道上传，整体链路会比较长。

对于图片、视频这种数据传输量大的消息来说，在这么长的链路上来回多次进行数据拷贝，整体性能会比较差，同时也会导致不必要的带宽浪费，而且可能会造成整个文本消息通道阻塞，影响普通消息的收发。

上传链路优化的思路就是出于性能和隔离的考虑，一般把这些多媒体消息上传通道和普通消息收发通道独立开。发送多媒体消息时，先通过独立通道上传文件流，上传完成后会返回文件的唯一标识 ID，然后再把这个唯一标识 ID 作为消息的引用，通过普通消息收发通道进行发送。

语音的“分片先行下推”

语音消息和图片、视频等多媒体的区别主要有：

一般会有录制时长的限制，上传的文件较小，相对比较可控。
从接收方的角度，图片和视频在接收查看的时候，都会有缩略图或者视频首帧图用于预览，不需要一开始就下载原文件，而语音消息没有预览功能，只能下载原文件用于播放。如果语音也和图片、视频等多媒体消息走一样的上传下载逻辑，播放时就需要去下载原文件，这样会容易出现下载慢、卡顿的情况。

因此，对于语音实时聊天，更好的优化方式是通过长连下推的方式将语音流推到对端，这样用户在播放语音时就不需要再从远程临时下载文件，使用流畅度也会更好。

在一些即时消息场景的实现中，会通过普通消息收发的长连通道来分片上传语音流，这样更方便通过长连来下推给接收方。

另外，**IM 服务端在接收到分片后，可以同步先行把分片的二进制流下推给接收方但暂不显示，不需要等所有分片都在后端存储完成再进行下推。**这样的好处是：当语音的最后一片到达后端并存储完成后，IM 服务端只需要给接收方推一条“所有分片存储完成”的轻量信令，即可让接收方马上看到这条语音消息。这个“分片先行下推”机制在实时性上比远程临时下载的方式更好，能有效降低语音聊天的延时。

分片上传

分片上传，是指“在客户端把要上传的文件按照一定规则，分成多个数据块并标记序号，然后再分别上传，服务端接收到后，按照序号重新将多个数据块组装成文件”。

对于图片、视频、语音等这种较大的消息来说，采用分片上传可以让客户端在分片完成后，利用“并行”的方式来同时上传多个分片，从而提升上传效率。

另外，分片上传的优势还有：

在一些网络环境较差的场景下，采用“分片”的方式，可以在上传失败后进行重试时，不必重新上传整个文件，而只需要重传某一个失败的分片，这样也能提升重新发送的成功率和性能；
此外，类似语音这种流式消息，在上传时可能不知道文件最终大小，采用分片上传可以让消息文件先部分上传到服务器，而没必要等到录制完才开始上传，也能节约上传的整体时长。

分片策略

在分片上传中，分片策略是一个重要但又比较有挑战的问题。

分片太大，片数少，上传的并发度不够，可能会降低上传效率，每个大的分片在失败后重传的成本会比较高。
分片太小，片数多，并发需要的 TCP 连接太多，多条 TCP 连接的“窗口慢启动”会降低整体吞吐，两端拆分与合并分片的开销也相应增加，而且传输时的额外流量（HTTP 报头）也会更多。

通常在网络状况较好的环境，比如在 WiFi、4G、5G 下，相应的分片大小应该设置得更大一些；而在 2G、3G 弱网情况下，分片可以设置小一点（减少弱网重传成本）。

对于分片大小的设置，简单一点的处理可以按照网络状态来粗略划分。比如，WiFi 下 2M，4G 下 1M，3G/2G 下 256K。当然也可以根据相关的算法策略自适应动态根据网络现状调整分片大小。

断点续传

在上传视频、图片等较大文件时，整体耗时会比较长，用户由于某些原因可能需要在上传未完成时临时暂停，或者遇上系统意外崩溃导致上传中断的情况。对此，如果要再次上传同一个文件，我们希望不必再重新上传整个文件，而是从暂停的位置“断点续传”，而上述分片上传机制，就能相对简单地实现“断点续传”功能。

给每一次上传行为分配一个唯一的操作标识，每个分片在上传时除了携带自己的序号外，还需要带上这个操作标识，服务端针对接收到的同一个操作标识的分片进行“暂存”，即使由于某个原因暂停上传了，这些“暂存”的分片也不会马上清理掉，而是保留一定的时间。

续传时继续以之前同一个操作标识来上传，客户端先检查服务端已有分片的情况，如果没有过期就继续从上次的位置续传，否则需要重新从头开始上传。“断点续传”功能实现上比较简单，但在上传大文件时，对于提升用户体验是比较明显的。