Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 467, comments - 13, trackbacks - 0, articles - 0

     摘要: 本文作者张彦飞,原题“127.0.0.1 之本机网络通信过程知多少 ”,首次发布于“开发内功修炼”,转载请联系作者。本次有改动。1、引言继《你真的了解127.0.0.1和0.0.0.0的区别?》之后,这是我整理的第2篇有关本机网络方面的网络编程基础文章。这次的文章由作者张彦飞原创分享,写作本文的原因是现在本机网络 IO 应用非常广。在 php 中 一...  阅读全文

posted @ 2021-06-28 15:32 Jack Jiang 阅读(224) | 评论 (0)编辑 收藏

     摘要: 本文由微信开发团队工程师“virwu”分享。1、引言近期,微信小游戏支持了视频号一键开播,将微信升级到最新版本,打开腾讯系小游戏(如跳一跳、欢乐斗地主等),在右上角菜单就可以看到发起直播的按钮一键成为游戏主播了(如下图所示)。然而微信小游戏出于性能和安全等一系列考虑,运行在一个独立的进程中,在该环境中不会初始化视频号直播相关的模块。这就意味着小游戏的音视频数据必须跨进程传输...  阅读全文

posted @ 2021-06-21 15:32 Jack Jiang 阅读(161) | 评论 (0)编辑 收藏

本文引用了“拍乐云Pano”的“深入浅出理解视频编解码技术”和“揭秘视频千倍压缩背后的技术原理之预测技术”文章部分内容,感谢原作者的分享。

1、引言

从 20 世纪 90 年代以来,数字音视频编解码技术迅速发展,一直是国内外研究的热点领域。随着5G的成熟和广泛商用,带宽已经越来越高,传输音视频变得更加容易。视频直播、视频聊天,已经完全融入了每个人的生活。

视频为何如此普及呢?是因为通过视频能方便快捷地获取到大量信息。但视频数据量非常巨大,视频的网络传输也面临着巨大的挑战。于是视频编解码技术就出场了。

具体到实时视频场景,不仅仅是数据量的问题,实时通信对时延要求、设备适配、带宽适应的要求也非常高,要解决这些问题,始终离不开视频编解码技术的范畴。

本文将从视频编解码技术的基础知识入手,引出视频编解码技术中非常基础且重要的预测技术,学习帧内预测和帧间预测的技术原理。

本文已同步发布于:http://www.52im.net/thread-3581-1-1.html

2、相关文章

如果你是音视频技术初学者,以下3篇入门级干货非常推荐一读:

零基础,史上最通俗视频编码技术入门

零基础入门:实时音视频技术基础知识全面盘点

实时音视频面视必备:快速掌握11个视频技术相关的基础概念

3、为什么需要视频编解码

首先,来复习一下视频编解码方面的理论常识。

视频是由一系列图片按照时间顺序排列而成:

  • 1)每一张图片为一帧;
  • 2)每一帧可以理解为一个二维矩阵;
  • 3)矩阵的每个元素为一个像素。

一个像素通常由三个颜色进行表达,例如用RGB颜色空间表示时,每一个像素由三个颜色分量组成。每一个颜色分量用1个字节来表达,其取值范围就是0~255。编码中常用的YUV格式与之类似,这里不作展开。

1280x720@60fps的视频序列为例,十秒钟的视频有:1280*720*3*60*10 = 1.6GB

如此大量的数据,无论是存储还是传输,都面临巨大的挑战。视频压缩或者编码的目的,也是为了保证视频质量的前提下,将视频减小,以利于传输和存储。同时,为了能正确还原视频,需要将其解码。

PS:限于篇幅,视频编解码方面的技术原理就不在此展开,有兴趣强烈推荐从这篇深入学习:即时通讯音视频开发(十九):零基础,史上最通俗视频编码技术入门》。

总之,视频编解码技术的主要作用就是:在可用的计算资源内,追求尽可能高的视频重建质量和尽可能高的压缩比,以达到带宽和存储容量的要求。

为何突出“重建质量”?

因为视频编码是个有损的过程,用户只能从收到的视频流中解析出“重建”画面,它与原始的画面已经不同,例如观看低质量视频时经常会碰到的“块”效应。

如何在一定的带宽占用下,尽可能地保持视频的质量,或者在保持质量情况下,尽可能地减少带宽利用率,是视频编码的基本目标。

用专业术语来说,即视频编解码标准的“率失真”性能:

  • 1)“率”是指码率或者带宽占用;
  • 2)“失真”是用来描述重建视频的质量。

与编码相对应的是解码或者解压缩过程,是将接收到的或者已经存储在介质上的压缩码流重建成视频信号,然后在各种设备上进行显示。

4、什么是视频编解码标准

视频编解码标准,通常只定义上述的解码过程。

例如 H.264 / AVC 标准,它定义了什么是符合标准的视频流,对每一个比特的顺序和意义都进行了严格地定义,对如何使用每个比特或者几个比特表达的信息也有精确的定义。

正是这样的严格和精确,保证了不同厂商的视频相关服务,可以很方便地兼容在一起,例如用 iPhone、Android Phone 或者 windows PC 都可以观看同一在线视频网站的同一视频。

世界上有多个组织进行视频编码标准的制定工作,国际标准组织 ISO 的 MPEG 小组、国际电信联盟 ITU-T 的 VCEG 小组、中国的 AVS 工作组、Google 及各大厂商组成的开放媒体联盟等。

视频编码标准及发展历史:

自 VCEG 制定 H.120标准开始,视频编码技术不断发展,先后成功地制定了一系列满足不同应用场景的视频编码标准。VCEG 组织先后制定了H.120、H.261、H.262(MPEG-2 Part 2)、H.263、H.263+、H.263++

MPEG也先后制定了MPEG-1、MPEG-2、MPEG-4 Part 2。以及两个国际组织合作制定的H.264/AVC、H.265/HEVC、H.266/VVC

中国自主知识产权的 AVS、AVS2、AVS3 视频编码标准;Google 制定的 VP8、VP9。

Google、思科、微软、苹果等公司组成的开放媒体联盟(AOM)制定的 AV1。

这里特别提一下H.264/AVC:H.264/AVC虽有近20年历史,但它优秀的压缩性能、适当的运算复杂度、优秀的开源社区支持、友好的专利政策、强大的生态圈等多个方面的因素,依旧让它保持着强大的生命力,特别是在实时通信领域。像 ZOOM、思科 Webex 等视频会议产品和基于 WebRTC SDK 的视频服务,大多数主流场景都采用 H.264/AVC。

有关视频编解码标准,这里就不深入展开。更多详细资料,可以读一下下面这些精选文章:

即时通讯音视频开发(五):认识主流视频编码技术H.264

即时通讯音视频开发(十三):实时视频编码H.264的特点与优势

即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生

爱奇艺技术分享:轻松诙谐,讲解视频编解码技术的过去、现在和将来

5、混和编码框架

纵观视频编解码标准历史,每一代视频标准都在率失真性能上有着显著的提升,他们都有一个核心的框架,就是基于块的混合编码框架(如下图所示)。它是由J. R. Jain 和A. K. Jain在1979年的国际图像编码学会(PCS 1979)上提出了基于块运动补偿和变换编码的混合编码框架。

我们一起来对该框架进行拆解和分析。

从摄像头采集到的一帧视频:通常是 YUV 格式的原始数据,我们将它划分成多个方形的像素块依次进行处理(例如 H.264/AVC 中以16x16像素为基本单元),进行帧内/帧间预测、正变换、量化、反量化、反变换、环路滤波、熵编码,最后得到视频码流。从视频第一帧的第一个块开始进行空间预测,因当前正在进行编码处理的图像块和其周围的图像块有相似性,我们可以用周围的像素来预测当前的像素。我们将原始像素减去预测像素得到预测残差,再将预测残差进行变换、量化,得到变换系数,然后将其进行熵编码后得到视频码流。

接下来:为了可以使后续的图像块可以使用已经编码过的块进行预测,我们还要对变换系统进行反量化、反变换,得到重建残差,再与预测值进行求合,得到重建图像。最后我们对重建图像进行环路滤波、去除块效应等,这样得到的重建图像,就可以用来对后续图像块进行预测了。按照以上步骤,我们依次对后续图像块进行处理。

对于视频而言:视频帧与帧的间隔大约只有十到几十毫秒,通常拍摄的内容不会发生剧烈变化,它们之间存在非常强的相关性。

如下图所示,将视频图像分割成块,在时间相邻的图像之间进行匹配,然后将匹配之后的残差部分进行编码,这样可以较好地去除视频信号中的视频帧与帧之间的冗余,达到视频压缩的目的。这就是运动补偿技术,直到今天它仍然是视频编解码的核心技术之一。

运动估计和运动补偿:

变换编码的核心思想:是把视频数据分割成块,利用正交变换将数据的能量集中到较少几个变换系数上。结合量化和熵编码,我们可以获得更有效的压缩。视频编码中信息的损失和压缩比的获得,很大程度上来源于量化模块,就是将源信号中的单一样本映射到某一固定值,形成多到少的映射,从而达到压缩的目的,当然在压缩的过程中就引入了损失。量化后的信号再进行无损的熵编码,消除信号中的统计冗余。熵编码的研究最早可以追溯到 20 世纪 50 年代,经过几十年的发展,熵编码在视频编码中的应用更加成熟、更加精巧,充分利用视频数据中的上下文信息,将概率模型估计得更加准确,从而提高了熵编码的效率。例如H.264/AVC中的Cavlc(基于上下文的变长编码)、Cabac(基于上下文的二进制算术编码)。算术编码技术在后续的视频编码标准,如AV1、HEVC/H.265、VVC/H.266 中也有应用。

视频编码发展至今,VVC/H.266 作为最新制定的标准,采纳了一系列先进的技术,对混合编码框架的各个部分都进行了优化和改进,使得其率失真性能相比前一代标准,又提高了一倍。

例如:VVC/H.266 采用了128x128大小的基本编码单元,并且可以继续进行四叉树划分,支持对一个划分进行二分、三分;色度分量独立于亮度分量,支持单独进行划分;更多更精细的帧内预测方向、帧间预测模式;支持多种尺寸和形式的变换、环内滤波等。

VVC/H.266 的制定,目标是对多种视频内容有更好支持,例如屏幕共享内容、游戏、动漫、虚拟现实内容(VR、AR)等。其中也有特定的技术被采纳进标准,例如调色板模式、帧内运动补偿、仿射变换、跳过变换、自适应颜色变换等。   

回到本文的正题,接下来的内容,我们着重介绍视频编解码中的预测技术。

6、帧内预测技术

视频数据被划分成方块之后,相邻的方块的像素,以及方块内的像素,颜色往往是逐渐变化的,他们之间有比较强的有相似性。这种相似性,就是空间冗余。既然存在冗余,就可以用更少的数据量来表达这样的特征。

比如:先传输第一个像素的值,再传输第二个像素相对于第一个像素的变化值,这个变化值往往取值范围变小了许多,原来要8个bit来表达的像素值,可能只需要少于8个bit就足够了。

同样的道理,以像素块为基本单位,也可以进行类似的“差分”操作。我们从示例图中,来更加直观地感受一下这样的相似性。

如上图中所标出的两个8x8的块:其亮度分量(Y)沿着“左上到右下”的方向,具有连续性,变化不大。

假如:我们设计某种特定的“模式”,使其利用左边的块来“预测”右边的块,那么“原始像素”减去“预测像素”就可以减少传输所需要的数据量,同时将该“模式”写入最终的码流,解码器便可以利用左侧的块来“重建”右侧的块。

极端一点讲:假如左侧的块的像素值经过一定的运算可以完全和右侧的块相同,那么编码器只要用一个“模式”的代价,传输右侧的块。

当然,视频中的纹理多种多样,单一的模式很难对所有的纹理都适用,因此标准中也设计了多种多样的帧内预测模式,以充分利用像素间的相关性,达到压缩的目的。

例如下图所示的H.264中9种帧内预测方向:以模式0(竖直预测)为例,上方块的每个像素值(重建)各复制一列,得到帧内预测值。其它各种模式也采用类似的方法,不过,生成预测值的方式稍有不同。有这么多的模式,就产生了一个问题,对于一个块而言,我们应该采用哪种模式来进行编码呢?最佳的选择方式,就是遍历所有的模式进行尝试,计算其编码的所需的比特数和产生的质量损失,即率失真优化,这样明显非常复杂,因而也有很多种其它的方式来推断哪种模式更好,例如基于SATD或者边缘检测等。

从H.264的9种预测模式,到AV1的56种帧内方向预测模式,越来越多的模式也是为了更加精准地预测未编码的块,但是模式的增加,一方面增加了传输模式的码率开销,另一方面,从如此重多的模式中选一个最优的模式来编码,使其能达到更高的压缩比,这对编码器的设计和实现也提出了更高的要求。

7、帧间预测技术

以下5张图片是一段视频的前5帧:可以看出,图片中只有Mario和砖块在运动,其余的场景大多是相似的,这种相似性就称之为时间冗余。编码的时候,我们先将第一帧图片通过前文所述的帧内预测方式进行编码传输,再将后续帧的Mario、砖块的运动方向进行传输,解码的时候,就可以将运动信息和第一帧一起来合成后续的帧,这样就大大减少了传输所需的bit数。这种利用时间冗余来进行压缩的技术,就是运动补偿技术。该技术早在H.261标准中,就已经被采用。

细心地读者可能已经发现:Mario和砖块这样的物体怎么描述,才能让它仅凭运动信息就能完整地呈现出来?

其实视频编码中并不需要知道运动的物体的形状,而是将整帧图像划分成像素块,每个像素块使用一个运动信息。即基于块的运动补偿。

下图中红色圈出的白色箭头即编码砖块和Mario时的运动信息,它们都指向了前一帧中所在的位置。Mario和砖块都有两个箭头,说明它们都被划分在了两个块中,每一个块都有单独的运动信息。这些运动信息就是运动矢量。运动矢量有水平和竖直两个分量,代表是的一个块相对于其参考帧的位置变化。参考帧就是已经编码过的某一(多)个帧。

当然:传输运动矢量本身就要占用很多 bit。为了提高运动矢量的传输效率,主要有以下措施。

一方面:可以尽可能得将块划分变大,共用一个运动矢量,因为平坦区域或者较大的物体,他们的运动可能是比较一致的。从 H.264 开始,可变块大小的运动补偿技术被广泛采用。

另一方面:相邻的块之间的运动往往也有比较高的相似性,其运动矢量也有较高的相似性,运动矢量本身也可以根据相邻的块运动矢量来进行预测,即运动矢量预测技术;

最后:运动矢量在表达物体运动的时候,有精度的取舍。像素是离散化的表达,现实中物体的运动显然不是以像素为单位进行运动的,为了精确地表达物体的运动,需要选择合适的精度来定义运动矢量。各视频编解码标准都定义了运动矢量的精度,运动矢量精度越高,越能精确地表达运动,但是代价就是传输运动矢量需要花费更多的bit。

H.261中运动矢量是以整像素为精度的,H.264中运动矢量是以四分之一像素为精度的,AV1中还增加了八分之一精度。一般情况,时间上越近的帧,它们之间的相似性越高,也有例外,例如往复运动的场景等,可能相隔几帧,甚至更远的帧,会有更高的相似度。

为了充分利用已经编码过的帧来提高运动补偿的准确度,从H.264开始引入了多参考帧技术。

即:一个块可以从已经编码过的很多个参考帧中进行运动匹配,将匹配的帧索引和运动矢量信息都进行传输。

那么如何得到一个块的运动信息呢?最朴素的想法就是,将一个块,在其参考帧中,逐个位置进行匹配检查,匹配度最高的,就是最终的运动矢量。

匹配度:常用的有SAD(Sum of Absolute Difference)、SSD(Sum of Squared Difference)等。逐个位置进行匹配度检查,即常说的全搜索运动估计,其计算复杂度可想而知是非常高的。为了加快运动估计,我们可以减少搜索的位置数,类似的有很多算法,常用的如钻石搜索、六边形搜索、非对称十字型多层次六边形格点搜索算法等。

以钻石搜索为例,如下图所示,以起始的蓝色点为中心的9个匹配位置,分别计算这9个位置的SAD,如果SAD最小的是中心位置,下一步搜索中心点更近的周围4个绿色点的SAD,选择其中SAD最小的位置,继续缩小范围进行搜索;如果第一步中SAD最小的点不在中心,那么以该位置为中心,增加褐色的5或者3个点,继续计算SAD,如此迭代,直到找到最佳匹配位置。

编码器在实现时,可根据实际的应用场景,对搜索算法进行选择。

例如:在实时音视频场景下,计算复杂度是相对有限的,运动估计模块要选择计算量较小的算法,以平衡复杂度和编码效率。当然,运动估计与运动补偿的复杂度还与块的大小,参考帧的个数,亚像素的计算等有关,在此不再深入展开。

更多预测技术方面的原理这里就不再赘述。如果你对上面所述的预测技术理解上感到力不从心,这里有篇入门级的文章,可以先读读这篇《即时通讯音视频开发(四):视频编解码之预测技术介绍》。

8、写在最后

音视频编解码技术,归根结底就是在有限的资源下(网络带宽、计算资源等),让音质更清晰、视频更高质。

这其中,对于视频来说,质量的提升仍然有很多可以深入研究的热点问题。

比如:基于人眼的主观质量优化,主要利用人眼的视觉特性,将掩蔽效应、对比度灵敏度、注意力模型等与编码相结合,合理分配码率、减少编码损失引起的视觉不适。

AI在视频编解码领域的应用:包括将多种人工智能算法,如分类器、支持向量机、CNN等对编码参数进行快速选择,也可以使用深度学习对视频进行编码环外与编码环内的处理,如视频超分辨率、去噪、去雾、自适应动态范围调整等编码环外处理,达到提升视频质量的目的。

此外还有打破传统混合编码框架的深度神经网络编码,如Nvidia的Maxine视频会议服务,利用深度学习来提取特征,然后对特征进行传输以节省带宽。

附录:更多精华文章

[1] 实时音视频开发的其它精华资料:

[2] 开源实时音视频技术WebRTC的文章:

本文已同步发布于“即时通讯技术圈”公众号。

▲ 本文在公众号上的链接是:点此进入。同步发布链接是:http://www.52im.net/thread-3581-1-1.html

posted @ 2021-06-15 11:25 Jack Jiang 阅读(139) | 评论 (0)编辑 收藏

本文作者“商文默”,有修订和改动。

1、写在前面

即时通讯网整理的大量IM技术文章中(见本文末“参考资料”一节),有关消息可靠性和一致性问题的文章占了很大比重,原因是IM这类系统抛开各种眼花缭乱的产品功能和技术特性,保证消息的可靠性和一致性几乎是IM产品必需的素质。

试想如果一个IM连发出的消息都不知道对方到底能不能收到、发出的聊天内容对方看到的到底是不是“胡言乱语”(严重乱序问题),这样的APP用户肯定不会让他在手机上过夜(肯定第一时间卸载了),因为最基本的聊天逻辑都无法实现,它已经失去了IM软件本身的意义。

不过,另一个方面来讲,IM系统是不标准的(虽然曾经XMPP这种协议试图解决这个问题,但事实证明那根本不现实),各家几乎都是自已的私有协议、不同的实现逻辑,这也决定了即使同一个技术问题,对于IM来说很难有固定的实现套路和标准的解决方案。

所以,对于本文来说,文中作者虽然提供了有关IM消息“可靠性”与“一致性”问题的解决方案,但方案到底合不合理、适不适合你,这就是仁者见仁、智者见智的事了。用人话说就是:本文内容仅供参考,具体的解决方案请务结合自已的系统构架和实现情况,多阅读几篇即时通讯网上有关这个技术话题的文章,取其精华,找到适合自已的技术方案和思路才是最明智的。

学习交流:

- 即时通讯/推送技术开发交流5群:215477170 [推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

- 开源IM框架源码:https://github.com/JackJiang2011/MobileIMSDK

本文同步发布于:http://www.52im.net/thread-3574-1-1.html

2、本文引言

丛所周之,即时通讯聊天(IM)系统必需要解决消息可靠性及消息一致性问题(PS:如果具体IM系统是什么你都还没弄明白,先读这篇《零基础IM开发入门(一):什么是IM系统?)。

这两个问题,通俗来说就是:

  • 1)消息可靠性:简单来说就是不丢消息,会话一方发送消息,消息成功到达对方并正确显示;
  • 2)消息一致性:包括发送一方消息一致及会话双方消息一致,要求消息不重复,不乱序。

本文会从典型的IM消息发送逻辑开始,简单易懂地阐明消息可靠性、一致性问题的原理及可参考的技术解决方法,或许技术方案并不完美,但希望能为你的IM技术问题解决带来启发。

3、典型IM消息发送过程

IM的消息发送一般的实现过程可以分为两个阶段:

  • 1)发送方发送消息、服务端接收、返回消息 ACK 给发送方;
  • 2)服务端将消息推送到接收方。

判断消息发送是否成功主要依据第一阶段——即服务器是否接受到消息。

对于消息发送者来说,消息状态可以分为三类:

  • 1)正在发送;
  • 2)发送成功;
  • 3)发送失败。

具体来说,这三类状态的具体意义是:

  • 1)正在发送:发送方触发发送事件开始,到收到服务端返回消息对应 ACK 之前;
  • 2)发送成功:发送方收到消息对应 ACK 回复;
  • 3)发送失败:超过一定重发次数,未收到消息对应 ACK 回复。

对应的消息发送流程如下图所示:

4、IM消息可靠性

限于篇幅,对于IM消息可靠性的基本概念和详细原理建议阅读《零基础IM开发入门(三):什么是IM系统的可靠性?》,本文着重谈谈解决思路。

4.1 重发机制

保证消息发送第一阶段(见本文“3、典型IM消息发送过程”一节)消息成功发送的方法是设立重发机制:

  • 1)依据一定时长内是否收到消息对应 ACK,判断消息是否要重发;
  • 2)如果超过预设时长,就重新发送;
  • 3)当重发次数超过预设次数,就不再重发,判定该消息发送失败,修改消息发送状态。

PS:具体的完整方案级代码实现,可以参考MobileIMSDK  中有关QoS机制的代码实现。

4.2 会话记录检查

消息发送第二阶段(见本文“3、典型IM消息发送过程”一节)服务端推送消息到接收方,如果连接断开,会丢失消息。

所以要保证消息完整,就需要在建立连接后,根据上一条消息(已经 ACK)时间戳,获取会话记录,一次返回一段时间内所有消息(PS:中大型应用中,消息的拉取也不是个简单事情,详情可以阅读《IM开发干货分享:如何优雅的实现大量离线消息的可靠投递)。

另一种保证方法是加入定时轮询,检查消息完整性,具体的思路如下图所示。

建立连接流程图:

4.3 需要考虑的两个问题

消息重发、会话记录检查需要考虑两个问题:

  • 1)消息是否会重复发送;
  • 2)消息顺序是否会被打乱。

举两个例子。

关于消息重发问题:

  • 1)如果丢消息的点在消息达到服务端之前,服务端并没有收到消息,发送方重新发送丢失消息,服务端接收成功,不会产生两条相同消息;
  • 2)而如果服务端接收到消息,返回 ACK 丢失,这时再发送一次相同消息,就可能造成消息重复。

关于消息顺序问题:

  • 1)如果发送方连发三条消息,第一、第三条成功被服务端接收,第二条丢了,那第三条消息是否会被记录?
  • 2)如果这时第二条消息达到服务端,其顺序是在第三条时间之前还是之后(服务端一般都会给记录打一个时间戳)?

5、IM消息一致性

同上节一样,对于IM消息一致性的基本概念和详细原理建议阅读《零基础IM开发入门(四):什么是IM系统的消息时序一致性?》。

5.1 使用 uuid 消息去重

对于消息重发问题,可以给每条消息增加属性 uuid 作为消息唯一标识,重发消息 uuid 不变,前端根据 uuid 去重。大致思路就是这样。

PS:对于IM来说,消息ID也是个很大的技术话题,有兴趣可以读下面这个系列:

IM消息ID技术专题(一):微信的海量IM聊天消息序列号生成实践(算法原理篇)

IM消息ID技术专题(二):微信的海量IM聊天消息序列号生成实践(容灾方案篇)

IM消息ID技术专题(三):解密融云IM产品的聊天消息ID生成策略

IM消息ID技术专题(四):深度解密美团的分布式ID生成算法

IM消息ID技术专题(五):开源分布式ID生成器UidGenerator的技术实现

IM消息ID技术专题(六):深度解密滴滴的高性能ID生成器(Tinyid)

5.2 使用向量时钟进行消息排序

对于消息排序问题:因为在聊天中,消息的顺序对于发送方的表述有重要的影响,消息不完整或顺序颠倒都可能造成语意不连贯,甚至曲解。所以需要保证发送方发送消息顺序,而会话双方消息排序需要考虑实际情况。

在一般的认知里:状态是正在发送的消息,应该还没有被对方看到,只有发送成功的消息,才会被对方看到。但在实现中,消息发送成功是以服务器接收消息并返回 ACK 成功为判断依据,而不是被对方接收到。

那么就会出现这样一个问题:如果一条消息状态是正在发送,此时收到一条消息,那么收到的消息是在正在发送的消息之前还是之后?

这是一个上下文关系,关键问题是:发送方是以哪条所见消息为依据发送消息的。

这里提供一种思路:借鉴分布式系统中的向量时钟算法(见《分布式系统中的向量时钟算法)。

先简单描述向量时钟算法:

向量时钟算法用于在分布式系统中生成事件偏序关系,并纠正因果关系。一个系统包含 N 个节点,每个节点产生的消息体中包含该节点的逻辑时钟,整体系统的向量时钟由 N 维逻辑时钟组成,并在每个节点产生的消息体中传递。

简单来说,向量时钟算法的实现原理如下:

  • 1)初始状态,向量值为 0;
  • 2)每次节点处理完节点事件,该节点时钟+1;
  • 3)每次节点发送消息,将包含自身时钟的系统向量时钟一起发送;
  • 4)每次节点收到消息,更新向量时钟,该节点时钟+1,其他节点对比每个节点本地保留的向量时钟值和消息体中向量时钟值,取最大值;
  • 5)节点同时收到多条消息,判断接收消息的向量时钟之间是否存在偏序关系。

针对上述的第5)点:

  • 1)如果存在偏序关系,则合并向量时钟,取偏序较大的向量时钟;
  • 2)如果不存在偏序关系,则不能合并。

偏序关系:如果 A 向量中的每一维都大于等于 B 向量,则 A、B 之间存在偏序关系,否则不存在偏序关系。

对于IM为聊天消息排序来说,其实就是处理聊天消息的上下文语境,决定消息之间的因果关系。

参考向量时钟算法:假设有 N 个消息会话方,系统的向量时钟由 N 维时钟组成,向量时钟在各方发送的消息体中传递,并依据向量时钟排序。

具体实现思路如下:

  • 1)系统向量时钟设为 (0, 0, …, N);
  • 2)节点发送消息,更新系统向量时钟,该节点时钟加一,其他节点不变;
  • 3)节点接收消息,更新系统向量时钟,该节点时钟加一;其他节点对比每个节点本地保留的向量时钟的值和消息中向量时钟的值,取最大值;
  • 4)依据消息体内系统向量时钟的偏序关系决定消息顺序。

针对上述第4)点:

  • 1)如果可以确定偏序关系,则根据偏序关系由小到大显示;
  • 2)如果多条消息不能确定偏序关系,则按照自然顺序(接收到的顺序)显示。

向量时钟在理论上可以解决大部分消息一致性的问题,但在实现中还需要考虑实际使用时的体验。

这其中最需要关注的问题是:是否要强制排序,或者说,如果实际显示顺序和向量时钟之间的偏序关系不一致,是否要移动消息之间的顺序。

举个例子:在一个有多人的会话中,如果有一方网速特别慢,收不到消息,也发不出消息。在他看到的最后的消息之后,其他人已经开始新的话题,这时他关于上一个话题的消息终于发送成功,并被其他人收到。

此时就存在这样一个问题:这条关于上一个话题的消息是显示在最后,还是移到较早时间?

  • 1)如果显示在最后,但消息内容和目前的话题不相关,其他人可能会感到莫名其妙;
  • 2)如果把消息移到较早时间,那么这条消息可能不会被其他人看到,或者看到前面多了一条消息,会有种突兀的感觉。

IM 的场景很多,也很复杂,更多的时候需要从产品角度考虑问题。

对于消息是否需要排序的问题,这里只提出一个比较通用的方案:建议会话中不强制排序,会话历史记录中按照向量时钟的偏序关系进行排序。

6、本文小结

对于 IM 系统消息可靠性及一致性问题,通过消息重发机制保证消息成功被服务端接收,通过会话记录检查保证收取消息完整,从而保证整个消息发送过程的可靠性。使用 uuid 消息去重,参考向量时钟算法进行消息排序,为保证消息一致性提供一种解决方案。

总之,IM这类系统看似简单,实则水深似海,如果你是IM开发新手,可以从《新手入门一篇就够:从零开发移动端IM》这篇入手系统学习。如果你自认为已是IM老手,这里整理的 IM中大型架构设计 方面的文章或许可以参考一下。

7、参考资料

[1] 零基础IM开发入门(三):什么是IM系统的可靠性?

[2] 零基础IM开发入门(四):什么是IM系统的消息时序一致性?

[3] IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

[4] IM消息送达保证机制实现(二):保证离线消息的可靠投递

[5] 如何保证IM实时消息的“时序性”与“一致性”?

[6] 一个低成本确保IM消息时序的方法探讨

[7] IM群聊消息如此复杂,如何保证不丢不重?

[8] 完全自已开发的IM该如何设计“失败重试”机制?

[9] IM开发干货分享:如何优雅的实现大量离线消息的可靠投递

[10] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[11] 一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等

[12] 从新手到专家:如何设计一套亿级消息量的分布式IM系统

本文已同步发布于“即时通讯技术圈”公众号。

▲ 本文在公众号上的链接是:点此进入。同步发布链接是:http://www.52im.net/thread-3574-1-1.html

posted @ 2021-06-07 20:34 Jack Jiang 阅读(167) | 评论 (0)编辑 收藏

     摘要: 本文由喜马拉雅技术团队原创分享,原题《喜马拉雅自研网关架构实践》,有改动。1、引言网关是一个比较成熟的产品,基本上各大互联网公司都会有网关这个中间件,来解决一些公有业务的上浮,而且能快速的更新迭代。如果没有网关,要更新一个公有特性,就要推动所有业务方都更新和发布,那是效率极低的事,有网关后,这一切都变得不是问题。喜马拉雅也是一样,用户数增长达到 6 亿多的级别,Web 服务个数达到500+,目前我...  阅读全文

posted @ 2021-05-31 10:30 Jack Jiang 阅读(237) | 评论 (0)编辑 收藏

     摘要: 本文来自“糊糊糊糊糊了”的分享,原题《实时消息推送整理》,有优化和改动。1、写在前面对Web端即时通讯技术熟悉的开发者来说,我们回顾网页端IM的底层通信技术,从短轮询、长轮询,到后来的SSE以及WebSocket,使用门槛越来越低(早期的长轮询Comet这类技术实际属于hack手段,使用门槛并不低),技术手段越来越先进,网页端即时通讯技术的体验也因此越来越好。但上周在编辑《...  阅读全文

posted @ 2021-05-25 12:18 Jack Jiang 阅读(171) | 评论 (0)编辑 收藏

本文由爱奇艺技术团队原创分享,原题《构建通用WebSocket推送网关的设计与实践》,有优化和改动。

1、引言

丛所周之,HTTP协议是一种无状态、基于TCP的请求/响应模式的协议,即请求只能由客户端发起、由服务端进行响应。在大多数场景,这种请求/响应的Pull模式可以满足需求。但在某些情形:例如消息推送(IM中最为常见,比如IM的离线消息推送)、实时通知等应用场景,需要实时将数据同步到客户端,这就要求服务端支持主动Push数据的能力。

传统的Web服务端推送技术历史悠久,经历了短轮询、长轮询等阶段的发展(见《新手入门贴:史上最全Web端即时通讯技术原理详解),一定程度上能够解决问题,但也存在着不足,例如时效性、资源浪费等。HTML5标准带来的WebSocket规范基本结束了这一局面,成为目前服务端消息推送技术的主流方案。

在系统中集成WebSocket十分简单,相关讨论与资料很丰富。但如何实现一个通用的WebSocket推送网关尚未有成熟的方案。目前的云服务厂商主要关注iOS和安卓等移动端推送,也缺少对WebSocket的支持。本文分享了爱奇艺基于Netty实现WebSocket长连接实时推送网关时的实践经验总结。

学习交流:

- 即时通讯/推送技术开发交流5群:215477170 [推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

- 开源IM框架源码:https://github.com/JackJiang2011/MobileIMSDK

本文同步发布于:http://www.52im.net/thread-3539-1-1.html

2、专题目录

本文是系列文章的第4篇,总目录如下:

长连接网关技术专题(一):京东京麦的生产级TCP网关技术实践总结

长连接网关技术专题(二):知乎千万级并发的高性能长连接网关技术实践

长连接网关技术专题(三):手淘亿级移动端接入层网关的技术演进之路

长连接网关技术专题(四):爱奇艺WebSocket实时推送网关技术实践》(* 本文

其它相关技术文章:

绝对干货:基于Netty实现海量接入的推送服务技术要点

京东到家基于Netty的WebSocket应用实践分享

爱奇艺技术团队分享的其它文章:

爱奇艺技术分享:轻松诙谐,讲解视频编解码技术的过去、现在和将来

爱奇艺技术分享:爱奇艺Android客户端启动速度优化实践总结

爱奇艺移动端网络优化实践分享:网络请求成功率优化篇

3、旧方案存在的技术痛点

爱奇艺号是我们内容生态的重要组成,作为前台系统,对用户体验有较高要求,直接影响着创作者的创作热情。

目前,爱奇艺号多个业务场景中用到了WebSocket实时推送技术,包括:

  • 1)用户评论:实时的将评论消息推送到浏览器;
  • 2)实名认证:合同签署前需要对用户进行实名认证,用户扫描二维码后进入第三方的认证页面,认证完成后异步通知浏览器认证的状态;
  • 3)活体识别:类似实名认证,当活体识别完成后,异步将结果通知浏览器。

在实际的业务开发中,我们发现,WebSocket实时推送技术在使用中存在一些问题。

这些问题是:

  • 1)首先:WebSocket技术栈不统一,既有基于Netty实现的,也有基于Web容器实现的,给开发和维护带来困难;
  • 2)其次:WebSocket实现分散在在各个工程中,与业务系统强耦合,如果有其他业务需要集成WebSocket,面临着重复开发的窘境,浪费成本、效率低下;
  • 3)第三:WebSocket是有状态协议的,客户端连接服务器时只和集群中一个节点连接,数据传输过程中也只与这一节点通信。WebSocket集群需要解决会话共享的问题。如果只采用单节点部署,虽然可以避免这一问题,但无法水平扩展支撑更高负载,有单点的风险;
  • 4)最后:缺乏监控与报警,虽然可以通过Linux的Socket连接数大致评估WebSocket长连接数,但数字并不准确,也无法得知用户数等具有业务含义的指标数据;无法与现有的微服务监控整合,实现统一监控和报警。

PS:限于篇幅本文不详细介绍WebSocket技术本身,有兴趣可以详读《WebSocket从入门到精通,半小时就够!》。

4、新方案的技术目标

如上节所示,为了解决旧方案中存在的问题,我们需要实现统一的WebSocket长连接实时推送网关。

这套新的网关需要具备如下特点:

  • 1)集中实现长连接管理和推送能力:统一技术栈,将长连接作为基础能力沉淀,便于功能迭代和升级维护;
  • 2)与业务解耦:将业务逻辑与长连接通信分离,使业务系统不再关心通信细节,也避免了重复开发,浪费研发成本;
  • 3)使用简单:提供HTTP推送通道,方便各种开发语言的接入。业务系统只需要简单的调用,就可以实现数据推送,提升研发效率;
  • 4)分布式架构:实现多节点的集群,支持水平扩展应对业务增长带来的挑战;节点宕机不影响服务整体可用性,保证高可靠;
  • 5)多端消息同步:允许用户使用多个浏览器或标签页同时登陆在线,保证消息同步发送;
  • 6)多维度监控与报警:自定义监控指标与现有微服务监控系统打通,出现问题时可及时报警,保证服务的稳定性。

5、新方案的技术选型

在众多的WebSocket实现中,从性能、扩展性、社区支持等方面考虑,最终选择了Netty。Netty是一个高性能、事件驱动、异步非阻塞的网络通信框架,在许多知名的开源软件中被广泛使用。

PS:如果你对Netty知之甚少,可以详读以下两篇:

WebSocket是有状态的,无法像直接HTTP以集群方式实现负载均衡,长连接建立后即与服务端某个节点保持着会话,因此集群下想要得知会话属于哪个节点有点困难。

解决以上问题一般有两种技术方案:

  • 1)一种是使用类似微服务的注册中心来维护全局的会话映射关系;
  • 2)一种是使用事件广播由各节点自行判断是否持有会话,两种方案对比如下表所示。

WebSocket集群方案:

综合考虑实现成本与集群规模,选择了轻量级的事件广播方案。

实现广播可以选择基于RocketMQ的消息广播、基于Redis的Publish/Subscribe、基于ZooKeeper的通知等方案,其优缺点对比如下表所示。从吞吐量、实时性、持久化、实现难易等方面考虑,最终选择了RocketMQ。

广播的实现方案对比:

6、新方案的实现思路

6.1 系统架构

网关的整体架构如下图所示:

网关的整体流程如下:

1)客户端与网关任一节点握手建立起长连接,节点将其加入到内存维护的长连接队列。客户端定时向服务端发送心跳消息,如果超过设定的时间仍没有收到心跳,则认为客户端与服务端的长连接已断开,服务端会关闭连接,清理内存中的会话。

2)当业务系统需要向客户端推送数据时,通过网关提供的HTTP接口将数据发向网关。

3)网关在接收到推送请求后,将消息写入RocketMQ。

4)网关作为消费者,以广播模式消费消息,所有节点都会接收到消息。

5)节点接收到消息后判断推送的消息目标是否在自己内存中维护的长连接队列里,如果存在则通过长连接推送数据,否则直接忽略。

网关以多节点方式构成集群,每节点负责一部分长连接,可实现负载均衡,当面对海量连接时,也可以通过增加节点的方式分担压力,实现水平扩展。

同时,当节点出现宕机时,客户端会尝试重新与其他节点握手建立长连接,保证服务整体的可用性。

6.2 会话管理

WebSocket长连接建立起来后,会话维护在各节点的内存中。SessionManager组件负责管理会话,内部使用了哈希表维护了UID与UserSession的关系。

UserSession代表用户维度的会话,一个用户可能会同时建立多个长连接,因此UserSession内部同样使用了一个哈希表维护Channel与ChannelSession的关系。

为了避免用户无限制的创建长连接,UserSession在内部的ChannelSession超过一定数量后,会将最早建立的ChannelSession关闭,减少服务器资源占用。SessionManager、UserSession、ChannelSession的关系如下图所示。

SessionManager组件:

6.3 监控与报警

为了了解集群建立了多少长连接、包含了多少用户,网关提供了基本的监控与报警能力。

网关接入了Micrometer,将连接数与用户数作为自定义指标暴露,供Prometheus进行采集,实现了与现有的微服务监控系统打通。

Grafana中方便地查看连接数、用户数、JVM、CPU、内存等指标数据,了解网关当前的服务能力与压力。报警规则也可以在Grafana中配置,当数据异常时触发奇信(内部报警平台)报警。

7、新方案的性能压测

压测准备:

  • 1)压测选择两台配置为4核16G的虚拟机,分别作为服务器和客户端;
  • 2)压测时选择为网关开放了20个端口,同时建立20个客户端;
  • 3)每个客户端使用一个服务端端口建立起5万连接,可以同时创建百万个连接。

连接数(百万级)与内存使用情况如下图所示:

给百万个长连接同时发送一条消息,采用单线程发送,服务器发送完成的平均耗时在10s左右,如下图所示。

服务器推送耗时: 

一般同一用户同时建立的长连接都在个位数。以10个长连接为例,在并发数600、持续时间120s条件下压测,推送接口的TPS大约在1600+,如下图所示。

长连接10、并发600、持续时间120s的压测数据:

当前的性能指标已满足我们的实际业务场景,可支持未来的业务增长。

8、新方案的实际应用案例

为了更生动的说明优化效果,文章最后,我们也以封面图添加滤镜效果为例,介绍一个爱奇艺号使用新WebSocket网关方案的案例。

爱奇艺号自媒体发表视频时,可选择为封面图添加滤镜效果,引导用户提供提供更优质的封面。

当用户选择一个封面图后,会提交异步的后台处理任务。当异步任务处理完成后,通过WebSocket将不同滤镜效果处理后的图片返回给浏览器,业务场景如下图所示。

从研发效率方面考虑,如果在业务系统中集成WebSocket,至少需要1-2天的开发时间。

如果直接使用新的WebSocket网关的推送能力,只需要简单的接口调用就实现了数据推送,开发时间降低到分钟级别,研发效率大大提高。

从运维成本方面考虑,业务系统不再含有与业务逻辑无关的通信细节,代码的可维护性更强,系统架构变得更加简单,运维成本大大降低。

9、写在最后

WebSocket是目前实现服务端推送的主流技术,恰当使用能够有效提供系统响应能力,提升用户体验。通过WebSocket长连接网关可以快速为系统增加数据推送能力,有效减少运维成本,提高开发效率。

长连接网关的价值在于:

  • 1)它封装了WebSocket通信细节,与业务系统解耦,使得长连接网关与业务系统可独立优化迭代,避免重复开发,便于开发与维护;
  • 2)网关提供了简单易用的HTTP推送通道,支持多种开发语言接入,便于系统集成和使用;
  • 3)网关采用了分布式架构,可以实现服务的水平扩容、负载均衡与高可用;
  • 4)网关集成了监控与报警,当系统异常时能及时预警,保证服务的健康和稳定。

目前,新的WebSocket长连接实时网关已在爱奇艺号图片滤镜结果通知、MCN电子签章等多个业务场景中得到应用。

未来还有许多方面需要探索,例如消息的重发与ACK、WebSocket二进制数据的支持、多租户的支持等。

附录:更多相关技术资料

[1] 有关WEB端即时通讯开发:

新手入门贴:史上最全Web端即时通讯技术原理详解

Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE

SSE技术详解:一种全新的HTML5服务器推送事件技术

Comet技术详解:基于HTTP长连接的Web端实时通信技术

新手快速入门:WebSocket简明教程

WebSocket详解(一):初步认识WebSocket技术

WebSocket详解(二):技术原理、代码演示和应用案例

WebSocket详解(三):深入WebSocket通信协议细节

WebSocket详解(四):刨根问底HTTP与WebSocket的关系(上篇)

WebSocket详解(五):刨根问底HTTP与WebSocket的关系(下篇)

WebSocket详解(六):刨根问底WebSocket与Socket的关系

socket.io实现消息推送的一点实践及思路

LinkedIn的Web端即时通讯实践:实现单机几十万条长连接

Web端即时通讯技术的发展与WebSocket、Socket.io的技术实践

Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)

开源框架Pomelo实践:搭建Web端高性能分布式IM聊天服务器

使用WebSocket和SSE技术实现Web端消息推送

详解Web端通信方式的演进:从Ajax、JSONP 到 SSE、Websocket

MobileIMSDK-Web的网络层框架为何使用的是Socket.io而不是Netty?

理论联系实际:从零理解WebSocket的通信原理、协议格式、安全性

微信小程序中如何使用WebSocket实现长连接(含完整源码)

八问WebSocket协议:为你快速解答WebSocket热门疑问

Web端即时通讯实践干货:如何让你的WebSocket断网重连更快速?

WebSocket从入门到精通,半小时就够!

WebSocket硬核入门:200行代码,教你徒手撸一个WebSocket服务器

>> 更多同类文章 ……

[2] 有关推送技术的文章:

一个基于MQTT通信协议的完整Android推送Demo

求教android消息推送:GCM、XMPP、MQTT三种方案的优劣

移动端实时消息推送技术浅析

绝对干货:基于Netty实现海量接入的推送服务技术要点

极光推送系统大规模高并发架构的技术实践分享

魅族2500万长连接的实时消息推送架构的技术实践分享

专访魅族架构师:海量长连接的实时消息推送系统的心得体会

基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)

一个基于长连接的安全可扩展的订阅/推送服务实现思路

实践分享:如何构建一套高可用的移动端消息推送系统?

Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)

腾讯信鸽技术分享:百亿级实时消息推送的实战经验

百万在线的美拍直播弹幕系统的实时推送技术实践之路

京东京麦商家开放平台的消息推送架构演进之路

技术干货:从零开始,教你设计一个百万级的消息推送系统

长连接网关技术专题(四):爱奇艺WebSocket实时推送网关技术实践

>> 更多同类文章 ……

本文已同步发布于“即时通讯技术圈”公众号。

▲ 本文在公众号上的链接是:点此进入。同步发布链接是:http://www.52im.net/thread-3539-1-1.html

posted @ 2021-05-17 23:12 Jack Jiang 阅读(283) | 评论 (0)编辑 收藏

     摘要: 本文引用了作者“大古同学”的“二维码扫码登录是什么原理”一文的主要内容,为了更好的理解和阅读,即时通讯网收录时有修订和改动,感谢原作者的分享。1、引言自从微信的PC端使用扫码登陆认证逻辑后,这种方式似乎在越来越多的IM中看到(虽然我个人认为这种登录方式很酷,但并不方便,尤其手机不大身边的时候)。 ▲ 上图微信PC端的扫码登录界面...  阅读全文

posted @ 2021-05-10 13:42 Jack Jiang 阅读(185) | 评论 (0)编辑 收藏

     摘要: 本文原题“百度直播消息服务架构实践”,由百度APP消息中台团队原创分享于“百度Geek说”公众号,为了让文章内容更通俗易懂,本次已做排版优化和内容重新划分,原文链接在文末。1、引言一套完整的直播系统核心功能有两个:1)实时音视频的推拉流;2)直播间消息流的收发(包括聊天消息、弹幕、指令等)。本文主要分享的是百度直播的消息系统的架构设计实践和演进过程。...  阅读全文

posted @ 2021-04-27 15:17 Jack Jiang 阅读(195) | 评论 (0)编辑 收藏

     摘要: 文中引用了参考资料中的部分内容,本文参考资料详见文末“参考资料”一节,感谢资料分享者。1、引言对于IM开发者而言,网络保活这件事再熟悉不过了,比如这是我最近一篇有关网络保活话题文章《一文读懂即时通讯应用中的网络心跳包机制:作用、原理、实现思路等》,以及我分享的大量代码实战编码中也都必须要考虑这个问题的实现,比如最近的这篇《跟着源码学IM(五):正确理解IM长连接、心跳及重连...  阅读全文

posted @ 2021-04-19 15:10 Jack Jiang 阅读(284) | 评论 (0)编辑 收藏

仅列出标题
共47页: First 上一页 20 21 22 23 24 25 26 27 28 下一页 Last 
Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang