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

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

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

来看下握手全程：

1. 客户端发送：①：ClientHello，包含Cipher Suite（密码套件），②：Key Share（DH密钥交换参数列表）

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

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

3. 客户端接收到 Key Share后，使用证书公钥对签名进行验证，获取服务端的公钥，并生成共享密钥

4. 双方使用生成的共享密钥进行加密传输，完成TLS握手

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

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

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

因为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草案被提出后，这么受欢迎的原因。

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

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

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处理。

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

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

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

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 按照顺序组织起来，交给应用程序处理。

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相比于其他协议，队头阻塞问题解决的更加彻底：

1. QUIC的滑动窗口的移动之和接收到的最大字节偏移有关，而不和顺序有关。 对于TCP来说，窗口滑动的前提是此前所有的包都顺序的接收到了，否则就等待，

2. QUIC同一个Connection中的不同Stream是互相独立的，即StreamA被阻塞，并不影响StreamB、C的读取。而Tcp由于其不知道将不同Stream交给上层哪一个请求，因此同一个Connection内，StreamA被阻塞后，StreamB、C都要等待。

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

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失败率较高的三个省份为：贵州、广西和新疆；失败率较高的运营商为：教育网和长城宽带。