网络基础回顾：OSI模型与TCP/IP协议栈

做网络排障这么多年，我有个习惯——不管多复杂的问题，先回到基础。说白了，网络拥塞分析这件事，根基就在OSI模型和TCP/IP协议栈上。你连数据包怎么封装、怎么拆解都搞不清楚，那拥塞发生在哪一层、怎么定位，基本就是瞎猜。

今天咱们就把这块基础夯实了。别嫌简单，我见过太多老手在关键时刻栽在这些基础问题上。

OSI模型把网络通信分成七层。每一层只管自己的事，跟上下层通过接口沟通。这个设计理念，说白了就是“各司其职”。

层级	名称	典型协议/设备	排障关注点
7	应用层	HTTP、FTP、DNS	应用响应慢、超时
6	表示层	SSL/TLS、加密	证书问题、加密协商失败
5	会话层	NetBIOS、RPC	会话中断、认证失败
4	传输层	TCP、UDP	重传、窗口缩放、端口不通
3	网络层	IP、ICMP、路由器	路由环路、TTL超时、丢包
2	数据链路层	以太网、交换机、MAC	CRC错误、冲突、广播风暴
1	物理层	网线、光纤、信号	光衰、线缆损坏、接口松动

我个人习惯，遇到拥塞问题先问自己：问题出在哪一层？如果是应用卡顿，但ping正常，那大概率是7层或4层的问题。如果ping都丢包，那就要往下看3层或2层了。

我的经验：有一次客户说视频会议卡顿，我查了三天没头绪。最后发现是物理层的光模块光衰过大，导致间歇性丢包。嗯，从那以后我排障一定从物理层开始排查，哪怕只是看一眼接口指示灯。

OSI是理论模型，实际互联网用的是TCP/IP协议栈。它把七层压缩成四层：应用层、传输层、网络层、网络接口层。

为什么讲拥塞分析必须懂TCP/IP？因为拥塞控制机制就在传输层。TCP的慢启动、拥塞避免、快速重传、快速恢复——这些算法直接决定了网络在拥塞时的表现。

  核心要点：TCP拥塞控制的核心是“探测-反馈-调整”。发送方通过丢包或延迟信号感知拥塞，然后主动降低发送速率。这个机制既是网络稳定的保障，也是拥塞问题的根源之一。

你发一条消息，从应用层到物理层，每层都会加上自己的头部信息。这个过程叫封装。接收端反过来，一层层剥掉头部，叫解封装。

我画了一张图，帮你理解这个过程：

你想想看，每一层加头部，数据包就变大了。如果网络带宽有限，大包就容易造成拥塞。这就是为什么MTU（最大传输单元）这么重要——超过1500字节的包会被分片，分片本身就会增加拥塞风险。

注意：我曾经遇到一个案例，某应用频繁超时。抓包发现TCP分片太多，每个分片都要单独确认。一旦丢了一个分片，整个TCP流都要重传。最后把MTU从1500调到9000（开启巨帧），问题直接解决。但巨帧不是所有设备都支持，改之前一定要确认兼容。

做拥塞分析，你得有数据说话。四个核心指标：延迟、抖动、丢包、吞吐量。我一个个说。

延迟就是数据从A到B花的时间。单位通常是毫秒（ms）。

我个人习惯，先ping测RTT（往返时间）。如果RTT超过100ms，用户就能感知到卡顿。超过200ms，基本没法用了。

抖动是延迟的变化量。说白了，就是延迟忽高忽低。

为什么抖动比延迟更可怕？因为延迟高但稳定，应用可以自适应。抖动大，语音视频就会断断续续。我做过一个VoIP排障，平均延迟才30ms，但抖动高达50ms，通话质量一塌糊涂。

  计算公式：抖动 = |延迟(n) - 延迟(n-1)| 的平均值。一般要求抖动 < 30ms 才能保证实时通信质量。

丢包就是数据包在半路消失了。原因很多：线路噪声、缓冲区溢出、路由环路、设备故障。

TCP对丢包特别敏感。一旦丢包，发送方会触发拥塞控制，把发送窗口砍半。这就是为什么丢包率哪怕只有1%，TCP吞吐量可能下降50%以上。

吞吐量是单位时间内成功传输的数据量。单位是bps（比特每秒）。

这里有个坑：带宽和吞吐量不是一回事。带宽是理论最大值，吞吐量是实际能达到的值。拥塞发生时，吞吐量远低于带宽。

我的经验：测吞吐量别用ping，ping测的是延迟和丢包。用iPerf工具，它能准确测出TCP和UDP的吞吐量。我曾经帮一个客户排查“千兆网络只有200M”的问题，iPerf一跑发现是网卡协商成了百兆模式——物理层的问题。

好了，这一章的基础就这些。记住：没有扎实的基础，排障就是碰运气。下一章咱们会深入TCP拥塞控制的具体算法，到时候这些基础概念都会用上。