兄弟们干运维和网络这行的甭管你平时吹得多天花乱坠最后都得落到排查问题这根钢丝绳上。你跟我说你网络架构玩得花我信但你说你链路抖动、应用卡顿、用户那边嗷嗷叫的时候你连个包都没抓明白那我只能说兄弟你还得练。排查网络问题咱们不靠猜全靠看证据。而抓包这个动作tcpdump就是那个最趁手、最不起眼、但最关键的工具。今天这篇不整虚的就聊聊tcpdump最普通的玩法。不是那种把man手册给你抄一遍的教程而是从一个老运维的实际工作角度把它当成一把螺丝刀告诉你什么时候拧哪颗螺丝怎么拧不滑丝拧完之后怎么判断螺丝到底紧没紧。看完这篇你至少能对付掉工作里八成以上的网络排查场景不用再遇到问题就先重启或者对着屏幕发呆。1. 为什么偏偏是它tcpdump的核心思路拆解先把心态摆正。tcpdump不是万能的它就是一个命令行下的抓包分析器原理简单得吓人——把网卡上跑过的数据包按你的规则截获一份副本然后要么打印到屏幕上要么存成文件给你慢慢分析。它的优势从来不是分析得有多深而是贴近底层、轻巧、灵活在服务器上一条命令就能跑起来不依赖任何花哨的图形界面。很多人一上来就被各种各样的参数吓住了其实你只需要抓住三个核心点抓什么、抓多久、抓完怎么办。抓什么这就是BPF过滤规则也就是伯克利包过滤语法。它是tcpdump的灵魂决定了你是把所有流量都捞上来还是只捞你关心的那部分。抓多久抓包不是录监控视频不能无限录。你需要明确时间窗口和包数量上限否则生成的文件能把你的磁盘撑爆。抓完怎么办是直接在屏幕上实时滚动看还是落盘保存成.pcap文件然后用Wireshark等工具去细看。这是两种完全不同的工作模式一个适合临时瞄一眼一个适合深挖慢查。这三个问题想清楚了你已经比百分之八十的初级使用者强。剩下的就是语法熟练度的问题。记住我们是在有目的地取证而不是在海里捞针。2. 上场之前先拿最基本的几个命令热热身上手别整那些花活先保证你能看到东西。2.1 抓包前的三件事先想明白第一你当前要监控哪块网卡。用ip addr或者老的ifconfig看一眼找到你关心流量的那块物理网卡名称常见的比如eth0、ens192、em1。你要是连网卡都搞错了抓半天抓了个寂寞流量根本不过这块卡纯属浪费时间。第二你有没有权限。tcpdump需要root权限才能抓包所以别老想着用普通用户去执行然后报错说找不到设备先sudo -i或者检查一下你的用户是否在sudo组里。在有的生产环境里甚至得看看你的系统是不是SELinux或者AppArmor拦着你到时候报Operation not permitted都不知道是哪儿出了问题。第三确定你要不要开混杂模式。网卡默认只把发给自己MAC地址的包交给内核处理但抓包工具通常会让网卡进入混杂模式把经过这块网卡的所有包都接收一份。所以我们经常看到tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes这行提示其中promiscuous mode开没开就说明这件事。默认情况下像在交换机镜像口这种场景我们必须依赖混杂模式才能抓到别人的流量这个开关非常关键。2.2 从一个最朴素的抓包命令说起比如说我现在怀疑我这台服务器访问某个数据库有问题最简单的我就想先看看连接能不能建立TCP握手能不能完成。直接在机器上敲tcpdump -i eth0 tcp port 3306这条命令的意思是在eth0这块网卡上抓取TCP协议且目标或源端口是3306的包。屏幕上开始一行行刷数据你会看到类似下面这样的东西05:03:02.123456 IP 10.0.1.10.54321 10.0.1.20.3306: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0 05:03:02.124002 IP 10.0.1.20.3306 10.0.1.10.54321: Flags [S.], seq 987654321, ack 123456790, win 65160, options [mss 1460,sackOK,TS val 456 ecr 123,nop,wscale 7], length 0 05:03:02.125001 IP 10.0.1.10.54321 10.0.1.20.3306: Flags [.], ack 987654322, win 512, length 0看到这个你就知道TCP三次握手是正常完成的。S是SYN包S.是SYN-ACK包.就是纯ACK包。如果后面还有一串P开头的包那就是携带了应用层数据的PUSH包。这里有个小技巧Flags字母如果出现[F.]那就是正常四次挥手[R.]就是连接被重置了这往往是排查问题的重要信号。如果我就想把这个过程实时看完那直接-n参数把域名和端口翻译关掉让输出更快更干净tcpdump -n -i eth0 tcp port 3306加了-n之后屏幕上就不会去做IP到域名的反解析也不会把3306显示成mysql输出速度更快也更纯粹。特别是当你抓的是公网流量反查DNS这个过程非常拖慢速度甚至会因为DNS解析超时导致输出卡顿所以-n是我在任何抓包场景里几乎必带的一个参数。2.3 不只会抓还要会看基本输出很多新手看到tcpdump输出的原始行就像看天书一样其实拆开看很简单。我也顺手给你解读一下标准输出格式的几段信息时间戳是第一个字段精确到微秒级是判断延迟的重要依据。然后是协议层头信息比如IP表示这个包是裸的IP包如果是ARP那就会显式写出来。再往后是源地址源端口 目的地址目的端口这个指向关系可以让你快速判断数据流向。然后是很关键的Flags也就是TCP控制位。S建连、F断开、R重置、P推送数据、E显式拥塞混合标志位用点号分隔。seq和ack则是TCP序号和确认号专门用来分析重传和乱序。最后面的win是接收窗口大小可用来辨别接收方缓存压力。把这些字段拼在一起你就能在屏幕世界里看见两台机器之间到底发生了什么。熟练之后很多网络故障从表面现象到根因方向在你脑子里一瞬间就能拉出一条线来。3. 进阶玩法像筛金子一样用过滤表达式基础命令会了接下来得学会“挑食”。电脑网络上的数据包就像嘈杂集市里的人群你得学会只盯着你想找的那个目标而不是把所有人都喊到你面前来一个一个看。3.1 过滤主机只关心源或目的IP排查问题时最常用的就是限定主机。比如我怀疑后端服务器10.0.2.5返回数据有问题那我只抓跟它相关的流量tcpdump -nn -i eth0 host 10.0.2.5这里用了两个n既不做域名反解也不翻译端口号纯纯的数字化输出速度最极致。如果你还想精确到是我本机发给它还是它发给我那就再加方向限定词tcpdump -nn -i eth0 src host 10.0.2.5 tcpdump -nn -i eth0 dst host 10.0.2.5src和dst这两个词非常直观组合使用能精准锁定单向流量。还有更灵活的src or dst组合比如我要看所有从10.0.2.5来或者去往10.0.2.6的流量tcpdump -nn -i eth0 src host 10.0.2.5 or dst host 10.0.2.6单引号包起来很重要因为or、and这些关键字会被shell解释成管道或者逻辑符号别看小看这层单引号少了它很多命令执行结果会直接崩掉或者行为大变。3.2 过滤端口直击服务的咽喉端口过滤是跟具体应用排查绑定的。比如排查web服务直接抓80或443端口tcpdump -nn -i eth0 tcp port 443但我个人更推荐你直接写全五元组逻辑源端口目的端口分开写因为有时候你想区分是外部请求进来还是内部向外请求。比如我只想看本机eth0上对外发起的连接那目的端口一定是远程的443tcpdump -nn -i eth0 dst port 443反过来像收集内部服务日志或观测出网流量那就看源端口tcpdump -nn -i eth0 src port 53这里的逻辑还可以用portrange来抓端口段。比如某个游戏服务器开了一大片UDP端口从20000到30000写起来就是tcpdump -nn -i eth0 udp portrange 20000-30000这种连续端口的匹配在排查P2P或者RPC类服务的时候特别给力不然一条条端口写进去手都能给你写酸。3.3 协议与多条件组合把网撒得刚刚好最后来点真正有实战感的组合。比如你要定位是不是有人在你内网里搞ARP欺骗那就直接只抓ARP协议tcpdump -nn -i eth0 arp比如你要排查DNS解析慢的问题又不想抓太多无关流量可以限定UDP端口53tcpdump -nn -i eth0 udp port 53遇到那种既有TCP又有UDP的服务比如某些基于QUIC/HTTP3的应用想一把梭全抓下来tcpdump -nn -i eth0 (tcp or udp) and port 8443这行表达式里的括号也同样需要单引号保护。另外有个更实在的建议你真的特别明确就要某一种类型比如排除掉SSH的22端口干扰那你可以直接tcpdump -nn -i eth0 port not 22 and host 10.0.2.5活了。这一套组合拳打下来你要的流量就像从沙子里淘出来的金子其余无关数据全都安静地躺在内核缓冲区之外。这里多插一句经验过滤器并不是越复杂越好规则写得越宽内核拷贝到用户态的数据越多丢包概率越大。所以先宽后窄先抓到方向、再细抠颗粒度是实战里效率最高的节奏。4. 落盘为王生产环境必会的抓包姿势实时滚动看几眼适合临时验证但遇到那种老大看了半天才说“好像有点不对劲”的疑难杂症我们就得把包保存下来拿回去慢慢分析。4.1 写出文件与循环切割保存成.pcap文件的命令很常规tcpdump -i eth0 -w /tmp/capture.pcap tcp port 8080这里有个极其重要的点写文件模式下屏幕上不会打印每一行抓包信息因为你告诉它把原始包写到文件里它就不做实时翻译了。很多人第一次用半天没输出以为卡死了其实它是默默在后台干活。如果需要一边抓一边确保文件数量可控可以用-C参数按大小分割文件单位是MBtcpdump -i eth0 -w /tmp/capture.pcap -C 100 tcp port 8080这行命令表示单个文件超过100MB就自动新建下一个文件后面会跟着生成capture.pcap、capture.pcap1、capture.pcap2这样的序列文件。也可以按时间切片-G 60表示每60秒切一个文件适合长时间无人值守。这种循环切文件的方式在生产排查里就是神器既能防止单个文件过大拖垮后期分析也能让回传文件时间点更精确。4.2 控制抓包时长和包数量抓包不能无限期抓下去要给个极限约束。比如我就是想抓3分钟看看情况timeout 180 tcpdump -i eth0 -w /tmp/capture.pcap -n host 10.0.2.5用timeout命令来限时这是一个很可靠的做法比后台挂PID然后手动杀要优雅得多。另外也可以用-c数量控制抓到一定包数自动退出tcpdump -i eth0 -c 2000 -w /tmp/capture.pcap这里-c 2000意思就是抓满2000个包就自己停了适合你只想快速采样几个包验证协议特征时用。要知道有时候你并不需要全程录屏前几秒的特征足以说明问题。结合-c加上-w这个组合是典型的快速取证姿势比如你接到报警说某台机器疯狂发包抓2000个包看看包长跟目标往往几秒就能锁到具体进程的特征。4.3 落盘抓包的缓冲区大小调节生产环境流量稍微大一点你会碰到一个很头疼的坑抓包丢包。这个时候就需要调整内核抓包缓冲区大小参数是-B单位是KB。默认值往往只有几MB高并发下瞬间就被打满新到的包只能丢弃。常见做法是拉高到几十甚至几百MBtcpdump -i eth0 -B 4096 -w /tmp/huge_capture.pcap-B 4096意思是缓冲区设为4MB注意这个单位默认KB。这能显著降低高流量场景下的丢包率。虽然tcpdump在退出时会打印一条包含dropped kernel的统计信息但你要是看完包再发现丢包严重再回头重新抓可就麻烦多了。所以流量很大的场景开局就先把缓冲区拉高别省着用。还有一个很有用的参数是-s控制每个包抓取的长度也就是snaplen。默认是262144字节256KB但绝大多数常见协议我们只看头部和部分载荷就行了。为了减小文件体积可以设成tcpdump -i eth0 -s 128 -w /tmp/small.pcap这样每个包就只保留前128字节足以看到TCP/UDP头以及部分应用层信息。这在无线网卡或者流量大的环境里非常节省空间代价是你可能看不到完整的应用载荷需要根据实际需求权衡。有一点提醒有些协议比如TLS证书、某些文件传输要看全证书或全载荷这时候-s 0才代表完整抓取整个包别到时候抓完发现里面只有一截数据悔到肠子都青了。4.4 直取出可读的十六进制和ASCII内容有时候你不想开Wireshark就是想快速看看包里的实际内容。这时候可以用-X或者-A。-A把包以纯ASCII形式打印出来适合看HTTP明文请求和响应-X则同时输出十六进制和ASCII适合检查二进制协议细节或加密流量的特征。tcpdump -nn -i eth0 -A -s 0 tcp port 80这条命令会把80端口的所有TCP载荷以可读字符形式刷出来排查HTTP接口调试时特别直观。你会直接看到GET / HTTP/1.1、Host:之类的请求行限流了、乱码了、参数丢了一眼就能判断。5. 真实排障演练一次假性超时的血泪实录理论讲了一大堆不发点实战总觉得心里不踏实。跟大家分享一个我亲身经历过的排查案例让我们把前面这些参数串起来用一遍。某个周五下午业务方那边反馈说调用一个内部接口经常超时但又不是每次必现大概两三次里有一次要等好几秒。监控看CPU、内存都没啥压力数据库负载也不高。这种间歇性超时最折磨人因为无从下手。我决定在应用服务器网卡上落盘抓包。先确认网卡名是eth0然后用了这么一条命令tcpdump -nn -i eth0 -B 2048 -s 128 -w /tmp/app_timeout.pcap tcp port 8080 and host 10.10.20.15抓了大概十分钟等到业务方又反馈一次超时之后我把包拿了回来。直接用Wireshark打开先看TCP流。结果发现一个很有意思的现象客户端发出的请求包带P标志数据段已经到达服务器IP但服务器这边迟迟没回ACK然后客户端就开始疯狂重传。重传了好几轮服务器终于是回了一个S.不对是回了一个R也就是连接重置。看起来就像是业务层把连接关了。顺着这个方向去查发现后端Tomcat的线程池配置有问题活跃线程数上限设得太低请求一多连接就被pending最终触发超时重置。客户端看到的是几十秒超时实际上瓶颈根本不在网络链路而在于服务端应用线程池满。这个结论可以说完全是依靠抓包锁定到端口的如果不是看到TCP层面的重传和RST时间点我们可能还在傻乎乎查中间交换机丢包和防火墙策略。这里的经验总结就是抓到包后别急着看乱七八糟的几百兆数据先按照时间顺序过滤出几个关键节点找TCP重传TCP Retransmission、找RST、找零窗口Zero Window这三个信号基本能覆盖大部分“网络慢”的根因方向。6. 那些年我们踩过的坑tcpdump使用常见问题速查玩的时间久了总会有些小坑反反复复出现。我把它们整理成表格方便你对着查。问题现象大概率原因解决/排查方向屏幕上什么都看不到过滤规则写错、网卡选错、流量确实没走这块网卡先用-i any抓所有网卡拿掉过滤条件试试确认抓包机器是否在流量路径上提示Permission denied非root用户执行sudo执行或者给普通用户配置CAP_NET_RAW能力抓包过程中丢包严重缓冲区太小或CPU不够用-B调大缓冲区减少无关抓包范围用-s限制抓包长度文件写入特别巨大抓包范围太宽或snaplen太大严格限定host/port组合使用-s 128限制载荷用-C/-G自动切割文件tcpdump: syntax error过滤表达式引号没加或写错检查是否用了单引号检查语法中and、or的优先级用括号包裹条件时务必加引号抓到包但Wireshark打不开文件未正常结束或抓包过程中被强杀用-w落盘务必用timeout或者-c限制别用kill -9强杀进程只看到请求没看到ACK负载均衡器做了代理或者本机防火墙拦了确认流量路径上是否有四层负载设备检查本机iptables规则想抓但机器带宽已被打满抓包本身成为最后一根稻草改用硬件镜像旁观抓包或先做流量限速及时止损别硬抓最后再给大家一个杀手锏级别的提醒如果你要在生产环境长期蹲点千万别忘了-Z root参数。默认tcpdump在打开抓包设备后会把自己降权到tcpdump用户来执行以防止安全问题。但有些环境下这个降权反而导致无法写文件。如果你遇到这种诡异问题加个-Z root操作就能解决。当然这是个双刃剑自己评估风险再上别乱用。再分享一个我自己的习惯抓完包之后不管有没有发现问题我都会写一行小字记录在案的命令行。这样一个月后看到这个文件还能回忆起当初抓包时的范围和意图而不是对着几百兆的二进制文件发愁我已经忘了自己在验证什么。如果你从头看到这里恭喜你至少已经从“会用tcpdump”进阶到“知道为什么这么用tcpdump”的阶段了。工具永远是死的能灵活组合思路去抽丝剥茧才是这行真正值钱的地方。下次线上出故障别慌先深吸一口气把上面这些招数从头到尾过一遍多半就能摸到一点门道。