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