📄 一句话概括
断开用 FIN 互告——谁先说完谁先关，四个报文各表【我说完了】与【知道了】。
📝 本节和前面几节的关系
响应收完，管道完成使命；本篇看拆管的报文账。
一、四次往来
服务器发 FIN（我说完了）→ 客户端 ACK（知道了）→ 客户端发 FIN（我也完了）→ 服务器 ACK（知道了）。 比握手多一次：两边要各说一次完事。
二、Web 的节奏
HTTP/1.1 的典型连接是【请求-响应-断开】短连接； 长连接（keep-alive）只是把断开推迟到多轮之后。
三、动手 Demo：断开的报文流
四个报文收尾：
for s in ['服务器 -> 客户端 FIN （我说完了）',
'客户端 -> 服务器 ACK （知道了）',
'客户端 -> 服务器 FIN （我也完了）',
'服务器 -> 客户端 ACK （知道了）']:
print(s)
实跑输出：
--------------------------------------------------------------------
断开的报文流
--------------------------------------------------------------------
服务器先关（响应发完了）：
服务器 -> 客户端 FIN （我说完了）
客户端 -> 服务器 ACK （知道了）
客户端 -> 服务器 FIN （我也完了）
服务器 -> 客户端 ACK （知道了）
共 4 次往来——比连接多一次，因为两边要各说一次完事。
⭐ 2026 现状：HTTP/2、HTTP/3 的连接生命周期更长， 短连接已不是主流——四次挥手机制不变。
30 秒实验
- Wireshark 过滤 tcp.flags.fin==1 抓一次断开。
- curl 访问时观察连接是保持还是立即关闭。
- 想想为什么 FIN 与 ACK 不能像握手那样合包。
常见误区
- 以为断开一个 FIN 就够——两边各一轮。
- 以为断开即资源全还——还有等待期（下节）。
自测三问（点开对答案）
1. 断开共几个报文？ —— 四个（双方各 FIN＋ACK）。 2. 谁先发 FIN？ —— 先说完数据的一方（典型是服务器）。 3. 为什么比握手多一次？ —— 两方要分别声明结束。- ☐ 下一节（2.4.2 删除套接字）
相关笔记
- 连接操作的实际过程 — 一头一尾相呼应
- 删除套接字 —— 资源的最后归宿
- 🔌 网络是怎样连接的 · 索引