QUIC协议设计要点分析

简介

QUIC（Quick UDP Internet Connections）是Google设计的一套可靠UDP传输协议，旨在为HTTP提供一个安全、可靠、高效和低延时的通信基础。QUIC协议已被IETF采纳为标准，并且HTTP/3已选择使用QUIC来代替TCP作为其传输层协议。本文将会逐一分析QUIC协议设计的要点。

HTTP/1和HTTP/2

HTTP是互联网的基石，它的简单、灵活使得各种各样的互联网应用成为可能。但HTTP的一些先天不足也为应用的开发增加了难度，为此，业界各大公司和标准化组织一直在对HTTP做各种改进和扩展，包括缓存、Range、长连接、Pipelining，还有基于SSL/TLS的HTTPS。后来Google设计的SPDY协议，在HTTP的基础上实现了多路复用和Header压缩，以进一步改善基于HTTP的传输性能和应用的交互体验。SPDY最终被IETF接受并做为HTTP/2的基础。

虽然多路复用提高了数据并发传输的性能，但由于SPDY是基于TCP的，而TCP使用的是统一的流控，还是存在Head-of-line blocking的问题。而且TLS层需要协商密钥，导致连接建立的过程比较复杂且低效，所以就有了QUIC协议的出现。

QUIC的设计要点

安全

随着安全和隐私越来越受重视，HTTPS也越来越普及，因此QUIC直接集成了TLS，以保障数据传输的私密，这样所有使用QUIC的上层协议和应用都不用再担心安全问题。

低延时

在HTTPS协议中，由于TCP和TLS都各需要自3次握手，导致连接建立过程较为复杂和耗时，降低了HTTPS的效率。QUIC选择UDP来作为其底层协议，就可以将连接建立和密钥协商的过程合二为一，简化操作流程，提高连接效率。

可靠传输

为了实现可靠传输，需要对传输信道的差错进行处理。处理方式一般有两种，一种是ARQ（Automatic Repeat-reQuest），由接收方对接收到的数据包进行确认，发送回执，以指示错误和请求重传出错的报文；另一种是FEC，将在本文后面讲到。

QUIC的ARQ是在TCP的基础上做了一些改进，一方面ACK报文会携带数据包的接收时间和ACK的时间，以方便计算RTT，另一方面QUIC的ACK是基于包的序号，并支持更多的ACK块，在乱序发送方面比TCP更灵活。

多路复用

多路复用是SPDY协议最重要的改进。HTTP/1.1虽然支持了Pipelining，但多个请求的回应依然需要顺序返回，如果其中一个请求的处理出现延误，后面所有的请求都会受影响。而多路复用则解决了这个问题，不同请求的回应可以乱序返回，避免单路的问题影响其他支路的传输。

QUIC协议则更进一步，在UDP的基础上实现了对多个独立可靠传输通道的支持，这些独立的传输通道有各自的ACK和流控，一个通道的问题不会影响其他通道的传输，使得网络通信的可靠性和传输能力得以提升。

改进的拥塞算法

QUIC本质上是把TCP的拥塞算法在应用层又实现了一遍，不过相比TCP算法是实现在操作系统内核模块中，QUIC在用户层的实现可以更灵活，更易于调整和改进，而且可以根据不同的应用场景选择不同的算法和参数，以充分的利用带宽。

连接迁移

QUIC协议基于虚拟的连接ID来唯一确定一条传输通道，即使底层的网络发生改变，只要连接ID保持不变，就可以认为是同一个连接。这样用户在WIFI、有线和移动网络之间切换时，可以保持上层的虚拟通道不变，避免重新连接带来的各种损失。

FEC（已移除）

前向纠错（Forward Error Correction），是指通过发送冗余的编码数据，使得接收方当传输过程中出现错误时，接收方能从收到的数据中重建和还原得到正确的原始数据。

FEC算法有很多种，包括内存中使用的汉明码，磁盘存储系统中常用的Reed-Solomon码，还有移动通信中用到的卷积码、Turbo码、LDPC码等。

早期QUIC中使用的FEC算法是基于XOR的简单实现，不过IETF的QUIC协议标准中已经没有FEC的踪影，猜测是FEC在QUIC协议的应用场景中难以被高效的使用。

参考

1. QUIC Protocol

2. HTTP/3 Protocol