一、前言：
我们都知道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；
4.3、发送数据：
在源源不断发送RTP数据包过程中：
- 如果接收端B收到包序号不连续，未必是丢包，有可能是乱序，在
jitter buffer（webrtc默认是20ms）里面稍微调整下； - 如果调整之后发现确实丢包，那么发送RTCP-RTPFB-NACK给发送端一个回馈消息；
- 发送端解析RTCP的NACK请求，从历史队列找出丢失的包（如果可以找到），打包成RTX数据包，重新发送。
- 接收端收到RTX包之后，去丢失队列中去找，如果找到了，就从丢失队列中移除对应包。
4.4、适用场景：
- 低延迟场景： NACK和RTX针对丢包的小范围重传非常有效，因为其反馈与重传机制相对快速，对于实时性较高的应用（如视频通话）非常适用。
- 丢包率低的网络环境： 在较高丢包率的环境中，频繁的NACK请求及RTX重传可能造成更大的网络负担，影响质量。