tcpdump网络排查实战：从基础命令到高级技巧

1. 网络问题排查的痛点与工具选择

刚接手一台服务器就发现网络异常？应用突然出现高延迟却找不到原因？这类问题在实际运维中太常见了。传统的ping/traceroute只能告诉我们"有问题"，但具体是什么包被丢弃、哪个环节出问题，往往需要更专业的工具。

tcpdump作为网络分析领域的"瑞士军刀"，能在数据链路层捕获原始报文。与Wireshark这类图形化工具相比，它的优势在于：

• 几乎存在于所有Linux发行版中
• 对系统资源占用极低
• 能保存原始数据供后续分析
• 支持复杂的过滤表达式

我在处理跨国网络问题时，曾用tcpdump在30秒内定位到是某中间节点错误分片导致的问题。下面分享我的标准排查流程。

2. 排查工具准备与基础命令

2.1 安装与权限配置

大多数系统已预装tcpdump，如需安装：

bash复制# RHEL/CentOS
sudo yum install -y tcpdump

# Ubuntu/Debian 
sudo apt-get install -y tcpdump

注意：普通用户使用时需要sudo权限，生产环境建议通过sudoers精确控制权限：

code复制Cmnd_Alias NETWORK = /usr/sbin/tcpdump
%admin ALL=(ALL) NOPASSWD: NETWORK

2.2 基础捕获命令

最简捕获命令（需root权限）：

bash复制sudo tcpdump -i any -w capture.pcap

• -i any 监听所有网卡
• -w 保存原始数据包
• 默认捕获所有流量，生产环境慎用

按Ctrl+C停止捕获后，用下面命令查看统计：

bash复制tcpdump -r capture.pcap -q -nn -t | awk '{print $3}' | sort | uniq -c | sort -n

3. 三步定位法实战演示

3.1 第一步：确认连通性基础

先捕获ICMP协议（ping使用的协议）：

bash复制sudo tcpdump -i eth0 icmp -nn -v

在另一个终端执行ping测试：

bash复制ping -c 4 8.8.8.8

健康情况下应看到类似输出：

code复制IP (tos 0x0, ttl 64, id 1234, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.100 > 8.8.8.8: ICMP echo request, id 1234, seq 1, length 64
IP (tos 0x0, ttl 118, id 5678, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.1.100: ICMP echo reply, id 1234, seq 1, length 64

如果只有request没有reply，说明：

• 可能本地防火墙拦截（检查iptables/nftables）
• 中间网络设备丢弃（需逐跳排查）
• 目标主机禁用ICMP

3.2 第二步：TCP连接问题分析

对于Web服务等TCP应用，捕获特定端口：

bash复制sudo tcpdump -i eth0 'tcp port 80 and (tcp-syn|tcp-rst|tcp-ack)' -nn -v

关键标志位解读：

• [S] SYN：连接请求
• [.] ACK：确认响应
• [R] RST：连接重置
• [F] FIN：连接终止

典型问题模式：

1. 只有SYN没有SYN-ACK：目标服务未监听或防火墙拦截
2. 大量SYN重传：网络严重拥塞或目标主机过载
3. 频繁RST：可能是应用层异常断开

3.3 第三步：延迟问题精确定位

使用时间戳分析延迟：

bash复制sudo tcpdump -i eth0 -tttt -nn 'host 1.2.3.4 and port 443' -w https.pcap

然后用Wireshark分析TCP握手时序：

1. 计算SYN到SYN-ACK的时间（网络往返延迟）
2. 检查ACK确认时间（应用处理延迟）
3. 观察重传间隔（网络质量指标）

我曾用这个方法发现某云厂商的负载均衡器在TCP窗口缩放协商时增加了200ms延迟，最终通过调整内核参数解决：

bash复制echo 0 > /proc/sys/net/ipv4/tcp_slow_start_after_idle

4. 高级技巧与性能优化

4.1 精准过滤表达式

常用过滤条件示例：

bash复制# 捕获特定子网的DNS查询
tcpdump -i eth0 'udp port 53 and net 192.168.1.0/24'

# 捕获HTTP GET请求
tcpdump -i eth0 'tcp port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

# 排除SSH流量
tcpdump -i eth0 'not port 22'

4.2 性能调优参数

大流量场景下的优化：

bash复制sudo tcpdump -i eth0 -B 4096 -s 96 -G 300 -W 5 -w /var/tmp/cap-%H-%M.pcap

• -B 设置缓冲区大小（单位KB）
• -s 限制每个包捕获长度
• -G 按时间分割文件（秒）
• -W 最大文件轮转数

4.3 容器环境捕获

Docker容器网络捕获方法：

bash复制# 查找容器PID
docker inspect --format '{{.State.Pid}}' nginx

# 进入容器网络命名空间
nsenter -n -t <PID> tcpdump -i eth0

5. 常见问题排查指南

5.1 抓不到包的可能原因

1. 网卡处于混杂模式？

   bash复制ip link show eth0 | grep -i promisc
   

2. 过滤条件太严格？
   先尝试不加任何过滤
3. 接口选择错误？
   ip addr 确认实际使用的网卡

5.2 典型报错处理

报错：tcpdump: eth0: You don't have permission...
解决方法：

bash复制sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump

报错：dropped packets
调整缓冲区大小：

bash复制sudo sysctl -w net.core.rmem_max=26214400

5.3 生产环境注意事项

1. 避免长时间全量捕获，建议：
   • 使用-c参数限制包数量
   • 配合-G参数轮转文件
2. 敏感数据过滤：

   bash复制tcpdump -i eth0 -w /tmp/cap.pcap 'not (port 22 or port 3306)'
   

3. 资源监控：

   bash复制watch -n 1 'cat /proc/net/dev | grep eth0'
   

6. 分析案例：电商网站延迟问题

某电商API平均响应从50ms突增到800ms，通过以下步骤定位：

1. 捕获问题时段流量：

   bash复制sudo tcpdump -i eth0 'port 8080' -G 60 -w /tmp/api-%H-%M.pcap
   

2. 分析发现：

   • 90%的TCP重传发生在与Redis服务器之间
   • 重传间隔呈现指数增长（典型拥塞控制行为）

3. 最终定位：

   • 某台Redis服务器网卡有CRC错误
   • ethtool -S eth0 确认error计数增长
   • 更换网线后恢复正常

这个案例展示了tcpdump与其他工具（ethtool）的配合使用方法。实际网络问题往往需要多维度数据交叉验证。