1. 网络基础回顾：OSI模型与TCP/IP协议栈、TCP三次握手与四次挥手、IP分片与MTU
做网络排障这么多年，我越来越觉得一个道理——基础不牢，地动山摇。很多重传和丢包问题，追根溯源，都出在大家对网络基础的理解不够扎实。今天咱们就把这些地基重新夯实一遍。
1.1 OSI模型与TCP/IP协议栈
OSI七层模型，说实话，在实际工作中很少有人会逐层去背。但它的分层思想，是理解网络通信的灵魂。
核心观点：OSI是理论模型，TCP/IP是实战模型。你抓包看到的，基本都是TCP/IP协议栈的产物。
我个人习惯把这两者结合起来记：
| OSI七层 | TCP/IP四层 | Wireshark中常见协议 | 核心作用 |
|---|---|---|---|
| 应用层 | 应用层 | HTTP, DNS, TLS | 为用户提供网络服务 |
| 表示层 | SSL/TLS加密 | 数据格式转换、加密 | |
| 会话层 | SOCKS, RPC | 建立/管理会话 | |
| 传输层 | 传输层 | TCP, UDP | 端到端可靠传输 |
| 网络层 | 网络层 | IP, ICMP | 路由寻址与转发 |
| 数据链路层 | 网络接口层 | Ethernet, ARP | 帧封装、MAC寻址 |
| 物理层 | 网线、光模块 | 比特流传输 |
我的经验：抓包分析时，我通常只看TCP/IP四层模型。但遇到诡异的丢包问题，我会回到OSI模型去排查——比如物理层的网线松动、数据链路层的MAC地址冲突，这些在Wireshark里往往表现为“莫名其妙的丢包”。
说白了，OSI模型是教科书，TCP/IP协议栈是实战手册。你抓包看到的每一个数据包，都是TCP/IP协议栈的产物。
1.2 TCP三次握手与四次挥手
这是面试必考题，也是排障基本功。我见过太多人把状态机背得滚瓜烂熟，但一抓包就懵了。
三次握手：建立连接
为什么是三次？不是两次，也不是四次？
嗯，这里要注意——三次握手的核心目的是确认双方的收发能力都正常。
- 第一次握手（SYN）：客户端发送SYN包，告诉服务器“我要连你”。此时客户端状态变为
SYN_SENT。 - 第二次握手（SYN+ACK）：服务器回复SYN+ACK，表示“收到，我也准备好连你”。服务器状态变为
SYN_RCVD。 - 第三次握手（ACK）：客户端发送ACK，表示“确认收到，开始传数据”。双方进入
ESTABLISHED状态。
我曾经踩过的坑：有一次线上服务响应慢，我抓包发现大量TCP Retransmission。排查了半天，发现是客户端发完SYN后，服务器回了SYN+ACK，但客户端的ACK丢了。服务器一直在等ACK，客户端以为连接已建立，开始发数据——结果全被重传了。这就是典型的半连接问题。
四次挥手：断开连接
挥手比握手多一次，因为TCP是全双工的，每一端都需要独立关闭。
- 第一次挥手（FIN）：主动方发送FIN，表示“我这边没数据要发了”。
- 第二次挥手（ACK）：被动方回复ACK，表示“收到，但我还有数据要发”。
- 第三次挥手（FIN）：被动方数据发完，发送FIN，表示“我也没数据了”。
- 第四次挥手（ACK）：主动方回复ACK，进入
TIME_WAIT状态，等待2MSL后关闭。
关键点：TIME_WAIT状态持续2MSL（约1-4分钟），是为了确保最后一个ACK能被对方收到。如果ACK丢了，被动方会重发FIN。
你想想看，如果只有三次挥手，被动方把ACK和FIN合并发送，那主动方怎么知道被动方还有没有数据要发？所以四次挥手是必须的。
1.3 IP分片与MTU
这是重传和丢包的重灾区。很多网络问题，表面上看是TCP重传，根因其实是IP分片导致的。
MTU是什么？
MTU（Maximum Transmission Unit）是数据链路层能承载的最大数据帧大小。以太网的MTU通常是1500字节。
如果IP层要发送的数据包超过MTU，就需要分片。
我的习惯：排查丢包问题时，我第一件事就是检查路径MTU。用ping -M do -s 1472（Linux）或ping -f -l 1472（Windows）测试，看有没有分片或丢包。
IP分片的过程
假设你要发送一个3000字节的IP数据包，MTU是1500字节：
- 原始包：IP头(20字节) + 数据(2980字节) = 3000字节
- 分片1：IP头(20字节) + 数据(1480字节) = 1500字节（MF=1, Offset=0）
- 分片2：IP头(20字节) + 数据(1480字节) = 1500字节（MF=1, Offset=185）
- 分片3：IP头(20字节) + 数据(20字节) = 40字节（MF=0, Offset=370）
注意，分片只在源端或路由器进行，重组只在目的端进行。
我曾经遇到的坑：有一次客户反馈文件传输慢，抓包发现大量TCP Retransmission和IP Fragmentation。排查后发现，中间有个VPN设备的MTU设置成了1400，导致大量分片。更坑的是，有些分片在传输过程中丢了，整个数据包都得重传——性能直接崩了。
MTU与TCP MSS的关系
为了避免IP分片，TCP在建立连接时会协商MSS（Maximum Segment Size）。MSS = MTU - IP头(20) - TCP头(20)。
以太网环境下，MSS通常是1460字节（1500 - 20 - 20）。
核心原则：TCP层发送的数据段大小，不能超过MSS。这样IP层就不需要分片了。
但问题来了——如果路径上的某个路由器MTU更小呢？比如从1500跳到了1400？
这时候，如果IP包设置了DF（Don't Fragment）标志，路由器会丢弃这个包，并返回ICMP消息“Fragmentation Needed”。如果防火墙把ICMP过滤了，发送端就永远不知道MTU变小了——这就是PMTUD黑洞问题。
1.4 本章知识体系
下面这张图，是我梳理的本章知识脉络。建议你保存下来，后面分析重传和丢包时，随时回来对照。