简介：这是一份面向网络运维、音视频技术支持及Wireshark初学者的实操型PDF教程，聚焦如何用Wireshark分析RTP丢包率。资源大小759KB，含1个PDF文档，页面内容围绕四步排查流程展开：先用Ctrl+F定位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%。镜像口抓包时还要注意：如果交换机上同时镜像了多个 VLAN，Wireshark 的捕获过滤器最好写“udp port ranging”，否则大数据量下 Wireshark 自身丢包，会让 RTP 分析结果严重失真。
2.2 用显示过滤器锁定一路 RTP 流
捕获过滤器负责“少抓”，显示过滤器负责“只看”。分析 RTP 丢包率时，我习惯先抓到完整的 UDP 流量，再用显示过滤器把目标流筛出来。最常用的显示过滤器是：
rtp && udp.port == 5004如果你的 RTP 端口不是标准端口，比如国标 GB28181 平台经常用 10000 以上的随机端口，那就需要先通过 SIP 信令找到媒体端口，或者直接过滤 IP：
rtp && 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.src==192.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 转发到 60000，Wireshark 按端口识别流，两个端口被当成不同流，各自缺了一半。
解决：使用显示过滤器时不要限定端口，而是用 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.src==192.168.1.10" -T fields \ -e rtp.ssrc -e rtp.seq -E separator=, 2>/dev/null \ | awk -F, 'BEGIN{last=-1; lost=0; total=0} { 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/(total+lost)*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%”这句话本身没有意义，加上这些上下文才算一个可追溯的结论。希望帮到你。
本文还有配套的精品资源，点击获取
