在本文中，我将探讨 NGINX 的内部架构，重点关注以下主题：
NGINX 工作进程
连接管理
请求处理
工作进程
NGINX 架构的主要部分是主进程。当启动 NGINX 时，它会启动一个管理 NGINX 其他进程的进程。
主进程创建两个进程用于缓存管理。一个用于从磁盘读取缓存，另一个用于刷新缓存。但我最感兴趣的是工作进程，它们是 NGINX 中承担大部分工作的主力。
当将 NGINX 设置为自动模式（默认模式）时，该应用程序会根据 CPU 核心数量自动启动一定数量的工作进程。这取决于您是否启用了超线程。
超线程技术允许单个物理核心在操作系统中显示为两个逻辑核心。这可以提高性能，因为操作系统可以在多个硬件 CPU 线程上高效地调度进程。
如果您有一颗双核心 CPU 并启用了超线程，则操作系统将看到四个逻辑核心或硬件线程。这是基于性能的选择。
在工作进程和 CPU 之间建立一对一的对应关系是后端的选择。这假设工作进程和请求是 CPU 绑定的，但这并不一定是正确的。如果请求是 I/O 绑定的，例如从另一个后端或数据库读取，进程将花费大部分时间进行 I/O 操作，而不是使用 CPU。当然，这也取决于通信中使用的协议。
连接管理
工作进程在其配置的端口上进行监听，比如说 HTTP 的端口是 80。监听的动作会创建一个套接字（socket）和两个队列。一个是 SYN 队列，另一个是 ACCEPT 队列。这两个队列由内核管理。
如果一个客户端连接到端口 80，它会尝试与 NGINX 服务器建立 TCP 连接。客户端发送 SYN 开始 TCP 握手，内核接收到 SYN 并将其与 NGINX 的监听套接字匹配，然后将其放入 SYN 队列中。然后内核回复 SYN-ACK 以完成 TCP 握手。最后，客户端发送 ACK 以完成三次握手。现在我们有一个完整的连接。
一旦连接建立完成，内核将该连接移动到 ACCEPT 队列中，其中一个工作进程会接收它。工作进程之间会竞争 ACCEPT 队列上的连接。当一个工作进程接受一个连接时，会创建一个文件描述符，此时该工作进程负责从连接中读取数据。
工作进程可以以不同的方式接收连接。有时所有的工作进程都监听同一个端口，内核会在它们之间分配连接。其他时候，工作进程会让主工作进程接收连接，并将请求直接发送给工作进程。
一旦工作进程接收连接，它们可以开始读取数据。接下来是请求处理。当然，一个工作进程可以同时接受和处理多个连接。
请求处理
假设有两个客户端连接到一个 NGINX 负载均衡器。一个客户端连接到 Worker 3，另一个客户端连接到 Worker 4。
连接到 Worker 3 的客户端发送一个 HTTP 请求来获取一个 HTML 页面，以下是发生的情况：
请求作为字节流在 TCP 连接上传输。
字节流到达内核的连接缓冲区。
Worker 3 在连接上调用 read。
数据被复制到 Worker 3 的内存中。
Worker 3 解析数据并理解它是一个 HTTP 请求。
Worker 3 处理请求并从磁盘读取 HTML。
Worker 3 将 HTTP 响应写回连接。
响应字节流进入发送缓冲区。
内核将数据发送给客户端。
请注意，内核不会将数据推送给工作进程。相反，内核将数据保留在接收缓冲区，并告知工作进程它有数据可供读取。
根据 HTTP 版本和是否启用了 TLS，工作进程需要进行更多的工作来解密数据，然后解析协议。相比于 HTTP/1.1，HTTP/2 和 HTTP/3 的解析更加耗费资源。这就是为什么将进程固定到 CPU 上非常重要。过多的进程会导致上下文切换（进程在 CPU 上切换），可能降低性能。
我们可以按照同样的步骤处理连接到 Worker 4 的客户端。唯一的区别是 Worker 4 会与配置的后端建立一个新的连接来转发请求。在这里，后端连接池的正确配置至关重要。实际上，这也是为什么 Cloudflare 放弃了使用 NGINX 的原因之一，后端连接池无法在多个工作进程之间进行共享。
结论
NGINX 是一个功能强大的 Web 服务器、负载均衡器和缓存层。多工作进程的架构使得 NGINX 能够将连接和请求分配到多个 CPU 上，以更有效地利用资源。这只是 NGINX 内部架构的概述，NGINX 还有更多的功能。
如果你喜欢我的文章，点赞，关注，转发！
