探究QUIC协议的深入研究与理解

最编程 2024-07-31 15:33:41

...

编译QUIC

前置要求

git
gcc & g++

拉取depot_tools

git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git

将其加入环境变量

export PATH="$PATH:YOUR_PATH/depot_tools"

拉取chromium

mkdir chromium
cd chromium
fetch --nohooks chromium --no-history chromium

安装依赖

cd src
./build/install-build-deps.sh
gclient runhooks

编译

gn gen out/Debug
ninja -C out/Debug quic_server quic_client

QUIC研究

介绍

QUIC(Quick UDP Internet Connections),即快速UDP网络连接，是被设计用在传输层的网络协议。
QUIC增加了面向连接的TCP网络应用程序的性能，它通过使用UDP在两个端点之间建立⼀系列多路复用的连接实现这个目的，它同时被用来代替（obsolesce）TCP在网络层的作用。
QUIC的另⼀个⽬标是减少连接和传输时候的延迟,以及评估每⼀个⽅向的带宽来避免阻塞。它还将拥塞控制算法移动到两个端点的⽤户空间，⽽不是内核空间，根据QUIC的实现，这将会提升算法的性能。

优势

QUIC的⽬标⼏乎等同于TCP连接，但是延迟却会更少。主要是由于以下的改变：

减少连接期间的开销
提高网络交换事件期间的性能。

另外QUIC相比较于TCP而言，在如下方面做的更好：

拥塞控制
前向纠错
多路复用

建立连接

TCP为了建立连接需要三次握手，而QUIC只需要一次往返握手即可。

具体方法如下：

QUIC客户端第⼀次连接到服务器时，客户端必须执⾏1次往返握⼿，以获取完成握⼿所需的信息。客户端发送早期（empty）客户端Hello问候（CHLO），服务器发送拒绝(rejection) （REJ），其中包含客户端前进所需的信息，包括源地址令牌和服务器的证书。客户端下次发送CHLO时，可以使⽤以前连接中的缓存凭据来⽴即将加密的请求发送到服务器。

这导致，QUIC只需要在首次建立连接时需要一次RTT，往后的连接可以不再握手直接发送数据。

前⾯图⽚是首次连接需要1RTT,后⾯是之后的连接不需要RTT

拥塞控制

QUIC的拥塞控制是基于拥塞窗口的。和TCP相比拥塞算法没有多少不同，其主要多了如下的几个特性：

可插拔
包编号单调递增
禁止Reneging
更多ACK帧
更精准的发送延迟

可插拔

指可以灵活的使⽤拥塞算法，⼀次选择⼀个或⼏个拥塞算法同时⼯作

在应⽤层实现拥塞算法，⽽以前实现对应的拥塞算法，需要部署到操作系统内核中。现在可以更快
的迭代升级
不同的平台具有不同的底层和⽹络环境，现在我们能够灵活的选择拥塞控制，⽐如选择A选择
Cubic，B则选择显示拥塞控制
应⽤程序不需要停机和升级，我们在服务端进⾏的修改，现在只需要简单的reload⼀下就能实现不同拥塞控制切换

包编号单调递增

QUIC使⽤Packet Number，每个Packet Number严格递增，所以如果Packet N丢失了，重传Packet N的Packet Number已不是N，⽽是⼀个⼤于N的值。这样可以确保不会出现TCP中的”重传歧义“问题。

禁止Reneging

QUIC不允许重新发送任何确认的数据包，也就禁止了接收方丢弃已经接受的内容。

更精准的发送延迟

QUIC端点会测量接收到数据包与发送相应确认之间的延迟，使对等⽅可以保持更准确的往返时间估计

多路复用

HTTP2的最⼤特性就是多路复⽤，⽽HTTP2最⼤的问题就是队头阻塞。例如，HTTP2在⼀个TCP连接上同时发送3个stream，其中第2个stream丢了⼀个Packet，TCP为了保证数据可靠性，需要发送端重传丢失的数据包，虽然这时候第3个数据包已经到达接收端，但被阻塞了。

QUIC可以避免这个问题，因为QUIC的丢包、流控都是基于stream的，所有stream是相互独
⽴的，⼀条stream上的丢包，不会影响其他stream的数据传输。

前向纠错

为了从丢失的数据包中恢复⽽⽆需等待重新传输，QUIC可以⽤FEC数据包来补充⼀组数据包。与RAID-4相似，FEC数据包包含FEC组中数据包的奇偶校验。如果该组中的⼀个数据包丢失，则可以从FEC数据包和该组中的其余数据包中恢复该数据包的内容。发送者可以决定是否发送FEC分组以优化特定场景（例如，请求的开始和结束).
在这⾥需要注意的是：早期QUIC中使⽤的FEC算法是基于XOR的简单实现，不过IETF的QUIC协议标准中已经没有FEC的踪影，猜测是FEC在QUIC协议的应⽤场景中难以被⾼效的使⽤。

头部和负载的加密

由于使用了TLS 1.3，因此QUIC可以确保数据的可靠性，每次发送的数据都被加密。

更快的网络交换

QUIC允许更快地进行网络切换，例如jiangwifi切换为数据网络。

为了做到这一点，QUIC的连接标识发生了变化。

任何⼀条 QUIC 连接不再以 IP 及端⼝四元组标识，⽽是以⼀个 64 位的随机数作为 ID 来标识，这样就算 IP 或者端⼝发⽣变化时，只要 ID 不变，这条连接依然维持着，上层业务逻辑感知不到变化，不会中断，也就不需要重连。

启动切换

端点可以通过发送包含来⾃该地址的⾮探测帧的数据包，将连接迁移到新的本地地址。

响应切换

从包含⾮探测帧的新对等⽅地址接收到数据包表明对等⽅已迁移到该地址。

数据检测和拥塞控制

当响应后，中间可能会有数据损失和拥塞控制问题：新路径上的可⽤容量可能与旧路径上的容量不同。在旧路径上发送的数据包不应有助于新路径的拥塞控制或RTT估计。端点确认对等⽅对其新地址的所有权后，应⽴即为新路径重置拥塞控制器和往返时间估计器。

流量控制

QUIC同样可以针对接收方的缓冲进行设置，以防止发送方发送过快对接收方造成压力。

QUIC有两种控制方法：

流控制：通过限制可以在任何流上发送的数据量来防⽌单个流占⽤整个连接的接收缓冲区。
连接控制：通过限制所有流上以STREAM帧发送的流数据的总字节数，来防⽌发送⽅超出连接的接收⽅缓冲区容量。

QUIC 实现流量控制的原理⽐较简单：
通过 window_update 帧告诉对端⾃⼰可以接收的字节数，这样发送⽅就不会发送超过这个数量的数据。
通过 BlockFrame 告诉对端由于流量控制被阻塞了，⽆法发送数据。

Packet格式

QUIC 有四种 packet 类型

Version Negotiation Packets
Frame Packets
FEC Packets
Public Reset Packets

所有的 QUIC packet 大小都应该低于路径的 MTU，路径 MTU 的发现由进程负责实现， QUIC 在IPv6 最大支持 1350 的packet，IPv4最大支持 1370

QUIC普通帧头部

所有的QUIC 帧都有一个 2-21 字节的头部，头部的格式如下

0        1        2        3        4        8
+--------+--------+--------+--------+--------+--- ---+
| Public | Connection ID (0, 8, 32, or 64) ... | ->
|Flags(8)| (variable length) |
+--------+--------+--------+--------+--------+--- ---+
9        10       11       12
+--------+--------+--------+--------+
| Quic Version (32) | ->
| (optional) |
+--------+--------+--------+--------+
13       14       15       16       17       18       19       20
+--------+--------+--------+--------+--------+--------+--------+--------+
| Sequence Number (8, 16, 32, or 48) |Private | FEC (8)|
| (variable length) |Flags(8)| (opt) |
+--------+--------+--------+--------+--------+--------+--------+--------+

从 Private Flags 开始的数据是加密过的

QUIC 代码分析

在开源实现的lsquic中自带了一个示例的echo_server和echo_client。这里将对改代码进行分析

static lsquic_conn_ctx_t *echo_server_on_new_conn (void *stream_if_ctx, lsquic_conn_t *conn)
{
    struct echo_server_ctx *server_ctx = stream_if_ctx;
    lsquic_conn_ctx_t *conn_h = calloc(1, sizeof(*conn_h));
    conn_h->conn = conn;
    conn_h->server_ctx = server_ctx;
    TAILQ_INSERT_TAIL(&server_ctx->conn_ctxs, conn_h, next_connh);
    LSQ_NOTICE("New connection!");
    print_conn_info(conn);
    return conn_h;
}

当连接建立的时候，会调用上述函数。该函数会构造一个新的conn_ctx,并调用TAILQ_INSERT_TAIL，将这个连接插入到队列结尾。

static void echo_server_on_conn_closed (lsquic_conn_t *conn)
{
    lsquic_conn_ctx_t *conn_h = lsquic_conn_get_ctx(conn);
    if (conn_h->server_ctx->n_conn)
    {
        --conn_h->server_ctx->n_conn;
        LSQ_NOTICE("Connection closed, remaining: %d", conn_h->server_ctx->n_conn);
        if (0 == conn_h->server_ctx->n_conn)
            prog_stop(conn_h->server_ctx->prog);
    }
    else
        LSQ_NOTICE("Connection closed");
    TAILQ_REMOVE(&conn_h->server_ctx->conn_ctxs, conn_h, next_connh);
    free(conn_h);
}

当链接断开的时候，上述函数会被调用，该函数会检测连接计数，并在合适的时候停止服务程序。最后调用TAILQ_REMOVE移除掉该链接。

static void echo_server_on_read (lsquic_stream_t *stream, lsquic_stream_ctx_t *st_h)
{
    struct lsquic_conn_ctx *conn_h;
    size_t nr;

    nr = lsquic_stream_read(stream, st_h->buf + st_h->buf_off++, 1);
    if (0 == nr)
    {
        LSQ_NOTICE("EOF: closing connection");
        lsquic_stream_shutdown(stream, 2);
        conn_h = find_conn_h(st_h->server_ctx, stream);
        lsquic_conn_close(conn_h->conn);
    }
    else if ('\n' == st_h->buf[ st_h->buf_off - 1 ])
    {
        /* Found end of line: echo it back */
        lsquic_stream_wantwrite(stream, 1);
        lsquic_stream_wantread(stream, 0);
    }
    else if (st_h->buf_off == sizeof(st_h->buf))
    {
        /* Out of buffer space: line too long */
        LSQ_NOTICE("run out of buffer space");
        lsquic_stream_shutdown(stream, 2);
    }
    else
    {
        /* Keep reading */;
    }
}

当有数据传输过来时，该函数会被调用，用于读取收到的数据。lsquic_stream_read函数会通过stream读取输入，返回读取到的字节数。

static void 
echo_server_on_write (lsquic_stream_t *stream, lsquic_stream_ctx_t *st_h)
{
    lsquic_stream_write(stream, st_h->buf, st_h->buf_off);
    st_h->buf_off = 0;
    lsquic_stream_flush(stream);
    lsquic_stream_wantwrite(stream, 0);
    lsquic_stream_wantread(stream, 1);
}

该函数用于服务器向客户端发送数据。其中lsquic_stream_write会将数据通过stream发送出去。

原文地址：https://www.cnblogs.com/DevinK/p/14327649.html

上一篇： QUIC协议下的HTTP/3实现探索

下一篇：深入剖析 quic 协议

探究QUIC协议的深入研究与理解

编译QUIC

QUIC研究

介绍

优势

建立连接

拥塞控制

可插拔

包编号单调递增

禁止Reneging

更多ACK帧

更精准的发送延迟

多路复用

前向纠错

头部和负载的加密

更快的网络交换

启动切换

响应切换

数据检测和拥塞控制

流量控制

Packet格式

QUIC普通帧头部

QUIC 代码分析

京东直播中的QUIC应用与实践：深入探究

理解RTCP：实时传输控制协议的简介与发送时间安排

理解增量模型与迭代模型：探究增量模型的奥秘

深入理解数据库锁协议与InnoDB的锁定机制：探索行级锁、表级锁、排他锁、共享锁、悲观锁与乐观锁等实用锁

深入理解SPI总线协议与GPIO模拟SPI的时序图解析

理解点对点协议（PPP）的运作原理与应用

深入理解QUIC协议的背后奥秘

QUIC协议与TCP/UDP协议的比较分析

剖析QUIC协议的工作原理与细节

深入理解QUIC协议的背后奥秘