linux udp丢包检测_linux udp 网卡丢包 - CSDN
  • 一、UDP丢包现象 UDP丢包是正常现象,因为它是不安全的。 UDP是无连接的,面向消息的数据传输协议,与TCP相比,有两个致命的缺点,一是数据包容易丢失,二是数据包无序。 要实现文件的可靠传输,就必须在上层对...

    一、UDP丢包现象

    UDP丢包是正常现象,因为它是不安全的。

    UDP是无连接的,面向消息的数据传输协议,与TCP相比,有两个致命的缺点,一是数据包容易丢失,二是数据包无序。

    要实现文件的可靠传输,就必须在上层对数据丢包和乱序作特殊处理,必须要有要有丢包重发机制和超时机制。

    常见的可靠传输算法有模拟TCP协议,重发请求(ARQ)协议,它又可分为连续ARQ协议、选择重发ARQ协议、滑动窗口协议等等。

    1、我感觉原因可能有两个:

    (1)、客户端发送过快,网络状况不好或者超过服务器接收速度,就会丢包。

    (2)、原因是服务器收到包后,还要进行一些处理,而这段时间客户端发送的包没有去收,造成丢包。

    2、解决方法:

    (1)、客户端降低发送速度,可以等待回包,或者加一些延迟。

    (2)、服务器部分单独开一个线程,去接收UDP数据,存放在一个缓冲区中,又另外的线程去处理收到的数据,尽量减少因为处理数据延时造成的丢包。

    3、总结:

    如果必须使用UDP,而且丢包又是不能接受的,只好自己实现确认和重传,说白了,就是自己实现TCP(当然是部分和有限的简单实现)。

    二、如何制造UDP丢包?

    如果只是小规模程序,也可以自己实现丢包处理,原理基本上就是给文件分块,每个数据包的头部添加一个唯一标识序号的ID值,当接收的包头部ID不是期望中的ID号,则判定丢包,将丢包ID发回服务端,服务器端接到丢包响应则重发丢失的数据包。

    UDP是面向无连接的,用户在实施UDP编程时,必须制定上层的协议,包括流控制,简单的超时和重传机制,如果不要求是实时数据,我想TCP可能会更适合你!

    三、怎样测试UDP并发性能?

    1、连续把程序跑24个小时。

    2、一般就是在同一个时间段内采用大量的客户端或者一个客户端采用多线程的方式向服务器发送数据,因此也就是多线程或者多进程的的方式来模拟发送数据的形式

    展开全文
  • UDP 丢包率测试工具

    2020-07-26 23:31:19
    客户端使用UDP发送指定大小数据包,服务端收到后原样返回。客户端判断丢失率。包含工程、源码、可执行文件等
  • UDP丢包检测工具

    2020-07-30 23:32:19
    这是一款测试网络的丢包的软件,该软件具有收发软件测试包的功能。
  • 本文讨论的udp丢包是指网卡接收到数据包后,linux内核的tcp/ip协议栈在udp数据包处理过程中的丢包,主要原因有两个: 1) udp数据包格式错误或校验和检查失败 ...首先介绍通用的udp丢包检测方法,使用netstat

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

    1)        udp数据包格式错误或校验和检查失败

    2)        应用程序来不及处理udp数据包

    对于原因1),udp数据包本身的错误很少见,应用程序也不可控,本文不讨论。

     

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

    # netstat -su

    udp:

        380408160 packets received

        17 packets to unknown port received.

        62314 packet receive errors

        397718604 packets sent

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

     

    下面介绍一下udp丢包的常见原因:

    1)    Linux内核socket缓冲区设的太小
           通过 cat /proc/sys/net/core/rmem_default cat /proc/sys/net/core/rmem_max可以查看socket缓冲区的缺省值和最大值。rmem_defaultrmem_max设置为多大合适呢?如果服务器的性能压力不大,对处理时延也没有很严格的要求,设置为1M左右即可。如果服务器的性能压力较大,或者对处理时延有很严格的要求,则必须谨慎设置rmem_default rmem_max,如果设得过小,会导致丢包,如果设得过大,会出现滚雪球。socket缓冲区设的过大导致滚雪球的问题,大家可以参考http://km.oa.com/user/bisonliao/articles/show/75674中的介绍,有定量的计算方法,分析得很深入。

     

    2)    服务器负载过高,占用了大量cpu资源,无法及时处理linux内核socket缓冲区中的udp数据包,导致丢包

           一般来说,服务器负载过高有两个原因:收到的udp包过多;服务器进程存在性能瓶颈。如果收到的udp包过多,就要考虑扩容了,从日常运营的经验来看,公司现有的B5机器,在业务逻辑不复杂(简单的打包解包和内存hash等操作)、不超过网卡流量限制的情况下,每秒可以处理25万个udp包。至于如何提高服务器的性能,属于高性能服务器的设计和实现范畴,功力有限,不敢在这里班门弄斧,自己平时使用最多也就是三板斧:top+strace+ltrace,先使用top查看cpu内核态时间和用户态时间的比例,如果内核态时间占大头,就用strace查看主要的系统调用有哪些;如果如果用户态时间占大头,就用ltrace查看主要的库函数调用有哪些。找到性能瓶颈后,想办法优化系统架构和业务逻辑,减少不必要的系统调用和库函数调用。从以往的经验来看,很容易犯的一个错误是调用不必要的memsetmemcpy操作一大片内存,当请求量小的时候,发现不了问题,一旦突发的请求过来,触发大量的memsetmemcpy操作,占用了cpu资源,导致丢包和滚雪球,让人措手不及,所以系统上线前,一定要做好压力测试,通过压力测试找出性能瓶颈,将危险消灭在萌芽状态。

     

    3)     磁盘IO

            服务器有大量IO操作,会导致进程阻塞,cpu都在等待磁盘IO,不能及时处理内核socket缓冲区中的udp数据包。如果业务本身就是IO密集型的,要考虑在架构上进行优化,合理使用缓存降低磁盘IO。这里有一个容易忽视的问题:很多服务器都有在本地磁盘记录日志的功能,由于运维误操作导致日志记录的级别过高,或者某些错误突然大量出现,使得往磁盘写日志的IO请求量很大,磁盘IO忙,导致udp丢包。对于运维误操作,可以加强运营环境的管理,防止出错。如果业务确实需要记录大量的日志,可以使用内存log或者远程log

       

    4)    物理内存不够用,出现swap交换

           swap交换本质上也是一种磁盘IO忙,因为比较特殊,容易被忽视,所以单列出来。只要规划好物理内存的使用,并且合理设置系统参数,可以避免这个问题。

     

    5)    磁盘满导致无法IO

           没有规划好磁盘的使用,监控不到位,导致磁盘被写满后服务器进程无法IO,处于阻塞状态。公司的监控中心对机器的磁盘使用率有监控,使用率超过95%会通知机器负责人处理。但是如果机器负责人错过了告警,或者没有及时处理告警,仍然会导致磁盘被写满。最根本的办法是规划好磁盘的使用,防止业务数据或日志文件把磁盘塞满,同时加强监控,例如开发一个通用的工具,当磁盘使用率达到80%时就持续告警,留出充足的反应时间。

    展开全文
  • udp丢包是指在截获数据包后,linux内核的tcp/ip协议栈在udp数据包处理过程...首先介绍通用的udp丢包检测方法,使用netstat命令,加-su参数。 # netstat -su Udp:  * packets received  * packets to unknown p

          udp丢包是指在截获数据包后,linux内核的tcp/ip协议栈在udp数据包处理过程中的丢包,主要原因有两个:udp数据包格式或校验和错误和应用程序来不及处理udp数据包。

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

    # netstat -su

    Udp:

        * packets received

        * packets to unknown port received.

        * packet receive errors

        * packets sent

        RcvbufErrors: *

        SndbufErrors: *

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

    其次,由于应用程序来不及处理而导致udp丢包的常见原因:

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

    # cat /proc/sys/net/core/rmem_max

    可以查看socket缓冲区的缺省值和最大值。

    在大压力下,rmem_default、rmem_max、wmem_default和wmem_max的值,如果服务器的性能压力不大,对处理时延也没有很严格的要求,设置为1M左右即可。如果服务器的性能压力较大,对处理时延有很严格的要求,则须谨慎设置rmem_default 和rmem_max,如果设得过小,会导致丢包,如果设得过大,会出现滚雪球。



             修改rmem_default、rmem_max、wmem_default和wmem_max的值,需要在/etc/sysctl.conf文件中进行,执行sysctl -p即可生效。

           即当系统重新启动后,原来设置的参数值就会丢失,而系统每次启动时都会自动去/etc/sysctl.conf文件中读取内核参数,因此将内核的参数配置写入这个文件中,是一个比较好的选择。


      首先打开/etc/sysctl.conf文件,查看如下两行的设置值,这里是:
      kernel.shmall = 2097152
      kernel.shmmax = 4294967295 如果系统默认的配置比这里给出的值大,就不要修改原有配置。同时在/etc/sysctl.conf文件最后,添加以下内容:

      fs.file-max = 6553600 
      kernel.shmmni = 4096 
      kernel.sem = 250 32000 100 128 
      net.ipv4.ip_local_port_range = 1024 65000 
      net.core.rmem_default = 4194304 
      net.core.rmem_max = 4194304 
      net.core.wmem_default = 262144 
      net.core.wmem_max = 262144 
      这里的“fs.file-max = 6553600”其实是由“fs.file-max = 512 * PROCESSES”得到的,我们指定PROCESSES的值为12800,即为“fs.file-max =512 *12800”。

      sysctl.conf文件修改完毕后,接着执行“sysctl -p”使设置生效。
      [root@localhost ~]# sysctl -p 常用的内核参数的含义如下。
      kernel.shmmax:表示单个共享内存段的最大值,以字节为单位,此值一般为物理内存的一半,不过大一点也没关系,这里设定的为4GB,即“4294967295/1024/1024/1024=4G”。
      kernel.shmmni:表示单个共享内存段的最小值,一般为4kB,即4096bit.
      kernel.shmall:表示可用共享内存的总量,单位是页,在32位系统上一页等于4kB,也就是4096字节。
      fs.file-max:表示文件句柄的最大数量。文件句柄表示在Linux系统中可以打开的文件数量。
      ip_local_port_range:表示端口的范围,为指定的内容。
      kernel.sem:表示设置的信号量,这4个参数内容大小固定。
      net.core.rmem_default:表示接收套接字缓冲区大小的缺省值(以字节为单位)。
      net.core.rmem_max :表示接收套接字缓冲区大小的最大值(以字节为单位)
      net.core.wmem_default:表示发送套接字缓冲区大小的缺省值(以字节为单位)。

      net.core.wmem_max:表示发送套接字缓冲区大小的最大值(以字节为单位)。



         注:当加入iptable规则,在输入/输出/转发过程中不起作用时,则需要在/etc/sysctl.conf文件中,添加:

                         net.ipv4.ip_forward = 1

    展开全文
  • udp丢包

    2014-09-08 11:45:35
    本文讨论的udp丢包是指网卡接收到数据包后,linux内核的tcp/ip协议栈在udp数据包处理过程中的丢包,主要原因有两个: 1) udp数据包格式错误或校验和检查失败 ...首先介绍通用的udp丢包检测方法,使用netstat

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

    1)        udp数据包格式错误或校验和检查失败

    2)        应用程序来不及处理udp数据包

    对于原因1),udp数据包本身的错误很少见,应用程序也不可控,本文不讨论。

     

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

    # netstat -su

    udp:

        380408160 packets received

        17 packets to unknown port received.

        62314 packet receive errors

        397718604 packets sent

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

     

    下面介绍一下udp丢包的常见原因:

    1)        linux内核socket缓冲区设的太小
        通过 cat /proc/sys/net/core/rmem_default cat /proc/sys/net/core/rmem_max可以查看socket缓冲区的缺省值和最大值。rmem_defaultrmem_max设置为多大合适呢?如果服务器的性能压力不大,对处理时延也没有很严格的要求,设置为1M左右即可。如果服务器的性能压力较大,或者对处理时延有很严格的要求,则必须谨慎设置rmem_default rmem_max,如果设得过小,会导致丢包,如果设得过大,会出现滚雪球。socket缓冲区设的过大导致滚雪球的问题,大家可以参考http://km.oa.com/user/bisonliao/articles/show/75674中的介绍,有定量的计算方法,分析得很深入。

     

    2)        服务器负载过高,占用了大量cpu资源,无法及时处理linux内核socket缓冲区中的udp数据包,导致丢包

    一般来说,服务器负载过高有两个原因:收到的udp包过多;服务器进程存在性能瓶颈。如果收到的udp包过多,就要考虑扩容了,从日常运营的经验来看,公司现有的B5机器,在业务逻辑不复杂(简单的打包解包和内存hash等操作)、不超过网卡流量限制的情况下,每秒可以处理25万个udp包。至于如何提高服务器的性能,属于高性能服务器的设计和实现范畴,功力有限,不敢在这里班门弄斧,自己平时使用最多也就是三板斧:top+strace+ltrace,先使用top查看cpu内核态时间和用户态时间的比例,如果内核态时间占大头,就用strace查看主要的系统调用有哪些;如果如果用户态时间占大头,就用ltrace查看主要的库函数调用有哪些。找到性能瓶颈后,想办法优化系统架构和业务逻辑,减少不必要的系统调用和库函数调用。从以往的经验来看,很容易犯的一个错误是调用不必要的memsetmemcpy操作一大片内存,当请求量小的时候,发现不了问题,一旦突发的请求过来,触发大量的memsetmemcpy操作,占用了cpu资源,导致丢包和滚雪球,让人措手不及,所以系统上线前,一定要做好压力测试,通过压力测试找出性能瓶颈,将危险消灭在萌芽状态。

     

    3)        磁盘IO

        服务器有大量IO操作,会导致进程阻塞,cpu都在等待磁盘IO,不能及时处理内核socket缓冲区中的udp数据包。如果业务本身就是IO密集型的,要考虑在架构上进行优化,合理使用缓存降低磁盘IO。这里有一个容易忽视的问题:很多服务器都有在本地磁盘记录日志的功能,由于运维误操作导致日志记录的级别过高,或者某些错误突然大量出现,使得往磁盘写日志的IO请求量很大,磁盘IO忙,导致udp丢包。对于运维误操作,可以加强运营环境的管理,防止出错。如果业务确实需要记录大量的日志,可以使用内存log或者远程log

       

    4)        物理内存不够用,出现swap交换

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

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

     

    5)        磁盘满导致无法IO

        没有规划好磁盘的使用,监控不到位,导致磁盘被写满后服务器进程无法IO,处于阻塞状态。公司的监控中心对机器的磁盘使用率有监控,使用率超过95%会通知机器负责人处理。但是如果机器负责人错过了告警,或者没有及时处理告警,仍然会导致磁盘被写满。最根本的办法是规划好磁盘的使用,防止业务数据或日志文件把磁盘塞满,同时加强监控,例如开发一个通用的工具,当磁盘使用率达到80%时就持续告警,留出充足的反应时间

    展开全文
  • UDP主要丢包原因及具体问题分析   一、主要丢包原因   1、接收端处理时间过长导致丢包:调用recv方法接收端收到数据后,处理数据花了一些时间,处理完后再次调用recv方法,在这二次调用间隔里,发过来的包可能...
  • 1. 测试UDP丢包率 30个现成以5Mbps速度测试60siperf -u -c 目的IP -b 5M -P 30 -t 602. 测试TCP丢包率iperf -c 目的IP -b 5M -P 30 -t 60
  • udp丢包分析》

    2020-04-23 10:27:08
    UDP主要丢包原因及具体问题分析 一、主要丢包原因 1、接收端处理时间过长导致丢包:调用recv方法接收端收到数据后,处理数据花了一些时间,处理完后再次调用recv方法,在这二次调用间隔里,发过来的包可能丢失。对于...
  • 2019独角兽企业重金招聘Python工程师标准>>> ...
  • 环境:redhat6.9 服务端:192.168.7.134 客户端:192.168.7.132 测试工具:iperf3:参数如下: 工具下载地址... 解压压缩包进入iperf-3.0.12文件夹 1. cd iperf-3.0.12 ...3....
  • UDP数据包丢包

    2018-06-07 16:09:54
    UDP数据包丢包UDP数据包的理论长度udp数据包的理论长度是多少,合适的udp数据包应该是多少呢?从TCP-IP详解卷一第11章的udp数据包的包头可以看出,udp的最大包长度是2^16-1的个字节。由于udp包头占8个字节,而在ip层...
  • UDP数据包长度 UDP数据包的理论长度 ...从TCP-IP详解卷一第11章的udp数据包的包头可以看出,udp的最大长度是2^16-1的个字节。由于udp包头占8个字节,而在ip层进行封装后的ip包头占去20字
  • TC_QDisc 模拟网络丢包、延时、重复、损坏TC_QDisc 模拟网络丢包、延时、重复、损坏TC_QDisc 模拟网络丢包、延时、重复、损坏
  • Linux 上,编写一个每秒接收 100万UDP数据包的程序究竟有多难? 写的不错,转载一下 1. UDP概念  用户数据报协议(英语:User Datagram Protocol,缩写为 UDP),又称使用者资料协定,是一个简单的...
  • UDP数据包长度 UDP数据包的理论长度 ...从TCP-IP详解卷一第11章的udp数据包的包头可以看出,udp的最大长度是2^16-1的个字节。由于udp包头占8个字节,而在ip层进行封装后的ip包头占去20字节,所以这个是udp数...
  • LinuxUDP/TCP协议

    2018-07-03 21:50:34
    我们知道UDP/TCP这两个协议是在传输层上面的,传输层的主要功能是实现分布式进程通信。 下面我们来分别介绍一下UPD和TCP协议 一、UDP又叫用户数据报协议 UDP协议端格式: 解释说明: 16位UDP长度,表示整个...
1 2 3 4 5 ... 20
收藏数 4,812
精华内容 1,924
关键字:

linux udp丢包检测