在Wireshark里翻包的时候有一种情况特别容易让刚上手的同学懵圈数据包列表里明明显示的是UDP双击进去却发现负载部分只有几个字节Frame层还挂着一行灰色小字——[Packet size limited during capture: 512 bytes captured (1200 bytes original)]。对这就是TRUNC一句话解释就是这个UDP包在抓包那一刻就被“腰斩”了。这篇文章要聊的正是这个看起来像报错、其实属于“证据不完整”的TRUNC标志。它离我们并不远用tcpdump远程抓包忘了设snaplen默认值、在服务器上用短快照长度抓UDP流量、排查音视频卡顿的时候看到RTP包被截断……都可能是它出场的时候。我会从TRUNC的识别方法讲起分析UDP数据包被截断的三种典型原因再走一遍一次UDP打流丢包问题的完整排查过程最后给出抓包参数的设置建议和补救思路。适合正在做网络抓包分析、搞UDP传输调优、或者第一次在Wireshark里看到“Packet size limited during capture”的读者。1. 认识TRUNC数据包被“截断”后Wireshark会告诉你什么1.1 捕获长度与原始长度从一列数字里读出断裂痕迹要理解TRUNC先分清两个概念frame.cap_len捕获长度和frame.len线上原始长度。正常抓包时这两个值应该相等一旦frame.lenframe.cap_len就说明包在写入pcap文件之前就被砍掉了一截。打开任意一个包含截断包的pcap文件你会看到两种明显信号在包列表的Info列里Wireshark会直接追加提示文字最常见的就是[Packet size limited during capture]。在Packet Details面板的Frame层会有一行类似[Packet size limited during capture: 512 bytes captured (1200 bytes original)]的说明括号里前半部分是捕获长度后半部分是原始长度。很多人在这个位置会犯一个低级错误只看Length列发现是512就以为这个UDP包本身就只有512字节结果把后面所有分析都带偏了。所以我拿到一个陌生抓包文件第一件事是先把frame.cap_len和frame.len这两列都调出来快速扫一遍有没有明显差值。1.2 为什么说TRUNC是“不完整证据”而非“包错误”TRUNC和FCS错误、Checksum错误完全不是一回事。CRC错误说明线路传输过程中有比特翻转CheckSum错误说明数据内容可能被修改而TRUNC只代表“你没有抓到完整数据”并不一定代表网络本身有问题。它更像是你拿到一张被剪掉半边的地图能判断出大概位置但按地图上的距离导航就会翻车。具体到UDP包上被截断后你通常还能看到完整的以太网头、IP头和UDP头因为这些内容都排在包的最前面。但UDP负载里的业务数据、应用层协议字段比如RTP的时间戳和负载类型、NTP的参考时间戳、DNS的资源记录甚至某些情况下UDP头之后的扩展字段都可能缺失。分析这类包的时候最怕的就是拿着残缺信息去推演完整逻辑——比如看到RTP包序号没有连续就断言丢包结果发现只是抓包截断造成的假象。2. 谁在制造TRUNCUDP数据包被截断的三种典型成因2.1 抓包工具的snaplen人为设定的“腰带”snaplensnapshot length快照长度是抓包时最重要的参数之一它规定了每个数据包最多从线路上拷贝多少字节到缓冲区。如果这个值设置得太小超过的部分就会被直接丢弃产生TRUNC。Wireshark图形界面里Capture Options窗口有一个“Limit each packet to”输入框默认是65535字节命令行工具tcpdump则用-s参数控制。常见翻车方式# 只想抓包头做快速验证结果把负载全丢了 tcpdump -i eth0 udp port 1234 -s 96 -w ntp_debug.pcap # 或者干脆不写-s用某些老版本默认的68字节 tcpdump -i eth0 udp port 1234 -w test.pcap-s 96意味着每个包只保留前96字节已经超过了以太网头IP头UDP头总共42字节或者VLAN场景54字节所以包头字段基本都在但任何超过这个长度的UDP负载都会被截断。我见过把snaplen设成128抓SIP信令结果SDP消息体被砍得七零八落最后还要用“分片重组”的歪招去补数据——非常被动。2.2 IP分片重组失败UDP包“装不进”一个帧第二种TRUNC成因不太容易一眼看出来它和IP分片有关。UDP本身没有自动分段能力如果应用层一次性发送的UDP数据报超过了链路MTU典型以太网是1500字节IP层就会把它拆成多个分片传输。抓包文件里会看到多个IP分片报文Wireshark会尝试将它们重组为完整的UDP数据报。如果某个分片因为网络拥堵、丢包、乱序等原因没有被抓到或者抓包点位于两台设备中间导致只看到一部分分片Wireshark就无法完成重组此时UDP层会显示一个“Reassembly error”同时在Expert Info里出现类似New fragment overlaps old fragment (strings at offset)这种状况和snaplen截断不同它不是被动地砍长度而是因为分片不齐导致重组后的数据报缺了一块。比如一个原始UDP载荷为3000字节的包在以太网上被拆成3个分片但你只抓到了前两个重组结果可能就是第一个分片第二个分片然后标记为“截断”。从效果上看用户同样会看到UDP长度不匹配、数据不完整但根因完全是另一套。2.3 巨型帧、GRO/LRO与“超长包”的怪现象第三种成因在现代服务器上越来越常见网卡开启了LROLarge Receive Offload或GROGeneric Receive Offload内核驱动会把多个连续的数据包在网卡层面聚合成一个“超级大包”再提交给抓包工具。于是Wireshark里会出现一个长度明显超过MTU的怪物包比如Length显示2896、4500甚至更大。这种聚合后的超大包如果超过了抓包设置的快照长度也会被截断。更麻烦的是即使snaplen足够大很多分析工具对超过65535字节的包也会表现异常因为IP头里的Total Length字段是16位最大就65535UDP头里的Length字段同理。GRO产生的超长包实际是多个包的payload拼接协议解析会错乱看起来就像“UDP装不下了”。要验证是不是offload造成的可以对比同一台机器上关闭GRO/LRO前后的抓包结果。Linux下可以用ethtool -K eth0 gro off ethtool -K eth0 lro offWindows网卡则在设备管理器-高级属性里把“Large Send Offload”“Receive Side Scaling”等选项禁用后重试。3. 在Wireshark中快速识别与定位TRUNC数据包3.1 用显示过滤器和自定义列筛出所有截断包面对一个大pcap文件不可能靠肉眼一包包翻。Wireshark里识别TRUNC最直接的过滤器是frame.len frame.cap_len这个条件对所有的截断包都成立不管是snaplen截断还是分片重组失败。如果你只关心UDP流可以叠加协议条件udp frame.len frame.cap_len实际项目里我还会做两层保险第一层在列配置里新增两列分别绑定frame.cap_len和frame.len这样包列表里一眼就能看到长度差值第二层自定义一个颜色规则把frame.len frame.cap_len设为浅黄色背景配合Expert Information一起看。这样即使是上千个包的流量文件也能快速把“问题包”单独拉出来。提示过滤器的写法是frame.cap_len不是frame.caplen中间有下划线。如果提示Unknown field说明你的Wireshark版本可能比较旧可以在“Display Filter Expression”里搜“capture length”确认字段名。3.2 读懂Expert Info里的截断提示Wireshark的Expert InfoAnalyze - Expert Info是定位奇怪包的好帮手。对于TRUNC不同成因会出现在不同分组里成因Expert Info位置典型提示snaplen截断Notes / InfoPacket size limited during captureIP分片重组失败Errors / MalformedNew fragment overlaps old fragment或Reassembly erroroffload聚合异常Warnings / Malformed长度字段异常、解析错位等很多人都习惯只关注红色“Errors”觉得黄色警告无所谓但TRUNC的提示往往藏在“Notes”级别里。尤其当抓包文件里同时存在TCP和UDP时Expert Info的统计列表会把UDP截断和TCP重传混在一起要记得按协议过滤或者直接对frame.len frame.cap_len做一次“Analyze - Apply as Filter”先把截断包隔离出来。3.3 十六进制视图下确认截断边界如果需要在报告里说清楚“这包是被腰斩了”而不是“这包本来就短”可以配合Packet Bytes十六进制视图进一步确认。操作方法是选中任意一个被怀疑的UDP包切到Packet Bytes面板查看数据末尾的最后一个字节。如果数据在某个固定偏移处戛然而止且之后全是灰色区域通常对应snaplen截断。比如snaplen512那所有截断包的最后一个字节都会落在512这个位置。如果数据停止的位置正好是某个分片的边界并且前面还能看到IP Fragment Offset字段的递进那更可能是分片重组失败。如果字节流内容显示是多个Payload的混合体但IP/UDP头只有一个需要考虑GRO聚合。这种基于“数据到底断在哪”的显微镜式观察比只读Expert Info更能帮你还原出抓包点的真实情况。4. 实战复盘一次UDP音视频传输丢包排查中的TRUNC线索4.1 问题现场RTP丢包率异常与抓包文件的“残缺”包有一次帮客户排查视频会议卡顿问题现象是接收端显示丢包率在5%到10%之间波动但网络设备上所有的丢包计数器都是零。我们在发送端和接收端同时用Wireshark抓包想通过RTP序列号对比确定丢包发生在哪一段链路。接收端的抓包文件里出现了大量UDP包Info列清一色显示[Packet size limited during capture: 1434 bytes captured (1448 bytes original)]。第一反应是“是不是交换机把这几个包丢了”因为从数量上看丢包率正好和截断包的比例接近。但做RTP流分析时发现这些截断包的RTP序列号并没有中断也就是说包其实到了只是负载数据被截断了。4.2 排查链路从流量统计到Follow UDP Stream顺着这个线索继续查我先用Wireshark的Telephony - RTP - Stream Analysis打开对应的RTP流发现“丢包率”指标骤降实际丢包率远低于客户端报告的数值。原因很简单客户端判断丢包不只是看RTP序列号还会校验负载完整性那些负载被截断的UDP包在上层Socket读出来时发现长度不对就被应用层统计成了“坏包”甚至“丢包”。接着我又拿一个截断包看它的长度字段UDP头里的Length写的是1448但实际捕获长度只有1434差了14字节。14正好是以太网帧头的大小说明抓包工具是先把以太网头也算进snaplen了导致UDP层被砍掉了最后14字节。再回头看抓包配置原来是那边同事在远程抓包时为了减小pcap文件体积给tcpdump加了-s 1434参数——1434这个值听着挺专业实际上既不等于MTU也没计算IP/UDP头开销。4.3 抽丝剥茧snaplen截断与分片重组失败的分辨技巧这个案例里还有一个小插曲抓包里同时存在另一个IP分片相关的异常让我一度怀疑是不是分片重组的问题。分辨两个成因其实有规律判断角度snaplen截断分片重组失败截断偏移所有包都断在固定snaplen值断点随分片大小变化伴随现象无额外分片提示能看到多个IP分片包长度字段原始长度捕获长度差值恒定原始长度与分片偏移相关Expert InfoNotes级别Errors级别常见overlap提示在那种情况下如果真的是分片重组失败包列表里应该还能看到多个Fragmented IP protocol分包而这次看到的每个截断包都是独立完整的IP包没有分片标志所以可以直接锁定为snaplen截断。最后把抓包参数改成-s 0重新抓了一遍客户端显示的丢包率瞬间恢复正常证明网络本身并没有丢包——问题出在抓包姿势上。5. 如何抓全UDP数据包snaplen设置经验与截断后的补救思路5.1 设置合理的snaplen经验值与计算方式抓包之前设置snaplen最稳的选择是直接设成0或65535让驱动“有多少抓多少”。但在内存和磁盘受限的嵌入式设备或者长时间抓包场景下确实需要控制文件大小这时候可以精确计算标准以太网帧最大1518字节含FCS抓完整一帧不下于单个帧snaplen设为1514去掉FCS就够如果抓802.1Q VLAN包以太网头加4字节设为1518如果抓巨型帧jumbo frame按MTU 9000算设为9000 14也就是9014如果怕性能不够只想留包头的诊断用途不要低于96字节并且要在报告里写明“这个文件不包含完整负载”。tcpdump和dumpcap命令行分别对应tcpdump -i eth0 -s 0 -w full.pcap udp port 5000 dumpcap -i eth0 -s 65535 -w full.pcapWireshark图形界面里取消勾选“Limit each packet to”就等于无限长一般本地网卡上不需要勾选。5.2 关闭网卡offload避免“假巨型包”相关截断如果你抓到的UDP包普遍长度超过1500或者同一个流里出现超大包和截断包混在一起先别急着怀疑MTU设置多半是网卡的GRO/LRO在捣乱。Linux下关闭后要确认一下ethtool -K eth0 gro off ethtool -K eth0 lro off ethtool -k eth0 | grep -E gro|lroethtool -k显示large-receive-offload: off和generic-receive-offload: off才算生效。Windows下则是在网卡高级属性里把“Large Receive Offload”设为Disabled“Receive Buffers”适当调大。关闭offload后再次抓包你会发现包长度回归正常很多莫名其妙的“截断”也随之消失。5.3 TRUNC数据包仍能榨取的信息量如果手头的pcap已经写满了TRUNC包也别急着删掉重抓。大多数情况下即使UDP负载被截断IP头、UDP头、端口号、包长信息都还在这些足够你回答以下问题该UDP会话的流量速率是多少包大小分布如何序列号是否连续RTP、QUIC等基于UDP的协议往返时延、抖动是否正常是否存在IP分片分片偏移是否规律哪个端口对哪个端口在大量通信是否与预期行为一致真正受影响的是深度解析协议内容比如SIP消息体、RTP音频数据、DNS应答资源记录里的具体字段。做这类分析时可以尝试用Wireshark的“Follow UDP Stream”看看首屏数据虽然没有完整负载但偶发情况下应用层协议的前几个字段还在依然能辅助判断。最后再分享一个小技巧如果你跟我一样经常在远程服务器上用tcpdump抓包建议在抓包命令里固定加上-s 0然后用-C 100和-W 50限制文件大小和数量这样既不会因为snaplen太小留下残缺证据也不会把磁盘写爆。我踩过一次这个坑之后已经养成习惯抓完包先跑一下过滤器frame.len frame.cap_len只要有任何一个包命中就说明当前抓包文件对“完整数据”这件事是打了折扣的——宁可重新抓也别拿一个先天残缺的文件去做后续分析。