windows 上 netstat -ano
linux netstat -anp
TCP 的"三次握手"和"四次挥手"是网络通信中最经典的设计，也是面试必考题。既然你有编程基础，我把这两个过程背后的核心逻辑 拆解给你看，不仅仅是流程，更是为什么必须这样设计。
一、 三次握手（建立连接）
核心目的 ：防止历史重复连接请求造成资源浪费 ，并同步双方的初始序列号711。
1. 过程回顾（客户端 -> 服务器）
- 第一次 ：
SYN=1, seq=x（客户端说：我要连你，我的序号是x） - 第二次 ：
SYN=1, ACK=1, seq=y, ack=x+1（服务器说：收到，我也连你，我的序号是y，期待你下个发x+1） - 第三次 ：
ACK=1, seq=x+1, ack=y+1（客户端说：收到，期待你下个发y+1）
2. 为什么必须是三次？（关键）
问：为什么不能是两次？
这是最常问的。如果只有两次（客户端发SYN，服务器回SYN+ACK就结束）：
- 场景：客户端发了一个SYN，但网络拥堵了，迟迟没到。客户端等超时了，又发了一个新的SYN。
- 结果 ：后来网络通畅了，那个旧的、迟到的SYN突然到了服务器。
- 如果是两次握手：服务器以为是新请求，直接回一个SYN+ACK，连接就建立了！但客户端根本没发这个旧请求，不会理服务器。服务器就会白白浪费资源（半开连接）等待，甚至被攻击（SYN Flood）35。
- 三次握手的解决 ：服务器收到旧SYN后，虽然回了SYN+ACK，但客户端发现这不是我想要的连接，就不会发第三次ACK。服务器等一会没收到ACK，连接就自动断了24。
问：为什么不是四次？
因为第二次握手时，服务器的 SYN（同意连接）和 ACK（确认收到客户端请求）可以合并成一个包发出去3。既然能合并，就没必要拆成两次通信，三次是效率和安全的最优解17。
二、 四次挥手（断开连接）
核心目的 ：全双工通信的双向关闭，确保数据不丢失45。
1. 过程回顾（以客户端主动关闭为例）
- 第一次 ：
FIN=1, seq=u（客户端说：我发完了，要关这一头了） - 第二次 ：
ACK=1, seq=v, ack=u+1（服务器说：收到，我这边还剩点数据要发，你先等着） - 第三次 ：
FIN=1, seq=w, ack=u+1（服务器说：我也发完了，关我这头） - 第四次 ：
ACK=1, seq=u+1, ack=w+1（客户端说：收到，连接彻底断了）
2. 为什么必须是四次？（关键）
问：为什么断开要四次，不能像握手那样合并？
因为 TCP 是全双工的（就像双向车道）5。
- 双向独立 ：客户端说"我不发了"（FIN），只是关了客户端到服务器 的车道。但服务器到客户端的车道还是通的，服务器可能还有数据没发完。
- 不能合并的原因 ：服务器收到客户端的
FIN后，必须立刻回一个ACK（这是第二次挥手），告诉客户端"我知道你发完了"。但是，服务器不能立刻发FIN，因为它可能还在发数据给你。等服务器把剩下的数据发完了，才能发FIN（第三次挥手）45。 - 总结 ：因为ACK （确认收到关闭请求）和FIN（我也要关闭）通常不是同时发生的，所以必须分两次发，总共就是四次。
问：为什么要有 TIME_WAIT 状态（等待 2MSL）？
客户端发完最后一次ACK后，不能直接消失，要等一阵子。原因有两个：
- 防止丢包：如果最后一次ACK丢了，服务器会重传FIN。客户端等着，就能收到重传的FIN并回复ACK，确保服务器正常关闭9。
- 防止旧连接干扰：等待一段时间，让网络里所有属于这个连接的旧数据包都消失，避免它们干扰新建立的连接89。
总结对比表
表格
| 特性 | 三次握手 (建立) | 四次挥手 (断开) |
|---|---|---|
| 核心目的 | 同步序列号，防止旧连接干扰 | 双向关闭，确保数据不丢失 |
| 为什么是这个次数 | 两次不安全（资源浪费），四次多余 | 因为全双工，ACK和FIN通常不能合并 |
| 关键标志位 | SYN (同步), ACK (确认) |
FIN (结束), ACK (确认) |
| 类比 | 打电话："喂？""在711。""在。" | 挂电话："我说完了7。""好。""我也说完了。""好。" |