很多團(tuán)隊(duì)做網(wǎng)絡(luò)排障時(shí)，最容易掉進(jìn)兩個(gè)坑：
- **只盯帶寬圖，不看連接結(jié)構(gòu)**，最后只能得到一句“流量變大了”；
- **抓了包但沒有分層拆解**，最終 Wireshark 開著像看天書，問題卻一毫米都沒推進(jìn)。
這篇文章我用一個(gè)非常典型、也非常常見的案例，完整拆解一次 **UDP 流量洪峰** 的排障路徑：監(jiān)控先報(bào)警、鏈路帶寬被打滿、應(yīng)用方說“我們沒發(fā)版”、網(wǎng)絡(luò)側(cè)懷疑“是不是攻擊”、最后通過 **抓包 + 會(huì)話聚合 + 端口畫像 + 采樣比對(duì)**，把異常源縮到具體業(yè)務(wù)模塊。
這類問題在園區(qū)網(wǎng)、云上 VPC、跨機(jī)房專線、視頻平臺(tái)、游戲后端、IoT 平臺(tái)都非常高發(fā)。區(qū)別只在于外殼不同，底層邏輯幾乎一樣。
---
## 一、故障背景：為什么 UDP 洪峰最容易把人搞懵
先交代案例背景。
某業(yè)務(wù)區(qū)在工作日中午出現(xiàn)持續(xù) 20 分鐘的出口擁塞：
- 核心交換機(jī)出口帶寬從日常 180 Mbps 突然沖到 930 Mbps；
- 同時(shí)段業(yè)務(wù)側(cè)反饋 API 響應(yīng)時(shí)間抖動(dòng)明顯；
- 但服務(wù)器 CPU、內(nèi)存、磁盤都沒有明顯異常；
- 四層負(fù)載設(shè)備上看不到大面積 TCP 重傳飆升；
- NetFlow 側(cè)只能看到“某幾臺(tái)節(jié)點(diǎn)發(fā)出了大量 UDP”。
這時(shí)候很多團(tuán)隊(duì)會(huì)直覺判斷成三類：
1. 被打了；
2. 某個(gè)視頻/日志/采集程序失控；
3. 網(wǎng)絡(luò)設(shè)備抽風(fēng)，監(jiān)控誤報(bào)。
看上去三選一，實(shí)際上都不夠精確。真正要問的是：
> **這波 UDP 流量，到底是“正常業(yè)務(wù)放大了”，還是“異常行為偽裝成正常流量”？**
這是兩種完全不同的處理路徑。
- 如果是正常業(yè)務(wù)放大，重點(diǎn)是容量治理、限速、調(diào)度和協(xié)議設(shè)計(jì)；
- 如果是異常行為，重點(diǎn)是快速止血、識(shí)別源頭、修復(fù)觸發(fā)器并防止復(fù)發(fā)。
而抓包分析的價(jià)值，就在于它能把“感覺像”變成“證據(jù)鏈”。
---
## 二、第一步不是抓包，而是先確認(rèn)“異常是否真的存在”
排障第一原則：**先證明確實(shí)異常，再討論原因。**
### 1）先拉 4 個(gè)最小觀察面
我一般先看這四組數(shù)據(jù)：
- **帶寬時(shí)間序列**：異常開始時(shí)間、峰值、持續(xù)時(shí)間、回落方式；
- **接口丟包/隊(duì)列**：是否真有擁塞、是否有 burst queue；
- **Top Talker / Top Port**：誰發(fā)得最多，發(fā)到哪里；
- **應(yīng)用側(cè)關(guān)鍵指標(biāo)**：RT、錯(cuò)誤率、超時(shí)、任務(wù)堆積。
這里一個(gè)關(guān)鍵動(dòng)作是：**把“異常時(shí)間點(diǎn)”釘死到分鐘級(jí)**。
因?yàn)楹竺婺悴还芸戳髁咳罩?、抓包文件、主機(jī)日志、任務(wù)日志，全部都要圍繞這個(gè)時(shí)間窗比對(duì)。如果時(shí)間窗不準(zhǔn)，后面所有分析都會(huì)在錯(cuò)誤樣本上兜圈子。
本次案例里我們最后確認(rèn)：
- 異常開始：12:17
- 峰值區(qū)間：12:19 ~ 12:24
- 基本恢復(fù)：12:36
### 2）確認(rèn)是不是“監(jiān)控看起來高，其實(shí)沒堵”
有些團(tuán)隊(duì)看到帶寬圖高了就慌，結(jié)果接口并沒有丟包，應(yīng)用也沒波動(dòng)，那未必叫故障，可能只是業(yè)務(wù)峰值。
這次之所以確認(rèn)它是有效故障，是因?yàn)橥瑫r(shí)滿足了三個(gè)條件：
- 接口利用率接近上限；
- 輸出隊(duì)列增長(zhǎng)明顯；
- 上層 API 延遲同步抬升。
這三個(gè)條件一疊加，說明不是“圖好看”，而是真影響業(yè)務(wù)了。
---
## 三、第二步：先做流量畫像，不要一上來就全量抓
很多人一碰到網(wǎng)絡(luò)問題就直接 tcpdump 全抓，最后得到一個(gè)十幾 GB 的 pcap，然后把自己埋了。
**正確順序應(yīng)該是：先畫像，再精準(zhǔn)抓。**
### 1）先看五元組分布
目標(biāo)不是立刻定位真兇，而是回答幾個(gè)基礎(chǔ)問題：
- 流量主要是南北向還是東西向？
- 是單源多目的，還是多源單目的？
- 是固定端口，還是隨機(jī)高端口？
- 包長(zhǎng)是小包密集，還是大包占帶寬？
- 流量是持續(xù)平推，還是短時(shí)脈沖？
本次案例的初步畫像是：
- 主要是 **少量源 IP 對(duì)少量目的 IP**；
- 協(xié)議高度集中在 UDP；
- 目的端口高度集中；
- 包長(zhǎng)以 1200~1400 字節(jié)為主；
- 流量不是瞬時(shí)脈沖，而是連續(xù) 10+ 分鐘高位運(yùn)行。
這幾個(gè)特征已經(jīng)足夠說明：
- 它不像傳統(tǒng) UDP flood 那種完全無規(guī)律的攻擊；
- 也不像日志打點(diǎn)那種大量小包；
- 更像某種 **批量分發(fā)、媒體分片、采集轉(zhuǎn)發(fā)、傳輸重試或消息廣播類業(yè)務(wù)** 被放大了。
### 2）先用輕量命令拿輪廓
在 Linux 主機(jī)上，常用第一輪命令我一般會(huì)這樣打：
```bash
ss -u -anp
sar -n DEV 1 5
sar -n UDP 1 5
iftop -n -P
sudo tcpdump -ni any udp -c 200
```
這幾條命令的作用分工很明確：
- `ss -u -anp`：看 UDP socket 與進(jìn)程關(guān)聯(lián)；
- `sar -n DEV/UDP`：看接口與 UDP 收發(fā)概況；
- `iftop`：快速看誰在發(fā)；
- `tcpdump -c 200`：先拿樣本，不急著全量抓。
這里的關(guān)鍵不是命令多厲害，而是你先拿到**樣本級(jí)事實(shí)**：
> 到底是哪個(gè)主機(jī)、哪些端口、什么包長(zhǎng)、什么節(jié)奏在跑。
---
## 四、第三步：抓包不是目的，構(gòu)造證據(jù)鏈才是目的
接下來進(jìn)入最核心的抓包分析。
### 1）抓包范圍要先縮，不然只會(huì)得到噪音
本案例里我沒有直接在核心口做長(zhǎng)時(shí)間全量抓包，而是做了兩層收縮：
**第一層：按協(xié)議與主機(jī)收縮**
```bash
sudo tcpdump -ni eth0 host 10.20.14.23 and udp -w udp_spike_host.pcap
```
**第二層：按端口進(jìn)一步收縮**
```bash
sudo tcpdump -ni eth0 host 10.20.14.23 and udp port 9005 -w udp_spike_9005.pcap
```
為什么這么做？因?yàn)榕耪喜皇欠ㄡt(yī)展覽，不需要“把所有東西都錄下來”。你需要的是：
- 樣本可分析；
- 文件可打開；
- 結(jié)論可復(fù)現(xiàn)；
- 時(shí)間窗口與異常對(duì)齊。
### 2）在 Wireshark 里先看這幾件事
拿到 pcap 后，優(yōu)先看：
- Conversations（會(huì)話聚合）
- Endpoints（端點(diǎn)排行）
- Protocol Hierarchy（協(xié)議層級(jí)）
- IO Graph（流量曲線）
- Length / Delta Time 分布
如果你一進(jìn) Wireshark 就直接看逐包明細(xì)，十有八九會(huì)被細(xì)節(jié)淹死。
本次會(huì)話聚合里有兩個(gè)非常關(guān)鍵的發(fā)現(xiàn)：
- 單個(gè)源 IP 發(fā)往兩個(gè)目的 IP 的 UDP 流量占比超過 78%；
- 目標(biāo)端口幾乎固定在 9005，包長(zhǎng)高度集中在 MTU 附近。
這說明問題已經(jīng)從“網(wǎng)絡(luò)普遍異?！笔湛s成：
> **某個(gè)應(yīng)用模塊，正在向固定接收端持續(xù)推送大塊 UDP 數(shù)據(jù)。**
這時(shí)就不再是泛化的“網(wǎng)絡(luò)問題”，而是可以與應(yīng)用/中間件同學(xué)對(duì)表的業(yè)務(wù)路徑問題。
---
## 五、第四步：區(qū)分“高流量業(yè)務(wù)”與“異常重傳/風(fēng)暴”
很多團(tuán)隊(duì)看到 UDP 大流量就默認(rèn)它是正常媒體流。這個(gè)判斷很危險(xiǎn)。
因?yàn)?UDP 沒有 TCP 那種天然的連接控制與重傳語義，很多業(yè)務(wù)會(huì)在應(yīng)用層自己做補(bǔ)償。一旦補(bǔ)償策略寫得激進(jìn)，就會(huì)形成：
- 應(yīng)用層重復(fù)發(fā)送；
- 接收側(cè)處理不過來但發(fā)送側(cè)無感；
- 中間鏈路持續(xù)被占滿；
- 監(jiān)控只看見“UDP 很高”，卻看不見“為什么高”。
### 1）怎么識(shí)別是不是重復(fù)發(fā)送
可以從三個(gè)角度判斷：
#### 角度 A：包內(nèi)容相似度
在樣本里抽取連續(xù)報(bào)文，觀察 payload 是否出現(xiàn)大段重復(fù)。
如果同一源、同一端口、同一時(shí)間窗里，連續(xù)多組數(shù)據(jù) payload 高度相似，往往不是正常實(shí)時(shí)流，而可能是：
- 重試風(fēng)暴；
- 緩存積壓后重復(fù)下發(fā)；
- 某隊(duì)列消費(fèi)失敗導(dǎo)致重復(fù)投遞。
#### 角度 B：時(shí)間間隔模式
實(shí)時(shí)業(yè)務(wù)通常有比較穩(wěn)定的發(fā)送節(jié)奏；
而異常重傳常常會(huì)出現(xiàn)“固定周期回灌”或者“批次式突刺”。
本案例里 IO Graph 很典型：
- 每 3 秒出現(xiàn)一次明顯波峰；
- 峰值之間不是完全歸零，而是維持高位；
- 波形非常機(jī)械。
這就很像應(yīng)用定時(shí)任務(wù)或重試器在工作，而不是自然用戶流量。
#### 角度 C：主機(jī)進(jìn)程與業(yè)務(wù)日志對(duì)表
網(wǎng)絡(luò)證據(jù)只能告訴你“誰在發(fā)”；
真正閉環(huán)還需要系統(tǒng)側(cè)回答“為什么發(fā)”。
所以我一般會(huì)立刻去看：
```bash
sudo lsof -iUDP -n -P
ps -ef | grep -i <service-name>
journalctl -u <service-name> --since "2026-04-28 12:10:00" --until "2026-04-28 12:40:00"
```
最后我們?cè)谥鳈C(jī)日志里發(fā)現(xiàn)，某個(gè)數(shù)據(jù)分發(fā)服務(wù)在 12:16 左右觸發(fā)了“補(bǔ)償重投”，而下游 ACK 統(tǒng)計(jì)異常，導(dǎo)致發(fā)送側(cè)誤判數(shù)據(jù)未送達(dá)，開始批量重發(fā)。
這就是完整證據(jù)鏈：
- 帶寬高 →
- UDP 占比高 →
- 端口集中 →
- 源目固定 →
- 周期性波峰 →
- payload 高相似 →
- 進(jìn)程與日志對(duì)應(yīng)上重試邏輯。
至此，問題已經(jīng)不是“像不像攻擊”，而是**可以明確歸因?yàn)閼?yīng)用層補(bǔ)償機(jī)制失控**。
---
## 六、第五步：為什么很多 UDP 排障最后都卡在“看見現(xiàn)象，看不見歸因”
因?yàn)橹蛔隽恕安蓸佑^察”，沒做“關(guān)聯(lián)分析”。
真正能落地的排障，至少要把以下 4 層串起來：
1. **接口層**：帶寬、丟包、隊(duì)列、突發(fā)；
2. **流量層**：協(xié)議、端口、會(huì)話、方向、包長(zhǎng)；
3. **主機(jī)層**：socket、進(jìn)程、容器、節(jié)點(diǎn)角色；
4. **業(yè)務(wù)層**：任務(wù)、重試、補(bǔ)償、發(fā)布、上游觸發(fā)。
少一層，你都容易停留在“看起來是它”。
而企業(yè)里最貴的，不是故障本身，而是這種模糊判斷帶來的扯皮成本：
- 網(wǎng)絡(luò)說應(yīng)用亂發(fā)；
- 應(yīng)用說網(wǎng)絡(luò)不穩(wěn)；
- 安全說像攻擊；
- 管理層問：到底誰負(fù)責(zé)？
沒有證據(jù)鏈，大家都能說得像自己沒錯(cuò)。
---
## 七、這類故障的止血?jiǎng)幼髟趺醋?/p>
定位到異常發(fā)送后，處理順序不要亂。
### 1）先止血，再根因
止血常見動(dòng)作包括：
- 對(duì)異常源主機(jī)做臨時(shí)限速；
- 對(duì)目的端口做 ACL / QoS 限流；
- 暫停補(bǔ)償任務(wù)或批量分發(fā)任務(wù)；
- 在接入層隔離問題節(jié)點(diǎn)。
但要注意：
> **止血?jiǎng)幼饕欢ㄒ蜆I(yè)務(wù)確認(rèn)影響面。**
比如直接封某個(gè) UDP 端口，可能把真實(shí)在線業(yè)務(wù)也一起干掉。
本次案例采取的是更穩(wěn)妥的方式：
- 對(duì)異常源進(jìn)程先摘流；
- 下調(diào)補(bǔ)償任務(wù)并發(fā)；
- 同時(shí)在出口做臨時(shí) rate-limit，防止再次沖滿。
這樣既能把鏈路從 930 Mbps 拉回安全區(qū)，也不會(huì)把業(yè)務(wù)一刀切打死。
### 2）根因修復(fù)要盯住三個(gè)點(diǎn)
這類問題后續(xù)修復(fù)，我建議必查三件事：
- **ACK 統(tǒng)計(jì)邏輯是否有誤判**；
- **重試退避機(jī)制是否缺失**；
- **單任務(wù)是否缺少發(fā)送上限與熔斷保護(hù)**。
如果只修一個(gè) bug，不補(bǔ)保護(hù)機(jī)制，這類事故大概率還會(huì)回來。
---
## 八、從工程治理看，真正缺的不是抓包工具，而是“持續(xù)可觀測(cè)性”
很多企業(yè)網(wǎng)絡(luò)排障仍然停留在：出事了才登錄機(jī)器、臨時(shí)跑 tcpdump、手工比對(duì)日志。
這種方式能破案，但不適合規(guī)?；\(yùn)維。原因很簡(jiǎn)單：
- 抓包依賴現(xiàn)場(chǎng)經(jīng)驗(yàn)；
- 證據(jù)鏈容易碎；
- 問題復(fù)盤難標(biāo)準(zhǔn)化；
- 跨團(tuán)隊(duì)協(xié)同成本高。
真正成熟的做法，應(yīng)該是把下面這些能力做成日?；A(chǔ)設(shè)施：
- 長(zhǎng)周期流量趨勢(shì)留存；
- Top Talker / Top Port 自動(dòng)畫像；
- 異常會(huì)話自動(dòng)聚合；
- 關(guān)鍵鏈路延遲、抖動(dòng)、丟包聯(lián)動(dòng)；
- 應(yīng)用指標(biāo)與網(wǎng)絡(luò)指標(biāo)統(tǒng)一關(guān)聯(lián)。
這樣你下次遇到“UDP 洪峰”時(shí)，不是從零開始抓嫌疑人，而是系統(tǒng)已經(jīng)把嫌疑范圍縮到 3 臺(tái)主機(jī)、1 個(gè)端口、1 條業(yè)務(wù)鏈路。
這才是排障效率真正躍遷的地方。
---
## 九、給一線運(yùn)維/網(wǎng)絡(luò)工程師的實(shí)戰(zhàn)排障清單
如果你也遇到類似場(chǎng)景，我建議按下面這份順序走：
### 快速排障 9 步法
1. 鎖定異常時(shí)間窗到分鐘級(jí)；
2. 確認(rèn)是否真實(shí)影響業(yè)務(wù)；
3. 看接口利用率、丟包、隊(duì)列；
4. 拉 Top Talker、Top Port、Top Protocol；
5. 先抓小樣本，不要直接全量抓；
6. 用會(huì)話聚合確認(rèn)主源/主目/主端口；
7. 分析包長(zhǎng)、節(jié)奏、payload 重復(fù)度；
8. 把主機(jī)進(jìn)程與業(yè)務(wù)日志對(duì)齊；
9. 先止血，再修復(fù)補(bǔ)償/重試邏輯。
看起來不復(fù)雜，但真正難的是：
- 不要跳步驟；
- 不要靠感覺；
- 不要把“高流量”直接等同于“網(wǎng)絡(luò)壞了”。
網(wǎng)絡(luò)排障最怕的是把結(jié)論下得太快。很多事故不是技術(shù)上難，而是誤判路徑太貴。
---
## 十、結(jié)論：抓包的價(jià)值，不在于抓到包，而在于抓到因果
這次案例最后復(fù)盤下來，真正的問題不是 UDP 本身，也不是交換機(jī)性能不夠，而是：
- 應(yīng)用層補(bǔ)償任務(wù)觸發(fā)；
- ACK 統(tǒng)計(jì)失真；
- 發(fā)送側(cè)缺少足夠保守的退避與熔斷；
- 網(wǎng)絡(luò)側(cè)先感知到的是“出口帶寬被打滿”。
所以一次優(yōu)秀的網(wǎng)絡(luò)故障排查，終點(diǎn)不該是“知道哪臺(tái)機(jī)器發(fā)了很多流量”，而應(yīng)該是：
> **把異常流量、業(yè)務(wù)行為和系統(tǒng)機(jī)制串成一條可復(fù)盤、可修復(fù)、可預(yù)防的因果鏈。**
這才叫真正解決問題。
如果你所在團(tuán)隊(duì)經(jīng)常遇到 **帶寬突增、UDP 異常、抓包困難、跨團(tuán)隊(duì)甩鍋、性能抖動(dòng)卻難定位** 這類問題，說明你們?nèi)钡耐皇窃俣嘁粋€(gè)監(jiān)控圖，而是更完整的網(wǎng)絡(luò)可觀測(cè)與流量分析體系。
AnaTraf（<www.anatraf.com>）這類網(wǎng)絡(luò)流量分析方案的價(jià)值，就在于把“看見異常”進(jìn)一步推進(jìn)到“快速歸因”，讓排障不再停留在經(jīng)驗(yàn)主義。
