絡(luò)故障模擬與抓包分析：TCP/UDP協(xié)議行為復(fù)現(xiàn)實戰(zhàn))
1. 網(wǎng)絡(luò)故障模擬到底在模擬什么第一次接觸“網(wǎng)絡(luò)故障模擬”這個說法的人腦子里冒出來的畫面往往是機房著火、交換機冒煙、網(wǎng)線被老鼠咬斷。但真正做過抓包分析的人都知道日常工作中遇到的絕大多數(shù)“網(wǎng)絡(luò)故障”其實根本不是硬件壞了而是協(xié)議行為不符合預(yù)期——TCP 該重傳的時候沒重傳UDP 該丟包的時候丟得莫名其妙握手該三次的時候偏偏只走了兩次。這些東西你在應(yīng)用層是看不出來的日志里只會寫一句“連接超時”然后就沒有然后了。所以網(wǎng)絡(luò)故障模擬的核心不是去制造物理損壞而是在可控環(huán)境下復(fù)現(xiàn)那些“看起來像故障”的協(xié)議行為再用抓包工具把整個過程錄下來逐幀分析。TCP 和 UDP 是繞不開的兩個主角TCP 面向連接、有狀態(tài)、有重傳機制它的故障往往表現(xiàn)為握手失敗、窗口凍結(jié)、RST 異常、重傳風(fēng)暴UDP 無連接、無狀態(tài)、不保證送達(dá)它的故障更多體現(xiàn)在丟包、亂序、重復(fù)、MTU 分片問題上。兩者的排查思路完全不同抓包時的過濾策略也不一樣。這套東西適合誰我個人的判斷是三類人最需要一是剛?cè)胄械倪\維或后端開發(fā)線上出了問題只會重啟服務(wù)想往深了走必須懂抓包二是做物聯(lián)網(wǎng)、音視頻、游戲這類對 UDP 依賴很重的開發(fā)者UDP 的問題不抓包基本靠猜三是準(zhǔn)備面試網(wǎng)絡(luò)相關(guān)崗位的人TCP 三次握手四次揮手背得再熟不如自己抓一次包看一遍來得扎實。接下來我會按照“先搭環(huán)境、再制造故障、然后抓包、最后逐幀分析”的順序把整個流程拆開講。中間會穿插大量我實際踩過的坑比如為什么你抓到的包總是缺幀、為什么 Wireshark 顯示的“重傳”有時候是誤報、為什么 UDP 抓包過濾規(guī)則寫錯了會漏掉關(guān)鍵數(shù)據(jù)。這些細(xì)節(jié)文檔里通常不會寫但恰恰是決定你能不能定位到問題的關(guān)鍵。2. 動手之前環(huán)境搭建與工具選型2.1 抓包工具的取舍邏輯抓包工具市面上主流的就是 Wireshark、tcpdump再加上一些命令行小工具。我的建議是兩個都要會但分工明確。Wireshark 是圖形化分析的主力優(yōu)勢在于協(xié)議解碼極其完整TCP 的每一個標(biāo)志位、每一個選項字段都能展開看還能自動標(biāo)記重傳、亂序、重復(fù) ACK。但它的劣勢也很明顯在服務(wù)器上跑圖形界面不現(xiàn)實而且抓大流量的時候內(nèi)存吃得厲害。tcpdump 則是服務(wù)器端的標(biāo)配幾乎任何 Linux 發(fā)行版都自帶或者一條命令就能裝它負(fù)責(zé)“抓”把包存成 pcap 文件然后拉到本地用 Wireshark 分析。這個“服務(wù)器抓、本地析”的組合是我用得最多的。至于故障模擬工具Linux 下最順手的是tctraffic control配合netem模塊可以模擬延遲、丟包、亂序、重復(fù)、損壞。Windows 下可以用 Clumsy 這類工具但功能沒 tc 細(xì)。如果你只是想模擬應(yīng)用層的連接異常用iptables直接 DROP 或 REJECT 某些包也能達(dá)到目的而且更簡單粗暴。提示不要一上來就上復(fù)雜工具。很多“故障”用 iptables 一條規(guī)則就能造出來比如直接丟棄 SYN 包模擬服務(wù)不可達(dá)比配置 tc 快得多。2.2 實驗環(huán)境的搭建步驟我習(xí)慣用兩臺 Linux 虛擬機加一臺宿主機來做這套實驗。一臺當(dāng)客戶端一臺當(dāng)服務(wù)端宿主機用來跑 Wireshark 分析。網(wǎng)絡(luò)模式用 NAT 或者僅主機模式都行關(guān)鍵是兩臺機器能互通且你能控制它們之間的流量。具體步驟兩臺虛擬機都裝好基礎(chǔ)系統(tǒng)確認(rèn)ping能通。服務(wù)端裝一個簡單的 TCP 服務(wù)和 UDP 服務(wù)。TCP 用nc -l或者 Python 的 socket 都行UDP 同理。我一般用 Python 寫個十幾行的小腳本方便控制收發(fā)邏輯。客戶端裝tcpdump服務(wù)端也裝因為有時候需要兩端同時抓包對比。宿主機裝 Wireshark用來打開 pcap 文件。確認(rèn)tc可用tc qdisc show能輸出內(nèi)容就說明沒問題。這里有個容易被忽略的點虛擬機的網(wǎng)卡類型會影響抓包結(jié)果。如果你用的是 virtio 網(wǎng)卡某些情況下 TCP 校驗和卸載checksum offload會導(dǎo)致 Wireshark 顯示校驗和錯誤但那其實是網(wǎng)卡卸載造成的假象不是真的錯誤。解決辦法是在 Wireshark 里關(guān)掉校驗和驗證或者用ethtool -K eth0 tx off rx off關(guān)掉卸載。這個坑我踩過不止一次一開始以為是數(shù)據(jù)包損壞查了半天才發(fā)現(xiàn)是卸載的鍋。2.3 抓包過濾規(guī)則的正確寫法抓包時最忌諱的就是“全抓”。全抓的后果是文件巨大、噪音極多分析的時候光過濾就浪費半小時。正確的做法是在抓的時候就過濾而不是抓完再過濾。tcpdump 的過濾表達(dá)式基于 BPF 語法幾個我常用的# 只抓某臺主機的 TCP 流量 tcpdump -i eth0 -w tcp.pcap host 192.168.1.100 and tcp # 只抓某個端口且排除 SSH 自身流量 tcpdump -i eth0 -w udp.pcap udp port 9999 # 抓 TCP 握手和揮手相關(guān)的包 tcpdump -i eth0 -w handshake.pcap tcp[tcpflags] (tcp-syn|tcp-fin|tcp-rst) ! 0Wireshark 的顯示過濾器則是另一套語法常用的有tcp.analysis.retransmission看重傳、tcp.flags.reset 1看 RST、udp.length 100按長度過濾。注意區(qū)分捕獲過濾器和顯示過濾器前者在抓的時候就生效后者只是隱藏不匹配的包文件里其實還在。注意抓包時加-s 0表示抓完整包不加的話默認(rèn)只抓前 96 字節(jié)TCP 選項字段可能被截斷分析握手參數(shù)時會缺信息。這個細(xì)節(jié)很多人不知道導(dǎo)致抓到的包“看起來正?！钡治霾涣?。3. TCP 故障模擬與抓包實戰(zhàn)3.1 三次握手失敗的三種典型場景TCP 故障里最基礎(chǔ)也最?？嫉木褪俏帐质 Ｎ野阉殖扇NSYN 丟失、SYN-ACK 丟失、ACK 丟失。三種情況在抓包結(jié)果上表現(xiàn)完全不同排查方向也不一樣。場景一SYN 丟失?？蛻舳税l(fā)出 SYN 后服務(wù)端根本沒收到所以不會有任何回應(yīng)。抓包看到的是客戶端反復(fù)重發(fā) SYN間隔按 1s、2s、4s、8s 指數(shù)退避重試幾次后放棄報“連接超時”。這種故障通常意味著網(wǎng)絡(luò)路徑不通、防火墻攔截或者服務(wù)端根本沒在監(jiān)聽。模擬方法很簡單在服務(wù)端用 iptables 丟棄入站 SYNiptables -A INPUT -p tcp --dport 8080 --syn -j DROP抓包分析時重點看客戶端 SYN 的序列號是否每次相同相同說明是重傳不是新連接、重傳間隔是否符合指數(shù)退避、有沒有收到任何回應(yīng)。場景二SYN-ACK 丟失。服務(wù)端收到了 SYN回了 SYN-ACK但這個回應(yīng)在回程路上丟了。客戶端視角和場景一一樣也是反復(fù)重發(fā) SYN。但如果你在服務(wù)端抓包會看到服務(wù)端其實回了 SYN-ACK而且可能回了多次因為服務(wù)端也在重傳。這種故障的迷惑性在于客戶端和服務(wù)端的抓包結(jié)果對不上一個說“我發(fā)了你沒回”一個說“我回了你沒收到”。這時候兩端同時抓包對比就非常關(guān)鍵。場景三ACK 丟失。這個最隱蔽。服務(wù)端收到 SYN回 SYN-ACK客戶端收到后回 ACK但 ACK 丟了。服務(wù)端會認(rèn)為握手沒完成重傳 SYN-ACK客戶端認(rèn)為自己已經(jīng) ESTABLISHED 了收到重復(fù)的 SYN-ACK 會覺得奇怪。抓包時能看到服務(wù)端反復(fù)重傳 SYN-ACK而客戶端可能已經(jīng)開始發(fā)數(shù)據(jù)了。這種“半開連接”狀態(tài)是很多詭異問題的根源。3.2 用 tc netem 制造可控的丟包和延遲iptables 只能做“丟”或“不丟”的二元選擇想要更精細(xì)的控制比如“丟 30% 的包”“延遲 200ms 且抖動 50ms”就得上 tc netem。# 在 eth0 上添加 30% 丟包 tc qdisc add dev eth0 root netem loss 30% # 添加 200ms 延遲抖動 50ms tc qdisc add dev eth0 root netem delay 200ms 50ms # 模擬亂序25% 的包延遲 10ms 發(fā)送 tc qdisc add dev eth0 root netem delay 10ms reorder 25% # 用完記得刪除否則一直生效 tc qdisc del dev eth0 root這里有個實操心得netem 的丟包是隨機的不可復(fù)現(xiàn)。同樣的配置跑兩次丟的包不一樣。如果你需要精確復(fù)現(xiàn)某個故障場景netem 不太合適得用更底層的手段比如自己寫個代理程序按規(guī)則丟包。但對于學(xué)習(xí)抓包分析來說隨機丟包已經(jīng)足夠制造出重傳、重復(fù) ACK、快速重傳這些現(xiàn)象了。我一般會這樣設(shè)計實驗先建立正常連接抓一份“健康”的包作為基線然后加上 netem 丟包再抓一份“故障”的包兩份對比著看差異一目了然。沒有基線對比你很難判斷某個現(xiàn)象是正常的還是異常的。3.3 重傳與快速重傳的抓包識別TCP 重傳分兩種超時重傳和快速重傳。超時重傳是發(fā)送方等不到 ACK超過 RTO 時間后重發(fā)快速重傳是發(fā)送方收到三個重復(fù) ACK 后立即重發(fā)不等超時。在 Wireshark 里超時重傳會被標(biāo)記為TCP Retransmission快速重傳標(biāo)記為TCP Fast Retransmission。但要注意Wireshark 的標(biāo)記有時候是誤報。比如它可能把正常的重傳當(dāng)成異常或者因為抓包點位置不對而誤判。判斷重傳是否真的發(fā)生了最可靠的方法是看序列號如果兩個包的序列號相同、載荷相同那就是重傳。重復(fù) ACK 的識別也有講究。接收方收到亂序的包時會重復(fù)發(fā)送最后一個按序到達(dá)的 ACK告訴發(fā)送方“我還在等某個序列號的包”。收到三個重復(fù) ACK發(fā)送方就觸發(fā)快速重傳。抓包時看到連續(xù)的、ACK 號相同的包基本就是重復(fù) ACK 了。提示分析重傳時把 Wireshark 的“相對序列號”打開默認(rèn)就是開的比看絕對序列號直觀得多。絕對序列號是一串大數(shù)字相對序列號從 0 開始一眼就能看出哪個包重傳了。3.4 RST 異常的排查思路RST 包是 TCP 里的“急剎車”收到 RST 意味著連接被強制終止。RST 出現(xiàn)的原因很多連接到一個沒監(jiān)聽的端口、防火墻主動拒絕、應(yīng)用層主動關(guān)閉、半開連接收到數(shù)據(jù)等。排查 RST 的第一步是看 RST 是誰發(fā)的、在什么階段發(fā)的。如果是握手階段服務(wù)端回 RST說明端口沒監(jiān)聽或者被防火墻 REJECT 了。如果是數(shù)據(jù)傳輸階段某一方發(fā) RST可能是應(yīng)用崩潰或者主動關(guān)閉。如果是連接空閑很久后突然 RST可能是中間設(shè)備清理了會話表。我遇到過一個很典型的案例客戶端連接服務(wù)端握手正常發(fā)第一個請求也正常但發(fā)第二個請求時收到 RST。抓包發(fā)現(xiàn)服務(wù)端在收到第二個請求后立即回了 RST。查下來是服務(wù)端的連接池配置有問題第一個請求處理完后連接被錯誤地關(guān)閉了但客戶端不知道繼續(xù)復(fù)用這個連接服務(wù)端收到數(shù)據(jù)后發(fā)現(xiàn)連接已經(jīng)不存在只能回 RST。這種問題不看抓包根本定位不到。4. UDP 故障模擬與抓包實戰(zhàn)4.1 UDP 抓包的特殊性UDP 和 TCP 在抓包分析上的最大區(qū)別是UDP 沒有連接狀態(tài)沒有握手揮手沒有重傳機制。這意味著你抓到的每一個 UDP 包都是獨立的不存在“這個包屬于哪個連接”的概念除非應(yīng)用層自己定義了會話 ID。這給分析帶來了兩個困難一是無法通過握手判斷通信是否正常建立二是丟包后沒有任何協(xié)議層的補償只能靠應(yīng)用層自己處理。抓 UDP 包時過濾規(guī)則要更精確。因為 UDP 沒有標(biāo)志位你只能按端口、按 IP、按長度來過濾。我常用的# 按端口抓 tcpdump -i eth0 -w udp.pcap udp port 9999 # 按源或目的 IP 抓 tcpdump -i eth0 -w udp.pcap udp and host 192.168.1.100 # 排除某個端口避免抓到噪音 tcpdump -i eth0 -w udp.pcap udp and not port 53Wireshark 里分析 UDP 時我建議打開“協(xié)議層次統(tǒng)計”和“會話統(tǒng)計”能快速看出哪些 IP 對之間流量最大、包數(shù)量是否對稱。UDP 的故障往往表現(xiàn)為“一方發(fā)了很多另一方收得很少”這種不對稱在統(tǒng)計圖里一眼就能看出來。4.2 丟包、亂序、重復(fù)的模擬與識別UDP 的故障模擬和 TCP 類似也是用 tc netem但因為 UDP 沒有重傳丟包的影響更直接。# 模擬 20% 丟包 tc qdisc add dev eth0 root netem loss 20% # 模擬亂序 tc qdisc add dev eth0 root netem delay 5ms reorder 50% 50% # 模擬重復(fù) tc qdisc add dev eth0 root netem duplicate 10%識別丟包的方法在發(fā)送端和接收端同時抓包對比兩邊的包序列號如果應(yīng)用層有序列號的話。發(fā)送端發(fā)了 100 個包接收端只收到 80 個那 20 個就是丟了。如果應(yīng)用層沒有序列號那就只能靠包的數(shù)量和內(nèi)容來推斷難度大很多。這也是為什么我強烈建議自研的 UDP 協(xié)議一定要在應(yīng)用層加序列號不然出了問題根本沒法排查。亂序的識別接收端收到的包序列號不是遞增的比如收到 1、2、4、3、5。Wireshark 本身不會標(biāo)記 UDP 亂序因為它不知道你的序列號規(guī)則你得自己看載荷里的序列號字段。重復(fù)的識別同一個序列號的包出現(xiàn)了兩次。netem 的 duplicate 是隨機復(fù)制所以你會看到某些包莫名其妙出現(xiàn)兩遍。4.3 MTU 與分片問題的抓包分析UDP 還有一個 TCP 不太會遇到的問題分片。UDP 包如果超過 MTUIP 層會把它分片。分片本身不是故障但分片會帶來兩個隱患一是任何一片丟失整個 UDP 包就廢了而 UDP 不會重傳二是某些防火墻或 NAT 設(shè)備對分片的處理不一致可能導(dǎo)致分片被丟棄或重組失敗。抓包時識別分片看 IP 頭的Flags字段MFMore Fragments為 1 表示后面還有分片F(xiàn)ragment Offset不為 0 表示這是后續(xù)分片。Wireshark 會把同一個 UDP 包的分片標(biāo)記出來但需要你手動開啟“重組”功能才能看到完整的載荷。我遇到過一個經(jīng)典問題客戶端發(fā)一個 2000 字節(jié)的 UDP 包服務(wù)端收不到。抓包發(fā)現(xiàn)包被分成了兩片第一片到了第二片丟了。因為 UDP 不重傳服務(wù)端重組失敗整個包被丟棄。解決辦法要么是減小包大小避免分片要么是在應(yīng)用層做分片和重傳。這個問題的隱蔽性在于小包測試一切正常一大包就出問題很容易誤判為“服務(wù)端處理能力不足”。注意路徑 MTU 發(fā)現(xiàn)PMTUD在 UDP 場景下經(jīng)常失效因為很多防火墻會丟棄 ICMP 的“需要分片”消息。所以 UDP 應(yīng)用最好自己控制包大小不要依賴 PMTUD。5. 常見問題與排查技巧實錄5.1 抓包抓不到包的幾個原因這是新手最常遇到的問題明明配置了抓包但一個包都沒有。我總結(jié)了幾種可能現(xiàn)象可能原因排查方法完全沒包網(wǎng)卡選錯了ip a確認(rèn)流量走哪塊網(wǎng)卡只有單向包抓包點位置不對在兩端同時抓對比包不完整沒加-s 0重新抓指定 snaplen過濾太嚴(yán)表達(dá)式寫錯先不加過濾抓確認(rèn)有流量再逐步加權(quán)限不足沒用 rootsudo tcpdump還有一個隱蔽的原因流量走了 loopback。如果客戶端和服務(wù)端在同一臺機器上流量走的是lo網(wǎng)卡你在eth0上抓是抓不到的。這個坑我踩過當(dāng)時以為是防火墻問題查了半天才發(fā)現(xiàn)是網(wǎng)卡選錯了。5.2 Wireshark 分析中的誤報與陷阱Wireshark 很強大但它的自動分析功能有時候會誤導(dǎo)人。幾個常見的誤報校驗和錯誤誤報。前面提過網(wǎng)卡卸載會導(dǎo)致 Wireshark 顯示校驗和錯誤但實際包是好的。解決辦法是關(guān)掉校驗和驗證或者關(guān)掉網(wǎng)卡卸載。重傳誤報。Wireshark 判斷重傳是基于序列號和時間的如果抓包點位置特殊比如在發(fā)送方和接收方之間的中間設(shè)備上抓可能會把正常的包誤判為重傳。亂序誤報。多路徑或者抓包點不對稱時Wireshark 可能把正常到達(dá)的包標(biāo)記為亂序。我的經(jīng)驗是永遠(yuǎn)不要只信 Wireshark 的標(biāo)記要自己看序列號、看時間戳、看載荷。標(biāo)記只是提示最終判斷得靠數(shù)據(jù)本身。5.3 從抓包到定位問題的完整思路抓包只是手段定位問題才是目的。我一般的分析流程是先看整體用 Wireshark 的“統(tǒng)計”功能看包數(shù)量、會話分布、協(xié)議分布快速定位異常點。再看異常過濾出重傳、RST、重復(fù) ACK、ICMP 錯誤等異常包看它們集中在哪個時間段、哪對 IP 之間。然后看細(xì)節(jié)針對異常包展開協(xié)議樹看序列號、標(biāo)志位、選項字段、載荷內(nèi)容。最后做對比和正常情況的抓包對比找出差異。沒有對比就沒有判斷。這個流程說起來簡單但實際操作中最難的是第 4 步。很多人抓了包看到一堆重傳就慌了但其實如果基線抓包里也有重傳那說明重傳在這個網(wǎng)絡(luò)環(huán)境下是正常的不是故障原因。建立基線這個習(xí)慣是我做抓包分析這些年最重要的經(jīng)驗。5.4 幾個提升效率的小技巧Wireshark 的“追蹤 TCP 流”功能Follow TCP Stream能把一個連接的所有載荷拼起來看分析應(yīng)用層協(xié)議時特別有用。UDP 沒有流的概念但可以用“追蹤 UDP 流”看一段時間內(nèi)的所有包。給 pcap 文件命名時帶上時間、場景、過濾條件比如20240115_tcp_retrans_loss30.pcap過幾天回頭看還能想起來是什么實驗。分析大文件時先用editcap按時間或包數(shù)量切分再逐段分析比一次性打開幾百兆的文件流暢得多。如果需要在多臺機器上同時抓包用tcpdump的-w寫到文件然后統(tǒng)一拉到一臺機器上用 Wireshark 的“合并”功能合并注意時間同步問題機器之間時間差太大會導(dǎo)致合并后的時間線錯亂。最后分享一個我個人的習(xí)慣每次做完故障模擬實驗我都會把抓包文件、分析筆記、結(jié)論整理成一個文檔存檔。下次遇到類似問題直接翻文檔比重新抓包分析快得多。網(wǎng)絡(luò)故障這東西太陽底下沒有新鮮事你遇到過的大概率別人也遇到過只是你當(dāng)時沒記下來而已。 網(wǎng)絡(luò)故障模擬與抓包分析：TCP/UDP協(xié)議行為復(fù)現(xiàn)實戰(zhàn)
1. 網(wǎng)絡(luò)故障模擬到底在模擬什么第一次接觸“網(wǎng)絡(luò)故障模擬”這個說法的人腦子里冒出來的畫面往往是機房著火、交換機冒煙、網(wǎng)線被老鼠咬斷。但真正做過抓包分析的人都知道日常工作中遇到的絕大多數(shù)“網(wǎng)絡(luò)故障”其實根本不是硬件壞了而是協(xié)議行為不符合預(yù)期——TCP 該重傳的時候沒重傳UDP 該丟包的時候丟得莫名其妙握手該三次的時候偏偏只走了兩次。這些東西你在應(yīng)用層是看不出來的日志里只會寫一句“連接超時”然后就沒有然后了。所以網(wǎng)絡(luò)故障模擬的核心不是去制造物理損壞而是在可控環(huán)境下復(fù)現(xiàn)那些“看起來像故障”的協(xié)議行為再用抓包工具把整個過程錄下來逐幀分析。TCP 和 UDP 是繞不開的兩個主角TCP 面向連接、有狀態(tài)、有重傳機制它的故障往往表現(xiàn)為握手失敗、窗口凍結(jié)、RST 異常、重傳風(fēng)暴UDP 無連接、無狀態(tài)、不保證送達(dá)它的故障更多體現(xiàn)在丟包、亂序、重復(fù)、MTU 分片問題上。兩者的排查思路完全不同抓包時的過濾策略也不一樣。這套東西適合誰我個人的判斷是三類人最需要一是剛?cè)胄械倪\維或后端開發(fā)線上出了問題只會重啟服務(wù)想往深了走必須懂抓包二是做物聯(lián)網(wǎng)、音視頻、游戲這類對 UDP 依賴很重的開發(fā)者UDP 的問題不抓包基本靠猜三是準(zhǔn)備面試網(wǎng)絡(luò)相關(guān)崗位的人TCP 三次握手四次揮手背得再熟不如自己抓一次包看一遍來得扎實。接下來我會按照“先搭環(huán)境、再制造故障、然后抓包、最后逐幀分析”的順序把整個流程拆開講。中間會穿插大量我實際踩過的坑比如為什么你抓到的包總是缺幀、為什么 Wireshark 顯示的“重傳”有時候是誤報、為什么 UDP 抓包過濾規(guī)則寫錯了會漏掉關(guān)鍵數(shù)據(jù)。這些細(xì)節(jié)文檔里通常不會寫但恰恰是決定你能不能定位到問題的關(guān)鍵。2. 動手之前環(huán)境搭建與工具選型2.1 抓包工具的取舍邏輯抓包工具市面上主流的就是 Wireshark、tcpdump再加上一些命令行小工具。我的建議是兩個都要會但分工明確。Wireshark 是圖形化分析的主力優(yōu)勢在于協(xié)議解碼極其完整TCP 的每一個標(biāo)志位、每一個選項字段都能展開看還能自動標(biāo)記重傳、亂序、重復(fù) ACK。但它的劣勢也很明顯在服務(wù)器上跑圖形界面不現(xiàn)實而且抓大流量的時候內(nèi)存吃得厲害。tcpdump 則是服務(wù)器端的標(biāo)配幾乎任何 Linux 發(fā)行版都自帶或者一條命令就能裝它負(fù)責(zé)“抓”把包存成 pcap 文件然后拉到本地用 Wireshark 分析。這個“服務(wù)器抓、本地析”的組合是我用得最多的。至于故障模擬工具Linux 下最順手的是tctraffic control配合netem模塊可以模擬延遲、丟包、亂序、重復(fù)、損壞。Windows 下可以用 Clumsy 這類工具但功能沒 tc 細(xì)。如果你只是想模擬應(yīng)用層的連接異常用iptables直接 DROP 或 REJECT 某些包也能達(dá)到目的而且更簡單粗暴。提示不要一上來就上復(fù)雜工具。很多“故障”用 iptables 一條規(guī)則就能造出來比如直接丟棄 SYN 包模擬服務(wù)不可達(dá)比配置 tc 快得多。2.2 實驗環(huán)境的搭建步驟我習(xí)慣用兩臺 Linux 虛擬機加一臺宿主機來做這套實驗。一臺當(dāng)客戶端一臺當(dāng)服務(wù)端宿主機用來跑 Wireshark 分析。網(wǎng)絡(luò)模式用 NAT 或者僅主機模式都行關(guān)鍵是兩臺機器能互通且你能控制它們之間的流量。具體步驟兩臺虛擬機都裝好基礎(chǔ)系統(tǒng)確認(rèn)ping能通。服務(wù)端裝一個簡單的 TCP 服務(wù)和 UDP 服務(wù)。TCP 用nc -l或者 Python 的 socket 都行UDP 同理。我一般用 Python 寫個十幾行的小腳本方便控制收發(fā)邏輯。客戶端裝tcpdump服務(wù)端也裝因為有時候需要兩端同時抓包對比。宿主機裝 Wireshark用來打開 pcap 文件。確認(rèn)tc可用tc qdisc show能輸出內(nèi)容就說明沒問題。這里有個容易被忽略的點虛擬機的網(wǎng)卡類型會影響抓包結(jié)果。如果你用的是 virtio 網(wǎng)卡某些情況下 TCP 校驗和卸載checksum offload會導(dǎo)致 Wireshark 顯示校驗和錯誤但那其實是網(wǎng)卡卸載造成的假象不是真的錯誤。解決辦法是在 Wireshark 里關(guān)掉校驗和驗證或者用ethtool -K eth0 tx off rx off關(guān)掉卸載。這個坑我踩過不止一次一開始以為是數(shù)據(jù)包損壞查了半天才發(fā)現(xiàn)是卸載的鍋。2.3 抓包過濾規(guī)則的正確寫法抓包時最忌諱的就是“全抓”。全抓的后果是文件巨大、噪音極多分析的時候光過濾就浪費半小時。正確的做法是在抓的時候就過濾而不是抓完再過濾。tcpdump 的過濾表達(dá)式基于 BPF 語法幾個我常用的# 只抓某臺主機的 TCP 流量 tcpdump -i eth0 -w tcp.pcap host 192.168.1.100 and tcp # 只抓某個端口且排除 SSH 自身流量 tcpdump -i eth0 -w udp.pcap udp port 9999 # 抓 TCP 握手和揮手相關(guān)的包 tcpdump -i eth0 -w handshake.pcap tcp[tcpflags] (tcp-syn|tcp-fin|tcp-rst) ! 0Wireshark 的顯示過濾器則是另一套語法常用的有tcp.analysis.retransmission看重傳、tcp.flags.reset 1看 RST、udp.length 100按長度過濾。注意區(qū)分捕獲過濾器和顯示過濾器前者在抓的時候就生效后者只是隱藏不匹配的包文件里其實還在。注意抓包時加-s 0表示抓完整包不加的話默認(rèn)只抓前 96 字節(jié)TCP 選項字段可能被截斷分析握手參數(shù)時會缺信息。這個細(xì)節(jié)很多人不知道導(dǎo)致抓到的包“看起來正?！钡治霾涣?。3. TCP 故障模擬與抓包實戰(zhàn)3.1 三次握手失敗的三種典型場景TCP 故障里最基礎(chǔ)也最?？嫉木褪俏帐质 Ｎ野阉殖扇NSYN 丟失、SYN-ACK 丟失、ACK 丟失。三種情況在抓包結(jié)果上表現(xiàn)完全不同排查方向也不一樣。場景一SYN 丟失?？蛻舳税l(fā)出 SYN 后服務(wù)端根本沒收到所以不會有任何回應(yīng)。抓包看到的是客戶端反復(fù)重發(fā) SYN間隔按 1s、2s、4s、8s 指數(shù)退避重試幾次后放棄報“連接超時”。這種故障通常意味著網(wǎng)絡(luò)路徑不通、防火墻攔截或者服務(wù)端根本沒在監(jiān)聽。模擬方法很簡單在服務(wù)端用 iptables 丟棄入站 SYNiptables -A INPUT -p tcp --dport 8080 --syn -j DROP抓包分析時重點看客戶端 SYN 的序列號是否每次相同相同說明是重傳不是新連接、重傳間隔是否符合指數(shù)退避、有沒有收到任何回應(yīng)。場景二SYN-ACK 丟失。服務(wù)端收到了 SYN回了 SYN-ACK但這個回應(yīng)在回程路上丟了。客戶端視角和場景一一樣也是反復(fù)重發(fā) SYN。但如果你在服務(wù)端抓包會看到服務(wù)端其實回了 SYN-ACK而且可能回了多次因為服務(wù)端也在重傳。這種故障的迷惑性在于客戶端和服務(wù)端的抓包結(jié)果對不上一個說“我發(fā)了你沒回”一個說“我回了你沒收到”。這時候兩端同時抓包對比就非常關(guān)鍵。場景三ACK 丟失。這個最隱蔽。服務(wù)端收到 SYN回 SYN-ACK客戶端收到后回 ACK但 ACK 丟了。服務(wù)端會認(rèn)為握手沒完成重傳 SYN-ACK客戶端認(rèn)為自己已經(jīng) ESTABLISHED 了收到重復(fù)的 SYN-ACK 會覺得奇怪。抓包時能看到服務(wù)端反復(fù)重傳 SYN-ACK而客戶端可能已經(jīng)開始發(fā)數(shù)據(jù)了。這種“半開連接”狀態(tài)是很多詭異問題的根源。3.2 用 tc netem 制造可控的丟包和延遲iptables 只能做“丟”或“不丟”的二元選擇想要更精細(xì)的控制比如“丟 30% 的包”“延遲 200ms 且抖動 50ms”就得上 tc netem。# 在 eth0 上添加 30% 丟包 tc qdisc add dev eth0 root netem loss 30% # 添加 200ms 延遲抖動 50ms tc qdisc add dev eth0 root netem delay 200ms 50ms # 模擬亂序25% 的包延遲 10ms 發(fā)送 tc qdisc add dev eth0 root netem delay 10ms reorder 25% # 用完記得刪除否則一直生效 tc qdisc del dev eth0 root這里有個實操心得netem 的丟包是隨機的不可復(fù)現(xiàn)。同樣的配置跑兩次丟的包不一樣。如果你需要精確復(fù)現(xiàn)某個故障場景netem 不太合適得用更底層的手段比如自己寫個代理程序按規(guī)則丟包。但對于學(xué)習(xí)抓包分析來說隨機丟包已經(jīng)足夠制造出重傳、重復(fù) ACK、快速重傳這些現(xiàn)象了。我一般會這樣設(shè)計實驗先建立正常連接抓一份“健康”的包作為基線然后加上 netem 丟包再抓一份“故障”的包兩份對比著看差異一目了然。沒有基線對比你很難判斷某個現(xiàn)象是正常的還是異常的。3.3 重傳與快速重傳的抓包識別TCP 重傳分兩種超時重傳和快速重傳。超時重傳是發(fā)送方等不到 ACK超過 RTO 時間后重發(fā)快速重傳是發(fā)送方收到三個重復(fù) ACK 后立即重發(fā)不等超時。在 Wireshark 里超時重傳會被標(biāo)記為TCP Retransmission快速重傳標(biāo)記為TCP Fast Retransmission。但要注意Wireshark 的標(biāo)記有時候是誤報。比如它可能把正常的重傳當(dāng)成異常或者因為抓包點位置不對而誤判。判斷重傳是否真的發(fā)生了最可靠的方法是看序列號如果兩個包的序列號相同、載荷相同那就是重傳。重復(fù) ACK 的識別也有講究。接收方收到亂序的包時會重復(fù)發(fā)送最后一個按序到達(dá)的 ACK告訴發(fā)送方“我還在等某個序列號的包”。收到三個重復(fù) ACK發(fā)送方就觸發(fā)快速重傳。抓包時看到連續(xù)的、ACK 號相同的包基本就是重復(fù) ACK 了。提示分析重傳時把 Wireshark 的“相對序列號”打開默認(rèn)就是開的比看絕對序列號直觀得多。絕對序列號是一串大數(shù)字相對序列號從 0 開始一眼就能看出哪個包重傳了。3.4 RST 異常的排查思路RST 包是 TCP 里的“急剎車”收到 RST 意味著連接被強制終止。RST 出現(xiàn)的原因很多連接到一個沒監(jiān)聽的端口、防火墻主動拒絕、應(yīng)用層主動關(guān)閉、半開連接收到數(shù)據(jù)等。排查 RST 的第一步是看 RST 是誰發(fā)的、在什么階段發(fā)的。如果是握手階段服務(wù)端回 RST說明端口沒監(jiān)聽或者被防火墻 REJECT 了。如果是數(shù)據(jù)傳輸階段某一方發(fā) RST可能是應(yīng)用崩潰或者主動關(guān)閉。如果是連接空閑很久后突然 RST可能是中間設(shè)備清理了會話表。我遇到過一個很典型的案例客戶端連接服務(wù)端握手正常發(fā)第一個請求也正常但發(fā)第二個請求時收到 RST。抓包發(fā)現(xiàn)服務(wù)端在收到第二個請求后立即回了 RST。查下來是服務(wù)端的連接池配置有問題第一個請求處理完后連接被錯誤地關(guān)閉了但客戶端不知道繼續(xù)復(fù)用這個連接服務(wù)端收到數(shù)據(jù)后發(fā)現(xiàn)連接已經(jīng)不存在只能回 RST。這種問題不看抓包根本定位不到。4. UDP 故障模擬與抓包實戰(zhàn)4.1 UDP 抓包的特殊性UDP 和 TCP 在抓包分析上的最大區(qū)別是UDP 沒有連接狀態(tài)沒有握手揮手沒有重傳機制。這意味著你抓到的每一個 UDP 包都是獨立的不存在“這個包屬于哪個連接”的概念除非應(yīng)用層自己定義了會話 ID。這給分析帶來了兩個困難一是無法通過握手判斷通信是否正常建立二是丟包后沒有任何協(xié)議層的補償只能靠應(yīng)用層自己處理。抓 UDP 包時過濾規(guī)則要更精確。因為 UDP 沒有標(biāo)志位你只能按端口、按 IP、按長度來過濾。我常用的# 按端口抓 tcpdump -i eth0 -w udp.pcap udp port 9999 # 按源或目的 IP 抓 tcpdump -i eth0 -w udp.pcap udp and host 192.168.1.100 # 排除某個端口避免抓到噪音 tcpdump -i eth0 -w udp.pcap udp and not port 53Wireshark 里分析 UDP 時我建議打開“協(xié)議層次統(tǒng)計”和“會話統(tǒng)計”能快速看出哪些 IP 對之間流量最大、包數(shù)量是否對稱。UDP 的故障往往表現(xiàn)為“一方發(fā)了很多另一方收得很少”這種不對稱在統(tǒng)計圖里一眼就能看出來。4.2 丟包、亂序、重復(fù)的模擬與識別UDP 的故障模擬和 TCP 類似也是用 tc netem但因為 UDP 沒有重傳丟包的影響更直接。# 模擬 20% 丟包 tc qdisc add dev eth0 root netem loss 20% # 模擬亂序 tc qdisc add dev eth0 root netem delay 5ms reorder 50% 50% # 模擬重復(fù) tc qdisc add dev eth0 root netem duplicate 10%識別丟包的方法在發(fā)送端和接收端同時抓包對比兩邊的包序列號如果應(yīng)用層有序列號的話。發(fā)送端發(fā)了 100 個包接收端只收到 80 個那 20 個就是丟了。如果應(yīng)用層沒有序列號那就只能靠包的數(shù)量和內(nèi)容來推斷難度大很多。這也是為什么我強烈建議自研的 UDP 協(xié)議一定要在應(yīng)用層加序列號不然出了問題根本沒法排查。亂序的識別接收端收到的包序列號不是遞增的比如收到 1、2、4、3、5。Wireshark 本身不會標(biāo)記 UDP 亂序因為它不知道你的序列號規(guī)則你得自己看載荷里的序列號字段。重復(fù)的識別同一個序列號的包出現(xiàn)了兩次。netem 的 duplicate 是隨機復(fù)制所以你會看到某些包莫名其妙出現(xiàn)兩遍。4.3 MTU 與分片問題的抓包分析UDP 還有一個 TCP 不太會遇到的問題分片。UDP 包如果超過 MTUIP 層會把它分片。分片本身不是故障但分片會帶來兩個隱患一是任何一片丟失整個 UDP 包就廢了而 UDP 不會重傳二是某些防火墻或 NAT 設(shè)備對分片的處理不一致可能導(dǎo)致分片被丟棄或重組失敗。抓包時識別分片看 IP 頭的Flags字段MFMore Fragments為 1 表示后面還有分片F(xiàn)ragment Offset不為 0 表示這是后續(xù)分片。Wireshark 會把同一個 UDP 包的分片標(biāo)記出來但需要你手動開啟“重組”功能才能看到完整的載荷。我遇到過一個經(jīng)典問題客戶端發(fā)一個 2000 字節(jié)的 UDP 包服務(wù)端收不到。抓包發(fā)現(xiàn)包被分成了兩片第一片到了第二片丟了。因為 UDP 不重傳服務(wù)端重組失敗整個包被丟棄。解決辦法要么是減小包大小避免分片要么是在應(yīng)用層做分片和重傳。這個問題的隱蔽性在于小包測試一切正常一大包就出問題很容易誤判為“服務(wù)端處理能力不足”。注意路徑 MTU 發(fā)現(xiàn)PMTUD在 UDP 場景下經(jīng)常失效因為很多防火墻會丟棄 ICMP 的“需要分片”消息。所以 UDP 應(yīng)用最好自己控制包大小不要依賴 PMTUD。5. 常見問題與排查技巧實錄5.1 抓包抓不到包的幾個原因這是新手最常遇到的問題明明配置了抓包但一個包都沒有。我總結(jié)了幾種可能現(xiàn)象可能原因排查方法完全沒包網(wǎng)卡選錯了ip a確認(rèn)流量走哪塊網(wǎng)卡只有單向包抓包點位置不對在兩端同時抓對比包不完整沒加-s 0重新抓指定 snaplen過濾太嚴(yán)表達(dá)式寫錯先不加過濾抓確認(rèn)有流量再逐步加權(quán)限不足沒用 rootsudo tcpdump還有一個隱蔽的原因流量走了 loopback。如果客戶端和服務(wù)端在同一臺機器上流量走的是lo網(wǎng)卡你在eth0上抓是抓不到的。這個坑我踩過當(dāng)時以為是防火墻問題查了半天才發(fā)現(xiàn)是網(wǎng)卡選錯了。5.2 Wireshark 分析中的誤報與陷阱Wireshark 很強大但它的自動分析功能有時候會誤導(dǎo)人。幾個常見的誤報校驗和錯誤誤報。前面提過網(wǎng)卡卸載會導(dǎo)致 Wireshark 顯示校驗和錯誤但實際包是好的。解決辦法是關(guān)掉校驗和驗證或者關(guān)掉網(wǎng)卡卸載。重傳誤報。Wireshark 判斷重傳是基于序列號和時間的如果抓包點位置特殊比如在發(fā)送方和接收方之間的中間設(shè)備上抓可能會把正常的包誤判為重傳。亂序誤報。多路徑或者抓包點不對稱時Wireshark 可能把正常到達(dá)的包標(biāo)記為亂序。我的經(jīng)驗是永遠(yuǎn)不要只信 Wireshark 的標(biāo)記要自己看序列號、看時間戳、看載荷。標(biāo)記只是提示最終判斷得靠數(shù)據(jù)本身。5.3 從抓包到定位問題的完整思路抓包只是手段定位問題才是目的。我一般的分析流程是先看整體用 Wireshark 的“統(tǒng)計”功能看包數(shù)量、會話分布、協(xié)議分布快速定位異常點。再看異常過濾出重傳、RST、重復(fù) ACK、ICMP 錯誤等異常包看它們集中在哪個時間段、哪對 IP 之間。然后看細(xì)節(jié)針對異常包展開協(xié)議樹看序列號、標(biāo)志位、選項字段、載荷內(nèi)容。最后做對比和正常情況的抓包對比找出差異。沒有對比就沒有判斷。這個流程說起來簡單但實際操作中最難的是第 4 步。很多人抓了包看到一堆重傳就慌了但其實如果基線抓包里也有重傳那說明重傳在這個網(wǎng)絡(luò)環(huán)境下是正常的不是故障原因。建立基線這個習(xí)慣是我做抓包分析這些年最重要的經(jīng)驗。5.4 幾個提升效率的小技巧Wireshark 的“追蹤 TCP 流”功能Follow TCP Stream能把一個連接的所有載荷拼起來看分析應(yīng)用層協(xié)議時特別有用。UDP 沒有流的概念但可以用“追蹤 UDP 流”看一段時間內(nèi)的所有包。給 pcap 文件命名時帶上時間、場景、過濾條件比如20240115_tcp_retrans_loss30.pcap過幾天回頭看還能想起來是什么實驗。分析大文件時先用editcap按時間或包數(shù)量切分再逐段分析比一次性打開幾百兆的文件流暢得多。如果需要在多臺機器上同時抓包用tcpdump的-w寫到文件然后統(tǒng)一拉到一臺機器上用 Wireshark 的“合并”功能合并注意時間同步問題機器之間時間差太大會導(dǎo)致合并后的時間線錯亂。最后分享一個我個人的習(xí)慣每次做完故障模擬實驗我都會把抓包文件、分析筆記、結(jié)論整理成一個文檔存檔。下次遇到類似問題直接翻文檔比重新抓包分析快得多。網(wǎng)絡(luò)故障這東西太陽底下沒有新鮮事你遇到過的大概率別人也遇到過只是你當(dāng)時沒記下來而已。