QUIC协议原理与XQUIC测试

weixin_42052826 2022-01-18 17:19:41

介绍

QUIC旨在提供几乎等同于TCP连接的可靠性，但延迟大大减少。它主要通过两个理解HTTP流量的行为来实现这一点。

第一个变化是在连接创建期间大大减少开销。由于大多数HTTP连接都需要TLS，因此QUIC使协商密钥和支持的协议成为初始握手过程的一部分。当客户端打开连接时，服务器响应的数据包包括将来的数据包加密所需的数据。这消除了TCP上的先连接并通过附加数据包协商安全协议的需要。其他协议可以以相同的方式进行服务，并将多个步骤组合到一个请求中。然后，这些数据既可用于初始设置中的后续请求，也可用于未来的请求。

QUIC使用UDP协议作为其基础，不包括丢失恢复。相反，每个QUIC流是单独控制的，并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误，协议栈仍然可以独立地继续为其他流提供服务。这在提高易出错链路的性能方面非常有用，因为在大多数情况下TCP协议通知数据包丢失或损坏之前可能会收到大量的正常数据，但是在纠正错误之前其他的正常请求都会等待甚至重发。 QUIC在修复单个流时可以自由处理其他数据，也就是说即使一个请求发生了错误也不会影响到其他的请求。

QUIC包括许多其他更普通的更改，这些更改也可以优化整体延迟和吞吐量。例如，每个数据包是单独加密的，因此加密数据时不需要等待部分数据包。在TCP下通常不可能这样做，其中加密记录在字节流中，并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商，但QUIC旨在通过单个握手过程完成这些。[8]

QUIC的另一个目标是提高网络切换期间的性能，例如当移动设备的用户从WiFi热点切换到移动网络时发生的情况。当这发生在TCP上时，一个冗长的过程开始了：每个现有连接一个接一个地超时，然后根据需要重新创建。期间存在较高延迟，因为新连接需要等待旧连接超时后才会创建。为解决此问题，QUIC包含一个连接标识符，该标识符唯一地标识客户端与服务器之间的连接，而无论源IP地址是什么。这样只需发送一个包含此ID的数据包即可重新创建连接，因为即使用户的IP地址发生变化，原始连接ID仍然有效。

QUIC在应用程序空间中实现，而不是在操作系统内核中实现。当数据在应用程序之间移动时，这通常会由于上下文切换而调用额外的开销。但是在QUIC下协议栈旨在由单个应用程序使用，每个应用程序使用QUIC在UDP上托管自己的连接。最终差异可能非常小，因为整个HTTP/2堆栈的大部分已经存在于应用程序（或更常见的库）中。将剩余部分放在这些库中，基本上是纠错，对HTTP/2堆栈的大小或整体复杂性几乎没有影响。

QUIC允许更容易地进行未来更改，因为它不需要更改内核就可以进行更新。 QUIC的长期目标之一是添加前向纠错和改进的拥塞控制。

关于从TCP迁移到UDP的一个问题是TCP被广泛采用，并且互联网基础设施中的许多中间设备被调整为UDP速率限制甚至阻止UDP。 Google进行了一些探索性实验来描述这一点，发现只有少数连接存在此问题。所以Chromium的网络堆栈同时打开QUIC和传统TCP连接，并在QUIC连接失败时以零延迟回退到TCP连接。参考[Wiki QUIC介绍]

原理

数据格式

由 header 和 data 两部分组成。header 是明文的，包含 4 个字段：Flags、Connection ID、QUIC Version、Packet Number；data 是加密的，可以包含 1 个或多个 frame，每个 frame 又分为 type 和 payload，其中 payload 就是应用数据；数据帧有很多类型：Stream、ACK、Padding、Window_Update、Blocked 等，这里重点介绍下用于传输应用数据的 Stream 帧。

TLS层设计

QUIC Transport层，对TLS模块有如下依赖：加密握手协商、数据加解密、密钥更新、session resumption、0-RTT、传输参数、ALPN协商。TLS层，则需要依赖底层SSL库，来支撑上述功能。因此，TLS模块存在数据的多样性，以及依赖的多样性，数据流程和代码结构会比较复杂。TLS层需要对这些数据流进行归类整理，从而来简化上下游的依赖关系，降低代码的复杂度。

XQUIC适配了babassl、boringssl两种底层的ssl库，向上提供统一的接口，从而消除了它们之间接口、流程的差异，并抽象为统一的内部数据流程，仅针对不同ssl库提供轻薄的适配层，减少重复适配的代码逻辑，达到降低代码复杂度、提升可维护性的效果。同时XQUIC也提供了编译选项，方便开发者根据自身应用的情况，选择适合自己的依赖库。

0-RTT握手

（1）客户端：生成随机数 c，选择公开的大数 G 和 P，计算 A=c*G%P，将 A 和 G 发送给服务器，也就是 Client Hello 消息

（2）客户端：客户端直接使用缓存的 ServerConfig 计算通信密钥 KEY = cB = cb*G%P，加密发送应用数据

（3）服务器：根据 Client Hello 消息计算通信密钥 KEY = bA = bc*G%P

流量控制

和 TCP 一样，QUIC 也是利用滑动窗口机制实现流量控制。和 TCP 不同的是，QUIC 的滑动窗口分为 Connection 和 Stream 两种级别。Connection 流量控制：规定了所有数据流的总窗口大小；Stream 流量控制：规定了每个流的窗口大小。

连接迁移

当客户端切换网络时，和服务器的连接并不会断开，仍然可以正常通信，对于 TCP 协议而言，这是不可能做到的。因为 TCP 的连接基于 4 元组：源 IP、源端口、目的 IP、目的端口，只要其中 1 个发生变化，就需要重新建立连接。但 QUIC 的连接是基于 64 位的 Connection ID，网络切换并不会影响 Connection ID 的变化，连接在逻辑上仍然是通的。

传输层能力和应用协议协商

XQUIC提供两套接口，分别是使用标准HTTP3的7层接口和直接使用传输层能力的4层接口，同时XQUIC支持ALPN协商机制，可以通过向ALPN接口注册新的应用层协议回调，并通过握手期间的协商实现多套应用层协议的兼容。

XQUIC部署和测试

测试环境

Ubuntu 20.04
CMake
libevent
CUnit

安装CMake，libevent，CUnit工具

安装libevent

wget https://github.com/libevent/libevent/releases/download/release-2.1.10-stable/libevent-2.1.10-stable.tar.gz

./configure
make
make verify   # (optional)
sudo make install

安装CMake
```
sudo apt install CMake
```

安装CUnit

sudo apt install libcunit1 libcunit1-doc libcunit1-dev

获取XQUIC源码

git clone git@github.com:alibaba/xquic.git
cd xquic

安装编译BabaSSL

git clone git@github.com:BabaSSL/BabaSSL.git ./third_party/babassl
cd ./third_party/babassl/
./config --prefix=/usr/local/babassl
make -j
SSL_TYPE_STR="babassl"
SSL_PATH_STR="${PWD}"
SSL_INC_PATH_STR="${PWD}/include"
SSL_LIB_PATH_STR="${PWD}/libssl.a;${PWD}/libcrypto.a"
cd -

使用BabaSSL编译XQUIC

git submodule update --init --recursive
mkdir -p build; cd build
cmake -DGCOV=on -DCMAKE_BUILD_TYPE=Debug -DXQC_ENABLE_TESTING=1 -DXQC_SUPPORT_SENDMMSG_BUILD=1 -DXQC_ENABLE_EVENT_LOG=1 -DXQC_ENABLE_BBR2=1 -DXQC_DISABLE_RENO=0 -DSSL_TYPE=${SSL_TYPE_STR} -DSSL_PATH=${SSL_PATH_STR} -DSSL_INC_PATH=${SSL_INC_PATH_STR} -DSSL_LIB_PATH=${SSL_LIB_PATH_STR} ..
make -j