不靠谱的糖饼两年前我需要在一台只有 256MB 内存的嵌入式设备上提供 HTTP 服务，设备要同时处理状态查询、远程配置和文件上传。第一反应当然是装个 Nginx，但业务方要求二进制体积控制在 5MB 以内、不能依赖动态库、还得支持自定义的鉴权逻辑。换了好几个方案都不满意，最后干脆决定自己实现一个基于 Reactor 模式编写的 HTTP 服务器。正是那段经历让我把 IO 多路复用、HTTP 协议解析、连接复用这些概念从"看过"变成了"真正掌握"。这篇文章想把这套东西完整梳理一遍：从 Reactor 模式怎么拆解，到 HTTP 报文边界怎么处理，再到压测和内核参数调优，把我踩过的坑原原本本摆出来。
如果你也在学网络编程、想自己写一个 HTTP 服务器练手，或者正在为嵌入式设备挑选轻量级服务方案，这篇应该能帮你少走不少弯路。代码我会以 C++ 伪代码为主，核心逻辑不依赖特定平台，Windows 和 Linux 都能参考。
1. 我为什么放着 Nginx 不用，非要自己写一个 HTTP 服务器
1.1 这个项目解决的真实问题
先说清背景。我要做的不是"再造一个 Nginx"，而是在受限环境下提供恰好够用的 HTTP 能力。当时设备上跑的是一块 ARM 处理器，内存 256MB，Flash 存储 16MB，系统里已经有一个采集程序在持续占用 CPU。常规 Web 服务器在这个环境里显得太"重"了，光是 Nginx 的动态模块和配置系统就占掉不少空间，而且为了做设备接入鉴权，我还得写 C 模块挂在 Nginx 里，开发周期完全不可控。
后来我也考虑过用轻量级的 httpd、mongoose，但调研一圈发现，这些库要么文档不全，要么许可证有坑，要么对自定义协议扩展不友好。最让我纠结的是：它们都封装好了事件循环，出了问题我只能当黑盒处理。在嵌入式设备上调试一个黑盒的网络库，体验真的很糟糕。所以最终决定自己写一个。
这个决定看起来"反效率"，但实际算账下来是划算的：
- 功能可控：需要什么协议特性就实现什么，不需要的一律砍掉。
- 体积可控：一个静态编译好的二进制可以控制在 3MB 左右。
- 排查可控：出了问题我能直接看源码定位，不需要去翻第三方库内部实现。
1.2 为什么选择 Reactor 模式而不是多线程
写服务器之前，最先要回答的问题是：怎么处理并发连接？
最简单粗暴的方案是为每个连接开一个线程，也就是常说的 thread-per-connection。这个模型写起来确实直观，accept 一个连接就 pthread_create 一个线程去 read/write。但问题也很明显：线程的创建和切换都是有代价的，一个线程默认栈空间就有 8MB（虚拟内存），虽然实际占用按需分配，但上千个连接同时活跃时，调度器会被频繁切换搞得很痛苦，更别说在 256MB 内存的设备上。
Reactor 模式的核心思路是：用一个（或少数几个）线程同时监听大量文件描述符，当某个 fd 上发生了可读、可写、有连接到来等事件时，再调用对应的回调函数去处理。这样就不用为每个连接单独创建线程了。换句话说，Reactor 把"等待"这件事集中起来了，而把"干活"分散到各个具体的事件处理函数里。
对于我这个 HTTP 服务器的场景，绝大多数连接都是短平快的请求响应，真正在 CPU 上干活的时间非常短，大部分时间都花在等待网络数据上。用 Reactor 模式，几个线程就能扛住成千上万的并发连接，资源占用和扩展性都远好于 thread-per-connection。
1.3 我对 Reactor 模式的理解：一个类比
很多教程喜欢把 Reactor 比作"餐厅服务员"，但我更愿意把它比作"前台接待员"：
一个大型办公室里有很多人在等电话（等待事件），如果每个人办公桌上都配一部电话，那电话线就要铺满整栋楼（thread-per-connection）。Reactor 的做法是只设一个总机，所有来电先打到总机，总机根据来电号码转接到相应分机，或者直接记录消息让分机稍后回拨（事件回调）。分机不需要一直守着电话，它可以去干别的事，等总机通知"你的电话来了"再处理。
这个类比带出了 Reactor 模式的核心：事件分离。你不需要为每个连接准备一个阻塞等待的线程，只需要在事件发生时被通知，然后去做对应的处理。理解了这个，后面看 epoll 和事件循环就顺理成章了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Reactor 的核心机制：事件循环、IO 多路复用和回调的配合
2.1 阻塞 IO 的痛点
要理解 Reactor，先要理解阻塞 IO 为什么不行。
假设你写一个最简单的 accept 循环：
cpp复制while (true) {
int client_fd = accept(listen_fd, ...);
handle_client(client_fd); // 这里如果阻塞读，就只能处理一个连接
}
如果 handle_client 里先 recv 等待客户端数据，而客户端一直不发数据，整个服务就卡住了，后面排队的连接全都进不来。非阻塞 IO 可以解决"卡住"的问题，但随之而来的问题是：你怎么知道哪个连接有数据了？总不能挨个轮询所有连接吧，那样 CPU 就被白白耗光了。
这时候就需要 IO 多路复用机制来帮你"监控"所有连接。Linux 上的 epoll、macOS 上的 kqueue、Windows 上的 IOCP，都是干这件事的。Reactor 模式在 Linux 上的经典实现骨架就是 epoll。
2.2 select、poll、epoll 的差异和选型
很多初学者会在这三个 API 之间迷茫。我直接说结论：新写的 Linux 服务端程序，用 epoll；跨平台需要简单实现时，才考虑 poll；select 除了兼容老代码几乎不用。
它们的核心差异在于：每次调用时，内核怎么知道你要监控哪些 fd，以及有事件时怎么告诉你。
- select 每次调用都要把整个 fd 集合从用户态拷贝到内核态，内核线性扫描，返回后你还要线性遍历找出就绪的 fd。FD_SETSIZE 默认只有 1024，连接一多直接不够用。
- poll 解决了 FD_SETSIZE 的限制，但本质上还是每次全量拷贝、全量扫描，复杂度 O(n)。
- epoll 在 Linux 2.6 引入，它通过 epoll_ctl 提前把要监控的 fd 注册进内核维护的红黑树，事件发生时只需要把就绪列表拷贝回用户态。复杂度 O(就绪数)，而不是 O(总fd数)。
我用 epoll 时最直观的感受是：1 万个空闲连接 + 100 个活跃连接，epoll_wait 只返回那 100 个，处理起来非常轻快。如果是 poll，每次都得扫描 1 万个，差距一下就出来了。
2.3 从事件到回调：Reactor 的完整链路
我的服务器里，事件循环大概是这样的：
cpp复制while (true) {
int n = epoll_wait(epfd, events, MAX_EVENTS, timeout_ms);
for (int i = 0; i < n; i++) {
EventCtx* ctx = (EventCtx*)events[i].data.ptr;
uint32_t ev = events[i].events;
if (ev & EPOLLIN) {
ctx->read_callback(ctx);
}
if (ev & EPOLLOUT) {
ctx->write_callback(ctx);
}
if (ev & (EPOLLERR | EPOLLHUP)) {
ctx->close_callback(ctx);
}
}
}
每个连接对应一个 EventCtx，里面保存了文件描述符、读写缓冲区、连接状态、解析上下文等数据。fd 和 EventCtx 通过 epoll_event.data.ptr 关联，事件触发后直接拿到对应连接的上下文。
我刚写的时候犯过一个典型错误：把 fd 存在 data.fd 里，然后每次再通过 fd 去查 EventCtx。查一次 map 或数组是还好，但完全没有必要，直接存指针就好了。这里唯一要注意的是内存生命周期：epoll 事件触发时，对应的 EventCtx 必须还活着。所以我统一在连接关闭时先从 epoll 摘除，再释放 EventCtx，保证不会被回调访问悬空指针。
这个事件循环就是整个服务器的"心脏"。所有连接的处理逻辑都被拆成了"什么事发生了，要做什么"，而不是"我用一个线程专门等这个连接"。理解了这一层，Reactor 模式最核心的东西就抓住了。
3. 主从 Reactor 线程模型：服务器并发能力的真正分水岭
3.1 三种线程模型的取舍
Reactor 模式具体怎么部署到线程上，有三种常见方案：
| 模型 | 线程数量 | 优点 | 缺点 |
|---|---|---|---|
| 单 Reactor 单线程 | 1 个线程跑事件循环 | 简单、无锁、调试容易 | 一个回调卡住，整个服务器瘫痪；发挥不了多核 |
| 单 Reactor 多线程 | 1 个线程监听 + 工作线程池处理业务 | 简单扩展了计算能力 | 监听线程可能成为瓶颈；线程间通信有开销 |
| 主从 Reactor 多线程 | 主 Reactor 只负责 accept，从 Reactor 负责连接 IO | 并发能力强，Netty、Nginx 都在用 | 实现复杂，需要处理连接分配和负载均衡 |
单 Reactor 单线程模型最适合做学习和原型验证，我的第一版就是这种：一个 epoll 循环搞定所有事。但后来压测发现，当客户端大量并发时，CPU 单核跑满，其他核闲着，请求处理能力遇到天花板。
单 Reactor 多线程模型稍微复杂一点：IO 事件还是主线程处理，业务逻辑丢给线程池。但 HTTP 请求解析本身也是 IO 操作，如果解析也在主线程做，压力还是集中在一个线程上。这个模型适合"IO 轻 + 业务重"的场景，而我的场景是"IO 重 + 业务轻"（设备上主要是转发静态数据和简单 JSON），所以不是最优解。
3.2 我的选型：主从 Reactor 多线程模型
最后我采用的是主从 Reactor：主线程只 accept 新连接，然后把连接 fd 均匀分发给多个从 Reactor 线程。每个从 Reactor 线程都有自己的 epoll 实例，负责一部分连接的读写事件。
好处很明显：
- 主线程只做 accept，非常轻量，几乎不可能成为瓶颈。
- 多个从 Reactor 线程分配到不同 CPU 核，充分利用多核性能。
- 每个连接绑定到一个从 Reactor 线程，不需要加锁处理这个连接上的读写。
分发策略我用了最简单的 round-robin，也就是每 accept 到一个 fd，就把它添加到下一个从 Reactor 线程的 epoll 里。这里有个跨线程操作 epoll 的问题，我踩过坑：从主线程直接调用另一个线程的 epoll_ctl 是不安全的，因为 io_uring 或者旧内核上可能存在并发问题。我的解决办法是给每个 Reactor 线程配一个 eventfd，主线程要往某个 Reactor 注册连接时，先把连接信息放到一个无锁队列里，然后向 eventfd 写入 1 个字节。Reactor 线程在 epoll_wait 里醒过来，再处理队列里的待注册连接。这样既跨线程传递了 fd，又保证了线程安全。
3.3 连接分配中的惊群问题与解决
"惊群"是服务器开发里很有名的一个坑：多个线程同时 epoll_wait 同一个监听 fd，当有新连接到来时，所有线程都被唤醒，但只有一个线程能 accept 成功，其他线程白白空转一圈。
我刚开始做多 Reactor 时犯过这个错：所有 Reactor 线程都去监听同一个 listen_fd，结果压测时发现系统负载翻了好几倍，转发延迟也上去了。后来改成"只有一个主 Reactor 监听 listen_fd，accept 后再分发"，才彻底绕开这个问题。Linux 4.5+ 的 EPOLLEXCLUSIVE 可以部分缓解惊群，但最稳妥的做法还是主从分离，反正我们用主 Reactor 专门 accept 也不需要额外成本。
需要提醒的是，主从 Reactor 并不是越多的从线程越好。我的设备是双核 ARM，开 2 个从 Reactor 线程就够了。在 16 核的服务器上我测试过 8 个线程和 16 个线程，后者反而因为上下文切换和内存争用导致吞吐略降。正确的做法是让 Reactor 线程数等于 CPU 物理核数，而不是逻辑核数，尤其是开启了超线程的机器上，更需要实测确认。
4. HTTP 协议解析：请求行、头部和 body 的边界问题
4.1 把 HTTP 报文解析看成状态机
HTTP/1.1 报文看起来很简单，但解析起来有一堆边界细节。我把它拆成一个状态机：
code复制状态：METHOD_START -> METHOD -> URI -> VERSION -> HEADER_START -> HEADER_NAME -> HEADER_VALUE -> HEAD_END -> BODY
每个状态只处理一个字符，遇到条件就跳转。比如在 METHOD_START 状态读到空格，说明方法名结束，切换到 URI 状态。实现时我用了枚举状态机，而不是字符串分割，因为 TCP 是流式协议，你没有办法保证一次 recv 就能拿到完整的 HTTP 请求，很可能读到一半，下次再来数据。
状态机的漂亮之处在于：无论这次 recv 得到 1 个字节还是 1KB，状态机都能正确处理。比如请求行 "GET /index.html HTTP/1.1\r\n" 被 TCP 分成了两段："GET /index.h" 和 "tml HTTP/1.1\r\n"，状态机在第一段结束时停在 URI 的中间，等第二段到了接着解析，最后完整拼出请求行。如果我用字符串查找 \r\n 的方式，就得手动维护残缺数据的缓冲区，很容易出 bug。
4.2 粘包、半包和缓冲区管理
粘包和半包是 TCP 编程里最经典的问题。HTTP/1.1 请求和响应没有固定边界，靠 \r\n 分隔头部，靠 Content-Length 或 Transfer-Encoding 界定 body。我踩过一个很隐蔽的坑：客户端连续发送两个请求到同一个连接，第一个请求的 body 和第二个请求的请求行粘在同一个 TCP 包里。如果解析完第一个请求，直接把缓冲区剩余部分丢掉，第二个请求就永久丢了。
正确的做法是：解析器消费了多少字节，就从缓冲区头部移除多少字节，剩余数据留着继续解析下一个请求。我的 Connection 默认有一个 8KB 的读缓冲区，recv 回来的数据先追加到缓冲区尾部，然后由解析器尝试解析完整请求。如果缓冲区不够大，body 很长时，得自动扩容，我采用倍增策略，同时设一个上限（默认 8MB），超过就返回 413 Request Entity Too Large，防止有人恶意上传巨包打满内存。
4.3 Connection 头与 Keep-Alive 的解析细节
HTTP/1.1 默认是长连接，也就是 Connection: keep-alive。HTTP/1.0 默认是短连接，除非显式带上 Connection: keep-alive。解析完一个请求后，服务器需要根据协议版本和 Connection 头决定是否关闭连接。
这里有个细节：Connection 头可能出现在头部任意位置，也可能有多个值，比如 "Connection: keep-alive, Upgrade"。所以不能用简单的字符串相等判断，我得把值按逗号拆开逐个比较。我因为这个没处理好，出现过一次线上诡异的"每隔几个请求就断连"的问题——客户端发的是 "Connection: keep-alive, Upgrade"，我直接比较整个字符串，匹配失败就当成短连接关掉了。
如果客户端带了 Expect: 100-continue，服务器还得先回复 HTTP/1.1 100 Continue，再读取 body。这个特性在各种 HTTP 库里实现不多，但浏览器上传大文件时可能用到，我一开始忽略了，导致某些客户端上传文件失败。后来抽时间补上了。
4.4 响应端：缓冲区满了怎么办
解析完请求，进入处理阶段，最后要写回响应。很多人以为发送就是简单 write 一次，但在高并发下，一个连接的发送缓冲区可能瞬间被写满，write 返回 EAGAIN。如果这时候选择放弃数据或者关闭连接，就是错误行为。
我的写事件处理逻辑是：业务处理完成后的响应数据先写入 Connection 的写缓冲区，然后尝试非阻塞 write 一次。如果全部写完，很好；如果没写完，就把这个连接的 EPOLLOUT 事件注册到 epoll 里，等 socket 可写时再继续发送剩余数据。注意，EPOLLOUT 不需要一直挂在 epoll 上，只有缓冲区有剩余数据时才注册，否则每次 epoll_wait 都会返回可写事件，变成忙轮询，白白烧 CPU。这个"按需注册 EPOLLOUT"的细节，是我压测时发现 CPU 占用异常才定位出来的。
5. 连接复用与超时管理：高并发下最容易翻车的地方
5.1 HTTP 连接复用为什么重要
HTTP 连接复用（keep-alive）对服务器性能影响非常大。如果不复用连接，每个请求都要经历 TCP 三次握手 + 四次挥手。一次握手大约消耗 1 个 RTT，在高延迟网络里可能就是几十毫秒，而且每次连接建立和关闭都要内核参与，成本不低。
我做过一个简单对比：在同一台机器上压测，短连接模式（每个请求新建连接）和 keep-alive 模式（同一个连接连续发请求），后者的 QPS 能提升 3 到 5 倍。原因很简单，省掉了大量握手和挥手的开销。所以我的 Reactor HTTP 服务器默认支持 keep-alive，只有在资源紧张或收到 Connection: close 时才主动关闭连接。
5.2 空闲连接的清理：别让不活跃的连接占着 fd
连接复用带来了新问题：客户端连上后长时间不发请求，连接就一直占着文件描述符和内存。如果客户端有上万个空闲连接，服务器的 fd 会被耗尽，新连接根本 accept 不进来。
解决思路是给每个连接设置空闲超时。我采用的是一个基于小根堆的定时器：每个连接的最近活跃时间戳更新时，就调整它在堆里的位置；每秒钟事件循环轮询一次堆顶，如果堆顶的连接空闲时间超过 60 秒，就关闭它。用堆而不是链表，是因为每次只需要处理"最老"的连接，堆的插入和删除复杂度都是 O(log n)，对 10 万连接来说性能完全可接受。
实现还有一个要点：定时器事件不能单独开线程去跑，否则又要跟 Reactor 线程加锁。我的做法是让 epoll_wait 的超时时间等于"堆顶连接还剩多久超时"，这样 epoll_wait 既不会空转，又能按时醒来检查定时器。这个设计把定时任务完美嵌入了事件循环，是我比较满意的一个点。
5.3 TIME_WAIT 和 SO_REUSEADDR：连接关闭的隐藏坑
做短连接压测时，我遇到一个很奇怪的现象：压测跑了一万多个请求后，新连接突然全部失败，报"Cannot assign requested address"。排查下来发现是客户端端口被占用光了——短连接模式下客户端大量进入 TIME_WAIT 状态，端口没法快速复用。
服务器端也有类似的坑。服务器主动关闭连接时，会进入 TIME_WAIT 状态，默认要等 2 MSL 才能完全释放端口。如果用 SO_REUSEADDR 属性，就能在这段时间里重新绑定同一个端口。这是我强烈建议所有服务端程序默认开启的 socket 选项。在 Linux 上还可以调整 tcp_tw_reuse 让客户端更快复用 TIME_WAIT 状态的连接，但要注意，tcp_tw_reuse 是客户端选项，服务器端设置没意义，这个我曾经搞错过。
另外，如果服务器需要"优雅停机"（等正在处理的请求返回后再退出），需要处理 SIGTERM 信号后不再 accept 新连接，但继续执行事件循环直到活跃连接数为零。这个功能我一开始图省事没做，后来在滚动升级时吃了亏——直接 kill 进程导致正在上传文件的客户端全部断开。后来花了一个下午补上了优雅退出逻辑，止损效果非常明显。
6. 压测与调优：从 2 万连接到 10 万连接的完整过程
6.1 压测工具和场景设计
开发完成后，我需要对 HTTP 服务器做性能验证。压测工具我用了两个：ab（ApacheBench）和 wrk。
ab 适合做简单的请求 QPS 测试，命令一行就能跑：
bash复制ab -n 100000 -c 1000 -k http://127.0.0.1:8080/status
wrk 的优势是可以自定义 Lua 脚本，模拟更真实的请求分布，比如不同路径、不同 body 大小：
bash复制wrk -t 8 -c 1000 -d 30s -s post.lua http://127.0.0.1:8080
我的压测场景分了三种：
- 纯静态响应：返回固定 JSON，考验服务器极限吞吐。
- 小 body 上传：POST 2KB 数据，考验解析和内存分配。
- 长连接空闲：建立大量 keep-alive 但不发请求，考验连接管理和超时回收。
只有把三种场景都跑过一遍，才能暴露不同类型的问题。很多新手只跑第一种，结果服务器在空闲连接一堆时照样崩溃。
6.2 文件描述符限制和内核参数
压测遇到过最尴尬的问题不是程序崩溃，而是"连不上"。查下来是进程的文件描述符限制太少。Linux 默认 ulimit -n 可能是 1024，也就是一个进程最多开 1024 个文件描述符。压测 1000 个连接就直接爆了。
需要调整两个地方：
- 用户态限制：
ulimit -n 1048576，或者写进 /etc/security/limits.conf。 - 系统全局限制：
/proc/sys/fs/file-max，这个一般默认够大，但也要确认。
此外还有几个内核参数对高并发服务器至关重要：
| 参数 | 作用 | 我的建议值 |
|---|---|---|
| net.ipv4.tcp_tw_reuse | 快速复用 TIME_WAIT 连接 | 1（客户端场景） |
| net.ipv4.tcp_fin_timeout | 减少 TIME_WAIT 等待时间 | 30 |
| net.core.somaxconn | listen 队列最大值 | 4096 |
| net.ipv4.tcp_max_syn_backlog | SYN 半连接队列 | 8192 |
调完这些参数后，我的服务器才能扛住 10 万连接的压测。如果不调，程序写得再对也没用，瓶颈在内核配置。
6.3 TCP_NODELAY 和缓冲区调优
还有一个很容易被忽略的优化是设置 TCP_NODELAY，也就是禁用 Nagle 算法。Nagle 算法会把小的数据包攒在一起发送，减少网络包数量，但对 HTTP 这种"发送完响应就想立刻收到下一个请求"的场景来说，它会把延迟拉高。
经典问题是：Nagle 算法的小包攒发和 TCP 延迟确认（Delayed ACK）互相等待，可能造成 40ms 的额外延迟。我的服务器在每条连接建立后立刻设置 TCP_NODELAY，压测数据立刻好看了不少。代价是网络包数量增加，但在局域网和现代网络上，低延迟更重要。
socket 读写缓冲区大小也需要调。默认的内核 socket 缓冲区是几十 KB，对于大响应场景来说偏小。我用 setsockopt 把 SO_SNDBUF 和 SO_RCVBUF 调大到了 256KB，同时注意不要让用户态缓冲区和内核缓冲区重复占用内存。这里要平衡：缓冲区太大，内存占用高；太小，又容易触发 EAGAIN，增加事件循环的唤醒次数。我最终在 64KB 到 256KB 之间做了多组对比，选了一个平衡点。
6.4 一次 502 的排查经历：别忽略用户态的数据回收
压测过程中遇到过"unexpected status 502 bad gateway"这个错误，一开始我以为是负载均衡器的问题，看了半天配置才发现，是我的服务器在处理完一个请求后没有释放读缓冲区，导致连接上累计了很多半解析的数据。客户端复用同一个连接发下一个请求时，解析器状态已经混乱，返回了错误响应，网关层读到非 2xx 或非 3xx 就报 502。
这个坑提醒我：HTTP keep-alive 下，一个连接会处理多个请求，解析器的状态必须在每个请求结束后干净地复位，缓冲区里残留的数据也必须正确保留（不能清空，因为可能已经粘了下一个请求的数据）。我在代码里加了一个"请求结束"的 token，把解析上下文重新初始化，但保留未消费的字节，问题才彻底消失。
排查方式上，我强烈建议先在本地用 nc 或 curl 手动发一连串请求复现。比如：
bash复制printf 'GET /a HTTP/1.1\r\nHost: x\r\n\r\nGET /b HTTP/1.1\r\nHost: x\r\n\r\n' | nc 127.0.0.1 8080
如果这两个请求只有一个成功，说明 keep-alive 下的状态复位有问题。这种问题在单请求压测下永远不会暴露，只有复现长连接连续请求才能发现。
7. 一些新手最容易忽略的细节和经验之谈
7.1 关闭连接：不只是 close 而已
连接关闭在 Reactor 模型里比想象中麻烦。直接 close 可能造成两个问题：
- 如果发送缓冲区还有数据没写完，close 会直接丢弃这些数据。
- 如果对方还有数据要发，close 会导致对方的写操作收到 ECONNRESET，而不是正常的 EOF。
规范的关闭流程应该是：先 shutdown(fd, SHUT_WR)，表示"我不会再发数据了"，然后等待对端关闭读方向。如果设置了 SO_LINGER 的 linger 选项，可以控制 close 时是立即返回还是等待数据发送完毕。我踩过的教训是：千万不要在 EPOLLHUP 事件里直接 close，一定要先判断发送缓冲区是否为空，为空才 close；不为空就等 EPOLLOUT 把数据发完再关。
7.2 事件循环里的耗时操作会把整个服务器拖垮
Reactor 模式最怕回调函数里出现阻塞操作。任何可能阻塞的调用，比如磁盘 IO、外部 API 请求、复杂的 JSON 序列化，都不应该直接写在事件回调里，否则一个慢请求就会阻塞整个 Reactor 线程，所有连接都跟着遭殃。
我的处理方式是建立了一个"业务线程池"，Reactor 线程只负责解析 HTTP 报文、写入 socket；一旦解析出完整请求，就把请求对象投递到线程池，线程池处理完再把响应结果通过一个队列送回对应的 Reactor 线程。这里同样用了 eventfd 来做跨线程唤醒，避免 Reactor 线程空等。
有人可能觉得这样会增加复杂度，但你要想清楚：Reactor 的目标是极高的 IO 并发能力，而业务逻辑是另一码事。Netty 之所以单独划分 worker 线程和业务线程，也是同样的道理。如果你非要在回调里做重活，那服务器的并发能力就名存实亡了。
7.3 可观测性：日志和监控从第一天就要设计
最后聊一个项目后期才补的教训。最开始我几乎没做日志，出问题时完全靠猜。后来我加了几个关键埋点：
- 每个连接的建立时间和关闭时间、关闭原因。
- 每个请求的解析耗时、业务处理耗时、发送耗时。
- 事件循环单次 epoll_wait 返回的事件数量，如果长期接近 MAX_EVENTS，说明事件堆积，需要关注。
这些指标用简单的计数器和环形缓冲实现，不依赖第三方监控系统。我在压测时就是因为看到"发送耗时"异常，才发现响应大文件时用户态缓冲区和内核缓冲区之间拷贝太多，后来改成 writev 发送多个缓冲区块，效率才上来。
日志输出也要注意性能。高并发下，每条请求打一条日志都可能压垮磁盘。我用的方案是异步日志：业务线程把日志字符串放进内存环形队列，一个专门的日志线程批量写入磁盘。这样日志写入不影响网络事件循环，压测时性能损耗从 10% 降到了 1% 以内。
7.4 最后分享一点个人体会
回头看，这个基于 Reactor 模式的 HTTP 服务器，从最初 700 多行的单线程版本，演进到后面主从 Reactor + 线程池 + 定时器 + 异步日志的完整实现，整个过程中我对网络编程的理解提升是巨大的。有些事情只有亲手做一遍才会真正明白：比如为什么 epoll 的事件要配合缓冲区状态来注册和注销，为什么连接关闭要照顾发送缓冲区，为什么 keep-alive 超时不能简单用系统默认参数。
如果你也想做类似的练手项目，我的建议是分阶段来：第一版不要一上来就追求主从 Reactor 多线程，先用单线程把 HTTP 报文解析和响应写完整；第二步再加上 keep-alive 和超时管理；第三步才是多线程化。每一步都能独立测试和压测，出了问题也容易定位。这样走下来，你会发现自己不仅学会了 Reactor 模式，更把整个 HTTP 服务器从 socket 到协议层再到并发控制的链路彻底打通了，这个收获比单纯看十篇八篇文章要大得多。