Wireshark抓包之统计发送的数据包长度抓包容易看包难看包容易看明白更难。很多人拿到 Wireshark打开一个 pcapng 文件第一反应就是对着几万条报文发呆到底哪条是我发出去的发了多少个包每个包多大总流量占了多少今天这篇就专门解决这个问题把“统计发送的数据包长度”这件事从头到尾拆开讲清楚。先说一下我为什么要专门写这个主题。前阵子帮朋友排查一个云端接口超时问题两边程序都说是网络慢开发小哥甩过来一个抓包文件问我能不能告诉他“客户端往服务端到底发了多少数据”。这种需求在故障排查、性能分析、协议对接里太常见了。Wireshark 自带的统计功能完全可以回答但很多人不会用或者只会看一眼“Summary”稍微复杂一点的需求就卡住了。这篇文章适合刚接触抓包的新人也适合那些已经会用基本过滤、但没深入研究过 Statistics 菜单的工程师。看完之后你至少能自己回答这三个问题发送方向一共多少字节包长分布长什么样某个时间段的发送速率是多少1. 先搞清楚“包长”到底指哪一层1.1 长度列背后藏了至少三个数字我第一次看 Wireshark 的时候以为列表里那个 Length 列就是“包大小”直到有一次拿它跟交换机流量统计对不上账才认真研究了一下。Wireshark 默认显示的 Length 列指的是捕获文件里的帧长度frame length也就是从以太网帧头开始算起的大小。但如果你按下 CtrlAltShiftT 或者点开一个包的详情会发现还有好几个长度概念帧长度Frame Length物理线路上传输的完整帧大小通常包含以太网头部、IP头部、传输层头部和载荷。如果是 VLAN 报文这里还会多出 4 字节的 802.1Q Tag。IP 包长度Total LengthIP 头里专门有一个字段记录这个 IP 包的总长度单位是字节包含 IP 头本身。注意它不包含以太网头部所以正常来说 IP Length 会比 Frame Length 小 14 字节不含 VLAN 时。上层数据长度TCP Len / UDP Length比如 TCP 段的 Length 字段只是指 TCP 载荷的大小不包含 TCP 头而 UDP 的 Length 字段又包含了 UDP 头 8 字节。所以当你问“这个包多大”必须先定义清楚是哪一层的长度。我们统计“发送的数据包长度”我个人习惯默认按 Wireshark 列表里的 Length 列来统计也就是完整帧长因为它最接近真实网卡发出的字节数跟对端抓包、交换机端口计数器也比较容易对齐。如果你关心的是应用层有效数据那就得用tcp.len或者data.len这类显示字段来过滤和计算否则会把协议头开销也算进去数据对不上。1.2 统计发送方向的两个核心过滤思路明白了层次第二步就是怎么定位“发送方向”。抓包文件里每个包都有源地址和目的地址你要统计“发送”本质上就是区分哪些报文是你关注的这台主机发出去的。最常见的写法是以本机 IP 为准ip.src 192.168.1.100这个显示过滤器会把源 IP 是 192.168.1.100 的所有包筛出来包括本机发出的 TCP SYN、HTTP 请求、Ping 请求等。如果要看接收方向就用ip.dst 192.168.1.100。有些场景更复杂比如有两个设备 A 和 B你想统计“A 发给 B”的所有数据那就写成ip.src 192.168.1.1 ip.dst 192.168.1.2这里要特别提醒一个新手常犯的错误不要默认ip.src就等于发送方向。如果抓包位置在路由器或者交换机镜像口上一个包从客户端到服务器对于抓包点来说可能是“从端口 A 进来、从端口 B 出去”但它的 IP 源地址始终是客户端。所以“发送”要看 IP 层源地址或者更严谨一点结合以太网源地址eth.src来判断真正从哪个物理接口发出来的。2. Statistics 菜单里那些和包长有关的入口2.1 从 Protocol Hierarchy 到 Packet LengthsWireshark 的 Statistics 菜单功能非常密集很多入口第一眼不知道干什么用。我按平时使用频率从高到低排个序让你有个整体印象。先说Statistics - Protocol Hierarchy这个窗口会按协议层级展示每个协议的帧数、字节数和端到端的字节占比。它的价值在于快速看“占比”如果发现某种协议占了 90% 的字节那后续再细化分析就有方向了。但它不区分方向所以只能做总量参考。然后是Statistics - Packet Lengths这才是统计包长分布的正主。它会自动把全部包按长度区间分组常见分组是 40-79、80-159、160-319、320-639 等每组显示包数、百分比、累积包数、累积百分比。默认统计的是帧长但你也可以在对话框里调整长度单位的设置选择按字节统计、按比特统计甚至按报文里的特定字段统计。它同样不区分方向所以你得先在外层设置好显示过滤器再打开 Packet Lengths统计结果才会按过滤后的包来算。Statistics - Conversations和Endpoints则适合按会话和端点维度看字节数。比如我想知道本机和某个服务器之间到底互相发了多少字节打开 Conversations选中 TCP 页签找到那对 IP 地址A-B 和 B-A 的字节数分列显示非常直观。这个功能虽然不直接叫“包长统计”但实际工作中我经常靠它快速判断哪个会话流量大。2.2 Capture File Properties 里有个隐藏关键点遇到“统计结果和实际不符”的问题我第一步一定是打开Statistics - Capture File Properties看中间有一项叫 “Snapshot length”快照长度。这是抓包时刻每个报文实际被捕获的长度上限也叫 snaplen。比如很多人抓包时网卡默认设置了 520 字节的快照那么超过 520 字节的实际报文在文件里只保留了前 520 字节Wireshark 的 Length 列就会显示 520而不是真实长度。这种情况下你做任何包长分布统计、字节数统计得到的结果都会偏小而且是系统性偏小。这个细节在后面常见问题部分我会展开讲这里先埋个伏笔。3. 统计发送数据包长度的完整实操流程3.1 用 Packet Lengths 快速拿到“发送包长分布”假设我已经抓好了一个文件本机 IP 是 192.168.1.100现在要看“这台机器发送方向的数据包长度分布”。操作步骤如下第一步在 Wireshark 主界面的显示过滤器栏输入ip.src 192.168.1.100回车之后列表里就只保留本机发出的报文。第二步点击菜单Statistics - Packet Lengths弹出分布表。表格第一列是长度区间比如 “40-79”、“80-159” 等第二列是该区间包数第三列是该区间占过滤后总包数的百分比。这一步基本零门槛十秒钟就能得到结论。但如果抓包文件很大、有几十万条报文显示过滤器计算会有点慢我通常会先加一个更精确的过滤条件比如只想看 TCP 层发出的数据包ip.src 192.168.1.100 tcp或者只想看某个特定端口避免 ARP、DNS 等混杂流量干扰ip.src 192.168.1.100 tcp.port 443Packet Lengths 的分组粒度比较粗如果你需要精确到每个包的具体长度分布可以用tshark导出每个包的长度再用 Excel 或脚本来做精细统计。后面我专门讲命令行方案。3.2 用 IO Graphs 看“发送字节数随时间的变化”分布表只能告诉你长什么样没法告诉你什么时候发送量大。想回答时间维度的问题就要用Statistics - IO Graphs。IO Graphs 是一个折线图工具默认显示“所有包”的速率。我习惯这样配置在显示过滤器里输入ip.src 192.168.1.100然后在 IO Graphs 窗口里把该条曲线的 Y 轴单位从 Packets 改成 Bytes这样折线就表示每个时间间隔内发送的总字节数。如果觉得 1 秒粒度太粗可以把 Interval 改成 100ms 甚至 10ms能更清楚看到突发流量。这里有个技巧Y 轴还可以选SUM(*)之类的聚合函数配合显示过滤器可以做出很多花样。比如我想分别看“发送的 TCP 载荷字节”和“发送的 IP 总字节”两条曲线可以建两条曲线一条过滤器写ip.src 192.168.1.100 tcp.payload另一条写ip.src 192.168.1.100Y 轴都设为 SUM(*) 或 Bytes。两条线之间的差距就是 TCP 头 IP 头 以太网头的开销。IO Graphs 的曲线默认是对整个文件起作用但窗口最下方有个 “Display Filter” 输入框如果你在这里再写一个过滤条件那么只有符合这个条件的包才会被计入曲线。比如写ip.src 192.168.1.100 tcp.port 443曲线就只统计发往 443 端口的流量。3.3 用 tshark 命令行算平均包长和总量图形界面够用了但如果你要处理几十个 pcap 文件或者想写脚本自动统计那还是tshark更顺手。tshark 是 Wireshark 自带的命令行工具装了 Wireshark 就会一起装上在终端直接调用。比如我要统计本机发送方向的包总数和总字节数最快的方式是用-q静默模式和-z io,stat统计模块tshark -r capture.pcapng -q -z io,stat,0 -Y ip.src 192.168.1.100输出里会有一行| Frame: 12345 | 12345678 |之类的结果第一数字是包数第二个是总字节数。但这里统计的字节数默认是帧长度与抓包时是否截断直接相关。要算平均包长可以分两步先拿到总字节数再拿到总包数除一下就是平均帧长。也可以通过 tshark 自带的 TShark 字段打印tshark -r capture.pcapng -Y ip.src 192.168.1.100 -T fields -e frame.len这会输出一行一个数字把这些数字导入 Excel 或者 Python 里做分布统计、排序统计都很方便。我自己写过一个简单的 Python 脚本读取frame.len后用 numpy 直接算均值、中位数和 95 百分位在评估某个协议是否容易触发 MTU 分片时特别有用。4. 一个真实场景网页访问时“发送方向”到底发了多少4.1 场景设定与抓包准备理论讲了一堆还是用一次常见的网页访问全过程来演示。假设我在浏览器里访问http://example.com本机 IP 是 192.168.1.100对端服务器 IP 是 93.184.216.34网关和 DNS 各干各的。我提前在 Wireshark 里设置好显示过滤器ip.addr 192.168.1.100 or ip.addr 93.184.216.34避免无关流量混进来然后开始抓包刷新页面等页面加载完毕停止抓包。这个抓包文件里包含了我方发出的 DNS 查询、TCP 三次握手、HTTP GET 请求以及服务端返回的响应数据。现在要严格回答“我这一侧发送方向总共发了多少数据、包长分布如何”。4.2 双重过滤确认纯发送方向有人会问为什么不在抓包开始前就设置捕获过滤器而要在显示过滤器里慢慢筛因为捕获过滤器会在抓包时就把不符合条件的包丢掉万一之后发现想看的流量没抓到就没办法补救了。所以我一般建议“抓全一点显示时再筛”除非流量大到你完全不关心其他东西。先删除之前加的总过滤器重新输入ip.src 192.168.1.100列表里剩下的就是本机发出的包。此时再做一步细化只看和这个网站交互相关的排除 DNS 查询可能产生的干扰ip.src 192.168.1.100 tcp.port 80对于普通的 HTTP 访问这种方法比较直接如果是 HTTPS则把端口改成 443 即可。4.3 统计结果解读与细节确认在过滤好的视图下打开 Packet Lengths通常会看到两部分一部分是很小的包40-79 字节区间对应 TCP 三次握手的 SYN、SYN-ACK、ACK还有 HTTP 请求发送结束后的小 ACK一部分是稍大的包具体大小取决于 GET 请求头长度和 Cookie 长度。如果页面里有上传操作还会看到接近 1460 字节的包那说明应用层数据已经超过了单包承载能力需要多次发送。再用 IO Graphs 打开设置好 Y 轴为 Bytes能明显看到发送流量的尖峰集中在页面请求发出的那一刻。如果你在同一个图表里再加一条接收方向的曲线两条线对比起来就能很直观地看出“发送的小、接收的大”这种典型的读多写少模式。如果我想精确知道发送方向的总字节数最快的方法是Statistics - Capture File Properties上方其实没有按方向统计所以要靠 Conversations。打开 Conversations切换到 TCP 页签找到本机与 93.184.216.34 的那一行A-B 一列就是发送方向的字节总数B-A 是接收方向。这个数字和 Packet Lengths 的分布在细节上可能略有差异但总量是能对上的。5. 常见问题排查与避坑指南5.1 为什么 Wireshark 只显示 520 字节怎么显示完整的 2090 字节这个现象非常典型搜“wireshark 为何只能显示520字节数据”的人一大堆。两种情况最常见第一种是抓包时把快照长度设小了。在 Capture Options 里你可以给每个接口设置 “Limit each packet to” 的字节数比如设置了 520那么任何超过 520 字节的包都只会记录前 520 字节列表里的 Length 列显示为 520后面不管真实长度是 1500 还是 2000通通看不到。解决办法是回到抓包这一步把“Limit each packet to”关掉或改成 65535重新抓一次。第二种是对方设备或交换机的端口镜像本身做了截断。有时候运维在交换机上做镜像时担心镜像流量太大会设置一个 mirror 报文截断长度比如 128 字节或 520 字节。这种情况下就算 Wireshark 设置完整抓包收到的包也是被截过的。解决办法是修改交换机上的镜像配置把截断长度改成不限制或者至少改成大于 MTU 的值。那如果已经有了一份被截断的 pcap 文件还能不能恢复出真实的 2090 字节很遗憾直接看是不行的数据没抓进来就没法从文件里变出来。但有一种例外TCP 场景下如果抓包文件里保存了足够多的连续 TCP 段Wireshark 的“Follow TCP Stream”可以通过重组还原出完整的应用层数据流这跟单包长度统计是两码事。所以遇到这种文件我通常先看看能不能做 TCP 重组而不是死磕包长统计。5.2 Length 列显示 1514但 IP 层只有 1500差在哪这是另一个让人挠头的问题。以太网标准 MTU 是 1500意思是 IP 层最大载荷是 1500 字节但以太网帧头还有 14 字节所以一个完整的不带 VLAN 的帧长度是 14 1500 1514 字节。如果带了 VLAN 标签还要再加 4 字节变成 1518 字节。很多抓包工具还会额外记录 4 字节的 FCS 校验和于是你看到 1522 也不是怪事取决于驱动和抓包工具的设置。所以当你统计发送方向的包长时如果看到一堆 1514 的包说明应用层数据已经撑满了 MTU这是大流量传输的正常表现。如果你看到的是 2090、4054 甚至更大的长度那基本可以断定这个抓包环境里有巨型帧Jumbo Frame或者网卡做了 LRO/GRO 合并这种情况下 IP 层分片逻辑、TCP 校验和计算都会跟标准 MTU 环境不同统计时要注意区分。5.3 同一份抓包Packet Lengths 和 ip.len 统计结果对不上有次我帮同事统计数据包长度分布他用ip.len作为长度字段我用frame.len两个人算出来的平均包长差了 14 字节。其实谁都没错只是统计口径不同。frame.len是帧长包含以太网头ip.len是 IP 总长不包含以太网头。对于不带 VLAN 的标准以太网帧两者之间差一个固定的 14。我的建议是如果是跟对端设备、交换机流量对比尽量用frame.len如果是做 IP 层或传输层性能分析用ip.len或tcp.len。关键是整个统计过程保持口径一致。团队协作时最好在统计结果旁边注明你用的是哪个字段避免后面接手的人误解。5.4 抓包文件很大统计一下卡死怎么办超过 1GB 的 pcap 文件在图形界面里开 Packet Lengths确实有可能会卡顿。我的处理办法是先用tshark做一次裁切把发送方向的包单独导成一个小文件tshark -r big.pcapng -Y ip.src 192.168.1.100 -w send_only.pcapng然后对这个小文件再做图形化统计流畅很多。如果需要按时间切片可以用-Y frame.time \2024-01-01 00:00:00\ frame.time \2024-01-01 00:05:00\来切出一段窗口再统计就不必等图形界面慢慢算。5.5 重传、乱序和分片包会不会影响统计会而且影响比你想象的大。TCP 重传包在 Wireshark 里会被标记为TCP Retransmission这些包的实际数据是对之前某个包的重复发送。如果你的目标是统计“应用层实际发送的有效载荷”那重传包不应该算进去但如果你想统计“这台机器网卡实际发出的字节数”那重传包必须算因为它确实占用了带宽。两者的业务含义不同统计前要想清楚。IP 分片也是类似。一个 3000 字节的 IP 包在以太网上会被分成两个 1500 字节左右的片段Packet Lengths 统计会看到两个接近 1514 的包但如果你用ip.len 3000去过滤则一个都匹配不到因为分片后每个片段的 IP 头里的 Total Length 只是分片自身的长度总长度信息在第一个分片的偏移字段里才能拼出来。因此做包长分布统计时不要指望 ip.len 能精确代表应用层消息大小。6. 我的几个独家心得6.1 先看总体再分方向最后看时间线很多人一上来就直接套过滤条件结果漏掉了关键信息。我的习惯是三步走先打开 Protocol Hierarchy 看整体协议构成和字节量再打开 Conversations 和 Endpoints 看哪些 IP、哪个端口在消耗流量快速锁定方向最后才用 Packet Lengths 和 IO Graphs 深入统计具体长度分布和时间趋势。这套流程在绝大多数网络故障里都够用而且不会因为过早过滤而错过异常报文。6.2 保存一套自己的显示过滤器模板统计发送方向包长这种过滤条件值得存成 Wireshark 的显示过滤器按钮。操作很简单在显示过滤器栏输入ip.src 192.168.1.100点击左侧的“书签”或者“保存”按钮给它起个名字叫“本机发送”。下次抓到新文件点一下这个按钮就自动应用了。办公网环境里本机 IP 可能会变所以我的模板通常写成变量比如ip.src $MYIP通过过滤表达式对话框配置好变量值这样换环境也能直接套用。6.3 统计工具是死的统计口径是活的最后分享一个容易被忽视的经验Wireshark 只是工具它给出的所有统计数字在离开具体场景前都没有绝对意义。同样是“发送数据包长度”在做弱网模拟时你关注的是小包和重传包的占比在做带宽规划时你关注的是总字节数和峰值速率在定位 MTU 分片问题时你关注的是 1500 附近的包有没有被截断。所以我的建议是每次统计前先问自己一个问题——“这个数字算出之后我要拿它做什么决策”想清楚答案统计口径自然就对了。包长大小的统计这活儿熟练之后五分钟就能跑完一轮但真正值钱的不是你点了哪几个菜单而是你看见数字之后能判断出系统状态正不正常。写这篇文章的时候我脑子里一直想的是以前踩过的那些坑被 520 字节快照坑过被 ip.len 和 frame.len 口径不一致坑过也被重传包重复计数坑过。这些坑其实都能用一套清晰的流程绕过去先看总体再分方向再按时间轴细看全程保持统计口径一致。希望这篇能让你少走点弯路下次再遇到“帮我看看这个抓包文件里发了多少数据”的请求你能底气十足地说“十分钟给你一份完整的发送方向包长统计报告。”