QUIC协议的分析，性能测试以及在 *** 会员实践

图2 what's quic?

How QUIC works?

建立连接

一、基于TCP+TLS的HTTP2建连

出于HTTP的明文和无法验证服务器的真实性，在TCP的基础上引入了TLS协议，目前广泛使用的HTTPS是基于TCP+TLS协议，HTTP2也被主流浏览器默认支持TLS。

但对于建立连接的耗时而言，TCP本身就需要握手时延，而TLS协议为了使得客户端和服务器端在不安全的网络通信中协商出后续安全通信所需的加密私钥，更是要经过额外2次RTT( Time往返时间)

图3 TCP+TLS建连过程

除了TCP建立连接过程，TLS握手过程要经过如下步骤：

1、客户端提供加密套件（算法）列表，版本等信息

2、服务器端提供自己的证书，选择的加密套件，非对称加密公钥（自己保留私钥）等

3、客户端提供自己的证书，用服务器公钥和加密套件加密的自己的私钥

4、服务端用保留的私钥解密客户端传来的加密私钥，得到的私钥即为后续加密传输使用的对称密钥，最后完成握手

此时，双方协商出了对称密钥。基于TCP+TLS的HTTP2建连过程结束，大约需要耗时200-300ms。

二、QUIC建连

为了保证安全，QUIC也是加密传输数据的，所以在QUIC的建连过程中也需要双方协商出一个加密私钥。但与TLS不同，QUIC采用的加密算法仅需要一个RTT就能实现密钥交换，并且该算法也被用于目前正在草案阶段的TLS1.3协议。该就是-密钥交换算法。

图4 -算法

可以看到，客户端和服务端各自保留了自己的私钥a和b，通过交换各自的公钥B和A，以及基底G和很大的质数P，双方就能计算出相等的私钥S，这个S就是加密传输的对称密钥。

另外，根据离散对数的不可逆，即使拿到G,P,和质数B，也很难推导出私钥b（同理私钥a），也就保证了计算密钥的安全。

该过程对应到QUIC建连的过程中如下图。

图5 1RTT建连

1、客户端发起 hello

2、服务器返回，包括密钥交换算法的公钥信息，算法信息，证书信息等被放到 中传给客户端

3、客户端发起 hello，包括客户端公钥信息

此时，双方各自计算出了对称密钥。QUIC的1RTT建连过程结束，平均只耗时100ms以内。

后续发起连接的过程中，一旦客户端缓存或持久化了 ，就可以复用并结合本地生成的私钥进行加密数据传输了，不需要再次握手，从而实现0RTT建立连接。

协商升级

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

1、客户端发出tcp请求

2、服务端如果支持quic可以通过响应头alt-svc告知客户端

3、客户端同时发起tcp连接和quic连接竞赛

4、一旦quic建立连接获胜则采用quic协议发送请求

5、如遇网络或服务器不支持quic/udp，客户端标记quic为

6、传输中的请求通过tcp重发

7、5min后尝试重试quic，下一次尝试增大到10min

8、一旦再次成功采用quic并把标记取消

其中，支持quic的alt-svc头部信息如下图示，ma为有效时间（单位秒），v为支持的quic版本信息。

图6 alt-svc头信息

研究过程中发现，除了alt-svc ，http2.0下服务端还可以通过支持alt-svc frame来让客户端在之一次请求的时候就走新协议，比通过让浏览器第二次才能请求新协议更高效，这个留给后续研究。

连接迁移

TCP使用四元组（源IP，源端口，目的IP，目的端口）来标识一条连接，当四元组中的IP或端口任一个发生变化了连接就需要重新建立，从而不具备连接迁移的能力。

而QUIC使用了 id对连接进行唯一标识。即使网络从4G变成了wifi，只要两次连接中的 id不变，并且客户端或者服务器能通过校验，就不需要重新建立连接，连接迁移就能成功。

改进的多路复用

在SPDY协议出现以前，每个HTTP请求都需要建立一条TCP连接，那么如果希望请求并行，就需要同时开启多条TCP连接（都是有建连代价的）。而大多数浏览器对于同一个域名可以建立的更大TCP连接数是有限制的，所以，如果超出限制，更多的请求资源是无法并行的。

SPDY协议以来提出的多路复用，是让所有请求基于一条TCP连接，解决了上述的问题但同时引入了新的问题——队头阻塞，如果某个资源的某个包丢失了，因为TCP是保证时序的，就会在接收端形成队头阻塞，TCP此时无法区分各个资源的包是否关联，因此会停止处理所有资源直到丢包恢复。

图7 基于TCP的多路复用

QUIC也有多路复用，但是QUIC是基于UDP的，UDP不需要保证包的时序，只会在接收包的时候对包进行重组，因而不存在等待丢包恢复的队头阻塞问题，这样某个资源的包丢失只会影响自身不会影响到其他资源的继续传输，所以是改进的多路复用。

图8 基于QUIC的多路复用

双级别流量控制

QUIC是多路复用的，多条可以建立在一条上，所以QUIC的流量控制不仅基于单个，还基于。

级别的流控能够控制单的数据发送情况。另外，接收窗口的收缩取决于更大接收字节的偏移而不是所有已接受字节的总和，它不像tcp流控，不会受到丢失数据的影响。

图9 流控

如果满足(flow - bytes) < (max / 2)

会触发 frame的发送来增大发送窗口大小。

图10 触发前

图11 触发后

级别流控算法和一致，各项数值是所有的总和。

级别的流控存在的必要是，即使做好了流控，但如果过多也会导致过度消耗带宽和系统资源；而且即使某一条过慢，其他依然能触发

级别的，从而不会被影响。

图12 流控

拥塞控制

我们知道TCP有多种拥塞控制算法，当遇到网络拥塞会通过减包等方式来避免网络环境恶化。但是，UDP本身是没有拥塞控制的，一旦不加约束的使用会导致侵占其他“守规矩”的网络协议的带宽。

所以，为了避免上述情况，基于UDP的QUIC协议借鉴了TCP的一些优秀的拥塞控制算法，如默认使用Cubic，同时，为了避免AIMD机制带来的带宽利用率低，采用了 来探测网络带宽。

思路是，QUIC会通过追踪包的到达时间来预测当前带宽的使用情况，以决定是否提高，保持或者减少发送包的速率来避免网络拥塞。

图13

丢包恢复

类似拥塞控制，除了基于TCP的一些丢包恢复机制，如：TLP，FACK。QUIC的丢包恢复也在一些方面做了改进。

比如：通过引入严格递增的 使得计算RTT更加精确。更精确的RTT也意味更精确的RTO和超时重传机制。

还比如我们知道TCP中有个SACK选项，该选项打开时用于记录传输过程中一些没有被确认的数据的范围，便于后续定向重传多组丢失数据，而不是全部重传，所以更多的范围便于更多的选择重传，也意味着更少的重传包频率。但TCP最多支持3个SACK范围，而QUIC能支持255个。

除了上述基于TCP的改进的丢包恢复特性以外，早期的QUIC版本还有一个丢包恢复机制，就是FEC（ Error ），这个特性虽然目前处于正在改造阶段（可能会浪费带宽并且作用不是很明显），但是依然是一个有意思的解决方案。FEC的思路是通过在一组包（一般是10个）中，通过增加一个FEC包，并用FEC和每个包进行XOR，如果一旦有丢包，那么将FEC包和其余包XOR，得到的FEC包就是那个丢包，所以一组包最多只能恢复一个丢包。