作者：京东批发 周凯
一. 前言与背景
国内的互联网直播技术从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秒以内。