linuxudp接收数据
vi /etc/sysctl.conf
增加或修改 net.ipv4.udp_mem项
net.ipv4.udp_mem = min pressure max
再设一下 net.ipv4.udp_rmem_min
具体含义man udp 查看
完成后执行 sysctl -p 生效
Ⅱ 在Linux 上，编写一个每秒接收 100万UDP数据包的程序究竟有多难
首先，我们假设：
测量每秒的数据包(pps)比测量每秒字节数(Bps)更有意思。您可以通过更好的管道输送以及发送更长数据包来获取更高的Bps。而相比之下，提高pps要困难得多。
因为我们对pps感兴趣，我们的实验将使用较短的 UDP 消息。准确来说是 32 字节的 UDP 负载，这相当于以太网层的 74 字节。
在实验中，我们将使用两个物理服务器：“接收器”和“发送器”。
它们都有两个六核2 GHz的 Xeon处理器。每个服务器都启用了 24 个处理器的超线程(HT)，有 Solarflare 的 10G 多队列网卡，有 11 个接收队列配置。稍后将详细介绍。
测试程序的源代码分别是：udpsender、udpreceiver。
预备知识
我们使用4321作为UDP数据包的端口，在开始之前，我们必须确保传输不会被iptables干扰：
Shell
receiver$ iptables -I INPUT 1 -p udp --dport 4321 -j ACCEPT
receiver$ iptables -t raw -I PREROUTING 1 -p udp --dport 4321 -j NOTRACK
为了后面测试方便，我们显式地定义IP地址：
Shell
receiver$ for i in `seq 1 20`; do
ip addr add 192.168.254.$i/24 dev eth2;
done
sender$ ip addr add 192.168.254.30/24 dev eth3
1. 简单的方法
开始我们做一些最简单的试验。通过简单地发送和接收，有多少包将会被传送？
模拟发送者的伪代码：
Python
fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
fd.bind(("0.0.0.0", 65400)) # select source port to rece nondeterminism
fd.connect(("192.168.254.1", 4321))
while True:
fd.sendmmsg(["x00" * 32] * 1024)
因为我们使用了常见的系统调用的send，所以效率不会很高。上下文切换到内核代价很高所以最好避免它。幸运地是，最近Linux加入了一个方便的系统调用叫sendmmsg。它允许我们在一次调用时，发送很多的数据包。那我们就一次发1024个数据包。
模拟接受者的伪代码：
Python
fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
fd.bind(("0.0.0.0", 4321))
while True:
packets = [None] * 1024
fd.recvmmsg(packets, MSG_WAITFORONE)
同样地，recvmmsg 也是相对于常见的 recv 更有效的一版系统调用。
让我们试试吧：
Shell
sender$ ./udpsender 192.168.254.1:4321
receiver$ ./udpreceiver1 0.0.0.0:4321
0.352M pps 10.730MiB / 90.010Mb
0.284M pps 8.655MiB / 72.603Mb
0.262M pps 7.991MiB / 67.033Mb
0.199M pps 6.081MiB / 51.013Mb
0.195M pps 5.956MiB / 49.966Mb
0.199M pps 6.060MiB / 50.836Mb
0.200M pps 6.097MiB / 51.147Mb
0.197M pps 6.021MiB / 50.509Mb
测试发现，运用最简单的方式可以实现 197k – 350k pps。看起来还不错嘛，但不幸的是，很不稳定啊，这是因为内核在核之间交换我们的程序，那我们把进程附在 CPU 上将会有所帮助
Shell
sender$ taskset -c 1 ./udpsender 192.168.254.1:4321
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.362M pps 11.058MiB / 92.760Mb
0.374M pps 11.411MiB / 95.723Mb
0.369M pps 11.252MiB / 94.389Mb
0.370M pps 11.289MiB / 94.696Mb
0.365M pps 11.152MiB / 93.552Mb
0.360M pps 10.971MiB / 92.033Mb
现在内核调度器将进程运行在特定的CPU上，这提高了处理器缓存，使数据更加一致，这就是我们想要的啊！
2. 发送更多的数据包
虽然 370k pps 对于简单的程序来说已经很不错了，但是离我们 1Mpps 的目标还有些距离。为了接收更多，首先我们必须发送更多的包。那我们用独立的两个线程发送，如何呢：
Shell
sender$ taskset -c 1,2 ./udpsender
192.168.254.1:4321 192.168.254.1:4321
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.349M pps 10.651MiB / 89.343Mb
0.354M pps 10.815MiB / 90.724Mb
0.354M pps 10.806MiB / 90.646Mb
0.354M pps 10.811MiB / 90.690Mb
接收一端的数据没有增加，ethtool –S 命令将显示数据包实际上都去哪儿了：
Shell
receiver$ watch 'sudo ethtool -S eth2 |grep rx'
rx_nodesc_drop_cnt: 451.3k/s
rx-0.rx_packets: 8.0/s
rx-1.rx_packets: 0.0/s
rx-2.rx_packets: 0.0/s
rx-3.rx_packets: 0.5/s
rx-4.rx_packets: 355.2k/s
rx-5.rx_packets: 0.0/s
rx-6.rx_packets: 0.0/s
rx-7.rx_packets: 0.5/s
rx-8.rx_packets: 0.0/s
rx-9.rx_packets: 0.0/s
rx-10.rx_packets: 0.0/s
通过这些统计，NIC 显示 4 号 RX 队列已经成功地传输大约 350Kpps。rx_nodesc_drop_cnt 是 Solarflare 特有的计数器，表明NIC发送到内核未能实现发送 450kpps。
有时候，这些数据包没有被发送的原因不是很清晰，然而在我们这种情境下却很清楚：4号RX队列发送数据包到4号CPU，然而4号CPU已经忙不过来了，因为它最忙也只能读350kpps。在htop中显示为：
多队列 NIC 速成课程
从历史上看，网卡拥有单个RX队列，用于硬件和内核之间传递数据包。这样的设计有一个明显的限制，就是不可能比单个CPU处理更多的数据包。
为了利用多核系统，NIC开始支持多个RX队列。这种设计很简单：每个RX队列被附到分开的CPU上，因此，把包送到所有的RX队列网卡可以利用所有的CPU。但是又产生了另一个问题：对于一个数据包，NIC怎么决定把它发送到哪一个RX队列？
用 Round-robin 的方式来平衡是不能接受的，因为这有可能导致单个连接中数据包的重排序。另一种方法是使用数据包的hash值来决定RX号码。Hash值通常由一个元组（源IP，目标IP，源port，目标port）计算而来。这确保了从一个流产生的包将最终在完全相同的RX队列，并且不可能在一个流中重排包。
在我们的例子中，hash值可能是这样的：
Shell
1
RX_queue_number = hash('192.168.254.30', '192.168.254.1', 65400, 4321) % number_of_queues
多队列 hash 算法
Hash算法通过ethtool配置，设置如下：
Shell
receiver$ ethtool -n eth2 rx-flow-hash udp4
UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
对于IPv4 UDP数据包，NIC将hash(源 IP,目标 IP)地址。即
Shell
1
RX_queue_number = hash('192.168.254.30', '192.168.254.1') % number_of_queues
这是相当有限的，因为它忽略了端口号。很多NIC允许自定义hash。再一次，使用ethtool我们可以选择元组(源 IP、目标 IP、源port、目标port)生成hash值。
Shell
receiver$ ethtool -N eth2 rx-flow-hash udp4 sdfn
Cannot change RX network flow hashing options: Operation not supported
不幸地是，我们的NIC不支持自定义，我们只能选用(源 IP、目的 IP) 生成hash。
NUMA性能报告
到目前为止，我们所有的数据包都流向一个RX队列，并且一个CPU。我们可以借这个机会为基准来衡量不同CPU的性能。在我们设置为接收方的主机上有两个单独的处理器，每一个都是一个不同的NUMA节点。
在我们设置中，可以将单线程接收者依附到四个CPU中的一个，四个选项如下：
另一个CPU上运行接收器，但将相同的NUMA节点作为RX队列。性能如上面我们看到的，大约是360 kpps。
将运行接收器的同一 CPU 作为RX队列，我们可以得到大约430 kpps。但这样也会有很高的不稳定性，如果NIC被数据包所淹没，性能将下降到零。
当接收器运行在HT对应的处理RX队列的CPU之上，性能是通常的一半，大约在200kpps左右。
接收器在一个不同的NUMA节点而不是RX队列的CPU上，性能大约是330 kpps。但是数字会不太一致。
虽然运行在一个不同的NUMA节点上有10%的代价，听起来可能不算太坏，但随着规模的变大，问题只会变得更糟。在一些测试中，每个核只能发出250 kpps，在所有跨NUMA测试中，这种不稳定是很糟糕。跨NUMA节点的性能损失，在更高的吞吐量上更明显。在一次测试时，发现在一个坏掉的NUMA节点上运行接收器，性能下降有4倍。
3.多接收IP
因为我们NIC上hash算法的限制，通过RX队列分配数据包的唯一方法是利用多个IP地址。下面是如何将数据包发到不同的目的IP：
1
sender$ taskset -c 1,2 ./udpsender 192.168.254.1:4321 192.168.254.2:4321
ethtool 证实了数据包流向了不同的 RX 队列：
Shell
receiver$ watch 'sudo ethtool -S eth2 |grep rx'
rx-0.rx_packets: 8.0/s
rx-1.rx_packets: 0.0/s
rx-2.rx_packets: 0.0/s
rx-3.rx_packets: 355.2k/s
rx-4.rx_packets: 0.5/s
rx-5.rx_packets: 297.0k/s
rx-6.rx_packets: 0.0/s
rx-7.rx_packets: 0.5/s
rx-8.rx_packets: 0.0/s
rx-9.rx_packets: 0.0/s
rx-10.rx_packets: 0.0/s
接收部分：
Shell
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.609M pps 18.599MiB / 156.019Mb
0.657M pps 20.039MiB / 168.102Mb
0.649M pps 19.803MiB / 166.120Mb
万岁！有两个核忙于处理RX队列，第三运行应用程序时，可以达到大约650 kpps !
我们可以通过发送数据到三或四个RX队列来增加这个数值，但是很快这个应用就会有另一个瓶颈。这一次rx_nodesc_drop_cnt没有增加，但是netstat接收到了如下错误：
Shell
receiver$ watch 'netstat -s --udp'
Udp:
437.0k/s packets received
0.0/s packets to unknown port received.
386.9k/s packet receive errors
0.0/s packets sent
RcvbufErrors: 123.8k/s
SndbufErrors: 0
InCsumErrors: 0
这意味着虽然NIC能够将数据包发送到内核，但是内核不能将数据包发给应用程序。在我们的case中，只能提供440 kpps，其余的390 kpps + 123 kpps的下降是由于应用程序接收它们不够快。
4.多线程接收
我们需要扩展接收者应用程序。最简单的方式是利用多线程接收，但是不管用：
Shell
sender$ taskset -c 1,2 ./udpsender 192.168.254.1:4321 192.168.254.2:4321
receiver$ taskset -c 1,2 ./udpreceiver1 0.0.0.0:4321 2
0.495M pps 15.108MiB / 126.733Mb
0.480M pps 14.636MiB / 122.775Mb
0.461M pps 14.071MiB / 118.038Mb
0.486M pps 14.820MiB / 124.322Mb
接收性能较于单个线程下降了，这是由UDP接收缓冲区那边的锁竞争导致的。由于两个线程使用相同的套接字描述符，它们花费过多的时间在UDP接收缓冲区的锁竞争。这篇论文详细描述了这一问题。
看来使用多线程从一个描述符接收，并不是最优方案。
5. SO_REUSEPORT
幸运地是，最近有一个解决方案添加到 Linux 了 —— SO_REUSEPORT 标志位（flag）。当这个标志位设置在一个套接字描述符上时，Linux将允许许多进程绑定到相同的端口，事实上，任何数量的进程将允许绑定上去，负载也会均衡分布。
有了SO_REUSEPORT，每一个进程都有一个独立的socket描述符。因此每一个都会拥有一个专用的UDP接收缓冲区。这样就避免了以前遇到的竞争问题：
Shell
1
2
3
4
receiver$ taskset -c 1,2,3,4 ./udpreceiver1 0.0.0.0:4321 4 1
1.114M pps 34.007MiB / 285.271Mb
1.147M pps 34.990MiB / 293.518Mb
1.126M pps 34.374MiB / 288.354Mb
现在更加喜欢了，吞吐量很不错嘛！
更多的调查显示还有进一步改进的空间。即使我们开始4个接收线程，负载也会不均匀地分布：
两个进程接收了所有的工作，而另外两个根本没有数据包。这是因为hash冲突，但是这次是在SO_REUSEPORT层。
结束语
我做了一些进一步的测试，完全一致的RX队列，接收线程在单个NUMA节点可以达到1.4Mpps。在不同的NUMA节点上运行接收者会导致这个数字做多下降到1Mpps。
总之，如果你想要一个完美的性能，你需要做下面这些：
确保流量均匀分布在许多RX队列和SO_REUSEPORT进程上。在实践中，只要有大量的连接(或流动)，负载通常是分布式的。
需要有足够的CPU容量去从内核上获取数据包。
To make the things harder, both RX queues and receiver processes should be on a single NUMA node.
为了使事情更加稳定，RX队列和接收进程都应该在单个NUMA节点上。
虽然我们已经表明，在一台Linux机器上接收1Mpps在技术上是可行的，但是应用程序将不会对收到的数据包做任何实际处理——甚至连看都不看内容的流量。别太指望这样的性能，因为对于任何实际应用并没有太大用处。
Ⅲ linux 下用socket 文件传输问题(UDP)
要下班了，时间急，不写代码了先给你一个思路
1 实现最简单的udp socket 模型，实现发送一个字符串。
2 实现一个简单的打开文件，读取文件的例子，如用fgets(),类似的函数有很多，然后再把读取的文件内容忘另一个文件里写(相关函数fopen(),write(),read())。
3 把上面两个函数结合到一起，在客户端实现打开要传送的文件，按一定的大小读取，读取后调用sendto（）发送到服务器端。在服务器端创建一个文件，然后调用recvfrom（）接受客户端发送过来的数据，向来是创建的那个文件中写。
下面是改好的udp发送文件的例子。
服务器端程序的编译
gcc -o file_server file_server
客户端程序的编译
gcc -o file_client file_client.c
服务器程序和客户端程应当分别运行在2台计算机上.
服务器端程序的运行,在一个计算机的终端执行
./file_server
客户端程序的运行,在另一个计算机的终端中执行
./file_client 运行服务器程序的计算机的IP地址
根据提示输入要传输的服务器上的文件，该文件在服务器的运行目录上
在实际编程和测试中,可以用2个终端代替2个计算机,这样就可以在一台计算机上测试网络程序,
服务器端程序的运行,在一个终端执行
./file_server
客户端程序的运行,在另一个终端中执行
./file_client 127.0.0.1
说明: 任何计算机都可以通过127.0.0.1访问自己. 也可以用计算机的实际IP地址代替127.0.0.1
//////////////////////////////////////////////////////////////////////////////////////
// file_server.c 文件传输顺序服务器示例
//////////////////////////////////////////////////////////////////////////////////////
//本文件是服务器的代码
#include <netinet/in.h> // for sockaddr_in
#include <sys/types.h> // for socket
#include <sys/socket.h> // for socket
#include <stdio.h> // for printf
#include <stdlib.h> // for exit
#include <string.h> // for bzero
/*
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
*/
#define HELLO_WORLD_SERVER_PORT 6666
#define LENGTH_OF_LISTEN_QUEUE 20
#define BUFFER_SIZE 1024
#define FILE_NAME_MAX_SIZE 512
int main(int argc, char **argv)
{
//设置一个socket地址结构server_addr,代表服务器internet地址, 端口
struct sockaddr_in server_addr， pcliaddr;
bzero(&server_addr,sizeof(server_addr)); //把一段内存区的内容全部设置为0
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = htons(INADDR_ANY);
server_addr.sin_port = htons(HELLO_WORLD_SERVER_PORT);
//创建用于internet的据报套接字（UDPt,用server_socket代表服务器socket
// 创建数据报套接字（UDP）
int server_socket = socket(PF_INET,SOCK_DGRAM,0);
if( server_socket < 0)
{
printf("Create Socket Failed!");
exit(1);
}
//把socket和socket地址结构联系起来
if( bind(server_socket,(struct sockaddr*)&server_addr,sizeof(server_addr)))
{
printf("Server Bind Port : %d Failed!", HELLO_WORLD_SERVER_PORT);
exit(1);
}
while (1) //服务器端要一直运行
{
//定义客户端的socket地址结构client_addr
struct sockaddr_in client_addr;
socklen_t n = sizeof(client_addr) ;
int length;
char buffer[BUFFER_SIZE];
bzero(buffer, BUFFER_SIZE);
length = recvfrom(new_server_socket,buffer,BUFFER_SIZE,0,&pcliaddr,&n);
if (length < 0)
{
printf("Server Recieve Data Failed!\n");
break;
}
char file_name[FILE_NAME_MAX_SIZE+1];
bzero(file_name, FILE_NAME_MAX_SIZE+1);
strncpy(file_name, buffer, strlen(buffer)>FILE_NAME_MAX_SIZE?FILE_NAME_MAX_SIZE:strlen(buffer));
// int fp = open(file_name, O_RDONLY);
// if( fp < 0 )
FILE * fp = fopen(file_name,"r");
if(NULL == fp )
{
printf("File:\t%s Not Found\n", file_name);
}
else
{
bzero(buffer, BUFFER_SIZE);
int file_block_length = 0;
// while( (file_block_length = read(fp,buffer,BUFFER_SIZE))>0)
while( (file_block_length = fread(buffer,sizeof(char),BUFFER_SIZE,fp))>0)
{
printf("file_block_length = %d\n",file_block_length);
//发送buffer中的字符串到new_server_socket,实际是给客户端
if(send(new_server_socket,buffer,file_block_length,0)<0)
{
printf("Send File:\t%s Failed\n", file_name);
break;
}
bzero(buffer, BUFFER_SIZE);
}
// close(fp);
fclose(fp);
printf("File:\t%s Transfer Finished\n",file_name);
}
}
}
//////////////////////////////////////////////////////////////////////////////////////
// file_client.c 文件传输客户端程序示例
//////////////////////////////////////////////////////////////////////////////////////
//本文件是客户机的代码
#include <netinet/in.h> // for sockaddr_in
#include <sys/types.h> // for socket
#include <sys/socket.h> // for socket
#include <stdio.h> // for printf
#include <stdlib.h> // for exit
#include <string.h> // for bzero
/*
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
*/
#define HELLO_WORLD_SERVER_PORT 6666
#define BUFFER_SIZE 1024
#define FILE_NAME_MAX_SIZE 512
int main(int argc, char **argv)
{
if (argc != 2)
{
printf("Usage: ./%s ServerIPAddress\n",argv[0]);
exit(1);
}
//设置一个socket地址结构client_addr,代表客户机internet地址, 端口
struct sockaddr_in client_addr;
bzero(&client_addr,sizeof(client_addr)); //把一段内存区的内容全部设置为0
client_addr.sin_family = AF_INET; //internet协议族
client_addr.sin_addr.s_addr = htons(INADDR_ANY);//INADDR_ANY表示自动获取本机地址
client_addr.sin_port = htons(0); //0表示让系统自动分配一个空闲端口
//创建用于internet的流协议(TCP)socket,用client_socket代表客户机socket
int client_socket = socket(AF_INET,SOCK_DGRAM,0);
if( client_socket < 0)
{
printf("Create Socket Failed!\n");
exit(1);
}
//设置一个socket地址结构server_addr,代表服务器的internet地址, 端口
struct sockaddr_in server_addr;
bzero(&server_addr,sizeof(server_addr));
server_addr.sin_family = AF_INET;
if(inet_aton(argv[1],&server_addr.sin_addr) == 0) //服务器的IP地址来自程序的参数
{
printf("Server IP Address Error!\n");
exit(1);
}
server_addr.sin_port = htons(HELLO_WORLD_SERVER_PORT);
socklen_t server_addr_length = sizeof(server_addr);
char file_name[FILE_NAME_MAX_SIZE+1];
bzero(file_name, FILE_NAME_MAX_SIZE+1);
printf("Please Input File Name On Server:\t");
scanf("%s", file_name);
char buffer[BUFFER_SIZE];
bzero(buffer,BUFFER_SIZE);
strncpy(buffer, file_name, strlen(file_name)>BUFFER_SIZE?BUFFER_SIZE:strlen(file_name));
//向服务器发送buffer中的数据
socklen_t n = sizeof(server_addr) ;
sendto(client_socket,buffer,BUFFER_SIZE,0,(struct sockaddr*)&server_addr,n);
// int fp = open(file_name, O_WRONLY|O_CREAT);
// if( fp < 0 )
FILE * fp = fopen(file_name,"w");
if(NULL == fp )
{
printf("File:\t%s Can Not Open To Write\n", file_name);
exit(1);
}
//从服务器接收数据到buffer中
bzero(buffer,BUFFER_SIZE);
int length = 0;
while( length = recv(client_socket,buffer,BUFFER_SIZE,0))
{
if(length < 0)
{
printf("Recieve Data From Server %s Failed!\n", argv[1]);
break;
}
// int write_length = write(fp, buffer,length);
int write_length = fwrite(buffer,sizeof(char),length,fp);
if (write_length<length)
{
printf("File:\t%s Write Failed\n", file_name);
break;
}
bzero(buffer,BUFFER_SIZE);
}
printf("Recieve File:\t %s From Server[%s] Finished\n",file_name, argv[1]);
return 0;
}
Ⅳ 使用recvfrom接收UDP包在Windows和Linux平台的不同表现
1 UDP接收原理
操作系统的UDP接收流程如下：收到一个UDP包后，验证没有错误后，放入一个包队列中，队列中的每一个元素就是一个完整的UDP包。当应用程序通过recvfrom()读取时，OS把相应的一个完整UDP包取出，然后拷贝到用户提供的内存中，物理用户提供的内存大小是多少，OS都会完整取出一个UDP包。如果用户提供的内存小于这个UDP包的大小，那么在填充慢内存后，UDP包剩余的部分就会被丢弃，以后再也无法取回。
这与TCP接收完全不同，TCP没有完整包的概念，也没有边界，OS只会取出用户要求的大小，剩余的仍然保留在OS中，下次还可以继续取出。
socket编程虽然是事实上的标准，而且不同平台提供的接口函数也非常类似，但毕竟它不存在严格的标准。所以各个平台的实现也不完全兼容。下面就从recvfrom()这个函数看看Window平台和Linux平台的不同。
2 Windows平台的表现
先看头文件中的声明：
[cpp] view plain在CODE上查看代码片派生到我的代码片
int
WSAAPI
recvfrom(
_In_ SOCKET s,
_Out_writes_bytes_to_(len, return) __out_data_source(NETWORK) char FAR * buf,
_In_ int len,
_In_ int flags,
_Out_writes_bytes_to_opt_(*fromlen, *fromlen) struct sockaddr FAR * from,
_Inout_opt_ int FAR * fromlen
);
再看MSDN说明:
If the datagram or message is larger than the buffer specified, the buffer is filled with the first part of the datagram, and recvfrom generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost.
可以看出，buf大小小于UDP包大小的时候，recvfrom()会返回-1，并设置错误WSAEMSGSIZE。
实际编程测试验证确实是这样的表现。
3 Linux平台的表现
先看头文件中的声明：
[cpp] view plain在CODE上查看代码片派生到我的代码片
__extern_always_inline ssize_t
recvfrom (int __fd, void *__restrict __buf, size_t __n, int __flags,
__SOCKADDR_ARG __addr, socklen_t *__restrict __addr_len)
可以看出与Windows平台的函数原型相同。但是在其man手册里，没有看到UDP包大于接收缓冲区情况的特殊说明。
写代码测试表明，buf小于UDP包大小的时候，recvfrom()仍然返回复制到缓冲区的字节数，调用者无法得知UDP包被截断的情况。
4 写代码注意事项
UDP包最大是多大呢？UDP头部大小字段占16字节，所以理论上是65535个字节大小。但是UDP如果是通过IP（大多数情况）来传送，由于UDP本身不支持分片，所以一个UDP包只能通过一个IP包来传送，一个IP包大大小理论上也是用16字节表示，这样UDP最大大小就是（65535-IP头部）。
而现实中如果IP包大小大于底层链路层帧的最大数据区大小，则必须对IP包进行分片传送。分片会严重影响传送效率，而且增大不稳定性，所以实际的网络程序发送的IP包都封装到单一的链路层帧中，从而避免分片。问题是链路层帧是多大呢？答案是不一定，因为不同的物理网络的帧大小不一样，如以太网是1500字节，但是其他物理网络可能更小，Internet上的有个最小的限制，那就是576字节。如果UDP程序运行在只运行在以太网中，那么为了避免IP分片，可以采用的最大大小为(1500-20-8)=1472字节。如果UDP程序需要运行在Internet上，那么建议最大大小为(576-20-8)=548字节。
上面是实践中的最佳UDP大小，但是并不是所有程序都采用上述经验，所以对于接收缓冲区的大小也就没有一个标准，而是取决于应用程序设计者本身。虽然对于Windows平台，recvfrom()能够提示调用者buf过小的问题，但是即使得到了这个错误，包还是被丢弃了。所以在接收UDP包时，一定要事先了解应用层设计的最大UDP包大小，然后按照最大值开辟接收缓冲区。
Ⅳ linux查看本地一个udp端口有没有接收到数据包
使用如下命令： tcpmp udp port 200