柴少的官方网站 技术在学习中进步,水平在分享中升华

网络测试工具

网络压缩测试工具多种多样,这里也不详细一一列举了,就简单记录一下。

#首先有个Google的BBR优化算法非常牛逼,最新版本的Linux内核已经集成了该算法,该算法是一个优化网络堵塞的算法。开启BBR的机器首先在网络正常的情况下就比不开启的机器网络性能要高20%左右,随着丢包率和延时的增大,BBR算法的跟不开启BBR算法的Linux机器在响应速度上差距也越来越大,所以BBR算法挺厉害的,在这里记录一下。

部署链接地址:https://segmentfault.com/a/1190000008395823

http://51.ruyo.net/2783.html

一、网络丢包延时测试工具

#当然你可以用iptables来模拟丢包延时场景,当然也可以使用其他的工具。这里记录TC(Linux下流量控制工具)

http://blog.csdn.net/u011641885/article/details/45640313   #这篇博客记录的很详细了,我就不多说了。

操作很简单,比如我们的网卡是eth0:

#tc qdisc show dev eth0    #查看eth0网卡的规则,下面是h没有任何限制规则的情况

qdisc mq 0: root 
qdisc fq 0: parent :8 limit 10000p flow_limit 100p buckets 1024 quantum 3028 initial_quantum 15140 
qdisc fq 0: parent :7 limit 10000p flow_limit 100p buckets 1024 quantum 3028 initial_quantum 15140 
qdisc fq 0: parent :6 limit 10000p flow_limit 100p buckets 1024 quantum 3028 initial_quantum 15140 
qdisc fq 0: parent :5 limit 10000p flow_limit 100p buckets 1024 quantum 3028 initial_quantum 15140 
qdisc fq 0: parent :4 limit 10000p flow_limit 100p buckets 1024 quantum 3028 initial_quantum 15140 
qdisc fq 0: parent :3 limit 10000p flow_limit 100p buckets 1024 quantum 3028 initial_quantum 15140 
qdisc fq 0: parent :2 limit 10000p flow_limit 100p buckets 1024 quantum 3028 initial_quantum 15140 
qdisc fq 0: parent :1 limit 10000p flow_limit 100p buckets 1024 quantum 3028 initial_quantum 15140

#tc qdisc add dev eth0 root netem delay 100ms     #这是让延时+100ms 

#tc qdisc show dev eth0    #再次查看可以看到有个100ms的规则

qdisc netem 800e: root refcnt 9 limit 1000 delay 100.0ms

#tc qdisc del dev eth0 root netem delay 100ms    #要是测试其他的延时测试,要先将之前的规则删除掉

#tc qdisc add dev eth0 root netem delay 300ms   #再添加新的测试规则就可以了。

#tc qdisc add  dev eth0 root netem loss 10%  #丢包率也是这样依次类推

#当然TC工具不简单的用于丢包率测试,也可以给主机做限速或者指定IP来限速,还是有一些实际使用场景的。

二、网络压测工具

2.1 网络I/O测试的测试用例:

TCP 吞吐测试
TCP 连接数测试
TCP 单连接多交易测试测试
TCP 发包率测试
UDP 吞吐测试
UDP 单连接多交易测试测试
UDP 发包率测试
UDP 单连接多交易测试测试
UDP 发包率测试
业务模型网络模拟测试。

2.2 测试工具

       这里记录一下Netperf工具(www.netperf.org),Netperf是一款网络性能的测量工具,主要针对基于TCP或UDP的传输。Netperf根据应用的不同,可以进行不同模式的网络性能测试,即批量数据传输(Bulk Data Transfer)模式和请求/应答(Request/Reponse)模式。Netperf测试结果所反映的是一个系统能够以多块的速度向另外一个系统发送数据,以及另外一个系统能够以多快的速度接收数据。

      Netperf工具以Client/Server方式工作。Server端是Netserver,用来侦听来自Client端的连接,Client端是Netperf,用来向Server发起网络测试。在Client与server之间首先建议一个控制连接,传递有关测试配置的信息,以及测试的结果;在控制连接建立并传递了测试配置信息之后,Client与Server之间会再建立一个测试连接,用来来回传递着特殊的流量模式,以测试网络的性能。

      进行网络测试时,一般有如下两个关键指标:

BPS 网络吞吐量: 一分钟经过网卡的数据流量
PPS发包率: 一分钟经过网卡数据包的数量

     Netperf可以模拟如下三种不同的TCP流量模式:

单TCP连接: 连接大量数据
单TCP连接:大量的连接次数
多TCP连接:每个连接中一对请求/应答的交易方式

   Netperf可以模拟UDP的流量模式:

单向批量传输
请求/应答的交易方式

   Netperf常用参数如下:

-H  #指定netserver的server  IP地址
-l  # 指定测试的时间长度,单位为妙
-t  #指定进行的测试类型,包括TCP_STREAM、UDP_STREAM、TCP_RR、TCP_CRR、UDP_RR等。

每个测试项的意义如下:

TCP_STREAM  #Netperf默认情况下进行TCP批量传输,即-t TCP_STREAM。测试过程中,netperf向netserver发送批量的TCP数据分组,以确定数据传输过程中的吞吐量。
UDP_STREAM   #UDP_STREAM用来测试进行UDP批量传输时的网络性能。需要特别注意的是,此时测试分组的大小不得大于socket的发送与接收缓冲大小,否则,netperf会报错。
TCP_RR  #TCP_RR方式的测试对象是多次TCP Request和Response的交易过程,但是它们发生的同一个TCP连接中,这种模式常常出现在数据库应用中。数据库的Client程序与Server程序建议一个TCP连接以后,就在这个连接中传送数据库的多次交易过程。
TCP_CRR  #与TCP_RR不同,TCP_CRR为每次交易建立一个新的TCP连接。最典型的应用就是HTTP,每次HTTP交易是在一条单独的TCP连接中进行的。因此,由于需要不停的建立新的TCP连接,并且在交易结束后拆除TCP连接,交易率一定会受到很大的影响。
UDP_RR  #UDP_RR方式使用UDP分组进行request/response的交易过程。由于没有TCP连接所带来的负担,所以推测交易率一定会有相应的提升。

#由于Netperf2.xx版本只支持每个实例一个线程。由于一个线程产生的TCP交易远远达不到系统瓶颈,需要开多个netperf实例,并将每个实例的结果相加。当然一般结合网络流量监控工具测试使用。

服务端的部署:

# wget https://github.com/HewlettPackard/netperf/archive/netperf-2.7.0.zip
# unzip netperf-2.7.0.zip

# cd  netperf-netperf-2.7.0/
# ./configure  --prefix=/usr/local/netperf

# make && make install

# /usr/local/netperf/bin/netserver   #启动一下netserver服务

# netstat  -lntup|grep netserver   #多了一个12865端口

tcp6       0      0 :::12865                :::*                    LISTEN      4487/netserver

客户端的部署:

# wget https://github.com/HewlettPackard/netperf/archive/netperf-2.7.0.zip
# unzip netperf-2.7.0.zip

# cd  netperf-netperf-2.7.0/
# ./configure  --prefix=/usr/local/netperf

# make && make install

# /usr/local/netperf/bin/netperf -H 192.168.14.61 -l 60 -t TCP_STREAM   #测试一下

MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.14.61 () port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    60.00    16052.36

#87380是远端系统(即server)使用大小为87380字节的socker接收缓冲

#16384是本地系统(即client)使用大小为16384字节的socket发送缓冲。

#16384是向远端系统发送的测试分组大小为16384字节

#60是测试经历的时间为60秒。

#16052.36是吞吐量的测试结果为16052.36*10^6bits/秒。

在缺省情况下,netperf向发送的测试分组大小设置为本地系统所使用的socket发送缓冲大小。
TCP_STREAM方式下与测试相关的局部参数如下表所示:

-s size:设置本地系统的socket发送与接收缓冲大小;
-S size:设置远端系统的socket发送与接收缓冲大小;
-m size:设置本地系统发送测试分组的大小;
-M size:设置远端系统接收测试分组的大小;
-D:对本地与远端系统的socket设置TCP_NODELAY选项I/O测试。

#其它的网络性能测试工具,如dbs, iperf, pathrate, nettest, netlogger, tcptrace, ntop等。

#还有一个Kcp协议非常也是非常吊的,特点是流量换延迟,快速重传,流控优化,una/ack优化等。:

KCP是一个快速可靠协议,能以比 TCP浪费10%-20%的带宽的代价,换取平均延迟降低 30%-40%,且最大延迟降低三倍的传输效果。如果不丢包不使用也看不出效果,但是公网就不一样了,移动网丢包更严重,所以效果就出来了。参考链接:http://www.skywind.me/blog/archives/1048

作者:忙碌的柴少 分类:运维工具使用 浏览:8457 评论:5
留言列表
阿文
阿文 博主,您好,
对于网络性能测试这一块内容,我还是个孩子。我用的是Netperf-2.pl1.exe(Windows版本)即Client端,
用命令 Netperf-2.pl1.exe -H (IP远程,我采用的是租用的VPS) 回车后,一直显示:‘远程端是否开放或监听12865端口’此类信息。
我一直怀疑,访问建立控制连接之前是不是先要求本地能够Ping 通远端?而且网络处于持续稳定状态,否则,测试连接无法建立并保持。  回复
阿文
阿文 我昨天测试,远端侦听12865端口,本地(Windows)通过上面命令连接,还是连接不到,我用的代理是SS代理,
我还有个疑问:
1、 用上述命令和远端建立控制连接,是不是还要求本地能够访问外网(毋庸置疑)?
2、然后,我用VMware装了虚拟机然后用Linux系统进行测量,发现可以PING 通远程IP,而且很稳定。用上述命令还是无法访问。
您发表这篇博文久了,相信您能看到我的评论,先谢谢您了!  回复
访客
访客 可以先telnet下端口通不通,windows应该有防火墙之类的问题  回复
访客
访客 谢谢您的回复,我试试。  回复
访客
访客 您说的没错,是远端UFW打开了,不是本地的防火墙,然后用Telnet测试端口发现,该端口可以访问!
真的谢谢您!  回复
发表评论
来宾的头像