ab的使用和行为分析

ab的全称是Apache Benchmark。用于测试HTTP服务器的性能。

ab命令会创建很多的并发访问连接，使用多线程模拟多个访问者同时对某一URL地址进行访问。支持http和https。代码是C语言书写的。

使用举例：

ab -c 20 -n 10000 -k http://172.16.1.100:10000/

选项说明：

-c表示并发连接数。需要注意如果请求很少，可能达不到指定的并发连接数。最大值为20000。要想测试更大的值，需要运行多个实例。

-n是请求总数。

-k表示使用HTTP持久连接。

-B 指定客户端地址。

-s指定等待应答的超时时间，默认是30秒。

功能：

测试吞吐量。使用-k有利于吞吐量。这是ab最适合的测试。

测试并发连接数。一定要使用-k。还要将-n的值设置的远远大于-c的值，因为所有事务都完成后连接就断开了。因为无法让ab发送请求的速度慢一些，每秒rps太大，消耗太多资源。所以其实ab并不太适合用来测试并发连接数。

测试每秒新建连接数。这个时候建议不使用-k。

场景分析：

服务器端是apache。

场景1、ab -n 1000 -c 2 -k http://172.16.1.27/。Apache使用默认配置。

一个连接处理了100个事务后，服务器发送FIN报文断开连接，客户端重新发起连接。apache MaxKeepAliveRequests的缺省值是100。

同时最多两条工作的连接，总共建立过10条TCP连接，客户端TCP端口从一个随机位置开始选取，17806、17808、17810、17812、17814、17816、17818、17820、17822、17824。

场景2、ab -n 1000 -c 2 -k http://172.16.1.27/。修改apache服务器配置为MaxKeepAliveRequests 100000。

总共只建立两个连接。直到测试完成了，由客户端主动发送fin报文，断开连接。

场景3：

ab -n 10 -c 2 http://172.16.1.27/。没使用-k选项时，每次事务完成，服务器就会发送FIN报文断开连接。然后客户端使用一个新的端口建立新的连接。因为是服务器主动发送fin报文，客户端在收到服务器的fin报文之后，就立刻发送syn重建连接，这个时候原来的连接处于close_wait状态，原来的端口还不能使用，所以选用新的端口来建立连接。客户端IP协议栈配置了tcp_tw_reuse=1，在这里没有什么作用。因为是服务器主动发送的FIN报文，所以客户端根本不会进入time_wait状态，而是在发送了fin+ack、并且服务器回复了ack后，进入close状态，这时原来的端口就彻底释放了。ab -n 100000 -c 100 http://172.16.1.27/也能够全部成功，而且4.8秒就完成了，这个时候客户端和服务器端肯定都重复使用了之前的端口。这里apache服务器要配置tcp_tw_reuse=1、tcp_tw_recycle = 1，否则客户端的端口号被遍历完后，apache会因为那些连接还处于timewait状态而拒绝再次的连接请求。timewait的超时时间是60秒。

报文分析：

对于每个事务：

情况1：客户端发送HTTP request，服务器发送HTTP response（捎带ACK），客户端发送一个ACK。一个事务3个报文。

情况2：客户端发送HTTP request，服务器发送TCP ACK，服务器发送HTTP response，客户端发送一个ACK。一个事务4个报文。

大多数是情况1，少部分是情况2。情况2是因为有时候服务器回复HTTP response比较慢，服务器端的TCP需要先行回复一个TCP ACK报文给客户端，避免客户端因为超时而重传请求。

每次事务最后一个报文客户端发送的ACK并没有捎带下一个事务的HTTP request。

说明：这里的HTTP response内容很少，所以可以放进一个报文中。内容大了，就需要多个报文来承载。

每次建立连接使用3个报文。每次断开连接使用4个报文。是标准的三次握手和4次挥手。建立和断开连接的报文中，没有捎带http请求或者应答。