写这篇博文不打算介绍RTP/RTCP的基础知识，以及NACK是什么含义。
让我们从一个Wireshark抓包开始，一起来看看NACK是怎么一回事。
抓个包
我在Windows上用Wireshark（2.6.2）抓了一个基于RTP/RTCP协议的直播软件的包。这个软件启动后，会将本地音视频数据推流到服务器，它的抓包中，音视频数据部分长这样子：
我们看到，Wireshark并没有自动帮我们将这些UDP包显示为RTP/RTCP，所以我们需要修改一下。
选中一个UDP包，右键选择Decode As…，在弹出的窗口中，双击对应的Current列下方的下拉菜单，找到RTP，选中它，然后OK关闭对话框。
OK，回到Wireshark主窗口，我们看到，原来的UDP包已经变成了RTP/RTCP包了：
把RTCP过滤出来
从抓包看出，我们本机的IP地址是172.31.10.20，UDP发送的远端地址是59.110.163.25，这是一个阿里云服务器地址。所以，我们可以在Wireshark中设置过滤规则，把我们感兴趣的RTCP包都过滤出来，便于我们来分析。
由于本文的主题是NACK，所以我们来寻找一下NACK包。
我们知道，RTCP的Receiver Report（PT=201，后文简写为RR）中会包含丢包信息（Fraction Lost/Cumulative number of packets lost），当接收端检测到存在丢包时，会通过RTCP给发送端发送RR告知其丢包情况，随后会发来PT=205的丢包反馈信息（Generic RTP Feedback）来请求丢失的数据包。所以我们需要关注的就是PT=205的RTCP数据包。
在Wireshark的Filter中输入：
rtcp && (ip.src==59.110.163.25)
目的是过滤所有发送IP为59.110.163.25的RTCP包。过滤后的结果如下：
我们在过滤出来的所有RTCP包中，除了频繁发送的RR和APP包以外，找到了2个显示为Generic RTP Feedback的包，选中其中任一一个：
我们看到， PID为5014这个包应该是在发送端往接收端发送途中因为某种原因丢掉了，接收端以为没有收到这个包，所以向发送端来要。
那么发送端是否响应并回复了这个请求的包呢？让我们去掉Filter，显示该NACK请求附近所有的包，如下：
OK，我们看到，当接收到NACK请求后，本机（172.31.12.20）立刻将序号为5014这个丢掉的包补给了接收端（59.110.163.25）。这下，真相大白。原来一个NACK请求的过程就是这么简单。
NACK和FEC是WebRTC中非常常见的对抗弱网的手段，了解其原理对我们的工作会有一定的帮助。这篇文章就介绍到这里。
参考资料：