UDP資料包問題，UDP丟包原因總結

1樓：匿名使用者

不好意思搞錯了 360裡是防止arp攻擊在即時保護那裡。

udp丟包原因總結

2樓：新酷數碼

傳送的包比64k大會導致udp協議sendto返回錯誤。

傳送的包比mtu大，udp包在接收端容易丟包，可檢視接收端的網絡卡統計。可考慮把包切分到mtu一下再傳送。

發包速度太快的話，可能有兩個問題：1.接收端來不及接收導致接收端丟包。

2.傳送端網絡卡處理不過來。這個時候sendto沒有返回錯誤，但是用netstat檢視會發現sndbuferrors不斷上公升，有可能是網絡卡的輸出佇列太小導致。

可以考慮使用ifconfig命令把txqueuelen設定大一些。

同乙個襲掘巧埠傳送的資料量太大時會導致網絡卡丟包，拍鍵這個時候可以用netstat檢視會發現sndbuferrors不斷上公升。sendto會返回-1.這個時候可以考慮增大/proc/sys/net/core/wmem_max的值。

這種情況尤其是同時給多個客戶端傳送音**資料時導致。筆者曾經遇到過這麼一次情況。乙個埠向8個客戶端傳送**流時，網絡卡散巖流量大概400m/s，sendto會返回-1，errno 11.

程式裡也呼叫setsockopt設定了傳送緩衝區為60m，然而還是會丟包。後來將系統引數/proc/sys/net/core/wmem_max設到60m才解決問題。

接收緩衝區小於傳送客戶端的包的大小，或者接收客戶端recvfrom速度太慢，導致接收緩衝區滿丟棄資料。前一種問題，可以考慮增大接收緩衝區。後一種問題，可以考慮將接收操作和業務處理操作分離到不同的執行緒來處理。

4.udp協議

3樓：一襲可愛風

使用者資料包協議 udp 只在 ip 的資料包服務之上增加了很少一點的功能，這就是複用和分用的功能以及查錯檢測的功能。

某些即時應用需要使用沒有擁塞控制的 udp，但很多的源主機同時都向網路傳送高速率的即時**流時，網路就有可能發生擁塞，導致大家都無法正常接收。

還有一些使用 udp 的即時應用，需要對 udp 的不可靠傳輸進行適當的改進，以減少資料的丟失。應用程序可以在不影響應用的即時性的前提下，增加一些提高可靠性的措施，如採用前向糾錯或重傳已丟失的報文。

udp 的首部格式。

使用者資料包 udp 有兩個欄位：資料欄位和首部欄位。首部欄位很簡單，只有8個位元組，由四個欄位組成，每個欄位都是兩個位元組。

源埠源埠號。在需要對方回信時。不需要時可用全0

目的埠目的埠號。這在終點交付報文時必須使用。

長度udp 使用者資料包的長度，其最小值是8(僅有首部)

檢驗和檢測 udp 使用者資料包在傳輸中是否有錯。有錯就丟棄。

當運輸層從 ip 層收到 udp 資料包時，就根據首部中的目的埠，把 udp 資料包通過相應的埠，上交最後的終點——應用程序。

如果接受方 udp 發現收到的報文中的目的埠號不正確(即不存在對應於該埠號的應用程式)，就丟棄該報文，並由網際控制報文協議 icmp 傳送「埠不可達」差錯報文給傳送方。

udp 使用者資料包首部中檢驗和的計算方法有些特殊。在計算檢驗和時，要在 udp 使用者資料包之前增加 12 個位元組的偽首部。所謂「偽首部」是因為這種偽首部並不是 udp 使用者資料包真正的首部。

只是在計算檢驗和時，臨時新增在 udp 使用者資料包前面，得到乙個臨時的 udp 使用者資料包。檢驗和就是按照這個臨時使用者資料包來計算的。偽首部既不向下傳也不向上遞交，而僅僅是為了計算檢驗和檢測。