导语 | 音视频时代，WebRTC在形形色色的产品和营业场景下均有落地。在熟悉如安在浏览器获取设备的音视频数据和WebRTC是若何将获取的音视频数据进行收集传输的同时，我们更要夯实一下收集传输协定相干的基本常识，这能赞助我们更深刻地进修WebRTC。推荐和前端音视频专题中的文章一路食用。
1. 传输层协定：TCP vs. UDP
我们都知道HTTP协定，运行于TCP协定之上，是万维网的运转的基本。作为一名前端开辟，我们似乎理所应当熟悉HTTP、TCP协定，乃至于HTTP状况码、报文构造、TCP三次握手、四次挥手等等都已经成为了标配的基本面试题。但对于其他协定，我们似乎多若干少认为陌生。
下图是一个TCP/IP通信协定的4层构造图，在基于网际层的运输层，它供给了节点间的数据传送办事，个中最为人所熟知的 TCP协定（Transmission Control Protocol）和 UDP协定（User Datagram Protocol）。
两个协定本身涉及到内容异常多，但在实际选择应用中，我们不妨直接经由过程比较TCP和UDP，往来交往进修和懂得它们。
1.1. TCP和UDP比较
总体上有以下三点不合：
TCP是面向连接的，UDP是无连接的。
TCP是面向字撙节的，实际上是TCP把数据算作连续串无构造的字撙节；UDP是面向报文的。
TCP供给靠得住的传输，也就是说TCP连接传输的数据不会损掉，没有反复，并且按次序达到，UDP供给弗成靠传输。
1.1.1. UDP无连接，TCP面向连接
UDP在传输数据之前不须要建立连接，传输两边可以随时发送数据，是以UDP是无连接的。而TCP协定在传输数据之前三次握手建立连接，在停止后须要四次挥手释放连接，具体细节在此不做赘述。
1.1.2. UDP面向报文，TCP面向字撙节
对于UDP，发送接收方应用层只给UDP传输层发送或接收报文，而UDP除了传输外的处理只是对应用层报文添加或摘除UDP首部，保存了应用层报文，是以说UDP是面向报文。
对于TCP而言，TCP只将应用层交下来的数据当做连续串的无构造字撙节，仅将他们存入缓存并根据策略构建TCP报文进行发送，而接收方TCP只提取数据载荷部分存入缓存，并同时将缓存字撙节交给应用层。TCP不包管两边应用层的发送和接收数据具有对应大年夜小关系。是以说它是面向字撙节的，而它也是TCP实现流量控制和拥塞控制的基本。
1.1.3. UDP是弗成靠连接，TCP是靠得住连接
UDP在传输数据时，发送产生了丢包，发送方不做任何处理。接收方校验首部发明误码，同样也不做任何处理。是以说UDP向上供给的是无连接弗成靠办事。
而TCP在传输数据时，假如产生了丢包或者接收方检查了误码（此时会接收方会丢弃），接收方不会回确认报文，则触发接收方超时重发。由此可见，TCP经由过程其策略确保其传输过程无论产生什么情况，则接收方就能精确收到该数据包，是以说TCP是向上供给面向连接的靠得住办事。
1.2. 为什么选择UDP
既然TCP有这么多长处特点，那么为什么在及时音视频传输中应用UDP呢？
原因在于及时音视频对于延迟特别敏感，而基于TCP协定的做不到足够低。试想一下在丢包的情况下，TCP协定的超时重传机制中RTT是以2的指数的增长。假如7次重传任然掉败，理论计算会达到2分钟！在延迟高的情况下，想做到正常的及时通信显然是弗成能的，此时TCP的靠得住性反而成了包袱。
但实际情况是，平日及时音频视频数据在传输的少量数据包损掉，对接收者影响并不大年夜。而UDP不属于连接型协定，我们认为它根本是管发不管收，因而具有资本消费小，处理速度快的长处。
是以UDP在及时性和效力性都很高，在及时音视频传输中平日会选用UDP协定作为传输层协定。
WebRTC也是如斯，在信令控制方面采取了靠得住的TCP， 然则音视频数据传输上，应用了UDP作为传输层协定（如上图右上）。
2. 应用层协定：RTP and RTCP
及时音视频通信只靠UDP够不敷呢？谜底显然是不敷的！还须要基于UDP的应用层协定，来专门为音视频通信做更多保障处理。
2.1. RTP协定
音视频中一个视频帧数据量须要多个包来传送，并在接收端构成对应帧，精确还原出视频旌旗灯号。是以要做到至少两点：
检测掉足次序，并保持采样和播放之间的同步关系。
须要在接收端检测出分组的损掉。
而UDP并没有这个才能，所以音视频传输中，并不直接应用UDP，而是须要RTP作为及时音视频中的应用层协定。
RTP全名Real-timeTransportProtocol(及时传输协定)，主用于及时传输数据。那么RTP协定供给哪些才能？
包含以下四点：
及时数据的端到端传输。
序号（用于丢包和重排序检）
时光戳（时光同步校订和分发监控）
载荷的定义类型（用于解释数据的编码格局）
但不包含：
及时发送
质量包管
送达（可能丢）
时序（达到次序）
接下来让我们简单看下 RTP协定规范[1]
RTP报文由两部分构成：报头和有效载荷。
以下为RTP协定头的解释，前12字节是固定的，CSRC可以有多个或者0个。
V：RTP协定的版本号，占2位，当前协定版本号为2。
P：填充标记，占1位，假如P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
X：扩大标记，占1位，假如X=1，则在RTP报头后跟有一个扩大报头。
CC：CSRC计数器，占4位，指导CSRC标识符个数。
M：标记，占1位，不合的有效载荷有不合的含义， 对于视频，标记一帧的停止；对于音频，标记会话的开端。
PT（payload type）： 有效荷载类型，占7位，用于记录RTP报文中有效载荷的类型/Codec，在流媒体中大年夜部分是用来区分音频流和视频流，便于接收（receiver）找出响应的 decoder 解码出?。
序列号（sequence number）：占16位， 用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。 这个字段当基层的承载协定用UDP的时刻，收集状况不好的时刻可以用来检查丢包。当出现收集颤抖的情况可以用来对数据进行从新排序。序列号的初始值是随机的，同时音频包和视频包的sequence是分别计数的。
时戳（timestamp）：占32位，必须应用90kHZ时钟频率（法度榜样中的90000）。 时戳反应了该RTP报文的第一个八位组的采样时刻。接收者应用时戳来计算延迟和延迟颤抖，并进行同步控制。可以根据RTP包的时光戳来获得数据包的时序。
同步源（SSRC）标识符：占32位，用于标识同步信源。同步信源是指产生媒体流的信源，他经由过程RTP报头中的一个32为数字SSRC标识符来标识，而不依附收集地址，接收者将根据SSRC标识符来区分不合的信源，进行RTP报文的分组。
供献源（CSRC）标识符：每个CSRC标识符占32位，可以有0~15个CSRC。每个CSRC标识了包含在RTP报文有效载荷中的所有供给信源。
2.2. RTCP协定
前面提到RTP协定整体上照样比较简单粗暴的，其本身并没有供给按时发送机制或其它办事质量（QoS）包管。是以RTP还须要有一套配套协定为其办事质量供给包管，则就是 RTCP协定（全名Real-timeControlProtocol）。
RTP标准定义了两个子协定，RTP和RTCP。
举个例子，在传输音视频时的丢包，乱序，颤抖，这些WebRTC在底层都有对应的处理策略。然则若何将这些传输时 “收集质量信息”及时告诉对方，就是RTCP它的感化。相对于RTP来说，RTCP所占的带宽异常小，平日只有5%。
接下来让我们简单看下RTCP协定规范：起首RTCP报文有多种类型：
发送申报SR (Sender Report): 当前活动发送者发送、接收统计。PT=200
接收者申报RR (Reciver Report)：接收申报，非活动发送者接收统计。PT=201
源描述申报SDES(Source Deion)：源描述项，包含CNAME PT=202
BYB申报：介入者停止对话 PT=203
APP申报：应用自定义 PT=204
jitter申报IJ PT=195
传输反馈RTPFB PT=205
Playload反馈PSFB PT=206 . . . . . 这里我们可以存眷两个比较重要的的报文：SR 和 RR，经由过程他们让收发两端知道收集质量情况。
以上为SR的协定规范：
Header 部分用于标识该报文的类型，比如是 SR（200） 照样 RR（201）。
Sender info 部分用于指明作为发送方，到底发了若干包。
Report block 部分指明发送方作为接收方时，它从各个 SSRC 接收包的情况。
经由过程申报以上信息，各端知道收集传输反馈数据后，就可以根据其做传输策略的调剂了。当然协定本身的内容并不只有上面的简单一小段，实际还涉及各项反馈数据的计算办法，这里篇幅有限不展开细讲。
2.3. RTP会话流程小结
当懂得为什么选择UDP协定、以及RTP/RTCP协定做了些什么工作之后，让我们简单总结在传输协定层面上的全部流程：
当应用建立一个RTP会话时，应用法度榜样将肯定一对目标传输地址。目标传输地址由一个收集地址和一对端口构成，有两个端口：一个给RTP包，一个给RTCP包。RTP数据发向偶数的UDP端口，而对应的控制旌旗灯号RTCP数据发向相邻的奇数UDP端口（偶数的UDP端口＋1），如许就构成一个UDP端口对。大年夜致流程如下：
RTP协定从上层接收流媒体信息码流，封装成RTP数据包；
RTCP从上层接收控制信息，封装成RTCP控制包。
RTP将RTP 数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口。
2.4. 快速上手Wireshark抓包RTP及RTCP
纸上得来终觉浅,绝知此事要躬行。接下来让我们经由过程实际播放WebRTC流媒体，并经由过程抓包来还原RTP包和RTCP报文的真面貌。
Wireshark是一个强大年夜的收集数据包分析软件，可以具体的展示收集数据包的交换过程，是监控收集请求定位收集问题的利器。这个强大年夜的抓包对象，涉及异常多功能，因为这里不是Wireshark教程，更具体的功能课自行搜刮发掘，这里只会讲个大年夜致流程：
下载并安装Wireshark（异常简单）。
浏览器打开腾讯教室，遴选一个免费且正在直播的课程，一般情况下采取WebRTC播放。(另起tab打开WebRTC调试对象 这里会展示页面WebRTC播放及时流媒体数据的收集情况。)
打开Wireshark，须要选摘要捕获机械上彀卡的收集包。当你的机械上有多块网卡的时刻，你须要选择一个网卡接口，这里我选择了我的Wifi，并点击左上角蓝色按钮开端抓包。
一旦你启动抓包，这里会刹时展示抓到的各类协定的大年夜量数据包（下图展示wireshark每个区域的功能），个中在①过滤栏中输入UDP进行过滤，然后就会在②数据包列表中只展示出udp的数据包，并会解析出部分协定的数据包，并在Protocol列清楚的看到它们的协定。
因为WireShark不会直接辨认RTP的UDP数据包，须要右键UDP包解析为（decode as）RTP包。
此时wireshark可以或许辨认RTP协定数据包，在分层协定可以看到清楚的构造，从上往下依次是：IP = > UDP => RTP 我们点开RTP协定那一层，展开可以看到，和上面RTP报文协定的一致：标清楚明了版本号、填充标记...等等内容。
经由过程上方‘对象栏’=>‘德律风’=>‘RTP‘打开信息面板，可以看到当前有一条音频RTP流，和一条视频RTP流。左边分析出表示了流的源地址端口和目标地址和端口。右边为RTP相干内容，展示了RTP流的SSRC、载荷类型、丢包情况等等。
最后再简单看RTCP，在过滤栏中输入rtcp进行过滤，可以看到Sender Report 和 Receive Report。他们的PT（packcet type）分别为200和201，申报的SSRC为0x02029dfc，以及具体的发送包和接收的情况。具体的内容解析可以结合RTCP规范协定去进一步进修懂得。
个中我们应当侧重存眷的部分内容：
Playload type（PT值）：代表负载的类型，个中这里122对比WebRTC的SDP可以确认是H264视频负载类型数据。
时光戳：记录的是采样时刻为6120，还要根据采样率进行换算。
SSRC: 同步源（SSRC）标识符为0x0202c729。以上这些都是RTP头部，最后playload才是承载的媒体数据。
RTP的特点不仅仅支撑承载在UDP上，有利于低延迟音视频数据的传输，它许可经由过程其它协定接收端和发送端协商音视频数据的封装和编解码格局，playload type字段比较灵活支撑的音视频数据类型异常多的，具体可以参考：RTP payload formats
让我们再具体看看RTP包的音视频帧：
个中下面seq=21到seq=24的多个数据包，每个零丁为一个音频帧，所以时光戳不合。而红色框seq=96到seq=102的多个数据包构成，构成PT=122的一个视频帧，所以这几个报的时光戳也是雷同的。这是因为一个视频帧包含数据量较大年夜，须要分开多个包发送。而音频帧较小，则零丁一个包发送，从它们的包length大年夜小就能看出视频包比音频包要大年夜的多。别的seq=102的数据包，mark字段为true表示为一个视频帧的最后一个数据包，经由过程结合seq可以知道音视频数据的接收是否有乱序或者是丢包。
3. 总结
不少人认为一名开辟者在进修应用WebRTC时，可以或许快速上手实践和营业落地就足够了，再去懂得这些传输协定有须要吗？但经常即便你已经清楚若何应用它，不代表你能发挥出它本身最大年夜优势。我认为应用一项技巧所达到的上限，往往取决于你对它的底层懂得有多深刻。
这里简单介绍为什么及时音视频选择UDP作为传输层协定，以及简单介绍WebRTC所涉及协定中比较重要的两个协定RTP/RTCP，像WebRTC技巧涉及与融合多方面种技巧（音视频处理，传输、安然加密等等）每个模块涉及的协定都能零丁写一篇文章，篇幅所限以及本人控制的内容比较有限，此文无法对更多内容进行展开。假如你想进修实践WebRTC，此文只能让你在其传输协定层面上有初步的熟悉。因为协定往往涉及底层，日常平凡应用往往存眷不到，是以还介绍了若何快速上手抓包来赞助懂得，假如想深刻进修还需另寻材料深刻进修。
4. 参考材料
[1] RTP协定: https://tools.ietf.org/html/rfc35f50#
紧追技巧前沿，深挖专业范畴
- 上一篇： 亿航CEO胡华智：我们要成全球领先的空中智能交通运输服务商
- 下一篇： 顺丰失利，一个省钱时代的到来
