功能简介

QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于UDP的低时延的互联网传输层协议。其核心是在现有的网络传输技术基础上，在应用层和网络层中间，对现有技术的一次全新整合和利用，以此，实现了提高网络传输效率和降低传输时延的目的。
QUIC的核心技术包括：HTTP/2, TLS1.3, TCP FAST OPEN, UDP。
QUIC协议最初只是在海外Chrome浏览器和YouTube视频网站上使用，但是，随着IETF QUIC项目组的建立，以及2018年IETF宣布计划将QUIC协议作为HTTP/3.0进行推广，QUIC协议慢慢开始被业界广泛讨论，到2018年底，国内已经有多家厂商开始尝试开发QUIC协议的应用。
基于敏锐的市场嗅觉，及时洞悉到QUIC协议的市场潜力，尤其是在直播场景中，QUIC协议可以有效解决跨网、跨区域等弱网环境下推拉流质量不稳定的问题，率先开始了QUIC协议的研发。
直播QUIC功能基于Google QUIC （以下简称gQUIC）39、43、44、46版本开发，采用gQUIC代理组件的方案，实现在不改变原有直播推拉流业务模式的情况下，支持直播gQUIC协议推拉流。

使用说明

标准gQUIC协议是将HTTP/2、TLS 1.3、UDP集合于一身的产物。与 HTTP/2 + TLS + TCP 相比，gQUIC 承担了 HTTP/2 中的整个 stream管理部分、TLS 安全连接部分和 TCP 的重传、顺序、流控等机制。

• 直播gQUIC推流方案
  直播gQUIC推流采用RTMP over QUIC代理方案，方案中，QUIC Agent作为TCP代理，与客户端QUIC SDK建联，将UDP转换为TCP，透传直播数据给到媒体中心。
  此方案需客户端使用UDP 1935端口发起推流请求。
• 直播gQUIC拉流方案
  直播gQUIC拉流方案有两种，TCP代理模式和QUIC代理模式：
  【TCP代理模式】
  与直播gQUIC推流方案类似，QUIC Agent作为TCP代理，与播放器QUIC SDK建联，将TCP转换为UDP，透传边缘服务器的直播视频数据给到播放器QUIC SDK。
  此模式仅支持RTMP协议。
  此方案需客户端使用UDP 443端口发起拉流请求。
  【QUIC代理模式】
  QUIC Agent作为QUIC代理，与播放器或浏览器的QUIC组件建联，将边缘服务器的HTTP/1.1 + TCP直播视频数据转换为QUIC HTTP/2.0 + UDP协议，供客户端浏览器或播放器播放。
  此模式支持标准gQUIC协议的HDL和HLS模式。
  此方案需要客户端使用UDP 443端口发起拉流请求。
  
• 直播gQUIC效果展示
  【测试环境】
  使用同一服务器（可进行丢包控制），同时推两路相同直播流（码率1M），一路使用QUIC协议，一路使用TCP协议，推到同一直播边缘节点，使用第三方听云在全国范围内用不同运营商进行拉流测试。
  【码率】
  在非丢包环境下，QUIC和TCP码率相当，而在丢包20%的情况下，QUIC基本保持与不丢包一致的码率，而TCP则降低很多。
  【流畅度】
  流畅度：测试样本数在每一个小时周期内，只要存在一次重新填充播放器buffer的情况，便记为卡顿。
  在非丢包环境下，QUIC对比TCP因为多了针对应用层组包的加密操作，所以流畅度有所降低，但在丢包情况下，QUIC明显优于TCP。
  【首包】
  首包：测试机发起播放请求后收到第一个视频包的时间间隔。
  在20%丢包的情况下，QUIC保持与非丢包环境一致的首包时间，而TCP则增加很多。
  综上所述，使用QUIC协议，在弱网环境下，可以明显改善直播质量。

应用场景

对弱网环境下的推拉流有质量及稳定性需求的客户，如海外直播、跨区域直播、移动直播等。

注意事项

1.QUIC协议为双边加速协议，需要客户端开发QUIC协议或嵌入QUIC SDK方可使用。
2.QUIC协议在网络条件较好的情况下，无法区分出与TCP在传输质量上的差别，只有在弱网环境才可以显现出优势。
3.QUIC协议未定义端口标准，所以客户与我司对接时，需确保客户端端口与我司一致。
4.QUIC代理方案业界有较多种实现方式，不同方案不一定可以相互兼容，对接前，需确认客户端所采用的推拉流方案是否与我司兼容。
5.gQUIC草案还在不断更新，对接前，需确认客户端gQUIC是否为39、43或44版本。