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

適用條件: ①發(fā)送端是可以控制的.②微秒數(shù)量級(jí)的延遲可以接受

解決方法:發(fā)送時(shí)使用usleep(1)延遲1微秒發(fā)送,即發(fā)送頻率不要過(guò)快,延遲1微妙發(fā)送,可以很好的解決這個(gè)問(wèn)題.。

2.從接收端解決方法一

適用條件:①無(wú)法控制發(fā)送端發(fā)送數(shù)據(jù)的頻率

解決方法: 用recvfrom函數(shù)收到數(shù)據(jù)之后盡快返回,進(jìn)行下一次recvfrom,可以通過(guò)多線程+隊(duì)列來(lái)解決.收到數(shù)據(jù)之后將數(shù)據(jù)放入隊(duì)列中,另起一個(gè)線程去處理收到的數(shù)據(jù)；可以總結(jié)為服務(wù)器程序啟動(dòng)之出，接收端開(kāi)辟兩個(gè)線程，一個(gè)線程專門用于接收數(shù)據(jù)包，并存放在應(yīng)用層的緩存區(qū)；另外一個(gè)線程用于專門處理和響應(yīng)數(shù)據(jù)包請(qǐng)求，避免因?yàn)樘幚頂?shù)據(jù)造成數(shù)據(jù)丟包。其本質(zhì)上還是增大了緩沖區(qū)大小，只是將系統(tǒng)緩沖區(qū)轉(zhuǎn)移到了自己的緩沖區(qū)。

3.從接收端解決方法二

適用條件:①使用方法2依然出現(xiàn)大規(guī)模丟包的情況,需要進(jìn)一步優(yōu)化

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

4.最復(fù)雜的方式

在應(yīng)用層實(shí)現(xiàn)丟包重發(fā)機(jī)制和超時(shí)機(jī)制，確保數(shù)據(jù)包不丟失。

NACK機(jī)制

說(shuō)到丟包重傳就不得不提到NACK技術(shù)，那么NACK是什么呢。它的全稱是Negative Acknowledgment Packet，意思是否定確認(rèn)包，說(shuō)到這里我們應(yīng)該可以聯(lián)想到ACK（Acknowledgment Packet，確認(rèn)包）。沒(méi)錯(cuò)，二者的意思是相反的。ACK表示通知對(duì)方我收到了你發(fā)給我的數(shù)據(jù)包，NACK表示通知對(duì)方我沒(méi)有收到你發(fā)給我的數(shù)據(jù)包。

那么問(wèn)題來(lái)了，為什么會(huì)導(dǎo)致對(duì)方明明發(fā)送了響應(yīng)的數(shù)據(jù)包，而我沒(méi)有收到呢？其中的原因有很多，比如網(wǎng)絡(luò)問(wèn)題，因?yàn)橹虚g路由器轉(zhuǎn)發(fā)丟失，延時(shí)較大導(dǎo)致被NACK（可能數(shù)據(jù)包還在傳輸中，只是到達(dá)時(shí)間比較久）等。

基于上述原因，NACK的存在是非常有必要的。它能夠及時(shí)的通知發(fā)送端重傳相應(yīng)的數(shù)據(jù)包，保證接收端音頻和視頻的正常播放。NACK其實(shí)是RTCP包的一種，用來(lái)是對(duì) RTP 數(shù)據(jù)傳輸層進(jìn)行反饋，它包類型是?205。

前向糾錯(cuò)機(jī)制FEC

在每個(gè)數(shù)據(jù)包中，您將添加一些關(guān)于前一個(gè)信息的信息，以防丟失，您需要重新構(gòu)建它們（flexfec是WebRTC [1]中的新格式）。

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

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

?

所謂的Qos，也可以理解為抖動(dòng)緩沖，解決udp包亂序、包重復(fù)的問(wèn)題

NAT保活，保持udp連接，簡(jiǎn)言之：

當(dāng)你向一個(gè)公網(wǎng)服務(wù)器發(fā)送數(shù)據(jù)時(shí)，服務(wù)器可以翻轉(zhuǎn)IP和端口向你發(fā)數(shù)據(jù)，?但如果你長(zhǎng)時(shí)間不發(fā)數(shù)據(jù)給服務(wù)器，服務(wù)器若想用之前的IP和端口向你發(fā)就不一定成功了。因?yàn)樵诼酚善魃系腘AT映射可能已經(jīng)失效，如果你是一直向服務(wù)器發(fā)送數(shù)據(jù)，那就不存在這個(gè)問(wèn)題。

FEC的設(shè)計(jì)理念大多一樣，編碼/解碼/回調(diào)函數(shù)：

1.encode,不區(qū)分輸入內(nèi)容,編碼后輸出輸出冗余包數(shù)據(jù)；

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

3.callback,一包一包數(shù)據(jù)輸出,阻塞接口

?

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。