点击图片报名 社交泛娱乐出海赋能会【广州站】
在音视频通话,尤其是多人群组通话场景,过大的申请包领会导致客户端频繁报错、连贯超时等问题。关注【融云寰球互联网通信云】理解更多
为解决这一问题,融云引入并优化相干算法,使呼叫和全局双向申请传输体积降落了 85%,为用户提供更晦涩的应用体验。
业界支流压缩算法
HTTP(Hypertext Transfer Protocol,超文本传输协定)是一种申请 / 响应式的应用层协定。客户端与服务器建设连贯后,向服务器发送一个申请;服务器接到申请后,给予相应的响应信息。
HTTP 包体支流压缩算法有 MiniSDP、Brotli、Gzip 等。
MiniSDP
在进行音视频通话时,首先须要替换信令,SDP 调换就是其中的重要信息,让单方理解彼此的音视频参数及能力。所以,包体中绝大部分是 SDP 内容,即专门用于形容多媒体数据的会话形容协定。
其次要内容包含会话所有者无关的参数、会话的起始工夫和完结工夫、发送方所反对的媒体类型、媒体的连贯信息等,参与者人数越多,SDP 内容占比越高。
因而,将 SDP 革新为 MiniSDP 肯定水平上能够对 HTTP 包体进行压缩。
WebRTC 的 SDP 用文本字符串示意比拟简短,不利于疾速高效传输;MiniSDP 把 SDP 文本压缩成高效传输的二进制流,具备 高压缩率、强扩展性、应用便利性。
mini_sdp 由 mini_sdp header、n 个 session 级别扩大和 n 个 media 三局部组成,具体构造如下:
mini_sdp header 次要定义 mini_sdp 传输所须要的一些辅助信息及 ice 候选地址信息,各字段的长度及含意如下:
struct MiniSdpHdr {
uint16_t version; //2B, 示意该 mini_sdp 的版本号
uint8_t is_bundle:1; //1b, 0- 未绑定, 1- 绑定
uint8_t plan_type:1; //1b, 0-plan-b, 1-unifield-plan
uint8_t dtls_role:2; //2b, 0-actpass, 1-active, 2-passive
uint8_t encrypt_switch:1; //1b, 0- 不加密, 1-encrypt_key 加密
uint8_t ip_type:1; //1b, 0-ipv4, 1-ipv6
uint8_t ice_type:1; //1b, 0-full-lite, 1-ice-lite
uint8_t reversed1:1; //1b, 保留位
uint8_t reversed2:5; //5b, 保留位
uint8_t candidate_num:3; //3b, ice 候选地址的个数
uint16_t media_num; //2B, 原 sdp 中 m 行的个数
} __attribute__((packed));
留神:1、version 和 media_num 以网络字节序传输;2、必须反对 ice,并且 rtp 和 rtcp 共用端口,否则会在 media 中减少 ip,rtpPort,rtcpPort 的开销;3、media_num 用 uint16_t,避免大会议应用 unifield plan
struct MiniCandidateDesc {uint32_t ip[4]; //ipv4, ipv6 转换后的 ip
uint32_t priority; // 优先级
uint16_t port; // 端口
uint8_t type; //0-host, 1-srflx, 2-prflx, 3-relay
} __attribute__((packed));
留神:priority 和 port 以网络字节序传输
session extenses 次要形容会话信息:
{
uint16_t ufrag_len; // 长度传输时应用网络字节序
const char* ice_ufrag;
uint16_t pwd_len;
const char* ice_pwd;
uint16_t key_len;
const char* encrypt_key;
uint16_t session_id_len;
const char* session_id;
uint16_t session_version_len;
const char* session_version;
}
session extenses 构造示意图
struct MiniMediaHdr {
uint8_t media_type:2; //2b, 0-audio, 1-video, 2-data
uint8_t codec_num:6; //6b, 示意以下有多少个 codec 形容
uint8_t direction:2; //2b, 0-sendrecv, 1-recvonly, 2-sendonly, 3-inactive
uint8_t rtcp_mux:1; //1b, 0- 不使能 rtcp-mux, 1- 使能 rtcp-mux
uint8_t reversed:5; //5b, 保留
uint8_t rtp_extense_num;//1B, 示意以下有多少个 rtp extense 形容
uint16_t track_num; //2B, 示意以下有多少个 track 形容
} __attribute__((packed));
留神:track_num 以网络字节序传输
目前,客户端和服务器都不反对 MiniSDP,须要 SDP 与 MiniSDP 二者之间实现转换。
经测试发现,原始 SDP 在 MiniSDP encode 和 decode 后,局部属性会失落或扭转,还需对 MiniSDP 进行定制化开发反对。
数据主权
Brotli 是 Google 在 2015 年 9 月推出的一种压缩算法。它通过变种的 LZ77 算法、Huffman 编码及二阶文本建模等形式进行数据压缩,与其余压缩算法相比,Brotli 有着更高的压缩效率。
依据 Google 公布的钻研报告,Brotli 压缩算法具备多个特点,最典型的是以下三个:
- 针对常见的 Web 资源内容,Brotli 的性能相比 Gzip 进步了 17%-25%;
- 当 Brotli 压缩级别为 1 时,压缩率比 Gzip 压缩等级为 9(最高)时还要高;
- 在解决不同 HTML 文档时,Brotli 仍然可能提供十分高的压缩率。
Brotli 在压缩水平上有着相对的劣势,然而这些劣势是用其余代价换来的。Brotli 压缩操作所破费的工夫会随着压缩级别的减少而减少。
简而言之,就是 Brotli 须要更多的计算能力,而计算能力需要的减少代表着设施和软件设施的老本上涨。另外,Brotli 要求浏览器必须反对与 HTTPS 一起应用,这也是它相比在浏览器反对量上比 Gzip 少的起因。
毕竟,Gzip 是同时反对 HTTP 和 HTTPS 的。
Gzip
Gzip 是 GNUzip 的缩写,基于 DEFLATE 算法实现,是 LZ77 和霍夫曼编码的组合。
作为一种比拟罕用的数据压缩形式,它最早用于 UNIX 零碎的文件压缩。
HTTP 协定上的 Gzip 编码是一种用来改良 Web 应用程序性能的技术,Web 服务器和客户端(浏览器)必须独特反对 Gzip。
目前,支流的浏览器如 Chrome、Firefox、IE 等和常见的服务器如 Apache、Nginx、IIS 都反对该协定。
Gzip 罕用于网站内容压缩传输,以缩小网络耗费,压缩比率在 3 到 10 倍左右,能够大大节俭服务器的网络带宽。
在理论利用中,它并不是对所有文件进行压缩,通常只压缩动态文件。
服务中应用 Gzip 的计划示意如下:
各计划 PK 后果
数据压缩传输的效率次要通过压缩率和解压缩工夫来综合判断,三种计划的原始数据压缩后数据大小如下:
理论包体长度 19678 的 Gzip 和 Brotli 压缩比率与解压缩工夫比照如下:
在数据压缩率上 Brotli > Gzip > MiniSDP,在解压缩效率上 MiniSDP > Gzip > Brotli。
Gzip 压缩在压缩率上与 Brotli 相差不多,在各种浏览器中兼容性更强,且解压缩效率优于 Brotli。
综合思考兼容性、开发量等因素,融云抉择 Gzip 计划对呼叫和全局双向申请进行优化,使传输体积降落 85%,大大减少了传输效率问题和连贯超时问题。