大家好，又见面了，我是你们的朋友全栈君。
前面讲解了音视频编解码的基本知识，相信阅读过的朋友，都有个基本的认识。音视频除了存储，还如何传输呢?比如直播互动，网上课堂等，这些场景中，音视频是如何实现在网络中传输呢?今天这篇文章，就讲解下，音视频的传输的基本知识。本文主要讲解一些基本的传输协议、拥塞控制，音视频同步，校验，QOS服务质量等。
一.传输协议 流媒体的很多协议都是在传统的TCP/UDP协议之上，加强流媒体在网络传输中的稳定性。在端到端的结构中，发送端的音视频数据通过流媒体协议发送给接收端，中间的传输过程重要的部分就是用TCP/UDP。下面是流媒体与TCP/UDP协议的结构图。
流媒体中有一些常用的协议，比如RTMP，RTSP，RTP等，这些协议底层或者说传输层，基本都是基于TCP/IP模型，也就是在局域网的实现还是TCP/IP。传输层有着承上启下的作用，对上提供服务，对下提供网络传输是否可靠，是否能够增加网络服务的质量。其作用如图所示。
TCP协议都很熟悉了，具有如下这些特点：
1.面向连接的协议，可靠，顺序包
2.一种字节流
3.滑动窗口，流量控制
TCP通过三次握手建立连接后，应用层的数据会不断发到TCP缓冲中去，在流媒体中，数据这个层次需要切片，并加上header，形成segment，TCP报头如图所示：
为什么音视频在有些场景不直接用TCP呢?具有以下原因。
1.在实时语音，视频等场景下，TCP的重传会造成流媒体极大延时，用户体验差。 2.拥塞控制会造成大量卡顿，主要体现在弱网环境中，码率不变的情况。 3.TCP报头要大于UDP，数据量更大。 4.TCP连接需要花大量的时间，对于画面秒开会有一定的影响。 以上都是在实时互动的场景中，不用TCP的原因，这些场景使用UDP肯能更加合适。 UDP报头如下:
UDP更加适合一对多实时互动的流媒体场景中，在网络带宽足够的情况，采用UDP，会更加符合实际，在UDP包加一个时标和序号，再加上适当的缓冲，也可以记录无序包，同步音视频数据等效果。 这里并不是说哪种协议更加好，关键是看使用场景。TCP与UDP对比。
编程思路，这里暂时不讲解具体编程代码，后面会有专栏来去分析。 TCP协议套接字编码流程。
RTP协议应用在组播，一对多的场景中比较多，它是基于UDP协议之上，RTP协议的应用部分主要是提供一些控制信息，比如同步，报文分割等，具体报文格式如下，PT(类型)、M(标记)、时间戳，RTP格式如下:
RTSP，也是一种流媒体协议，在很对安防场景中，使用的十分频繁，一般工作在TCP之上，它也是采用一种流式传输，可以减小延迟。当接收端有足够数据之后，就会解码播放。RTSP主要特性如下：
二.拥塞控制
拥塞控制主要是解决网络堵塞的情况，解决好网络堵塞的传输，一直是业内关注的问题，有很多的专家组建团队去攻克这些难题。拥塞控制可以做些什么呢?在网络资源和带宽有限的情况，如何控制质量，尽可能提升质量，就是传输视频的有效手段。网络堵塞表现在数据包延时增加，丢弃率增加，性能下降。拥塞控制对网络性能影响如下：
产生拥塞控制主要是由以下几点影响的?
1.带宽，最大值受香农定理限制，发送速率小于或等于信道容量。
2.存储空间，主要体现在数据报的丢弃上。
3.处理器能力，这个不仅仅指的是CPU，还有GPU，其它硬件编解码器等。
根据服务模型不同，拥塞控制可分为预留策略和反馈策略。
预留策略主要是向网络提交资源请求，在带宽足够，则会为主机预留响应资源。否则拒绝。
反馈策略主要是根据反馈，动态调整发送速率。
网络层的拥塞控制
网络层的拥塞控制主要利用路由器的包调度算法和缓存管理技术，也就数要处理好两个基本问题。存储和转发。在技术上实现思想包括。
TCP拥塞控制分为4个阶段:慢启动、拥塞避免、快速重传、恢复阶段。如果在TCP启动阶段，向网络发出了很多数据，这个时候可能造成网络吞吐量下降。慢启动阶段就是为了避免出现数据爆发的情况。慢启动流程就是当建立新的连接时，先初始化一个数据包大小，按照拥塞窗口大小发送数据，收到一个ACK，拥塞窗口就增加一个数据包的发送量，基于这种反馈的策略，保证不破坏网络状态平衡，使启动阶段能够稳定。如果连续收到确认帧，则控制算法判定网络要发生拥塞，这时就需要进入拥塞避免阶段。若超时，窗口置1，就需要设置慢启动阈值，如果慢启动阈值小于拥塞窗口，TCP就执行拥塞避免算法，每收到一个确认帧，就需要增加一个数据包。反之TCP重新进入慢启动。拥塞控制过程如下图所示:
当源端收到3个或3个以上确认时，TCP就断定数据已经丢失，重传该数据包，迅速进入快传和恢复阶段。 1.先进先出(FIFO) 比如FFmpeg、MediaCode等开源代码或音视频架构都是应用的非常多，基于此方法，路由转发的压力会下降。如图所示：
FIFO优点是通过缓存，可以提前得到一些信息，避免卡顿。缺点是对于特殊包的公平性较差，快速恢复的效率也不高。
2.公平排队算法
这种算法表示每一路数据流都需要维护一个队列，路由器以轮询方式访问，当路由器来回扫描所有队列，将第一个包发出。FQ的工作原理如图所示:
FQ的优点是在轮询机制下表示什么时候可以发送完毕，通过结束时间去安排数据包发送，保证算法公平性，同时不会影响统计复用。缺点实现复杂，需要更多的资源和容错处理。市面上也有一些改进算法，比如加权公平排队算法、通过加权的方式分配缓存资源。 3.ECN
ECN将更平均分配在路由器和终端节点，这类通知是通过简单的经过路由器的数据包中设置一个拥塞位来实现，先把ECN使能位发送，由路由器根据网络设置CE比特位，如果接受到网络反馈的这类CE置位的数据包，然后发出的数据包标记为丢弃包。 优点是不需要超时重传，不依赖TCP定时，对于网络的突发性变化更好。
4.REQ
这个算法可估计拥塞什么时候发生，按照一定的概率丢包，提高吞吐量。 基于网络层和传输层的控制算法比较
在组播环境的音视频的层次化传输方案如下图所示，这种基于应用层的控制，需要把音视频切分成更小的数据片，网络发生堵塞时，丢掉一些不太重要的数据。这些类型的方法有3类，自适应算法，重传和缓冲。
三类算法的延时比较。
三、音视频同步
音视频同步是流媒体中十分重要的模块，直接影响用户体验，如果音视频不同步，不仅仅导致观感效果差，而且还可能会引起视频卡顿，音频无法播放等。所以这个模块与解码，编码等模块都有着千丝万缕的联系。一般同步机制主要是分为三种，音频同步视频，视频同步音频，音视频同步一个固定时钟，字幕也有同步，这里暂且不讨论。
音视频同步背后的故事？
音视频在传输过程中，延时抖动，时钟偏差，网络变化都会导致同步的过程发生变化。以下是延时抖动对流媒体同步的影响。
流媒体在采集，传输，解码等过程中，都会实现相应的同步机制。
本地文件流同步方法：
(1)基于参考点同步
使用流媒体的音频或者视频的索引作为参考点，开始打开文件，读取文件的头信息，读取第n帧的音频数据，检查前面的n-1帧是否播放完，如果已经播放完，则跳过下一帧视频，只播放第n帧的视频，重新返回到音频的N 1帧读取，如果前面的第N帧音频还没有播放完，则把第n帧音频放到输出队列，然后读取并显示第n帧视频，如果上述情况出现很多次，则显示视频时加入一定延时。
(2)基于参考时钟同步
音视频基于系统固定时钟，实现同步，各自沿着时钟线段进行播放，如果音视频的时间戳与固定时钟的误差超过设置的同步门限，则重新同步。这个方法优点是，音频和视频的时间戳不用交集，相互不影响，缺点是，如果固定时钟，音频，视频，这三者中的时间戳不准，或者跳变很大，就会出现灾难性的体验。大致的流程是，以参考时钟的映射为标杆，进行同步控制，重置音视频的起点，如果音频或者视频超越和落后对方，则就会等待或丢弃相应数据。 网络传输同步
音视频在网络传输过程中，基于参考时钟的这种方法很难实现，或者实现起来体验很差，为什么呢?在复杂的网络环境中，如果时钟信息被丢失或者读取错误，会导致解码端和播放端，同步的效果很差。所以在网络中，都是基于音频同步视频，或视频同步音频，这里以音频的时间戳作为基准进行同步，音频会以固定速率播放，而视频会根据音频的时间戳进行等待或者丢弃。
在客户端和服务端，会同步实现一种反馈机制，客户端会把不同步的信息，发送给服务端，由服务端根据这种反馈信息进行反馈检测。当客户端检测到失调后，接收端会跳过或暂停。服务端则调整发送速率。
四、差错控制
前面提到的拥塞控制，无法完全避免包的丢失，这就需要一定的差错控制技术。可以发送定义和识别帧边界，并处理接收方回送的确认帧。如帧数计数法，首尾标志法等。
差错控制的方式分为2类，即反馈纠错和前向纠错。反馈纠错方式是指在发送端对输入信息编码时，加入少量监督符号，在接收端需要对编码信息进行检查，如果出错，需要请求重发，指导收到的信息正确为止。前向纠错就是在发送端使用一套相对复杂的编码方法，从而能够在解码端去纠正传输的差错，接收端不仅能发现错码，还要纠正。这些纠错码，市面上比较常用的海明码，循环冗余码等，这篇文章就不详细分析。
五、QoS服务质量
上面介绍的音视频同步，校验，都是Qos的范畴。它是指提供服务质量的期望值以及考验网络性能的要求。Qos设计满足一些基本原则，比如，透明原则，综合原则，分离原则等。
Qos参数体系结构如下图所示，用户使用Qos来分析网络性能。
网络接口层，是解决传输介质问题。 网络层需要解决延时，抖动，差错控制等问题。 传输层解决吞吐量，延时，抖动，传输优先级等问题 应用层主要是实现不同场景的参数配置，及问题反馈。 关于Qos分析，先讲解这么多，后面再补充 六、总结
前面五部分都是十分重要的环境，如果需要掌控整个系统，或者优化，这些基础知识是必备，希望各位朋友认真阅读并理解。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/127341.html原文链接：https://javaforall.cn
