QUIC网络协议简介

【前言】

QUIC 全称 Quick UDP Internet Connection, 是谷歌公司研发的一种基于 UDP 协议的低时延互联网传输协议。在2018年IETF会议中，HTTP-over-QUIC协议被重命名为HTTP/3，并成为 HTTP 协议的第三个正式版本。本文将介绍QUIC协议的优势、特性和原理。

添加描述

【现有TCP网络协议存在的问题】

一、TCP队头阻塞，停等问题

这是TCP的可靠性机制的特性。HTTP2是在一个TCP连接上并行发送多个资源，TCP队头阻塞将会导致所有资源的传输需要停等，对网络质量影响较大。

二、握手延迟无法避免

TCP的3次握手和4次挥手是其建立和断开连接的基本步骤，这无可避免的要消耗一次RTT。而现在主流的HTTPS协议，还需要2消耗两次RTT握手才能建立连接。

三、网络中间设备僵化

网络中间设备在传输TCP协议时设置了很多潜规则，例如部分防火墙只允许通过80和443端口；部分NAT网关在转换网络地址时会重写传输层头部，可能导致双方无法使用新的传输格式；部分中间代理有时候出于安全需要，删除一些它不认识的选项字段。因此升级基于TCP的网络协议时，就必须要考虑和兼容这些影响。

四、协议僵化

TCP是在操作系统内核和中间设备固件中实现的。要对TCP进行大更改，就必须要通信双方升级操作系统，中间设备更新固件。这基本难以大规模实现。

以上问题都来自于TCP传输层。基于TCP协议要再进一步提升网络协议，已举步维艰。这时，基于UDP协议实现的QUIC网络协议应运而生。

【QUIC协议特性】

简单来说，QUIC协议就是基于UDP重新实现了一遍HTTP2的特性。

用一个等式来描述就是 QUIC = UDP + TLS + HTTP2

QUIC与HTTP2的网络层次对比如下图所示：

QUIC与HTTP2网络层次对比

下面来分析其一些关键特性。

一、0RTT快速连接

前面我们说过，TCP最少需要花费1RTT的时间来建立连接。下图3列分别描述了TLS1.2、TLS1.3和QUIC建立连接的成本。每1列分为上下两个图，上图表示首次建立连接所需成本，下图表示再次建立连接所需成本。

添加描述

可以看到，TLS1.2下，首次建立连接，首先需要1次RTT建立连接（蓝色线），2次RTT交换密钥和加密策略（黑色线），然后开始通信。再次建立连接时，由于已缓存了密钥，因此少1次RTT。 TLS1.3和QUIC都采用了Diffie-Hellman密钥交换算法来交换密钥。该算法的优点是交换密钥只需要1次RTT。在QUIC下，只有首次建立连接交换密钥时消耗1RTT时间，再次连接时就是0RTT了。这已最大限度的减少握手延迟带来的影响。这个特性在连接延迟较大的移动网络上有较好的性能提升。

二、连接迁移

TCP下一个连接是以四元组标识的，即（SrcIp，SrcPort，DstIp，DstPort）。而QUIC连接是以客户端产生的一个64位随机数作为连接标识。当网络、端口发生改变或中断时，只要连接标识不改变，连接就不会中断。

三、改进拥塞控制

1. QUIC在应用层即可实现不同的拥塞控制算法，不需要改操作系统和内核。
2. 单个程序的不同连接也能支持配置不同的拥塞控制。这样我们就可以给不同的用户提供更好的拥塞控制。
3. 应用程序变更拥塞控制，甚至不需要停机和升级。
4. QUIC还有带宽预测，RTT监控，发送速率调整等高级算法支持。

四、双级别流控

TCP通过滑动窗口机制来保证可靠性以及进行流量控制。QUIC更新了其滑动窗口机制，并在Connection和Stream两个级别分别进行流控。

添加描述

用公式表示就是： connection可用窗口 = stream1可用窗口 + stream2可用窗口 + streamN可用窗口

五、没有队头阻塞的多路复用

添加描述

SDPY和HTTP2协议的多路复用，是让所有请求在一个TCP连接上传输。前面说过，TCP协议有队头阻塞问题，如果某个资源的某个包丢失了，由于TCP是保证时序的，就会在接收端形成队头阻塞。TCP协议无法区分各个资源的包是否关联，因此会停止处理所有资源，直到丢包恢复。

添加描述

QUIC是基于UDP的，UDP不需要保证包的时序，因而不存在等待丢包恢复，不存在队头阻塞问题。如果某个资源的某个包丢失了，只会影响单个资源，其他资源会继续传输。

六、实现与升级更灵活

TCP协议栈是写在操作系统内核以及中间设备固件上的，对其更新升级，耗费的时间是以年为周期。 基于UDP协议栈的QUIC协议在应用层实现。应用软件的更新较为轻量，因此协议新特性的升级迭代周期是以月或周来计算。

【QUIC实战】

一、访问QUIC网站

我们可以用Chrome浏览器来访问QUIC网站，或者使用基于Chrome内核的浏览器也可以。目前较新版本的chrome浏览器已默认开启QUIC支持，如果你不确定当前浏览器是否开启QUIC支持，可以在地址栏输入chrome://flags/查看：

添加描述

如何判断一个网站是否支持QUIC呢？一般可以通过其返回的header来判断：

添加描述

当出现如上图这行alt-svc: quic=xxx时，即表示该网站支持QUIC。该行具体的含义是服务器在443端口开启了QUIC支持，最大缓存时间是2592000秒（30天），支持的QUIC版本号是44、43、39。 在浏览器输入chrome://net-internals/#quic可以查看当前chrome浏览器支持的QUIC版本以及其他信息。如下图所示，我的浏览器支持版本号39的QUIC。

添加描述

当访问支持QUIC的网站时，可以打开开发者工具，在Protocol列可以查看其具体的协议，如下图所示：

添加描述

这里显示的http/2+quic/39表示采用的是QUIC的版本号是39。从这里也可以看出，QUIC是在HTTP2基础上提供的一个增强的协议。如果QUIC无法访问，浏览器就会无缝fallback回HTTP2，保证用户的访问。

二、QUIC访问流程

一般情况下，Chrome浏览器和服务器端协商使用QUIC协议要经过如下步骤：

1. 首次访问，客户端发出正常的tcp请求
2. 服务端如果支持quic，会通过header返回alt-svc信息告知客户端自己支持QUIC
3. 下次访问，客户端同时发起tcp连接和QUIC连接竞速
4. 一旦quic竞速连接获胜，则后续会采用quic协议发送请求
5. 如遇网络或服务器不支持quic/udp，客户端标记quic为broken
6. 传输中的QUIC请求立即用tcp重发
7. 5min后尝试重试quic，下一次尝试增大到10min
8. 一旦再次成功采用quic并把broken标记取消

在地址栏输入 chrome://net-internals/#alt-svc 可以查看QUIC连接的缓存情况，如下图所示：

添加描述

标记为broken的域名就是竞速失败，fallback为HTTP2连接。 如果握手失败，chrome会将QUIC标记为broken，并fallback到TCP继续发送。5分钟后chrome会再次尝试让TCP和QUIC进行竞争。由于QUIC连接被标记为broken，所以禁止0RTT握手，如果握手再次失败，则冷到10分钟，再下次则是20分钟，以此类推。

三、搭建一个QUIC网站

目前较为热门的服务端开源组件是Caddy。它是一个用Go语言编写的通用web服务器，性能非常好。项目Github地址：https://github.com/mholt/caddy 大家可以按照Github说明进行安装。启动Caddy时加上-quic标记即可启用QUIC支持。 caddy -quic 启动后，通过netstat命令查看端口使用情况，可以见到caddy同时用TCP和UDP监听端口：

添加描述

【QUIC性能表现】

下面图表来自：https://cloud.tencent.com/developer/article/1155289

添加描述

从上图的数据可以看出，QUIC的总体性能比HTTP2略有提升

添加描述

从上图的数据可以看出，在弱网络、高丢包率的情况下，QUIC才能凸显其独特优势。

【QUIC业界案例】

• Google超过50%的请求来自QUIC
• Youtube有20%的流量来自QUIC
• 微博移动端全面支持QUIC协议
• 腾讯安全云网关全面支持QUIC协议
• 腾讯X5内核已支持
• aQUIC（AliQUIC，阿里云开发的一套基于QUIC协议的解决方案）

【QUIC存在的问题】

一、QUIC协议标准制定存在争议

虽然目前Google制定的QUIC协议版本已实现并应用在自家的搜索产品和Chrome上，但IETF小组自身也创建了一个QUIC协议版本，并且与Google的原始提案有较大差异。为了区分两者，Google推出的QUIC被称为gQUIC，IETF制定的QUIC称为iQUIC（目前cloudflare已实现该套协议并提供了相应的SDK和工具）。而即使是Google自身，也在不断的对QUIC进行升级和改进，因此短期内QUIC不会称为一个成熟稳定的网络协议。

二、尚未形成趋势

据W3Techs统计，截止到2018年底，全球排名前1000万的网站中，有31.2%已支持了HTTP2，而QUIC只有1.2%。HTTP2的优秀表现，以及全球各国对网络基础设施的建设，让QUIC协议暂无法显示其魅力。

三、国内网络环境对UDP的限制

不管是国外还是国内，TCP流量都占主流地位。因此网络运营商、云厂商和防火墙设备，在网络拥堵时可能会不同程度的丢弃部分UDP流量。常用端口（如http协议的80、443）上的UDP包经常会被防火墙认为是恶意访问直接屏蔽掉。