linux tcp连接的建立与释放是状态机驱动的可靠通信机制：三次握手确保双向同步序列号并验证收发能力，四次挥手因全双工特性需独立关闭双方向数据流；syn/fin消耗序号，isn须随机；各状态异常对应具体运维问题。
Linux 下 TCP 连接的建立与释放，本质是状态机驱动的可靠通信保障机制。三次握手不是为了“走流程”，而是为双向同步初始序列号、验证双方收发能力、防止历史失效请求干扰；四次挥手则源于全双工连接需独立关闭两个方向的数据流。理解它，关键不在背步骤，而在懂每个报文背后的意图和状态变迁逻辑。
三次握手：为什么必须是三次？
一次握手只能单向发起，两次无法确认服务端的发送能力——客户端发 SYN 后，服务端回 ACK，看似连通，但客户端无从知道服务端的 ACK 是否真的发出或被自己收到；若此时服务端已分配资源却等不到后续数据，就会造成资源泄漏。
三次握手真正解决的是：双方各自确认对方的“能收”和“能发”：
- 第一次（SYN）：客户端告诉服务端“我想连，我的起始序号是 X”，进入 SYN_SENT
- 第二次（SYN+ACK）：服务端回应“我收到了（ack=X+1），我也准备好了（seq=Y），我的起始序号是 Y”，进入 SYN_RCVD
- 第三次（ACK）：客户端确认“我收到你的 Y，现在我确认你也能收（ack=Y+1）”，双方进入 ESTABLISHED
注意：SYN 和 FIN 都消耗一个序列号，而纯 ACK 不消耗；初始序列号（ISN）必须随机生成，防止序列号预测攻击。
四次挥手：为何不能合并成三次？
TCP 是全双工协议，连接两端可同时收发数据。断开时，每一端都需独立声明“我发完了”，再确认“你确实不发了”。这导致关闭过程天然不对称：
- 主动方（如客户端）发 FIN，进入 FIN_WAIT1，表示“我数据发完了”
- 被动方（服务器）回 ACK，进入 CLOSE_WAIT，表示“我收到你不发了”，但自己可能还有数据要发
- 被动方发完剩余数据后，再发自己的 FIN，进入 LAST_ACK
- 主动方回 ACK，进入 TIME_WAIT，等待 2MSL 后彻底关闭
第二步和第三步不能合并，因为服务器在收到第一个 FIN 后，未必立刻准备好关闭——它可能正处理最后一批响应数据。强行合并会破坏可靠性。
关键状态与常见问题定位
实际运维中，这些状态异常往往指向具体问题：
- SYN_RECV 过多：可能是 SYN Flood 攻击，或服务端 accept 队列满（检查 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog）
- CLOSE_WAIT 大量堆积：通常是应用层未正确调用 close() 或 shutdown()，导致连接卡在被动关闭侧，资源无法释放
- TIME_WAIT 占用高：属正常现象（保证旧连接报文在网络中消亡），但若影响新连接，可调优 net.ipv4.tcp_tw_reuse（仅客户端适用）和 net.ipv4.tcp_fin_timeout
用 ss -tan state time-wait 或 netstat -ant | grep TIME_WAIT 可快速统计当前连接状态分布。
底层实现与 socket 编程映射
三次握手与四次挥手并非内核黑盒，它直接对应 socket API 的行为：
- 客户端调用 connect() → 触发 SYN 发送，进入 SYN_SENT
- 服务端调用 listen() 后，内核维护半连接队列（SYN queue）和全连接队列（accept queue）
- 调用 accept() → 从全连接队列取已建立的连接，返回新 socket，此时双方已是 ESTABLISHED
- 调用 close() → 默认触发四次挥手；若先调用 shutdown(SHUT_WR)，则立即发送 FIN
注意：close() 对 socket 引用计数减一，仅当计数为 0 才真正发起挥手；而 shutdown() 直接操作连接状态，不受引用计数影响。
