QUIC唯快不破，三个核心设计
原创
简介
QUIC（Quick UDP Internet Connections）是由 google 提出的使用 udp 进行多路并发传输的协议，旨在为HTTP提供一个安全、可靠、高效和低延时的通信基础。QUIC协议已被IETF采纳为标准，并且HTTP/3已选择使用QUIC来代替TCP作为其传输层协议。本文内容为笔者学习的主要笔记。
QUIC诞生背景
我们知道在互联网中的应用层里的网络传输协议很多，如支持万维网应用的HTTP协议，支持电子邮件的SMTP协议，支持文件传送的FTP协议，DNS，POP3，SNMP，Telnet等等。其中HTTP可以说是互联网的基石，它的简单、灵活促进了各种各样互联网应用的诞生。但HTTP也存在着一些先天不足，例如它的连接无法复用，连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的下影响明显，慢启动则对大量小文件请求影响较大。虽然各大公司和标准化组织一直在对HTTP做各种改进和扩展，包括缓存、Range、长连接、Pipelining，还有基于SSL/TLS的HTTPS。后来Google设计的SPDY协议，在HTTP的基础上实现了多路复用和Header压缩，以进一步改善基于HTTP的传输性能和应用的交互体验。SPDY最终成为HTTP/2的基础，HTTP/2 解决了很多之前旧版本的问题，但是它还是存在一个巨大的问题，主要是底层支撑的 TCP 协议造成的。虽然 HTTP/2 使用了多路复用，但是通常同一域名下只会建立一个 TCP 连接。如果这个连接中出现了丢包的情况，那就会导致 HTTP/2 的性能急剧下降。比不上HTTP/1。因为发生丢包的情况下，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1.1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。我们都很容易想到可以去修改 TCP 协议，但是 TCP 存在的时间太长，广泛应用于各个领域各种设备，并且这个协议是由操作系统实现的，基本无法再修改。基于这个原因，Google 就提出了一个全新的，基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上，HTTP/3 之前名为 HTTP-over-QUIC，从这个名字可以看出，HTTP/3 的最大改进在于加入了 QUIC协议。
QUIC的实现网络数据快速传输设计三要点
QUIC协议比较多，为此笔者主要讲述QUIC实现“快”的核心设计理念。
1.快速连接
在使用TCP传输协议时，在发送数据之前必须要经过三次握手，如果存在TLS握手，至少需要两个RTT（这里的RTT指的是一次握手的往返时间），虽然保证了安全性，但是网络延迟非常高。由于建立在 UDP 的基础上，可以将连接建立和密钥协商的过程合二为一，实现了 0RTT 的安全握手，简化操作流程，提高连接效率，所以在大部分情况下，只需要 0 个 RTT 就能实现数据发送。
2.quic的拥塞控制
网络出现拥塞一般指的是数据在传输的过程中过多的数据注入到网络，从而导致分组的丢失，此时发送方会继续重传，从而导致网络的拥塞程度更高。在重传的过程中TCP的seq保持不变，这样会导致一个问题就是客户端不知道收到的seq是重传的seq还是原始请求的seq，如下图所示，如果原始sql被判断成重传的seq，会导致RTT增大，如果重传的seq被判断成原始的seq，就会导致计算的RTT偏小。
quic采用自增式seq解决上述问题，重传之后的seq会比原有的seq大，当计算RTT时就不会计算错误，如下图所示：
3.多路复用
多路复用是SPDY协议最重要的改进。HTTP/1.1虽然支持了Pipelining，但多个请求的回应依然需要顺序返回，如果其中一个请求的处理出现延误，后面所有的请求都会受影响。而多路复用则解决了这个问题，不同请求的回应可以乱序返回，避免单路的问题影响其他支路的传输。
QUIC协议则更进一步，在UDP的基础上实现了对多个独立可靠传输通道的支持，这些独立的传输通道有各自的ACK和流控，一个通道的问题不会影响其他通道的传输，使得网络通信的可靠性和传输能力得以提升。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。