发布和播放
在流视频领域，WebRTC服务器端有两个主要功能：发布和播放。需要发布时，WebRTC从网络摄像机捕获视频流，并将其从浏览器移动到服务器。需要播放时，视频流从服务器移动到浏览器，在设备浏览器的HTML5的“video”进行解码，然后播放。
UDP和TCP
视频可以通过两种传输协议（即TCP或UDP）移动。用UDP协议的话，NACK RTCP反馈会主动工作，并携带丢失数据包的相关信息，这使得检测UDP信道恶化非常简单，即对NACK（Negative ACK）进行计数以确定质量。NACK和PLI（Picture Loss Indicator）反馈越多，实际损耗就越多，信道质量也越低。
没有NACK的TCP
本文重点讨论TCP协议。在TCP上使用WebRTC时不会发送NACK RTCP反馈。即使发送了NACK RTCP反馈，也无法反映损耗的真实情况，所以我们无法通过反馈来确定信道质量。但众所周知，TCP是可以保证传递的传输协议。因此，我们会通过TCP发送网络中的其余数据包以防信道质量下降。这些数据包迟早会被交付，但这些损失不会导致NACK的产生，因为实际上并没有损失。所以，这些数据包会延迟到达目的地，且他们根本不会聚集到视频帧中，只会被拆包器丢弃。所以用户会看到些许失真的图片，如下图所示。
但同时，反馈显示一切正常。下图中包含Wireshark流量的截图，显示了在压缩的TCP和UDP通道上发布的视频流的走向。Google Chrome数据截图在下图中也有所展示。通过这些截图您可以看到：即使信道状态非常糟糕，TCP中的NACK指标也不会像在UDP中那样剧增。
TCP
UDP
如果UDP更好，为什么还要通过TCP进行流传输？
这个问题很好。答案是：我们需要TCP来推动更高的分辨率。比如在进行VR（虚拟现实）流传输时，分辨率可能为4k，不可能把这种分辨率和约10 Mbps比特率的流无损地推送到常规信道中。这时服务器会拒绝接收UDP数据包，然后把这些数据包成包丢弃在网络中，再把剩下的数据包发送。长此以往，大量废弃的视频数据包会破坏视频，最终导致视频质量很差。这就是为什么我们要使用TCP上的WebRTC，通过WebRTC在通用网络中以高分辨率（如Full HD和4k）传送视频以减少网络中数据包丢失的情况。这样做我们只会有一点通信延迟，事半功倍。
RTT用于确定信道质量
因此，没有指标能百分百显示信道的不良状态。一些开发人员试图依靠RTT指标，但是它不能在所有浏览器中使用，且无法给出准确的结果。
下图展示了基于callstat项目的信道质量对RTT的依赖性。
原文地址：https://flashphoner.com/channel-quality-indicator-for-server-webrtc-over-tcp/
