作者：赵咏
QUIC的发音类似于Quick，实际上也确实很快。它可以很好地解决应用在传输层和应用层面临的各种需求，包括处理更多的连接、安全性以及低延迟。
目前在互联网领域，QUIC可以说刮起了新一代互联网传输协议的风。对开发者而言，了解QUIC更是有助于时延敏感性应用以及音视频、购物支付等应用场景的体验提升。
![]()
1 QUIC拥有两大优势
*** 0RTT，建立低延迟传输**
传统的TLS协议，需要经过两级握手实现用户数据的传输。第一级包括TCP的三次握手，至少需要一个来回；第二级是TLS协议的握手，通过ClienHello、ServerHello几次握手的数据包协商后才能开始用户数据传输。
虽然TLS1.3在TLS握手阶段进行了优化，支持在首包ClientHello传输数据，但TCP的握手还是无法节省。QUIC协议则抛弃了TCP协议，改用UDP作为底层传输协议，进一步压缩了TCP三次握手所带来的时延，达到了真正的0RTT。这一优势对时延敏感型的应用很有吸引力，也给视频类应用提供了切换至QUIC协议的动力。
*** 加密传输**
大部分互联网公司都十分注重用户的安全隐私，始终持续推进数据的加密传输。这项工作需要两个协议支撑，分别是HTTP协议和DNS协议。
（1） HTTP协议从1.1版本升级到2.0再到3.0，本身并没有涉及加密的内容，仅在时延问题上改进。但与HTTP协议伴生的TLS协议专职进行加密，从TLS1.2升级到了TLS1.3，不仅增强了加密的强度，还将原先的明文握手部分进行了大幅加密。甚至，TLS协议计划未来将所有的握手部分均加密。
（2） DNS协议与HTTP协议也是伴生状态，但不可避免的会泄露HTTP协议中的域名信息。因此，DNS的加密一般会同时进行。
目前主流的解决方案是使用TLS进行加密，但QUIC协议拥有和TLS类似的加密能力，且性能更好。这打破了TLS协议对加密的垄断，成为其最大竞争者。
2 QUIC的使用情况
很多年前，谷歌和Meta（原Facebook）对QUIC协议分别进行了研究，甚至Facebook还实现了一个TCP版本的QUIC。后来，他们在研究上分列两个阵营，一个是谷歌的gQUIC，另一个是IETF-QUIC。不过最后，他们达成了一致，均归为IETF-QUIC阵营，也就是现今QUIC的雏形。
作为主推者，谷歌和Facebook旗下的App已大量使用QUIC进行通信。那么如今他们以及各大互联网厂商都在QUIC上有哪些进展呢？
-
谷歌：作为使用广泛的移动操作系统Android，其自带浏览器组件Webview均默认支持QUIC，Chrome及其衍生浏览均支持QUIC。还有一些和用户生活连接紧密的App也会尝试使用QUIC，比如Youtube、Gmail、Google map、Google Play等。这些在支持使用的场景下都会默认进行QUIC的传输。
-
Facebook：Facebook、Messenger、Instagram、Whatsapp等旗下较为知名的App和谷歌使用类似的QUIC策略。
-
Apple：苹果在QUIC上的策略没有那么激进，但已经将QUIC作为未来趋势进行准备，包括QUIC上线所配套的DoH服务器。另外，苹果已经在最新的iCloud+ Private Relay中使用了QUIC作为代理传输协议。
-
CloudFlare：作为一个CDN厂商，ClouFlare一直大力推动QUIC的使用，覆盖大量chrome+小网站模式下的流量，让这些流量默认使用QUIC。
-
Snapchat：跟随着Google的脚步，这款较为风靡的聊天软件，也大量使用了QUIC。
-
国内互联网厂商：快手、搜狐视频主力使用QUIC传输视频，目前是国内推进最快的。微信、淘宝、爱奇艺、抖音、百度已在部分流量或者部分时延场景下启用QUIC。使用QUIC逐渐成为国内互联网厂商的潮流。
3 QUIC协议格式
经过长时间的演变以及两个阵营的研究，QUIC协议具有很多分支和变种。这里我们省略一些前期变化的叙述，聚焦当前的情况展开。目前，QUIC协议主要有两大分支版本。
- gQUIC版本，由谷歌打造并广泛使用。QUIC的载荷内容能够看到的只有ClientHello包和Rejection包，其他的数据包均是加密的，没有秘钥看不到。因此我们先介绍一下暴露在外面的内容，如下图是gQUIC的ClientHello包结构，在wireshark里面显示的是IETF QUIC。这是因为两个分支正在融合，在这部分是基本一致的，包括包头、CRYPTO和PADDING三部分。包头是一些基本信息，重要的是版本号和Connection ID。
![]()
CRYPTO包含具体的握手参数，这是与gQUIC和IETF QUIC区别最大的地方。但它们的作用类似，都是提供域名、加密参数之类的握手所需要的信息。下图则是gQUIC中的格式，是谷歌自己定义的：
![]()
在IETF QUIC里的CRYPTO装的是一个TLS的ClientHello，基本上直接复制了TLS的格式。下图是IETF QUIC的CRYPTO格式，从外部格式看这是两个QUIC分支最大的区别点：
![]()
外部能看到的格式介绍到这里，已经说明了90%，其他部分在Wireshark里面有比较明确的解释。此外，最新版的QUIC（两个分支）均使用了Encrypted ClientHello机制，前面介绍的ClientHello在流量里面是“加密”状态，看起来是一些随机的字节，只有最开始的几个字节用来区分不同的QUIC版本。但这个“加密”的秘钥就藏在ClientHello包里面，可以现场计算出真正的秘钥并解密。因此，Wireshark能够看到明文的ClientHello内容。这种“加密”类似当年的P2P协议，都是为了增加DPI设备的处理难度，最终需要拼CPU算力。如果CPU算力不够则看不到明文。
4 QUIC的交互过程
Wireshark提供了QUIC流量的解密功能，有秘钥就能看到加密前的具体内容。这样我们也就能直观的看到QUIC的交互过程。事实上，QUIC承担了TCP的功能，主要是可靠性传输的保障能力。从下图可以看出，内部会传输大量的ACK报文，用来确认数据已经收到，基于此再产生重传等拥塞控制相关的能力。
![]()
除了可靠性传输的保障能力，QUIC内部存在stream机制。每个stream都可以被认为是一个独立的流，这样QUIC本身就是一个大的加密传输隧道。QUIC内部实际传输数据的协议一般是HTTP3，这让QUIC和HTTP3产生了强绑定，很多时候大家会把这二者当成是一个东西。Wireshark目前并没有解析HTTP3，只能看到一些二进制的数据。但HTTP3继承了HTTP2，数据带有压缩，短短的几个字节可能就是一个巨大请求压缩后的结果。
![]()
综上所述，QUIC协议是一个结合多种优秀特性的互联网传输新协议，自然也成为了互联网各大厂商的新宠儿。对此，华为也推出了HMS Core网络加速套件——hQUIC Kit，帮助开发者在应用中快速支持QUIC协议，再辅以智能拥塞算法，最终为用户提供更快的连接建立速度，更强的抗丢包能力以及更高的吞吐量。hQUIC适用游戏、视频通话、在线TV/VOD、VR实时广播等应用场景，其服务优势有：
更多hQUIC Kit 信息，请参见： https://developer.huawei.com/consumer/cn/hms/huawei-hQUIC/?ha_source=hms1
开发指南： https://developer.huawei.com/consumer/cn/doc/development/system-Guides/dev-process-0000001050197790?ha_source=hms1】
了解更多详情>>
访问华为开发者联盟官网
获取开发指导文档
华为移动服务开源仓库地址：GitHub、Gitee
关注我们，第一时间了解 HMS Core 最新技术资讯~
