干网络这一行差不多十年我见过太多同事在服务器前排障的时候第一反应是问“谁装个Wireshark”。但说实话真到了生产环境那台Linux服务器上我绝大多数时候第一件事是敲一条tcpdump命令。这玩意儿没有图形界面一个黑框框加一堆看似晦涩的参数但它是流量抓包和网络问题排查里最能救命、也最体现功底的工具。这篇就从零开始把我这些年用tcpdump踩过的坑、总结出来的方法一次讲清楚。tcpdump是什么它是Linux环境下最经典的命令行抓包工具基于libpcap实现能把经过网卡的数据包截获、过滤、输出或保存成文件。它能解决的问题非常明确在不装任何图形界面的服务器上、在远程SSH连接里、在需要长时间自动化采集流量的场景下搞清楚“包到底走了没有”“对方回没回包”“回包是不是被丢了”“握手到底卡在哪一步”。适合谁看刚入行的网络工程师、运维工程师还有那些需要自己排查网络问题的后端开发。这篇文章不绕弯子直接从原理、命令、过滤语法讲到六个实战场景和性能调优看完你就能上手用。1. 为什么网工不能只依赖Wireshark三个真实场景先说一个我亲身经历的事。有一次某个内部系统的数据库出现大量连接超时我登录跳板机排查发现数据库服务器在机房内网出于安全策略无法通过图形化方式访问更不可能在上面装带GUI的Wireshark。当时我直接在上面执行tcpdump -i eth0 -nn tcp port 3306 and host 10.20.30.40 -c 100几十秒内就看到客户端发了很多SYN但数据库回包里的SYN-ACK数量明显对不上问题定位到是服务器侧连接队列满导致SYN被丢弃。整个过程没有开任何图形工具只有一条命令。这个例子背后是三个Wireshark做不到或者做不好的场景。第一生产服务器几乎都是命令行环境你没法在上面装Wireshark图形界面哪怕装了你敢在线上随便点击抓包吗第二Wireshark是交互式工具你想实现“每天凌晨自动抓包10分钟”“抓满1GB自动轮转”“把抓包结果持续写入文件供事后分析”用脚本和crontab才能完成这些场景天然属于tcpdump。第三流量很大的时候Wireshark要把每个包都解码并渲染到界面上CPU和内存消耗远高于tcpdump抓包本身就会影响业务。我经常打一个比方Wireshark像是带全套手术设备的现代化手术室适合你坐在工位上慢慢分析tcpdump像是战场急救包里的止血钳和纱布小、快、灵在条件受限的环境中能先稳住局面。两者不是对立关系而是搭档。正确的工作流通常是用tcpdump在服务器上把包抓下来保存成pcap文件然后带回到本地用Wireshark做深度协议分析。维度Wiresharktcpdump安装环境需要图形界面或桌面环境纯命令行几乎任何Linux都可用资源开销高解码渲染耗CPU/内存低适合长时间抓包过滤能力强大但依赖界面交互依赖BPF表达式标准化、可脚本化远程使用需要X11转发或远程桌面SSH连上直接用自动化困难GUI难自动化极简单命令加脚本即可分析体验图形化、协议解析丰富原始输出需要一定的报文字段阅读能力所以我的观点很明确一个合格的网工Wireshark可以慢慢精通但tcpdump必须随手能用。尤其当你面对的是几十台服务器的集群或者只有命令行入口的生产环境tcpdump才是真正的第一抓手。2. tcpdump抓包原理与四个必须搞懂的基础概念很多人用了很久tcpdump却说不清它到底是怎么抓到包的。甚至有人问我“tcpdump是不是在应用层抓包”这个误解很典型。要真正用好它下面这四件事必须搞清楚。2.1 数据包是怎么从网卡到tcpdump手里的数据包被网卡接收后先进入内核的协议栈处理正常情况下会经过链路层、网络层、传输层最后交给应用程序。而tcpdump这类抓包工具利用的是libpcap库它通过Linux内核提供的AF_PACKET套接字在较老的系统上是SOCK_PACKET在报文进入协议栈做正式处理之前复制一份副本出来给用户态程序。这句话有两个关键点。第一个关键点抓到的“副本”不只是某个协议的报文而是从链路层开始的完整原始帧所以默认情况下你能看到以太网头部、IP头部、TCP头部和应用层数据。第二个关键点内核提供了一份流量给tcpdump处理但原包依然走正常协议栈路径所以抓包行为本身不会改变数据包的正常转发最多是带来一点点CPU开销。这也是为什么我们常说流量抓包是一种“旁路观察”不是“串接拦截”。BPF伯克利包过滤器在这个过程中扮演了闸门角色。你写的过滤表达式会被编译成一段伪机器码在内核态执行。它的意义在于不需要把每个包都拷贝到用户态再判断而是在内核态就把不关心的包丢弃大幅度降低拷贝量和用户态处理压力。理解这一点后你就明白为什么tcpdump过滤表达式写得好不好直接影响抓包性能。2.2 网卡工作模式与本地回环默认情况下网卡只会把目的MAC是自己、或者广播/组播的报文交给内核。但抓包的时候我们经常需要看整个链路上的流量比如交换机上有两台机器在通信而你只想在第三台机器上“旁观”它们这时候就必须让网卡进入混杂模式。tcpdump加-p参数可以关闭混杂模式不加的时候默认打开实际上tcpdump在Linux上默认启用混杂模式。有一个特别容易忽略的坑本地回环接口lo。你抓本机进程之间的通信时比如用客户端连本机的服务端流量只是走loopback接口如果不加-i lo什么都抓不到。我见过不少人排查本机服务问题对着eth0抓了半天一片空白实际上流量就在lo上。这也引出一个排查习惯先确认流量到底走哪个接口再决定抓哪个网卡。2.3 理解BPF过滤表达式tcpdump的灵魂BPF表达式是tcpdump最核心的东西如果你只会-i eth0而不写过滤规则那在生产环境上基本没法用。举一个最简单的例子一个繁忙的数据库服务器每秒几千个包你需要从中筛选出某个客户端IP发往3306端口的包。这就要写tcpdump -i eth0 -nn tcp and src host 10.0.0.5 and dst port 3306这里的tcp、src host、dst port都是BPF语法。BPF表达式由限定词构成常见的三类限定词类型限定词host、net、port、portrange、方向限定词src、dst、src or dst、src and dst、协议限定词ether、ip、ip6、arp、tcp、udp、icmp。它们之间可以用布尔运算and、or、not组合还可以用小括号调整优先级。这就是为什么tcpdump能精准匹配任意维度组合。理解BPF表达式之后还有一个高级技巧很多网工不知道tcpdump支持“基于报文内容的过滤”。比如你想抓所有TCP SYN包其实是抓tcp[13] 0x02 ! 0。这个写法基于TCP头部的字节偏移13号偏移字节对应TCP标志位0x02是SYN位。同理抓RST包是tcp[13] 0x04 ! 0。这个能力在调试特定报文时特别有用后面实战部分会展开。2.4 tcpdump的完整命令结构摆脱“只会加-i抓个试试”的阶段你就要把tcpdump的命令结构完整掌握。它总体上是这个形态tcpdump [选项] [过滤表达式]常用的选项我整理成一张表每个都是实战里高频用到的。选项作用我的使用习惯-i 接口指定抓包网卡如eth0、lo、any不确定走哪张网卡时用any-c 数量抓到指定数量包后自动停止快速验证时用避免一直抓下去-n不做域名解析直接显示IP必加解析域名会慢且可能产生额外流量-nn不解析IP和端口名称排障时必加避免把80显示成http-s 长度设置抓取报文长度0表示整包默认抓前一部分需要分析应用层时设0-w 文件名将原始包写入pcap文件需要事后分析或交给Wireshark时用-r 文件读取pcap文件进行分析抓完回来离线分析-v / -vv / -vvv输出详情逐级增加需要看TTL、校验和、选项字段时加-e打印链路层头部信息排查ARP、VLAN、MAC问题时必加-A以ASCII形式显示应用层数据快速看HTTP报文内容时用-X以十六进制加ASCII显示调试非文本协议时用-q快速输出模式只输出极少信息流量大时减少输出占用的CPU-D列出所有可用抓包接口到了新服务器先看有哪些网卡其中有一个非常实用但我发现很多人不用的选项组合-w加-C加-W。-C表示每个文件多大单位是MB-W表示最多保存多少个文件配合起来可以避免抓包文件把磁盘撑爆。举例tcpdump -i eth0 -nn -s 0 -w /data/capture.pcap -C 100 -W 10 tcp port 443这条命令会持续抓取443端口流量每个文件到100MB就切换最多保留10个文件旧的自动覆盖。这样即使忘了停掉抓包磁盘也不会被写满。这个技巧我在生产上用过无数次强烈建议收藏。3. 从小白到熟练tcpdump输出和过滤表达式的层层递进基础概念过了之后就要解决“抓下来的东西怎么看”“过滤条件怎么越写越精准”这两个核心问题。这一节我把输出格式和过滤写法掰开揉碎了讲。3.1 先学会看懂tcpdump的输出格式抓包之后屏幕上会一行行刷出报文信息。很多新手第一次看这些输出是懵的我逐步拆解一个典型的TCP报文输出14:23:45.123456 IP 192.168.1.10.54321 192.168.1.20.80: Flags [S], seq 1000, win 64240, length 0这段输出从左到右分别是时间戳14:23:45.123456、协议IP、源地址和端口192.168.1.10.54321、方向箭头、目的地址和端口192.168.1.20.80、标志位Flags [S]、序列号seq 1000、窗口大小win 64240、包长度length 0。看到Flags [S]就知道这是TCP三次握手的第一步SYN包。常见的标志位对应关系[S]是SYN[.]是ACK[F]是FIN[R]是RST[P]是PSH。组合出现时比如[S.]表示SYN-ACK[FP.]表示FIN加PSH加ACK。如果你带着-nn抓包端口就显示数字不会有歧义如果不加它可能会显示成54321和http这种服务名反而增加心算负担。所以我在所有命令里都会带上-nn。UDP报文更简单没有标志位和序列号14:23:46.654321 IP 192.168.1.10.5353 192.168.1.20.53: 1234 0.000000 C? example.com. (31)这是DNS查询请求C?代表这是Client的查询example.com.是查询的域名括号里是报文总长度。看到这些字段能解构出来你就能在没有任何图形界面的情况下快速判断网络状态。3.2 按主机过滤最常用的第一步主机过滤是所有网络排障里最高频的需求。例如排查“某个IP是不是在跟你通信”最基础的就是hosttcpdump -i eth0 -nn host 192.168.1.100这条命令会抓一切跟192.168.1.100有关的包无论方向。如果你想区分方向用src host和dst host。比如抓某台服务器发出的流量用src host抓发给它的流量用dst host。我习惯在排障时先观察双向通信因为很多时候“对方没回包”和“对方回了但你没收到”是两种完全不同的故障。如果你只抓单向流量很容易漏掉关键线索。先抓host得到全貌再逐步收窄为src host或dst host这比一开始就限定方向要稳妥。3.3 按端口和端口范围过滤端口过滤用于定位特定服务。最基础的是tcpdump -i eth0 -nn port 8080这相当于把所有源端口或目的端口是8080的包都抓下来。更精确的写法是src port和dst port。端口范围用portrange比如看DHCP流量抓portrange 67-68。端口过滤排障时最典型的应用场景你怀疑某个服务有异常但服务器上同时跑着好几个应用。比如一台机器上既有Nginx在80端口又有Java服务在8080端口还有数据库在3306端口。你只关心Java服务的连接就写tcpdump -i eth0 -nn tcp port 8080这样Nginx的流量完全不会干扰你。还有一个组合技巧抓客户端IP到特定端口的精准组合tcpdump -i eth0 -nn tcp and src host 10.0.0.5 and dst port 3306这是我在排查数据库问题时最常敲的命令。3.4 按协议过滤协议过滤是基础中的基础。tcp只抓TCP包udp只抓UDP包icmp只抓ICMP包arp只抓ARP包。组合场景非常多比如查网络不通先用icmp抓ping包再用arp看MAC解析是否正常。用tcp or udp把传输层主流量都抓下来结合port使用通常是我排查应用连接问题的标准起步姿势。IPv6环境下还有一个坑很多老网工习惯了ip关键字但IPv6报文要写ip6。比如tcpdump -i eth0 -nn ip6 and tcp port 443不写ip6的话有些版本的tcpdump默认只匹配IPv4IPv6的流量会被漏掉。排障时如果发现机器明明有IPv6地址但抓了半天没有任何流量排除这个点往往就是答案。还有一个容易被忽略但很实用的协议vlan。如果服务器接的是trunk口收到的包带VLAN tag默认tcpdump的过滤逻辑会跟VLAN标签产生“错位”因为在Linux上VLAN头部在以太网头之后、IP头之前。解决方法是先写vlan再写其他过滤条件tcpdump -i eth0 -nn vlan and tcp port 8080老版本tcpdump还有一个经典场景需要先vlan再做协议匹配否则过滤条件会不生效但新版本对VLAN的处理已经友好很多。遇到带tag的流量建议第一时间加这个前缀。3.5 组合逻辑与高级匹配网工的分水岭单一条件过滤只是入门真正的分水岭是会组合逻辑和高级匹配。组合逻辑用的就是and、or、not和小括号。举个例子我想抓某个网段内除了某台机器之外的所有TCP 443流量tcpdump -i eth0 -nn tcp and dst port 443 and src net 192.168.1.0/24 and not src host 192.168.1.200这里src net 192.168.1.0/24表示源地址在某个网段内not src host排除了特定主机。实际排障时这种条件组合能迅速缩小范围避免被无关流量淹没。再引入基于报文内容的过滤。抓TCP的SYN包用tcp[13] 0x02 ! 0抓RST包用tcp[13] 0x04 ! 0抓TCP连接中的重传通常在Wireshark里看标志但命令行下可以先抓所有含SYN和ACK的包来分析。举一个我实测用过的例子排查某个服务大量出现TCP连接被重置我抓所有RST包定位哪些IP在发tcpdump -i eth0 -nn tcp[13] 0x04 ! 0这条命令在下发后立刻看到一堆来自某个跳板机的RST包问题很快就定位到是安全策略主动切断连接。如果不懂tcp[13]这种写法你可能要把所有流量抓下来用Wireshark过滤效率差非常多。3.6 抓包时机的把握先抓再说还是先过滤再抓很多新手容易走两个极端要么不加任何过滤条件就把所有流量抓下来导致文件巨大、分析困难要么过滤条件写得太严格结果真正需要的包没抓到。我的经验是分两步走。第一步先放宽条件抓一小段时间比如-c 100观察当前流量的大致构成这好比先“看一眼战场”。第二步根据第一步结果收窄条件开始正式抓包。假设我第一步发现网卡上有大量访问某IP的流量第二步就锁定tcpdump -i eth0 -nn src host 10.0.0.8 and tcp port 8080 -c 500 -w /tmp/problem.pcap这样既避免了文件膨胀又保证关键流量被完整保存。我特别强调一点在线抓包排查时第一优先是“保留证据”第二优先才是“精确过滤”。因为故障往往是瞬时的如果你把过滤条件写得太细万一漏掉关键特征排查很容易陷入被动。4. 六个真实场景的现场排障实录排障技巧讲了一堆不如直接看我实际用过的案例。下面这六个场景每个都是我过去踩过的真实问题类型你可以直接照着操作。4.1 场景一服务器对外请求超时怎么区分网络还是应用问题有一次某个应用服务器调用外部支付接口频繁超时。应用开发说是网络问题网络团队说是应用问题。我登录服务器抓了一段调用目标的连接过程tcpdump -i eth0 -nn host 203.0.113.10 and tcp port 443 -c 60输出里很清楚看到本机发出了SYN目标服务器返回了SYN-ACK但后续的ACK以及HTTP请求数据一直没有出现。这意味着三层和四层网络是通的问题出在应用层——本机发出握手后应用进程因为自身原因没有继续完成TLS握手或HTTP请求。顺着这个方向查下去果然发现是本地应用线程池满导致任务排队请求根本没发出去。这个场景的关键点在于看到SYN和SYN-ACK就说明网络路径是通的看到“第三次握手没发”或“发了但没后续数据”就要往应用侧深挖。反之如果SYN发出后连SYN-ACK都等不到那就是中间链路或目标防火墙拦截的问题。一次抓包就能把责任划分得清清楚楚。4.2 场景二接口响应慢抓包拆解耗时分布另一个经典场景用户反馈某个网页打开很慢后端服务响应也慢。我在前端服务器上同时抓两个方向的包用时间戳来拆解耗时。tcpdump -i eth0 -nn host 192.168.1.50 and tcp port 80 -w /tmp/http_slow.pcap抓完用Wireshark打开启用TCP时间戳分析。通常能从数据包里看出几个时间差客户端到服务器完成TCP握手耗时、TLS握手耗时、发送HTTP请求到收到响应的间隔。有一次我分析后发现TCP握手很快但浏览器发出请求之后服务器在20毫秒内就返回了ACK却迟滞了整整3秒才返回HTTP响应数据。这说明瓶颈在后端应用处理而不是网络传输。把抓包结果截图发给开发争议瞬间就解决了。这里我额外说一个经验排查“慢”的时候不要只看单个包的时间戳建议先看“首个请求包到首个响应数据包之间间隔多少”这个间隔基本对应服务端的处理时间非常直接。4.3 场景三DNS解析失败判断是本地缓存还是上游问题某天办公网大面积反映网页打不开浏览器提示找不到服务器。初步怀疑DNS。我在DNS客户端机器上执行tcpdump -i eth0 -nn udp port 53 -c 20输出显示客户端向本地DNS服务器发出了查询但没有收到任何响应。继续抓DNS服务器的出口也没有发现查询转发出去。这说明本地DNS服务进程可能已经“假死”上层查询根本没有被处理。重启DNS服务后恢复事后看日志确认是服务进程异常退出。如果没有tcpdump单凭nslookup其实也能测出“不通”但很难快速说清楚到底是客户端没发、本地DNS没回、还是转发链路断了。一抓包问题层次一下就清晰了。4.4 场景四内网间歇性“断网”结果抓到ARP风暴某内网偶尔断网ping网关时而通时而不通网络设备配置看起来一切正常。我在一台办公机上抓包tcpdump -i eth0 -nn -e arp加-e是为了看到链路层信息。没抓多久就见屏幕上疯狂刷ARP响应源头都指向某一台机器的MAC地址。几百条ARP广播在短时间内把交换机CPU打满导致正常数据转发被延迟。后来查明是那台机器网卡故障或中了ARP类病毒不断伪造ARP应答。处理办法是封掉那个MAC地址同时更新交换机端口安全配置。这个场景如果只靠Wireshark做镜像抓包当然也能看但没有镜像端口权限时tcpdump直接在终端侧就能给出初步判断。4.5 场景五TCP重传频发判断中间链路丢包一个专线业务经常卡顿怀疑专线质量。我在业务服务器上抓包看TCP重传情况tcpdump -i eth0 -nn tcp and host 192.168.100.66 -w /tmp/loss.pcap抓完导入Wireshark看Expert Information里的重传和快速重传数量。大量重传且序列号跳跃明显基本可以判定中间链路丢包或乱序。后来配合丢包检测工具对比证明就是运营商专线链路某一段光衰过高导致。这里tcpdump的价值在于它敢在生产服务器上长时间抓包采集样本而Wireshark在同等流量环境下很难持续运行几个钟头不卡。4.6 场景六抓容器或指定进程的流量容器化部署普及后网工经常要抓Docker容器里的网络流量。这里有一个关键认知容器有独立的网络命名空间你在宿主机上直接tcpdump -i eth0看到的流量是宿主机的不一定能看到容器内部的loopback通信或容器独立网络栈的流量。抓容器流量有两个常用办法。第一个找到容器的网络命名空间用nsenter进入去执行tcpdump。大致思路是docker inspect --format {{.State.Pid}} 容器名 nsenter -t 容器PID -n tcpdump -i eth0 -nn tcp port 8080 -c 50第二如果容器使用host网络模式那直接在宿主机上抓对应端口即可。我自己的习惯是能先绑定端口就绑定端口因为进容器的网络命名空间操作直观但生产环境上权限管控比较严格时直接抓宿主机的对应端口更省事。这里要特别提醒一句抓容器流量时注意区分容器网桥名比如docker0和eth0是两个完全不同的链路位置抓错地方就是白忙一场。5. 生产环境实战tcpdump性能调优与文件管理在新手阶段能抓出包来这个阶段要考虑的是“怎么抓才能不影响业务”“怎么管理抓包文件才能不把磁盘撑爆”。生产环境的抓包跟实验室完全不同这几个点必须掌握。5.1 抓包文件的四要素-s、-w、-C、-W组合使用前文提过-w是写文件-s 0是抓全包-C限制单文件大小-W限制文件数量。我记得有一次帮某平台排查问题没有加文件的轮转参数直接-w开抓结果一个晚上抓了上百GB把数据盘差点撑满。从那以后凡是在生产上做长时间抓包我必带-C和-W。一条保护磁盘的命令长这样tcpdump -i eth0 -nn -s 0 -w /data/cap_output.pcap -C 200 -W 5 tcp port 8080这条命令限制每个文件200MB最多5个总磁盘占用不超过1GB即使你人跑开了也不会出事。另外-G选项可以按秒轮转文件比如-G 3600表示每小时切换一个新文件适合长期监控时按时间段归档。5.2 使用环形缓冲区避免磁盘被写满上面说的-C加-W本质上就是一种环形缓冲区思路。如果在抓包前就想好最多保留几个文件那磁盘始终可控。实际工作中我还会配合系统层面的日志轮转工具或定时任务做清理但-C-W是tcpdump自身最简方案不需要依赖外部脚本。有一个细节容易踩坑如果-w指定的目录满了tcpdump不会自动停而是会报错并退出导致抓包中断。建议在开机启动脚本或nohup启动之前先用df -h检查一下磁盘剩余空间至少预留1.5倍你预期的文件总量。5.3 大流量下性能优化快照长度和缓冲区大流量环境里tcpdump本身的开销过高会导致丢包甚至影响业务。优化思路有三个。第一用-s限制快照长度不一定每次都要抓全包。很多排障场景只需要看头部信息比如TCP握手问题抓前128字节就足够-s 128能大幅减少数据拷贝量。第二tcpdump在Linux上有多Buffer机制如果遇到“内核丢包”计数明显可以适当调大socket接收缓冲区但这个通常需要修改内核参数net.core.rmem_max等。第三用-B参数设定缓冲区大小比如-B 4096表示4MB缓冲区能缓解瞬时流量高峰导致的丢包。实际命令示例tcpdump -i eth0 -nn -s 96 -B 4096 tcp port 8080 -c 10000我实测下来流量约几百Mbps时限制快照长度和加大缓冲区就能显著降低抓包丢包率。提示生产环境尽量抓“够用”的包而不是“全部”的包。计算下你这个问题需要看到应用层哪个字段再决定快照长度。抓全包一时爽分析文件和磁盘空间会让你后悔。5.4 后台运行与自动化抓包排查问题经常需要跨夜间时段。ssh一断前台tcpdump就没了。我惯用nohup把tcpdump放到后台nohup tcpdump -i eth0 -nn -s 0 -w /data/cap.pcap -C 200 -W 8 tcp port 8080 /dev/null 21 然后可以用pidof tcpdump或者查看/data/cap.pcap文件大小变化来确认抓包进程还活着。如果要每天定点抓包可以写一个简单的定时任务但注意别和业务高峰期冲突。做自动化抓包时我习惯在文件命名里加上日期时间比如cap_20250610_2330.pcap方便事后梳理。还有一点需要强调nohup挂后台的时候标准输出尽量重定向到空设备或者日志文件否则你后期可能会看到终端里残留大量信息。我是直接把输出写到日志文件里这样随时能回看抓包启动报错之类的信息。5.5 与Wireshark的无缝对接把抓包带回本地分析tcpdump抓出来的pcap文件格式是标准的libpcap格式Wireshark原生支持。我通常是生产上用tcpdump抓文件用scp拉回本地再用Wireshark打开分析。这样既保留了tcpdump在远端的高性能和低资源占用又享受了Wireshark在本地强大的可视化分析能力。如果是纯命令行环境也可以用tsharkWireshark的命令行版本直接在服务器上做离线分析但多数情况下本地图形化更方便。在Wireshark里打开pcap后我第一步按下CtrlAltShiftT打开Telephony菜单里的TCP流图或者直接看Statistics下的Conversation列表先把流量最大的会话找出来再逐步进到Expert Info里看重传和异常。整个过程有个前提你自己要知道抓包时的过滤范围和时间段否则拿回本地分析时面对一堆混杂流量反而无从下手。所以我建议抓包文件名上一定要写清时间、网卡、过滤条件别嫌麻烦。6. 常见问题速查表与我的排障习惯最后这部分我把实际运维里高频遇到的问题整理成速查表顺便分享一套我固定的排障动作。6.1 常见问题速查表现象可能原因排查思路抓包抓不到任何流量网卡选错、过滤条件过于严格、网卡处于非混杂模式先用-i any加-c 10不加过滤条件验证抓到SYN但没回包防火墙拦截、目标服务没监听、中间链路丢包目标机上同时抓包对比检查iptables/安全组大量TCP重传中间链路丢包、带宽瓶颈、对端处理慢看重传的序列号和重传间隔定位丢包路径大量RST包应用主动拒绝、健康检查探测、安全设备干扰用tcp[13] 0x04 ! 0单独抓RST找源头IP抓包文件过大没有限制快照长度或过滤条件太宽加-s限制长度加-C和-W控制文件DNS查询无响应DNS服务异常、防火墙丢弃UDP 53、上游问题分别抓客户端和DNS服务器出口的53端口流量只抓到出向包没有入向包对端没回包、路由不对称、中间设备拦截抓包点尽量贴近故障设备或开启镜像端口6.2 我固定的排障动作抓前、抓中、抓后三步法抓包最忌讳一上来就一顿猛抓。我自己总结了一套固定动作。抓前先回答三个问题流量在哪个接口、我需要看哪个协议哪组IP端口、抓到的包要存成文件还是直接看。这三个问题想清楚命令基本就定型了。抓中观察实时输出重点看有没有异常标志位、有没有连续重传、有没有大量广播。抓后一定把pcap文件保存好哪怕当下已经解决问题也要留着做事后复盘或给同事参考。这个过程中还有个动作容易被忽略记录时间点。抓包开始前先记一下当前系统时间抓到异常包时再记一下网络现象发生的时间。事后分析时时间是串联各种日志的核心线索。你如果没有这些记录抓回来的包再完整也很难对应到故障发生的精确窗口。6.3 保留证据的意识与文件命名规范排障的经历告诉我抓包不只是给自己看也经常要交给开发、网络厂商、安全团队。所以抓包文件一定要信息充分。我常用的命名规范是日期_时间_网卡_过滤条件_用途.pcap例如20250611_0230_eth0_port8080_问题复现.pcap。同时我会在抓包前后把tcpdump -D列出的接口信息、网卡速率、系统时间一起记录下来这样别人拿模糊的pcap文件来问时我们至少能从文件名和附带信息里快速对齐上下文。6.4 tcpdump版本相关的坑最后说几个版本坑。第一老版本tcpdump比如4.9之前对vlan关键字的支持不如新版完善遇到VLAN报文过滤不生效时最好先升级版本或改用-e观察链路层头部。第二不同发行版默认的tcpdump参数行为略有差异比如-s默认抓包长度有的是96字节有的是262144字节建议在命令里显式指定-s 0或-s 128避免默认值不同导致的分析偏差。第三在CentOS 6这类老系统上tcpdump解析某些新协议字段可能不完整分析结果要以报文原始十六进制为准。这些坑都不大但每个都曾让我困惑过。尤其时-s默认值这件事我见过有人抓包后拿回Wireshark一看应用层数据全被截断了还以为是网络问题其实纯粹是快照长度设短了。显式指定参数能让抓包行为跨环境保持一致这个习惯值得养成。按照我的经验tcpdump的学习曲线其实并不陡峭难点在于你是否愿意在平时多模拟、多复盘。我在实际排障中最受益的一个习惯是每次抓完包不管问题有没有解决都花十分钟把抓到的报文过一遍看看有没有什么异常点之前没注意到。很多网络隐患就是这么提前发现的。还有一个小技巧你可以在自己的电脑上装个虚拟机用tcpdump抓ssh登录自己的流量观察三次握手和加密协商过程多练几次手感很快就出来了。网络排查是门经验活tcpdump就是你手上最值得信任的那把刀。 干网络这一行差不多十年我见过太多同事在服务器前排障的时候第一反应是问“谁装个Wireshark”。但说实话真到了生产环境那台Linux服务器上我绝大多数时候第一件事是敲一条tcpdump命令。这玩意儿没有图形界面一个黑框框加一堆看似晦涩的参数但它是流量抓包和网络问题排查里最能救命、也最体现功底的工具。这篇就从零开始把我这些年用tcpdump踩过的坑、总结出来的方法一次讲清楚。tcpdump是什么它是Linux环境下最经典的命令行抓包工具基于libpcap实现能把经过网卡的数据包截获、过滤、输出或保存成文件。它能解决的问题非常明确在不装任何图形界面的服务器上、在远程SSH连接里、在需要长时间自动化采集流量的场景下搞清楚“包到底走了没有”“对方回没回包”“回包是不是被丢了”“握手到底卡在哪一步”。适合谁看刚入行的网络工程师、运维工程师还有那些需要自己排查网络问题的后端开发。这篇文章不绕弯子直接从原理、命令、过滤语法讲到六个实战场景和性能调优看完你就能上手用。1. 为什么网工不能只依赖Wireshark三个真实场景先说一个我亲身经历的事。有一次某个内部系统的数据库出现大量连接超时我登录跳板机排查发现数据库服务器在机房内网出于安全策略无法通过图形化方式访问更不可能在上面装带GUI的Wireshark。当时我直接在上面执行tcpdump -i eth0 -nn tcp port 3306 and host 10.20.30.40 -c 100几十秒内就看到客户端发了很多SYN但数据库回包里的SYN-ACK数量明显对不上问题定位到是服务器侧连接队列满导致SYN被丢弃。整个过程没有开任何图形工具只有一条命令。这个例子背后是三个Wireshark做不到或者做不好的场景。第一生产服务器几乎都是命令行环境你没法在上面装Wireshark图形界面哪怕装了你敢在线上随便点击抓包吗第二Wireshark是交互式工具你想实现“每天凌晨自动抓包10分钟”“抓满1GB自动轮转”“把抓包结果持续写入文件供事后分析”用脚本和crontab才能完成这些场景天然属于tcpdump。第三流量很大的时候Wireshark要把每个包都解码并渲染到界面上CPU和内存消耗远高于tcpdump抓包本身就会影响业务。我经常打一个比方Wireshark像是带全套手术设备的现代化手术室适合你坐在工位上慢慢分析tcpdump像是战场急救包里的止血钳和纱布小、快、灵在条件受限的环境中能先稳住局面。两者不是对立关系而是搭档。正确的工作流通常是用tcpdump在服务器上把包抓下来保存成pcap文件然后带回到本地用Wireshark做深度协议分析。维度Wiresharktcpdump安装环境需要图形界面或桌面环境纯命令行几乎任何Linux都可用资源开销高解码渲染耗CPU/内存低适合长时间抓包过滤能力强大但依赖界面交互依赖BPF表达式标准化、可脚本化远程使用需要X11转发或远程桌面SSH连上直接用自动化困难GUI难自动化极简单命令加脚本即可分析体验图形化、协议解析丰富原始输出需要一定的报文字段阅读能力所以我的观点很明确一个合格的网工Wireshark可以慢慢精通但tcpdump必须随手能用。尤其当你面对的是几十台服务器的集群或者只有命令行入口的生产环境tcpdump才是真正的第一抓手。2. tcpdump抓包原理与四个必须搞懂的基础概念很多人用了很久tcpdump却说不清它到底是怎么抓到包的。甚至有人问我“tcpdump是不是在应用层抓包”这个误解很典型。要真正用好它下面这四件事必须搞清楚。2.1 数据包是怎么从网卡到tcpdump手里的数据包被网卡接收后先进入内核的协议栈处理正常情况下会经过链路层、网络层、传输层最后交给应用程序。而tcpdump这类抓包工具利用的是libpcap库它通过Linux内核提供的AF_PACKET套接字在较老的系统上是SOCK_PACKET在报文进入协议栈做正式处理之前复制一份副本出来给用户态程序。这句话有两个关键点。第一个关键点抓到的“副本”不只是某个协议的报文而是从链路层开始的完整原始帧所以默认情况下你能看到以太网头部、IP头部、TCP头部和应用层数据。第二个关键点内核提供了一份流量给tcpdump处理但原包依然走正常协议栈路径所以抓包行为本身不会改变数据包的正常转发最多是带来一点点CPU开销。这也是为什么我们常说流量抓包是一种“旁路观察”不是“串接拦截”。BPF伯克利包过滤器在这个过程中扮演了闸门角色。你写的过滤表达式会被编译成一段伪机器码在内核态执行。它的意义在于不需要把每个包都拷贝到用户态再判断而是在内核态就把不关心的包丢弃大幅度降低拷贝量和用户态处理压力。理解这一点后你就明白为什么tcpdump过滤表达式写得好不好直接影响抓包性能。2.2 网卡工作模式与本地回环默认情况下网卡只会把目的MAC是自己、或者广播/组播的报文交给内核。但抓包的时候我们经常需要看整个链路上的流量比如交换机上有两台机器在通信而你只想在第三台机器上“旁观”它们这时候就必须让网卡进入混杂模式。tcpdump加-p参数可以关闭混杂模式不加的时候默认打开实际上tcpdump在Linux上默认启用混杂模式。有一个特别容易忽略的坑本地回环接口lo。你抓本机进程之间的通信时比如用客户端连本机的服务端流量只是走loopback接口如果不加-i lo什么都抓不到。我见过不少人排查本机服务问题对着eth0抓了半天一片空白实际上流量就在lo上。这也引出一个排查习惯先确认流量到底走哪个接口再决定抓哪个网卡。2.3 理解BPF过滤表达式tcpdump的灵魂BPF表达式是tcpdump最核心的东西如果你只会-i eth0而不写过滤规则那在生产环境上基本没法用。举一个最简单的例子一个繁忙的数据库服务器每秒几千个包你需要从中筛选出某个客户端IP发往3306端口的包。这就要写tcpdump -i eth0 -nn tcp and src host 10.0.0.5 and dst port 3306这里的tcp、src host、dst port都是BPF语法。BPF表达式由限定词构成常见的三类限定词类型限定词host、net、port、portrange、方向限定词src、dst、src or dst、src and dst、协议限定词ether、ip、ip6、arp、tcp、udp、icmp。它们之间可以用布尔运算and、or、not组合还可以用小括号调整优先级。这就是为什么tcpdump能精准匹配任意维度组合。理解BPF表达式之后还有一个高级技巧很多网工不知道tcpdump支持“基于报文内容的过滤”。比如你想抓所有TCP SYN包其实是抓tcp[13] 0x02 ! 0。这个写法基于TCP头部的字节偏移13号偏移字节对应TCP标志位0x02是SYN位。同理抓RST包是tcp[13] 0x04 ! 0。这个能力在调试特定报文时特别有用后面实战部分会展开。2.4 tcpdump的完整命令结构摆脱“只会加-i抓个试试”的阶段你就要把tcpdump的命令结构完整掌握。它总体上是这个形态tcpdump [选项] [过滤表达式]常用的选项我整理成一张表每个都是实战里高频用到的。选项作用我的使用习惯-i 接口指定抓包网卡如eth0、lo、any不确定走哪张网卡时用any-c 数量抓到指定数量包后自动停止快速验证时用避免一直抓下去-n不做域名解析直接显示IP必加解析域名会慢且可能产生额外流量-nn不解析IP和端口名称排障时必加避免把80显示成http-s 长度设置抓取报文长度0表示整包默认抓前一部分需要分析应用层时设0-w 文件名将原始包写入pcap文件需要事后分析或交给Wireshark时用-r 文件读取pcap文件进行分析抓完回来离线分析-v / -vv / -vvv输出详情逐级增加需要看TTL、校验和、选项字段时加-e打印链路层头部信息排查ARP、VLAN、MAC问题时必加-A以ASCII形式显示应用层数据快速看HTTP报文内容时用-X以十六进制加ASCII显示调试非文本协议时用-q快速输出模式只输出极少信息流量大时减少输出占用的CPU-D列出所有可用抓包接口到了新服务器先看有哪些网卡其中有一个非常实用但我发现很多人不用的选项组合-w加-C加-W。-C表示每个文件多大单位是MB-W表示最多保存多少个文件配合起来可以避免抓包文件把磁盘撑爆。举例tcpdump -i eth0 -nn -s 0 -w /data/capture.pcap -C 100 -W 10 tcp port 443这条命令会持续抓取443端口流量每个文件到100MB就切换最多保留10个文件旧的自动覆盖。这样即使忘了停掉抓包磁盘也不会被写满。这个技巧我在生产上用过无数次强烈建议收藏。3. 从小白到熟练tcpdump输出和过滤表达式的层层递进基础概念过了之后就要解决“抓下来的东西怎么看”“过滤条件怎么越写越精准”这两个核心问题。这一节我把输出格式和过滤写法掰开揉碎了讲。3.1 先学会看懂tcpdump的输出格式抓包之后屏幕上会一行行刷出报文信息。很多新手第一次看这些输出是懵的我逐步拆解一个典型的TCP报文输出14:23:45.123456 IP 192.168.1.10.54321 192.168.1.20.80: Flags [S], seq 1000, win 64240, length 0这段输出从左到右分别是时间戳14:23:45.123456、协议IP、源地址和端口192.168.1.10.54321、方向箭头、目的地址和端口192.168.1.20.80、标志位Flags [S]、序列号seq 1000、窗口大小win 64240、包长度length 0。看到Flags [S]就知道这是TCP三次握手的第一步SYN包。常见的标志位对应关系[S]是SYN[.]是ACK[F]是FIN[R]是RST[P]是PSH。组合出现时比如[S.]表示SYN-ACK[FP.]表示FIN加PSH加ACK。如果你带着-nn抓包端口就显示数字不会有歧义如果不加它可能会显示成54321和http这种服务名反而增加心算负担。所以我在所有命令里都会带上-nn。UDP报文更简单没有标志位和序列号14:23:46.654321 IP 192.168.1.10.5353 192.168.1.20.53: 1234 0.000000 C? example.com. (31)这是DNS查询请求C?代表这是Client的查询example.com.是查询的域名括号里是报文总长度。看到这些字段能解构出来你就能在没有任何图形界面的情况下快速判断网络状态。3.2 按主机过滤最常用的第一步主机过滤是所有网络排障里最高频的需求。例如排查“某个IP是不是在跟你通信”最基础的就是hosttcpdump -i eth0 -nn host 192.168.1.100这条命令会抓一切跟192.168.1.100有关的包无论方向。如果你想区分方向用src host和dst host。比如抓某台服务器发出的流量用src host抓发给它的流量用dst host。我习惯在排障时先观察双向通信因为很多时候“对方没回包”和“对方回了但你没收到”是两种完全不同的故障。如果你只抓单向流量很容易漏掉关键线索。先抓host得到全貌再逐步收窄为src host或dst host这比一开始就限定方向要稳妥。3.3 按端口和端口范围过滤端口过滤用于定位特定服务。最基础的是tcpdump -i eth0 -nn port 8080这相当于把所有源端口或目的端口是8080的包都抓下来。更精确的写法是src port和dst port。端口范围用portrange比如看DHCP流量抓portrange 67-68。端口过滤排障时最典型的应用场景你怀疑某个服务有异常但服务器上同时跑着好几个应用。比如一台机器上既有Nginx在80端口又有Java服务在8080端口还有数据库在3306端口。你只关心Java服务的连接就写tcpdump -i eth0 -nn tcp port 8080这样Nginx的流量完全不会干扰你。还有一个组合技巧抓客户端IP到特定端口的精准组合tcpdump -i eth0 -nn tcp and src host 10.0.0.5 and dst port 3306这是我在排查数据库问题时最常敲的命令。3.4 按协议过滤协议过滤是基础中的基础。tcp只抓TCP包udp只抓UDP包icmp只抓ICMP包arp只抓ARP包。组合场景非常多比如查网络不通先用icmp抓ping包再用arp看MAC解析是否正常。用tcp or udp把传输层主流量都抓下来结合port使用通常是我排查应用连接问题的标准起步姿势。IPv6环境下还有一个坑很多老网工习惯了ip关键字但IPv6报文要写ip6。比如tcpdump -i eth0 -nn ip6 and tcp port 443不写ip6的话有些版本的tcpdump默认只匹配IPv4IPv6的流量会被漏掉。排障时如果发现机器明明有IPv6地址但抓了半天没有任何流量排除这个点往往就是答案。还有一个容易被忽略但很实用的协议vlan。如果服务器接的是trunk口收到的包带VLAN tag默认tcpdump的过滤逻辑会跟VLAN标签产生“错位”因为在Linux上VLAN头部在以太网头之后、IP头之前。解决方法是先写vlan再写其他过滤条件tcpdump -i eth0 -nn vlan and tcp port 8080老版本tcpdump还有一个经典场景需要先vlan再做协议匹配否则过滤条件会不生效但新版本对VLAN的处理已经友好很多。遇到带tag的流量建议第一时间加这个前缀。3.5 组合逻辑与高级匹配网工的分水岭单一条件过滤只是入门真正的分水岭是会组合逻辑和高级匹配。组合逻辑用的就是and、or、not和小括号。举个例子我想抓某个网段内除了某台机器之外的所有TCP 443流量tcpdump -i eth0 -nn tcp and dst port 443 and src net 192.168.1.0/24 and not src host 192.168.1.200这里src net 192.168.1.0/24表示源地址在某个网段内not src host排除了特定主机。实际排障时这种条件组合能迅速缩小范围避免被无关流量淹没。再引入基于报文内容的过滤。抓TCP的SYN包用tcp[13] 0x02 ! 0抓RST包用tcp[13] 0x04 ! 0抓TCP连接中的重传通常在Wireshark里看标志但命令行下可以先抓所有含SYN和ACK的包来分析。举一个我实测用过的例子排查某个服务大量出现TCP连接被重置我抓所有RST包定位哪些IP在发tcpdump -i eth0 -nn tcp[13] 0x04 ! 0这条命令在下发后立刻看到一堆来自某个跳板机的RST包问题很快就定位到是安全策略主动切断连接。如果不懂tcp[13]这种写法你可能要把所有流量抓下来用Wireshark过滤效率差非常多。3.6 抓包时机的把握先抓再说还是先过滤再抓很多新手容易走两个极端要么不加任何过滤条件就把所有流量抓下来导致文件巨大、分析困难要么过滤条件写得太严格结果真正需要的包没抓到。我的经验是分两步走。第一步先放宽条件抓一小段时间比如-c 100观察当前流量的大致构成这好比先“看一眼战场”。第二步根据第一步结果收窄条件开始正式抓包。假设我第一步发现网卡上有大量访问某IP的流量第二步就锁定tcpdump -i eth0 -nn src host 10.0.0.8 and tcp port 8080 -c 500 -w /tmp/problem.pcap这样既避免了文件膨胀又保证关键流量被完整保存。我特别强调一点在线抓包排查时第一优先是“保留证据”第二优先才是“精确过滤”。因为故障往往是瞬时的如果你把过滤条件写得太细万一漏掉关键特征排查很容易陷入被动。4. 六个真实场景的现场排障实录排障技巧讲了一堆不如直接看我实际用过的案例。下面这六个场景每个都是我过去踩过的真实问题类型你可以直接照着操作。4.1 场景一服务器对外请求超时怎么区分网络还是应用问题有一次某个应用服务器调用外部支付接口频繁超时。应用开发说是网络问题网络团队说是应用问题。我登录服务器抓了一段调用目标的连接过程tcpdump -i eth0 -nn host 203.0.113.10 and tcp port 443 -c 60输出里很清楚看到本机发出了SYN目标服务器返回了SYN-ACK但后续的ACK以及HTTP请求数据一直没有出现。这意味着三层和四层网络是通的问题出在应用层——本机发出握手后应用进程因为自身原因没有继续完成TLS握手或HTTP请求。顺着这个方向查下去果然发现是本地应用线程池满导致任务排队请求根本没发出去。这个场景的关键点在于看到SYN和SYN-ACK就说明网络路径是通的看到“第三次握手没发”或“发了但没后续数据”就要往应用侧深挖。反之如果SYN发出后连SYN-ACK都等不到那就是中间链路或目标防火墙拦截的问题。一次抓包就能把责任划分得清清楚楚。4.2 场景二接口响应慢抓包拆解耗时分布另一个经典场景用户反馈某个网页打开很慢后端服务响应也慢。我在前端服务器上同时抓两个方向的包用时间戳来拆解耗时。tcpdump -i eth0 -nn host 192.168.1.50 and tcp port 80 -w /tmp/http_slow.pcap抓完用Wireshark打开启用TCP时间戳分析。通常能从数据包里看出几个时间差客户端到服务器完成TCP握手耗时、TLS握手耗时、发送HTTP请求到收到响应的间隔。有一次我分析后发现TCP握手很快但浏览器发出请求之后服务器在20毫秒内就返回了ACK却迟滞了整整3秒才返回HTTP响应数据。这说明瓶颈在后端应用处理而不是网络传输。把抓包结果截图发给开发争议瞬间就解决了。这里我额外说一个经验排查“慢”的时候不要只看单个包的时间戳建议先看“首个请求包到首个响应数据包之间间隔多少”这个间隔基本对应服务端的处理时间非常直接。4.3 场景三DNS解析失败判断是本地缓存还是上游问题某天办公网大面积反映网页打不开浏览器提示找不到服务器。初步怀疑DNS。我在DNS客户端机器上执行tcpdump -i eth0 -nn udp port 53 -c 20输出显示客户端向本地DNS服务器发出了查询但没有收到任何响应。继续抓DNS服务器的出口也没有发现查询转发出去。这说明本地DNS服务进程可能已经“假死”上层查询根本没有被处理。重启DNS服务后恢复事后看日志确认是服务进程异常退出。如果没有tcpdump单凭nslookup其实也能测出“不通”但很难快速说清楚到底是客户端没发、本地DNS没回、还是转发链路断了。一抓包问题层次一下就清晰了。4.4 场景四内网间歇性“断网”结果抓到ARP风暴某内网偶尔断网ping网关时而通时而不通网络设备配置看起来一切正常。我在一台办公机上抓包tcpdump -i eth0 -nn -e arp加-e是为了看到链路层信息。没抓多久就见屏幕上疯狂刷ARP响应源头都指向某一台机器的MAC地址。几百条ARP广播在短时间内把交换机CPU打满导致正常数据转发被延迟。后来查明是那台机器网卡故障或中了ARP类病毒不断伪造ARP应答。处理办法是封掉那个MAC地址同时更新交换机端口安全配置。这个场景如果只靠Wireshark做镜像抓包当然也能看但没有镜像端口权限时tcpdump直接在终端侧就能给出初步判断。4.5 场景五TCP重传频发判断中间链路丢包一个专线业务经常卡顿怀疑专线质量。我在业务服务器上抓包看TCP重传情况tcpdump -i eth0 -nn tcp and host 192.168.100.66 -w /tmp/loss.pcap抓完导入Wireshark看Expert Information里的重传和快速重传数量。大量重传且序列号跳跃明显基本可以判定中间链路丢包或乱序。后来配合丢包检测工具对比证明就是运营商专线链路某一段光衰过高导致。这里tcpdump的价值在于它敢在生产服务器上长时间抓包采集样本而Wireshark在同等流量环境下很难持续运行几个钟头不卡。4.6 场景六抓容器或指定进程的流量容器化部署普及后网工经常要抓Docker容器里的网络流量。这里有一个关键认知容器有独立的网络命名空间你在宿主机上直接tcpdump -i eth0看到的流量是宿主机的不一定能看到容器内部的loopback通信或容器独立网络栈的流量。抓容器流量有两个常用办法。第一个找到容器的网络命名空间用nsenter进入去执行tcpdump。大致思路是docker inspect --format {{.State.Pid}} 容器名 nsenter -t 容器PID -n tcpdump -i eth0 -nn tcp port 8080 -c 50第二如果容器使用host网络模式那直接在宿主机上抓对应端口即可。我自己的习惯是能先绑定端口就绑定端口因为进容器的网络命名空间操作直观但生产环境上权限管控比较严格时直接抓宿主机的对应端口更省事。这里要特别提醒一句抓容器流量时注意区分容器网桥名比如docker0和eth0是两个完全不同的链路位置抓错地方就是白忙一场。5. 生产环境实战tcpdump性能调优与文件管理在新手阶段能抓出包来这个阶段要考虑的是“怎么抓才能不影响业务”“怎么管理抓包文件才能不把磁盘撑爆”。生产环境的抓包跟实验室完全不同这几个点必须掌握。5.1 抓包文件的四要素-s、-w、-C、-W组合使用前文提过-w是写文件-s 0是抓全包-C限制单文件大小-W限制文件数量。我记得有一次帮某平台排查问题没有加文件的轮转参数直接-w开抓结果一个晚上抓了上百GB把数据盘差点撑满。从那以后凡是在生产上做长时间抓包我必带-C和-W。一条保护磁盘的命令长这样tcpdump -i eth0 -nn -s 0 -w /data/cap_output.pcap -C 200 -W 5 tcp port 8080这条命令限制每个文件200MB最多5个总磁盘占用不超过1GB即使你人跑开了也不会出事。另外-G选项可以按秒轮转文件比如-G 3600表示每小时切换一个新文件适合长期监控时按时间段归档。5.2 使用环形缓冲区避免磁盘被写满上面说的-C加-W本质上就是一种环形缓冲区思路。如果在抓包前就想好最多保留几个文件那磁盘始终可控。实际工作中我还会配合系统层面的日志轮转工具或定时任务做清理但-C-W是tcpdump自身最简方案不需要依赖外部脚本。有一个细节容易踩坑如果-w指定的目录满了tcpdump不会自动停而是会报错并退出导致抓包中断。建议在开机启动脚本或nohup启动之前先用df -h检查一下磁盘剩余空间至少预留1.5倍你预期的文件总量。5.3 大流量下性能优化快照长度和缓冲区大流量环境里tcpdump本身的开销过高会导致丢包甚至影响业务。优化思路有三个。第一用-s限制快照长度不一定每次都要抓全包。很多排障场景只需要看头部信息比如TCP握手问题抓前128字节就足够-s 128能大幅减少数据拷贝量。第二tcpdump在Linux上有多Buffer机制如果遇到“内核丢包”计数明显可以适当调大socket接收缓冲区但这个通常需要修改内核参数net.core.rmem_max等。第三用-B参数设定缓冲区大小比如-B 4096表示4MB缓冲区能缓解瞬时流量高峰导致的丢包。实际命令示例tcpdump -i eth0 -nn -s 96 -B 4096 tcp port 8080 -c 10000我实测下来流量约几百Mbps时限制快照长度和加大缓冲区就能显著降低抓包丢包率。提示生产环境尽量抓“够用”的包而不是“全部”的包。计算下你这个问题需要看到应用层哪个字段再决定快照长度。抓全包一时爽分析文件和磁盘空间会让你后悔。5.4 后台运行与自动化抓包排查问题经常需要跨夜间时段。ssh一断前台tcpdump就没了。我惯用nohup把tcpdump放到后台nohup tcpdump -i eth0 -nn -s 0 -w /data/cap.pcap -C 200 -W 8 tcp port 8080 /dev/null 21 然后可以用pidof tcpdump或者查看/data/cap.pcap文件大小变化来确认抓包进程还活着。如果要每天定点抓包可以写一个简单的定时任务但注意别和业务高峰期冲突。做自动化抓包时我习惯在文件命名里加上日期时间比如cap_20250610_2330.pcap方便事后梳理。还有一点需要强调nohup挂后台的时候标准输出尽量重定向到空设备或者日志文件否则你后期可能会看到终端里残留大量信息。我是直接把输出写到日志文件里这样随时能回看抓包启动报错之类的信息。5.5 与Wireshark的无缝对接把抓包带回本地分析tcpdump抓出来的pcap文件格式是标准的libpcap格式Wireshark原生支持。我通常是生产上用tcpdump抓文件用scp拉回本地再用Wireshark打开分析。这样既保留了tcpdump在远端的高性能和低资源占用又享受了Wireshark在本地强大的可视化分析能力。如果是纯命令行环境也可以用tsharkWireshark的命令行版本直接在服务器上做离线分析但多数情况下本地图形化更方便。在Wireshark里打开pcap后我第一步按下CtrlAltShiftT打开Telephony菜单里的TCP流图或者直接看Statistics下的Conversation列表先把流量最大的会话找出来再逐步进到Expert Info里看重传和异常。整个过程有个前提你自己要知道抓包时的过滤范围和时间段否则拿回本地分析时面对一堆混杂流量反而无从下手。所以我建议抓包文件名上一定要写清时间、网卡、过滤条件别嫌麻烦。6. 常见问题速查表与我的排障习惯最后这部分我把实际运维里高频遇到的问题整理成速查表顺便分享一套我固定的排障动作。6.1 常见问题速查表现象可能原因排查思路抓包抓不到任何流量网卡选错、过滤条件过于严格、网卡处于非混杂模式先用-i any加-c 10不加过滤条件验证抓到SYN但没回包防火墙拦截、目标服务没监听、中间链路丢包目标机上同时抓包对比检查iptables/安全组大量TCP重传中间链路丢包、带宽瓶颈、对端处理慢看重传的序列号和重传间隔定位丢包路径大量RST包应用主动拒绝、健康检查探测、安全设备干扰用tcp[13] 0x04 ! 0单独抓RST找源头IP抓包文件过大没有限制快照长度或过滤条件太宽加-s限制长度加-C和-W控制文件DNS查询无响应DNS服务异常、防火墙丢弃UDP 53、上游问题分别抓客户端和DNS服务器出口的53端口流量只抓到出向包没有入向包对端没回包、路由不对称、中间设备拦截抓包点尽量贴近故障设备或开启镜像端口6.2 我固定的排障动作抓前、抓中、抓后三步法抓包最忌讳一上来就一顿猛抓。我自己总结了一套固定动作。抓前先回答三个问题流量在哪个接口、我需要看哪个协议哪组IP端口、抓到的包要存成文件还是直接看。这三个问题想清楚命令基本就定型了。抓中观察实时输出重点看有没有异常标志位、有没有连续重传、有没有大量广播。抓后一定把pcap文件保存好哪怕当下已经解决问题也要留着做事后复盘或给同事参考。这个过程中还有个动作容易被忽略记录时间点。抓包开始前先记一下当前系统时间抓到异常包时再记一下网络现象发生的时间。事后分析时时间是串联各种日志的核心线索。你如果没有这些记录抓回来的包再完整也很难对应到故障发生的精确窗口。6.3 保留证据的意识与文件命名规范排障的经历告诉我抓包不只是给自己看也经常要交给开发、网络厂商、安全团队。所以抓包文件一定要信息充分。我常用的命名规范是日期_时间_网卡_过滤条件_用途.pcap例如20250611_0230_eth0_port8080_问题复现.pcap。同时我会在抓包前后把tcpdump -D列出的接口信息、网卡速率、系统时间一起记录下来这样别人拿模糊的pcap文件来问时我们至少能从文件名和附带信息里快速对齐上下文。6.4 tcpdump版本相关的坑最后说几个版本坑。第一老版本tcpdump比如4.9之前对vlan关键字的支持不如新版完善遇到VLAN报文过滤不生效时最好先升级版本或改用-e观察链路层头部。第二不同发行版默认的tcpdump参数行为略有差异比如-s默认抓包长度有的是96字节有的是262144字节建议在命令里显式指定-s 0或-s 128避免默认值不同导致的分析偏差。第三在CentOS 6这类老系统上tcpdump解析某些新协议字段可能不完整分析结果要以报文原始十六进制为准。这些坑都不大但每个都曾让我困惑过。尤其时-s默认值这件事我见过有人抓包后拿回Wireshark一看应用层数据全被截断了还以为是网络问题其实纯粹是快照长度设短了。显式指定参数能让抓包行为跨环境保持一致这个习惯值得养成。按照我的经验tcpdump的学习曲线其实并不陡峭难点在于你是否愿意在平时多模拟、多复盘。我在实际排障中最受益的一个习惯是每次抓完包不管问题有没有解决都花十分钟把抓到的报文过一遍看看有没有什么异常点之前没注意到。很多网络隐患就是这么提前发现的。还有一个小技巧你可以在自己的电脑上装个虚拟机用tcpdump抓ssh登录自己的流量观察三次握手和加密协商过程多练几次手感很快就出来了。网络排查是门经验活tcpdump就是你手上最值得信任的那把刀。