HTTP请求生命周期即TCP连接从建立到释放的全过程，涵盖11个状态：LISTEN→SYN_SENT→SYN_RCVD→ESTABLISHED→FIN_WAIT1→CLOSE_WAIT→FIN_WAIT2→LAST_ACK→TIME_WAIT→CLOSED，其中ESTABLISHED为唯一数据交互状态。
一个 HTTP 请求的完整生命周期，本质是底层 TCP 连接从建立到释放的全过程。它不始于“收到 URL”，而始于操作系统内核中一个 TCP 状态机的启动；也不止于“浏览器显示页面”，而终于双方状态归零、资源彻底回收。这 11 个 TCP 状态，就是这个生命周期的精确刻度。
TCP 连接建立：三次握手的三步落点
服务端启动后调用 listen()，进入 LISTEN 状态——这是整个生命周期的守门人，只等 SYN 报文敲门。
客户端发起请求时调用 connect()，发出 SYN 并立刻变为 SYN_SENT；
服务端收到后回复 SYN+ACK，状态跃迁为 SYN_RCVD；
客户端确认 ACK 后，双方同时进入 ESTABLISHED——此时连接真正就绪，应用层才开始读取请求、解析 HTTP 头、执行业务逻辑。
数据交互阶段：ESTABLISHED 是唯一“干活”的状态
所有真正的请求接收、响应生成、数据发送，都发生在 ESTABLISHED 状态下。这个状态没有子阶段，但它是全双工通信的舞台：
→ 应用层调用 recv() 从内核缓冲区取请求数据
→ 服务器处理并调用 send() 将响应写入发送缓冲区
→ TCP 协议栈负责分段、编号、重传、滑动窗口控制
→ 数据经网卡发出，对方按序组装、确认
只要双方都保持 ESTABLISHED，通信就持续进行。任何异常（如超时、RST 包）都可能触发向错误状态迁移。
连接关闭：四次挥手与五个关键状态
HTTP/1.1 默认复用连接，但一次请求-响应完成后，若决定关闭，则进入终止流程：
• 客户端先发 FIN，进入 FIN_WAIT1
• 服务端回 ACK，进入 CLOSE_WAIT（注意：此时服务端应用层仍可发数据）
• 客户端收到 ACK，进入 FIN_WAIT2
• 服务端发完剩余数据后也发 FIN，进入 LAST_ACK
• 客户端回最后一个 ACK，进入 TIME_WAIT（必须等待 2MSL，防止旧包干扰新连接）
服务端收到 ACK 后直接转为 CLOSED；客户端在 2MSL 超时后也进入 CLOSED。
容易被忽略的两个边缘状态
CLOSING：极少见，发生在客户端已发 FIN、尚未收到服务端 ACK，却意外收到服务端 FIN 时。说明 ACK 丢包且服务端已提前关闭——属于网络异常下的容错路径。
CLOSED 不是“空闲态”，而是初始态和终态：进程刚创建 socket 时是 CLOSED，连接彻底释放后也回到 CLOSED。它不参与任何数据收发，仅作为状态机的起点与终点锚点。
