揭开“QUIC”的神秘面纱
作者:赵咏
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实时广播等应用场景,其服务优势有:
-
简单易用:提供简单易用的编程接口,屏蔽网络细节。
-
兼容性:兼容gQUIC协议,支持Cronet接口。
-
移动网络体验提升:提升弱网环境对用户的体验。
更多hQUIC Kit 信息,请参见:
https://developer.huawei.com/consumer/cn/hms/huawei-hQUIC/?ha_source=hms1
了解更多详情>>
访问华为开发者联盟官网
获取开发指导文档
华为移动服务开源仓库地址:GitHub、Gitee
关注我们,第一时间了解 HMS Core 最新技术资讯~