重传之ACK,SACK, RACK, NACK

Posted 2023-05-13

参考技术A 好比我从淘宝买东西，商家通过快递向我发送货物， 但货物可能在快递途中弄丢了， 我反馈给商家货物没收到后， 商家给补发一个货物， 这就是重传。

商家怎么知道货物丢了呢？可能是我的反馈，也可能是快递公司的反馈，或是商家发现我没确认收货。 这些方式就是ACK, SACK, RACK, NACK等报文了。怎么理解这些报文呢？ 下面从三种传输方式来解释重传的原理和工作方式。

ACK: acknowledgement 应答，响应。 在TCP里的ACK是一种累积ACK, 当前n个数据块收到后， 接收端发送ACK n+1, 告知发送端前n个数据收到了，而不是发一块数据给一个ACK响应。

假如从A到B送d1, d2, d3,d4,d5,d6,d7七块数据：

其中d3, d4丢失了，
那么ACK就是这样的：

什么时候会重传d3, d4呢？

从这里可以发现快速重传机制有个问题： 触发了d3的快速重传， 但d4还没有重传，d4要等到自己的T4 timeout到了或是三个ACK 4才重传，显然时延加大了， 有没有好的解决办法呢？ 这就引入了SACK。

SACK: Selective Acknowledgement 选择性的应答。在TCK协议里的SACK就是接收放告知发送方收到了一些数据片段， 它是ACK的补充， 如上例， B通过ACK告知了A收到了d1, d2, 但没告知A收到片段d5, d6,d7。

有了SACK, 就可以提前触发d4的重传了。

QUIC的重传机制同TCP的类似，同样用到ACK, SACK, RTO。 但改进了TCP重传机制中的问题。

TCP重传机制的问题：

NACK: Negative Acknowledgement 消极应答。所谓消极应答， 就是接收端不反馈收到哪些数据，而是反馈没有收到哪些数据。

当B收到d5后，通过对比序列号，发现d3, d4没收到， 那么发送NACK, 告知A, d3, d4丢失了， A就可以重传d3, d4了。

WebRTC系列-Qos系列之音频设置丢包重传nack

文章目录

• 1. 打开方式
• 2. 验证修改是否成功

1. 打开方式

在目前的WebRTC各个版本中音频的重传目前都是默认处于关闭的，也就是音频的sdp里默认是没有NACK；设置打开音频NACK有两种方式：

1. 修改源码的方式，通过前面的一系列文章我们知道WebRTC中收集音频编码信息是在WebRtcVoiceEngine的CollectCodecs(...)方法中，在这个方法里可以找到kRtcpFbParamTransportCc 也就是"transport-cc"设置，在sdp中是a=rtcp-fb:111 transport-cc；但是这种方式只适合有源码的修改；
2. 修改sdp的方式，在调用setRemoteSessionDescription之前修改sdp(这里不管是offer还是answer，都是在setRemoteSessionDescription之前)，修改建议使用libsdptransform c++版本把sdp转成json操作，浏览器有对应的sdp-transform js版；转成json后修改方式：