一、传统服务器模型与 C10K 挑战
Per-Connection 模型：
传统的 Per-Connection模型（每连接一个进程/线程模型或进程/线程阻塞模型），是早期和许多传统服务器（如旧版本的Web服务器、数据库服务器等）采用的一种基本的并发处理架构。这种模型的核心思想就是：
- 为每个客户端连接分配一个独立的资源（通常是一个独立的进程或一个线程）；
- 当客户端发起连接请求时，服务器主进程/线程会接受连接，然后 fork 一个新的进程或创建一个新的线程来专门处理这个连接上的所有请求；
- 该进程/线程会阻塞在连接上，直到接收到客户端的请求、完成处理、发送响应，或连接关闭。
虽然这种模型的优势简单，隔离性很强（进程隔离比线程隔离更好），但是劣势也不是一般的大，如果针对的是小型项目那还简单，但如果是大型项目，那部署管理的复杂度将指数级上升：
- 进程或线程的创建和维护都需要消耗大量的内存和CPU资源（上下文切换开销）；
- 服务器能够同时处理的连接数受到系统资源的严重限制，在高并发场景下，频繁创建和销毁进程/线程会导致性能急剧下降，这种现象被称为 C10K 问题；
- 由于每个线程在等待I/O操作时都会被阻塞，导致CPU资源在等待过程中处于空闲状态，无法高效地利用
C10K 问题：
什么是 C10K 问题？？
C10K 是指 Concurrent 10,000 Connections（一万个并发连接）的缩写。描述的是在传统的基于进程/线程阻塞 I/O 的服务器架构下，单个服务器难以有效管理和处理超过 1w 个并发客户端连接的瓶颈和性能障碍。
问题的根源是什么呢？？
- 资源消耗：每建立一个连接就需要分配一个独立的进程或线程，而它们都需要消耗内核资源（如栈空间、线程控制块、内存等），当连接数达到数千甚至一万时，这些资源的总和会压垮服务器内存；
- 上下文切换开销：操作系统需要不断地在数以万计的进程或线程之间进行上下文切换，如此频繁的切换本身就会消耗大量的 CPU 周期，这部分开销并未用于实际处理业务逻辑，最终导致 CPU 效率低下；
- 内核限制：在早期或默认配置下，OS 会对单个进程可以创建的 线程或文件描述符 数量进行严格限制，这进一步阻碍了高并发的实现。此外在阻塞 I/O 的模型下，大量线程都在等待数据到达，导致 CPU 空闲，但线程数又太多，系统还是处于高负载状态。
二、Nginx 的革命性优势与起源
Nginx 的诞生：
为了解决上述问题，俄罗斯程序员 Igor Sysoev 于 2000 年左右启动该项目，并于 2004 年 10 月 4 日首次公开发布了 Nginx 0.1.0 版本。据野史记载，Sysoev 当时担任的是俄罗斯最大的互联网门户网站和搜索引擎之一 Rambler.ru 的系统管理员，而他开发 Nginx 的初衷，也正是为了解决 Rambler 网站当时面临高并发访问量的性能问题。
- 2007年，Nginx 发布 0.5.x 和 0.6.x 版本，功能逐渐完善，稳定性和性能得到显著提升，社区采用率增加，开始在一些大型网站中被用作反向代理和负载均衡器；
- 2008年，发布 0.7.x 版本，支持 HTTP/1.1 Keepalive，提升了长连接的性能；
- 2009年，发布 0.8.x 版本，支持 SSL/TLS，增强了安全性，使 Nginx 能够用于处理加密流量；
- 2011年，Sysoev 辞去 Rambler 的工作，与他人共同创立 NGINX, Inc. 公司，并发布 Nginx Plus 商业版本；
- 2013年，Nginx 成为全球前 1000 大流量网站中最受欢迎的 Web 服务器，市场份额迅速增长；
- 2017年，HTTP/2 协议在 Nginx 中获得成熟支持；
- 2019年，NGINX, Inc. 被网络基础设施巨头 F5 以 6.7 亿美元的价格收购，Nginx 的商业成功达到顶峰，成为 F5 产品组合中的关键组件；
- 2023年，Nginx 开源版本 1.25.0 发布，正式支持 HTTP/3 和 QUIC 协议。这是一个重大的技术里程碑，HTTP/3 作为下一代 Web 协议，Nginx加入对 HTTP/3 的支持使 Nginx 始终保持在行业技术的最前沿。
异步非阻塞模型：
这是一种高效的 I/O 处理机制，它允许程序在发起 I/O 操作后不必等待结果（即非阻塞），而是立即返回去处理其他任务；当 I/O操作在后台完成时，系统会通过回调函数或事件的方式通知程序来获取结果（即异步）。
这种模型的核心优势在于通过利用事件循环机制，用少量线程即可实现高并发处理，极大地提高了服务器等 I/O 密集型应用的资源利用率和响应速度。
这也就是 Nginx 为什么会采用这种模型的原因，用少量线程（甚至单线程）处理海量并发，避免了为每个连接创建和维护大量线程所产生的开销，大幅降低了内存消耗和上下文切换的成本。
Nginx 的核心定位：
Nginx 凭借其优秀的架构，使其在互联网基础设施中扮演了以下四个主要的核心角色：
- 高性能 Web 服务器：Nginx 可以直接托管静态文件（HTML、CSS、JS、图片等），相比传统服务器，Nginx 能以更少的内存和 CPU 资源处理更多的并发静态请求；
- 反向代理服务器：这是 Nginx 最常见的用途之一，它位于客户端和真正的后端应用服务器（Tomcat、Node.js、Django 等）之间，客户端的请求先到达 Nginx，Nginx 再将请求转发给一个或多个后端服务器。它隐藏了后端服务器的真实地址和结构，提供了额外的安全性和管理层；
- 负载均衡器：此功能是作为反向代理的延伸，当有多个后端服务器实例时，Nginx 可以根据配置的策略将传入的客户端流量均匀地分配到这些后端服务器上，确保服务的高可用和可伸缩，避免了单一后端服务器过载；
- 缓存服务器：Nginx 可以配置在自身内部存储里缓存后端服务器的响应内容（图片等），当有重复请求到达时，它可直接从缓存中返回数据，无需再次访问后端服务器，大大降低了后端负载，提高了响应速度。
总结起来就一句话：在面向大规模并发访问的场景中，Nginx 可作为一个轻量、高效的流量协调者和内容分发者。
三、新星 Angie 的崛起
Angie 的起源：
Angie 是一个相对较新的项目，其起源与 Nginx 软件及其团队的变动直接相关，它是由前 Nginx 的核心开发者们基于 Nginx 代码库创建的分支项目，它的诞生主要源于几个关键事件：
- Nginx 团队的变动与 F5 战略调整： 2022 年，俄乌冲突爆发，F5 公司随即宣布停止在俄罗斯的销售和运营，并停止了对俄罗斯境内 Nginx 开发者社区的支持。这一举动导致了 F5 位于俄罗斯的开发团队面临变动，直接导致一批曾经深度参与 Nginx 开发和支持的资深工程师们选择了离开 F5；
- 前 Nginx 核心开发者的聚集： 这批离开的工程师们在 2022 年 7 月左右成立了新公司 Web Server，他们认为 Nginx 的原有愿景还有扩展空间，决定将继续开发和演进 Nginx 的核心功能；
- 项目启动，fork Nginx 分支： Angie 从 Nginx 的代码库 fork 出来了一个分支，并于 2022 年秋季发布了 Angie 的开源版本。
Angie 的定位：
Angie 的目标并不仅仅是复制 Nginx，而是要作为一个直接替代品，同时扩展其功能，提供更强大的能力：
- 下一代协议支持： 尽早且全面地支持了 HTTP/3 和 QUIC 协议，包括用于代理连接；
- 简化配置与监控： 添加 RESTful API 接口，用于配置信息、服务器指标的 JSON 输出，以及支持 Prometheus（云监控工具） 统计格式等；
- 增强负载均衡： 引入会话绑定模式以及更平滑的故障后重新上线的机制等；
Angie 的出现是一次技术人员基于开源项目，因商业和地缘政治因素而导致的架构和项目方向的延续性创新。它继承了 Nginx 高性能、事件驱动的架构，但在功能和生态支持上，旨在走得更远，并满足特定的市场需求。
本文文在 CSDN 和 稀土掘金同步更新，系列最新版请查看 CSDN 专栏 blog.csdn.net/qq_55902573…
