尧图网页设计 
简介这是一份面向网络运维、音视频技术支持及Wireshark初学者的实操型PDF教程聚焦如何用Wireshark分析RTP丢包率。资源大小759KB含1个PDF文档页面内容围绕四步排查流程展开先用CtrlF定位rtsp/1.0交互包再从SETUP命令中提取下行端口示例为6072随后按udp.port eq 6072过滤流量最后通过Telephony菜单下的RTP Stream Analysis查看丢包统计全程配有界面截图与字段说明。已有1074人浏览学习适合有一定网络协议基础、希望快速定位VoIP或视频会议卡顿原因的读者。通过这份资料可掌握RTP丢包分析的标准操作路径学会利用Wireshark的统计工具判断网络传输质量并据此优化链路或调整编码参数。整份指南体量精简无需复杂环境跟着示例操作即可完成一次完整的RTP流丢包率验证。1. 用 Wireshark 看 RTP 丢包率先搞清楚统计口径做 VoIP 和视频监控排查的人迟早会被一句“RTP 丢包率高”拉去背锅。实际上 Wireshark 的 RTP 流分析面板给出的“丢包率”并不是简单数一数少了几个包而是基于 RTP 序列号Sequence Number的连续性、SSRC 对应关系、抓包起点和终点综合算出来的。很多人拿着这个数字去投诉线路质量结果发现数据根本不靠谱——因为丢包率这个指标只有在抓包位置、过滤条件、时间基准都对了之后才有意义。这篇笔记就按我平时排障的顺序把 Wireshark 分析 RTP 丢包率的完整链路讲清楚适合刚接触抓包的运维也适合被领导要求“出一个 PDF 报告”的现场工程师。2. 抓包前的三个准备接口、过滤器、时间基准2.1 选对抓包接口别抓成环回口或者镜像口RTP 流量走的是实际网卡或虚拟网卡Wireshark 默认会列出所有可用接口。如果你是在本机调试一个软电话通常选“以太网”或“WLAN”而不是“Loopback: lo”。很多新手在虚拟机里抓包选了 NAT 网卡发现只有 ARP 和 DHCP那是因为 RTP 流根本没经过这块虚拟网卡或者被宿主机直接转发了。常见做法是先在“捕获”菜单里勾选“所有接口”用“统计 - 端点”看看 UDP 流量在哪个接口上出现再回来只抓那一个。如果是在交换机上做镜像口抓包记得确认镜像方向。我遇到过现场把上行口和下行口镜像反了抓回来的包里只有对方发来的 RTP本端发送的包一个都没有最后算出来的丢包率必然是 50%。镜像口抓包时还要注意如果交换机上同时镜像了多个 VLANWireshark 的捕获过滤器最好写“udp port ranging”否则大数据量下 Wireshark 自身丢包会让 RTP 分析结果严重失真。2.2 用显示过滤器锁定一路 RTP 流捕获过滤器负责“少抓”显示过滤器负责“只看”。分析 RTP 丢包率时我习惯先抓到完整的 UDP 流量再用显示过滤器把目标流筛出来。最常用的显示过滤器是rtp udp.port 5004如果你的 RTP 端口不是标准端口比如国标 GB28181 平台经常用 10000 以上的随机端口那就需要先通过 SIP 信令找到媒体端口或者直接过滤 IPrtp ip.addr 192.168.1.10这一步的关键作用是把同一时刻的多路 RTP 流分开。Wireshark 的 RTP 分析功能是按 SSRC 区分流的如果显示过滤器里同时混着两路通话Stream Analysis 面板会列出所有流的统计丢包率数字会被“平均”掉失去排查意义。我一般会先把“rtp”过滤出来然后从“Telephony - RTP - RTP Streams”列表里双击目标流让 Wireshark 自动跳到对应的显示过滤器。2.3 时间显示与参考时间别让时间戳欺骗你Wireshark 默认显示的是抓包时刻的相对时间或者绝对时间而 RTP 协议头部有自己独立的时间戳Timestamp这个时间戳由发送端按采样率递增用于播放同步。分析丢包率时Wireshark 的 Stream Analysis 面板里有两套时间**包到达的墙上时间Delta**和RTP 时间戳差值。看抖动Jitter必须用 RTP 时间戳差值看丢包则依赖序列号。这里有个很实际的坑如果抓包文件里同时包含了多个方向的媒体流Wireshark 计算抖动时会混入方向切换的 Delta 异常。所以在分析前我习惯在“视图 - 时间显示格式”里把时间改成“Seconds Since Previous Captured Packet”这样能直观看到包与包之间的到达间隔。但要注意这只是辅助观察真正算丢包率时Wireshark 只看序列号。3. 在 Wireshark 里算出 RTP 丢包率从菜单到算式3.1 Telephony - RTP - Stream Analysis 怎么看打开抓包文件后先确保显示过滤器里只有目标 RTP 流然后点菜单“电话Telephony- RTP - 流分析Stream Analysis”。Wireshark 会弹出一个表格每一行代表一个 RTP 方向根据 SSRC 和源地址区分。表格里有几个核心列丢包率Lost%、包数Packets、序列号错误Sequence Errors、抖动Jitter。丢包率这一列的计算逻辑是(预期包数 - 实际包数) / 预期包数。预期包数来自序列号范围从第一个包的序列号到最后一个包的序列号按顺序中间应该出现的包数量。所以如果抓包起点不是流的开始比如中途才打开 Wireshark第一个包的序列号不是流的起点Wireshark 会把你抓到的第一个包当作基准丢包率只反映你抓包窗口内的丢包情况而不是整条流的历史丢包率。这是一个非常重要的口径问题。3.2 读懂丢包率、抖动、失序三个数字之间的关系丢包率是“少了包”抖动是“包到得不够均匀”失序是“包到了但顺序不对”。三者经常同时出现。比如无线网络里RTP 包可能走两条路径到达顺序颠倒Wireshark 会把后到的包标记为“Sequence Error”如果乱序严重到超过了接收缓冲区实际效果等同于丢包但面板上的丢包率可能只有 1% 而序列错误有 5%。反过来如果网络里有中间设备做 QoS 整形RTP 包没丢但被缓存后突发到达抖动值会飚红而丢包率是 0%。这时候业务卡顿其实是抖动引起的不是丢包。现场排障时我会先看丢包率再看抖动两者都高基本可以确定是线路问题丢包率低但抖动高优先查设备缓冲和网络拥塞。3.3 手动用序列号算丢包率Excel 也能做Wireshark 的自动统计有时候会因为首包缺失、SSRC 冲突而算错。我习惯在关键排障时手动复核一次。方法是把 RTP 流导出为 CSV用序列号字段做差分。# 导出当前过滤后的 RTP 信息用 tshark 更可控 tshark -r capture.pcapng -Y rtp ip.src192.168.1.10 -T fields \ -e rtp.seq -e frame.time_epoch -e rtp.timestamp rtp_seq.csv然后用 Python 脚本计算序列号间隙import csv seqs [] with open(rtp_seq.csv, r) as f: reader csv.reader(f) for row in reader: seqs.append(int(row[0])) expected seqs[0] lost 0 total 0 for s in seqs: # RTP 序列号是 16 位无符号数注意回绕 if s expected: gap s 65536 - expected else: gap s - expected if gap 0: lost gap expected s 1 total 1 lost_rate lost / (total lost) * 100 print(f实际收到 {total} 包估计丢包 {lost} 包丢包率 {lost_rate:.2f}%)这段脚本的核心逻辑是用前一个包的序列号加 1 作为期望值如果下一个包的序列号比期望值大说明中间少了包如果小说明乱序或重复这种不算丢包。RTP 序列号最大 65535所以有回绕判断。手动算出来的丢包率如果和 Wireshark 面板相差超过 1 个百分点说明自动统计里混入了乱序包或者重复包需要进一步过滤。4. RTP 丢包率分析遇上的 5 个典型坑现象、原因、解决4.1 显示丢包率 0% 但业务卡顿现象Stream Analysis 面板丢包率 0抖动也不高但电话里声音断断续续视频画面花屏。原因丢包不是发生在抓包点而是发生在抓包点之后。比如你在核心交换机镜像口抓包镜像口看到的包是完整的但实际到达终端前被末级设备丢掉了。或者接收端的 jitter buffer 设置太小包虽然到了但超过播放窗口被主动丢弃。解决在终端侧同时抓包和核心侧抓包做对比。如果终端侧丢包率高而核心侧低问题在最后一段链路或终端驱动。如果两侧都 0%就得检查 RTP payload 里是否有 CRC 错误或媒体网关的丢包隐藏算法造成的主观卡顿。这种卡顿不会体现在 RTP 层丢包率上。4.2 显示丢包率高但业务正常现象Wireshark 显示丢包率 15%但通话双方都觉得声音清晰视频也不卡。原因常见于抓包文件里有重复包或乱序包。某些网卡驱动在抓包时会重复递交数据包Wireshark 不会自动去重。另外无线抓包时同一个包可能被 802.11 重传多次Wireshark 的 RTP 分析器把这些重传包当作新包重复包会让期望序列号前进但实际包数不变从而计算出虚高的丢包率。解决用过滤表达式排除重复包或者在“编辑 - 首选项 - Protocols - RTP”里勾选“忽略重复的 RTP 包”。我一般在现场先看“Sequence Errors”列如果错误数远大于丢包数优先考虑乱序和重复而不是真的丢包。4.3 单向抓包导致丢包虚高现象只抓了 A 到 B 的 RTP 流B 到 A 的方向没有抓Stream Analysis 面板里却显示 B 方向 100% 丢包。原因Wireshark 的 RTP Streams 列表会列出所有看到的 SSRC。如果你只抓了单向流量但对端发来的包也经过同一接口只是过滤掉了面板上会显示“仅见请求”或者只有几个包丢包率被算成接近 100%。另一种情况是防火墙做了端口映射RTP 包从 5004 转发到 60000Wireshark 按端口识别流两个端口被当成不同流各自缺了一半。解决使用显示过滤器时不要限定端口而是用 IP SSRC 组合。在 RTP Streams 面板里注意看“只有从 A 到 B”的行不要迷信那个红色的 100% 丢包率。如果确实需要单向分析就在报告里明确写“本抓包仅覆盖 A 到 B 方向丢包率不代表全程”。4.4 无线网络抓包把乱序和重复算成丢包现象在 Wi-Fi 环境下用笔记本抓包丢包率 20%但实际通话质量很好。原因无线网卡抓包时如果开启了 802.11 监听模式会捕获到同一帧的多份副本Control、Data、Retry。Wireshark 会把重传帧识别为重复 RTP 包导致序列号出现“跳变-回退-再跳变”的模式自动分析器容易把这些误判为丢包。另外无线链路的隐藏节点问题会造成实际乱序但应用层已经通过缓存纠正了。解决尽量不要用 Wi-Fi 网卡做 RTP 丢包率分析。如果必须用在捕获过滤器里加“wlan.fc.retry 0”来排除重传帧。同时建议用有线连接或者用 AP 的镜像口抓包。信号弱的环境下Wireshark 显示丢包率往往比真实丢包率高很多这个数字不能直接写进交付报告。4.5 分析期间有包被 Wireshark 自身丢弃现象抓包文件很大几 GB 起步分析时显示“Dropped Packets: 1234”丢包率统计明显异常。原因Wireshark 在高速流量下抓包如果磁盘写入速度跟不上内核缓冲区溢出包根本没被捕获。这种情况尤其在通过 SSH 远程抓包、或者把 pcapng 写到机械硬盘时常见。抓包丢包和网络丢包是两回事但都会影响 RTP 序列号连续性。解决抓包前在“捕获选项”里勾选“使用无限文件大小”并设置环形缓冲区或者直接限制抓包时长避免文件过大。抓完后看 Wireshark 右下角的“捕获”统计如果显示 dropped 非零这份文件不能用来做 RTP 丢包率分析重新抓。也可以用 dumpcap 命令抓包它的丢包统计更准确。5. 用 tshark 把丢包率计算脚本化验证与批量处理最后一章聊一个我个人的习惯GUI 点出来的丢包率只用来“快看”真正要进报告的数字我会用 tshark 重新算一遍。因为 tshark 可以精确控制过滤条件、排除乱序包、批量处理多个 pcapng 文件。下面这个脚本是一个可运行的模板适用于已经抓好的文件。#!/bin/bash # 批量计算 RTP 丢包率输出 CSV 结果 # 用法./rtp_loss.sh capture.pcapng for f in $; do echo -n $f, tshark -r $f -Y rtp ip.src192.168.1.10 -T fields \ -e rtp.ssrc -e rtp.seq -E separator, 2/dev/null \ | awk -F, BEGIN{last-1; lost0; total0} { if (last ! -1) { if ($2 last) { gap $2 65536 - last } else { gap $2 - last } if (gap 0) lost gap } last $2 1; total } END { rate lost/(totallost)*100 printf SSRC%s lost%d total%d rate%.2f%%\n, $1, lost, total, rate } done这个脚本的原理和上一章的手动算法一样只是用 awk 处理。注意两点一是必须按 IP 过滤因为 RTP 流可能同时存在于多个地址之间混在一起会把不同流的序列号穿插起来算法就废了二是tshark -Y的过滤表达式和 GUI 里的显示过滤器语法完全一样建议先在 GUI 里验证过滤结果再丢进脚本跑。如果要结合 RTCP 做交叉验证可以在同一个抓包里过滤 RTCP 的 Sender Report 包里面有累计丢包计数和期望包数字段是rtcp.sender.packet_count和rtcp.sender.lost。这是接收端主动反馈的丢包数据和 Wireshark 从序列号推出来的是两条独立证据链。只有当两者都指向同一量级时我才会把丢包率写进给客户的 PDF 报告里。单独一个数字很容易被质疑两个独立来源互相印证排障结论才站得住。最后说一句我的习惯每次出 RTP 丢包率报告我都会在页脚写明抓包点、抓包时长、过滤条件、是否有 dropped packets。“丢包率 3%”这句话本身没有意义加上这些上下文才算一个可追溯的结论。希望帮到你。本文还有配套的精品资源点击获取 Wireshark RTP丢包率分析：统计口径、排障实践与脚本化
简介这是一份面向网络运维、音视频技术支持及Wireshark初学者的实操型PDF教程聚焦如何用Wireshark分析RTP丢包率。资源大小759KB含1个PDF文档页面内容围绕四步排查流程展开先用CtrlF定位rtsp/1.0交互包再从SETUP命令中提取下行端口示例为6072随后按udp.port eq 6072过滤流量最后通过Telephony菜单下的RTP Stream Analysis查看丢包统计全程配有界面截图与字段说明。已有1074人浏览学习适合有一定网络协议基础、希望快速定位VoIP或视频会议卡顿原因的读者。通过这份资料可掌握RTP丢包分析的标准操作路径学会利用Wireshark的统计工具判断网络传输质量并据此优化链路或调整编码参数。整份指南体量精简无需复杂环境跟着示例操作即可完成一次完整的RTP流丢包率验证。1. 用 Wireshark 看 RTP 丢包率先搞清楚统计口径做 VoIP 和视频监控排查的人迟早会被一句“RTP 丢包率高”拉去背锅。实际上 Wireshark 的 RTP 流分析面板给出的“丢包率”并不是简单数一数少了几个包而是基于 RTP 序列号Sequence Number的连续性、SSRC 对应关系、抓包起点和终点综合算出来的。很多人拿着这个数字去投诉线路质量结果发现数据根本不靠谱——因为丢包率这个指标只有在抓包位置、过滤条件、时间基准都对了之后才有意义。这篇笔记就按我平时排障的顺序把 Wireshark 分析 RTP 丢包率的完整链路讲清楚适合刚接触抓包的运维也适合被领导要求“出一个 PDF 报告”的现场工程师。2. 抓包前的三个准备接口、过滤器、时间基准2.1 选对抓包接口别抓成环回口或者镜像口RTP 流量走的是实际网卡或虚拟网卡Wireshark 默认会列出所有可用接口。如果你是在本机调试一个软电话通常选“以太网”或“WLAN”而不是“Loopback: lo”。很多新手在虚拟机里抓包选了 NAT 网卡发现只有 ARP 和 DHCP那是因为 RTP 流根本没经过这块虚拟网卡或者被宿主机直接转发了。常见做法是先在“捕获”菜单里勾选“所有接口”用“统计 - 端点”看看 UDP 流量在哪个接口上出现再回来只抓那一个。如果是在交换机上做镜像口抓包记得确认镜像方向。我遇到过现场把上行口和下行口镜像反了抓回来的包里只有对方发来的 RTP本端发送的包一个都没有最后算出来的丢包率必然是 50%。镜像口抓包时还要注意如果交换机上同时镜像了多个 VLANWireshark 的捕获过滤器最好写“udp port ranging”否则大数据量下 Wireshark 自身丢包会让 RTP 分析结果严重失真。2.2 用显示过滤器锁定一路 RTP 流捕获过滤器负责“少抓”显示过滤器负责“只看”。分析 RTP 丢包率时我习惯先抓到完整的 UDP 流量再用显示过滤器把目标流筛出来。最常用的显示过滤器是rtp udp.port 5004如果你的 RTP 端口不是标准端口比如国标 GB28181 平台经常用 10000 以上的随机端口那就需要先通过 SIP 信令找到媒体端口或者直接过滤 IPrtp ip.addr 192.168.1.10这一步的关键作用是把同一时刻的多路 RTP 流分开。Wireshark 的 RTP 分析功能是按 SSRC 区分流的如果显示过滤器里同时混着两路通话Stream Analysis 面板会列出所有流的统计丢包率数字会被“平均”掉失去排查意义。我一般会先把“rtp”过滤出来然后从“Telephony - RTP - RTP Streams”列表里双击目标流让 Wireshark 自动跳到对应的显示过滤器。2.3 时间显示与参考时间别让时间戳欺骗你Wireshark 默认显示的是抓包时刻的相对时间或者绝对时间而 RTP 协议头部有自己独立的时间戳Timestamp这个时间戳由发送端按采样率递增用于播放同步。分析丢包率时Wireshark 的 Stream Analysis 面板里有两套时间**包到达的墙上时间Delta**和RTP 时间戳差值。看抖动Jitter必须用 RTP 时间戳差值看丢包则依赖序列号。这里有个很实际的坑如果抓包文件里同时包含了多个方向的媒体流Wireshark 计算抖动时会混入方向切换的 Delta 异常。所以在分析前我习惯在“视图 - 时间显示格式”里把时间改成“Seconds Since Previous Captured Packet”这样能直观看到包与包之间的到达间隔。但要注意这只是辅助观察真正算丢包率时Wireshark 只看序列号。3. 在 Wireshark 里算出 RTP 丢包率从菜单到算式3.1 Telephony - RTP - Stream Analysis 怎么看打开抓包文件后先确保显示过滤器里只有目标 RTP 流然后点菜单“电话Telephony- RTP - 流分析Stream Analysis”。Wireshark 会弹出一个表格每一行代表一个 RTP 方向根据 SSRC 和源地址区分。表格里有几个核心列丢包率Lost%、包数Packets、序列号错误Sequence Errors、抖动Jitter。丢包率这一列的计算逻辑是(预期包数 - 实际包数) / 预期包数。预期包数来自序列号范围从第一个包的序列号到最后一个包的序列号按顺序中间应该出现的包数量。所以如果抓包起点不是流的开始比如中途才打开 Wireshark第一个包的序列号不是流的起点Wireshark 会把你抓到的第一个包当作基准丢包率只反映你抓包窗口内的丢包情况而不是整条流的历史丢包率。这是一个非常重要的口径问题。3.2 读懂丢包率、抖动、失序三个数字之间的关系丢包率是“少了包”抖动是“包到得不够均匀”失序是“包到了但顺序不对”。三者经常同时出现。比如无线网络里RTP 包可能走两条路径到达顺序颠倒Wireshark 会把后到的包标记为“Sequence Error”如果乱序严重到超过了接收缓冲区实际效果等同于丢包但面板上的丢包率可能只有 1% 而序列错误有 5%。反过来如果网络里有中间设备做 QoS 整形RTP 包没丢但被缓存后突发到达抖动值会飚红而丢包率是 0%。这时候业务卡顿其实是抖动引起的不是丢包。现场排障时我会先看丢包率再看抖动两者都高基本可以确定是线路问题丢包率低但抖动高优先查设备缓冲和网络拥塞。3.3 手动用序列号算丢包率Excel 也能做Wireshark 的自动统计有时候会因为首包缺失、SSRC 冲突而算错。我习惯在关键排障时手动复核一次。方法是把 RTP 流导出为 CSV用序列号字段做差分。# 导出当前过滤后的 RTP 信息用 tshark 更可控 tshark -r capture.pcapng -Y rtp ip.src192.168.1.10 -T fields \ -e rtp.seq -e frame.time_epoch -e rtp.timestamp rtp_seq.csv然后用 Python 脚本计算序列号间隙import csv seqs [] with open(rtp_seq.csv, r) as f: reader csv.reader(f) for row in reader: seqs.append(int(row[0])) expected seqs[0] lost 0 total 0 for s in seqs: # RTP 序列号是 16 位无符号数注意回绕 if s expected: gap s 65536 - expected else: gap s - expected if gap 0: lost gap expected s 1 total 1 lost_rate lost / (total lost) * 100 print(f实际收到 {total} 包估计丢包 {lost} 包丢包率 {lost_rate:.2f}%)这段脚本的核心逻辑是用前一个包的序列号加 1 作为期望值如果下一个包的序列号比期望值大说明中间少了包如果小说明乱序或重复这种不算丢包。RTP 序列号最大 65535所以有回绕判断。手动算出来的丢包率如果和 Wireshark 面板相差超过 1 个百分点说明自动统计里混入了乱序包或者重复包需要进一步过滤。4. RTP 丢包率分析遇上的 5 个典型坑现象、原因、解决4.1 显示丢包率 0% 但业务卡顿现象Stream Analysis 面板丢包率 0抖动也不高但电话里声音断断续续视频画面花屏。原因丢包不是发生在抓包点而是发生在抓包点之后。比如你在核心交换机镜像口抓包镜像口看到的包是完整的但实际到达终端前被末级设备丢掉了。或者接收端的 jitter buffer 设置太小包虽然到了但超过播放窗口被主动丢弃。解决在终端侧同时抓包和核心侧抓包做对比。如果终端侧丢包率高而核心侧低问题在最后一段链路或终端驱动。如果两侧都 0%就得检查 RTP payload 里是否有 CRC 错误或媒体网关的丢包隐藏算法造成的主观卡顿。这种卡顿不会体现在 RTP 层丢包率上。4.2 显示丢包率高但业务正常现象Wireshark 显示丢包率 15%但通话双方都觉得声音清晰视频也不卡。原因常见于抓包文件里有重复包或乱序包。某些网卡驱动在抓包时会重复递交数据包Wireshark 不会自动去重。另外无线抓包时同一个包可能被 802.11 重传多次Wireshark 的 RTP 分析器把这些重传包当作新包重复包会让期望序列号前进但实际包数不变从而计算出虚高的丢包率。解决用过滤表达式排除重复包或者在“编辑 - 首选项 - Protocols - RTP”里勾选“忽略重复的 RTP 包”。我一般在现场先看“Sequence Errors”列如果错误数远大于丢包数优先考虑乱序和重复而不是真的丢包。4.3 单向抓包导致丢包虚高现象只抓了 A 到 B 的 RTP 流B 到 A 的方向没有抓Stream Analysis 面板里却显示 B 方向 100% 丢包。原因Wireshark 的 RTP Streams 列表会列出所有看到的 SSRC。如果你只抓了单向流量但对端发来的包也经过同一接口只是过滤掉了面板上会显示“仅见请求”或者只有几个包丢包率被算成接近 100%。另一种情况是防火墙做了端口映射RTP 包从 5004 转发到 60000Wireshark 按端口识别流两个端口被当成不同流各自缺了一半。解决使用显示过滤器时不要限定端口而是用 IP SSRC 组合。在 RTP Streams 面板里注意看“只有从 A 到 B”的行不要迷信那个红色的 100% 丢包率。如果确实需要单向分析就在报告里明确写“本抓包仅覆盖 A 到 B 方向丢包率不代表全程”。4.4 无线网络抓包把乱序和重复算成丢包现象在 Wi-Fi 环境下用笔记本抓包丢包率 20%但实际通话质量很好。原因无线网卡抓包时如果开启了 802.11 监听模式会捕获到同一帧的多份副本Control、Data、Retry。Wireshark 会把重传帧识别为重复 RTP 包导致序列号出现“跳变-回退-再跳变”的模式自动分析器容易把这些误判为丢包。另外无线链路的隐藏节点问题会造成实际乱序但应用层已经通过缓存纠正了。解决尽量不要用 Wi-Fi 网卡做 RTP 丢包率分析。如果必须用在捕获过滤器里加“wlan.fc.retry 0”来排除重传帧。同时建议用有线连接或者用 AP 的镜像口抓包。信号弱的环境下Wireshark 显示丢包率往往比真实丢包率高很多这个数字不能直接写进交付报告。4.5 分析期间有包被 Wireshark 自身丢弃现象抓包文件很大几 GB 起步分析时显示“Dropped Packets: 1234”丢包率统计明显异常。原因Wireshark 在高速流量下抓包如果磁盘写入速度跟不上内核缓冲区溢出包根本没被捕获。这种情况尤其在通过 SSH 远程抓包、或者把 pcapng 写到机械硬盘时常见。抓包丢包和网络丢包是两回事但都会影响 RTP 序列号连续性。解决抓包前在“捕获选项”里勾选“使用无限文件大小”并设置环形缓冲区或者直接限制抓包时长避免文件过大。抓完后看 Wireshark 右下角的“捕获”统计如果显示 dropped 非零这份文件不能用来做 RTP 丢包率分析重新抓。也可以用 dumpcap 命令抓包它的丢包统计更准确。5. 用 tshark 把丢包率计算脚本化验证与批量处理最后一章聊一个我个人的习惯GUI 点出来的丢包率只用来“快看”真正要进报告的数字我会用 tshark 重新算一遍。因为 tshark 可以精确控制过滤条件、排除乱序包、批量处理多个 pcapng 文件。下面这个脚本是一个可运行的模板适用于已经抓好的文件。#!/bin/bash # 批量计算 RTP 丢包率输出 CSV 结果 # 用法./rtp_loss.sh capture.pcapng for f in $; do echo -n $f, tshark -r $f -Y rtp ip.src192.168.1.10 -T fields \ -e rtp.ssrc -e rtp.seq -E separator, 2/dev/null \ | awk -F, BEGIN{last-1; lost0; total0} { if (last ! -1) { if ($2 last) { gap $2 65536 - last } else { gap $2 - last } if (gap 0) lost gap } last $2 1; total } END { rate lost/(totallost)*100 printf SSRC%s lost%d total%d rate%.2f%%\n, $1, lost, total, rate } done这个脚本的原理和上一章的手动算法一样只是用 awk 处理。注意两点一是必须按 IP 过滤因为 RTP 流可能同时存在于多个地址之间混在一起会把不同流的序列号穿插起来算法就废了二是tshark -Y的过滤表达式和 GUI 里的显示过滤器语法完全一样建议先在 GUI 里验证过滤结果再丢进脚本跑。如果要结合 RTCP 做交叉验证可以在同一个抓包里过滤 RTCP 的 Sender Report 包里面有累计丢包计数和期望包数字段是rtcp.sender.packet_count和rtcp.sender.lost。这是接收端主动反馈的丢包数据和 Wireshark 从序列号推出来的是两条独立证据链。只有当两者都指向同一量级时我才会把丢包率写进给客户的 PDF 报告里。单独一个数字很容易被质疑两个独立来源互相印证排障结论才站得住。最后说一句我的习惯每次出 RTP 丢包率报告我都会在页脚写明抓包点、抓包时长、过滤条件、是否有 dropped packets。“丢包率 3%”这句话本身没有意义加上这些上下文才算一个可追溯的结论。希望帮到你。本文还有配套的精品资源点击获取