前阵子公司一台测试服务器报了个很奇怪的故障客户端上传大文件特别慢但网络延迟和带宽测试都正常。我打开Wireshark抓包第一步就去看“统计 - 数据包长度”英文界面叫Packet Lengths想确认一下本机发送方向的数据包长度分布是否正常。结果窗口一开我就发现这个统计菜单默认统计的是整个抓包文件里的全部数据包根本没有区分“从本机发出去的”和“从对端收到的”。也就是说想真正搞清楚“发送的数据包长度”这件事光点一下菜单是不够的还得先解决方向过滤、统计口径、底层字段理解这一连串问题。这篇文章就把我摸索出来的完整做法拆开讲清楚顺便把几个和包长有关的经典坑也一并交代了。1. 统计前先搞清楚Wireshark里的“包长度”到底指哪一段很多人一上来就点“统计 - 数据包长度”然后对着表格发愣因为这个窗口展示的是按长度区间分组的包数量至于这个“长度”是从哪一层开始算的它不会主动告诉你。我建议先花两分钟搞明白Wireshark里几种“长度”的口径否则后面统计发送方向时很容易得出错误结论。1.1 先从菜单认识Packet Lengths统计菜单路径是“统计 - 数据包长度”英文版是“Statistics - Packet Lengths”。点开之后会弹出一个表格按区间列出每个长度范围的数据包数量、平均字节数、最小值和占比。我用一个最简单的例子说明客户端访问一次网站的HTTP请求抓包一共抓到几百个包 Packet Lengths表里四五行的常见分布大概是这样的范围字节数量平均字节数占比0-993565443.2%100-299421825.1%1000-11991811062.2%1400-1599408151449.5%看到没有大量54字节的包和大量1514字节的包。54字节是典型的纯ACK包以太网头14字节IP头20字节TCP头20字节没有载荷1514字节则是满载数据的TCP数据段。这两种极端形态并存正是TCP通信最典型的长相。表格右上角一般有个“复制”按钮可以把统计结果复制成CSV或纯文本写测试报告的时候特别方便。但这里有一个关键限制这个统计窗口默认作用在“当前显示的所有数据包”上而不会自动帮你把方向拆开。如果你在过滤栏里什么都没填它会把上行、下行、广播、组播全部混在一起统计。所以真正要统计“发送方向”的包长必须自己构造过滤条件。1.2 frame.len、ip.len、tcp.len、data.len四字段的差别Wireshark里和“包长度”相关的字段不止一个我把它整理成一张表这是后面所有操作的基石字段名含义典型值使用场景frame.len整个帧的完整长度从以太网帧头开始算是抓包文件里的总大小54、1514、1518最常用的总包长口径ip.lenIP分组总长度包含IP头不包含以太网头40、1500判断是否超过MTU、是否分片tcp.lenTCP段内载荷长度不包含TCP头0、1460判断实际传送了多少应用数据data.len应用层数据长度在TCP重组后可见变化较大判断应用消息的真实长度它们的关系可以用快递来类比frame.len是整个快递箱子的外观尺寸ip.len是内部包装盒的尺寸tcp.len是货品的净含量。如果一个TCP包满载且没有VLAN标签它们的数值关系大概是frame.len 14 ip.len 14 20IP头 20TCP头 tcp.len 54 tcp.len。如果这个包是纯ACKtcp.len 0那么frame.len 54。如果带了VLAN标签整个长度还得再加4字节。实际统计时我习惯优先看frame.len因为它最直观也能直接从列表第一列看到需要判断应用数据量时再看tcp.len。新手经常在过滤栏里写tcplen或者frame.len拼错注意Wireshark的字段名是带点的tcp.len、frame.len。2. 只看“发送方向”的包长度过滤表达式与两种统计姿势标题说的是“统计发送的数据包长度”所以过滤方向这一关绕不过去。这里我给出一套我自己一直在用的过滤方案以及两种比纯Packet Lengths更灵活的统计姿势。2.1 用ip.src界定发送方向用ip.dst界定接收方向方向过滤的基本原则很简单凡是ip.src等于本机IP的包就是本机发出的包ip.dst等于本机IP的包就是本机收到的包。以本机IP 192.168.1.100为例ip.src 192.168.1.100这样就能把所有从本机发出的包过滤出来。如果只想看带有数据的TCP发送包再加一个tcp.len 0因为纯ACK包虽然也是本机发出的但不像“数据包长度”的讨论对象ip.src 192.168.1.100 tcp.len 0如果只看某个具体端口的发送方向比如本机作为客户端访问443端口可以这样写ip.src 192.168.1.100 tcp.port 443这里有两个容易踩坑的细节。第一多网卡机器上一定要确认抓包用的是哪个网卡然后拿这个网卡的IP去过滤。很多人的笔记本同时开着有线网卡和Wi-Fi抓包文件里会混入两个网卡各自收发的内容只过滤一个IP会漏数据。第二广播、组播这类地址没有明确的“本机发起”概念比如ARP请求、DHCP发现报文它们没有ip.src字段所以ip.src 192.168.1.100不会包含ARP流量。如果是排查纯TCP/UDP业务问题这不影响但如果你想把所有“发出去”的包都统计到位就要额外增加arp、dhcp等协议的过滤条件。还有一个小技巧严格按网卡MAC来过滤发送方向用eth.src 本机MAC。在网卡混杂模式下或者存在IP地址漂移时这个条件比ip.src更精确。填好过滤条件之后再点“统计 - 数据包长度”出来的表格就是只针对发送方向的数据包长度分布了这个操作顺序很多人容易搞反——先点统计再填过滤条件那样统计窗口不会实时响应。2.2 另一种姿势IO Graph和Endpoint统计并不是所有场景都适合用Packet Lengths。有时候我想看的是“发送方向在时间轴上的流量走势”或者“发送方向总共多少字节”用另外两个功能效率高得多。第一个是“统计 - IO图”IO Graph。在IO Graph里把Y轴单位从“数据包”切成“字节”再填上ip.src192.168.1.100作为过滤条件就能画出本机发送方向的字节速率曲线。如果曲线出现周期性突刺或者长时间平台期很容易看出问题。看包长分布时包数曲线更直观看吞吐量时字节曲线更准确两者配合起来比单独看一个表格立体得多。第二个是“统计 - 端点”Endpoints。在“IPv4”标签页里Wireshark会为每个IP地址展示独立的“Tx字节”和“Rx字节”这里的Tx就是本机从这个端点发出的数据量。我排查大流量问题时几乎都是先看端点页找到那个Tx字节数异常大的连接再对会话进行深入过滤。会话视图Statistics - Conversations也能看到每个TCP连接两个方向各自的字节数和包数它比端点页更细直接定位到某个连接。三个工具各自的适用场景我总结了一下工具适合看什么注意点Packet Lengths包长分布判断是否满MSS、小包是否过多必须先过滤方向否则两边混在一起IO Graph时间维度上的发送速率、突发流量Y轴选字节更接近真实吞吐量Endpoints / Conversations总体发送量、大流量连接定位Endpoints是多IP汇总单连接要看Conversations我自己的排查习惯是先用Endpoints做全局判断再用Packet Lengths看包长分布最后用IO Graph看时间趋势。这个顺序能让我最快从“数据包数量巨大”的无序状态里找到一个清晰的切入点。3. 包长分布背后的协议机制MTU、MSS与载荷长度不匹配根因如果你只是照菜单统计了一堆数字但看不懂这些数字意味着什么那这活儿等于只做了一半。包长分布不是随机的它被MTU、MSS、网卡卸载机制等一系列协议行为严格约束着。理解了这些约束你才能从一个包长统计表里读出网络和应用的“体检报告”。3.1 为什么大多数数据包集中在几个特定长度区间最常见的以太网MTU是1500字节。MTU决定了一个IP分组最多能封装多少字节而TCP为了不触发IP分片会把MSS最大分段大小协商为MTU减去IP头和TCP头的长度。标准IPv4场景下以太网帧头14字节 IP头20字节 TCP头20字节 54字节MSS 1500 - 20 - 20 1460字节满载数据段的帧长 14 20 20 1460 1514字节所以你在绝大多数传统以太网抓包里看到的最大帧长是1514而不是1500很多人一开始不理解这14字节差在哪。如果网络里带了VLAN标签最大帧长会变成1518。IPv6环境下IPv6头是40字节MSS就变成1500-40-201440。PPPoE拨号环境下MTU往往降到1492MSS只有1452。所以当你看到Packet Lengths统计表里0-99字节和1400-1599字节两段占了绝对大头这是非常健康的TCP流量形态。前者大多是ACK、SYN、FIN这些控制包后者是满载数据段。如果中间段比如100-600字节突然占了大头就要考虑是不是应用层每次写入网络的数据量太小或者启用了某种压缩。如果出现了超过1518字节的帧基本就是开启了巨型帧Jumbo Frame或者网卡卸载功能前者常见于数据中心内网后者往往是抓包分析时需要注意的干扰项。3.2 “负载长度与读取字节数不匹配”到底是谁的问题搜索相关关键词时经常能看到“在网络数据包负载中指定的长度与读取的字节数不匹配该连接已关闭。请与客户端库”这种报错。很多人以为是Wireshark出了问题实际上这个报错背后通常藏着两个原因。第一个原因是网卡TSO/GRO卸载。TCP Segmentation OffloadTSO是网卡把上层传下来的大块数据一次性切分成多个MSS段再发送接收端的Generic Receive OffloadGRO则会把多个小段合并成大块再交给协议栈。问题在于某些网卡驱动在抓包点暴露出来的包不是最终在线路上传输的形态而是一个超大帧比如64KB。这时候Wireshark里看到的frame.len远超1500tcp.len也异常大协议解析器按长度字段去读取数据时就会因为实际载荷和声明长度对不上而报“不匹配”或者直接标记为Malformed。解决办法是在抓包期间临时关闭这些卸载功能。Linux下可以这样操作ethtool -K eth0 tso off gso off gro off抓完包后记得开回来否则高吞吐场景下CPU占用会明显上升。Windows下到“设备管理器 - 网卡 - 高级”里把“大量发送卸载”和“接收段合并”相关选项设为禁用。第二个原因是抓包不完整比如snaplen设得太小、中间链路丢包、抓包缓冲区溢出导致某个应用层PDU跨了多个TCP段但后面的段没抓进来。Wireshark里的表现是看到[TCP segment of a reassembled PDU]或者某个TLS记录只有前半截。遇到这种情况光看包长统计已经不够了得回到抓包现场检查是否有丢包再考虑补抓。理解了这一点再去看那些“负载长度不匹配”的报错就有清晰的排查路径了先关掉网卡卸载重抓一遍包长正常了说明是offload干扰包长还是异常再查snaplen和抓包缓冲区。4. 抓包显示520字节而不是2090字节截断问题的完整排查链路网络上有个高频问题“Wireshark为何只能显示520字节数据怎么显示2090个字节数据”。这个问题的本质通常绕不开截断Truncation和TCP分段两个方向。我遇到过不少人在这一块卡住这里把完整的排查链路按步骤拆开。4.1 先分清楚是“数据只有520字节”还是“抓包器只记了520字节”在Wireshark的抓包列表里点开任意一个数据包在左边的树形图最上层“Frame”部分会看到两个关键字段Frame Length和Capture Length。Frame Length是线路上这个帧的实际长度Capture Length是抓包工具实际保存下来的长度。如果两者不一致比如Frame Length2090而Capture Length520说明抓包工具从头记录了前520字节后面的数据因为某种原因没有落盘这就是截断。如果两者一致都是520那说明在这个抓包点网络里实际传输的帧就是520字节。这个时候再来一个反转你的应用日志里明明写着这次发送了2090字节为什么抓包里找不到一个2090字节的TCP包因为TCP在传输层会把应用层的一大块数据拆成多个TCP段。一个2090字节的HTTP或自定义协议消息如果MSS是1460大概率会拆成1460630两个段分别发送。抓包里压根不会出现2090字节的TCP包这是正常现象不是数据丢了。所以拿到任何“长度对不上”的问题第一步永远是先看Frame Length和Capture Length这两个字段再决定往哪个方向排查。4.2 截断来自哪里snaplen、捕获过滤与显示过滤三个坑截断最直接的原因是snaplen也就是抓包时设置的“限制每个包的长度”。图形界面在“抓包选项”窗口有一个下拉框默认通常是262144字节新版这个值一般不会截断。但很多教学案例为了减小抓包文件体积会建议设置成64或96字节只保留包头。如果用的是这种配置那你所有包的Capture Length都会整齐地变成64或96看到520这种值反而说明这个包的实际内容比较长。命令行工具更常见。比如用tcpdump抓包时有人习惯写-s 96之类dumpcap则可能带上-s 256。一旦限制得比实际帧小后面全部截断。用tshark、dumpcap想抓完整包就写dumpcap -i eth0 -s 0 -w output.pcap tshark -i eth0 -s 0 -w output.pcap-s 0表示不限制长度抓完整帧。还有两个很隐蔽的坑。第一个是“捕获过滤器”和“显示过滤器”的区别。捕获过滤器Capture Filter是在抓包前设置的BPF表达式会直接决定哪些包落盘显示过滤器Display Filter只是把已经落盘的数据隐藏起来。有人发现自己抓的包里看不到某些数据以为是截断其实是在显示过滤栏里填了条件把它们过滤掉了。第二个是抓包缓冲区溢出流量特别大时如果抓包进程来不及落盘驱动会丢包或截断这种在抓包界面上往往有“XX包已捕获XX包已丢弃”的提示。所以遇到长度异常先看Wireshark窗口下方的丢包统计。4.3 已经截断的pcap能补救吗说实话已经截断的包基本救不回来。截断意味着数据没有进到pcap文件里任何事后工具都无法从“未知”里恢复出原始载荷。你最多通过Frame Length字段知道这个包原来有多大但实际内容已经缺失了。不过截断包也不是完全没有利用价值。在大多数情况下frame.len保存的是原始帧长度即使后面的字节没保存统计包长分布时依然可以采用“这个包至少500多字节”的结论。如果你只是做包长统计不关心载荷内容截断数据也够用。但如果要做协议分析、排查应用层内容就必须重新抓包。重新抓包时建议按这个顺序来先关网卡卸载再把snaplen设成0或65535最后确认抓包缓冲区够大图形界面里可以调成100MB甚至200MB。这三点做到了基本能保证抓下来的包是干净完整的。5. 实战用包长统计定位一次上传慢的问题前面说了那么多方法论这里放一个完整的实战复盘就是我开头提到的那个上传慢问题。整个排查过程一环扣一环最后锁定瓶颈只花了不到半小时。5.1 场景复现与抓包第一步环境是客户端192.168.1.100往服务器192.168.1.200上传一个约120MB的文件业务反馈“特别慢”但ping延迟只有1ms丢包率0。我当时抓了60秒的上传流量然后没有急着看包长分布而是先打开“统计 - 端点”在IPv4标签页看到了两个关键IP的数据端点Tx字节Rx字节192.168.1.10011,652,431208,342192.168.1.200208,34211,652,431客户端Tx约11.6MB服务端Rx约11.6MB两边对得上说明链路层传输量没有明显丢失。但这60秒才传了11.6MB折算下来只有1.5Mbps左右而内网带宽明明是千兆。这时候我就知道问题不是“丢了数据”而是“数据走得很慢”要么是TCP窗口受限要么是应用层写入太慢要么是链路质量触发拥塞控制。5.2 从包长分布推断瓶颈接下来切到“统计 - 数据包长度”过滤条件填ip.src 192.168.1.100只统计客户端发出的包。结果如下范围字节数量占比0-99247230.0%100-9991882.3%1000-1399760.9%1400-1599550566.8%66.8%的包是1400-1599字节的满MSS数据段说明TCP每次都在尽力塞满数据MSS协商正常也没有应用层写入过小的问题。那问题在哪我继续过滤重传统计看到客户端发出的包里出现了1223次“TCP Dup ACK”和17次“TCP Fast Retransmission”。这就非常有意思了满数据段占比很高同时重传和重复确认频繁说明链路上存在一定丢包或乱序TCP被拥塞控制死死压住了速率。我还顺手看了一眼零窗口的情况。过滤tcp.analysis.zero_window发现服务端方向出现过几次零窗口通知。这提示服务端接收缓冲区或者应用消费速度也是潜在瓶颈之一但本次抓包里次数不算多属于次因。到这里不同现象对应的排查方向就很清楚了现象可能原因下一步满MSS包占比大 重传多链路丢包/带宽不足IO图、TCP吞吐图、MTU探测包长普遍小于MSS应用写入小、慢启动、压缩调整发送缓冲区、看应用层日志大量纯ACK小包Nagle算法与延迟ACK交互查看包间隔严重时关闭Nagleframe.len异常大网卡TSO/GRO卸载关闭offload后重抓5.3 验证与结论初步怀疑链路在TCP层存在丢包我用ping -M do -s 1400测了MTU发现1500字节的包能通说明MTU正常排除分片问题。接着用IO Graph画了客户端发送方向的字节速率曲线发现流量呈现明显锯齿状每几百毫秒冲高一次然后掉下来典型的拥塞窗口周期性触顶回落。这就基本坐实了问题出在丢包触发的拥塞控制上而不是应用层写入慢。最后我抓了服务端网卡上的包做对比发现同一段流量在服务端抓包点看起来更“平顺”而客户端到交换机这一段才出现大量重传。到这里瓶颈定位就很明确了客户端网卡到交换机之间的线路质量有问题或者客户端网卡的驱动/协商速率有问题。后来检查确认是网线接头松动导致协商降速和少量CRC错误换了一根线之后上传速率恢复Packet Lengths分布里重传统计也归零了。这个案例里包长统计起到的作用是“排除法”先确认数据都是满MSS说明应用层写缓冲没问题再结合重传统计和满包占比把怀疑目标从“应用不会发”拨到“链路不会传”。如果一开始只看吞吐量数字很容易误判成服务端处理慢。这也是我特别推荐把Packet Lengths当作常规排查第一站的原因它虽然只能告诉你“包多大”但配合一点TCP知识能帮你把排查范围快速缩得很小。实际用下来我的一个习惯是抓包前先把网卡卸载关了把snaplen设成0抓包后先看端点统计再看包长分布最后看IO图和TCP流图。这个流程对付80%的网络性能问题都够用。你如果刚接触Wireshark可以先从这招练起等包长分布看顺眼了再往下学TCP流图、TLS解密这些高阶操作会顺利很多。