很多網(wǎng)絡(luò)故障最麻煩的地方，不是它“很嚴(yán)重”，而是它**看起來(lái)不嚴(yán)重**。

監(jiān)控面板上帶寬沒(méi)跑滿，交換機(jī) CPU 正常，鏈路沒(méi)有明顯中斷，丟包率甚至低到可以忽略。但業(yè)務(wù)側(cè)的反饋卻很統(tǒng)一：頁(yè)面打開(kāi)慢、接口偶發(fā)超時(shí)、數(shù)據(jù)庫(kù)連接偶爾抖一下、視頻會(huì)議時(shí)不時(shí)卡頓。這個(gè)階段最容易出現(xiàn)的團(tuán)隊(duì)協(xié)作姿勢(shì)通常是三種：

- 應(yīng)用團(tuán)隊(duì)說(shuō)：“服務(wù)器資源沒(méi)打滿，應(yīng)該不是我們?！?/p>

- 網(wǎng)絡(luò)團(tuán)隊(duì)說(shuō)：“鏈路沒(méi)斷、丟包也不高，應(yīng)該不是網(wǎng)絡(luò)?！?/p>

- 業(yè)務(wù)團(tuán)隊(duì)說(shuō)：“用戶已經(jīng)罵起來(lái)了，你們先別互相甩鍋。”

真正的問(wèn)題往往不在“是否有大故障”，而在于**是否存在持續(xù)但隱蔽的時(shí)延抖動(dòng)、重傳堆積、微突發(fā)擁塞或路徑不一致**。這類問(wèn)題如果只看總量型指標(biāo)，很容易被掩蓋；但如果把觀察視角切到連接級(jí)、會(huì)話級(jí)、RTT 分布級(jí)，線索往往就會(huì)變得很明顯。

這篇文章我用一個(gè)典型排障案例，完整拆解一套適合一線運(yùn)維、網(wǎng)絡(luò)工程師和 IT 基礎(chǔ)架構(gòu)團(tuán)隊(duì)的思路：

1. 為什么“低丟包”不代表“用戶無(wú)感知”

2. 如何用 tcpdump 做**低侵入抓包**

3. 如何從 RTT、重傳、窗口變化和應(yīng)用響應(yīng)節(jié)奏中判斷瓶頸位置

4. 如何避免“抓了一堆包，但依然說(shuō)不清問(wèn)題在哪”

5. 最后如何把排障方法沉淀成可復(fù)用流程

如果你正好遇到“監(jiān)控一片綠、用戶體驗(yàn)一片紅”的情況，這篇內(nèi)容大概率能幫你少走很多彎路。

---

## 一、故障現(xiàn)象：看起來(lái)都正常，但用戶就是覺(jué)得慢

某企業(yè)內(nèi)部 OA 系統(tǒng)在早上 9:00 到 10:30 的高峰期持續(xù)被投訴卡頓。癥狀很典型：

- 登錄頁(yè)偶發(fā)轉(zhuǎn)圈 3~5 秒

- 列表頁(yè)刷新慢，偶爾超時(shí)

- API 網(wǎng)關(guān)日志中出現(xiàn)零星上游響應(yīng)超時(shí)

- 數(shù)據(jù)庫(kù)監(jiān)控沒(méi)有明顯鎖等待峰值

- 服務(wù)器 CPU、內(nèi)存、磁盤 IO 都不高

- 出口帶寬占用不足 40%

- 核心交換和防火墻也沒(méi)明顯告警

如果只看這些表象，你很容易得到一個(gè)“網(wǎng)絡(luò)整體沒(méi)問(wèn)題”的誤判。因?yàn)榇蟛糠謧鹘y(tǒng)監(jiān)控關(guān)注的是：

- 設(shè)備是否在線

- 端口是否 up/down

- 帶寬是否打滿

- 丟包率是否超過(guò)閾值

- 平均時(shí)延是否超標(biāo)

問(wèn)題在于，用戶體驗(yàn)往往不是由“平均值”決定的，而是由**尾延遲**決定的。

舉個(gè)最簡(jiǎn)單的例子：

- 平均 RTT 只有 8ms

- 95 分位 RTT 卻飆到 120ms

- 少量請(qǐng)求出現(xiàn) 300ms+ 的抖動(dòng)

從“平均值”看一切正常；從業(yè)務(wù)感知看，這已經(jīng)足夠讓接口串聯(lián)調(diào)用出現(xiàn)明顯卡頓。尤其在微服務(wù)、API 聚合、前后端分離的架構(gòu)里，一個(gè)頁(yè)面往往依賴十幾個(gè)甚至幾十個(gè)請(qǐng)求，只要其中幾條鏈路存在抖動(dòng)，整體體驗(yàn)就會(huì)明顯下降。

所以第一原則很明確：

> **用戶說(shuō)卡，不要先問(wèn)平均值正不正常，要先問(wèn)尾部時(shí)延和連接質(zhì)量有沒(méi)有抖。**

---

## 二、為什么低丟包也會(huì)卡？真正拖慢業(yè)務(wù)的常見(jiàn)機(jī)制

很多團(tuán)隊(duì)把“網(wǎng)絡(luò)問(wèn)題”過(guò)度簡(jiǎn)化成“丟包嚴(yán)重”。這其實(shí)是典型的經(jīng)驗(yàn)陷阱。

在真實(shí)生產(chǎn)環(huán)境里，以下幾類情況都可能讓?xiě)?yīng)用很卡，但總體丟包率并不高：

### 1）微突發(fā)擁塞

鏈路總帶寬不高，不代表某一瞬間沒(méi)有擁塞。

例如：

- 某批量任務(wù)在幾十毫秒內(nèi)突發(fā)寫(xiě)入

- 多個(gè)業(yè)務(wù)在同一交換上行口瞬時(shí)匯聚

- 虛擬化環(huán)境里多個(gè) vNIC 同時(shí)沖高

這類場(chǎng)景的特點(diǎn)是：

- 平均帶寬不高

- 但隊(duì)列瞬時(shí)積壓

- 個(gè)別報(bào)文排隊(duì)時(shí)間很長(zhǎng)

- 應(yīng)用會(huì)感知到抖動(dòng)和超時(shí)

這就像高速公路總體車流不大，但收費(fèi)站前偶爾一團(tuán)擠住了。你看全天平均通行量很正常，但某些車就是被堵了。

### 2）鏈路不丟，但重傳和亂序增多

TCP 不一定非要“大面積丟包”才會(huì)出現(xiàn)性能下降。只要發(fā)生：

- 局部重傳

- 亂序

- ACK 延遲異常

- SACK 增多

- 接收窗口變化異常

都會(huì)讓吞吐、交互時(shí)延和應(yīng)用響應(yīng)節(jié)奏變差。

### 3）DNS、TLS、應(yīng)用握手階段慢

很多人抓包只盯著數(shù)據(jù)傳輸階段，但真實(shí)卡頓可能發(fā)生在：

- DNS 解析等待

- TCP 三次握手重復(fù)嘗試

- TLS 握手耗時(shí)增加

- 上游服務(wù)首包返回慢

這類問(wèn)題對(duì)用戶的體感極強(qiáng)，因?yàn)樗苯永L(zhǎng)“開(kāi)始響應(yīng)之前”的等待時(shí)間。

### 4）路徑不一致或中間設(shè)備處理波動(dòng)

例如：

- 負(fù)載均衡回程路徑不一致

- 防火墻策略命中不同路徑

- 某鏈路上策略/檢查在高峰期變慢

- 某個(gè)安全設(shè)備沒(méi)有完全阻斷，但處理時(shí)延抖動(dòng)變大

這時(shí)候“網(wǎng)絡(luò)沒(méi)斷”是真的，但“網(wǎng)絡(luò)體驗(yàn)不好”也是真的。

所以如果你排障還停留在“沒(méi)丟多少包，應(yīng)該不是網(wǎng)絡(luò)”的階段，那基本屬于給故障開(kāi)了 VIP 免檢通道。

---

## 三、這次排障為什么選 tcpdump，而不是先大范圍上 Wireshark

先說(shuō)結(jié)論：**生產(chǎn)環(huán)境先抓證據(jù)，再做漂亮分析。**

Wireshark 很強(qiáng)，但一線環(huán)境里，很多時(shí)候第一步更適合用 tcpdump，原因有三個(gè)：

### 1）低侵入、部署快

大多數(shù) Linux 服務(wù)器和網(wǎng)絡(luò)分析節(jié)點(diǎn)都能直接用 tcpdump。無(wú)需圖形界面，也不需要把一整套工具先搬上去。

### 2）便于定點(diǎn)抓取

可以先按：

- 目標(biāo) IP

- 目標(biāo)端口

- 協(xié)議類型

- 抓包時(shí)長(zhǎng)

- 報(bào)文大小

進(jìn)行精確過(guò)濾，避免把磁盤打爆。

### 3）適合還原高峰時(shí)間窗

用戶反饋通常集中在某個(gè)時(shí)間段，比如 9:05~9:20。用 tcpdump 可以快速做一個(gè)定時(shí)、限量、限方向的抓取，把關(guān)鍵窗口留存下來(lái)，后續(xù)再離線分析。

本次案例里，我們采用的是兩級(jí)策略：

**第一級(jí)：在線輕量抓包**

```bash

tcpdump -i any host 10.20.30.45 and port 443 -s 0 -w oa_peak_window.pcap

```

這個(gè)階段的目標(biāo)不是“一網(wǎng)打盡”，而是拿到高峰時(shí)段核心業(yè)務(wù)連接的真實(shí)證據(jù)。

**第二級(jí)：離線分析 RTT / 重傳 / 響應(yīng)節(jié)奏**

拿到 pcap 后，再做：

- TCP RTT 抽樣

- 重傳分布統(tǒng)計(jì)

- 服務(wù)端首包時(shí)延觀察

- ACK 返回節(jié)奏分析

- 異常時(shí)間段與業(yè)務(wù)告警時(shí)間對(duì)齊

注意一個(gè)關(guān)鍵點(diǎn)：

> **抓包不是為了證明你會(huì)抓包，而是為了把“卡”的主觀感受翻譯成可定位的客觀證據(jù)。**

---

## 四、抓包前先定義問(wèn)題，不然只會(huì)抓到一堆無(wú)用數(shù)據(jù)

很多排障失敗，不是因?yàn)闆](méi)抓到包，而是因?yàn)樽グ皼](méi)有定義觀察目標(biāo)。

在這次案例里，我們先把問(wèn)題拆成四個(gè)判斷：

### 判斷 1：慢在建立連接前，還是慢在連接建立后？

看：

- DNS 是否慢

- TCP 三次握手是否有重試

- TLS ClientHello / ServerHello 間隔是否異常

### 判斷 2：慢在客戶端到服務(wù)端的傳輸，還是服務(wù)端處理后返回慢？

看：

- 請(qǐng)求發(fā)完后，服務(wù)端首個(gè)響應(yīng)包出現(xiàn)前的時(shí)間

- 服務(wù)端響應(yīng)是否被分段拖長(zhǎng)

### 判斷 3：慢是持續(xù)性的，還是高峰時(shí)段才發(fā)生？

看：

- 異常 RTT 是否集中在某時(shí)間窗

- 是否和用戶投訴時(shí)間重合

### 判斷 4：慢是單點(diǎn)問(wèn)題，還是鏈路/區(qū)域性問(wèn)題？

看：

- 是否只有某幾個(gè)客戶端網(wǎng)段明顯更差

- 是否同一應(yīng)用的多個(gè)會(huì)話同時(shí)出現(xiàn)抖動(dòng)

有了這四個(gè)判斷，抓包才有方向。否則很容易陷入“文件很大、信息很多、結(jié)論沒(méi)有”的經(jīng)典翻車現(xiàn)場(chǎng)。

---

## 五、實(shí)戰(zhàn)分析：怎么從 pcap 里把問(wèn)題拎出來(lái)

下面進(jìn)入最關(guān)鍵的部分：**抓到包之后到底怎么看。**

### 1）先看握手和基礎(chǔ)連通性，不要一上來(lái)就盯 payload

先檢查 TCP 三次握手：

- SYN 發(fā)出是否及時(shí)

- SYN, ACK 返回是否平穩(wěn)

- 是否存在 SYN 重傳

- 建連 RTT 是否高峰時(shí)段顯著上升

在本案例中，建連 RTT 大部分仍然較低，說(shuō)明問(wèn)題不是典型的“完全連不上”或“握手就明顯變慢”。這一步很重要，它幫我們先排除了防火墻阻斷、目標(biāo)不可達(dá)、嚴(yán)重路徑異常這類重故障。

### 2）再看請(qǐng)求發(fā)出后的首包響應(yīng)時(shí)間

很多“卡頓”其實(shí)出現(xiàn)在服務(wù)端首包響應(yīng)前。

如果一個(gè) HTTPs 請(qǐng)求發(fā)完后：

- 100ms 內(nèi)就有響應(yīng)首包，通常網(wǎng)絡(luò)側(cè)問(wèn)題不大

- 經(jīng)常拖到 500ms、800ms 甚至更高，就要進(jìn)一步判斷是服務(wù)端處理慢，還是鏈路中間有抖動(dòng)

本次分析中，最有價(jià)值的不是平均值，而是抽樣后發(fā)現(xiàn)：

- 正常請(qǐng)求首包響應(yīng)在 20~40ms

- 異常時(shí)段部分請(qǐng)求首包響應(yīng)拉長(zhǎng)到 180~350ms

- 這些異常樣本集中出現(xiàn)在 9:10~9:25

這已經(jīng)和業(yè)務(wù)反饋時(shí)間高度一致。

### 3）看 RTT 分布，而不是只看平均 RTT

排查網(wǎng)絡(luò)性能問(wèn)題時(shí)，我很推薦一個(gè)動(dòng)作：

> **做 RTT 抽樣分布，而不是只看一條平均曲線。**

因?yàn)槠骄?RTT 極易掩蓋尾部異常。

本次抽樣后發(fā)現(xiàn)：

- 大量連接 RTT 仍維持在 5~10ms

- 但同一時(shí)間窗中，部分會(huì)話 RTT 突然躍升到 80~150ms

- 個(gè)別連接伴隨 ACK 回包抖動(dòng)和短暫重傳

這意味著問(wèn)題不是“全網(wǎng)都慢”，而是**某些會(huì)話在高峰時(shí)段受到明顯排隊(duì)或路徑處理抖動(dòng)影響**。

這類現(xiàn)象在以下場(chǎng)景非常常見(jiàn)：

- 匯聚口短時(shí)排隊(duì)

- 中間設(shè)備高峰期處理抖動(dòng)

- 某條業(yè)務(wù)路徑上的檢查鏈路被打出微擁塞

### 4）重傳不多，不代表不用看重傳

本案例一個(gè)很有迷惑性的點(diǎn)在于：總體重傳率并不算高。

但當(dāng)我們把時(shí)間窗縮小、把會(huì)話粒度拉細(xì)后，會(huì)發(fā)現(xiàn)：

- 異常請(qǐng)求附近會(huì)出現(xiàn)小規(guī)模重傳

- 部分連接存在重復(fù) ACK

- 某些分段的返回間隔明顯拉長(zhǎng)

這說(shuō)明不是持續(xù)大面積丟包，而更像是：

- 瞬時(shí)擁塞

- 局部隊(duì)列堆積

- 個(gè)別分段排隊(duì)過(guò)久后觸發(fā)傳輸效率下降

也就是說(shuō)，這不是“炸裂式故障”，而是更討厭的那種：**足夠讓用戶感覺(jué)卡，但又不足以讓傳統(tǒng)閾值告警全面響起。**

### 5）結(jié)合業(yè)務(wù)訪問(wèn)路徑，鎖定問(wèn)題更接近網(wǎng)絡(luò)側(cè)而非應(yīng)用側(cè)

最終定性的關(guān)鍵，不是只看一項(xiàng)指標(biāo)，而是多個(gè)證據(jù)疊加：

- 服務(wù)器資源使用平穩(wěn)

- 應(yīng)用日志沒(méi)有大面積內(nèi)部異常

- 慢請(qǐng)求集中在高峰時(shí)間窗

- 首包前等待時(shí)間異常拉長(zhǎng)

- RTT 尾部分布顯著變差

- 有輕微重復(fù) ACK / 重傳 / 抖動(dòng)

- 問(wèn)題在用戶入口與應(yīng)用之間更明顯，而非數(shù)據(jù)庫(kù)后端鏈路

這些證據(jù)組合起來(lái)后，基本可以判斷：

**問(wèn)題更偏向網(wǎng)絡(luò)路徑上的高峰抖動(dòng)，而不是應(yīng)用程序本身處理能力不足。**

---

## 六、最后定位到什么問(wèn)題？

進(jìn)一步結(jié)合交換口隊(duì)列統(tǒng)計(jì)、匯聚鏈路流量突發(fā)走勢(shì)和上行時(shí)間窗分析，最終發(fā)現(xiàn)問(wèn)題主要來(lái)自：

### 匯聚層某上行鏈路在高峰期出現(xiàn)明顯微突發(fā)排隊(duì)

具體表現(xiàn)是：

- 平均帶寬并不高

- 但某些時(shí)間片瞬時(shí)流量尖峰明顯

- 排隊(duì)時(shí)延拉高了部分關(guān)鍵業(yè)務(wù)連接的 RTT

- 由于問(wèn)題持續(xù)時(shí)間短、總體丟包不高，傳統(tǒng)監(jiān)控沒(méi)有觸發(fā)強(qiáng)告警

優(yōu)化動(dòng)作包括：

1. 調(diào)整高峰批處理任務(wù)啟動(dòng)時(shí)間，避開(kāi)辦公流量峰值

2. 對(duì)關(guān)鍵業(yè)務(wù)流量做更細(xì)粒度隊(duì)列保障

3. 補(bǔ)充連接質(zhì)量和 RTT 分位數(shù)監(jiān)控，而不是只看平均值

4. 對(duì)入口關(guān)鍵鏈路增加更細(xì)時(shí)間粒度的可視化分析

優(yōu)化完成后，用戶投訴顯著下降，接口慢請(qǐng)求比例明顯回落。

這類案例最值得記住的一點(diǎn)是：

> **網(wǎng)絡(luò)性能問(wèn)題不一定表現(xiàn)為“斷”，更多時(shí)候表現(xiàn)為“偶發(fā)慢、難復(fù)現(xiàn)、很容易甩鍋”。**

而真正有價(jià)值的排障，不是等到徹底炸鍋才行動(dòng)，而是在“還沒(méi)完全炸”時(shí)就把證據(jù)鏈拉出來(lái)。

---

## 七、排障過(guò)程中最容易踩的 5 個(gè)坑

### 坑 1：只看平均值

平均 RTT、平均 CPU、平均帶寬都很容易騙人。網(wǎng)絡(luò)體驗(yàn)差，很多時(shí)候就是尾延遲問(wèn)題。

### 坑 2：抓包范圍過(guò)大

一上來(lái)全量抓，最后通常得到兩種結(jié)果：

- 文件巨大，不敢分析

- 關(guān)鍵時(shí)間窗反而不清楚

正確做法是先縮小目標(biāo)：主機(jī)、端口、時(shí)間窗、方向。

### 坑 3：只盯網(wǎng)絡(luò)設(shè)備，不看應(yīng)用交互節(jié)奏

真正能把問(wèn)題說(shuō)清楚的，往往不是“端口有沒(méi)有告警”，而是：

- 請(qǐng)求什么時(shí)候發(fā)出

- 對(duì)方什么時(shí)候開(kāi)始回

- 中間有沒(méi)有重傳、亂序、窗口變化

這才是用戶體感和底層證據(jù)之間的橋梁。

### 坑 4：沒(méi)有把抓包時(shí)間和用戶投訴時(shí)間對(duì)齊

時(shí)間對(duì)齊做不好，分析就會(huì)像在霧里打拳。

一定要把：

- 用戶反饋時(shí)間

- 業(yè)務(wù)監(jiān)控告警時(shí)間

- 抓包開(kāi)始結(jié)束時(shí)間

- 網(wǎng)絡(luò)側(cè)異常時(shí)間

統(tǒng)一到一個(gè)時(shí)間軸上。

### 坑 5：?jiǎn)栴}解決了，但流程沒(méi)沉淀

很多團(tuán)隊(duì)故障處理完就散會(huì)，下次繼續(xù)從頭猜。

更成熟的做法是把這次經(jīng)驗(yàn)沉淀成標(biāo)準(zhǔn)動(dòng)作：

- 先確認(rèn)影響范圍

- 定義慢在哪個(gè)階段

- 定點(diǎn)抓包

- 看 RTT 分布和首包時(shí)延

- 結(jié)合重傳/重復(fù) ACK/窗口變化判斷

- 回到鏈路、隊(duì)列、策略和業(yè)務(wù)時(shí)序做收斂

這樣下次再遇到類似問(wèn)題，處理速度會(huì)快很多。

---

## 八、給一線團(tuán)隊(duì)的一個(gè)實(shí)用排障框架

如果你經(jīng)常處理“應(yīng)用卡、但又說(shuō)不清是不是網(wǎng)絡(luò)”的問(wèn)題，可以直接套下面這套簡(jiǎn)版框架。

### Step 1：先問(wèn)業(yè)務(wù)感知

明確：

- 是所有人都慢，還是部分人慢

- 是全天慢，還是高峰期慢

- 是登錄慢、列表慢，還是下載慢

### Step 2：確認(rèn)是否為連接階段問(wèn)題

重點(diǎn)看：

- DNS

- TCP 握手

- TLS 握手

### Step 3：確認(rèn)是否為傳輸質(zhì)量問(wèn)題

重點(diǎn)看：

- RTT 分布

- 重傳

- 重復(fù) ACK

- 亂序

- 窗口變化

### Step 4：確認(rèn)是否為服務(wù)端處理問(wèn)題

重點(diǎn)看：

- 請(qǐng)求發(fā)出后首包等待時(shí)間

- 服務(wù)端日志與資源情況

### Step 5：回到鏈路和策略層定位根因

重點(diǎn)排查：

- 匯聚/出口排隊(duì)

- QoS 配置

- 中間安全設(shè)備處理抖動(dòng)

- 路徑不一致

- 高峰期批量任務(wù)沖擊

這套方法的好處是：不靠拍腦袋，不靠經(jīng)驗(yàn)主義甩鍋，而是一步一步把問(wèn)題縮到可以驗(yàn)證的范圍。

---

## 九、為什么越來(lái)越多團(tuán)隊(duì)需要“持續(xù)可回溯”的流量分析能力

這次案例里如果沒(méi)有抓包證據(jù)，團(tuán)隊(duì)很可能會(huì)長(zhǎng)期停留在“感覺(jué)不是網(wǎng)絡(luò)”“但用戶又確實(shí)很卡”的拉扯狀態(tài)。

而隨著系統(tǒng)越來(lái)越復(fù)雜，傳統(tǒng)靠人工臨時(shí)抓包的方式會(huì)越來(lái)越吃力，原因很現(xiàn)實(shí)：

- 故障可能只在幾分鐘內(nèi)出現(xiàn)

- 異常未必能穩(wěn)定復(fù)現(xiàn)

- 鏈路越來(lái)越長(zhǎng)，跨交換機(jī)、防火墻、負(fù)載均衡、服務(wù)器和應(yīng)用

- 只靠單點(diǎn)抓包，很難建立完整證據(jù)鏈

所以很多團(tuán)隊(duì)后面都會(huì)走向一個(gè)更成熟的方向：

- 平時(shí)做持續(xù)采集

- 故障時(shí)能按時(shí)間窗回溯

- 能快速看到 RTT、重傳、連接質(zhì)量、協(xié)議行為和路徑側(cè)異常

- 把“猜測(cè)問(wèn)題”變成“證據(jù)定位問(wèn)題”

說(shuō)白了，排障效率的上限，往往取決于你保留了多少高質(zhì)量證據(jù)。

如果你的團(tuán)隊(duì)正在處理類似的網(wǎng)絡(luò)故障排查、抓包分析、性能抖動(dòng)定位或全流量可視化問(wèn)題，可以關(guān)注 **AnaTraf**（<https://www.anatraf.com>）。它更適合那些不想再靠臨時(shí)救火、而是希望把網(wǎng)絡(luò)流量分析、故障回溯和性能診斷做成體系化能力的團(tuán)隊(duì)。

---

## 十、結(jié)語(yǔ)

“丟包不高但應(yīng)用卡”這類問(wèn)題，最容易把團(tuán)隊(duì)拖進(jìn)一個(gè)經(jīng)典誤區(qū)：

- 監(jiān)控看著沒(méi)事

- 用戶卻持續(xù)有感

- 每個(gè)人都能說(shuō)出一點(diǎn)道理

- 但誰(shuí)也拿不出完整證據(jù)

真正有效的辦法，不是繼續(xù)爭(zhēng)論“到底是不是網(wǎng)絡(luò)”，而是把問(wèn)題拆成：

- 慢在連接前還是連接后

- 慢在傳輸還是處理

- 是平均正常但尾部異常，還是持續(xù)性退化

- 是全局問(wèn)題還是局部路徑問(wèn)題

一旦你學(xué)會(huì)用抓包、RTT 抽樣、首包時(shí)延、重傳與連接質(zhì)量這些證據(jù)去說(shuō)話，很多原本看似模糊的問(wèn)題，都會(huì)快速收斂。

網(wǎng)絡(luò)排障這件事，怕的從來(lái)不是問(wèn)題復(fù)雜，而是**沒(méi)有證據(jù)時(shí)大家只能靠直覺(jué)互相猜**。

而猜，是生產(chǎn)環(huán)境里最昂貴的習(xí)慣。