UDP丟包及無序的問題

2021-07-23 14:57:07 字數 1683 閱讀 5080

最近在做乙個專案,在這之前,做了個驗證程式.

發現客戶端連續發來1000個1024位元組的包,伺服器端出現了丟包現象.

糾其原因,是服務端在還未完全處理掉資料,客戶端已經資料傳送完畢且關閉了.

有沒有成熟的解決方案來解決這個問題.

我用過sleep(1),暫時解決這個問題,但是這不是根本解決辦法,如果資料量大而多,網路情況不太好的話,還是有可能丟失.

你試著用阻塞模式吧...

select...我開始的時候好像也遇到過..不過改為阻塞模式後就沒這個問題了...

採用回包機制,每個發包必須收到回包後再發下乙個

udp丟包是正常現象,因為它是不安全的。

丟包的原因我想並不是「服務端在還未完全處理掉資料,客戶端已經資料傳送完畢且關閉了」,而是伺服器端的socket接收快取滿了(udp沒有流量控制,因此傳送速度比接收速度快,很容易出現這種情況),然後系統就會將後來收到的包丟棄。你可以嘗試用setsockopt()將接收快取(so_rcvbuf)加大看看能不能解決問題。

服務端採用多執行緒pthread接包處理

udp是無連線的,面向訊息的資料傳輸協議,與tcp相比,有兩個致命的缺點,一是資料報容易丟失,二是資料報無序。

要實現檔案的可靠傳輸,就必須在上層對資料丟包和亂序作特殊處理,必須要有要有丟包重發機制和超時機制。

常見的可靠傳輸演算法有模擬tcp協議,重發請求(arq)協議,它又可分為連續arq協議、選擇重發arq協議、滑動視窗協議等等。

如果只是小規模程式,也可以自己實現丟包處理,原理基本上就是給檔案分塊,每個資料報的頭部新增乙個唯一標識序號的id值,當接收的包頭部id不是期望中的id號,則判定丟包,將丟包id發回服務端,伺服器端接到丟包響應則重發丟失的資料報。

模擬tcp協議也相對簡單,3次握手的思想對丟包處理很有幫助。

udp是不安全的,如果不加任何控制,不僅會丟失包,還可能收到包的順序和傳送包的順序不一樣。這個必須在自己程式中加以控制才行。

收到包後,要返回乙個應答,如果傳送端在一定時間內沒有收到應答,則要重發。

udp本來存在丟包現象,現在的解決方案暫時考慮雙方增加握手.

這樣做起來,就是udp協議裡面加上了tcp的實現方法.

程式中採用的是pthread處理,丟包率時大時小,不穩定可靠

我感覺原因可能有兩個,乙個是客戶端傳送過快,網路狀況不好或者超過伺服器接收速度,就會丟包。

第二個原因是伺服器收到包後,還要進行一些處理,而這段時間客戶端傳送的包沒有去收,造成丟包。

解決方法,乙個是客戶端降低傳送速度,可以等待回包,或者加一些延遲。

二是,伺服器部分單獨開乙個執行緒,去接收udp資料,存放在乙個緩衝區中,又另外的執行緒去處理收到的資料,儘量減少因為處理資料延時造成的丟包。

有兩種方法解決樓主的問題:

方法一:重新設計一下協議,增加接收確認超時重發。(推薦)

方法二:在接收方,將通訊和處理分開,增加個應用緩衝區;如果有需要增加接收socket的系統緩衝區。(本方法不能從根本解決問題,只能改善)

網路丟包,是再正常不過的了。

既然用udp,就要接受丟包的現實,否則請用tcp。

如果必須使用udp,而且丟包又是不能接受的,只好自己實現確認和重傳,說白了,就是自己實現tcp(當然是部分和有限的簡單實現)。

udp是而向無連線的,使用者在實施udp程式設計時,必須制定上層的協議,包括流控制,簡單的超時和重傳機制,如果不要求是實時資料,我想tcp可能會更適合你!

來自:

UDP丟包及無序的現象

發現客戶端連續發來1000個1024位元組的包,伺服器端出現了丟包現象.糾其原因,是服務端在還未完全處理掉資料,客戶端已經資料傳送完畢且關閉了.有沒有成熟的解決方案來解決這個問題.我用過sleep 1 暫時解決這個問題,但是這不是根本解決辦法,如果資料量大而多,網路情況不太好的話,還是有可能丟失.你...

UDP丟包和無序 問題的解決方法

最近在做乙個專案,在這之前,做了個驗證程式.發現客戶端連續發來1000個1024位元組的包,伺服器端出現了丟包現象.糾其原因,是服務端在還未完全處理掉資料,客戶端已經資料傳送完畢且關閉了.我用過sleep 10 暫時解決這個問題,但是這不是根本解決辦法,如果資料量大而多,網路情況不太好的話,還是有可...

UDP丟包原因

一 主要丟包原因 1 接收端處理時間過長導致丟包 呼叫recv方法接收端收到資料後,處理資料花了一些時間,處理完後再次呼叫recv方法,在這二次呼叫間隔裡,發過來的包可能丟失。對於這種情況可以修改接收端,將包接收後存入乙個緩衝區,然後迅速返回繼續recv。2 傳送的包巨大丟包 雖然send方法會幫你...