轉(zhuǎn)自：

自己在做UDP傳輸時(shí)遇到的問題，接收端沒設(shè)置緩存，結(jié)果總是丟包。

看到這篇文章設(shè)置了一下接收緩存就好 int nRecvBuf=32*1024;//設(shè)置為32K setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int)); http://www.cnweblog.com/fly2700/archive/2011/09/19/317825.html

什么會(huì)導(dǎo)致udp丟包呢，我這里列舉了如下幾點(diǎn)原因：

1.調(diào)用recv方法接收端收到數(shù)據(jù)后，處理數(shù)據(jù)花了一些時(shí)間，處理完后再次調(diào)用recv方法，在這二次調(diào)用間隔里,發(fā)過來的包可能丟失。對(duì)于這種情況可以修改接收端，將包接收后存入一個(gè)緩沖區(qū)，然后迅速返回繼續(xù)recv。
2.發(fā)送的包巨大丟包。雖然send方法會(huì)幫你做大包切割成小包發(fā)送的事情，但包太大也不行。例如超過30K的一個(gè)udp包，不切割直接通過send方法發(fā)送也會(huì)導(dǎo)致這個(gè)包丟失。這種情況需要切割成小包再逐個(gè)send。
3.發(fā)送的包較大，超過mtu size數(shù)倍，幾個(gè)大的udp包可能會(huì)超過接收者的緩沖，導(dǎo)致丟包。這種情況可以設(shè)置socket接收緩沖。以前遇到過這種問題，我把接收緩沖設(shè)置成64K就解決了。
int nRecvBuf=32*1024;//設(shè)置為32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
4.發(fā)送的包頻率太快，雖然每個(gè)包的大小都小于mtu size 但是頻率太快，例如40多個(gè)mut size的包連續(xù)發(fā)送中間不sleep，也有可能導(dǎo)致丟包。這種情況也有時(shí)可以通過設(shè)置socket接收緩沖解決，但有時(shí)解決不了。
5.發(fā)送的廣播包或組播包在windws和Linux下都接收正常，而arm上接收出現(xiàn)丟包。這個(gè)還不好解決，我的解決方法是大包切割成大小為1448的小包發(fā)送，每個(gè)包之間sleep 1毫秒，雖然笨，但有效。我這里mtu size為1500字節(jié)，減去udp包頭8個(gè)字節(jié)，減去傳輸層幾十個(gè)字節(jié)，實(shí)際數(shù)據(jù)位1448字節(jié)。
除此之外還可以試試設(shè)置arm操作系統(tǒng)緩沖：
//設(shè)置mtu size 1500最大
ifconfig eth0 mtu 1500
//查看接收緩沖最大和默認(rèn)大小。
sysctl -A | grep rmem
//設(shè)置接收緩沖的最大大小
sysctl -w net.core.rmem_max=1048576
sysctl -w net.core.rmem_default=1048576
sysctl -w net.ipv4.udp_mem=1048576
sysctl -w net.ipv4.udp_rmem_min=1048576
6,局域網(wǎng)內(nèi)不丟包，公網(wǎng)上丟包。這個(gè)問題我也是通過切割小包并sleep發(fā)送解決的。如果流量太大，這個(gè)辦法也不靈了。

總之udp丟包總是會(huì)有的，如果出現(xiàn)了用我的方法解決不了，還有這個(gè)幾個(gè)方法： 要么減小流量，要么換tcp協(xié)議傳輸，要么做丟包重傳的工作。

轉(zhuǎn)載于:https://www.cnblogs.com/yorkyang/p/7384310.html

總結(jié)

以上是生活随笔為你收集整理的udp丢包 处理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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