概述

QUIC（Quick UDP Internet Connection）是一种基于UDP传输层协议由谷歌制定。QUIC更为轻量融合了HTTP/2，TLS的多路复用，安全性功效，TCP确认的可靠性，及UDP高效等特性。QUIC很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，安全性，和低延迟。

QUIC 与现有 TCP + TLS + HTTP/2 方案相比，有以下几点主要特征：

利用缓存，显著减少连接建立时间
改善拥塞控制，拥塞控制从内核空间到用户空间
没有 head of line 阻塞的多路复用
前向纠错，减少重传
连接平滑迁移，网络状态的变更不会影响连接断线。

市场分析

通常游戏、流媒体以及VoIP等应用均采用UDP，而网页、邮件、远程登录等大部分的应用均采用TCP。QUIC协议从诞生至今获得了不少厂家与企业的支持，也为这些企业带来了收益与回报。国外如Google搜索、YouTube视频、Akamai CDN等等都实现了对QUIC协议的支持，国内如腾讯云的负载网关、QQ空间、七牛直播云的直播推流等都在QUIC协议的帮助下实现了如0卡顿的直播推流等等技术提升。

屏幕快照 2019-08-23 下午4.24.50.png

QUIC高可用的优势

1.QUIC建连延迟低

QUIC仅需要 0～1RTT往返( 便可建立链接，相对于TCP(2～3RTT，当然下一代TLS1.3可能会到0-RTT 但是还未发布，我们先那TLS1.2做比较）。QUIC可以有效的降低传输层的延迟，改善用户体验。数据可以被立即发送而无需等待服务器的响应。

屏幕快照 2019-08-25 下午7.28.17.png

如图可见 TLS1.2 需要两次往返（ 1～2-RTT ）在加上TCP的握手1RTT 预计需要2～3RTT才能完成

2.QUIC多路复用

我们先对比一下HTTP1.1，HTTP/2，QUIC，如下图：

屏幕快照 2019-08-25 下午8.05.46.png

从上图我们可以看出HTTP1.1中多个数据传输要建立多个TCP连接，这样会增加服务端和客户端的并发负载。QUIC，HTTP/2采用了多路复用(简单来说就是将多个数据连接，执行在一个TCP连接中)就很好的解决了这个问题。

但是HTTP/2存在Head of Line Blocking队首阻塞问题 (stream2的队首包丢失会造成stream1，3的阻塞，直到stream2的数据流重传完成后才能恢复), QUIC会将每个数据重传放到每个stream包内执行，而且QUIC中每个数据包是UDP的数据包他不会存在队首阻塞的问题。

FEC向前纠错

QUIC实现了一种基于XOR的FEC形式通常用于提高链路层。传递数据包时还会带上其他数据包的奇偶校验信息，即将N个包的校验和（异或）建立一个单独的数据包发送

| P=D1 xor D2 xor D3 … xor Dn （D1,D2,D3 … Dn为数据块，P为校验，xor为异或运算） |

假如D3 数据包丢失，可以通过p和其他参数异或恢复出来。并且还可以用来校验记录的数据包的有效性。

3.QUIC灵活的拥塞控制

QUIC协议栈区别于TCP，他是存在于用户态可以非常灵活的控制而TCP是在内核代码中。QUIC比TCP的拥塞控制信号种类更丰富。每一个包，不管是原始的还是重新传输的，都携带一个新的数据包序列号。这使得一个QUIC发送者能够区分从ack中重新传输的ack，从而避免了TCP的再传输模糊问题。QUIC ack还显式地在接收数据包和它的确认被发送之间携带延迟，再加上单调递增的数据包数量，这就允许精确的往返时间(RTT)计算。

最后，QUIC的ACK帧支持最多256个NACK范围，所以QUIC比TCP(带SACK)更有弹性，也可以在重排序或者丢失时在线路中保留更多的字节，客户端和服务器都能更准确地了解对方接收到的数据包。

4.QUIC网络切换转移

移动网络比较复杂，经常会进行网络切换WiFi →4G, 4G→WiFi。如果是TCP的话一定会断开重新连接，TCP靠4元组判断链接(元IP source_ip，目标IP destination_ip，元端口 source_port，目标端口 destination_port TCP无法仅仅通过查看目的端口来确定数据报应发送给那个socket。它必须查看socket对的所有4个元素才能确定由哪个端点接受到达的数据包。)来表示。

QUIC是采用一个64位的ConnectionID（一个QUIC连接的身份标识）来判断链接与ip，port无关。无论你网络如何切换只要服务端搜索到的ConnectionID与客户端一致，服务器就会认为这是一个链接。

QUIC详细握手过程

未命名-2.jpg

QUIC握手及加密过程流程图

QUIC在握手过程中使用Diffie-Hellman算法协商初始密钥，初始密钥依赖于服务器存储的一组配置参数，该参数会周期性的更新。初始密钥协商成功后，服务器会提供一个临时随机数，双方根据这个数再生成会话密钥。

具体握手过程如下：

(1) 客户端判断本地是否已有服务器的全部配置参数，如果有则直接跳转到(5)，否则继续

(2) 客户端向服务器发送inchoate client hello(CHLO)消息，请求服务器传输配置参数

(3) 服务器收到CHLO，回复rejection(REJ)消息，其中包含服务器的部分配置参数

(4) 客户端收到REJ，提取并存储服务器配置参数，跳回到(1) 

(5) 客户端向服务器发送full client hello消息，开始正式握手，消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和自己选择的公开数，可以计算出初始密钥。

(6) 服务器收到full client hello，如果不同意连接就回复REJ，同(3)；如果同意连接，根据客户端的公开数计算出初始密钥，回复server hello(SHLO)消息，SHLO用初始密钥加密，并且其中包含服务器选择的一个临时公开数。

(7) 客户端收到服务器的回复，如果是REJ则情况同(4)；如果是SHLO，则尝试用初始密钥解密，提取出临时公开数

(8) 客户端和服务器根据临时公开数和初始密钥，各自基于SHA-256算法推导出会话密钥

(9) 双方更换为使用会话密钥通信，初始密钥此时已无用，QUIC握手过程完毕。之后会话密钥更新的流程与以上过程类似，只是数据包中的某些字段略有不同。

QUIC浅析