浅谈UDP(数据包长度,收包能力,丢包及进程结构选择)

UDP数据包长度linux

UDP数据包的理论长度编程

udp数据包的理论长度是多少,合适的udp数据包应该是多少呢?从TCP-IP详解卷一第11章的udp数据包的包头能够看出,udp的最大包长度是2^16-1的个字节。因为udp包头占8个字节,而在ip层进行封装后的ip包头占去20字节,因此这个是udp数据包的最大理论长度是2^16-1-8-20=65507。缓存

然而这个只是udp数据包的最大理论长度。首先,咱们知道,TCP/IP一般被认为是一个四层协议系统,包括链路层、网络层、运输层、应用层。UDP属于运输层,在传输过程当中,udp包的总体是做为下层协议的数据字段进行传输的,它的长度大小受到下层ip层和数据链路层协议的制约。性能优化

【文章福利】小编推荐本身的linuxC/C++语言交流群:832218493!整理了一些我的以为比较好的学习书籍、视频资料共享在群文件里面,有须要的能够自行添加哦!~服务器

MTU相关概念网络

以太网(Ethernet)数据帧的长度必须在46-1500字节之间,这是由以太网的物理特性决定的。这个1500字节被称为链路层的MTU(最大传输单元)。因特网协议容许IP分片,这样就能够将数据包分红足够小的片断以经过那些最大传输单元小于该数据包原始大小的链路了。这一分片过程发生在网络层,它使用的是将分组发送到链路上的网络接口的最大传输单元的值。这个最大传输单元的值就是MTU(Maximum Transmission Unit)。它是指一种通讯协议的某一层上面所能经过的最大数据包大小(以字节为单位)。最大传输单元这个参数一般与通讯接口有关(网络接口卡、串口等)。多线程

在因特网协议中,一条因特网传输路径的“路径最大传输单元”被定义为从源地址到目的地址所通过“路径”上的全部IP跳的最大传输单元的最小值。架构

须要注意的是,loopback的MTU不受上述限制,查看loopback MTU值:运维

[root@bogon ~]# cat /sys/class/net/lo/mtu异步

65536

IP分包udp数据包长度的影响

如上所述,因为网络接口卡的制约,mtu的长度被限制在1500字节,这个长度指的是链路层的数据区。对于大于这个数值的分组可能被分片,不然没法发送,而分组交换的网络是不可靠的,存在着丢包。IP 协议的发送方不作重传。接收方只有在收到所有的分片后才能 reassemble并送至上层协议处理代码,不然在应用程序看来这些分组已经被丢弃。

假定同一时刻网络丢包的几率是均等的,那么较大的IP datagram必然有更大的几率被丢弃,由于只要丢失了一个fragment,就致使整个IP datagram接收不到。不超过MTU的分组是不存在分片问题的。

MTU的值并不包括链路层的首部和尾部的18个字节。因此,这个1500字节就是网络层IP数据报的长度限制。由于IP数据报的首部为20字节,因此IP数据报的数据区长度最大为1480字节。而这个1480字节就是用来放TCP传来的TCP报文段或UDP传来的UDP数据报的。又由于UDP数据报的首部8字节,因此UDP数据报的数据区最大长度为1472字节。这个1472字节就是咱们可使用的字节数。

当咱们发送的UDP数据大于1472的时候会怎样呢?这也就是说IP数据报大于1500字节,大于MTU。这个时候发送方IP层就须要分片(fragmentation)。把数据报分红若干片,使每一片都小于MTU。而接收方IP层则须要进行数据报的重组。而更严重的是,因为UDP的特性,当某一片数据传送中丢失时,接收方便没法重组数据报。将致使丢弃整个UDP数据报。所以,在普通的局域网环境下,将UDP的数据控制在1472字节如下为好。

进行Internet编程时则不一样,由于Internet上的路由器可能会将MTU设为不一样的值。若是咱们假定MTU为1500来发送数据的,而途经的某个网络的MTU值小于1500字节,那么系统将会使用一系列的机制来调整MTU值,使数据报可以顺利到达目的地。鉴于Internet上的标准MTU值为576字节,因此在进行Internet的UDP编程时,最好将UDP的数据长度控件在548字节(576-8-20)之内。

UDP丢包

udp丢包是指网卡接收到数据包后,linux内核的tcp/ip协议栈在udp数据包处理过程当中的丢包,主要缘由有两个:

一、udp数据包格式错误或校验和检查失败。

二、应用程序来不及处理udp数据包。

对于缘由1,udp数据包自己的错误不多见,应用程序也不可控,本文不讨论。

首先介绍通用的udp丢包检测方法,使用netstat命令,加-su参数。

netstat -su

Udp:

2495354 packets received

2100876 packets to unknown port received.

3596307 packet receive errors

14412863 packets sent

RcvbufErrors: 3596307

SndbufErrors: 0

从上面的输出中,能够看到有一行输出包含了"packet receive errors",若是每隔一段时间执行netstat -su,发现行首的数字不断变大,代表发生了udp丢包。

下面介绍一下应用程序来不及处理而致使udp丢包的常见缘由:

一、linux内核socket缓冲区设的过小 # cat /proc/sys/net/core/rmem_default

cat /proc/sys/net/core/rmem_max

能够查看socket缓冲区的缺省值和最大值。

rmem_default和rmem_max设置为多大合适呢?若是服务器的性能压力不大,对处理时延也没有很严格的要求,设置为1M左右便可。若是服务器的性能压力较大,或者对处理时延有很严格的要求,则必须谨慎设置rmem_default 和rmem_max,若是设得太小,会致使丢包,若是设得过大,会出现滚雪球。

二、服务器负载太高,占用了大量cpu资源,没法及时处理linux内核socket缓冲区中的udp数据包,致使丢包。

通常来讲,服务器负载太高有两个缘由:收到的udp包过多;服务器进程存在性能瓶颈。若是收到的udp包过多,就要考虑扩容了。服务器进程存在性能瓶颈属于性能优化的范畴,这里不做过多讨论。

三、磁盘IO忙

服务器有大量IO操做,会致使进程阻塞,cpu都在等待磁盘IO,不能及时处理内核socket缓冲区中的udp数据包。若是业务自己就是IO密集型的,要考虑在架构上进行优化,合理使用缓存下降磁盘IO。

这里有一个容易忽视的问题:不少服务器都有在本地磁盘记录日志的功能,因为运维误操做致使日志记录的级别太高,或者某些错误忽然大量出现,使得往磁盘写日志的IO请求量很大,磁盘IO忙,致使udp丢包。

对于运维误操做,能够增强运营环境的管理,防止出错。若是业务确实须要记录大量的日志,可使用内存log或者远程log。

四、物理内存不够用,出现swap交换

swap交换本质上也是一种磁盘IO忙,由于比较特殊,容易被忽视,因此单列出来。

只要规划好物理内存的使用,而且合理设置系统参数,能够避免这个问题。

5)磁盘满致使没法IO

没有规划好磁盘的使用,监控不到位,致使磁盘被写满后服务器进程没法IO,处于阻塞状态。最根本的办法是规划好磁盘的使用,防止业务数据或日志文件把磁盘塞满,同时增强监控,例如开发一个通用的工具,当磁盘使用率达到80%时就持续告警,留出充足的反应时间。

UDP收包能力测试

测试环境

处理器:Intel(R) Xeon(R) CPU X3440 @ 2.53GHz,4核,8超线程,千兆以太网卡,8G内存

模型1

单机,单线程异步UDP服务,无业务逻辑,只有收包操做,除UDP包头外,一个字节数据。

测试结果

现象:

一、单机UDP收包处理能力能够每秒达到150w左右。

二、处理能力随着进程个数的增长而加强。

三、在处理达到峰值时,CPU资源并未耗尽。

结论:

一、UDP的处理能力仍是很是可观的。

二、对于现象2和现象3,能够看出,性能的瓶颈在网卡,而不在CPU,CPU的增长,处理能力的上升,来源于丢包(UDP_ERROR)个数的减小。

模型2

其余测试条件同模型1,除UDP包头外,一百个字节数据。

测试结果

现象:

一、100个字节的包大小,比较符合日常的业务情形。

二、UDP的处理能力仍是很是可观,单机峰值能够到达每秒75w。

三、在4,8个进程时,没有记录CPU的占用状况(网卡流量耗尽),不过能够确定的是,CPU未耗尽。

四、随着进程个数的上升,处理能力没有明显提高,可是,丢包(UDP_ERROR)的个数大幅降低。

模型3

单机,单进程,多线程异步UDP服务,多线程共用一个fd,无业务逻辑,除UDP包头外,一个字节数据。

测试结果:

现象:

一、随着线程个数的增长,处理能力不升反降。

结论:

一、多线程共用一个fd,会形成至关大的锁争用。

二、多线程共用一个fd,当有包来时,会激活全部的线程,致使频繁的上下文切换。

最终结论:

一、UDP处理能力很是可观,在平常的业务情形中,UDP通常不会成为性能瓶颈。

二、随着进程个数的增长,处理能力未明显上升,可是丢包个数明显降低。

三、本次测试过程当中,瓶颈在网卡,而不在CPU。

四、采用多进程监听不一样端口的模型,而不是多进程或多线程监听同一个端口。

总结

相关文章
相关标签/搜索