一、网络基础与瓶颈概述

大家好，我是老张。做网络性能优化这行十几年了，今天咱们聊聊最基础、也最容易被忽视的东西——网络模型和性能指标。

很多人一上来就抓包、调参数，结果折腾半天发现瓶颈根本不在网络上。嗯，我见过太多这样的案例了。所以这一章，我们先打好地基。

这两个模型，说白了就是网络通信的「分工手册」。你想想看，数据从一台机器传到另一台，中间要经过多少环节？从物理信号到应用数据，每一层都有自己的职责。

OSI七层模型（理论上的完美方案）：

TCP/IP四层模型（实际干活用的）：

我个人习惯：排查问题时，从应用层往下查。先看应用日志，再看传输层有没有丢包，最后查物理链路。这样效率最高。

下面这张图，是我自己画的一个对比结构，帮你快速理解两个模型的关系：

避坑指南：我曾经遇到一个项目，应用层响应慢，团队在应用代码里找了两天bug。最后发现是物理层的光模块坏了，光衰太大导致频繁重传。所以别只盯着上层，底层问题也会往上冒。

做性能优化，你得先知道「好」的标准是什么。我一般看四个指标：

指标	定义	单位	我的经验值
带宽	链路的最大传输速率	bps（比特每秒）	千兆网理论125MB/s，实际跑满80%就不错了
延迟	数据从源到目的的时间	ms（毫秒）	同机房<1ms，同城<10ms，跨省<50ms
吞吐量	实际传输的数据量	bps 或 pps	小包场景看pps，大包场景看bps
抖动	延迟的变化程度	ms	实时音视频要求抖动<30ms

带宽 vs 吞吐量：这两个最容易搞混。带宽是「路有多宽」，吞吐量是「实际跑了多少车」。你想想看，一条八车道高速，如果堵车了，吞吐量可能还不如两车道。

我建议：监控吞吐量时，一定要同时看带宽利用率。利用率超过70%就要警惕了，超过90%基本就是瓶颈。

网络出问题，原因往往不在网络本身。我把它分成四类：

CPU处理不过来网络包了。表现是软中断（softirq）占用高，或者用户态进程CPU跑满。

我曾经调过一个Web服务器，CPU软中断占了60%。查了半天发现是网卡队列没开多队列，所有流量挤在一个CPU核心上。开了RSS（Receive Side Scaling）后，软中断分散到8个核，问题解决。

内存不够用，或者内存带宽不够。表现是频繁swap、OOM killer、或者内存带宽跑满。

这是最直接的——网卡扛不住了。表现是丢包、错包、或者网卡队列溢出。

很多人忽略这个。磁盘慢，会导致应用层等待，进而影响网络吞吐。

注意：磁盘IO瓶颈经常被误判为网络瓶颈。我见过一个案例，NFS挂载的存储磁盘满了，应用层读写卡住，结果网络监控显示连接堆积。其实根因在磁盘，不在网络。

好了，这一章的基础就这些。记住一句话：网络性能优化，先看模型，再量指标，最后定位瓶颈类型。别一上来就调参数，那是瞎忙活。

核心总结：