有一次帮朋友排查一个视频推流的问题抓包抓了一整屏数据包列表里红红绿绿一片。翻到中间某个UDP流的时候我注意到一个细节某个包的Info列里多了一个方括号里面写着[Packet size limited during capture]点开详情UDP层的某个字段标着[truncated]。那一刻我脑子里冒出来的第一句话就是嗯老朋友TRUNC又来了。用过Wireshark的人都知道TRUNC这个标记在UDP场景里出现的频率远比你想象得高。它可能来自抓包时的长度限制可能来自IP分片后的重组失败也可能来自UDP长度字段和真实数据长度对不上。很多人一看到TRUNC就关掉窗口觉得是抓包工具坏了或者网络出了问题。其实它是个非常典型的信号背后对应着一整套关于UDP协议栈、MTU、分片、抓包snaplen的底层逻辑。这篇文章就借着“UDP装不下的那一刻”这个场景把TRUNC从原理到复现再到排查和过滤脚本完整地过一遍。1. Wireshark里的TRUNC是截断不是分片1.1 三种最常见的TRUNC出现形式先统一一下概念。在Wireshark里TRUNC不是某个协议的名字而是数据包被“截断”的一种状态标记。日常抓包中我遇到过三种最常见的表现形式。第一种是抓包时设了snaplen单包捕获长度导致的截断。这种情况Wireshark会在包详情里显示[Packet size limited during capture]同时在对应的协议层字段上标上[truncated]。比如你只抓每个包的前128字节一个1500字节的UDP包就会被切掉一大截应用层数据全部丢失但能看到完整的以太网头、IP头和UDP头。第二种是IP分片重组失败产生的truncated提示。UDP包一旦超过路径MTUIP层会把它切成多个分片正常情况下Wireshark会自动重组。但如果某个分片丢了或者分片偏移量对不上重组就会失败Wireshark只能把已有的数据展示出来并在标记里提示truncated或reassembly error。第三种是UDP自身长度字段和实际载荷长度不一致。这种多发生在恶意构造包或者某些实现不规范的协议栈里Wireshark会直接标成[Malformed Packet]载荷部分按truncated处理。三种情况看起来相似但成因完全不同排查方向也南辕北辙。1.2 UDP为什么总是那个“被装不下”的协议要理解UDP为什么这么容易触发TRUNC得从它的协议设计说起。UDP头只有8个字节结构非常简单源端口2字节、目的端口2字节、长度2字节、校验和2字节。注意这个“长度”字段它是16位最大值是65535。减去8字节的UDP头理论上UDP载荷最高可以到65527字节。但这里有个很容易被忽略的点65535这个数字是整个IPv4数据报的最大长度一个IP数据报的总长度字段也是16位。所以UDP载荷的上限应该是65535减20字节IP头减8字节UDP头也就是65507字节。超过这个值的UDP数据发送端的协议栈会直接报错根本不会发出去因为长度字段写不下。这就是“UDP装不下”的最原始含义协议头部的数字容量到头了。但实际网络中真正的瓶颈是MTU。以太网默认MTU是1500字节扣掉IP头和UDP头一个UDP包最多装1472字节的用户数据。一旦超过IP层就会启动分片机制。分片以后在抓包里看到的就是多个IP分片加一个UDP头而不是一个完整的UDP包。如果抓包工具或者协议栈的重组逻辑没跟上TRUNC就出现了。1.3 先分清IP分片和抓包截断写这节是因为无数人在排查时分不清这两件事。IP分片是网络协议栈的正常行为是发送端根据MTU自动做的切割每个分片在IP头中都有fragment offset标记。抓包截断是抓包工具自己的动作因为设置了snaplen只保存了每个报文的前N字节。两者的本质区别是IP分片后数据还在只是被拆成了好几个包snaplen截断后数据是真的丢了后面那些字节抓包工具根本没保存下来。所以在Wireshark里看到TRUNC第一步就是判断这个包是“被拆了”还是“被切了”。判断方法也很简单。IP分片的话你会在IP层看到More fragments标志位或Fragment offset字段有值而且数据包列表里会有多个源IP和目的IP相同、但ID相同的包。snaplen截断的话最明显的特征是frame.cap_len实际捕获长度小于frame.len线缆上的原始长度并且详情窗口里会出现[Packet size limited during capture]。2. 自己动手复现一个UDP装不下的现场2.1 准备一把趁手的工具光讲概念太虚我们直接复现一遍。工具很简单一台Linux机器Windows也行但Linux下调MTU更方便、Wireshark、iperf3。iperf3是网络压测的常用工具很多人只拿它测TCP带宽其实它UDP打流的能力也很强尤其是可以指定数据包长度非常适合模拟大UDP包场景。比如跑一条每秒10Mbps的UDP流包大小设成2000字节这个包一旦上路就会被IP层分片因为超过了以太网MTU 1500。抓包之前先把Wireshark的捕获选项打开在“Limit each packet to”那里先别勾选用默认的完整捕获。这样我们第一条测试能先抓到“IP分片”的样子。等会再用限制长度的方式抓第二次对比两种TRUNC的差异。2.2 用iperf3发起UDP大包打流命令大概是这样的服务端先起iperf3 -s -p 5201客户端打流指定UDP模式、目标带宽和包长iperf3 -c 192.168.1.100 -u -b 100M -l 2000 -t 10 -p 5201这条命令的意思是向192.168.1.100发送UDP数据目标速率100Mbps每个应用层包2000字节持续10秒。-l参数表示读写缓冲区的长度在UDP模式下就是你应用层一次write写入的字节数。跑起来的同时在客户端或者服务端任意一侧用Wireshark抓包。过滤条件直接写udp就行但建议加一个udp.length 1472这样就能把真正“装不下”的包单独拎出来看。iperf3跑完以后命令行会输出Jitter、Lost/Total Datagrams这些统计。我这里特别提醒一句很多人喜欢看server端报告里的Lost然后骂网络丢包严重。但在UDP大包分片场景下分片丢失基本就是路由器或者网卡处理不过来丢的往往不是整个应用包而是某个分片重组失败以后整个UDP包都算丢。Wireshark里看到的情况会比iperf3报告的丢包数更具体。2.3 从抓包里读出分片证据打开抓包结果过滤udp.length 1472你会看到类似这样的画面每个2000字节的UDP应用包先是一个带UDP头的分片紧接着是一到两个不含UDP头、但IP头中Fragment offset有值的分片。点开第一个分片在IP层能看到“Fragment offset: 0”和“More fragments: Set”。点开第二个分片Fragment offset变成了1480More fragments可能是Not set。1480这个数字哪里来的以太网MTU 1500减去20字节IP头就得1480。所以IP层每个分片最多承载1480字节UDP那个2000字节的包被切成了1480520两段第二个分片的偏移量正好是1480。此时Info列里Wireshark会显示类似“[Reassembled PDU in frame: 1221]”的提示。意思是这个被拆开的完整UDP包重组后的结果显示在第1221帧里。点开第1221帧你就能看到完整的UDP头和2000字节的载荷Wireshark自动帮你做了重组。如果你看不到这个重组而是每个分片各自独立显示那就要检查一下IPv4协议的首选项里是不是把“Reassemble fragmented IP datagrams”关掉了。2.4 抓包长度限制引起的TRUNC第二次测试我们在Wireshark的捕获选项里勾上“Limit each packet to”并填128字节。意思很直白每个数据包最多只保存前128字节。再跑一次iperf3这次你会看到完全不同的画面。滚到数据包列表很多包的Info列直接标着[Packet size limited during capture]点开之后以太网头、IP头、UDP头都在因为这三个头加起来只有54字节但UDP载荷基本没了。在UDP层点开会看到Data字段是空的或者只有几十字节然后一行提示[Packet size limited during capture]。这里有个很容易踩的坑这种截断发生在驱动层面数据过了BPDBerkeley Packet Filter之后就被切了一刀保存下来的原始数据只有前面那一小段Wireshark再神通广大也找不回后面的数据。所以任何后续的分析都只能基于头部的元数据应用层payload就别指望了。这就是为什么很多安全分析和协议解码场景里snaplen必须设大或者不设否则等于白抓。2.5 别漏了重组开关Wireshark默认会自动重组IP分片但如果你在一个特殊场景下发现分片没有合并成完整UDP包先别急着怀疑网卡或者驱动去检查一下设置。路径是Edit - Preferences - Protocols - IPv4右边有个“Reassemble fragmented IP datagrams”默认是勾上的。如果被取消了你看到的就是一堆零散分片每个都像半截尸体很多新手第一次遇到会误以为网络出大问题了。同样名字的开关在IPv6协议设置里也有一个IPv6环境下抓分片逻辑一样只是分片头的位置和IPv4不一样。注意即使开了重组如果分片在传输中丢失或者分片乱序严重导致缓存超时重组依然会失败Wireshark会把已收到的分片标成“reassembly error”或“truncated”。这种情况下的TRUNC是网络问题的信号不是抓包工具的锅。3. 真正读懂UDP头长度字段、MTU与65535上限3.1 解读UDP数据包格式要彻底搞明白“装不下”必须得会看UDP头部那几个字段。Wireshark的Packet Details面板里点开一个UDP包从上到下依次是Source Port、Destination Port、Length、Checksum和Data。Length这个字段指的是“UDP头长度 UDP载荷长度”也就是整个UDP数据报的长度。比如一个应用层数据是100字节的UDP包Length就是108。这个字段的值必须等于IP头里的总长度减去IP头长度如果对不上Wireshark就会开始报警具体表现就是我之前说的Malformed Packet或者truncated。我见过有些自定义协议栈实现不严谨Length字段写死成一个固定值结果包发出来以后和实际数据不一致接收方要么截断解析要么直接丢包。Checksum字段值得一提UDP校验和计算范围包括伪头部IP头里的源IP、目的IP、协议号、UDP长度加上整个UDP数据报。Wireshark右下角状态栏会显示“Invalid”或“Not computed”之类的校验信息。如果抓包时网卡开启了UDP checksum offload很多万兆网卡默认开Wireshark看到的校验和可能是错的并不是网络里真的在传坏包这点在做协议开发时别被误导。3.2 IP分片与DF标志再往下一层IP头里有一个跟TRUNC直接相关的标志位叫DFDont Fragment。这个位是发送端用来告诉沿途路由器我这个包不允许分片如果太大了你直接丢掉。ping命令里有个-M do选项就是干这个的。ping -M do -s 1472 192.168.1.1可以测试到某个目标的路径MTU。为什么是1472因为以太网MTU 1500减去IP头20字节和ICMP头8字节正好1472。一旦超过路由器会回一个ICMP Fragmentation Needed抓包时你会看到Type 3 Code 4的ICMP报文里面还带着出问题的MTU值。在UDP传输场景DF标志通常由应用或者系统策略决定。很多视频传输软件为了走路径MTU发现机制会主动设置DF宁可丢包也不让数据被切碎因为分片在丢包环境下的重组成功率太低。而iperf3默认发的UDP包不设DF所以可以被路由器分片。这也就解释了为什么同样是大UDP包在不同网络里抓到的分片表现完全不同。3.3 当UDP长度字段对不上时Malformed Packet有一种TRUNC和snaplen无关也和MTU无关纯粹是协议栈或者抓包工具对“长度”的解读发生了矛盾。比如UDP Length字段写的是500但IP层实际的payload只有400字节那说明有100字节在某个环节被丢了。Wireshark收到后会把UDP载荷按500字节去解析解析到400字节发现数据没了于是标成[Malformed Packet]或者[truncated]。这种情况我见到的最多的两种原因一是中间设备或者网卡驱动截断了包二是某些业务系统自己改了报文长度字段作为私有标记。排查思路其实不复杂先看frame.len线缆上的总长度和frame.cap_len如果cap_len小于len说明是snaplen截断。如果cap_len等于len但UDP Length还是大于可用数据那就是网络里出现了一个“假长度”包需要用校验和确认是不是物理层损坏或者中间有设备在篡改。工具用得好的人还会顺手对比一下同一流的其他包看看是不是只有特定大小或者特定flag触发的。3.4 实操中经常被忽略的缓冲区问题“装不下”的另一层含义其实是系统缓冲区装不下。UDP没有流量控制接收方的套接字接收缓冲区一旦被打满多余的数据包会被内核直接丢弃。很多人抓包的时候发现Wireshark里能看到包但应用程序一个都没收到跑去看应用日志发现UDP接收缓冲区溢出计数一直在涨。Windows和Linux调整UDP缓冲区的方法不一样。Linux下可以用sysctl改net.core.rmem_max和net.core.rmem_default然后应用里调用setsockopt设置SO_RCVBUF。Windows下我记得有注册表或者netsh命令可以调整系统的UDP缓存区上限网上很多人讨论“修改window全局udp系统缓存区”就是这个事。改完以后最好用netstat -su或者任务管理器看一下丢包计数是否归零。这里和Wireshark有什么关系其实关系很大。你在本机抓包是在协议栈的某个钩子上抓的可能看到的是内核已经接收到、但应用还没取走的包。如果缓冲区溢出被丢弃的包发生在抓包点之后那么Wireshark依然能抓到而应用层依然丢包。这种“看起来一切正常但业务就是断”的诡异问题我排查过不止一次最后都是靠看UDP缓冲区统计定位的。4. 常用过滤器与排查速查表4.1 过滤器五条命令锁定TRUNC和分片写这篇文章之前我又把过滤条件重新整理了一遍下面这几条是我在不同场景下经常轮换用的。udp.length 1472 ip.flags.mf 1 || ip.frag_offset 0 frame.cap_len frame.len _ws.malformed tcp.analysis.reassembled_in || ip.defragment第一条筛选所有超过1472字节的UDP包用来快速定位大包。第二条筛选所有IP分片不管是不是UDP这叫先看网络层有没有分片迹象。第三条是关键中的关键它比对抓包长度和线缆长度一旦cap_len小于len立刻说明抓包时被切了一刀这就是TRUNC最常见的识别公式。第四条把所有被Wireshark标记为格式错误的包挑出来适合排查“假长度”的包。第五条用来找分片重组的入口。想定位具体是哪条流出的问题可以再加一个ip.src 目标IP udp的条件组合但核心还是上面那几条熟练之后基本秒定位。4.2 TRUNC相关字段与含义对照整理了一张速查表方便对号入座。字段/标记含义常见原因frame.cap_len frame.len抓包截断snaplen限制或驱动丢数据[Packet size limited during capture]捕获时被截断捕获选项里限制了单包长度[Reassembled PDU in frame: X]分片重组成功IP分片后的完整数据在第X帧能看ip.frag_offset 0非首个分片MTU不足导致IP层分片[Malformed Packet]协议解析异常UDP长度字段与真实数据不一致[reassembly error]重组失败分片丢失或超时UDP Length 实际载荷假长度构造包或中间设备篡改这张表不光是考试用实际排查的时候我会把前三行挂在脑门上先看cap_len再看有没有重组提示然后才去看IP标志位。顺序对了效率就高顺序反了容易在第三个坑里浪费时间。4.3 典型场景排查思路针对几个高频出现的场景我分开说下思路。DNS大响应导致的UDP截断。DNS over UDP能承载的数据有限响应一旦超过512字节就可能触发DNS扩展机制。但如果你用抓包的方式分析DNS看到某个响应包超过1500字节并且出现分片或截断不一定就是DNS问题也可能就是MTU配置错了。先用udp.port 53过滤再看有没有分片分片多不多几个分片能不能重组成完整响应。重组成不了去查路径MTU。iperf3 UDP打流生产环境丢包。这种场景我前面已经讲过客户端跑完看报告里的Lost/Totalserver端和client端的丢包数不一致也是常事。最有效的办法就是在两端同时抓包然后对每个分片做统计。如果server端抓到的分片数少于client端发送的分片数说明丢在中间链路如果两端抓到的分片数一致但应用层还是丢包说明丢在协议栈缓冲区去调缓冲区参数。视频流或音视频传输卡顿排查。这类业务通常用UDP而且包比较大经常触发分片。用udp.length 1000过滤之后如果看到大量分片乱序或者重组失败那视频卡顿的根源基本就锁定了。另外视频流里如果出现snaplen截断会导致Wireshark里看不到帧类型和编码信息影响分析精度这时候把snaplen调大或者用镜像口重新抓一次。另外提一个很多人会问的Wireshark能不能抓串口数据严格来说Wireshark本身不直接抓串口但可以通过一些虚拟串口转网络的方式把串口数据封装成UDP包然后再用Wireshark抓UDP。这种情况下UDP包一般很小不会出现“装不下”的问题但你可以顺着这篇文章里学的过滤器快速把自定义协议的UDP包找出来并解码。算是一个具备了基础技能之后的扩展玩法。最后说点我的个人习惯写了这么多最后分享几个实操细节。每次排查UDP相关问题时我习惯性地先把Wireshark的Preferences里Time Display Format改成“Seconds Since Previous Captured Packet”这样能快速看出分片之间的时间间隔。分片间隔异常大比如超过几百毫秒基本可以断定网络有拥塞或丢包重传。另外一个习惯是在抓包文件里用frame.cap_len frame.len先做一次全局过滤只要有任何一个包命中我就会重新审视这次抓包的配置。很多人传抓包文件给别人分析时根本不提自己设置了snaplen对方如果不知道很容易把截断包当成正常包来分析白忙活半天。所以我也建议看到带TRUNC的pcap文件时第一件事就是打开Capture File Properties看截断长度别急着下结论。TRUNC这个东西说穿了就是“数据没到齐”的提醒。它不一定是网络故障但一定意味着你看到的包不完整。搞明白它是被切的还是被拆的是所有UDP抓包分析的基本功。把前面这些过滤器和判断思路练熟了下次再遇到“UDP装不下”的时刻你就能在几秒内给人一个清楚的结论。
