柴少的官方网站-网络测试工具

2017年12月04日 19:08:59

网络测试工具

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

#首先有个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来限速,还是有一些实际使用场景的。

1.2 网络限速

# man tc #可以跟着手册详细了解下相关命令,这里就不做翻译解释了

tc 的流量控制机制通过 qdisc、class、filter 的组合，形成树结构，根节点是 root qdisc，叶子节点是其它qdisc，中间的节点用于细分流量到子节点。数据包先进入root qdisc，然后通过filter进入不同的class，之后再继续进一步细分，直到到达最终的 qdisc，然后发往实际网卡。

下面是一个网卡限速的例子(如果没办法在网关上面针对指定机器做出网限速,你又不想这台机器拉爆整个网络)那就可以考虑使用tc进行网卡限速

tc qdisc del dev eth0 root   #先清空配置
tc qdisc add dev eth0 root handle 1: htb default 2  #创建一个HTB的类,流量的限制就是在这里限制的
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 2000kbit ceil 3000kbit prio 2  #创建一个过滤规则,限制速率每秒2000kb,突发可以到3000kb
tc class add dev eth0 parent 1:1 classid 1:3 htb rate 100mbit ceil 200mbit prio 2    #再创建一个过滤规则,限制速率每秒100mb,突发可以到300mb
tc filter add dev eth0 protocol ip parent 1: prio 50 u32 match ip dst 0.0.0.0/0 flowid 1:2  #默认所有的的都走1:2这个低class类
tc filter add dev eth0 protocol ip parent 1: prio 40 u32 match ip dst 192.0.0.0/8 flowid 1:3 #prio值越小优先级越高,所以内网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