3.10 HTTP Server：一个差生的逆袭

学习目标

• 能沿监听连接、注册兴趣、等待就绪、非阻塞读写和更新兴趣五个节点解释 HTTP Server 的一次事件循环
• 能比较多进程、select 和 epoll 各自承担的隔离、扫描或就绪通知职责，并指出它们没有替应用完成的工作
• 能在正常、边界和故障场景中根据事件、描述符状态与复位轨迹定位阻塞读取或过期兴趣注册的首个偏离

3.10 HTTP Server：一个差生的逆袭

本页依据刘欣《码农翻身》（2018 年第 1 版）及出版社公开书目信息，独立重构 3.10 HTTP Server：一个差生的逆袭。正文、图示、实验和练习是本课程重新设计的教学材料，不复制原书正文、插图、练习答案或代码。

一个 HTTP 服务器最初可以把一个连接交给一个串行处理流程：读请求、算响应、写回去。连接一多，慢客户端就会占住执行机会。演进的关键不是把版本号背下来，而是逐步改变“谁等待、谁扫描、谁保存连接状态”：2.0 用多进程隔离连接，3.0 用 select 等待一组描述符，4.0 用 epoll 维护关注集合并返回就绪事件。

三个会让事件服务器失真的陷阱

五个目录节点到事件证据

3.10 HTTP Server：一个差生的逆袭

本章的总合同是：监听连接得到描述符，注册兴趣表达“我想关注什么”，等待就绪只返回当前可尝试的事件，非阻塞读写推进连接状态，更新兴趣决定下一轮继续关注读、写还是关闭。版本演进改变的是调度与观察方式，不改变 HTTP 请求必须按连接状态逐步消费的事实。

HTTP Server 1.0

HTTP Server 1.0 用一个串行处理流程服务一个连接：accept → read → handle → write → close。它容易验证，因为等待关系清楚；代价是一个慢连接会占用整个处理流程。这里的边界是“连接隔离”而不是“请求已经完整”。

HTTP Server 2.0：多进程

HTTP Server 2.0：多进程

HTTP Server 2.0：多进程 为连接分配独立的执行上下文。一个进程阻塞或退出时，其他连接仍有机会推进，但进程创建、描述符继承、共享监听和回收都成为新边界。多进程是隔离策略，不是事件通知机制。

HTTP Server 3.0：select模型

HTTP Server 3.0：select模型 把多个描述符放进待检查集合，每轮等待后扫描返回集合，应用再判断哪个连接可以读或写。它降低了“每连接一个阻塞流程”的耦合，却把集合扫描和描述符上限带进了成本模型。

HTTP Server 3.0：select模型

HTTP Server 4.0：epoll模型

HTTP Server 4.0：epoll模型 把关注集合交给内核维护，等待调用返回就绪事件数组；应用只处理这轮真正有变化的连接。它减少了每轮扫描全部描述符的工作，但仍要求非阻塞读写、缓冲区管理和兴趣更新。

HTTP Server 4.0：epoll模型

就绪与非阻塞边界

非阻塞读写

“可读”只回答“现在可以尝试读”，不回答“请求已经结束”。应用要把已读字节放进连接缓冲区，按协议判断是否足够，再决定继续关注读、切换关注写，或关闭连接。读到暂时没有更多数据时，应保存状态并返回事件循环；写不完时也要保留剩余响应。

Lab

HTTP Server 事件循环诊断实验

只改变请求到达或处理边界，观察就绪事件、连接缓冲和兴趣集合怎样变化。

重置实验

完整请求样本 1半包到达样本 2阻塞故障样本 3

两个连接都能在一次或多次非阻塞读后完成

listen → ready(fd2, fd3) → read buffers → write → remove interest

判定

accept：每个连接都推进，响应完成后兴趣被清理

当前样本：完整请求；保存连接 ID、返回事件、缓冲长度、兴趣集合和复位结果。

五步复核一次事件循环

⚡分步1 / 5

1. 1
2. 2
3. 3
4. 4
5. 5

重置

1. 监听连接并固定样本

记录连接 ID、描述符、客户端输入片段和当前版本。正常样本包含一个完整请求，边界样本把请求拆成两次到达，故障样本让客户端在首段数据后停住。

上一步播放下一步

正常、边界与故障证据矩阵

样本	只改变的变量	预期判定	必存证据
正常	两个连接都可完整读写	就绪事件逐个推进，响应完成后兴趣被更新	连接 ID、事件、已读/已写字节
边界	一个请求拆成两段到达	第一次只保存缓冲，不阻塞其他连接	两次就绪、缓冲长度、解析状态
故障	一个连接停在半包读取	事件循环继续服务其他连接，超时后回收	首个停顿、超时、关闭与复位轨迹

故障诊断：先找首个错误边界

1. 监听与注册：核对监听描述符、连接归属、注册事件和关闭时是否移除兴趣；重复注册或遗留关闭描述符会制造假象。
2. 等待与返回：比较等待前集合、select 的返回集合或 epoll 的事件数组；不要用上一次返回结果替代本轮状态。
3. 读写与协议：查非阻塞返回、已读字节、缓冲长度和协议解析状态；可读事件后卡住，首个偏离通常是错误的阻塞边界。
4. 更新与回收：查写兴趣是否在响应完成后取消，错误、超时和关闭是否释放连接状态；否则空转和描述符泄漏会把后续样本污染。

如果慢客户端让所有连接延迟上升，先复现“可读后阻塞读取完整请求”；如果 CPU 随连接数上升，比较 select 的集合扫描和 epoll 的就绪数组；如果关闭连接后仍收到事件，检查兴趣更新和描述符生命周期。每次只改变一个边界，再从干净状态重放。

术语与边界

本页四个术语分别绑定到实验中的连接状态、事件集合或控制按钮，不能只当作版本标签：

• HTTP Server 2.0：多进程：隔离连接执行上下文，代价是进程与资源管理。
• HTTP Server 3.0：select模型：每轮等待并扫描描述符集合，返回本轮可尝试集合。
• HTTP Server 4.0：epoll模型：维护关注集合并返回就绪事件，仍需应用推进协议状态。
• 非阻塞读写：I/O 暂时不可继续时立即返回并保存连接状态，不把事件循环锁在单连接上。

名词解释

本章出现的专业名词，用大白话再讲一遍。

HTTP Server 2.0：多进程

为连接分配独立执行上下文的隔离结构，必须配合描述符继承和资源回收。

HTTP Server 3.0：select模型

每轮把描述符集合交给内核等待并扫描返回集合的多路复用方式。

HTTP Server 4.0：epoll模型

维护关注集合并返回当前就绪事件的 Linux 多路复用方式。

非阻塞读写

I/O 暂时不能继续时立即返回，保存缓冲与连接状态后由事件循环稍后推进。

练习

练习

问题 1： 一个客户端只发送了半个 HTTP 请求，为什么 epoll 返回可读后不能直接循环读取直到请求结束？

查看答案

就绪只表示当前读调用可以尝试，不保证消息完整，也不保证下一次读仍有数据。应使用非阻塞读，把字节放入连接缓冲区；未满足协议边界就保存状态并返回事件循环，不能让一个慢客户端占住其他连接。

问题 2： 连接数增加后，select 的 CPU 开销明显上升，为什么换成 epoll 可能改善，改善的边界是什么？

查看答案

select 每轮需要处理传入集合并扫描描述符，连接很多但同时活跃的比例较低时，扫描成本会显得突出。epoll 维护关注集合并返回就绪事件，减少无效扫描；但应用仍要处理非阻塞读写、事件风暴、缓冲和兴趣更新，不能把 epoll 当作完整请求调度器。

问题 3： 修改实验，让一个连接在读半包后停顿；写出首个偏离、修复动作和重置后的四项证据。

查看答案

首个偏离是把可读事件误当成完整请求并进入阻塞读取。修复是改为非阻塞读取、保存解析状态并设置超时；重置后应恢复监听/连接集合、缓冲长度、事件轨迹和样本状态，随后同一输入得到基线判定。

本页小结

• 1.0 以串行处理换简单，2.0 以多进程隔离连接，3.0 用 select 扫描集合，4.0 用 epoll 返回就绪事件。
• 就绪不是完整请求；非阻塞读写、缓冲区和协议状态仍由应用负责。
• 诊断要保存注册集合、返回事件、读写进度、兴趣更新和复位结果，先找首个错误边界。

读完后的自测问题是：面对慢客户端、select 扫描成本或关闭连接后的幽灵事件，你能否指出最早偏离的节点，并证明修复后的轨迹可以从同一基线重放？