把一行标题做成能跑、能压、能上生产的服务器，中间要踩的坑，比想象中多得多。“基于 Reactor 模式的 HTTP 服务器”这个标题写起来很轻巧，真正动手你会发现，Reactor 只是骨架，HTTP 解析、连接复用、超时管理、缓冲区策略，每一块都能单独写三篇博客。这篇文章我会按我自己落地一个简单但完整的 Reactor HTTP 服务器的过程来讲，从模式选型到协议解析，再到压测和线上 502 排查，把真正花时间的地方都摊开说。
适合谁看？如果你正在学网络编程，或者工作中要维护网关、代理、长连接服务，又或者单纯好奇 Netty、Redis、Nginx 底层那套事件驱动到底怎么回事，这篇都能给你一个能落地的参照系。我不保证写得比教科书严谨，但保证里面提到的每个坑都是我自己填过的。
1. 为什么 HTTP 服务器要选 Reactor 模式
1.1 从“一连接一线程”说起
最早写网络服务的人大概都经历过这个阶段：accept 到一个 socket，就 new 一个线程去处理。简单直接，写起来很快，但撑到几百上千并发就开始难受。
问题出在线程本身。一个线程默认栈空间 8MB，哪怕你的业务逻辑再轻，操作系统也得为它维护完整的上下文。CPU 核数是有限的，线程一多，光是上下文切换就能吃掉一大半性能。更现实的是，大部分连接其实都在等待——等客户端发数据，等数据库中某条记录，等上游响应，线程大部分时间处于阻塞状态，资源白白占着。
在 HTTP 这种“请求-响应”模型里，这种浪费尤其明显。一个 Keep-Alive 连接可能几分钟内只有几次请求，剩下的时间全是空等。用线程池可以缓解，但线程池解决的是“线程数量”问题，解决不了“怎么知道哪个连接可读可写”的问题。
1.2 Reactor 的拆法：把“等待”这件事集中起来
Reactor 模式的核心思路，是把“等待 I/O 事件”这个动作从业务线程里剥离出来，交给一个专职的事件循环。
你不需要知道每个连接什么时候有数据来，你只需要告诉事件循环：“这个 fd 可读的时候叫我”。剩下的时间，你的代码可以去做别的事，或者干脆歇着。
类比一下：传统方式是每个顾客配一个服务员，顾客不点菜时服务员也得站着；Reactor 是门口只有一个叫号员，所有顾客在大厅等着，叫到号了才去对应窗口取餐。服务员（工作线程）只在真正有事可做的时候才出现。
这个模型落到 HTTP 服务器上，天然契合 HTTP 的两个特点：
- 请求是短时突发，空闲期长。事件驱动方式下，空闲连接几乎不占 CPU。
- 连接数量大。2 万、10 万个连接，在 Reactor 里只是 epoll 维护的一堆 fd，而不是 2 万个线程。
这也是为什么 Nginx、Netty、Redis 底层都是这套路。不是大家约好了用 Reacotr，而是面对高并发网络服务，这是目前实践下来最划算的方案。
1.3 单 Reactor、多 Reactor、主从 Reactor 怎么选
Reactor 本身也有好几个变体，选型直接影响后续扩展。
单 Reactor 单线程：事件循环和处理逻辑都在一个线程里。Redis 就是典型。好处是完全没有并发问题，所有操作串行化，写起来最省心。但前提是你的业务必须“快”，绝不能有阻塞操作。HTTP 服务器如果只是在内存里查点数据、拼个响应，单线程也能扛几万 QPS，但一旦要查数据库、调远程服务，这条路就堵死了。
单 Reactor 多线程：事件循环负责 I/O，读到完整请求后丢给工作线程池处理，处理完再扔回事件循环写响应。这是很多轻量 HTTP 框架的默认形态。难点在于请求和响应的对应关系要理清楚，以及工作线程返回时怎么把数据交还给正确的连接。我在实际做的时候用了一个自增 requestId 配合连接对象上的 pending 队列解决。
主从 Reactor：main reactor 只管 accept，然后把新连接注册到某个 sub reactor 上，每个 sub reactor 一个事件循环，各管一批连接。Netty 的 bossGroup / workerGroup 就是这个结构。这种形态的好处是能利用多核，多个事件循环并行跑，单个事件循环里的慢操作不会阻塞整个服务。
我的建议是，第一版直接做单 Reactor 多线程。理由很实在：先把 HTTP 解析、连接管理、业务分发跑通，等发现性能瓶颈在事件循环上了，再拆成主从也来得及。一上来就上主从，日志和问题排查的复杂度会翻倍。
2. HTTP 协议解析本质上是一个状态机问题
Reactor 只解决“什么时候有数据”的问题。数据来了之后怎么解析，是另一件头大的事。
2.1 请求行与头部解析：一次读不完整怎么办
HTTP 请求的头部是文本格式，逐行以 CRLF 分隔。第一行是请求行，比如GET /index.html HTTP/1.1，后面是若干 header 行，直到空行结束。
新手最容易犯的错，是假定一次 recv 就能读到完整请求头。实际上 TCP 是流协议，数据包什么时候到、分几段到，完全不可控。客户端可能只发了半个请求行网络就断了，也可能把请求头和请求体一次性全怼过来。
所以解析器必须做成增量式的。我的做法是给连接维护一个环形缓冲区，recv 到的数据先追加进去，然后驱动一个状态机消费：
enum ParseState { PARSE_REQUEST_LINE, // 解析请求行 PARSE_HEADERS, // 解析头部 PARSE_BODY, // 解析请求体 PARSE_DONE // 完整请求已就绪 };每次 recv 之后循环调用tryParse()，能解析多少算多少，状态推进到哪儿就记到哪儿，缓冲区里剩多少字节也原样保留。等到PARSE_DONE，才把整个请求对象交给业务层。这样不管网络包怎么拆分，都能正确处理。
状态机里还有一个容易忽略的点：请求行和 header 都有长度上限。如果不限制，恶意客户端可以持续发数据不换行，把你的内存吃光。我踩过这个坑之后给请求行设了 8KB、单个 header 设了 16KB、总头部上限 64KB，超出直接回 431。
2.2 Content-Length 和 chunked 编码：请求体怎么读
头部解析完之后，请求体怎么读取决于传输方式。这里有两个标准答案：
- 有
Content-Length头：读满这么多字节就算一个完整请求体。 - 使用
Transfer-Encoding: chunked：每一个分块前有一行十六进制长度，行尾 CRLF，读够该长度后再读 CRLF，遇到长度 0 的块说明结束。
chunked 的处理一定要小心。我在实现时犯过一个错误：在 chunk 扩展字段（chunk-ext）上想当然，直接用\r\n切分行再解析十六进制长度，结果遇到带扩展的 chunk 直接解析失败。后来老老实实按strtol只解析十六进制部分，遇到;就停，才算稳定。
这里还有一个跟 Reactor 结合的关键点：解析只能发生在“读事件”的上下文里，但一个请求可能跨多个读事件到来。我的做法是连接对象内部维护bodyReceived计数，每次解析完头部就把目标体长存下来，每次 recv 后累加，够了再置PARSE_DONE。逻辑上依然是状态机，只是多了个计数维度的判断。
2.3 Keep-Alive 连接复用：HTTP/1.1 的默认行为
HTTP/1.1 默认是持久连接。也就是说，同一个 TCP 连接上可以连续发多个请求。这既是好事也是坏事。
好的一面是省去了频繁三次握手和四次挥手的开销，尤其是 HTTPS，省下的是完整的 TLS 握手。坏的一面是，你的解析器必须能处理“一个 socket 上粘着多个请求”的情况。
最典型的粘包场景：客户端用同一个连接连续发两个 POST，中间没有任何停顿。如果解析完第一个请求后，你把缓冲区剩下的数据丢了，第二个请求就再也找不回来。正确做法是解析完一个请求后，不要急着清空缓冲区，而是继续尝试解析下一个，直到缓冲区数据不足以构成一个完整请求为止。
我在写这个逻辑时，把连接对象设计成“一次循环可处理多个请求”，但每个请求都限制处理时长。这样既能榨干连接复用带来的吞吐，又不会因为某个连接上请求太密集而饿死其他连接的事件。
2.4 连接状态机：把生命周期管起来
HTTP 连接在服务器侧是有明确生命周期的：从 accept 开始，到数据可读、可写，到超时或对端关闭，再到资源释放。这些状态如果用散落的 if-else 管理，后期必然乱。
我整理了这样一张状态表，写代码的时候挂在注释里，排查问题时对着看：
| 状态 | 触发条件 | 后续动作 |
|---|---|---|
| CONNECTED | accept 完成 | 注册读事件，启动读超时计时 |
| PARSING | 读事件触发，数据进入缓冲区 | 驱动解析状态机 |
| READY | 完整请求就绪 | 提交到工作线程池，暂停该连接读事件 |
| PROCESSING | 业务线程处理中 | 等待业务完成，超时计入监控 |
| RESPONDING | 响应数据开始写 | 注册写事件，边写边确认写缓冲 |
| KEEP_WAIT | 响应写完，连接可复用 | 重置解析状态，恢复读事件 |
| CLOSING | 出错、超时、对端关闭 | 删除事件，释放缓冲区，close fd |
这里有个容易被忽略的设计：当请求进入业务线程池处理后，我会先把对应连接的读事件从 epoll 里摘掉。原因是如果不摘，同一个连接上如果有新请求进来，会读到下一帧数据，而此时上一帧还在业务处理中，数据会混在一起。等业务处理完、响应写完，再重新挂上读事件，这时候再解析下一个请求就顺理成章了。
3. 关键代码实现与参数选择
这一节直接上核心代码。语言我用 C++ 风格的伪代码，重点是让你看懂结构，而不是纠结某一行语法。
3.1 事件循环骨架
事件循环是整个服务器的发动机。它的任务就三件：等事件、分发事件、处理定时任务。
void EventLoop::run() { while (!stop_) { // 1. 等待事件，超时时间取最近一个定时任务的剩余时间 int timeoutMs = timerQueue_->nextExpiredTime(); int n = epoll_wait(epfd_, events_, MAX_EVENTS, timeoutMs); // 2. 分发 I/O 事件 for (int i = 0; i < n; ++i) { Channel* ch = static_cast<Channel*>(events_[i].data.ptr); uint32_t revents = events_[i].events; ch->handleEvent(revents); } // 3. 处理到期定时器（超时检测、空闲连接清理） timerQueue_->processExpired(); } }timeoutMs的计算很关键。如果没有定时任务，就传 -1 阻塞等待；如果有，就传最近的超时差值。这样 epoll_wait 最长阻塞到下一个定时任务到期，不会因为“没有网络事件”就睡死过去，也不会频繁空转。
事件分发这里我没有用 epoll 的 level-trigger 而是用了 edge-trigger，加上 EPOLLONESHOT。原因很实际：LT 模式下只要缓冲区有数据就会一直触发，多线程处理时容易重复唤醒；ET + ONESHOT 保证每个事件只触发一次，处理完手动重置，避免一个连接被多个线程同时处理。
3.2 非阻塞读写与缓冲区管理
所有 socket 必须设成非阻塞，否则一个慢客户端就能堵住整个事件循环。
void Connection::onReadable() { char tmp[65536]; for (;;) { ssize_t n = recv(fd_, tmp, sizeof(tmp), 0); if (n > 0) { inputBuffer_.append(tmp, n); totalReceived_ += n; lastActive_ = now(); if (inputBuffer_.size() >= MAX_BUFFER_SIZE) { // 防止缓冲区无限增长 sendErrorAndClose(413); return; } } else if (n == 0) { // 对端关闭 handleClose(); return; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) { break; // 读完了 } handleError(errno); return; } } // 数据已入缓冲，驱动状态机 parseAndDispatch(); }缓冲区管理这里，我踩过的坑是“读完立刻处理”和“数据没读完就开业务线程”之间的平衡。我的做法是每轮最多读取 64KB 进缓冲，然后立刻尝试解析；解析成功才提交业务，不给工作线程单独分配新内存，直接传递连接对象引用，业务侧只读输入缓冲。
写方向同样要注意。响应体大的时候，一次 send 是发不完的，得等可写事件。我的输出缓冲区设计成链表式的分段结构，每次只 attempt 发送，发不完就把剩余部分挂到连接上，等下一次可写事件继续。这个“写半包”的问题我在 3.4 节专门讲。
3.3 超时与空闲连接清理
服务器必须能处理“客户端连上不说话”的情况。否则恶意或者故障的连接会永远占着 fd 和内存。
我在 EventLoop 里维护了一个最小堆定时器，每个连接注册时插入一个超时节点，默认 60 秒。每次读事件触发时刷新节点时间，业务处理超时单独记。
void TimeoutManager::processExpired() { auto now = steady_clock::now(); while (!heap_.empty() && heap_.top().expireTime <= now) { auto id = heap_.top().id; if (auto conn = connections_[id].lock()) { if (conn->lastActive() + kKeepAliveTimeout < now) { conn->close("idle timeout"); } } heap_.pop(); } }注意，定时器节点不能只靠“到点检查”，因为连接可能提前关闭，堆里会留下失效节点。我的处理是：节点里记录连接对象的弱引用和连接自增 ID，取出来之后先验证是否还存在、是否还是同一个连接（重连后 fd 可能被复用），验证过了再判断超时，避免误杀新连接。
超时值的选择也讲究。设太短，正常的慢客户端会被频繁踢掉；设太长，空闲连接占着资源不减。我一般把空闲连接超时设在 60~75 秒，跟 Nginx 的 keepalive_timeout 对齐，前端有反向代理时不容易出现代理断了、源站还在等的尴尬场景。
3.4 响应发送与写半包问题
很多新手把 HTTP 响应当成一个可以一次 send 完的数据块，实际不是。
假设你要返回一个 10MB 的文件。socket 发送缓冲区可能只有几十 KB，一次 send 根本放不下，返回值会小于你要发的总长度。此时必须把剩余数据挂到写缓冲区，注册 EPOLLOUT 事件，等缓冲可写时继续发。
void Connection::sendResponse(const std::string& data) { ssize_t n = send(fd_, data.data(), data.size(), MSG_NOSIGNAL); if (n < 0) { if (errno == EAGAIN || errno == EWOULDBLOCK) { writeBuffer_.append(data); // 全部缓存 enableWriting(); // 等可写事件 } else { handleError(errno); } return; } if (n < (ssize_t)data.size()) { writeBuffer_.append(data.data() + n, data.size() - n); enableWriting(); } }写完一次后，还要在onWritable()里继续尝试发送 writeBuffer_ 里的剩余数据，直到发空才关闭写事件。
另一个细节：客户端可能已经断开，但 OS 还没通知你。此时 send 会成功（数据进了内核缓冲）不用慌，下次读事件会触发 EOF。或者更激进一点，可以在 send 返回 EPIPE 或者 n == -1 时立刻标记连接关闭。这里给 send 加了MSG_NOSIGNAL，否则进程直接收到 SIGPIPE 默认终止，线上事故就是这么来的。
4. 常见问题与排查技巧实录
这一节是我最想写的，因为网上讲 Reactor 原理的文章一抓一大把，但实战里踩的坑很少有人说清楚。
4.1 502 Bad Gateway 的真相
如果你把这个 HTTP 服务器作为反向代理的后端，或者你自己在它前面挂了 Nginx，那 502 一定不陌生。我排查过多次 502，绝大多数原因不是业务代码崩溃，而是这几个：
- 后端主动关闭了空闲连接。代理层和源站之间如果有 keepalive，但源站的超时时间比代理短，代理再复用连接时，源站已经悄悄关了。此时代理把请求发过去，读到的是 RST，直接抛 502。
- 并发太高，事件循环处理不过来，响应迟迟没写完，代理那边先超时了。
- 进程 per-connection 内存增长失控，OOM 被系统杀掉，代理立刻报上游失联。
对应解法也很明确：连接空闲超时不要设得比代理短，最好比代理的 keepalive_timeout 略长；事件循环里的耗时不归控制住；每轮读事件设置次数上限，避免单个大流量连接饿死其他连接。
4.2 连接复用导致串包和解析错乱
连接复用的代码写好后，很容易出现一种诡异的 bug：连续请求时，偶尔第一个请求正常，第二个请求解析出来 URL 和 header 错位。
这种问题大概率是“上一个请求的残留数据没清干净”。比如 parse 到一半时发现读事件归零，你误以为请求结束，把缓冲清了；或者解析完成后，缓冲里还残留着下一个请求的字节，你却把它当作当前请求体的一部分。
排查方法很笨但有效：在解析器入口加一个打印，输出每次 recv 的字节数和缓冲区剩余字节数，然后拿一款 HTTP 客户端做连续请求压测，对比每个请求边界处的缓冲状态。我当时发现问题是请求体解析完没有把\r\n之后的残留正确保留，明明还有 14 字节，我却在PARSE_DONE分支直接buffer.clear()了。改成只消费已使用的长度后，串包消失。
4.3 高并发下的惊群与负载不均
单 Reactor 多线程模式跑多进程时，如果每个进程都监听同一个 listen fd，accept 时会出现惊群：一个连接到达，多个进程被唤醒，只有一个能 accept 成功，其他白白空转。
Linux 4.5 之后的内核用EPOLLEXCLUSIVE可以缓解，或者在用户层做一把全局锁 + 轮询分发。更常见的做法是改成主从 Reactor，一个进程单独 accept，然后通过 socketpair 或 unix domain socket 把新连接的 fd 传给工作进程。
不想搞那么复杂的，还有一个土办法：每个工作进程监听不同的端口，前面加一层软件负载均衡或者直接多个 IP 做 DNS 轮询。简单但有效，缺点是运维负担上来了。
4.4 压测表现差的几个隐藏因素
用 wrk 压测自家服务器，发现 QPS 上不去，先去查这几个点：
- 是不是每请求都 new/delete 了连接对象和缓冲区。高频分配在压测下会放大 GC/内存碎片问题。我用的是对象池 + 固定容量缓冲，效果立竿见影。
- 是不是事件循环里做了日志打印。每次 recv 打一条日志，压测时磁盘 I/O 立刻变成瓶颈。生产日志切成采样模式或者只打异常。
- 是不是 accept 循环没做限流。压测时如果一秒钟几万连接进来，accept 本身也会占 CPU，我的做法是每轮最多 accept 1024 个，剩余留给下一轮，避免单轮卡死。
- 是不是响应头固定重复拼接导致内存拷贝过多。HTTP 头用缓存好的模板字符串，只替换 Content-Length 等动态字段，比每次 snprintf 拼整段快很多。
4.5 常见问题速查表
| 现象 | 可能原因 | 处理方案 |
|---|---|---|
| 压测几万连接进来后 CPU 飙高 | accept 循环无上限/日志过多 | 限制每轮 accept 次数，关闭 debug 日志 |
| 偶发请求解析错乱 | 请求体残留未清、粘包处理错误 | 检查 PARSE_DONE 后缓冲区处理 |
| 客户端频繁断开，代理报 502 | 空闲超时设置太短 | 对齐代理 keepalive_timeout，设置略长 |
| 进程被 SIGPIPE 杀死 | send 到已关闭连接 | 给 send 加 MSG_NOSIGNAL |
| 内存持续增长 | 缓冲区无上限、连接对象未释放 | 加 MAX_BUFFER_SIZE，定时器兜底清理 |
| 多个进程 accept 惊群 | 多进程共享 listen fd | 使用 EPOLLEXCLUSIVE 或 accept 分发 |
| 响应内容偶尔被截断 | 写半包未处理 | 实现完整写缓冲 + EPOLLOUT 驱动 |
排查顺序上，我习惯先看系统层（fd 数、内存、CPU、上下文切换），再看应用层（连接状态分布、缓冲剩余字节、超时触发频率），最后才看业务层。别一上来就怀疑业务代码，网络编程的 bug 多半是连接和缓冲管理的问题。
5. 经验沉淀与后续扩展
说句实话，这个项目做完之后，我最大的收获不是“我会写 Reactor 了”，而是理解了为什么每个成熟框架都不让你直接接触底层 epoll。Netty 帮你管好了连接生命周期、内存池、拆包粘包、超时重试，你在业务里感受到的“方便”，都是别人把坑填平了的结果。
几个可以继续动手的方向，我建议按这个顺序来：
- 先压测，用 wrk 或 ab 跑不同并发，记录 QPS、延迟分位数和连接数曲线，找到当前实现的瓶颈。
- 再加 HTTPS，在事件循环外封装一层 TLS 读写，重点处理非阻塞握手和 renegotiation 的状态管理。
- 然后加 HTTP/2，多路复用会把连接状态机从“一连接一请求串行”变成“一连接多流并发”，对连接管理是另一个量级的挑战。
- 最后可以试试把静态文件发送改用 sendfile 和零拷贝，对比 CPU 占用率的差异。
我个人在调试这个项目的过程中，最值钱的一条经验是：网络服务的问题，几乎都能在“连接状态 + 缓冲状态 + 事件循环占用”这三件事里找到答案。日志里不要只打业务信息，要打 fd、连接 ID、缓冲区字节数、事件循环耗时。把这些信息结构化地打出来，以后线上出问题，你的第一反应不再是猜，而是直接看图说话。
