Magic_o的博客

感觉单纯看理论没啥意思，结合RTCP、RTP来看一看抓包详解。

tcpdump抓 wireshark分析。

学一学直播的架构吧，感觉要学的好多啊！！！！！！！！！！软考也没有搞，不能这样啊。OK开始学。

流媒体协议，英文学名Streaming Protocol，用一句人话来解释：流媒体协议是一种用于通过 Web 传递多媒体的协议。RTMP 和 RTSP 是两种不同的视频传输协议，它们的主要区别在于应用场景和传输方式。用于Internet上针对多媒体数据流的一种传输协议，是应用层协议。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输RTSP默认使用554端口（服务器的端口）

原来这是因为IPV4引起的，我们上网很可能会处在一个NAT设备（无线路由器之类）之后。NAT设备会在IP封包通过设备时修改源/目的IP地址. 对于家用路由器来说, 使用的是网络地址端口转换(NAPT), 它不仅改IP, 还修改TCP和UDP协议的端口号, 这样就能让内网中的设备共用同一个外网IP. 举个例子, NAPT维护一个类似下表的NAT表：NAT设备会根据NAT表对出去和进来的数据做修改, 比如将192.168.0.3:8888发出去的封包。

简而言之，STUN 向 NAT 外部的 STUN 服务器发送请求，服务器返回其在请求中观察到的内容，STUN 根据这些内容来帮助 NAT 后面的端点找出已创建的映射。好消息是，所有的行为都是可以理解和观察到的，因此ICE代理能够确认它创建了一个NAT映射，以及映射的属性。STUN 不仅使你能够创建映射，还可以让你获取映射的详细信息，你可以他人分享这些详细信息，然后他们便可以通过你刚刚创建的映射向你传回数据。您有两个媒体描述，一个是fmt 111类型的音频，一个是96格式的视频。）之前的另一项技术。

然后确保你保持连接状态。这些路由被称为。

卡尔曼滤波器：基本思想是通过已有的观测数据，总能找到⼀条线，使得所有观测数据到这条线的误差（距离）的平⽅和最⼩，⽽这条线就是Trendline要求得的值。WebRTC发送端拥塞评估算法正是利⽤这个趋势来评估下⼀个时刻的⽹络拥塞状态的，如果斜率向上，说明线路拥塞，如果斜率向下，说明拥塞缓解。这⾥需要注意的是，WebRTC中是按窗⼝求平均值的，默认窗⼝⼤⼩n=20（窗⼝⼤⼩是可以动态变化的）。实际上，这⾥求出的ki值与接收端延时拥塞控制算法中的mi值表达的是同⼀个含义，即在这个窗⼝期内发送队列的增⻓梯度。

本文档介绍了适用于webRTC两种拥塞控制算法。一种是基于时延（delay-based）一种是基于损失（loss-based）。

本文档介绍了适用于webRTC两种拥塞控制算法。一种是== 基于时延（delay-based）== 一种是== 基于损失（loss-based）==。

本文档介绍了适用于webRTC两种拥塞控制算法。一种是== 基于时延（delay-based）== 一种是== 基于损失（loss-based）==。

WebRTC的拥塞控制方式主要有以下几个：Transport-cc、BBR-congestion、remb（BBR已被google从webrtc移除了）。mediasoup支持Transport-cc和remb。

音频跟视频很不一样，视频每一帧就是一张图像，而从上面的正玄波可以看出，音频数据是流式的，本身没有明确的一帧帧的概念，在实际的应用中，为了音频算法处理/传输的方便，一般约定俗成取 2.5ms~60ms 为单位的数据量为一帧音频。上图是一个典型的 CDN 系统的三级部署示意图，节点是 CDN 系统中的最基本部署单元，分为三级部署，中心节点、区域节点和边缘节点，最上面一级是中心节点，中间一级是区域节点，边缘节点地理位置分散，为用户提供就近的内容访问服务。视频采集卡能支持的最大点阵反映了其分辨率的性能；

p是peer的缩写，p2p就是点对点，两个客户端直接进行数据交互，不需要经过服务器转发(relay)，这种方式能大大减轻服务端的负载，所以特别视适合大数据的传输，比如实时音视频聊天、在线视频直播、大文件传输等应用场景。如果遵循ICE协议，基本上能打洞成功的网络他都能p2p，不能打洞成功的网络基本上都是跟路由器类型有关，与技术无关。googActualEncBitrate 视频编码器实际输出的码率，一般和目标码率是匹配的。

在一般的VOIP软件或视频会议系统中，假设我们只有A和B两个人在通话，首先，A的声音传给B，B然后用喇叭放出来，而这时B的MIC则会采集到喇叭放出来的声音，然后传回给A，如果这个传输的过程中时延足够大，A就会听到自己刚才说的话，这就是回音。回音消除的作用就是在B端对B采集到的声音进行处理，把采集到的声音中包含的A的声音去掉之后在传给A，这样A就不会听到自己说过的话了。

帧，是视频的一个基本概念，表示一张画面，如上面的翻页动画书中的一页，就是一帧。一个视频就是由许许多多帧组成的。

在RTC（实时通信）中，为了防止网络拥塞或数据包丢失，FEC（前向纠错）是一种广泛使用的技术，它通过添加冗余数据来确保数据正确性。XOR（异或）：XOR的FEC算法利用两个数据包的异或和（XOR），作为冗余数据来补充传输，这个方法简单，计算速度较快，但有限的冗余信息不能有效地纠正过多的错误。（里德-所罗门）：Reed-Solomon是最常用的FEC算法之一, 它会创建多个冗余数据块（也称为符号），这些符号可以有效地对丢失或损坏的数据包进行纠正，它被广泛应用于音频、视频、图像等需要高保真度的数据传输。喷泉码。

音视频服务质量与带宽之间的矛盾、实时性与服务质量之间存在矛盾。

对于TMMBR/TMMBN和REMB，接收方首先估计可用的入站带宽(使用GCC等协议)，然后将这些带宽估计传达给远程发送方。由于这些数据频繁交换，发送方能够快速调整变化的网络条件，并使用GCC这样的算法改变其输出带宽。发送方跟踪发送的数据包、它们的序列号、大小和时间戳。当发送方从接收方接收RTCP消息时，比较发送方的包间延迟和接收方的延迟。它们根据每个SSRC的时间表发送，它们是估计可用带宽时使用的输入。RTP/RTCP运行在所有类型的不同网络上，因此，一些信息在从发送方到接收方的途中被丢弃是很常见的。

在WebRTC中，ARQ（Automatic Repeat Request）和Nack（Negative Acknowledge）也被用于数据传输过程中检测和纠正错误。发送方发送数据包，接收方收到并检验数据包，若数据包出现错误，则向发送方发送Nack请求重传该数据包。发送方收到Nack后，会重新发送该数据包，直到接收方接收到正确的数据包为止。ARQ和Nack解决的问题也是数据传输过程中的错误。在WebRTC中，数据传输过程中数据包可能会出现错误，比如数据包被丢失、数据包内容损坏等。