共计 6354 个字符，预计需要花费 16 分钟才能阅读完成。
作者：京东批发 周凯
一. 前言与背景
国内的互联网直播技术从 2005 年前后衰亡，彼时最具代表性的直播产品是由 PPLive 创始人姚欣在华中科技大学就读期间发动的校园直播我的项目 PPLive。过后的直播技术用的还是基于 windows 零碎自带的 mediaplayer 内置的 COM 组件开发的播放器，采纳的是 RTSP 协定。受过后的互联网传输带宽及老本限度，PPLive 并没有采纳当初比拟风行的单播技术，而是采纳 P2P 技术散发直播流。国内的直播技术也进入了一段以 P2P 技术为主的期间，其中比拟有代表性的就是 PPLive 和 PPStream。用 P2P 技术散发直播流，具备经营成本低的显著劣势，每一个参加播放的终端都是一个潜在的数据热点，网络品质随着观看直播流的客户端的减少而减少。但 P2P 技术也有本身的有余，不足观众的冷门资源因参加数据共享的客户端稀少而难以保障播放品质，另外 P2P 难以保障 UDP 打洞穿透率、须要下载专用的播放器等都是限度用户数量增长的因素。
P2P 直播散发技术注定是一个过渡性的技术。2005 年当前，因为晚期的 HTML 规范尚不欠缺，各大浏览器存在实现上的差别，被寄予厚望的 HTML5 标准也还尚未定稿，基于 HTML 的视频播放技术也不成熟。彼时，Adobe 公司从 Macromedia 公司收买的网页多媒体插件 flashplayer 在这种状况下怀才不遇。在开发层面，flashplayer 因其优异的多媒体表现力以及欠缺的开发语言和调试工具，升高了网页播放器的开发门槛。在音视频品质方面，Flashplayer 内置的 On2 公司的 VP6 视频编解码器无论是在编码品质还是在解码效率上在过后都十分优良，随着 2003 年才定稿的 H.264/AVC 视频编解码器及更高质量的 AAC 音频解码器也很快被内置到 flashplayer 内核，进一步提高了 flashplayer 的音视频能力。在播放器推广层面，基于 flashplayer 开发的播放器文件，能像散发网页一样通过网站服务器下发和更新，这极大地升高了视频网站的推广难度。上述起因，促使 flashplayer 成为过后最好的网页视频播放器内核。在 flashplayer 的技术加持下，视频点播网站如雨后春笋般涌现，尤其在 2006 年 google 收买 youtube 后，网页视频点播网站迎来了暴发，六间房、优酷、土豆等视频网站先后融入巨资，从泛滥点播网站中怀才不遇。彼时，flashplayer 作为绝大部分视频点播网站对立应用的网页播放器，装机率疾速进步，逐渐成为事实上的网页多媒体播放器规范。2009 年，随着 Adobe 将 flashplayer 内置的革命性的流媒体传输协定 RTMP(Real-Time Messaging Protocol) 标准凋谢，本就曾经方兴未艾的 RTMP 直播技术，进入了倒退的快车道。各种基于 RTMP 协定的开源实现陆续呈现，涵盖服务器和播放器。由此，互联网直播进入了由 flashplayer 和 RTMP 协定主导的时代。
RTMP 是 flashplayer 原生反对的流媒体传输协定，反对点播和直播模式，通过十多年的大规模利用，曾经成为以后国内利用最为宽泛的直播协定，各大 CDN 厂商都曾经反对。国内技术圈还倒退出了 HTTP-FLV 协定，行将 RTMP 中的直播音视频流封装成 FLV 文件流，通过 HTTP 协定传输，这进一步升高了直播技术的接入老本和实现难度。
RTMP 和 HTTP-FLV 都是基于 TCP 的直播协定，TCP 固有的基于拥塞管制的传输策略在须要稳固、大量传输数据的直播场景下显得过于激进，偶发的丢包或网络抖动都会造成数据收发速率的急剧下降，从而造成画面及声音的卡顿，影响直播的品质及体验。而基于带宽和延时预测的 QUIC 传输协定的呈现，为直播行业提供了一个晋升直播品质和用户体验的新的选项。
二. QUIC 介绍
QUIC（读作“quick”）是一个通用的传输层网络协议，最后由 Google 的 Jim Roskind 设计。该协定于 2012 年实现并部署，2013 年随着试验范畴的扩充而公开公布，并向 IETF 形容。尽管长期处于互联网草案（英语：Internet Draft）阶段，但从 Chrome 浏览器至 Google 服务器的连贯中超过一半的连贯都应用了 QUIC。Microsoft Edge、Firefox 都已反对此协定；Safari 实现了 QUIC，但默认状况下没有启用。QUIC 于 RFC9000 中被正式标准化。
尽管 QUIC 的名称最后是“疾速 UDP 互联网连贯”（Quick UDP Internet Connection）的首字母缩写，但 IETF 指定的规范中 QUIC 并不是任何内容的缩写。QUIC 进步了目前应用 TCP 的面向连贯的网络应用的性能。它通过应用用户数据报协定（UDP）在两个端点之间建设若干个多路连贯来实现这一指标，其目标是为了在网络层淘汰 TCP，以满足许多利用的需要，因而该协定偶然也会取得“TCP/2”的昵称。
QUIC 与 HTTP/ 2 的多路复用连贯协同工作，容许多个数据流独立达到所有端点，因而不受波及其余数据流的丢包影响。相同，HTTP/ 2 建设在传输控制协议（TCP）上，如果任何一个 TCP 数据包提早或失落，所有多路数据流都会蒙受队头阻塞提早。
QUIC 的主要指标包含升高连贯和传输时延，以及每个方向的带宽预计以防止拥塞。它还将拥塞控制算法移到了两个端点的使用者空间，而不是内核空间，据称这将使这些算法失去更快的改良。此外，该协定还能够扩大前向纠错（FEC），以进一步提高预期谬误时的性能，这被视为协定演进的下一步。
三. 京东直播技术简介
京东直播体系从零开始构建，如下图所示，涵盖四大业务模块：推流端、中台源站、直播云 CDN 及播放端。
图 1. 京东直播产品体系
从上图能够看出，直播流的端到端传输，两头要通过多个链路。直播数据因数据量大、占用带宽高、传输间隔长而合乎典型的 Long-Fat（长肥）网络定义。在利用 QUIC 技术之前，京东的直播产品都是应用基于 TCP 的协定（RTMP/HTTP-FLV/HLS 等）进行直播流数据传输，TCP 因其激进的拥挤控制策略，在应答 Long-Fat 网络应用场景时差强人意，QUIC 技术的呈现，为优化直播传输品质提供了新的抉择。
京东从 2021 年上半年开始钻研 QUIC，基于 QUIC ietf v1 版本开发了自研的 QUIC 实现 QUIC-Pro，并最先在京东的直播场景落地。QUIC 在京东直播技术体系的落地过程并非欲速不达，而是循序渐进的。思考到直播数据流从 CDN 边缘服务器散发到用户端是最简单的“最初一公里”问题，因而，咱们抉择 QUIC 最后的落地场景是直播的散发和播放。
QUIC 落地之前，为了量化直播品质，不便比照优化收益，咱们制订了对立的全链路品质监控及数据上报规范，收集推流端、直播源站、直播云 CDN 及播放端等所有环节的跟传输、播放相干的监控数据，并对立上报到数据收集平台进行聚合、分类及统计，在泛滥质量指标中，选定画面首开时长、卡顿率及播放失败率作为播放品质的重要量化参考指标。
本文将别离从推流端、中台源站、直播云 CDN 及播放端四个局部串烧式地介绍与直播相干的一些技术实际，并重点介绍 QUIC 技术的利用状况及收益。
四. 推流端技术
京东直播反对的推流端包含京东视频 APP，PC 桌面端推流工具以及 web 网页端企业直播工具。京东视频 APP 及 PC 桌面端推流工具除反对真人直播及美颜性能外，还反对数字人直播，数字人直播数据流程如下图所示。
图 2. 京东数字人直播 SDK 架构
上图中，VideoSource 和 AudioRecord 别离管制图像和声音数据的输入，当真人直播时，VideoSource 关上 CameraCapturer，采集摄像头图像数据，并送到 Filter 滤镜链条进行美颜等操作，而后进行视频编码并打包发送，音频则通过 AudioRecord 关上 MicrophoneRecord，采集麦克风声音进行录制、编码并打包发送。
当采纳数字人直播时，流程通过图中黄色模块，TextureFactory 模仿摄像头运行机制，按帧率设置定期生成空白纹理，纹理通过 VideoSource 进入滤镜链条，滤镜链条中有一个 3DEngineFilter 滤镜，将京东自研的数字人 3D 引擎生成的数字人图像渲染到纹理，而后在屏幕上展现该纹理，同时将纹理上的图像进行编码、打包、发送。数字人的音频，则通过 AudioPlayer 管制音频播放到设施的同时，将音频采样数据输入到 AudioRecord，而后通过编码、打包，并发送进来。
五. 直播源站与 CDN 散发网络
京东直播包含实时音视频源站、实时转码、录制、审核等业务，推流端的实时音视频流都是先推到中台源站，而后再通过解决通过京东直播云 CDN 散发到播放端。中台源站还负责直播连麦相干业务的解决，包含混音、合屏等操作。
图 3. 京东中台直播源站低提早直播服务架构
直播云 CDN 通过京东云对外提供赋能，直播云 CDN 承载了京东主站、京喜等含直播性能的产品的日常直播流散发服务。通过近一年的密切合作，京东直播中台团队和京东直播云 CDN 团队已将共建的 QUIC 直播流散发服务全量部署到所有服务节点。直播云服务流程如下图所示。
图 4. 京东直播云 CDN 散发流程图
上图是京东直播云 CDN 对直播流的散发流程图，最左侧是直播源站或直播利用直推直播流到边缘推流集群，通过录制、转码截图、直达集群等两头模块及服务解决，最初转推给第三方 CDN 或经由边缘播放集群分发给播放端。
六. QUIC 服务端设计
以后网络上开源的服务端 QUIC 协定栈实现计划有多种，例如 Chromium QUIC、Lsquic、Nginx 官网 quic、cloudfare quic 等。其中 Chromium QUIC 倒退的最早，也绝对最成熟。因而 JDQUIC 服务端依靠 Chromium QUIC，应用了其 QUIC 协定栈相干源码，服务器框架及其他所有代码则为自研。
6.1．JDQUIC 服务器模式
为尽量减少对现有直播 CDN 散发体系的革新，并放弃 QUIC 的可扩展性及高效迭代更新，JDQUIC 服务器采纳反向代理模式进行 QUIC 直播流的申请、转换与散发。
图 5.JDQuicServer 工作流程
如上图显示，手机端播放器发送 QUIC 直播流拉流申请到 JDQuic-Server 服务器，JDQuic-Server 服务器将申请格局转换为一般的 http 或 tcp 数据，发送给后端 Web 或者 TCP 服务器，而后接管后端 HTTP-FLV 服务器返回的直播流数据并通过 HTTP/QUIC 协定下发给播放器。整个服务过程无需对后端服务体系作任何批改。
因为 JDQUIC 服务器个别和后端服务器部署在同一机房、甚至同一机器上，两者之间的数据传输提早根本能够忽略不计。
6.2. JDQUIC 服务端架构
JDQUIC 服务端采纳多过程单线程架构。音讯驱动采纳了 Libevent epoll 模式，QUIC 协定栈则应用了 Chromium QUIC 协定栈相干代码。如下所示：
图 6.JDQuic-Servrer 外部架构
JDQUIC 服务端采纳单线程多过程架构，单机多过程采纳内核 ebpf 进行负载平衡。
单线程外部采纳 Libevent epoll 进行音讯监听和散发，TCP UDP Unix domain、http 等多种协定依靠 Libevnet 进行收发，同时超时和异步音讯也通过 Libevent 架构进行回调。
Libevent 收上来的 UDP 数据包，在 Chromium QUIC 协定栈进行解析，还原出原始 Http 或者裸数据。这些数据通过线程内无锁调度模块，传给后端 Nghttp2 或 tcp udp client 模块，发送给后端服务器。
6.3. JDQUIC 连贯迁徙
网络的切换在当今挪动网络大规模遍及的背景下，是常常产生的事件。思考如下场景，当用户正在户外用挪动 4G/5G 网络看着直播的过程中，走到了一个具备 WIFI 网络的中央，连上了可用的 wifi 网络，此时，网络切换便产生了。如果要保障直播连贯在网络切换后依然放弃畅通，须要实现一套连贯迁徙机制。JDQUIC-server 的实现及工作原理，如图 7 所示：
图 7.JDQuic-Server 连贯迁徙原理
【工作流程】
- 手机端从 4G 网络切到 wifi 网络。
- 手机端网络连到不同的运营商机房（从挪动机房切到联通机房）。
- Ospf 和 nftable 负载调配到一个机器 quic server 实例。
- Quic server 通过 quic 数据包中的 connection id 中第一个字节，判断数据包该发回哪个机房。
- Quic server 把数据包转发给原来的机房。
- 原来的机房再负载到正确的 quic 实例。
【阐明】
• Ospf 负载: 三层负载平衡服务，硬件负载，效率很高。
• Nftable 单机负载: 操作系统内核级别的负载服务。
• QUIC 服务: quic 服务器，能够将 quic 协定转换为 http 去后端 FMS/SRS 拉流。
• 后端 FMS/SRS：直播流媒体 /CDN 服务器。
• 红色箭头：手机端首次播放直播的拉流路线。
• 蓝色箭头：手机端网络切换 WIFI 后进行连贯迁徙的拉流路线。
6.4. JDQUIC DCID 设计
连贯迁徙时，联通机房的 quic server 想要找到回源的机器，须要从 quic 数据包的 DestionationConntion id 字段获取机房信息，如下图所示。
图 8.JDQuic-Server CID 扩大设计方案
CID 字段取一个字节来映射机房信息，例如 0x01 示意长春挪动，0x02 示意长春联通等。
6.5. JDQUIC ebpf 设计
6.5.1. eBPF 简介
Linux 内核始终是实现监控 / 可观测性、网络和平安性能的现实中央。不过很多状况下这并非易事，因为这些工作须要批改内核源码或加载内核模块，最终实现模式是在已有的层层形象之上叠加新的形象。eBPF 是一项革命性技术，它能在内核中运行沙箱程序（sandbox programs），而无需批改内核源码或者加载内核模块。
将 Linux 内核变成可编程之后，就能基于现有的（而非减少新的）形象层来打造更加智能、性能更加丰盛的基础设施软件，而不会减少零碎的复杂度，也不会就义执行效率和安全性。
图 9.eBPF 原理及工作流程
6.5.2. eBPF 在 JDQuic-Server 中的利用
linux 内核中，通过 ebpf 保护两个映射表，并编写一段 ebpf JIT（即时编译）程序。客户端 QUIC 数据包进来后，ebpf JIT 程序依据 ip 端口、CID 进行 hash，别离拜访两个 map 表，来判断须要转发给哪个后端 QUIC 实例。其中，ip 和端口为 UDP 协定数据包的字段，包含源 IP、目标 IP、源端口、目标端口（合称四元组），如图所示。
图 10.JDQuic-Server 外部 ebpf 负载平衡原理
七. QUIC 技术收益
QUIC 协定基于带宽瓶颈预测及环路延时预测的传输控制算法，相比 TCP 的基于网络拥塞的控制算法，在抗网络抖动、进步网络传输速率方面有显著劣势。依据 QuicPro 在线上 Android 利用内的直播场景中的应用状况统计数据显示，直播卡顿率较 TCP 由 1.43% 降为 1.14%，降幅为 20%，首开工夫较 TCP 的 949 毫秒降为 659 毫秒，降幅为 30.5%，如下图所示：
图 11.TCP 与 QUIC 别离在直播卡顿率及首开工夫上的比照
八. 结语
京东直播通过 4 年多的倒退，技术上无论是服务架构还是播放协定都通过了多轮迭代，截至本文成文，仍在进行迄今为止最大规模的革新降级，波及全链路的协定降级与架构优化。协定上，将原有的基于 TCP 的信令、推流、散发、播放等环节降级为 QUIC 协定，在服务架构上，进行推流及媒体服务边缘化革新，在散发上，中台与京东云直播 CDN 兄弟部门共建低提早散发网络，咱们独特的指标是晋升传输品质、升高卡顿率的同时，将直播端到端的提早升高到 2 秒甚至是 1 秒以内。
