寫這篇博文不打算介紹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中非常常見的對抗弱網的手段，瞭解其原理對我們的工作會有一定的幫助。這篇文章就介紹到這裏。
參考資料：