当前位置：首页 > article >正文

WebRTC服务质量（04）- 重传机制（01) RTX NACK概述

article 2024/12/25 4:29:19

WebRTC服务质量（01）- Qos概述
WebRTC服务质量（02）- RTP协议
WebRTC服务质量（03）- RTCP协议
WebRTC服务质量（04）- 重传机制（01) RTX NACK概述
WebRTC服务质量（05）- 重传机制（02) NACK判断丢包
WebRTC服务质量（06）- 重传机制（03) NACK找到真正的丢包

一、前言：

我们都知道WebRtc传输层一般选用UDP（允许你选用TCP，一般没人这么干），UDP的特点就是不能保证不丢包，并且不能保证顺序。那么，如果我们丢包了应该怎么办呢？目前WebRtc当中选择的办法是使用FEC和NACK机制，也就是说，我先自己尝试恢复，恢复不过来要求发送端再发一次。

二、NACK机制：

2.1、定义：

NACK（Negative Acknowledgments）是一种反馈机制，用于通知发送端某些数据包在传输过程中丢失了，从而让发送端可以知道需要重新发送丢失的数据包。

2.2、工作原理：

丢包检测： 接收端根据 RTP数据包的序列号检测丢失的数据包。如果序列号不连续，则说明有数据包丢失。
发送NACK： 接收端通过RTCP向发送端发送NACK消息，告知具体丢失了哪些序列号的数据包。
重传丢包： 发送端在接收到NACK后，会重新发送被请求的丢失数据包。

2.3、优点：

提高了数据传输的可靠性，同时尽量减少重新发送不必要的数据。
适用于实时通信，例如视频会议，因为它能够快速恢复丢失的数据。

2.4、实际用途：

NACK通常用于对丢包敏感的传输，比如视频或音频编码中关键帧（Key Frame）或解码参考数据等。

三、RTX机制：

3.1、定义：

RTX（Retransmission）是WebRTC中实现NACK的一个实际重传机制，用于基于NACK反馈进行丢包的重传。

3.2、工作原理：

RTX在RTP层的基础上增加了专用的传输通道，用于发送重传的数据包。
被重传的数据包通过RTX专用的RTP流发送，重传数据包的Payload Type或者**SSRC（Synchronization Source）**不同于原始流，便于接收端区分哪部分数据是重传的。
RTX SSRC/扩展头部： RTX流使用单独的SSRC，接收端可以轻松区分原始数据流和重传流。
重传的数据包结构： 在RTP Payload部分包含一些原始包的元信息，比如原始的RTP序列号，以帮助接收端恢复正确的顺序。

3.3、优点：

RTX设计为独立的RTP流，使得原始包和重传包的管理更加清晰。
支持高效、精准的重传，尤其是和NACK配合使用时表现最佳。

3.4、缺点：

RTX重传增加了带宽使用量，因为重传的数据本身需要额外的网络资源。
如果丢包率持续较高，重传可能导致网络拥塞问题。

四、NACK 和 RTX 的配合：

4.1、简化流程：

WebRTC中的NACK和RTX经常协同工作，以下是简化的协作流程：

媒体协商时候确定是否支持NACK或者RTX。
接收端发现丢包，并通过NACK通知发送端。
发送端根据NACK请求使用RTX机制发送丢失数据包。
接收端将RTX流中的数据插入到原始流的正确位置，恢复丢失的数据包。

4.2、媒体协商时候确定是否支持：

比如有以下媒体协商SDP内容：

m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115
a=sendrecv
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96

a=rtpmap:96 VP8/90000：表示支持VP8视频编解码器，pt为96；
a=rtcp-fb:96 nack：表示使用nack来进行96的丢包重传；
a=rtmap:97 rtx/90000：表示支持rtx重传，pt为97；
a=fmtp:97 apt:96：表示绑定96和97，使用97来重传96；