UDP丟包原因

一、主要丟包原因

1、接收端處理時間過長導致丟包：呼叫recv方法接收端收到資料後，處理資料花了一些時間，處理完後再次呼叫recv方法，在這二次呼叫間隔裡,發過來的包可能丟失。對於這種情況可以修改接收端，將包接收後存入乙個緩衝區，然後迅速返回繼續recv。

2、傳送的包巨大丟包：雖然send方法會幫你做大包切割成小包傳送的事情，但包太大也不行。例如超過50k的乙個udp包，不切割直接通過send方法傳送也會導致這個包丟失。這種情況需要切割成小包再逐個send。

3、傳送的包較大，超過接受者快取導致丟包：包超過mtu size數倍，幾個大的udp包可能會超過接收者的緩衝，導致丟包。這種情況可以設定socket接收緩衝。以前遇到過這種問題，我把接收緩衝設定成64k就解決了。

int nrecvbuf=32*1024;//設定為32k

setsockopt(s,sol_socket,so_rcvbuf,(const char*)&nrecvbuf,sizeof(int));

4、傳送的包頻率太快：雖然每個包的大小都小於mtu size 但是頻率太快，例如40多個mut size的包連續傳送中間不sleep，也有可能導致丟包。這種情況也有時可以通過設定socket接收緩衝解決，但有時解決不了。所以在傳送頻率過快的時候還是考慮sleep一下吧。

5、區域網內不丟包，公網上丟包。這個問題我也是通過切割小包並sleep傳送解決的。如果流量太大，這個辦法也不靈了。總之udp丟包總是會有的，如果出現了用我的方法解決不了，還有這個幾個方法：要麼減小流量，要麼換tcp協議傳輸，要麼做丟包重傳的工作。

二、具體問題分析

1.傳送頻率過高導致丟包

很多人會不理解傳送速度過快為什麼會產生丟包，原因就是udp的sendto不會造成執行緒阻塞，也就是說，udp的sentto不會像tcp中的sendto那樣，直到資料完全傳送才會return**用函式，它不保證當執行下一條語句時資料是否被傳送。（sendto方法是非同步的）這樣，如果要傳送的資料過多或者過大，那麼在緩衝區滿的那個瞬間要傳送的報文就很有可能被丟失。至於對「過快」的解釋，作者這樣說：「a few packets a second are not an issue; hundreds or thousands may be an issue.」（一秒鐘幾個資料報不算什麼，但是一秒鐘成百上千的資料報就不好辦了）。要解決接收方丟包的問題很簡單，首先要保證程式執行後馬上開始監聽（如果資料報不確定什麼時候發過來的話），其次，要在收到乙個資料報後最短的時間內重新回到監聽狀態，其間要盡量避免複雜的操作（比較好的解決辦法是使用多執行緒**機制）。

2.報文過大丟包

至於報文過大的問題，可以通過控制報文大小來解決，使得每個報文的長度小於mtu。乙太網的mtu通常是1500 bytes，其他一些諸如撥號連線的網路mtu值為1280 bytes，如果使用speaking這樣很難得到mtu的網路，那麼最好將報文長度控制在1280 bytes以下。

3.傳送方丟包

傳送方丟包：內部緩衝區（internal buffers）已滿，並且傳送速度過快（即傳送兩個報文之間的間隔過短）；接收方丟包：socket未開始監聽；雖然udp的報文長度最大可以達到64 kb，但是當報文過大時，穩定性會大大減弱。這是因為當報文過大時會被分割，使得每個分割塊（翻譯可能有誤差，原文是fragmentation）的長度小於mtu，然後分別傳送，並在接收方重新組合（reassemble），但是如果其中乙個報文丟失，那麼其他已收到的報文都無法返回給程式，也就無法得到完整的資料了。

UDP丟包原因

udp丟包原因分析及總結

linux系統核心UDP丟包原因分析

Linux系統核心UDP丟包原因分析

UDP丟包原因

udp丟包原因分析及總結

linux系統核心UDP丟包原因分析

Linux系統核心UDP丟包原因分析

相關推薦