TCPDump抓包分析實(shí)戰(zhàn)：10個(gè)常見(jiàn)網(wǎng)絡(luò)問(wèn)題排查案例

作為一名資深運(yùn)維工程師，我在生產(chǎn)環(huán)境中遇到過(guò)各種奇葩的網(wǎng)絡(luò)問(wèn)題。今天分享10個(gè)真實(shí)案例，帶你掌握TCPDump這把利器，讓網(wǎng)絡(luò)問(wèn)題無(wú)處遁形！

前言：為什么TCPDump是運(yùn)維必備神器？

在凌晨3點(diǎn)被告警吵醒時(shí)，當(dāng)用戶瘋狂投訴網(wǎng)絡(luò)卡頓時(shí)，當(dāng)開發(fā)甩鍋說(shuō)"肯定是網(wǎng)絡(luò)問(wèn)題"時(shí)——TCPDump就是你最可靠的戰(zhàn)友。它不會(huì)說(shuō)謊，不會(huì)掩飾，只會(huì)如實(shí)記錄每一個(gè)數(shù)據(jù)包的來(lái)龍去脈。

本文你將學(xué)到：

? 10個(gè)生產(chǎn)環(huán)境真實(shí)排查案例

? TCPDump核心參數(shù)使用技巧

? 抓包結(jié)果分析的黃金法則

? 快速定位問(wèn)題的實(shí)戰(zhàn)方法論

案例1：神秘的連接超時(shí) - TCP三次握手失敗

問(wèn)題現(xiàn)象

# 用戶反饋：訪問(wèn)API接口頻繁超時(shí)
curl: (7) Failed to connect to api.example.com port 443: Connection timed out

抓包分析

# 抓包命令
tcpdump -i eth0 -nn -s0 -w timeout.pcap host api.example.com

# 分析結(jié)果
1015.123456 IP 192.168.1.100.45678 > 203.0.113.10.443: Flags [S],seq1000, win 65535
1018.123456 IP 192.168.1.100.45678 > 203.0.113.10.443: Flags [S],seq1000, win 65535
1024.123456 IP 192.168.1.100.45678 > 203.0.113.10.443: Flags [S],seq1000, win 65535

關(guān)鍵發(fā)現(xiàn)：只有SYN包，沒(méi)有SYN-ACK回包！

解決方案

檢查防火墻規(guī)則，發(fā)現(xiàn)出站443端口被誤刪。這種"只出不進(jìn)"的問(wèn)題，只有抓包才能快速定位。

運(yùn)維金句：網(wǎng)絡(luò)問(wèn)題80%都卡在防火墻上，TCPDump幫你一眼看穿！

案例2：詭異的慢查詢 - TCP窗口縮放問(wèn)題

問(wèn)題現(xiàn)象

數(shù)據(jù)庫(kù)查詢偶發(fā)性慢，監(jiān)控顯示CPU、內(nèi)存正常，但響應(yīng)時(shí)間飆升到30秒。

抓包技巧

# 專門抓取數(shù)據(jù)庫(kù)流量
tcpdump -i any -nn -s0 port 3306 and host 192.168.1.50 -w mysql_slow.pcap

# 重點(diǎn)關(guān)注窗口大小變化
tcpdump -r mysql_slow.pcap -nn | grep"win"

分析結(jié)果

# 正常情況
1001 IP client.45678 > mysql.3306: win 65535
# 異常情況 
1002 IP client.45678 > mysql.3306: win 0
1002 IP mysql.3306 > client.45678: win 32768 [window probe]

發(fā)現(xiàn)問(wèn)題：TCP接收窗口為0，觸發(fā)零窗口探測(cè)，導(dǎo)致傳輸停頓。

根本原因：應(yīng)用程序處理MySQL結(jié)果集太慢，接收緩沖區(qū)被占滿。

案例3：負(fù)載均衡的背后殺手 - RST包追蹤

問(wèn)題現(xiàn)象

負(fù)載均衡后端服務(wù)器連接頻繁中斷，日志顯示大量"Connection reset by peer"。

實(shí)戰(zhàn)抓包

# 專門捕獲RST包
tcpdump -i eth0 -nn'tcp[tcpflags] & tcp-rst != 0'-c 100

# 結(jié)果分析
1115 IP 10.0.1.100.80 > 192.168.1.200.12345: Flags [R.],seq12345, ack 67890
1116 IP 10.0.1.100.80 > 192.168.1.201.12346: Flags [R.],seq54321, ack 98765

分析思路：

1. RST包的發(fā)送方向（是客戶端還是服務(wù)端主動(dòng)斷開？）

2. RST包的時(shí)機(jī)（在數(shù)據(jù)傳輸中？還是連接建立后？）

3. 序列號(hào)是否正確（判斷是否為異常RST）

最終發(fā)現(xiàn)：負(fù)載均衡器健康檢查配置錯(cuò)誤，超時(shí)時(shí)間設(shè)置過(guò)短，導(dǎo)致正常連接被誤殺。

案例4：HTTP請(qǐng)求的離奇失蹤 - 應(yīng)用層協(xié)議分析

問(wèn)題描述

Web應(yīng)用POST請(qǐng)求成功率只有70%，GET請(qǐng)求正常，開發(fā)堅(jiān)持說(shuō)代碼沒(méi)問(wèn)題。

深度抓包

# 抓取HTTP流量并保存
tcpdump -i eth0 -A -s0 port 8080 -w http_post.pcap

# 過(guò)濾POST請(qǐng)求
tcpdump -r http_post.pcap -A | grep -i"post"

分析發(fā)現(xiàn)

# 成功的POST請(qǐng)求
POST/api/userHTTP/1.1
Content-Length:256
Content-Type:application/json

{"user_id":123,"name":"test"}

# 失敗的POST請(qǐng)求 
POST/api/userHTTP/1.1
Content-Length:512
Content-Type:application/json

{"user_id":123,"name":"test"}

問(wèn)題定位：Content-Length與實(shí)際載荷不匹配！

根本原因：反向代理Nginx配置了client_max_body_size限制，但錯(cuò)誤日志級(jí)別設(shè)置過(guò)高，運(yùn)維沒(méi)有察覺(jué)。

案例5：DNS解析的隱形陷阱

故障現(xiàn)象

應(yīng)用啟動(dòng)后前幾分鐘正常，隨后域名解析失敗，重啟臨時(shí)解決。

DNS抓包診斷

# 抓取DNS查詢流量
tcpdump -i eth0 -nn port 53 -w dns_issue.pcap

# 分析DNS響應(yīng)
tcpdump -r dns_issue.pcap -nn | grep"A?"

關(guān)鍵發(fā)現(xiàn)

# 正常DNS查詢
1201 IP 192.168.1.100.12345 > 8.8.8.8.53: 12345+ A? api.example.com
1201 IP 8.8.8.8.53 > 192.168.1.100.12345: 12345 1/0/0 A 203.0.113.10

# 異常DNS查詢
1201 IP 192.168.1.100.12346 > 8.8.8.8.53: 12346+ A? api.example.com
# 沒(méi)有回包！

問(wèn)題根源：DNS服務(wù)器IP配置了雙棧，但I(xiàn)Pv6路由有問(wèn)題，應(yīng)用隨機(jī)選擇DNS服務(wù)器導(dǎo)致間歇性失敗。

案例6：SSL握手的暗黑時(shí)刻

問(wèn)題場(chǎng)景

HTTPS站點(diǎn)間歇性報(bào)告SSL握手失敗，瀏覽器顯示"ERR_SSL_PROTOCOL_ERROR"。

TLS抓包技巧

# 抓取SSL握手過(guò)程
tcpdump -i eth0 -nn -s0 port 443 and host web.example.com -w ssl_handshake.pcap

# 使用Wireshark分析或命令行查看
tcpdump -r ssl_handshake.pcap -nn -x

分析要點(diǎn)

# 正常SSL握手流程
Client Hello -> Server Hello -> Certificate -> Server Hello Done ->
Client Key Exchange -> Change Cipher Spec -> Finished

# 異常情況：在Certificate階段中斷
Client Hello -> Server Hello -> [連接斷開]

深度分析：證書鏈不完整，中間CA證書缺失，部分客戶端無(wú)法驗(yàn)證。

案例7：微服務(wù)間的通信雷區(qū)

復(fù)雜場(chǎng)景

微服務(wù)A調(diào)用服務(wù)B，成功率95%，但失敗的5%找不到規(guī)律。

分布式追蹤抓包

# 多網(wǎng)卡同時(shí)抓包
tcpdump -i any -nn -s0'(src host serviceA and dst host serviceB) or (src host serviceB and dst host serviceA)'-w microservice.pcap

# 按連接分組分析
tcpdump -r microservice.pcap -nn | awk'{print $3 " -> " $5}'|sort|uniq-c

意外發(fā)現(xiàn)

# 正常連接
192.168.1.10.8080 -> 192.168.1.20.9090: established

# 異常連接 - 注意端口復(fù)用問(wèn)題
192.168.1.10.8080 -> 192.168.1.20.9090: [端口被復(fù)用，序列號(hào)混亂]

問(wèn)題本質(zhì)：服務(wù)B重啟時(shí)，TCP TIME_WAIT狀態(tài)處理不當(dāng)，導(dǎo)致端口復(fù)用沖突。

案例8：帶寬打滿的真相

告警現(xiàn)象

服務(wù)器帶寬使用率突然飆升到95%，但業(yè)務(wù)量沒(méi)有明顯增長(zhǎng)。

流量分析抓包

# 按流量大小排序連接
tcpdump -i eth0 -nn -q |head-1000 | awk'{print $3}'|sort|uniq-c |sort-nr

# 抓取大流量連接詳情
tcpdump -i eth0 -nn -s0 src 192.168.1.100 -w bandwidth_hog.pcap

驚人發(fā)現(xiàn)

大部分流量來(lái)自一個(gè)內(nèi)網(wǎng)IP的重復(fù)請(qǐng)求，仔細(xì)分析發(fā)現(xiàn)是負(fù)載均衡健康檢查配置錯(cuò)誤，檢查間隔設(shè)置為1ms！

優(yōu)化方案：調(diào)整健康檢查參數(shù)，帶寬使用率立即降到正常水平。

案例9：數(shù)據(jù)包的神秘變異

詭異現(xiàn)象

客戶端發(fā)送正確數(shù)據(jù)，但服務(wù)端接收到的數(shù)據(jù)被截?cái)嗷騺y碼。

中間人抓包

# 在網(wǎng)關(guān)設(shè)備抓包
tcpdump -i eth0 -xx -s0 host client.ip and host server.ip -w packet_corruption.pcap

# 對(duì)比數(shù)據(jù)包內(nèi)容
tcpdump -r packet_corruption.pcap -xx | grep"payload"

真相大白

# 客戶端發(fā)送（正確）
45 00 05 dc ... [完整數(shù)據(jù)包]

# 服務(wù)端接收（被篡改） 
45 00 05 dc ... [數(shù)據(jù)包被中間網(wǎng)絡(luò)設(shè)備修改]

罪魁禍?zhǔn)祝?/strong>某臺(tái)交換機(jī)固件bug，對(duì)特定模式的數(shù)據(jù)包進(jìn)行了錯(cuò)誤的校驗(yàn)和重計(jì)算。

# 精確時(shí)間戳抓包
tcpdump -i eth0 -ttt -nn port 8080 -w latency_analysis.pcap

# 分析往返時(shí)間
tcpdump -r latency_analysis.pcap -ttt -nn | grep"HTTP"

# TCP建連時(shí)間：150ms
# SSL握手時(shí)間：300ms 
# HTTP請(qǐng)求處理：50ms
# 網(wǎng)絡(luò)傳輸時(shí)間：4500ms ← 問(wèn)題在這里！

# 萬(wàn)能抓包命令
tcpdump -i any -nn -s0 -w capture.pcap

# 參數(shù)解釋
-i any   # 監(jiān)聽所有網(wǎng)卡
-nn    # 不解析主機(jī)名和端口名
-s0    # 抓取完整數(shù)據(jù)包
-w file  # 保存到文件

# 按主機(jī)過(guò)濾
tcpdump host 192.168.1.100

# 按端口過(guò)濾 
tcpdump port 80 or port 443

# 按協(xié)議過(guò)濾
tcpdump tcp and not ssh

# 按標(biāo)志位過(guò)濾
tcpdump'tcp[tcpflags] & tcp-syn != 0'

# 組合過(guò)濾
tcpdump -i eth0 -nn'host 192.168.1.100 and (port 80 or port 443) and tcp[tcpflags] & tcp-syn != 0'

#!/bin/bash
# 網(wǎng)絡(luò)問(wèn)題快速診斷腳本
echo"開始網(wǎng)絡(luò)診斷..."

# 基礎(chǔ)連通性測(cè)試
ping -c 4$1> /tmp/ping.log 2>&1

# 抓包分析
timeout30 tcpdump -i any -nn -c 100 host$1-w /tmp/capture.pcap 2>/dev/null

# 分析結(jié)果
echo"=== 連通性測(cè)試 ==="
cat/tmp/ping.log

echo"=== 數(shù)據(jù)包統(tǒng)計(jì) ==="
tcpdump -r /tmp/capture.pcap -nn |head-10

# Zabbix觸發(fā)器腳本示例
if[$NETWORK_ERROR_RATE-gt 5 ];then
  tcpdump -i eth0 -G 300 -W 2 -w /var/log/auto_capture_%Y%m%d_%H%M%S.pcap &
 echo"自動(dòng)抓包已啟動(dòng)"
fi