首先，wrk不支持自定义源IP地址，这在需要模拟来自不同客户端的请求时尤为不便，做并发测试时TCP连接数也上不去（此时你在curl命令中验证会看到类似Cannot assign request address的错误）。其次，wrk在每个连接上预分配的内存相对较大，这在单机上尝试建立大量连接时，会导致内存资源迅速耗尽，wrk进程会因为OOM被内核杀掉（如果wrk进程突然消失，你通常可以在/var/log/messages中看到形如Out of memory的日志）。这些限制对于需要评估高性能服务的开发者来说，无疑是一个不小的障碍。

在接下来的内容中，我将探讨如何通过修改wrk源码解决上述问题，以期帮助读者更好地利用wrk进行极限并发测试。

wrk与高并发测试挑战

在软件工程实践中，性能测试是确保应用性能达标的核心环节。比如容量测试会评估系统的最大处理能力；压力测试会评估系统在高负载下的行为；瓶颈测试会识别高负载情况下可能影响性能的系统限制因素。本文主要关注容量测试中的并发连接/会话测试，即如何达到预定的并发连接数，并不会考虑同一时间的吞吐量、每秒新建连接数等指标。

wrk的核心优势在于其轻量级和高性能，它通过C语言+epoll这种异步事件驱动架构，能够在短时间内生成大量的HTTP请求，测试目标服务器的响应时间和吞吐量。wrk的设计哲学是简单至上，它提供了一个简洁的命令行界面，用户可以通过-c参数指定并发线程数、-d指定请求持续时间、-t指定使用线程数等，快速启动测试，并在SSL测试中自动忽略不合法证书（相当于curl命令加入了-k参数）。

做C10M并发测试时，有一个必然的限制条件：测试目标通常集中在一个业务上，这就意味着业务监听的VIP（虚拟IP地址）和端口是固定的。在TCP连接的五元组（包括源IP、源端口、目的IP、目的端口、协议类型，如下图所示）中，协议类型、目的IP和端口由于业务需求已经确定，这限制了我们只能在源IP和源端口上寻求建立多连接的可能性。UDP会话也面临同样的问题。

即使我们通过ip或者nmcli命令建立了许多可用IP，wrk测试时也只能使用访问目的IP时主机的默认IP地址作为源IP地址。由于源IP不可配置且数量只能为1，我们只能依赖于源端口的多样性来实现并发连接。然而，端口号是一个short类型的2字节变量，其取值范围有限，即使我们放宽操作系统的端口范围限制（在Linux中可通过sysctl调整net.ipv4.ip_local_port_range），端口的数量最多也只能达到6万多个，这远远不能满足百万级并发连接的需求。

为了解决这一问题，我们下面探索如何通过修改官方wrk源代码的方式，扩展wrk的功能，实现大规模并发测试。

wrk源码分析：放开默认源地址的限制

wrk并不是为测试C10M级别并发而编写的，但它的基因其实是支持的。我们首先要找到wrk限制源地址的代码，也就是wrk向服务器发起TCP连接的源代码段–src/wrk.c文件中的connect_socket函数：

1
2
3
4
5
6
7
8
9
10
11
12

static int connect_socket(thread *thread, connection *c) {
    struct addrinfo *addr = thread->addr;
    struct aeEventLoop *loop = thread->loop;
    int fd, flags;

    fd = socket(addr->ai_family, addr->ai_socktype, addr->ai_protocol);

    if (connect(fd, addr->ai_addr, addr->ai_addrlen) == -1) {
        if (errno != EINPROGRESS) goto error;
    }
    ...
}

可见，该函数使用thread结构体中的addrinfo结构来确定目标服务器的地址信息，而源IP地址则是由系统自动选择的。如果需要自定义源地址，以便模拟来自特定IP地址的请求，可以在调用connect函数之前，使用bind函数将文件描述符（fd）绑定到指定的源地址。通过这种方式，可以控制从哪个本地IP地址和端口发起连接，从而满足特定的测试需求。

当然，做并发测试时并不需要指定源端口，所以将sin_port指定为0就可以继续使用操作系统分配的端口。

另外，究竟需要指定哪些IP作为源地址，还需要在wrk启动前做好准备，在main函数中获取这些地址后，再到connect_socket函数中使用，即可实现源地址的指定。这样，我们就绕过了高并发测试中TCP五元组的限制！

降低每连接消耗内存

要想使得wrk实现单机C10M级并发连接，还有1个问题需要克服：如何避免Out of memory问题？这个问题等价于，如何让每个测试连接使用尽量少的内存。

在深入探讨如何减少TCP连接所消耗的内存之前，我们必须首先理解TCP与HTTP协议在内存消耗方面的特点。wrk，作为一款专业的HTTP基准测试工具，其高效性能的实现基础在于对TCP流式消息的处理方式。wrk通过socket和系统API将TCP的流式消息缓存在内存中，仅通过指针引用来维护HTTP消息，从而显著降低了用户态进程中的内存占用。

然而，尽管wrk在用户态进程中对内存的管理做到了高效，但TCP和IP协议栈是由操作系统内核实现的，这意味着内核同样需要为每个TCP连接分配内存资源。内核的内存分配主要用于维护连接状态、缓冲区管理以及其它必要的网络操作，这些内存资源对于保持TCP连接的稳定性和性能至关重要。

为了减少每个连接的内存消耗，我们需要从两个层面进行考虑：

• 用户态进程中的内存优化：在wrk中，找到连接缓存、收发消息的代码，根据特定的测试场景减少其大小，或者采用更高效的数据结构来减少内存分配。

• 内核态的内存管理：对于操作系统内核中的TCP连接内存消耗，可以通过调整内核参数来优化内存使用，例如调整TCP缓冲区的大小、优化TCP的内存分配策略等。

关于内核态内存的调整，可以参见我的《高性能网络编程》系列文章，共有七篇，第7篇重点说了下内存调整：《高性能网络编程7–tcp连接的内存使用》

接下来我们重点来看wrk是如何为TCP连接分配内存的。

wrk源码分析：每个连接的内存分配

当我们通过-c指定并发连接数时，wrk.c文件中的parse_args函数会将参数保存到cfg->connections中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

static struct config {
    uint64_t threads;
    uint64_t connections;
    ...
} cfg;

static int parse_args(struct config *cfg, char **url, struct http_parser_url *parts, char **headers, int argc, char **argv) {
    ...
    while ((c = getopt_long(argc, argv, "a:t:c:d:s:H:T:R:LUBrv?", longopts, NULL)) != -1) {
        switch (c) {
            case 't':
                if (scan_metric(optarg, &cfg->threads)) return -1;
                break;
            case 'c':
                if (scan_metric(optarg, &cfg->connections)) return -1;
                break;
        }
    }
    ...
}

在main函数启动wrk测试前，会根据-t指定的线程数，为每个测试线程计算好待分配的连接数：

1
2
3
4

int main(int argc, char **argv) {
    ...
    uint64_t connections = cfg.connections / cfg.threads;
}

然后在每个线程启动的thread_main函数中，预分配好每个连接能够使用的内存：

1
2
3
4
5
6
7

void *thread_main(void *arg) {
    thread *thread = arg;
    aeEventLoop *loop = thread->loop;

    thread->cs = zcalloc(thread->connections * sizeof(connection));
    ...
}

接下来是重点部分：每个连接消耗的内存预分配为sizeof(connection)大小，这到底是多大呢？我们继续看wrk.h文件中的connection结构体：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#define RECVBUF  8192
typedef struct connection {
    thread *thread;
    http_parser parser;
    enum {
        FIELD, VALUE
    } state;
    int fd;
    SSL *ssl;
    double throughput;
    double catch_up_throughput;
    uint64_t complete;
    uint64_t complete_at_last_batch_start;
    uint64_t catch_up_start_time;
    uint64_t complete_at_catch_up_start;
    uint64_t thread_start;
    uint64_t start;
    char *request;
    size_t length;
    size_t written;
    uint64_t pending;
    buffer headers;
    buffer body;
    char buf[RECVBUF];
    uint64_t actual_latency_start;
    bool has_pending;
    bool caught_up;
    // Internal tracking numbers (used purely for debugging):
    uint64_t latest_should_send_time;
    uint64_t latest_expected_start;
    uint64_t latest_connect;
    uint64_t latest_write;
} connection;

可以看到，对于发起测试的HTTP请求内容，wrk全局只保存了一份，由所有连接共享使用（参见char *request成员），而每个连接接收到的消息则各自保存在8KB大小的内存中（wrk需要分析HTTP响应结果）！也就是说，除了buf数组，connection结构体几乎不消耗多少内存（http_parser只维持了一些必要的状态）。

通过减小buf数组的大小（修改RECVBUF宏的值），我们可以降低每个连接所需的内存量。这种方法简单易行，因为它直接减少了每个连接在用户态进程中分配的内存空间。这不仅有助于减少总体的内存消耗，而且可以使得更多的连接能够在有限的内存资源下被建立，从而提升了并发连接的数量。

当然，这种方法需要仔细考虑测试场景的需求。如果缓冲区设置得过小，可能无法满足某些情况下的数据接收需求，从而影响测试的准确性。因此，合理地调整缓冲区大小需要在内存消耗和测试需求之间找到一个平衡点。

当然，你还可以设计更灵活的内存管理策略来进一步优化内存使用。例如，可以实施动态内存分配策略、共享缓冲区、延迟分配等，这些技术可以在保持测试准确性的同时，进一步提高内存的使用效率。

小结

通过对官方wrk源码的适当修改，我们能够有效地降低每个TCP连接的内存消耗，从而避免内存溢出问题，同时通过指定多个源地址扩展了TCP连接的上限。这些改动配合Linux系统内核的TCP连接内存优化，使得单机wrk测试能够达到C10M，即百万并发级别的性能测试，这为评估高性能系统在极端负载下的并发度提供了一种有效的手段。

文章简介： 本文是我在《F5 NGINX Sprint 2022》大会分享的文字版整理。《NGINX网络协议栈优化》有两个关键词，第一个是网络协议，因此不涉及 NGINX 的业务模块。第二个关键词是性能优化，目标是让NGINX的性能达到目前硬件架构的极限。

很高兴大家回到这次深潜之旅，让我们继续挖掘 NGINX 的潜力。今天我的分享包括四个部分。首先从整体上来看一下 NGINX的协议栈如何进行优化。接着我们将按照 OSI七层网络模型，自上而下依次讨论HTTP协议栈、TLS/SSL协议栈以及TCP/IP协议栈。

首先要明确NGINX的优化方向。优化的目标在我看来可以用三个词表示——快、多、省。

• “快”是指降低请求的时延，请求时延是用户能够感知到的最明显因素。
• “多”指的是 NGINX正在处理的所有TCP连接数量以及收发的总字节数，比如总吞吐量能否打满网卡。
• “省”指处理一个 TCP 连接时所消耗的资源要尽量的少，这样我们的并发连接才能够达到千万、亿级别。

在做协议栈优化时，我们必须同时兼顾知识深度和广度。开发习惯从实现的角度看问题，知识面倾向深度。而运维更关注服务部署、运行，比如要了解IDC地理位置、网络规划、服务器硬件配置等情况，因此知识面是倾向广度的。NGINX运行在 Linux 或者 FreeBSD 等操作系统上，操作系统的内核协议栈和进程调度机制都会影响 NGINX 性能，所以优化内核参数时相对更需要深度。了解 NGINX 所在网络环境，针对丢包率、网卡特性、CPU特性、交换机和防火墙的规格、协议特性等要素优化 NGINX 时，相对又会偏重广度。

NGINX 协议栈优化方法论

首先我们看下面两张图，先同步下思路。

NGINX架构

第一张图由 NGINX 官方提供，我们从三个层面来解读它。

第1个层面是左下角的 3 个关键词。

1. 事件驱动Event-driven： 什么是事件呢？比如接收到TCP握手的SYN或者FIN报文，或者接收到ACK（发送缓冲区被释放出来），或者某个定时器执行结束，这些都是事件，而NGINX对请求的处理是由这些事件触发的。

2. 非阻塞Non- blocking： 指当你将socket设为非阻塞模式后，操作系统提供的POSIX API就能在未完成任务的情况下返回，比如建立连接的connect系统调用可以在未完成三次握手时就返回成功。

3. 异步Asynchronous： 面向开发人员的一种编程模式，它需要为每个请求维护上下文，并频繁更换状态机，非常复杂。当然，如果你使用了Lua协程，这种同步模式会降低复杂度，但在NGINX的C框架层仍然是异步的。

通过这三个关键词可以看到，NGINX 即使不做优化，性能也还不错。

第2个层面，再来从左至右看图中的网络流向。左边是下游客户端与 NGINX 之间的流量，主要是指HTTP协议。右边是 NGINX 与 IDC 内的各 Web server 传输的流量，它的交互协议种类比较丰富，但都能与HTTP协议进行语义转换。比如，当上游服务是Memcached 或者Redis时，存取缓存元素可以对应HTTP中的GET或者PUT方法（参见Roy Fielding的RestFul架构风格）。

第3个层面看进程架构。NGINX 有一个 master 父进程、多个 worker 子进程以及可选的cache manage和cache loader子进程。当然，如果你使用了NGINX的二次开发生态，还会多出一些进程，比如OpenResty可能产生的privileged agent子进程。master进程不处理网络流量，实际工作的是 worker 子进程，其他子进程都是用于配合worker进程处理请求的。比如HTTP缓存会存放在本地磁盘中，cache manage负责缓存的定时淘汰工作，而cache loader则在NGINX重启时载入磁盘文件。

NGINX也可以作为Web server使用，本次分享不涉及这块。今天主要讨论NGINX作为负载均衡的优化方法，除网络协议外，还会涉及一些磁盘 IO 知识。

再来看第二张图，它是OSI网络七层模型与真实的TCP/IP协议间的对应关系。模型是为了方便我们理解概念，而解决问题必须分析真实的协议。

比如，应用层中我们最常使用的是HTTP协议，它是由NGINX框架代码执行编解码的。表示层中常用的是TLS/SSL协议，它由NGINX进程中的openssl库执行编解码。传输层常用的是TCP协议，网络层是IP协议。网络层与链路层之间的定义则没有那么清晰，比如VLAN（802.1q）、ARP协议等可以近似归到这两层。以上传输层、网络层、链路层中的协议默认是由操作系统内核处理的，它们通过socket及一些系统工具（如ifconfig、route）提供给NGINX使用。

协议栈优化场景

接下来我们用4张图，看看协议栈优化的具体场景。

第一张图最常见。当网络报文到达服务器时，首先会从网卡来到内核的 TCP / IP 协议栈，处理完毕后经由右边的 socket 及 listen()、 bind()、recv()、send()等系统调用进入 NGINX worker 进程，再由 NGINX 框架调用 openssl库卸载TLS 协议，然后基于 http 状态机解析协议。获取到http 请求行、请求头后，NGINX框架就会依次调用各个NGINX http模块处理请求，包括过滤模块和处理模块，以及OpenResty用户常用的 Lua模块。

基于stream模块还可以将NGINX当作 4 层负载均衡使用，当然，这里的“4层”虽然指的就是OSI体系中的传输层，但与传统的4层负载均衡并不是一回事。例如，LVS作为4层负载均衡会部分参与到TCP协议的编解码（仅包含相对简单的握手阶段，不涉及复杂的滑动窗口与拥塞控制），即它会接管内核的TCP协议，而NGINX只是通过socket使用内核处理过的TCP协议。

第二张图可以看到TLS/SSL协议栈同时运行在用户态与内核态代码中，这是怎么回事呢？

TLS/SSL协议通常运行在用户态进程更合适，这是因为：首先它处于TCP与应用层协议之间，其次它又是消耗CPU的计算密集型协议，所以放在用户态进程中，既能提升应用开发效率，也不会影响性能。然而，在非常规场景下，TLS/SSL运行在内核中性能更高。比如，当NGINX作为CDN缓存服务运行时，缓存文件是放在磁盘中的，一旦HTTP请求命中缓存，接下来将磁盘文件发送到网卡这件工作，就可以通过sendfile零拷贝在内核中完成任务。可是一旦开启了HTTPS服务（当下全站加密是主流），零拷贝功能就无法使用，因为openssl是运行在NGINX进程中的。此时上图中的kTLS方案就有了用武之地。

再来看第三张图。

2022年 6 月份，HTTP3协议的正式RFC文档就已经发布，这给协议栈的优化又带来了变数。HTTP3为了解决HTTP2的队头阻塞、连接迁移问题，改用内核中的UDP协议解决进程调度，而将TCP协议中的可靠传输功能放在了用户态的quic协议栈中。因此，我们不再需要通过有限的sysctl指令优化复杂的TCP协议栈参数。

Go、Rust等语言都实现了 HTTP3协议库，但 NGINX 正式版却迟迟没有提供，仅有一个无法在生产环境中使用的quic分支。这里的原因很多，除了开源NGINX非常强调稳定性外，还因为NGINX的多进程架构，它使得连接迁移必须通过eBPF模块，才能在worker子进程间正确地分发报文，这就与操作系统内核紧密耦合起来，进一步延迟了正式版的发布。

另外，常见的TLS/SSL协议都是运行在TCP之上，而现在quic既需要使用TLS/SSL协议，又是跑在UDP协议上，这就改变了TLS/SSL的工作方式。比如，TLS不能对UDP payload整体加密，否则正、反向代理就无法通过connection-ID正确地执行会话保持或者负载均衡（quic不再基于四元组定义连接，而是通过1个64比特的connection-ID定义连接）。

最后来看第四张图，我们深入内核与硬件看协议栈如何优化。

对NGINX熟悉的同学都了解，使用worker_cpu_affinity 指令将worker 进程与CPU绑定时性能最高，因为这样就可以提升CPU的一、二级缓存命中率。但如果我们换个角度想，这意味着每个 worker 进程都有自己独立的HTTP协议栈！然而，这些 worker 进程却共享了操作系统的TCP协议栈，因此listen reuseport指令才有负载均衡的效果。共享提升了开发效率，但却因为加解锁操作降低了运行效率，因此在高并发、高吞吐时，你会发现ksoftirq进程占用的 CPU 很高。

对于更底层的IP 协议栈，它的共享影响范围就更大了，比如listen指令如果没有显示指定IP地址，那么你用 ifconfig 新增地址后，NGINX 就能马上处理新地址上的请求，可以想见这种灵活性的代价：对于满载、多IP的服务器，这种玩法一定会降低性能。IP层之下的数据链路层也有这个问题，通过brctl新增的网桥（做云原生的同学应该很熟悉）和802.1q 协议中的vlan也是可以立刻使用的。

有了总体视角，我们来看应用层的 HTTP 协议栈优化。

HTTP协议栈优化

从互联网的整体发展，我们先来看看HTTP/1.1协议栈的优化点，再来看HTTP2和HTTP3解决了哪些问题。下面这张图是从上世纪80年代起，以太网网卡带宽的演进速度。

可以看到，在 TCP 协议刚出现的80年代初，网卡带宽只有10Mb/s。到了HTTP/1.0协议出现、互联网开始飞速发展的95年，带宽已经达到100Mb/s，之后网卡进步明显加速，2004年出现了万兆网卡，2010 年 100G网卡，2018年时400G 网卡都出现了。当然，这些百G网卡目前都只在IDC数据中心出现，但这给协议开发人员的信号非常明显：如何才能用满越来越大的单机带宽呢？

与此同时，受制于物理规律（光速），报文在光纤中的传输速度并没有多大变化。必要的交换机中转所带来的“最后一公里”问题，是另一个让网络延迟居高不下的因素。因此，时延几乎不变，带宽却不断增大，协议设计者们有事可做了！

举个例子，十多年前我在设计服务器之间的传输协议时，还会使用gzip之类的压缩技术，因为那时带宽比CPU紧张。而现在IDC内部的带宽提升这么多后，就不再需要浪费CPU在两台服务器上压缩、解压缩数据了，而且消息传递速度还更快。

再比如，早期互联网大厂IDC内的资源利用率很低，因为在线业务的高峰与低谷流量差距太大，为了应对早晚、节假大促日、热点流量的变化，IDC必须预留大量空闲资源。这在早期的蓝海市场没有多大问题，但随着大数据时代的到来，在线业务的数据量以及引发的离线计算量增加的幅度越来越快，必须想办法提升IDC资源利用率。而在百G单机带宽的情况下，存储计算分离这种架构就有了用武之地，通过在线业务与离线计算服务的混合部署，谷歌IDC的 CPU 平均利用率达到惊人的 60% （参见论文Borg: the next generation，与此同时，国内许多IDC只有10%的平均使用率）。

理解了这两个例子，我们就能清晰的看到HTTP协议栈的优化方向：增带宽、降时延。

HTTP1的降时延

先从HTTP1的降时延谈起。单个页面上的资源数以百计，如果下载每个资源都使用独立的TCP连接，就有2个增大时延的因素：TCP握手与TCP慢启动。简单解释下。

一次HTTP资源下载包括2条HTTP消息：请求与响应，客户端在等待响应的过程中，承载HTTP会话的TCP连接只能处于空闲状态，这是HTTP的简单性设计理念决定的。所以，单一页面上百个资源下载任务，只能在并发范围内依次执行。如果每个HTTP会话都启动新的TCP连接，那么在TCP三次握手中，至少要浪费1个RTT，这就是数百毫秒。

TCP慢启动则是为了解决网络拥堵问题。就像公路上必须有红绿灯一样，TCP连接之间会在不通过第三方仲裁的情况下，自行监控丢包与延迟的变化解决网络拥塞。其中一个重要手段，就是连接刚建立时先不要满载发送字节流（慢慢提升拥塞窗口的大小），这就是“慢启动”。可以想见，对于百G大带宽的服务器而言，一次只能发送10个MSS大小（即15KB，假定MSS为1500字节）的报文有多浪费。

因此，早在HTTP1.0时代，就有了KeepAlive长连接技术，到了HTTP/1.1更是直接写入RFC标准里。简而言之，就是传输完1个HTTP请求后，不要关闭TCP连接，继续将它复用在下一个HTTP请求中，下图是NGINX上配置KeepAlive的方法：

上图左边是客户端与NGINX间的长连接配置，右边是应用服务器与NGINX间的长连接配置，可以看到，它们并不完全相同。其中，相同的配置是keepalive_requests、keepalive_time和keepalive_timeout，分别放在server{}或者upstream{}配置块中，表示1个TCP连接最多可以承载 1000 个请求、保持 1 小时或者 60 秒的最大空闲时长，一旦不满足任一条件，连接就会关闭。比起RFC标准来，似乎复杂了不少，但这是做软件工程必备的思维方式，因为NGINX需要处理各种意外情况，有了这些限制，单一用户就不会占用太多资源。

而对于IDC内的上游服务器，NGINX必须在客户端关闭HTTP会话后，继续维护TCP连接池，这其实对于上游的应用服务器带来了一些压力，所以又多了一个 keepalive 配置，它可以限制连接池内的TCP连接数量。

HTTP2的增带宽

上文说了如何减少报文的往返次数，我们再来看如何增带宽。其实传输层与网络层也能做到，比如以太网MTU默认 1500 字节，但巨型帧技术早已成熟，服务器之间单个报文可以增加到 9000 字节。而且在 IPV6 协议中，IP报文更是超过了 65535 字节的限制。当然，今天的重点还是在应用层协议上。

2015年推出的HTTP2协议有很多新特性，但相对HTTP1最大的提升就是增加了单TCP连接的传输带宽，下图可以清晰的看到它带来的变化，从左边的14秒到右边的2秒，差不多有一个数量级的提升！

解释下上图的测试上下文：这张高清地球图片被拆成了大约 380 张图片，因此需要发起380个HTTP请求才能用JavaScript拼接成完整的图片。 我的验证环境是Chrome浏览器，因此左边的 HTTP 1.1 会同时并发 6 个 TCP 连接，每个连接依次传输60多张图片。右边的HTTP 2 则仅使用1个TCP连接，同时传输380个小图片（实际上是380个STREAM），这样带宽便可以充分使用，消除了HTTP语义简单性带来的响应等待问题。

HTTP 2还有很多优点，比如浏览器解析完HTML资源（例如 index.html ）获得DOM 树后，会分析待下载的 CSS 、JavaScript或者多媒体资源，评价资源间的依赖程度和用户体验，从而对不同的STREAM设置优先级，这样可以在有限的总带宽下更有效的分配资源。再比如资源推送，当客户端下载了play.html后，服务器知道接下来浏览器一定需要jquery.js文件，于是就可以主动推送资源，如下图所示：

在NGINX上开启HTTP2非常简单，只要在listen指令最后添加http2参数即可。

当然HTTP 2协议并不是完美的，它的最大问题在于“队头阻塞”，如下图所示：

上图a场景的HTTP 1 协议中，蓝色报文的丢失并不会影响红色、绿色请求，但到了b场景的HTTP2协议，由于红、蓝、绿请求都承载在同1个 TCP 连接上，而TCP 又是一个有序字节流协议，所以蓝色报文的丢失不只影响了蓝色请求，还影响了红色、绿色请求，这就叫队头阻塞。HTTP3协议则通过UDP和quic层解决了这个问题，关于HTTP3我们后面再说。

TLS协议栈优化

接下来我们再来看 OSI表示层协议TLS/SSL的优化。在全栈加密的今天，绝大部分公网流量都是经由TLS协议加密的，而优化TLS除了在先进算法与兼容性、性能与安全性之间做权衡外，还要考虑系统架构约束的变化。

建立会话

先来看TLS会话握手，这是最消耗CPU性能的过程，通常单颗CPU核心的每秒新建数不过一千多，但更为关键的是，握手消耗的RTT时间更多，参见下图：

上图中右侧是以TLS1.2协议为例看会话建立过程的，相对于图左侧在TCP握手中消耗1个RTT（蓝色线条）之外，右侧共消耗了3个RTT（蓝色与绿色线条），这就接近1秒时延了。怎么解决呢？参见下图的TLS 1.3方案：

上图左侧，TLS1.2通过Client Hello、Server Hello、Client Key Exchange、Finished（或者可选的Server Key Exchange）4条消息在2个RTT中完成了握手。我们要分析下，为什么交换密钥不能从2次RTT降为1次RTT呢？这其实是能做到的，只要大幅减少加密算法（在TLS中被称为安全套件）的数量，就可以把Client Hello这个协商算法的消息与Client Key Exchange合并为一条消息，这就变成右图中的TLS 1. 3握手了。我们可以通过ssl_protocols指令配置NGINX支持的协议版本，但目前至少需要同时支持TLS 1.2和TLS 1.3，因为还有很多古老的客户端不兼容TLS1.3协议。

传输数据

再来看传输加密数据的过程，我们可以基于内核的kTLS提升性能。在介绍kTLS之前，咱们需要先回顾下HTTP缓存，这实际上是HTTP协议栈的优化内容，可又是NGINX使用kTLS的前置知识点，所以我放在这里简要介绍。

上图中，cache缓存可以存放在浏览器上，这时它的属性是private，只针对一个用户有效。缓存还可以存放在正向代理（参考科学上网）、反向代理（参考CDN）上，此时它的属性是public，可以被多个用户共享。缓存通过将内容放在空间上距离用户更近的位置上，降低用户下载内容的时间。

我们知道，NGINX可以使用Linux等操作系统提供的零拷贝技术（参见sendfile指令），将磁盘上的文件不通过worker进程就发送到网卡上。然而，openssl是运行在worker进程上的，一旦下游客户端走的是TLS流量，零拷贝就失效了，因为必须把磁盘上的文件读取到worker进程的内存空间上，才能使用openssl加密文件，然后再经由内核把加密后的字节流发送到网卡。所以，只要在内核中使用TLS协议加密流量，就可以继续使用零拷贝技术，如下图所示：

NGINX 1.21.4版本开始支持kTLS功能，通过ssl_conf_command Options KTLS;指令即可开启零拷贝TLS流量功能，具体参见这篇官方博客https://www.nginx.com/blog/improving-nginx-performance-with-kernel-tls/。

事实上如果不使用kTLS，在内核与worker进程间反复拷贝数据，造成的CPU消耗会越来越可观！关于这点，我们要从下图的内存发展趋势谈起：

上图中，红色的线是内存访问时延，绿色的线是内存访问带宽，黑色的线是内存容量。可以看到，从1999年到2017年，内存容量翻了 100 多倍，而访问带宽只升了20 倍，内存访问时延则基本没有变化！这对开发人员提出了要求：缓存的作用越来越大，但是内存拷贝是次数必须降低。因此，当我们把加密过程通过kTLS放到内核中，压根不跟worker 进程接触后，就会有10% 到 20% 的性能提升（参考官网测试数据）。

TCP/IP协议栈优化

最后来看TCP / IP协议栈的优化。摩尔定律的失效，对TCP/IP协议栈的优化影响很大，如下图所示，CPU在向多核心方向发展：

上图我们重点看绿、蓝、黑 3 条曲线。绿色曲线是 CPU 频率，从2004 年以后基本就不变了。蓝色曲线是CPU单核性能，略有提升是CPU架构优化和缓存带来的。黑色曲线则是CPU核心数，它的不断增加对开发人员的要求很高。具体到TCP/IP协议，就是操作系统的共享协议栈设计，带来的锁竞争概率直接上升！

现代OS都是分时操作系统，单核心CPU一样可以通过微观上的串行任务，实现宏观上的并发，而且这时的并行多任务在使用自旋锁时，几乎没有锁竞争问题。然而，一旦服务器使用了64核等CPU时，微观上就会有64个线程并行执行，对于高负载的NGINX来说锁冲突概率会非常高。此时你升级CPU，是不会带来线性性能提升的，与此同时，CPU的SI软中断百分比会急剧变大。

内核协议栈的设计，除了锁竞争问题外，还会引入3个问题。如下图所示，内核协议栈必须通过socket和系统调用与NGINX传递消息，因此系统调用导致的上下文切换、内核态与用户态间的内存拷贝、硬件NIC网卡与协议栈协同引入的软中断，都是不可忽视的因素：

当然，上图的设计优点也很多，比如大幅减少了应用开发的难度，增强了操作系统的稳定性等。但当我们关注性能、优化协议栈时，就不得不使用诸如零拷贝、kTLS等特性，还要不断关注软中断进程ksoftirq的CPU占用率。这里简单解释下什么是软中断，如下图所示：

上图有6 个步骤，其中第1、2、3步是从网络中接收的报文复制到 sk_buffer 中，并发起硬中断通知操作系统；第4、5步则是操作系统收到软中断后，通过协议栈处理报文，此时 ksoftirq 进程是在工作的。把两个步骤分开是一种异步化设计，毕竟网卡是硬件，处理报文的速度必须足够快，而ksoftirq则可以有延迟。第6步就是NGINX通过epoll_wait 拿到就绪的socket，或者经由read 或者 write 等函数拷贝报文数据。可见，在这个过程中，软中断对我们的消耗是可观的。

那么，当服务器CPU核心增多时，如何解决上述问题呢？Intel dpdk加上用户态协议栈是一条可选的路径。如下图所示，dpdk允许用户态进程直接从网卡上读取接收到的报文，或者拷贝数据到网卡来发送报文，绕过内核协议栈：

上图是腾讯f-stack给出的方案，它改造了freebsd操作系统的TCP/IP协议栈，对下通过dpdk与网卡交互，对上则以POSIX API的静态库形式，在 worker进程内为传输层之上提供服务。可以看到，由于每个NGINX worker进程内的IP、TCP协议栈都是独立的，所以当你修改IP地址时，不能使用操作系统的ifconfig或者nmcli命令，而是必须执行f-stack封装的ff_ifconfig命令，而且必须为每个worker进程分别执行脚本（使用-p指定进程ID），因此，管理每个worker进程的配置一致性是比较复杂的。

熟悉NGINX的同学都知道，所有worker子进程之间的地位是相同的。然而到了上图中的方案时，情况就不一样了。在多进程架构中，dpdk要求必须分清主次，也就是第1个fork出的worker子进程是主进程，它必须负责管理大页内存（huge page，dpdk必须使用这种管理模式，当然dpdk无锁内存池的设计非常高明！），而其他worker子进程则只是使用大页内存。这种设计导致NGINX reload模式会出问题，因为主worker退出、新建这段时间内，其他worker进程是不能提供服务的，这样NGINX的“热加载”功能就要大打折扣了。

worker进程的数量与网卡的数量并不一致，因此worker进程间必须通过哈希算法，各自处理网卡上收到的报文。由于每个worker进程绑定了一颗CPU核心，所以图中的cpu队列等价于worker进程处理报文的队列（dpdk是高性能网络框架，它只针对CPU设计独立的报文队列）。上图中，当蓝色报文到达网卡1时，会根据TCP四元组（在dpdk初始化时可通过f-stack.conf配置）分发到CPU1队列。worker0和worker1都会循环获取CPU队列中的报文，但worker0只取CPU0队列，所以worker1进程会获取到CPU1队列上的蓝色报文，经由进程内的独立TCP/IP协议栈（无须中断、无须加锁）处理完毕后，交由NGINX的epoll、各HTTP模块处理。可见，这种架构去除了软中断、系统调用、内核态用户态切换，大幅减少了内存拷贝次数，即使单worker性能也会有不少提升。但它的最大优势是多核心CPU，尤其是CPU核心达到32、64甚至更高时，无锁化设计带来的优势非常明显，可以轻松达到百万级CPS（每秒新建连接数）、上亿并发连接。

当然，这种带来高性能的独立协议栈设计，还引入了一个大麻烦：NGINX作为负载均衡使用时，一个会话上的客户端、上游服务器报文都必须在同一个worker进程内处理，这是普通的哈希算法无法做到的，如下图所示：

客户端发起的TCP连接由worker1进程处理，但worker1与上游服务器建立的连接，回包经由哈希算法，可能会落到worker0进程处理，这样数据就乱了！如何解决这个问题呢？f-stack和dpvs都给出了不太完美的方案。

f-stack在向上游发起TCP连接时，本地端口并不像从前一样找出一个空闲端口直接使用，而是从小到大反复测试（最大到65535），判断TCP四元组经由哈希函数的结果，如果本地端口导致哈希值没有落在当前worker进程上，就换一个，直到符合为止（O(n)时间复杂度！）。这套解决方案优点是与硬件无关，缺点则是性能非常差！

Dpvs的解决方案则必须使用支持fdir（Intel® Ethernet Flow Director）的网卡。Fdir技术允许程序基于TCP目的端口（其他四元组元素当然也可以）设置CPU队列的分发规则，比如，worker0进程发起的TCP连接本地端口只从1-10000（实际当然不是基于整数区间，而是按二进制bit位规划的），而worker1进程的本地端口则只从10001到20000，这样两个进程发送SYN报文时，就可以确保来自上游的SYN+ACK报文可以回到原worker进程了。这套方案的优点是性能很好，缺点则是绑定了硬件和应用代码（预留端口），而且dpdk的版本还必须与网卡配套才能正常工作。

事实上HTTP 3协议也面临类似的问题，只是它的表现形式在于“连接复用”功能！为了解决移动设备频繁更换IP地址导致的TCP断网重连问题，HTTP 3不再基于TCP四元组定义连接，而是设计了1个64位的connection ID，只要该ID不变，客户端在一段时间内（例如1分钟）断网重连后，依然可以复用原先的连接。然而，目前的操作系统内核只会基于TCP目的端口分发进程，并不知道每个worker进程上具体处理的connection ID，这也是NGINX迟迟无法推出HTTP3版本的原因（解决方案是高度耦合的eBPF模块，因此QUIC分支目前仍没有合并到主干）。

最后总结一下。今天我介绍了HTTP协议栈、TLS/SSL 协议栈和 TCP/IP 协议栈的优化思路，最终如何应用还要根据实际的应用场景来拍板，但取舍前一定要先了解当前协议栈的性能天花板在哪。好，谢谢大家，祝大家今天下午后面的旅程一切顺利！

让Nginx具备动态、集群管理能力并不容易，因为这将面临以下问题：

• 微服务架构使得上游服务种类多、数量大，这导致路由规则、上游Server的变更极为频率。而Nginx的路由匹配是基于静态的Trie前缀树、哈希表、正则数组实现的，一旦server_name、location变动，不执行reload就无法实现配置的动态变更；
• Nginx将自己定位于ADC边缘负载均衡，因此它对上游并不支持HTTP2协议。这增大了OpenResty生态实现etcd gRPC接口的难度，因此通过watch机制接收配置变更必然效率低下；
• 多进程架构增大了Worker进程间的数据同步难度，必须选择1个低成本的实现机制，保证每个Nginx节点、Worker进程都持有最新的配置；

等等。

APISIX基于Lua定时器及lua-resty-etcd模块实现了配置的动态管理，本文将基于APISIX2.8、OpenResty1.19.3.2、Nginx1.19.3分析APISIX实现REST API远程控制Nginx集群的原理。

接下来我将分析APISIX的解决方案。

基于etcd watch机制的配置同步方案

管理集群必须依赖中心化的配置，etcd就是这样一个数据库。APISIX没有选择关系型数据库作为配置中心，是因为etcd具有以下2个优点：

1. etcd采用类Paxos的Raft协议保障了数据一致性，它是去中心化的分布式数据库，可靠性高于关系数据库；
2. etcd的watch机制允许客户端监控某个key的变动，即，若类似/nginx/http/upstream这种key的value值发生变动，watch的客户端会立刻收到通知，如下图所示：

因此，不同于Orange采用MySQL、Kong采用PostgreSQL作为配置中心（这二者同样是基于OpenResty实现的API Gateway），APISIX采用了etcd作为中心化的配置组件。

因此，你可以在生产环境的APISIX中通过etcdctl看到如下的类似配置：

1
2
3

# etcdctl get  "/apisix/upstreams/1"
/apisix/upstreams/1
{"hash_on":"vars","nodes":{"httpbin.org:80":1},"create_time":1627982128,"update_time":1627982128,"scheme":"http","type":"roundrobin","pass_host":"pass","id":"1"}

其中，/apisix这个前缀可以在conf/config.yaml中修改，比如：

1
2
3
4

etcd:
  host:  
    - "http://127.0.0.1:2379"   
  prefix: /apisix                 # apisix configurations prefix

而upstreams/1就等价于nginx.conf中的http { upstream 1 {} }配置。类似关键字还有/apisix/services/、/apisix/routes/等，不一而足。

那么，Nginx是怎样通过watch机制获取到etcd配置数据变化的呢？有没有新启动一个agent进程？它通过HTTP/1.1还是gRPC与etcd通讯的？

ngx.timer.at定时器

APISIX并没有启动Nginx以外的进程与etcd通讯。它实际上是通过ngx.timer.at这个定时器实现了watch机制。为了方便对OpenResty不太了解的同学，我们先来看看Nginx中的定时器是如何实现的，它是watch机制实现的基础。

Nginx的红黑树定时器

Nginx采用了epoll + nonblock socket这种多路复用机制实现事件处理模型，其中每个worker进程会循环处理网络IO及定时器事件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

//参见Nginx的src/os/unix/ngx_process_cycle.c文件
static void
ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data)
{
    for ( ;; ) {
        ngx_process_events_and_timers(cycle);
    }
}

// 参见ngx_proc.c文件
void
ngx_process_events_and_timers(ngx_cycle_t *cycle)
{
    timer = ngx_event_find_timer();
    (void) ngx_process_events(cycle, timer, flags);
    ngx_event_process_posted(cycle, &ngx_posted_accept_events);
    ngx_event_expire_timers();
    ngx_event_process_posted(cycle, &ngx_posted_events);
}

ngx_event_expire_timers函数会调用所有超时事件的handler方法。事实上，定时器是由红黑树（一种平衡有序二叉树）实现的，其中key是每个事件的绝对过期时间。这样，只要将最小节点与当前时间做比较，就能快速找到过期事件。

OpenResty的Lua定时器

当然，以上C函数开发效率很低。因此，OpenResty封装了Lua接口，通过ngx.timer.at将ngx_timer_add这个C函数暴露给了Lua语言：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

//参见OpenResty /ngx_lua-0.10.19/src/ngx_http_lua_timer.c文件
void
ngx_http_lua_inject_timer_api(lua_State *L)
{
    lua_createtable(L, 0 /* narr */, 4 /* nrec */);    /* ngx.timer. */

    lua_pushcfunction(L, ngx_http_lua_ngx_timer_at);
    lua_setfield(L, -2, "at");

    lua_setfield(L, -2, "timer");
}
static int
ngx_http_lua_ngx_timer_at(lua_State *L)
{
    return ngx_http_lua_ngx_timer_helper(L, 0);
}
static int
ngx_http_lua_ngx_timer_helper(lua_State *L, int every)
{
    ngx_event_t             *ev = NULL;
    ev->handler = ngx_http_lua_timer_handler;
    ngx_add_timer(ev, delay);
}

因此，当我们调用ngx.timer.at这个Lua定时器时，就是在Nginx的红黑树定时器里加入了ngx_http_lua_timer_handler回调函数，这个函数不会阻塞Nginx。

下面我们来看看APISIX是怎样使用ngx.timer.at的。

APISIX基于定时器实现的watch机制

Nginx框架为C模块开发提供了许多钩子，而OpenResty将部分钩子以Lua语言形式暴露了出来，如下图所示：

APISIX仅使用了其中8个钩子（注意，APISIX没有使用set_by_lua和rewrite_by_lua，rewrite阶段的plugin其实是APISIX自定义的，与Nginx无关），包括：

• init_by_lua：Master进程启动时的初始化；
• init_worker_by_lua：每个Worker进程启动时的初始化（包括privileged agent进程的初始化，这是实现java等多语言plugin远程RPC调用的关键）；
• ssl_certificate_by_lua：在处理TLS握手时，openssl提供了一个钩子，OpenResty通过修改Nginx源码以Lua方式暴露了该钩子；
• access_by_lua：接收到下游的HTTP请求头部后，在此匹配Host域名、URI、Method等路由规则，并选择Service、Upstream中的Plugin及上游Server；
• balancer_by_lua：在content阶段执行的所有反向代理模块，在选择上游Server时都会回调init_upstream钩子函数，OpenResty将其命名为 balancer_by_lua；
• header_filter_by_lua：将HTTP响应头部发送给下游前执行的钩子；
• body_filter_by_lua：将HTTP响应包体发送给下游前执行的钩子；
• log_by_lua：记录access日志时的钩子。
  准备好上述知识后，我们就可以回答APISIX是怎样接收etcd数据的更新了。

nginx.conf的生成方式

每个Nginx Worker进程都会在init_worker_by_lua阶段通过http_init_worker函数启动定时器：

1
2
3

init_worker_by_lua_block {
    apisix.http_init_worker()
}

关于nginx.conf配置语法，你可以参考我的这篇文章《从通用规则中学习nginx模块的定制指令》。你可能很好奇，下载APISIX源码后没有看到nginx.conf，这段配置是哪来的？

这里的nginx.conf实际是由APISIX的启动命令实时生成的。当你执行make run时，它会基于Lua模板apisix/cli/ngx_tpl.lua文件生成nginx.conf。请注意，这里的模板规则是OpenResty自实现的，语法细节参见lua-resty-template。生成nginx.conf的具体代码参见apisix/cli/ops.lua文件：

1
2
3
4
5
6
7
8
9

local template = require("resty.template")
local ngx_tpl = require("apisix.cli.ngx_tpl")
local function init(env)
    local yaml_conf, err = file.read_yaml_conf(env.apisix_home)
    local conf_render = template.compile(ngx_tpl)
    local ngxconf = conf_render(sys_conf)

    local ok, err = util.write_file(env.apisix_home .. "/conf/nginx.conf",
                                    ngxconf)

当然，APISIX允许用户修改nginx.conf模板中的部分数据，具体方法是模仿conf/config-default.yaml的语法修改conf/config.yaml配置。其实现原理参见read_yaml_conf函数：

1
2
3
4
5
6
7
8

function _M.read_yaml_conf(apisix_home)
    local local_conf_path = profile:yaml_path("config-default")
    local default_conf_yaml, err = util.read_file(local_conf_path)

    local_conf_path = profile:yaml_path("config")
    local user_conf_yaml, err = util.read_file(local_conf_path)
    ok, err = merge_conf(default_conf, user_conf)
end

可见，ngx_tpl.lua模板中仅部分数据可由yaml配置中替换，其中conf/config-default.yaml是官方提供的默认配置，而conf/config.yaml则是由用户自行覆盖的自定义配置。如果你觉得仅替换模板数据还不够，大可以直接修改ngx_tpl模板。

APISIX获取etcd通知的方式

APISIX将需要监控的配置以不同的前缀存入了etcd，目前包括以下11种：

• /apisix/consumers/：APISIX支持以consumer抽象上游种类；
• /apisix/global_rules/：全局通用的规则；
• /apisix/plugin_configs/：可以在不同Router间复用的Plugin；
• /apisix/plugin_metadata/：部分插件的元数据；
• /apisix/plugins/：所有Plugin插件的列表；
• /apisix/proto/：当透传gRPC协议时，部分插件需要转换协议内容，该配置存储protobuf消息定义；
• /apisix/routes/：路由信息，是HTTP请求匹配的入口，可以直接指定上游Server，也可以挂载services或者upstream；
• /apisix/services/：可以将相似的router中的共性部分抽象为services，再挂载plugin；
• /apisix/ssl/：SSL证书公、私钥及相关匹配规则；
• /apisix/stream_routes/：OSI四层网关的路由匹配规则；
• /apisix/upstreams/：对一组上游Server主机的抽象；

这里每类配置对应的处理逻辑都不相同，因此APISIX抽象出apisix/core/config_etcd.lua文件，专注etcd上各类配置的更新维护。在http_init_worker函数中每类配置都会生成1个config_etcd对象：

1
2
3
4
5
6
7
8

function _M.init_worker()
    local err
    plugin_configs, err = core.config.new("/plugin_configs", {
        automatic = true,
        item_schema = core.schema.plugin_config,
        checker = plugin_checker,
    })
end

而在config_etcd的new函数中，则会循环注册_automatic_fetch定时器:

1
2
3

function _M.new(key, opts)
    ngx_timer_at(0, _automatic_fetch, obj)
end

_automatic_fetch函数会反复执行sync_data函数（包装到xpcall之下是为了捕获异常）：

1
2
3
4
5
6

local function _automatic_fetch(premature, self)
    local ok, err = xpcall(function()
        local ok, err = sync_data(self)
    end, debug.traceback)
    ngx_timer_at(0, _automatic_fetch, self)
end

sync_data函数将通过etcd的watch机制获取更新，它的实现机制我们接下来会详细分析。

总结下：

APISIX在每个Nginx Worker进程的启动过程中，通过ngx.timer.at函数将_automatic_fetch插入定时器。_automatic_fetch函数执行时会通过sync_data函数，基于watch机制接收etcd中的配置变更通知，这样，每个Nginx节点、每个Worker进程都将保持最新的配置。如此设计还有1个明显的优点：etcd中的配置直接写入Nginx Worker进程中，这样处理请求时就能直接使用新配置，无须在进程间同步配置，这要比启动1个agent进程更简单！

lua-resty-etcd库的HTTP/1.1协议

sync_data函数到底是怎样获取etcd的配置变更消息的呢？先看下sync_data源码：

1
2
3
4
5
6
7
8
9
10
11
12
13

local etcd         = require("resty.etcd")
etcd_cli, err = etcd.new(etcd_conf)

local function sync_data(self)
    local dir_res, err = waitdir(self.etcd_cli, self.key, self.prev_index + 1, self.timeout)
end

local function waitdir(etcd_cli, key, modified_index, timeout)
    local res_func, func_err, http_cli = etcd_cli:watchdir(key, opts)
    if http_cli then
        local res_cancel, err_cancel = etcd_cli:watchcancel(http_cli)
    end
end

这里实际与etcd通讯的是lua-resty-etcd库。它提供的watchdir函数用于接收etcd发现key目录对应value变更后发出的通知。

watchcancel函数又是做什么的呢？这其实是OpenResty生态的缺憾导致的。etcd v3已经支持高效的gRPC协议（底层为HTTP2协议）。你可能听说过，HTTP2不但具备多路复用的能力，还支持服务器直接推送消息，关于HTTP2的细节可以参照我的这篇文章《深入剖析HTTP3协议》，从HTTP3协议对照理解HTTP2：

然而，Lua生态目前并不支持HTTP2协议！所以lua-resty-etcd库实际是通过低效的HTTP/1.1协议与etcd通讯的，因此接收/watch通知也是通过带有超时的/v3/watch请求完成的。这个现象其实是由2个原因造成的：

1. Nginx将自己定位为边缘负载均衡，因此上游必然是企业内网，时延低、带宽大，所以对上游协议不必支持HTTP2协议！
2. 当Nginx的upstream不能提供HTTP2机制给Lua时，Lua只能基于cosocket自己实现了。HTTP2协议非常复杂，目前还没有生产环境可用的HTTP2 cosocket库。

使用HTTP/1.1的lua-resty-etcd库其实很低效，如果你在APISIX上抓包，会看到频繁的POST报文，其中URI为/v3/watch，而Body是Base64编码的watch目录：

我们可以验证下watchdir函数的实现细节：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

-- lib/resty/etcd/v3.lua文件
function _M.watchdir(self, key, opts)
    return watch(self, key, attr)
end

local function watch(self, key, attr)
    callback_fun, err, http_cli = request_chunk(self, 'POST', '/watch',
                                                opts, attr.timeout or self.timeout)
    return callback_fun
end

local function request_chunk(self, method, path, opts, timeout)
    http_cli, err = utils.http.new()
    -- 发起TCP连接
    endpoint, err = http_request_chunk(self, http_cli)
    -- 发送HTTP请求
    res, err = http_cli:request({
        method  = method,
        path    = endpoint.api_prefix .. path,
        body    = body,
        query   = query,
        headers = headers,
    })
end

local function http_request_chunk(self, http_cli)
    local endpoint, err = choose_endpoint(self)
    ok, err = http_cli:connect({
        scheme = endpoint.scheme,
        host = endpoint.host,
        port = endpoint.port,
        ssl_verify = self.ssl_verify,
        ssl_cert_path = self.ssl_cert_path,
        ssl_key_path = self.ssl_key_path,
    })

    return endpoint, err
end

可见，APISIX在每个worker进程中，通过ngx.timer.at和lua-resty-etcd库反复请求etcd，以此保证每个Worker进程中都含有最新的配置。

APISIX配置与插件的远程变更

接下来，我们看看怎样远程修改etcd中的配置。

我们当然可以直接通过gRPC接口修改etcd中相应key的内容，再基于上述的watch机制使得Nginx集群自动更新配置。然而，这样做的风险很大，因为配置请求没有经过校验，进面导致配置数据与Nginx集群不匹配！

通过Nginx的/apisix/admin/接口修改配置

APISIX提供了这么一种机制：访问任意1个Nginx节点，通过其Worker进程中的Lua代码校验请求成功后，再由/v3/dv/put接口写入etcd中。下面我们来看看APISIX是怎么实现的。

首先，make run生成的nginx.conf会自动监听9080端口（可通过config.yaml中apisix.node_listen配置修改），当apisix.enable_admin设置为true时，nginx.conf就会生成以下配置：

1
2
3
4
5
6
7
8
9

server {
    listen 9080 default_server reuseport;

    location /apisix/admin { 
        content_by_lua_block {
            apisix.http_admin()
        }
    }
}

这样，Nginx接收到的/apisix/admin请求将被http_admin函数处理：

1
2
3
4

-- /apisix/init.lua文件
function _M.http_admin()
    local ok = router:dispatch(get_var("uri"), {method = get_method()})
end

admin接口能够处理的API参见github文档，其中，当method方法与URI不同时，dispatch会执行不同的处理函数，其依据如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

-- /apisix/admin/init.lua文件
local uri_route = {
    {
        paths = [[/apisix/admin/*]],
        methods = {"GET", "PUT", "POST", "DELETE", "PATCH"},
        handler = run,
    },
    {
        paths = [[/apisix/admin/stream_routes/*]],
        methods = {"GET", "PUT", "POST", "DELETE", "PATCH"},
        handler = run_stream,
    },
    {
        paths = [[/apisix/admin/plugins/list]],
        methods = {"GET"},
        handler = get_plugins_list,
    },
    {
        paths = reload_event,
        methods = {"PUT"},
        handler = post_reload_plugins,
    },
}

比如，当通过/apisix/admin/upstreams/1和PUT方法创建1个Upstream上游时：

1
2
3
4
5
6
7
8

# curl "http://127.0.0.1:9080/apisix/admin/upstreams/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
> {
>   "type": "roundrobin",
>   "nodes": {
>     "httpbin.org:80": 1
>   }
> }'
{"action":"set","node":{"key":"\/apisix\/upstreams\/1","value":{"hash_on":"vars","nodes":{"httpbin.org:80":1},"create_time":1627982128,"update_time":1627982128,"scheme":"http","type":"roundrobin","pass_host":"pass","id":"1"}}}

你会在error.log中会看到如下日志（想看到这行日志，必须将config.yaml中的nginx_config.error_log_level设为INFO）：

1

2021/08/03 17:15:28 [info] 16437#16437: *23572 [lua] init.lua:130: handler(): uri: ["","apisix","admin","upstreams","1"], client: 127.0.0.1, server: _, request: "PUT /apisix/admin/upstreams/1 HTTP/1.1", host: "127.0.0.1:9080"

这行日志实际是由/apisix/admin/init.lua中的run函数打印的，它的执行依据是上面的uri_route字典。我们看下run函数的内容：

1
2
3
4
5
6
7
8
9
10
11
12

-- /apisix/admin/init.lua文件
local function run()
    local uri_segs = core.utils.split_uri(ngx.var.uri)
    core.log.info("uri: ", core.json.delay_encode(uri_segs))

    local seg_res, seg_id = uri_segs[4], uri_segs[5]
    local seg_sub_path = core.table.concat(uri_segs, "/", 6)

    local resource = resources[seg_res]
    local code, data = resource[method](seg_id, req_body, seg_sub_path,
                                        uri_args)
end

这里resource[method]函数又被做了1次抽象，它是由resources字典决定的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

-- /apisix/admin/init.lua文件
local resources = {
    routes          = require("apisix.admin.routes"),
    services        = require("apisix.admin.services"),
    upstreams       = require("apisix.admin.upstreams"),
    consumers       = require("apisix.admin.consumers"),
    schema          = require("apisix.admin.schema"),
    ssl             = require("apisix.admin.ssl"),
    plugins         = require("apisix.admin.plugins"),
    proto           = require("apisix.admin.proto"),
    global_rules    = require("apisix.admin.global_rules"),
    stream_routes   = require("apisix.admin.stream_routes"),
    plugin_metadata = require("apisix.admin.plugin_metadata"),
    plugin_configs  = require("apisix.admin.plugin_config"),
}

因此，上面的curl请求将被/apisix/admin/upstreams.lua文件的put函数处理，看下put函数的实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

-- /apisix/admin/upstreams.lua文件
function _M.put(id, conf)
    -- 校验请求数据的合法性
    local id, err = check_conf(id, conf, true)
    local key = "/upstreams/" .. id
    core.log.info("key: ", key)
    -- 生成etcd中的配置数据
    local ok, err = utils.inject_conf_with_prev_conf("upstream", key, conf)
    -- 写入etcd
    local res, err = core.etcd.set(key, conf)
end

-- /apisix/core/etcd.lua
local function set(key, value, ttl)
    local res, err = etcd_cli:set(prefix .. key, value, {prev_kv = true, lease = data.body.ID})
end

最终新配置被写入etcd中。可见，Nginx会校验数据再写入etcd，这样其他Worker进程、Nginx节点都将通过watch机制接收到正确的配置。上述流程你可以通过error.log中的日志验证：

1

2021/08/03 17:15:28 [info] 16437#16437: *23572 [lua] upstreams.lua:72: key: /upstreams/1, client: 127.0.0.1, server: _, request: "PUT /apisix/admin/upstreams/1 HTTP/1.1", host: "127.0.0.1:9080"

为什么新配置不reload就可以生效？

我们再来看admin请求执行完Nginx Worker进程可以立刻生效的原理。

开源版Nginx的请求匹配是基于3种不同的容器进行的：

1. 将静态哈希表中的server_name配置与请求的Host域名匹配，详见《HTTP请求是如何关联Nginx server{}块的？》；
2. 其次将静态Trie前缀树中的location配置与请求的URI匹配，详见《URL是如何关联Nginx location配置块的？》；
   
3. 在上述2个过程中，如果含有正则表达式，则基于数组顺序（在nginx.conf中出现的次序）依次匹配。

上述过程虽然执行效率极高，却是写死在find_config阶段及Nginx HTTP框架中的，一旦变更必须在nginx -s reload后才能生效！因此，APISIX索性完全抛弃了上述流程!

从nginx.conf中可以看到，访问任意域名、URI的请求都会匹配到http_access_phase这个lua函数：

1
2
3
4
5
6
7
8
9

server {
    server_name _;
    location / {
        access_by_lua_block {
            apisix.http_access_phase()
        }
        proxy_pass      $upstream_scheme://apisix_backend$upstream_uri;
    }
}

而在http_access_phase函数中，将会基于1个用C语言实现的基数前缀树匹配Method、域名和URI（仅支持通配符，不支持正则表达式），这个库就是lua-resty-radixtree。每当路由规则发生变化，Lua代码就会重建这棵基数树：

1
2
3
4
5
6
7

function _M.match(api_ctx)
    if not cached_version or cached_version ~= user_routes.conf_version then
        uri_router = base_router.create_radixtree_uri_router(user_routes.values,
                                                             uri_routes, false)
        cached_version = user_routes.conf_version
    end
end

这样，路由变化后就可以不reload而使其生效。Plugin启用、参数及顺序调整的规则与此类似。

最后再提下Script，它与Plugin是互斥的。之前的动态调整改的只是配置，事实上Lua JIT的及时编译还提供了另外一个杀手锏loadstring，它可以将字符串转换为Lua代码。因此，在etcd中存储Lua代码并设置为Script后，就可以将其传送到Nginx上处理请求了。

小结

Nginx集群的管理必须依赖中心化配置组件，而高可靠又具备watch推送机制的etcd无疑是最合适的选择！虽然当下Resty生态没有gRPC客户端，但每个Worker进程直接通过HTTP/1.1协议同步etcd配置仍不失为一个好的方案。

动态修改Nginx配置的关键在于2点：Lua语言的灵活度远高于nginx.conf语法，而且Lua代码可以通过loadstring从外部数据中导入！当然，为了保障路由匹配的执行效率，APISIX通过C语言实现了前缀基数树，基于Host、Method、URI进行请求匹配，在保障动态性的基础上提升了性能。

APISIX拥有许多优秀的设计，本文仅讨论了Nginx集群的动态管理，下篇文章再来分析Lua Plugin的设计。

这是因为基于域名规范，请求匹配server{ }配置块时，并不会按照它们在nginx.conf文件中的出现顺序作为选择依据。而且对于不支持Host头部、没有域名的HTTP/1.0请求和无法匹配到合适server{ }的异常请求，我们都要区别对待。

另外，为了加快匹配速度，Nginx将字符串域名、前缀通配符、后缀通配符都放在了哈希表中，该设计充分使用了CPU的批量载入主存功能。如果不了解这些流程，既有可能导致请求没有被正确的server{ }块处理，也有可能降低了原本非常高效地哈希表查询性能。

本文将沿着Nginx处理HTTP请求的流程，介绍一个请求是如何根据listen、server_name等配置关联到server{ }块的。我们将从TCP连接的建立、Nginx从哪些字段取出域名、域名是怎样与server_name匹配的，讲清楚Nginx如何为请求找到处理它的server{ }块。在实际运维中，大部分问题都是由于请求匹配指令错误造成的，搞清楚这一匹配流程，对我们掌握Nginx非常重要。

listen指令对server{ }块的第1次关联

为了让一台服务器可以处理访问多个域名的不同请求，我们用“虚拟主机”来定义一种域名的处理方式，在Nginx中这对应着一个server{ }块。因此，HTTP请求到达时，Nginx首先要找到处理它的server{ }配置块。

请求关联server{ }块时主要依据listen和server_name这两个指令，其中listen指令发生在TCP连接建立完成时，它对server{ }块进行首次匹配，等到接收HTTP请求头部时，server_name再进行第二次匹配，这样就可以决定请求由哪个server{ }块中的指令处理。我们先来看listen指令是如何匹配请求的。

Nginx启动时创建socket并监听listen指令告知的端口（包括绑定IP地址）。当运行在TCP协议之上的HTTP请求到达服务器时，操作系统首先收到了TCP三次握手请求。我们知道，TCP这种传输层协议是由内核实现的，因此，由内核完成TCP的三次握手后，就会通过“读事件”经由Linux的Epoll通知到Nginx的worker进程以及具体监听的socket。

比如，我们在nginx.conf中配置了以下两个server：

1
2
3
4
5
6

server {
    listen 192.168.1.5:80; 
}
server {
    listen 127.0.0.1:80; 
}

如果是本机进程发来的HTTP请求（在Linux中可以用curl或者telnet发起请求），它的IP报文头部目的IP地址就是127.0.0.1，而TCP报文头部的目的端口就是80。这样，Linux内核就找到了相应的socket，进而通过epoll_wait函数唤醒Nginx进程，而Nginx也就找到了对应的listen指令以及其所属的server{ }块。

你可能注意到，有些server{ }块没有listen指令也可以正常的工作。这是因为Nginx认为每个server{}都应该监听TCP端口，当你没有显式的配置listen指令时，Nginx会默认帮你打开80端口。

Nginx是怎样从HTTP请求中取出域名的？

Nginx允许多个server{ }块监听相同的端口，所以当访问相同端口、不同域名的请求到达时，还需要根据请求中的域名做第2次匹配，以决定最终关联的server{ }块。

这里我们先要搞清楚域名是怎么从HTTP请求中取出来的。在HTTP/1.0协议中并没有Host头部，这是因为互联网起步时，HTTP的设计者并没有考虑到域名的数量会远多于服务器。对于HTTP/1.0请求而言，只能从absolute URL中携带域名。

举个例子，下面这个没有携带Host头部的请求可以取到www.taohui.pub域名：

1

GET http://www.taohui.pub/index.html HTTP/1.0

如果你不清楚HTTP协议的格式，建议你先观看下我在极客时间上的视频课程《Web协议详解与抓包实战》第12课《详解HTTP的请求行》。

互联网业务的推动导致一台服务器必须要处理大量域名，于是HTTP/1.1协议推出了描述访问域名的Host头部。对于不含有Host头部的HTTP/1.1请求，RFC规范要求服务器必须返回400错误码（Nginx也正是这么做的）。当Host头部与上述absolute URL中的域名同时出现时，将会以后者为准。例如对于下面这个请求，Nginx会取出www.taohui.tech作为匹配域名：

1
2

GET http://www.taohui.tech/index.html HTTP/1.0
Host: www.taohui.pub

另外，对于使用了TLS/SSL协议的HTTPS请求来说，还可以从TLS握手中获取到域名。关于TLS握手及相关插件我会在后续的文章中再详述。

获取到请求的域名后，Nginx就会将其与上一节中listen指令匹配成功的server块进行第2次匹配，其中匹配依据就是server_name指令后的选项。我们暂且不谈server_name指令的匹配语法，先来看server_name匹配完成后的3种可能情况：

1. 域名恰好与1个server{ }块中的server_name相匹配，选用该server{ }中的指令处理与请求；
2. 有多个server{ }块匹配上了域名，此时按server_name规定的优先级选中一个server{ }块即可；
3. 所有server{ }块都没有匹配上域名，此时必须有一个默认server { }块来处理这个请求。

其中在第3种情况里，Nginx是这么定义默认server { }的：

1. 当listen指令后明确的跟着default_server选项时，它所属的server{ }就是默认server。
2. 如果监听同一个端口的所有server{ }都没有通过listen指令显式设置default_server，那么这些server{ }配置块中，在nginx.conf配置文件里第1个出现的就是默认server。

注意，你不能把监听相同端口、地址对的两个server{ }块同时设为默认server，否则nginx将无法启动，并给出类似下方的错误输出：

1

nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /usr/local/nginx/conf/nginx.conf:40

这就是请求匹配server{ }块的总体流程，下面我们来看server_name与域名的匹配，这也是最复杂的环节。

server_name指令对server{ }块的第2次关联

如果你购买过域名肯定清楚，虽然只买到一个域名，但你会有无数个子域名可以使用。比如我买到的是taohui.pub二级域名（pub是一级域名），我就可以配置出blog.taohui.pub这个三级域名，甚至自己搭建一个子域名解析服务，再配置出四级域名nginx.blog.taohui.pub，甚至五级、六级域名都能使用，如下图所示：

由于多级域名的存在，关联域名的server_name指令也相应地复杂起来，下面我们从3个层次看看server_name的选项种类。

首先，server_name支持精确地完全匹配，例如：

1

server_name blog.taohui.pub;

其次，server_name可以通过*符号作为通配符来匹配一类域名，比如：

1

server_name *.taohui.pub;

既可以匹配blog.taohui.pub，也可以匹配image.taohui.pub。由于*通配符在前方，所以我把它叫做前缀通配符。server_name还支持后缀通配符，例如：

1

server_name www.taohui.*;

它既可以匹配www.taohui.pub，也可以匹配www.taohui.tech域名。注意，server_name支持的通配符只能出现在最前方或者最后方，它不能出现在域名的中间，例如：

1

server_name www.*.pub;

就是非法的选项。

最后，当遇到通配符无法解决的场景时，可以使用正则表达式来匹配域名。当然，使用正则表达式的前提是将pcre开发库编译进Nginx（在CentOS下安装pcre开发库很简单，执行yum install pcre-devel -y即可。当有多个pcre版本并存时，可以通过configure –with-pcre=指定编译具体的pcre库）。

使用正则表达式时，需要在server_name选项前加入~符号，例如：

1

server_name ~^ww\d.\w+.taohui.tech;$

它可以匹配如ww3.blog.taohui.tech这样的域名。

当然，想一次写对正则表达式并不容易。pcre库提供的pcretest工具可以让我们提前测试正则表达式。注意，你用yum等工具安装pcre时，并不会自动安装pcretest工具，这需要你下载源代码（最新的pcre2-10.34下载地址参见这里，帮助文档参见这里）自行编译获得。本文不会讨论正则表达式的语法，也不会讨论pcretest工具的用法，关于Nginx中如何使用这两者，你可以观看下我在极客时间上的视频课程《Nginx核心知识100讲》第46课《Nginx中的正则表达式》。

Nginx中的正则表达式通常会提供提取变量的能力，server_name指令也不例外！我们可以通过小括号将域名中的信息取出来，交给后续的指令使用，例如：

1
2
3
4

server {
    server_name ~^(ww\d).(?<domain>\w+).taohui.tech$;
    return 200 'regular variable: $1 $domain';
}

此时发起访问域名ww3.blog.taohui.tech的请求，由于第1个小括号我通过$1变量获取值为ww3，而第2个小括号我通过domain名称获得值为blog（通过$2也可以获得相同的内容），因此return指令发来的响应将会是regular variable: ww3 blog。

说完这3种域名选项后，我们再来看它们同时出现且匹配命中时，Nginx是怎样根据优先级来选择server{ }块的。域名的总体匹配优先级，与server{ }块在nginx.conf中的出现顺序无关，也与server_name指令在server{ }块中的出现顺序无关。事实上，对于监听同一地址、端口的server{ }块而言，Nginx会在进程启动时在收集所有server_name后，将精确匹配的字符串域名、前缀通配符、后缀通配符分别构建出3个哈希表，并将正则表达式构建为一个链表。我们看下请求到达时的匹配流程：

1. 匹配域名时，首先在字符串域名构成的哈希表上做精确查询，如果查询到了，就直接返回，因此，完全匹配的字符串域名优先级是最高的；
2. 其次，将在前缀通配符哈希表上，按照每级域名的值分别查询哈希表，完成最长通配符的匹配。比如，blog.taohui.tech同时可以匹配以下2个前缀通配符：

   1 2	server_name *.tech; server_name *.taohui.tech;

   但Nginx会匹配命中*.taohui.tech。
3. 其次，会在后缀通配符哈希表上做查询，完成最长通配符的匹配。
4. 最后，会按照正则表达式在nginx.conf中出现的顺序，依次进行正则表达式匹配，这一步的性能比起前3步要慢许多。

这就是域名匹配的核心流程。

关于域名匹配你还需要了解的技巧

事实上，还有一些域名匹配的小技巧需要你掌握。

首先，就像前面说过的HTTP/1.0协议是没有Host头部的，所以使用relative URL的HTTP/1.0请求并没有域名。按照之前的流程，它只能被默认server{ }块处理，这大大限制了默认server {}块的功能。

在Nginx 0.7.11之后的版本，你可以通过server_name “”指定空字符串，来匹配没有域名的请求，这就解放了默认server { }的职责。

其次，当Nginx对内网提供HTTP服务时，许多客户端会通过网络可达的主机名发起请求，这样客户端填写的域名就是主机名。如果必须由管理员先用hostname命令获取到主机名，再改写server_name指令，这就太不方便了。因此，server_name后还可以填写$hostname变量，这样Nginx启动时，会自动把$hostname替换为真正的主机名。
server_name $hostname;

最后一点，上文说过非正则表达式的server_name选项都会存放在哈希表中，这样哈希表中每个bucket桶大小就限制了域名的最大长度。当我们使用长域名或者多级域名时，默认的桶大小很可能就不够了，这时需要提升server_name的桶大小。

桶大小由server_names_hash_bucket_size配置控制，由于CPU从内存中读入数据时是按批进行的，其中每批字节数是cpu cache line，因此为了一次可以载入一个哈希桶，server_names_hash_bucket_size的默认值被定为cpu cache line。目前多数CPU的cache line值是64字节，所以若域名较长时需要增加桶的大小。

当你增大桶大小时，需要保证server_names_hash_bucket_size是cpu cache line的整数倍，这样读取哈希桶时，会尽量少地读取主存。毕竟操作主存的速度通常在100纳秒左右，这比CPU的速度慢得多！

小结

最后对本文做个小结。

当TCP三次握手完成后，Linux内核就会按照内核的负载均衡算法，唤醒监听相应端口的某个Nginx worker进程。而从读事件及socket句柄上，Nginx可以找到对应的listen指令及所属的server{ }块，这完成了初次匹配。

接着，Nginx会接收HTTP请求，从absolute URL、 Host域名或者TLS插件中取出域名，再将域名与server_name进行匹配。其中匹配优先级是这样的：精确的字符串匹配优先级最高，其次是前缀通配符和后缀通配符匹配（这两者匹配时，如果多个通配符命中，会选择最长的server_name），最后才是正则表达式匹配。

如果以上情况皆未匹配上，请求会被默认server{ }处理。其中默认server {}是监听同一端口、地址的一系列server{ }块中，第1个在nginx.conf中出现的那个server{ }。当然，通过listen default_server也可以显示地定义默认server{ }。

最后留给你一个思考题，为什么有人用server_name _;来处理未匹配上的请求？欢迎你留言一起探讨。

UNIT是NGINX于2017年推出的Web容器方案，它提供了REST JSON接口动态修改服务配置，目前为Python、Java、Ruby、Perl、NodeJS、GOLang、WebAssembly等语言提供了生产环境级别的高性能Web容器，适用于大规模分布式环境中的微服务管理。从3月11日到4月1日，我分享了关于UNIT的4次课程。

微服务架构中，由于开发语言多样化、服务实例数量多，这就需要一种统一的服务治理方法，将配置更改、服务启停、网络协议适配、日志搜集等通用功能低成本的管理起来。K8S是一种解决方案，而NGINX UNIT针对Web场景也提供了上述功能，而且由于它仅针对Web容器场景，所以性能也更高。这4次视频课程如下：

3月11日 用Unit实现应用的动态配置

3月18日 Unit的负载均衡配置

3月25日 Unit架构设计

4月01日 Unit源代码解读

课件下载

这四次课程的PPT在这里：点击下载 。