简介面向网络工程师、音视频运维人员与协议分析初学者这份资料以Wireshark实操为主线解决RTP实时传输中丢包率的定位与判读问题。内容从打开抓包文件、查找RTSP/1.0信令入手逐步演示通过SETUP命令提取下行UDP端口再以udp.port过滤锁定目标RTP流最终在Telephony菜单的Stream Analysis中查看丢包统计与质量参数。全程图文对照、步骤清晰适合需要快速上手RTP排查的读者。包体为单个PDF文档容量约759KB便于本地查阅或打印随用。目前已有1074人学习被不少网络排障场景作为速查参考。通过阅读可掌握RTP流过滤、丢包率分析及质量评估的完整思路并能举一反三应用于VoIP、视频会议等实时传输环境的性能优化。1. Wireshark 分析 RTP 丢包率从抓包到结论的完整思路做音视频传输、VoIP 网关或者安防平台对接的同行应该都有过这种时刻对方说画面卡顿、声音断续抓了包却不知道从哪看起。RTP 丢包率这个指标很多人第一反应是去数 UDP 包数量数了半天对不上号。实际上Wireshark 里有一套标准的分析路径核心思路是先用 RTSP 协商出的端口号把目标数据流从海量报文中隔离出来再用自带的 RTP Stream Analysis 功能直接算出丢包率。整个过程不需要写脚本也不用第三方插件四步就能走到结论。这篇笔记就是把这四步拆开来讲顺带把我在实际项目里踩过的几个坑一并交代清楚适合刚接触 RTP 排查的新手也适合想确认自己操作姿势是否标准的熟手。2. 先拿到 RTP 流的真实端口RTSP 协商与 udp.port 过滤2.1 RTSP SETUP 包里的端口玄机RTP 的端口不是固定的这一点是很多新手第一次翻车的地方。视频会议、安防摄像头、流媒体服务器在建立会话时会通过 RTSP 协议动态协商传输端口。也就是说这一次通话用的端口可能是 6072下一次就变成了 8004靠猜或者靠记是不现实的。正确做法是回看 RTSP 握手阶段的 SETUP 包从里面的 transport 字段拿到服务端实际分配的下行端口。打开抓到的网络包后按下 CtrlF 呼出查找栏查找方式选字符串范围选报文字节然后在输入框里填 rtsp/1.0一路点查找直到定位到发送 SETUP 命令的报文。我这里实际的抓包里SETUP 包通常长这样Transport: RTP/AVP/UDP;unicast;client_port6070-6071;server_port6072-6073这个字段的意思要拆开看。client_port 是客户端声明要使用的端口对server_port 是服务端实际分配的端口对。每路 RTP 会话会占两个连续的 UDP 端口偶数是 RTP 数据端口奇数是对应的 RTCP 控制端口。上面这个例子里6072 就是服务端发给客户端的下行 RTP 数据端口6073 是这条流的 RTCP 端口。这里有一个细节容易被忽略SETUP 包可能有多个。RTSP 会话里视频和音频会各发一次 SETUP也就是说你会看到两个 SETUP 包、两组端口。你按下 CtrlF 找到的第一个 SETUP 包不一定是你要分析的那一路媒体得把两个 SETUP 都找出来确认哪一组端口对应的是视频流、哪一组对应音频流。区分方法很简单继续往下翻报文找到 SDP 描述里 media 行的内容媒体类型和端口是直接对应的。2.2 用 udp.port 把无关流量隔离掉拿到端口号 6072 之后接下来就是把这条流从整个抓包里剥离出来。在 Wireshark 顶部的过滤栏里输入udp.port eq 6072按下回车显示区就只剩跟端口 6072 相关的报文了。这个过滤器的逻辑是只要报文源端口或目的端口等于 6072就显示出来。RTP 是承载在 UDP 之上的所以用 udp.port 而不是 tcp.port这一点很关键。参数说明这里的 6072 是服务端分配的 server_port也就是下行 RTP 数据端口。如果你的抓包场景是客户端侧那么发出的 RTP 包源端口是 6072如果是服务端侧目的端口是 6072。不管方向如何udp.port 都能命中。对比一下如果写成 udp.dstport eq 6072那只会过滤出目的端口为 6072 的下行报文上行报文就被滤掉了。我这里建议用 udp.port 而不是 udp.srcport 或者 udp.dstport原因就是我们要分析的是整条流方向无关的匹配最省事。过滤完之后观察列表里报文的 Info 列如果出现 RTP 字样说明过滤生效了。如果看到 RTCP 也不奇怪刚才提到 6073 是 RTCP 端口而某些场景下 RTCP 的源端口或目的端口会恰好和 RTP 交织在一起。这种情况不是错误后面分析时会单独说明。2.3 端口猜错了怎么办反向验证的三种手段如果你照着上面的步骤过滤完发现列表里一个 RTP 包都没有大概率是端口找错了。这时候不要急着怀疑 Wireshark先做几个反向验证。第一种手段回到 SDP 描述里确认媒体端口。找 SIP INVITE 或者 RTSP DESCRIBE 响应里的 SDP 体找到类似这样的行mvideo 6072 RTP/AVP 96m 行里紧跟媒体类型后面的数字就是这一路媒体实际使用的 RTP 端口。如果这个数字和你从 transport 字段里读到的 server_port 不一致以 SDP 里的为准。第二种手段直接在抓包里挑一个看起来像 RTP 的 UDP 包双击点开看传输层协议头里的源端口和目的端口再把同一会话方向上的连续报文做对比。RTP 包的 UDP 载荷开头是固定格式的 RTP 头前两个字节里有版本号通常是 10和负载类型PT 值一眼就能认出来。第三种手段用统计功能辅助确认。进入 Statistics 菜单下的 Flow Graph按会话维度把 UDP 端口对列出来端口对之间的报文数量往往能反映出哪一对是真正的媒体流。媒体流的报文数量通常远大于其他会话这个特征在抓包文件里非常明显。三种手段我都用过实际项目中 SDP 验证是命中率最高的因为 SDP 是媒体协商的最终结果transport 字段偶尔会因为代理服务器改写而出现偏差。养成先看 SDP、再对 transport、最后抽查报文的习惯端口这个基础就稳了。3. 丢包率到底看哪个数RTP Stream Analysis 的指标拆解与判定3.1 RTP Stream Analysis 的正确打开方式端口过滤只完成了数据隔离真正的丢包分析要交给 Wireshark 的流分析功能。菜单路径在顶部栏的 Telephony 菜单下依次进入 Telephony - RTP - Stream Analysis点击后 Wireshark 会对当前过滤结果里的所有 RTP 流逐个做统计。注意这里统计的对象是当前过滤栏里显示的数据不是整个抓包文件。所以前面没做 udp.port 过滤就直接点进来你会得到一个包含十几条甚至几十条流的列表每条流都要人工去认效率很低。点击后界面会弹出一个带进度条的分析窗口包量大的时候进度条会走一阵子。这一步偶尔会遇到进度条卡死或者窗口长时间无响应的情况原因通常是过滤条件太宽、RTP 包数量过大。我在处理一个小时的抓包文件时碰到过一次后来把过滤条件里加上 IP 地址把范围收窄到一对会话分析窗口就顺畅多了。分析完成后窗口里会列出所有 RTP 流的统计信息每行代表一条流。关键字段有 Start Time、Duration、SSRC、Lost Packets、Max Sequence 等等。这里最重要的一列是 Lost Packets它直接告诉你这条流丢了多少个包。丢包率不是直接显示的需要自己算一下用 Lost Packets 除以收到的总包数再乘上 100% 就得到丢包率。3.2 丢包率是怎么算出来的序列号缺口与 RTP 序号原理要理解丢包率的计算逻辑先得知道 Wireshark 判断丢包的依据是 RTP 头里的序列号字段。RTP 序列号是一个 16 位的递增计数器每发送一个 RTP 包就加一。如果网络没有丢包接收端看到的序列号应该是连续的比如 100、101、102、103。如果中间跳过了几个值比如 100、101、104说明 102 和 103 在传输过程中丢了Wireshark 就把这种序列号缺口算作丢包。Stream Analysis 窗口里每条流后面会显示 Max Sequence当前流里出现的最大序列号和 Lost Packets丢包数量。这里的丢包数实际上是根据序列号跳变次数和跳变幅度推算出来的。举个例子如果流里出现了从 5000 直接跳到 5010 的情况中间缺失的 10 个序列号就会被计入丢包不管这 10 个包是真的丢了、还是乱序后还没到、还是被网络中间的某个设备缓存了。这也引出了一个重要边界Wireshark 算出的丢包率是接收端视角的序列号缺失率不完全是实际网络丢包率。两者在大部分场景下等价但在有乱序、重传、前向纠错的网络里会出现偏差。判断的时候要看另一个字段 Reversed逆序包数量如果这个值很高说明乱序严重丢包数可能被高估。3.3 抖动、迟到与时间戳三个容易被混在一起的指标除了丢包数Stream Analysis 窗口里还有一列值得关注Jitter抖动。它的单位是毫秒反映的是包到达间隔的波动程度。RTP 头里有一个时间戳字段标记的是媒体采样时刻和序列号是两套独立计数器。时间戳决定的是播放时机序列号决定的是包顺序所以会出现序列号连续但时间戳跳变的情况。典型的翻车场景视频通话里画面在动但声音一切正常这时候丢包数显示为 0可 Jitter 值高得离谱。原因是网络里某个环节引入了不均匀的延迟部分包晚到了几十毫秒但最终都到了所以序列号没有缺口。处理这类问题光看丢包率是不够的要把 Jitter 和 Delta包间隔一起看。Delta 是相邻 RTP 包之间的实际到达时间差正常情况下非常稳定如果 Delta 出现周期性的大幅波动即使丢包数为 0链路质量也不能算健康。另外提醒一点时间戳字段可能发生回绕。RTP 时间戳是 32 位无符号数到最大值后会归零重新累加。抓包时间超过一定长度后可能撞上回绕点此时 Jitter 的计算会出现瞬间异常值这种属于计算假象不要把它当成网络故障。判定的经验是如果 Jitter 异常值只出现在某一瞬间、前后都恢复正常而且丢包数和序列号都正常那多半是回绕导致的统计毛刺可以忽略。4. RTP 丢包分析避坑指南五个常见翻车现场与修复方法4.1 过滤 udp.port 后一个包都看不到现象按照 SETUP 包里的 server_port 填了 udp.port eq 6072回车后列表为空一个报文都不显示。原因最常见的情况是这条流根本不是用 UDP 传的。RTSP 协议支持 RTP over TCP 的模式也就是把 RTP 包塞进 TCP 连接里传输这种模式下没有独立的 UDP 端口udp.port 过滤器自然什么都匹配不到。解决检查 SETUP 包的 transport 字段如果里面写的是 RTP/AVP/TCP 而不是 RTP/AVP/UDP就说明走的是 TCP 传输。此时过滤器要改成 tcp.port eq 6072或者更直接一点用 rtsp 过滤器把整个 TCP 会话都拉出来在报文详情里展开 RTP 层数据看丢包情况。TCP 承载模式下 Wireshark 也能识别 RTP只是 Stream Analysis 的入口略有不同要先右键 RTP 报文选择解码为 RTP再进统计。4.2 丢包率显示 30% 但画面基本正常现象Stream Analysis 里某条流丢包率算出来接近 30%但实际播放器画面只是偶发卡顿没有到不可用的程度。原因我排查过一个实际案例起初也以为是网络问题后来发现统计里混入了 RTCP 包。RTCP 和 RTP 共享相邻端口过滤器 udp.port eq 6072 只会命中 6072 这一个端口但如果抓包文件里出现了端口镜像或者端口复用的情况RTCP 包也会被算进来。另外还有一种常见情况视频流启用了前向纠错FEC冗余包和原始包用同一个 SSRC 发送序列号缺了但冗余包能补上播放器实际没丢统计上却算丢了。解决回到 Stream Analysis 窗口双击这条流在打开的 RTP 流详情里逐包查看负载类型 PT 值。RTP 数据包的 PT 值通常是 96-127 之间的动态值RTCP 包在 RTP 详情里则表现为包长明显偏短且没有媒体载荷。确认混入的是 RTCP 后把过滤器改成 udp.srcport eq 6072 || udp.dstport eq 6072 !rtcp或者直接在过滤栏输入 rtp 来只保留 RTP 报文再重新分析。对于 FEC 场景需要了解协议本身具备纠错能力序列号缺失不代表媒体数据丢失。4.3 Stream Analysis 列了几十条流不知道看哪条现象点击 Telephony - RTP - Stream Analysis 后弹出的窗口里有几十行流记录SSRC 各不相同不知道该选哪一行。原因没有在过滤栏里先做端口过滤导致 Wireshark 对抓包里所有能被识别为 RTP 的流都做了统计。公网抓包场景下同一条链路上可能混着好几路并发通话SSRC 数量自然就多。解决关掉分析窗口回到主界面先在过滤栏里把范围收窄到目标 IP 对和端口对比如 udp.port eq 6072 ip.addr eq 192.168.1.100再重新打开 Stream Analysis。如果还是想从全量列表里挑就按 Lost Packets 字段排序丢包数最大的通常是问题流。选中一行后点击下方的统计或右键选择 RTP 流分析即可进入单条流的详细视图。4.4 序列号跳了 300 却显示 0% 丢包现象手动查 RTP 包时发现序列号从 8020 直接跳到了 8320但 Stream Analysis 显示丢包率为 0。原因序列号跳变只代表有包没被这个抓包点收到不代表包在网络里丢了。我遇到过镜像口抓包的场景交换机镜像口带宽比源口小丢包发生在抓包器入口处而不是业务链路。还有一种情况是 VoIP 网关做了媒体转发网关把收到的 RTP 重新封装后再发给终端序列号是网关自己生成的终端侧看到的是正常序列抓包器抓到的却是网关注入的流两种流混在一起就会出现跳变但不计入丢包的现象。解决先确认抓包点的位置。如果是镜像口抓包看一下 Wireshark 左下角的捕获统计是不是有大量received和displayed的数据差异。再检查包是不是来自同一个 SSRC如果序列号跳变处的前后报文 SSRC 不同说明不是同一条流跳变无意义。最后用时间维度验证如果跳变发生在某一个时间点之后且之后所有包都是新序列号更像是一次媒体重协商而不是丢包。4.5 交换机镜像口带宽溢出导致统计虚高现象同一路视频流在服务器侧抓包丢包率为 0.5%在交换机镜像口抓包显示丢包率 15%两边结论对不上。原因交换机镜像口通常只能承载一个或几个端口的流量总和如果被镜像的源口不止一个或者源口带宽接近饱和镜像口本身就会丢包。抓包器上看到的是抓包丢包不是网络丢包。这类问题最容易引发误判尤其是给客户出报告的时候拿镜像口的数据去证明网络不行会被对方用服务器侧数据直接怼回来。解决判断方法有两个。一是看 Wireshark 状态栏的丢包统计抓包工具自身丢包时会有明显的警告提示二是同时抓服务器侧和镜像口两侧的数据做对比如果两边丢包率差异悬殊优先相信靠近业务端的那一侧。在交换机配置时尽量减少被镜像的端口数量一个源口对一个镜像口是最稳的配置。从那以后我每次出 RTP 丢包分析报告之前都会先看一眼抓包入口的统计信息确认抓包本身没有问题再下结论希望帮到你。5. 把 RTP 丢包检查做成固定动作保存过滤器与 tshark 复核5.1 保存过滤器避免每次重新输入udp.port eq 6072 这样的过滤器平时排查还好一旦遇到多路并发流、多个端口对反复输入容易敲错。Wireshark 的过滤栏左侧有书签图标点开后可以保存当前过滤器并命名。我习惯按场景存几个固定组合# 常见组合一指定端口 指定主机 udp.port eq 6072 ip.addr eq 192.168.1.100 # 常见组合二只看 RTP 应用层 rtp ip.addr eq 192.168.1.100 # 常见组合三排除 RTCP 干扰后分析 udp.port eq 6072 !rtcp第一行组合用于单个摄像头推流场景把端口和 IP 双重限定避免同网段其他设备干扰。第二行直接过滤 RTP 协议层只要 Wireshark 能识别出 RTP 头的包都会显示适合不确定端口时使用。第三行用于前面第 4.2 节提到的情况把 RTCP 排除掉再做流分析。保存方法输入过滤器表达式确认正确后点过滤栏左侧的星号给过滤器起个名字下次从下拉列表直接选。这个操作能省不少时间也避免手误漏掉字符。5.2 用 tshark 做命令行复核图形界面适合做深度分析但如果你要一口气查几十个抓包文件或者想把丢包率写进批量报告Wireshark 的图形界面就太慢了。tshark 是 Wireshark 自带的命令行工具安装 Wireshark 时通常一并装好。进入抓包文件所在目录执行tshark -r capture.pcap -Y rtp.ssrc 0x3a1f2b4c -T fields -e rtp.seq seq.txt参数说明-r 指定要读取的抓包文件-Y 后面跟显示过滤器表达式这里用 SSRC 定位到具体某一条 RTP 流避免并行流的干扰。-T fields 表示以字段形式输出-e rtp.seq 提取每个 RTP 包的序列号最后重定向到文本文件。拿到序列号列表之后用一个小脚本检查是否有缺口或者在命令行里直接数行数和最大值做减法。复核的做法是把图形界面的分析结果和命令行计算结果交叉验证一次。我从项目里总结的验证顺序是先在图形界面上看 Stream Analysis 的丢包数再用 tshark 把序列号导出来自己数一遍两个数字能对上才敢把结论写进故障报告。这套习惯帮我挡掉过不少自己先翻车的情况特别是 4.2 和 4.4 里说的那两种假丢包光看图形界面真的容易误判。从那以后我每次分析完 RTP 丢包率都用 tshark 复核一遍序列号缺口再回头对照 Stream Analysis 的统计确认一致后才视为有效结论希望帮到你。本文还有配套的精品资源点击获取