音视频的传输根据场景不同，会涉及到很多的协议：如H.323、SIP等信令协议，如RTSP、RTMP等流控制协议、RTP、RTCP等流传输协议等等，另外音视频还涉及H.264、H.265、ACC等编码协议，所以第一次接触时很容易混淆，分析更无从下手。今天我们先捋清它们的关系，再以最常见的RTP协议为代表介绍多媒体流的分析，了解应该怎么从流量侧对实时多媒体类业务进行运维保障。
一、 什么是多媒体数据流
视频数据流和音频数据流统称为多媒体数据流，以视频举例：
视频常常可由多路信号合成，以每一路信号分辨率720×1280（常说的 720P，单位为像素）为例。每个像素包含RGB数据（红绿蓝分别为8位，即1像素包含3*8=24b的数据）。视频播放帧率为 30 fps（1秒钟播放30幅静态画面）。则对应的码率（单位为bps）为：
720 * 1280 * 3 * 8 * 30 = 632.8125 Mbps (宽 * 高 * 像素字节数 * 字节比特数 * 帧数)。
一分钟的单路720p视频包含的数据量为：632.8125 Mbps * 60s = 4.63 GB。
可见视频的数据量很大，高清视频需要很高的存储或传输成本，因此视频的传输需要采用编码压缩技术以减少码率。而具体到视频编码时，又可以对视频的冗余信息进行压缩（时间、空间冗余等），因此有了很多不同的视频编码格式，如：
ISO-MPEG/ITUT系列的：H.264、H.265、H.266；
AOM系列的：VP8、VP9、AV1；
AVS系列：AVS2、AVS3；
采用不同的编码，播放端就需要用不同的方式解编码（CSNAS专家版带有自动还原媒体流的功能，需配置编码方式才能识别还原，后文中会有介绍）。
好了，编码部分简单介绍到这里，主要让大家知晓：视频和音频为了提升传输效率，需要编码，并且有多种编码格式。严格说它们并不是网络协议（如果故障是编解码原因造成的播放不正常，从流量是看不到异常的），因此不是本文讲解的重点。
编码后的音视频文件，在底层全部变成一堆2进制数，所以我们把它形象地称为多媒体数据流（音频流和视频流）。
二、 多媒体流的传输
多媒体流生成后面临的问题是，能否用TCP或UDP直接传输流给对面呢？
TCP是可靠传输协议，通过超时和重传机制来保证传输数据流中的每一个bit的正确性，但是，当传输过程中有数据丢失的时候，由于对数据丢失的检测（超时检测）和重传，数据流的传输会被迫暂停或延时，无法保证数据传的输实时性。或许你能想到可以利用客户端构造一个足够大的缓冲区来保证显示的正常？这种方法对于从网络播放音视频来说是可以接受的，但是对于一些需要实时交互的场合（如视频聊天、视频会议等），如果缓冲超过了200ms，就会产生难以接受的实时性体验。（二十年前，在线看视频就经常会边看边缓冲，非常影响观影体验，当时就是用TCP传输的！）
那用UDP来传输呢？实时性保障没有问题，但多路视频或音视频如何保证同步呢？丢包又怎么解决？上层负载的编码方式那么多，双方怎么协商编解码呢？光靠UDP也是搞不定的。
由此，我们知道传输多媒体流需要在TCP/UDP传输层和应用层中间构建一种专门适应媒体流特点的传输协议，这就是我们今天要跟大家讲的流媒体传输协议。
1、流媒体协议简介及关联区分
（1）信令协议
SIP（Session Initiation Protocol，会话初始协议）:是一个基于文本的应用层控制协议，用于创建、修改和释放一个或多个参与者的会话。
H.323标准的音视频传输协议:它是一组协议。其中有负责音、视频信号的编解码和封装的信令，有负责呼叫信令收发和控制的信令，还有负责能力交换的信令，适合大型系统。
这里我们知道信令协议是让多人能在网络上建立、修改、释放实时通信会话的协议就行。
（2）流传输控制协议
RTSP（Real Time Streaming Protocol）实时流协议：是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内。
RTMP（Real Time Message Protocol）实时消息协议：最初用于在 RTMP 服务器和用户设备上的 Flash 播放器之间传输数据，通过将数据流分成相等的小部分并将它们顺序传输到接收设备，然后将它们重新组合成视频流来实现的。
这里我们知道它们是通信双方建立会话连接后，保证通信两端能实时将数据流传输给对方的协议。
（3）流传输协议
RTP（Real-time Transport Protocol）实时传输协议：是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。
RTCP（Real-time Transport Control Protocol）实时传输控制：是实时传输协议（RTP）的一个伴侣型协议。它收集RTP过程的统计信息（传输字节数，传输分组数， 丢失分组数，jitter，单向和双向网络延迟等等），为RTP所提供的服务质量（QoS）提供反馈。
这里我们知道它们是真正负责多媒体文件数据传输的协议。
小结：它们之间的关系可以简单概括为：SIP信令协议用于设备或用户(准确的说是Internet endpoints)地址管理、设备发现并初始化一个Session，相当于邀请大家一起参与网络视频语音通话；当需要被邀请的人都通过各自的终端设备被通知到后，就可以使用RTSP/RTMP来控制特定多媒体通信; 最后，若RTSP控制信息要求开始Video的播放，那么就开始使用 RTP实时传输数据，在传输过程中RTCP要负责QoS等。（SIP和RTSP/RTMP不是必须同时存在的，反而常常是根据不同的场景单独使用，如客户观看视频，RTSP就行了；多媒体数据的传输都依靠RTP）。
还没搞清楚它们的关系，可参考下图：
2、多媒体数据流传输场景
上文提到多媒体流场景不同，涉及的协议和分析方法也不同。下面简单介绍三种多媒体应用场景和场景中通信使用到的流传输协议：
（1） 简单的实时视频播放
用电脑上VLC播放器实时观看视频举例，采用最简单的C/S架构。类似于FTP，FTP是建立两个TCP链接，一个链接用来发控制命令，另一个链接用来传输数据。上文我们介绍了媒体流的特殊性，在这种实时视频播放架构下，是信令控制用一个协议（如RTSP（Real Time Streaming Protocol）实时流传输协议），传输流数据用流传输协议（如RTP（Real-time Transport Protocol实时传输协议，包含RTCP））。流传输协议和分层结构的关系如下图所示：
（2） 视频直播推流拉流
上面的架构很直观，很简单，我们再来看下视频直播间音视频流的传输（需要推流、拉流）。
所谓推流，就是把采集（如视频采集卡）到的音视频进行统一封装，通过流传输协议（多用RTMP），把数据传输到源站服务器（比如某音、某站的服务器）；
所谓拉流，就是把已经上传到源站的媒体流通过流传输协议（多用RMSP/RTSP+RTP）分发至CDN节点，再从CDN节点分发（多用RMSP/RTSP+RTP）至观看直播的终端；数据传输图如下：
在直播的网络架构下：
推流：一般采用RTMP来进行推流（可能用过摄像头的细心读者会注意到，摄像头通常使用RTSP提供原始视频流，那是因为RTSP在设计上更适合实时流媒体的控制和管理。而RTMP主要用于实时音视频传输，比RTSP的兼容性和适应性更好，RTMP用TCP传输，更稳定，所以都会把RTSP转换为RTMP，保证服务器收到的音视频流质量）；
拉流：采用RTMP或RTSP都行，用RTSP更多（可基于UDP）。
流传输：视频流量其实都是RTP（包含RTCP）在传输。
（3） 远程电话（视频）会议
这里以两个在不同域的设备进行SIP（Session initialization Protocol，会话初始协议）会话为例，如下图：
因为本篇不详细讲述SIP协议，现将上图电话会议的工作过程简单进行描述：
用户A邀请用户B进行SIP会话时，域A中的SIP代理服务器辨别出用户B不在同一域中。然后，SIP代理服务器在SIP重定向服务器上查询用户B的IP地址（SIP重定向服务器既可在域A中，也可在域B中，也可既在域A中又在域B中）。SIP重定向服务器将用户B的联系信息反馈给SIP代理服务器，该服务器再将SIP会话邀请信息转发给域B中的SIP代理服务器。域B中的SIP代理服务器将用户A的邀请信息发送给用户B。用户B再沿邀请信息经由的同一路径转发接受邀请的信息。
可见电话（视频）会议和前面直播类似，用SIP信令进行建连并控制，而音视频数据流是靠RTP来进行传播的。
小结：为什么花了这么大篇幅介绍音视频流的各种传输场景呢？因为如果不清楚媒体流在网络中的传输具像，在流量分析时将无从下手。读到这里，大家应该了解了多媒体流的传输流程（其他场景，如监控网络、视频会议等场景和上面我们讲到的大同小异。涉及SIP、H.323等信令协议本篇文章不做介绍），从几个场景图中也能看到，在网络中不同的抓包位置抓包，流量中包含的协议也是不同的。我们在对媒体流进行分析时，主要分析信令会话和数据会话两种。由于篇幅限制，我们不能把涉及的所有协议一一详解，下面我们选取贯穿整个媒体流传输的RTP协议进行详细讲解。
三、 RTP协议简介
1. RTP概念
RTP（Real-time Transport Protocol）是一个网络传输协议，协议详细说明了在互联网上传递音频和视频的标准数据包格式（可参考RFC3550，包含2个子协议RTP和RTCP）。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTSP协议），视频会议和一键通（PushtoTalk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，它建立在UDP协议上（前文已经说明过为什么不直接用UDP传输，不再缀述），广泛应用于流媒体相关的通讯和娱乐，包括电话、视频会议、电视。
RTP用于实时传输数据。该协议提供的信息包括：时间戳（用于同步）、序列号（用于丢包和重排序检测）、以及负载格式（用于说明数据的编码格式）。
RTCP用于QoS反馈和同步媒体流。（本文不再深入讲RTCP）
2. RTP数据包解码
这里需要说明一下，IP数据包中有一个识别传输层协议的“协议字段”，其中并没有RTP协议，UDP本身也没有协议类型字段，RTP自己也没字段，标识自己是一种具体的应用协议。因此，如果在通信双方建立会话时我们没有得到相应的会话信令（随机抓取了一段实时音视频包），则抓包工具不会显示数据包为RTP包，默认显示为UDP包。如果要对RTP包进行解码，需进行操作（以CSNAS为例）：
我们看到的全是UDP包，这时，我们需要选择一个包，右键点“解码为”，然后指定为RTP协议，如下：
配置好后，CSNAS中看到的结果为：
现在我们再来看RTP数据包的解码：
各字段解释如下：
| 字段名 | 含义 |
| 版本号（V，Version） | 当前使用的RTP版本 |
| 填充位（P，Padding） | 如果该位置位，则该RTP包的尾部就包含附加的填充字节 |
| 扩展位（X，extension） | 如果该位置位的话，RTP固定头部后面就跟有一个扩展头部 |
| CSRC计数器（contributing source identifier count） | 含有固定头部后面跟着的CSRC的数目 |
| 标记位（M，marker） | 该位的解释由配置文档（Profile）来承担 |
| 载荷类型（payload type） | 标识了RTP载荷的类型 |
| 序列号（sequence number） | 每发送一个 RTP 数据包，序列号增加1。接收端可以据此检测丢包和重建包序列。 |
| 同步源标识符(SSRC，synchronization source identifier) | 指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。 |
| 贡献源列表（CSRC List） | 前面CSRC置位后，这里用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。 |
注意：重要字段SSRC表明数据的来源，可用来关联SIP、RTSP等。也是用SSRC来还原RTP会话，进一步还原里面传输的音视频（必须支持解码格式，必须是明文数据）。
3. RTP的会话过程
当应用程序建立一个RTP会话时，应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成，有两个端口：一个给RTP包，一个给RTCP包，使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口（偶数的UDP端口＋1），这样就构成一个UDP端口对。
RTP的发送过程如下，接收过程则相反：
（1）RTP协议从上层接收流媒体信息码流（如H.263），封装成RTP数据包；RTCP从上层接收控制信息，封装成RTCP控制包。
（2）RTP将RTP 数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口。
4. RTP数据流分析
RTP建立在UDP上，分析单个RTP数据包几乎没有意义，因此，我们一般会借助抓包软件特有的VoIP分析功能。
对于一个没有信令的RTP会话（抓包时没抓到信令部分，如已经开始的视频会议等），在分析前必须自己做好RTP配置（暂不支持自动识别，功能还在开发中），CSNAS才会进行相关分析。配置方法如下：
配置成功后，即可开始分析，如下：
直接关注丢包率，及网络抖动情况等指标（更多相关指标还在添加中）。
如果有抓到会话建连的信令，则不用自己配置，系统会根据信令进行自动关联。
CSNAS专家版支持自动还原RTP流中的音视频文件（技术交流版暂不支持），当然需要是CSNAS支持的编码格式（见上面配置截图），并且是明文流量：
选择要还原的RTP会话，双击即可。
四、 案例分析举例
例：A集团某视频业务，画面总是莫名出现马赛克、卡顿、虚影等瑕疵，运维人员无法判断是设备问题（摄像头/服务器）还是传输问题（数通网络）所致，找到设备厂商，厂商很难做出检测，只是一味说自己设备没问题，但拿不出确切证据。
说明：今天取的例子比较特别，因为光是在一个位置抓包（客户端或服务器端），只能监控到视频的质量好坏，只能通过几项指标排查是否是网络问题，无法取判断视频质量不好的根因（RTP为UTP传输，不能像TCP传输那样分析）。因此，只能提前在网络中各个位置都部署好抓包点位，在同一故障时刻进行多段对比分析，才能定位出具体故障产生位置。所以本例中用到了科来的回溯分析服务器（多点位不间断抓包并分析存储），再从服务器上下载数据包用CSNAS分析（也可以不下载数据包，在服务器上直接查看相关指标）。
分析：检查网络指标：检查与视频流路径一致的TCP会话的指标，如SIP信令会话、H.225信令会话的建连时间、TCP丢包率等；
若没有信令，则直接查看会话重点查看平均码率、丢包率、抖动、乱序包四个指标；
若指标不正常（如丢包），则通过多段对比分析（不同抓包点同一时刻抓包的指标），确定出具体的丢包位置。
负责多点位抓包的回溯服务器上，在网络出口处看到相关视频业务流量，如下图：
下载相关数据包，由CSNAS打开：
存在较为严重的丢包，初步确认是网络问题导致的。现在定位具体丢包位置（如果部署了科来业务性能可观测性平台UPM，可直接进行多段分析，省去一个一个看包的麻烦）：
对上下行流量作多段对比分析后，最终确认是某设备处，因QoS策略设置不当导致的丢包，调整策略后，困扰集团很久的视频效果欠佳故障解决。
五、 总结
本篇文章我们从流量分析角度总体介绍了流媒体协议，因流媒体协议并非某一个协议，而是一众协议。因此我们先总体介绍了音视频传输的概念、原理和不同场景的网络架构，然后用RTP协议举例，讲解了流媒体协议的解码和分析。如果大家对流媒体协议感兴趣，可以把本文当成一个框架目录，后续依次去学习编码、信令、控制和传输等具体协议。后面我们将陆续介绍其他常见应用层协议，请大家持续关注！
暂无评论