QUIC浅析，android开发者模式

下图是HTTP Over TLS1.2首次连接的握手，其中TCP的第三次握手和TLS的第一次握手结合：

这个过程由于太长，在复杂的网络情况下的连接建立容易产生较大时延，所以优化的方向比较统一：在保证安全的情况下，尽可能减少握手交换数据，加快连接的速度

TLS1.3则实现了1RTT，甚至0RTT，而QUIC因为是基于Udp协议，所以也可做到0RTT。

这里讲一个TLS1.3和QUIC的事情，在2018年之前，因为TLS1.3还没有正式发布，所以QUIC使用的是自研的0RTT方式，叫做 QUIC crypto protocol。所以看2018年之前的文章，会发现两者达到0RTT的方式是不一样的。而在2018年TLS1.3正式发布，QUIC又和TLS同属IETF组织，所以自然而然的，QUIC统一使用TLS1.3作为安全协议。

The QUIC crypto protocol is the part of QUIC that provides transport security to a connection. The QUIC crypto protocol is destined to die. It will be replaced by TLS 1.3 in the future, but QUIC needed a crypto protocol before TLS 1.3 was even started.

感谢Google减少我们这些码农的学习成本~ 我们只需要弄清楚TLS1.3是如何实现0RTT的，就也能弄懂QUIC的了。

2.1.1 TLS1.3实现1RTT

首先看下TLS1.2协议握手图：

整个过程是2RTT，因为比较熟悉，就不再讲中间过程了。

接下来看下TLS1.3如何做到1RTT，看下面握手图：

来看下握手全程：

客户端发送：①：ClientHello，包含Cipher Suite（密码套件），②：Key Share（DH密钥交换参数列表）
服务端回复：①：ServerHello，包含所选Cipher Suite，②：服务器证书，③使用证书对应的私钥对握手消息签名，将结果发出，④：选用客户端提供的DH参数生成临时公钥，并将公钥通过Key Share发送出去

除此之外，结合选定的DH参数计算出用于加密Http的共享密钥

客户端接收到 Key Share后，使用证书公钥对签名进行验证，获取服务端的公钥，并生成共享密钥
双方使用生成的共享密钥进行加密传输，完成TLS握手

相比于TLS1.2，TLS1.3最大改动其实就是去掉了 RSA的密钥交换，也就是TLS握手中的唯一一次非对称加密（不算签名验证）。

所以握手的时候，就不会再去发送那些和非对称加密相关的数据了，比如 客户端服务端随机数 Server/Client KeyExchange、声明消息加密的信号 ChangeChiperSpec，还有 Pre-master Secret随机数。

TLS使用非对称加密的原因，是为了双方安全的算出 Master Secret，从而算出公共密钥。而TLS1.3版本移除掉了这个非对称加密，那就需要使用别的方式来弥补，所以使用到了 Key Share，它是一种前向安全的协议/算法，这里不多做解释，总之 DH四一中用于密钥交换的算法。

2.1.2 TLS1.3实现0RTT

因为Http是无状态的，所以就有了Cookie、Session的概念，Session ID 和 Session Ticket是会话的缓存，放在客户端和服务端的Cookie中，便于服务端来识别客户端。

在 TLS1.2中，如果客户端已经访问过了服务端，那么可以通过 Session Ticket在下次连接时快速建立握手，达到1RTT。这个行为叫做 恢复会话。

TLS1.3也是利用了这个机制实现0RTT的。客户端在第一次发送数据时，直接发送加密的应用数据，会话就正式进行。

虽然很快，但是不能保证前向安全，如果攻击者通过某种手段获取到 Session Ticket，那么该攻击者就可以解密以前的加密数据。

可以看到无论是第一次握手、还是恢复会话握手，TLS1.3都比TLS1.2少一个RTT，时间上是快了一倍，这也是为什么TLS1.3 daft草案被提出后，这么受欢迎的原因。

2.1.3 传输过程加密报文

上述说到QUIC是使用TLS1.3的，所以所有的UDP包都会经过加密，在防盗上是做足了保护。

而TCP协议的头部是没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改、注入和窃听。而QUIC的加密可以说是武装到牙齿。

2.2 无队头阻塞的多路复用

Http/2最强大的功能就是多路复用，QUIC的实现和Http/2类似，并且在其之上做了改进。我们先来看下Http2的不足之处。

2.2.1 Http2的多路复用和缺点

Http2多路复用的实现方案是：同域名请求共用一条TCP通道，这样可以减少多次Tcp握手所带来的消耗。

Http/1.1的Keep Alive实现多路复用，缺点是请求串行，如果服务器还在处理前面的请求，那么后面的请求就会阻塞，产生了 “队头阻塞” ，而Http2则通过数据流（Stream）以帧为基本协议单位，从根本上解决了这个问题。

但是即使如此，Http2的多路复用也有它的弱点：TCP的重传机制，这导致包的丢失会让整个通道停下来等待重传（停止等待协议的等待和滑动窗口的回退）。

例如下面是一个Http2的Tcp通道，客户端发送了4个数据流：stream1、2、3、4给服务端，第一个流已经到达，但是第二个流的第三个Tcp segment丢失，那么Tcp为了保证了传输的可靠性，会重新发送 stream2、3、4，这导致了即使原来的Stream3、4已经到达了服务端，但是服务端并不会先处理，而是阻塞等待Stream2处理。

2.2.2 QUIC实现多路复用

QUIC多路复用的实现方案是：同域名请求共用一条UDP通道，这样不仅省去了TCP连接，也没有Tcp的重传机制，在一条QUIC连接上，多个请求之间是没有依赖的，一个请求的丢失不会影响到其他的请求。如下图所示：

那就会有同学问了：那这样的话不跟udp一样传输不可靠了么？QUIC是如何保证传输可靠的？

这和QUIC的流量控制有关，来看看它的流量控制的方法把。

2.3 QUIC的可靠传输

2.3.1 单调递增的 Packet Number

QUIC使用了 Packet Number代替了 TCP的Sequence Number，并且每个 Packet Number都是严格递增。就算 Packet N丢失了，重传该Packet的Number一定是个比N大的值。这也解决了TCP重传歧义问题。如下图所示：

但是单纯依靠递
增的PacketNumber是无法保证数据的顺序性和可靠性的，QUIC引入了Stream Offset的概念。

如果Packet 里的装载的如果是 Stream（请求）的话，就需要依靠 Stream 的 Offset 来保证应用数据的顺序。

如下图所示：

发送端先后发送了 Pakcet N 和 Pakcet N+1，Stream 的 Offset 分别是 x 和 x+y。

假设 Packet N 丢失了，发起重传，重传的 Packet Number 是 N+2，但是它的 Stream 的 Offset 依然是 x，这样就算 Packet N + 2 是后到的，依然可以将 Stream x 和 Stream x+y 按照顺序组织起来，交给应用程序处理。

2.3.2 基于 stream 和 connecton 级别的流量控制

QUIC的流量控制类似Http2，提供了 Connection 和 Stream两个级别的流量控制。 Stream可以看成是一条请求，而Connection可以看成是一条连接通道。多路复用意味着一条Connection上会有多条Stream， QUIC的流量控制就是针对于一个Connection的Stream进行调控。

下图是QUIC的流量控制策略，是针对一个Stream的：

对于单个Stream而言，起始的接收窗口就是其最大接收窗口（max receive window），随着接收者接收到一部分数据后，接收窗口变小。在接收到的数据中，有一部分是已经读取的（consumed部分），一部分是接收但并没来得及读取的（received部分）。当上图中的黄色部分达到一定的阈值后，就需要更新接收窗口并告知发送者。这个阈值定义为已读取的数据大于最大接收窗口的一半，达到后，发送 WINDOW_UPDATE帧给发送者，接收窗口更新。比如告诉发送者，窗口向后移了Bytes consumed个字节。

而对于connection级别的流量窗口，其接收窗口大小就是各个stream接收窗口大小之和。

QUIC相比于其他协议，队头阻塞问题解决的更加彻底：

QUIC的滑动窗口的移动之和接收到的最大字节偏移有关，而不和顺序有关。对于TCP来说，窗口滑动的前提是此前所有的包都顺序的接收到了，否则就等待，
QUIC同一个Connection中的不同Stream是互相独立的，即StreamA被阻塞，并不影响StreamB、C的读取。而Tcp由于其不知道将不同Stream交给上层哪一个请求，因此同一个Connection内，StreamA被阻塞后，StreamB、C都要等待。

2.4 改进的拥塞控制算法

QUIC默认采用 Cubic 拥塞控制算法，和TCP一样，即慢开始、拥塞避免、快重传、快恢复。除此之外，也支持 CubicBytes、Reno、BBR、PCC等拥塞控制算法。而QUIC在此之上做了改进，主要有：

可插拔、灵活性

①：应用程序层面能实现不同的拥塞控制算法，不需要依赖操作系统和内核支持。

②：即使是个单应用程序的不同连接也能支持配置不同的拥塞控制算法

③：应用程序不需要停机和升级就能实现拥塞控制变更，只需要在服务端修改一下配置，就能实现拥塞算法的切换

尽可能避免超时重传

为了尽可能的实现快重传而不是超时重传，QUIC采用了Tail Loss Probes (TLPs)实现某些情况下的快重传机制触发。

TLP算法如下图，服务器的segments 6-10丢失，客户端在等待s6时，由于没有收到后续的序列，因此无法触发快速重传机制，时间达到probe阈值（PTO）后，TLP算法对segments10进行重传，客户端收到这个重传序列，就能触发快速重传机制。而QUIC会在PTO之前就发送两个TLPs来尽可能避免等到超时再重传。

2.5 连接迁移

传统NAT遇到的问题，比如小区运营商切换端口，导致设备端判断不了新的连接标识，需要重新握手。而QUIC使用UDP，不面向连接，所以不用握手。其上层QUIC链路由于使用了64位的Connection id作为唯一标识，就不像Tcp一样使用 ip:port四元组的发生变化导致影响链路标识。因此网络连接状态不会增加额外的重连耗时。

2.6 前向纠错

QUIC采用向前纠错(FEC)方案，即每个数据包除了本身的数据以外，会带有其他数据包的部分数据，在少量丢包的情况下，可以使用其他数据包的冗余数据完成数据组装而无需重传，从而提高数据的传输速度。

但这个方案在网络好的时候会影响性能，增加带宽，所以后面被Google废弃了。

3. Android端实现QUIC

===================================================================================

目前封装QUIC较好的库是Google的 Chromium项目，其移动端网络库是Cronet，支持Http、Http/2以及QUIC协议。我们需要安装Chromium环境，然后使用 Cronet进行源码编译，就能使用这个库。这里有官方安装文档文档：官方文档。

之后有空再实现，这几天环境一直没有装好，各种踩坑= =

4. 数据表现

=========================================================================

下面的数据均来自于腾讯、又拍云等大量使用QUIC的大厂的总结数据，不过数据比较老，来自18年，但具有一定的参考价值。

4.1 外网下表现

腾讯的黄钻业务、QQ会员接入了QUIC，在腾讯浏览服务中公布了这些使用的数据

4.1.1 性能表现

可以看到主要资源拉取耗时QUIC要比Http2快100ms，而首屏和Pagefinish耗时减少约20%。

4.1.2 监控数据

QUIC对于其他协议有速度上的优势，而对业务来说稳定是首要的。腾讯浏览服务在QUIC场景搭建了完善的异常上报机制，对X5内核的QUIC业务进行监控。下面一起来看看QUIC的外网监控表现情况。

成功率监控：

这一维度主要监控QUIC的连接成功率以及竞速成功率，上图为黄钻业务06月15-17号三天成功率及竞速成功率数据，目前QUIC的连接成功率保持在98%以上，QUIC的竞速成功率在70%以上。

QUIC失败监控：

对于QUIC失败异常，X5内核提供了详细的QUIC细分错误码以分析错误原因，从上报的大盘数据来看：

QUIC链接失败率不到2%，连接失败的情况，以QUIC连接超时为主。这种情况一般由于地区的QoS策略导致。
QUIC失败率较高的三个省份为：贵州、广西和新疆；失败率较高的运营商为：教育网和长城宽带。

cess=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Jpa2thdGhld29ybGQ=,size_16,color_FFFFFF,t_70#pic_center)

对于QUIC失败异常，X5内核提供了详细的QUIC细分错误码以分析错误原因，从上报的大盘数据来看：

QUIC链接失败率不到2%，连接失败的情况，以QUIC连接超时为主。这种情况一般由于地区的QoS策略导致。
QUIC失败率较高的三个省份为：贵州、广西和新疆；失败率较高的运营商为：教育网和长城宽带。