網(wǎng)絡(luò)通信中的ACK、NACK與REX是什么？相信大部分人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，話不多說，一起往下看吧。

成都創(chuàng)新互聯(lián)公司是一家專業(yè)從事成都網(wǎng)站設(shè)計、網(wǎng)站制作的網(wǎng)絡(luò)公司。作為專業(yè)網(wǎng)絡(luò)公司,成都創(chuàng)新互聯(lián)公司依托的技術(shù)實力、以及多年的網(wǎng)站運營經(jīng)驗,為您提供專業(yè)的成都網(wǎng)站建設(shè)、全網(wǎng)整合營銷推廣及網(wǎng)站設(shè)計開發(fā)服務(wù)！

ACK：Acknowledgement，它是一種正向反饋，接收方收到數(shù)據(jù)后回復(fù)消息告知發(fā)送方。

NACK：Negative Acknowledgement，則是一種負向反饋，接收方只有在沒有收到數(shù)據(jù)的時候才通知發(fā)送方。

REX：Retransmission，重傳，當發(fā)送方得知數(shù)據(jù)丟失后，重新發(fā)送一份數(shù)據(jù)。

問題 1：接收方如何判斷數(shù)據(jù)包是否丟失 ？

解決方案：編號，每一個 packet 都打上一個序列號（Seq number），接收端發(fā)現(xiàn)序列號跳變/缺失，則可以判斷數(shù)據(jù)包丟失了。

這就是為什么 TCP 協(xié)議的包頭（packet header）里面要定義一個序列號字段的原因（如圖紅色標記）：

擴展一下，我們再看看 UDP 協(xié)議的包頭（packet header）的定義：

可以看到，UDP header 沒有用任何字段來標識序列號（Seq number），由此可見，UDP 是一個完全不關(guān)心是否丟包的傳輸協(xié)議。

問題 2：發(fā)送方如何確認數(shù)據(jù)包已經(jīng)丟失 ？

有幾種常見的方案，這里先簡單介紹下，不詳細展開細節(jié)。

1. 停等協(xié)議

發(fā)送方每次只發(fā)送一個包，同時啟動一個定時器。如果定時器超時依然沒有收到這個包的 ACK，則認為丟包，重傳這個包。如果收到 ACK，則重置定時器并發(fā)送下一個包。

問題：丟包的判斷和傳輸效率非常低。

2. 連續(xù) ARQ 協(xié)議 & 滑窗協(xié)議

發(fā)送方維持著一個一定大小的發(fā)送窗口，位于發(fā)送窗口內(nèi)的所有包可以連續(xù)發(fā)送出去，中途不需要依次等待對方的 ACK 確認。

接收方通常采用 積累確認模式，即不必對每一個包逐個發(fā)送 ACK，而是在連續(xù)收到幾個包后，對順序到達的最后一個包序號發(fā)送 ACK，表示：這個包及之前的所有包都已正確收到了。

積累確認模式 的缺點：亂序比較嚴重的網(wǎng)絡(luò)下，效率非常低，部分已經(jīng)送到但沒有按照順序送達的包也必須重傳。

改進方案：選擇性重傳（注：KCP/SRT 協(xié)議有實現(xiàn)）：對于順序的包，發(fā)送積累確認；跳躍的包，發(fā)送 ACK；發(fā)送端只重傳真正丟失的數(shù)據(jù)包。

3. 快速重傳

使用 ACK 機制的傳輸協(xié)議，通常在發(fā)送端等到某個數(shù)據(jù)包的 ACK 超時后，才會重傳數(shù)據(jù)包，不夠及時。

快速重傳：如果接收端接收到了序號跳躍的數(shù)據(jù)包，則立即給發(fā)送方發(fā)送最后一個連續(xù)的數(shù)據(jù)包的 ACK（重復(fù)確認） 。如果發(fā)送端收到連續(xù) 3 個重復(fù)確認，則認為該 ACK 的下一個數(shù)據(jù)包丟失了，并立即重傳該丟失的數(shù)據(jù)包。

4. NACK

接收方定時把所有未收到的包序號通過反饋報文通知到發(fā)送方進行重傳。

帶來的改進：減少的反饋包的頻率和帶寬占用，同時也能比較及時地通知發(fā)送方進行丟包重傳。

問題 3：重傳超時的計算規(guī)則 ？

RTO：重傳超時時間（Retransmission Timeout），它是發(fā)送端用來判斷數(shù)據(jù)包丟失和執(zhí)行重傳的最重要的一個參數(shù)。

很明顯，它應(yīng)該是一個隨網(wǎng)絡(luò)傳輸?shù)?RTT（往返時間）而變化的值，理想情況下，RTO 的值不小于 RTT 即可（從數(shù)據(jù)包發(fā)送到對方的 ACK 到達的最短時間），實際情況下，RTT 變化是非常頻繁的，每一次傳輸?shù)?RTT 可能都不一樣，如果粗暴地設(shè)置 RTO = RTT 則一定會導(dǎo)致重傳過度頻繁。

因此 TCP 協(xié)議采用的 RTO 計算方法是：

1. 基于多次 RTT 測量，給出一個平滑后的 RTT 預(yù)估值：SRTT（Smoothed Round Trip Time）

2. RTO = SRTT + 某種系數(shù)（防止抖動的閾值）

3. 進一步，系統(tǒng)級別設(shè)置 RTO 的下限為 100ms 或 200ms，防止異常值

4. 更進一步，對于重傳包的 RTO，加上一個退避算法，比如，每重傳一次，則 RTO = 2 RTO 這樣的方式來減少對一個包進行頻繁的重傳

注：關(guān)于重傳包 RTO 的退避策略，KCP 經(jīng)過實驗證明 ，RTO 的退避系數(shù)使用 1.5 倍的效果比 2 倍的效果更好。

問題 4：發(fā)送方的數(shù)據(jù)包要緩存多久 ？

發(fā)送端為了能實現(xiàn)重傳，必須在本地將發(fā)送的數(shù)據(jù)包緩存起來，在需要重傳的時候，即可從緩存隊列里面取到該數(shù)據(jù)包進行重傳。

對于 ACK 模型的傳輸協(xié)議（如：TCP），在收到對方的 ACK 之后刪除緩存即可，那如果是 NACK 模型的傳輸協(xié)議，如何更新和清理這個緩存隊列呢 ？

1. 方案一：基于 RTT 和 NACK 時間間隔

假設(shè)當前的 RTT（網(wǎng)絡(luò)往返時間）是  rtt ms，NACK 的反饋時間間隔是 x ms，那么，一個數(shù)據(jù)包在發(fā)送緩存隊列中最少的存活時間應(yīng)該是：

cache time = 2 * rtt + x

假設(shè)在這個時間后內(nèi)收到的 NACK 反饋包沒有指出該數(shù)據(jù)包丟失，則可以刪除了。當然，類似 RTO 所涉及到的問題原因，rtt 是頻繁變化的，因此單純依靠這個理論值來刪除緩存并不安全，建議增加一定的冗余。

2. 方案二：基于業(yè)務(wù)場景

對于實時音視頻通信場景，對延時有一定的要求，因此，超過 1s 的數(shù)據(jù)，就沒有必要再重傳了?；蛘?，假設(shè)視頻的 GOP 是 2s，那么，最多在緩存隊列保持 2s 的數(shù)據(jù)包即可。

問題 5：接收端多久發(fā)送一次 nack 請求 ？

假設(shè)接收端發(fā)現(xiàn)數(shù)據(jù)包發(fā)生序列號跳躍后立即發(fā)送 NACK 請求，由于 UDP 數(shù)據(jù)包可能會亂序到達，因此這種方案會導(dǎo)致過多的無效重傳請求。

更加合理的方案是：每間隔指定的時間（比如：WebRTC 使用的是 10ms）發(fā)送一次 NACK 請求，一次性帶上這段時間所有的丟包序號。

問題 6：哪些丟失的數(shù)據(jù)包會放入 nack 請求隊列中 ？

接收端的重傳請求的隊列也應(yīng)該有一定的機制，不是所有的丟包都必須要求重傳，比如：

1. 當前音頻播放到了 timestamp 為 x 的時間點了，其實在 timestamp < x 的所有丟失的音頻包都不應(yīng)該再請求重傳了，視頻也是如此。

2. 作為 SFU 中轉(zhuǎn)服務(wù)器，它沒有播放時間的概念，因此方法 1 并不適用，但是可以參考發(fā)送端緩存的邏輯，假設(shè) GOP 是 2s，則對比最新的 packet 時間戳，丟失的數(shù)據(jù)包時間在 2s 之前的數(shù)據(jù)，則沒有必要再申請重傳了。

補充一點，作為 SFU 中轉(zhuǎn)服務(wù)器，可能會遇到下述情況，即：收到客戶端的 NACK 請求的數(shù)據(jù)包不再自己的 cached packet list 里面：

SFU 作為客戶端上行的接收端，發(fā)現(xiàn)丟包也跟普通的接收端一樣，定時主動地向源頭發(fā)送 NACK 請求；反過來，SFU 作為客戶端下行的發(fā)送端，收到 NACK 請求后，如果發(fā)現(xiàn)不在 cached list，則標記一下，一旦收到源頭的重傳，則第一時間轉(zhuǎn)發(fā)到下行。

問題 7：如何防止某個數(shù)據(jù)包頻繁的 nack 請求 ？

參考 WebRTC 的實現(xiàn)，有如下防止策略：

1. 當一個丟失的包被 NACK 請求重傳了至少 N 次（如：10次）后依然沒有成功收到，則應(yīng)該放棄了（很可能發(fā)送端也已經(jīng)沒有這個數(shù)據(jù)包的緩存了）

2. 考慮到重傳請求在發(fā)送端的響應(yīng)時間及網(wǎng)絡(luò) RTT，接收端應(yīng)該確保在一定時間周期內(nèi)不要頻繁地發(fā)送對同一個數(shù)據(jù)包的 NACK 重傳請求。（如：WebRTC 選擇的時間周期是 5 + RTT * 1.5），即：在這個時間周期內(nèi)不再重復(fù)發(fā)送同一個數(shù)據(jù)包的 NACK 請求。

3. 當 nack reqeust list 里面的數(shù)據(jù)包太多了（比如：超過 1000），則應(yīng)該考慮清理一下（網(wǎng)絡(luò)太弱了），對于視頻的話，直接發(fā)送 IDR request，重新申請新的 GOP 數(shù)據(jù)。

問題 8：重傳包的優(yōu)先級？FEC 包是否需要重傳 ？

考慮到丟包 -> 重傳已經(jīng)耽誤了數(shù)據(jù)包的達到時間了，因此，重傳包的優(yōu)先級應(yīng)該大于普通的數(shù)據(jù)包，當然，也應(yīng)該有根據(jù)重傳次數(shù)優(yōu)先級逐步遞減的策略。

FEC 包不需要，意義不大，F(xiàn)EC 的目的是為了減少重傳而增加的冗余包，丟掉沒有致命的影響，我們只需要重傳價值更大的數(shù)據(jù)包即可。

問題 9：RTCP 協(xié)議的 NACK 報文是如何定義的 ？

NACK 報文的定義在 [rfc4585] 文檔中定義。

RTCP 的反饋報文包頭定義如下，F(xiàn)MT 和 PT 決定了該報文的類型，F(xiàn)CI 則是該類型報文的具體負載：

協(xié)議規(guī)定的 NACK 反饋報文的 PT= 205，F(xiàn)MT=1，F(xiàn)CI 的格式如下（可以附帶多個 FCI，通過 header 的 length 字段來標示其長度）：

這里的設(shè)計比較巧妙，它可以一次性攜帶多個連續(xù)的數(shù)據(jù)包的丟包情況：

• PID（Packet identifier），即為丟失的 RTP 數(shù)據(jù)包的序列號

• BLP（Bitmao of Lost Packets），通過掩碼的方式指出了接下來 16 個數(shù)據(jù)包的丟失情況

看完上述內(nèi)容，你們對網(wǎng)絡(luò)通信中的ACK、NACK與REX大概了解了嗎？如果想了解更多相關(guān)文章內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！