点击图片报名交际泛娱乐出海赋能会【广州站】
在音视频通话，尤其是多人群组通话场景，过大的恳求包领会导致客户端频繁报错、衔接超时等问题。 重视【融云全球互联网通信云】了解更多
为解决这一问题，融云引入并优化相关算法，使呼叫和全局双向恳求传输体积下降了 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 成果
数据紧缩传输的功率首要通过紧缩率宽和紧缩时刻来归纳判别，三种计划的原始数据紧缩后数据巨细如下：
| 原始数据长度 | 32630(SDP:23725) | 8364(SDP:5559) |
|---|---|---|
| MiniSDP | 12911(8905+4006 MiniSDP 长度) | 3509(2805+704 MiniSDP 长度) |
| Brotli | 4100 | 1670 |
| Gzip | 5319 | 1910 |
实际包体长度 19678 的 Gzip 和 Brotli 紧缩比率与解紧缩时刻对比如下：
在数据紧缩率上 Brotli > Gzip > MiniSDP，在解紧缩功率上 MiniSDP > Gzip > Brotli。
Gzip 紧缩在紧缩率上与 Brotli 相差不多，在各种浏览器中兼容性更强，且解紧缩功率优于 Brotli。
归纳考虑兼容性、开发量等因素，融云选择 Gzip计划对呼叫和全局双向恳求进行优化，使传输体积下降 85%，大大削减了传输功率问题和衔接超时问题。
