1. 從發送端解決(推薦)

適用條件: ①發送端是可以控制的.②微秒數量級的延遲可以接受

解決方法:發送時使用usleep(1)延遲1微秒發送,即發送頻率不要過快,延遲1微妙發送,可以很好的解決這個問題.。

2.從接收端解決方法一

適用條件:①無法控制發送端發送數據的頻率

解決方法: 用recvfrom函數收到數據之后盡快返回,進行下一次recvfrom,可以通過多線程+隊列來解決.收到數據之后將數據放入隊列中,另起一個線程去處理收到的數據；可以總結為服務器程序啟動之出，接收端開辟兩個線程，一個線程專門用于接收數據包，并存放在應用層的緩存區；另外一個線程用于專門處理和響應數據包請求，避免因為處理數據造成數據丟包。其本質上還是增大了緩沖區大小，只是將系統緩沖區轉移到了自己的緩沖區。

3.從接收端解決方法二

適用條件:①使用方法2依然出現大規模丟包的情況,需要進一步優化

解決方法:使用setsockopt修改接收端的緩沖區大小。

4.最復雜的方式

在應用層實現丟包重發機制和超時機制，確保數據包不丟失。

NACK機制

說到丟包重傳就不得不提到NACK技術，那么NACK是什么呢。它的全稱是Negative Acknowledgment Packet，意思是否定確認包，說到這里我們應該可以聯想到ACK（Acknowledgment Packet，確認包）。沒錯，二者的意思是相反的。ACK表示通知對方我收到了你發給我的數據包，NACK表示通知對方我沒有收到你發給我的數據包。

那么問題來了，為什么會導致對方明明發送了響應的數據包，而我沒有收到呢？其中的原因有很多，比如網絡問題，因為中間路由器轉發丟失，延時較大導致被NACK（可能數據包還在傳輸中，只是到達時間比較久）等。

基于上述原因，NACK的存在是非常有必要的。它能夠及時的通知發送端重傳相應的數據包，保證接收端音頻和視頻的正常播放。NACK其實是RTCP包的一種，用來是對 RTP 數據傳輸層進行反饋，它包類型是?205。

前向糾錯機制FEC

在每個數據包中，您將添加一些關于前一個信息的信息，以防丟失，您需要重新構建它們（flexfec是WebRTC [1]中的新格式）。

顧名思義，FEC前向糾錯，根據收到的包進行計算獲取丟掉的包，而和大神溝通的結果就是 糾錯神髓：收到的媒體包+冗余包 >= 原始媒體包數據?

直到滿足?收到的媒體包+?冗余包 >= 原始媒體包數據 ? ? ? 則進入恢復模式，恢復出2?4，然后一次輸出2?3?4?5

?

所謂的Qos，也可以理解為抖動緩沖，解決udp包亂序、包重復的問題

NAT保活，保持udp連接，簡言之：

當你向一個公網服務器發送數據時，服務器可以翻轉IP和端口向你發數據，?但如果你長時間不發數據給服務器，服務器若想用之前的IP和端口向你發就不一定成功了。因為在路由器上的NAT映射可能已經失效，如果你是一直向服務器發送數據，那就不存在這個問題。

FEC的設計理念大多一樣，編碼/解碼/回調函數：

1.encode,不區分輸入內容,編碼后輸出輸出冗余包數據；

2.decode,根據輸入數據進行糾錯,如果數據不是有序，則等待 ?(收到的媒體包+冗余包 >= 原始媒體包數據) 輸出原數據

3.callback,一包一包數據輸出,阻塞接口

?

總結

以上是生活随笔為你收集整理的【技术解决方案】RTP_UDP传输过程中数据丢失的解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。