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经常协同工作，以下是简化的协作流程：

1. 媒体协商时候确定是否支持NACK或者RTX。
2. 接收端发现丢包，并通过NACK通知发送端。
3. 发送端根据NACK请求使用RTX机制发送丢失数据包。
4. 接收端将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；

4.3、发送数据：

在源源不断发送RTP数据包过程中：

• 如果接收端B收到包序号不连续，未必是丢包，有可能是乱序，在jitter buffer（webrtc默认是20ms）里面稍微调整下；
• 如果调整之后发现确实丢包，那么发送RTCP-RTPFB-NACK给发送端一个回馈消息；
• 发送端解析RTCP的NACK请求，从历史队列找出丢失的包（如果可以找到），打包成RTX数据包，重新发送。
• 接收端收到RTX包之后，去丢失队列中去找，如果找到了，就从丢失队列中移除对应包。

4.4、适用场景：

• 低延迟场景： NACK和RTX针对丢包的小范围重传非常有效，因为其反馈与重传机制相对快速，对于实时性较高的应用（如视频通话）非常适用。
• 丢包率低的网络环境： 在较高丢包率的环境中，频繁的NACK请求及RTX重传可能造成更大的网络负担，影响质量。