本页目录
网络慢，先别急着把锅扔给链路
第 10 章先拦住一个特别伤人的误判：只看本端现象，就直接宣布网络根因。
网络相关症状，至少可能落在这几层：
- 应用本身处理慢
- 本端主机排队或网络栈有问题
- 中间链路有丢包、拥塞或抖动
- 对端主机或对端应用处理慢
只看单边证据，根本分不清这些位置。
先把网络时间拆开
以后看网络问题，先按这个顺序拆：
1. 先分应用时间和网络时间
TTFB、请求总时长、超时，里面经常混着应用处理时间，不是纯网络时间。
别拿 TTFB 直接给网络定罪：它不仅包含网络传输时间，还死死绑定着目标服务器的 CPU 调度和应用处理时间。TTFB 飙高，很多时候更像对端应用卡了，而不是中间链路慢了。
2. 再分本端、链路、对端
重传、RTT、丢包、队列和应用日志，要尽量两边对起来看。
3. 再分偶发抖动和持续退化
这关系到你后面该看拥塞、配置问题，还是流量尖峰和队列。
4. 最后才判断哪一边最先形成约束
真正要找的，不是“哪里也慢”，而是“哪一边最早先开始等”。
别拿单边重传、超时和 TTFB 直接说链路有问题
最常见的错法有四种：
- 看到重传，就直接说链路有问题
- 看到 TTFB 变差，就直接说网络变慢
- 只看客户端，不看服务端
- 把端点主机排队、应用处理和链路问题混成一个结论
这些错法都缺一层对照。
什么时候更像主机或应用，不像外部网络
下面这些情况，更像端点主机或应用在制造表象：
- 本端排队和 CPU 等待同步变坏
- 服务端应用处理时间一起变长
- 只有单边有症状，另一边对不上
- 同机其他流量正常，只有特定请求慢
这时候先别急着认链路，先把端点主机和应用侧拆干净。
一个最典型的错法：只拿到客户端超时就宣布网络故障
现场里最常见的说法就是“客户端都超时了，肯定是网络”。
但这个结论中间至少还差三步：
- 服务端是不是先慢了
- 本端主机是不是先排队了
- 另一端有没有对应症状
如果这些都没对上，单边超时最多只能算症状。
到现场怎么把网络问题拆开
第 10 章真正缺的不是“网络会骗人”这个提醒，而是你拿到超时、重传、TTFB 变差以后，第一轮到底按什么顺序做。
第一步：先挑一条慢请求，不要先看一堆总图
先固定一条具体的慢事务，再往外扩。
最少写清：
- 哪个客户端发起
- 哪个服务端接收
- 哪个接口或操作变慢
- 慢发生在哪个时间窗
网络问题如果不先落到一条具体路径上，后面很容易把不同链路、不同端点、不同时间窗的现象混成一锅。
第二步：先把总时长拆成三段
对着这条请求，先问三件事：
- 客户端发出前是不是已经在本端排队
- 线上传输是不是明显变长
- 服务端收到后是不是处理得更慢
也就是说，先把总时长粗拆成：
- 本端等待
- 链路传输
- 对端处理
这一步不用一次做到特别准，但必须先拆。否则你看到的 TTFB 和超时只是一团总时间。
第三步：两边对证，不接受单边结论
然后立刻补双边证据：
- 客户端的 RTT、重传、超时、队列
- 服务端的连接、排队、应用处理时间
- 必要时再补中间链路或设备证据
这里的目标不是把所有数据都抓来，而是回答：最早先开始等的是哪一边。
还要再防一种特别常见的错判：单边 SYN 重传飙高，不等于物理链路就在丢包。它很可能是对端服务器的监听积压队列已经被打爆，应用层处理太慢，内核只能主动丢掉新连接。只要对端 accept 不出来，你在客户端看到的就会像“网络没接住”。
把全量抓包严格降级成最后手段。为了凑齐双边证据，现场很容易习惯性在两端直接开 tcpdump，但高速网络下抓包本身就可能瞬间吞掉 CPU 和存储带宽，甚至因为内核处理不过来而制造新的丢包。先把 ss、nstat 这类低开销计数器榨干，再决定要不要抓包；不然你拿到的“网络证据”里，已经混进了工具自己造出来的失真。
第四步：先分“本端慢”“链路慢”“对端慢”
到这一步，必须强迫自己先选一类主方向：
- 本端主机或本端应用先慢
- 中间链路先失真
- 对端主机或对端应用先慢
没选类之前，不要说“网络有问题”。因为这句话太大，等于什么都没说。
第五步：只在双边证据能对上时，才升级成链路判断
下面这些情况一起出现时，链路判断才更站得住：
- 两边都能看到对应时延或重传异常
- 端点主机和应用处理时间解释不了全部症状
- 路径切换、流量切分或链路缓解后，症状一起变化
只要其中任何一块是空的，网络结论就先降级成“链路方向待证实”。
先分清本端、链路和对端谁先开始等
每次做完网络排查，至少留下这张三栏表：
- 本端主机和应用看到了什么
- 中间链路和设备看到了什么
- 对端主机和应用看到了什么
再强迫自己补一句结论：
- 最早先开始等的是哪一边
- 另一边看到的是根因、连锁反应，还是单纯显影
这句写不出来，就说明你还停留在“哪里都像有点问题”，没有真正把网络问题拆开。
重传、TTFB 和超时都先当单边线索
先把证据分成本端、链路、对端三栏
以后看网络问题，证据至少按这三栏记：
- 本端主机和应用
- 中间链路和网络设备
- 对端主机和应用
只要有一栏是空的，结论就先别下重。
先把应用时间从网络时间里剥出来
看到 TTFB、超时、延迟恶化时，先问自己：里面有多少是应用自己在处理，有多少真花在网络上传输和等待。
单边证据只能当线索
重传、超时、RTT 变差、队列积压，这些单边现象先都当线索。只有两边证据和路径证据能接起来时，网络根因才更站得住。
单边误判压住以后，再看云里这些证据怎么失真
第 10 章解决的是“网络问题不能只看一边”。第 11 章接着解决“到了云和虚拟化环境里，这些证据还会怎样继续失真”。