androidudp丟包

Ⅰ UDP丟包原因總結

發送的包比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速度太慢，導致接收緩沖區滿丟棄數據。前一種問題，可以考慮增大接收緩沖區。後一種問題，可以考慮將接收操作和業務處理操作分離到不同的線程來處理。

Ⅱ ping不丟包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協議傳輸，要麼做丟包重傳的工作。

Ⅲ 引起udp丟包的可能原因是什麼

1，網路環境不好或不通
2，數據可能因處理不過來被沖掉

Ⅳ android開發，UDP發送失敗。ip，埠都沒問題，就send(包)的時候報異常。

解決問題的關鍵：第一，只建立一個socket用來收發數據，每次點擊連接時新建，中間不在新建或close同一埠的socket直到點擊斷開，這樣PC端服務程序解析出的埠就在斷開前不會變了，這可以解決前一段提到的兩個問題。第二，PC端服務程序要具有解析功能，最好用我提供的。順帶提一下，如果同一個埠的socket在沒有close的時候再次新建會出現程序自動退出的現象。

Ⅳ UDP為什麼丟包很嚴重

udp是不可靠協議，意思是說沒有應答重傳機制，這個可以自己上層做一個應答等待和握手。
udp在區域網內，低數據量，是比較可靠的，連續十幾萬包都幾乎不丟包。而且區域網內沒多路由分支路徑，基本能夠保證到達順序的先後。它只有在網路擁堵，數據包太多，接收方處理不過來導致丟失，還有就是交換機處理不過來導致丟包。
udp在長距離，網路跳點太多的網際網路才比較容易丟包。還有一個是包的順序無法保證，因為是多路由分支傳輸過來，在網路環境擁堵和交換機處理轉發延時下，無法確保到達包的先後順序。
udp作為命令的發送，少數據的傳輸，佔用資源更少，更高效，加上廣播機制，比tcp便捷太多了。尤其在一對多的信息傳輸中更有優勢，因為tcp需要佔用連接，同時處理並發數據請求能力有限，一旦終端卡死掉線就必須等待長時間的釋放，也容易出問題。
一般丟包嚴重，首先要確定接收緩存是否溢出，處理數據是否耗時，是否能夠跟上發送方速度。而tcp是跟udp一樣傳輸的，只是加上重傳機制和順序組裝機制，如果udp丟包很嚴重，tcp其實也很低效，幾乎無法用了。所以區域網udp丟包嚴重是網路和緩存程序的問題多。

Ⅵ UDP/TS碼流丟包問題解決思路

在有UDP傳輸視頻的業務，可以從以下角度去思考：

1 網路擁塞。這是很關鍵的原因，開發過程中由於涉及到不同庫/組件的協同開發，往往會把注意力集中到介面層面，而忽視了網路環境本身。視頻業務需要帶寬較寬，調試過程可以單獨組網以及使用千兆交換機。

2 recv-Q。recv-Q是度量socket接收緩沖擁塞情況的一個指標。可以使用netstat -anu 觀察socket介面緩沖的擁塞情況。

3 增加socket緩沖大小。可以修改 /proc/sys/net/core/rmem_default 和/proc/sys/net/core/rmem_max 調整內核默認分配給每個介面的緩沖大小。亦可在調用socket介面時設置緩沖大小，須知用戶設置的緩沖大小不應該比rmem_max大。

4 優化業務流程。UDP接收業務中，若數據處理的速度小於數據接收的速度，則可能造成socket介面緩沖堆積。緩沖滿了，便會丟包。若下游的業務速度無法優化，則可以非同步接收和處理流程，通常是在接收和處理流程之間增加一個緩存。

5 TS流分析工具。可以通過wireshark將需要分析的TS碼流過濾出來，右鍵Follow選UDP，show and save data as raw，把TS碼流保存下來，可以在VLC上播放。可以把TS碼流 文件拖到Elecard StreamAnalyzer 工具，點擊Report按鈕，即可分析TS碼流丟包情況。

Ⅶ udp丟包率多少為正常

百分之5。根據相關公開信息查詢：各個國家網路平均速率由1.5Mbps提升為5.1Mbps，網速提升近4倍。網路環境變好，網路傳輸的延遲、穩定性也隨之改善，UDP的丟包率低於百分之5。丟包率是指測試中所丟失數據包數量占所發送數據組的比率，丟包率與數據包長度以及包發送頻率相關。

Ⅷ android udp接收不到數據

1、可先在oncreate()方法裡面實例化一個WifiManager.MulticastLock 對象lock；具體如下：
WifiManager manager = (WifiManager) this
.getSystemService(Context.WIFI_SERVICE);
WifiManager.MulticastLock lock= manager.createMulticastLock("test wifi");

2、在調用廣播發送、接收報文之前先調用lock.acquire()方法；
3、用完之後及時調用lock.release()釋放資源，否決多次調用lock.acquire()方法，程序可能會崩，詳情請見
Caused by: java.lang.UnsupportedOperationException: Exceeded maximum number of wifi locks
注；記得在配置文件裡面添加如下許可權：
<uses-permission android:name="android.permission.CHANGE_WIFI_MULTICAST_STATE" />

經過這樣處理後，多數手機都能正常發送接收到廣播報文。
本小點轉載自Android手機接收不到UDP報文
二、在UDP通信中，android端發送UDP廣播包沒有問題。至於接收的話，有時候不能接收到包。
在UDP通信中，android端發送UDP廣播包沒有問題。至於接收的話，有時候不能接收到包。但是如果UDP包中指定了目標主機的地址的話，那麼android端就能正常接收。
下面上一段代碼，大家可用這段代碼進行測試。
1、在一個Service裡面，我們創建一個線程

public void onCreate() {//用於創建線程
WifiManager manager = (WifiManager) this
.getSystemService(Context.WIFI_SERVICE);
udphelper = new UdpHelper(manager);

//傳遞WifiManager對象，以便在UDPHelper類裡面使用MulticastLock
udphelper.addObserver(MsgReceiveService.this);
tReceived = new Thread(udphelper);
tReceived.start();
super.onCreate();
}

2、弄一個UDP幫助類，這個類主要用於發送和接收數據

package com.example.com.ihome.bang.util;

import java.io.IOException;
import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetAddress;
import java.net.MulticastSocket;
import java.net.SocketException;
import java.net.UnknownHostException;
import java.util.Observable;
import com.example.com.ihome.bang.tool.SendThread;
import android.net.wifi.WifiManager;
import android.util.Log;

/**
*
* UdpHelper幫助類
*
* @author 陳喆榕
*
*/
public class UdpHelper implements Runnable {
public Boolean IsThreadDisable = false;//指示監聽線程是否終止
private static WifiManager.MulticastLock lock;
InetAddress mInetAddress;
public UdpHelper(WifiManager manager) {
this.lock= manager.createMulticastLock("UDPwifi");
}
public void StartListen() {
// UDP伺服器監聽的埠
Integer port = 8903;
// 接收的位元組大小，客戶端發送的數據不能超過這個大小
byte[] message = new byte[100];
try {
// 建立Socket連接
DatagramSocket datagramSocket = new DatagramSocket(port);
datagramSocket.setBroadcast(true);
DatagramPacket datagramPacket = new DatagramPacket(message,
message.length);
try {
while (!IsThreadDisable) {
// 准備接收數據
Log.d("UDP Demo", "准備接受");
this.lock.acquire();

datagramSocket.receive(datagramPacket);
String strMsg=new String(datagramPacket.getData()).trim();
Log.d("UDP Demo", datagramPacket.getAddress()
.getHostAddress().toString()
+ ":" +strMsg );this.lock.release();
}
} catch (IOException e) {//IOException
e.printStackTrace();
}
} catch (SocketException e) {
e.printStackTrace();
}

}
public static void send(String message) {
message = (message == null ? "Hello IdeasAndroid!" : message);
int server_port = 8904;
Log.d("UDP Demo", "UDP發送數據:"+message);
DatagramSocket s = null;
try {
s = new DatagramSocket();
} catch (SocketException e) {
e.printStackTrace();
}
InetAddress local = null;
try {
local = InetAddress.getByName("255.255.255.255");
} catch (UnknownHostException e) {
e.printStackTrace();
}
int msg_length = message.length();
byte[] messageByte = message.getBytes();
DatagramPacket p = new DatagramPacket(messageByte, msg_length, local,
server_port);
try {

s.send(p);
s.close();

} catch (IOException e) {
e.printStackTrace();
}
}

@Override
public void run() {
StartListen();
}
}

希望能幫到你。

Ⅸ 如何測試UDP數據包的丟包率和延遲

iperf也可以用於UDP數據包吞吐量、丟包率和延遲指標，但是由於UDP協議是一個非面向連接的輕量級傳輸協議，並且不提供可靠的數據傳輸服務，因此對UDP應用的關注點不是傳輸數據有多快，而是它的丟包率和延時指標。通過iperf的「-u」參數即可測試UDP應用的傳輸性能，下圖測試的是在iperf客戶端傳輸100MB的UDP數據包的輸出結果：

iperf服務端顯示的UDP傳輸狀態

在這個輸出中，詳細記錄了在傳輸過程中，每個階段的傳輸延時和丟包率，在UDP應用中隨著傳輸數據的增大，丟包率和延時也隨之增加。對於延時和丟包可以通過改變應用程序來緩解或修復，例如視頻流應用，可以通過緩存數據的方式而可以容忍更大的延時。

Ⅹ android接收不到udp包嗎

1、有的手機不能直接接收UDP包，可能是手機廠商在定製Rom的時候把這個功能給關掉了。
2、在UDP通信中，android端發送UDP廣播包沒有問題。至於接收的話，有時候不能接收到包。