即时消息技术剖析与实战
袁武林
微博研发中心技术专家
立即订阅
6503 人已学习
课程目录
已完结 24 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 搞懂“实时交互”的IM技术,将会有什么新机遇?
免费
基础篇 (8讲)
01 | 架构与特性:一个完整的IM系统是怎样的?
02 | 消息收发架构:为你的App,加上实时通信功能
03 | 轮询与长连接:如何解决消息的实时到达问题?
04 | ACK机制:如何保证消息的可靠投递?
05 | 消息序号生成器:如何保证你的消息不会乱序?
06 | HttpDNS和TLS:你的消息聊天真的安全吗?
07 | 分布式锁和原子性:你看到的未读消息提醒是真的吗?
08 | 智能心跳机制:解决网络的不确定性
场景篇 (4讲)
09 | 分布式一致性:让你的消息支持多终端漫游
10 | 自动智能扩缩容:直播互动场景中峰值流量的应对
11 | 期中实战:动手写一个简易版的IM系统
12 | 服务高可用:保证核心链路稳定性的流控和熔断机制
进阶篇 (10讲)
13 | HTTP Tunnel:复杂网络下消息通道高可用设计的思考
14 | 分片上传:如何让你的图片、音视频消息发送得更快?
15 | CDN加速:如何让你的图片、视频、语音消息浏览播放不卡?
16 | APNs:聊一聊第三方系统级消息通道的事
17 | Cache:多级缓存架构在消息系统中的应用
18 | Docker容器化:说一说IM系统中模块水平扩展的实现
19 | 端到端Trace:消息收发链路的监控体系搭建
20 | 存储和并发:万人群聊系统设计中的几个难点
21 | 期末实战:为你的简约版IM系统,加上功能
22 | 答疑解惑:不同即时消息场景下架构实现上的异同
结束语 (1讲)
结束语 | 真正的高贵,不是优于别人,而是优于过去的自己
即时消息技术剖析与实战
登录|注册

14 | 分片上传:如何让你的图片、音视频消息发送得更快?

袁武林 2019-09-27
你好,我是袁武林。
在前面几节课中,我基本上都是从通用文本消息的角度出发,较为深入地分析讲解了即时消息相关的一些重要特性及核心概念。
随着网络环境的大幅改善及网络资费的显著降低,在很多即时消息场景下,人们的互动不再局限于传统的文本消息,越来越多的用户通过图片、语音、视频等丰富的多媒体消息来完成互动。相较于文本消息而言,多媒体消息在易用性和情感表达上更有优势。
但是,多媒体消息相对也会大很多。比如,一条文本消息只有不到 100 字节,但一条视频消息可能超过 100MB。因此,多媒体消息在网络传输、实时触达等方面相对更难一些。
在 IM 场景中,针对图片、语音、视频的优化一直都是一个需要长期投入和突破的重点。今天,我们就来看一看针对多媒体消息的优化手段都有哪些。由于篇幅原因,我会分成两篇,分别从发送和播放两个角度来谈一谈。

让图片和视频发送得又快又稳

要想让图片、视频、语音等多媒体消息发送得又快又稳,我们可以从“多上传接入点”“优化上传链路”“分片先行下推”“分片上传”等几种优化方式上着手。下面我分别来详细讲解一下。

多上传接入点

先来看一下,我们针对多媒体消息上传的第一种优化手段。国内目前的固网宽带运营商构成复杂,且用户宽带向来呈现出“南电信北联通”的分布现状。而在移动网络下,移动、电信、联通三足鼎立,再加上还有教育网和海外两大网络体系,整体网络结构更加复杂,跨运营商网络访问的高延迟和不稳定性一直是个无法解决的老大难问题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《即时消息技术剖析与实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 东东🎈
    老师,客户端api上传一个几M的视频文件,大约需要10几秒,猜测可能是网络传输慢,这个可以从哪几方面来优化呢?

    作者回复: 不要猜呀,这个抓个包分析下就能排除是不是网络的原因。如果确实是网络传输慢导致的,可以看下tcp窗口大小的是不是能打的足够开,另外看下重传啥的这些多不多。

    2019-09-27
    1
  • leslie
    打卡:学习了,等待后续课程;顺便问个小问题,写IM必须要JAVA还是GO也行?普通的掌握程度够吗?

    作者回复: 语言都可以的,除了java、go还有很多c++、erlang的实现。掌握基本语法后,可以找找相关语言的例子边学边试就行。

    2019-09-27
    1
  • 于欣磊
    其他方式 点对点传输 断点续传 压缩技术 编解码技术 视频流缓冲 视频流传输通道复用(视频是基于贞的 如果是直连 中间往往有空隙)
    2019-12-04
  • 奔奔奔跑
    老师,我一直在看您文章,每个留言的讨论都也有看,我想请教一个问题,我是用MQTT做客服系统,人也不多,一天最多四百个房间,五百个排队的,但是最近出现发消息卡顿的情况,消息发出收到broker响应时间有点长,我不知道该用什么手段定位问题,老师能不能指点我一下,谢谢了

    作者回复: 建议先从发消息的链路上来分段排查,分析下各个环节的分步耗时,确定到有耗时问题的环节后再通过线程状态或者hot thread来具体分析当前环节具体耗时的代码。

    2019-11-16
    1
  • GeekAmI
    云服务OSS存在的当下,是不是大部分业务场景不需要服务端优化上传这块呢?

    作者回复: 也不是呀,有些还是需要业务层自己来优化,比如并发分片上传,断点续传,业务权限控制等。

    2019-11-11
  • Darcy
    图片,文件,语音文件中包含有木🐎文件,这方面的安全性怎么保障?有什么手段,或者好的框架吗?

    作者回复: 抱歉这一块了解的不多

    2019-11-05
  • null
    老师,您好

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

    上传时标记序号,服务器怎么知道哪些序号是属于同一个文件的?序号包含了同一个文件标识么?例如:hash(file) + n位序号?这样就跟“断点续传”一样了,为每个上传动作分配一个唯一的操作符。

    服务端需要知道总的分片数么?
    如果不知道,是不是会存在丢失最后一片分片而不知道的情况?
    不过如果序号包含了文件的 hash 值,服务器也可以通过 hash 值校验文件的完整性。只不过服务器计算 hash 值也需要一定的开销。

    作者回复: 每个文件上传时会有一个唯一id来标识这一次上传,多个分片都会携带这个标识。另外,在上传的初始化阶段,会把分片数和文件hash值都告知服务端,用于识别分片是否缺少已经文件是否完整。

    2019-10-29
  • Darcy
    web开发中,有没有好的压缩算法或者图片分配方法可以借鉴那?

    作者回复: 采用webP格式或者google最新的Guetzli格式来对图片进行编码可以有效降低图片大小。另外说的图片分配算法没太理解是啥?

    2019-10-09
    2
  • 探索无止境
    老师讲解的这些方案能不能提供可落地的代码实现?这个实践也是非常关键的,或者说伪代码实现,然后给一些具体的技术指引

    作者回复: 嗯,我尽量在期末实战中有所体现哈,有些涉及的方案代码量比较大,更多的可能只能是实现上的关键点指引。

    2019-10-05
  • 🐾
    像图片缩略图、视频首帧是通过长链接推给接收方的吗?接收用户点击图片或者点击视频首帧播放的时候,才从服务器上进行下载,这个是通过HTTP的方式吗?

    如果是HTTP的话,如何去保证这个文件的安全性呢?比如说加了防盗链,防盗链也有可能在IM之外被人下载。

    作者回复: 缩略图之类的小流量文件可以通过长连下推来优化。http和防盗链不是绑定的呀,不需要上cdn的话,上传的时候自己的文件存储服务就可以记录文件所有者权限,下载的时候就可以根据用户登录认证的信息来鉴权了。

    2019-09-27
  • 东东🎈
    老师,问哈mq发送消息采用同步还是异步呢

    作者回复: 看具体使用场景吧,如果是需要确保写入queue成功才能响应用户的最好是同步写,如果不需要就可以异步。

    2019-09-27
  • 🐾
    老师上午好,图片、音视频消息一般是通过长链接(与文本消息不同通道)的方式上传吗?还是说会额外提供一个http上传文件接口?从性能或者效率来说是不是长链接方式更好?

    作者回复: 个人建议是直接http上传文件就可以啦,上传完就断开的,没必要再走个长连接。客户端同时开多个http连接并发上传就可以,性能没问题的。

    2019-09-27
  • 徐凯
    老师 请问一下 断点续传如果是做短暂暂存的话 上传信息是放服务端内存中 如果是像迅雷那种做长暂存的话 已传输的位置 是不是放在数据库中的 比如说 以操作唯一标识作为主键 然后一个字段放已完整接收的数据包序号 续传时告知客户端已正确接收的最大序号 客户端根据序号计算偏移 然后进行续传

    作者回复: 嗯,长时间的暂存持久化到db应该是没问题的,只要恢复的时候能取出之前已下载完的分片信息就可以。不过类似迅雷这种的,不需要放到服务器端来吧,我理解分片信息暂存在下载的客户端本地就可以呀。

    2019-09-27
收起评论
13
返回
顶部