之前文章《Linux服务器性能评估与优化(一)》太长，阅读不方便，因此拆分成系列博文：
1、网络性能评估
网络是所有子系统中最难监测的一个， 因为网络比较抽象， 在监测时有很多在系统可控制之外的因素如延迟，冲突，拥塞和丢包等对监测产生影响。
测量网络性能的五项指标是：
- 可用性（availability）
- 响应时间（response time）
- 网络利用率（network utilization）
- 网络吞吐量（network throughput）
- 网络带宽容量（network bandwidth capacity）
1． 可用性
测试网络性能的第一步是确定网络是否正常工作，最简单的方法是使用 ping 命令。通过向远端的机器发送 icmp echo request，并等待接收 icmp echo reply 来判断远端的机器是否连通，网络是否正常工作。
Ping 命令有非常丰富的命令选项，比如 -c 可以指定发送 echo request 的个数，-s 可以指定每次发送的 ping 包大小。
网络设备内部一般有多个缓冲池，不同的缓冲池使用不同的缓冲区大小，分别用来处理不同大小的分组（packet）。例如交换机中通常具有三种类型的包缓冲：一类针对小的分组，一类针对中等大小的分组，还有一类针对大的分组。为了测试这样的网络设备，测试工具必须要具有发送不同大小分组的能力。Ping 命令的 -s 就可以使用在这种场合。
2． 响应时间
Ping 命令的 echo request/reply 一次往返所花费时间就是响应时间。有很多因素会影响到响应时间，如网段的负荷，网络主机的负荷，广播风暴，工作不正常的网络设备等等。
在网络工作正常时，记录下正常的响应时间。当用户抱怨网络的反应时间慢时，就可以将现在的响应时间与正常的响应时间对比，如果两者差值的波动很大，就能说明网络设备存在故障。
3． 网络利用率
网络利用率是指网络被使用的时间占总时间（即被使用的时间+空闲的时间）的比例。比如，Ethernet 虽然是共享的，但同时却只能有一个报文在传输。因此在任一时刻，Ethernet 或者是 100% 的利用率，或者是 0% 的利用率。
计算一个网段的网络利用率相对比较容易，但是确定一个网络的利用率就比较复杂。因此，网络测试工具一般使用网络吞吐量和网络带宽容量来确定网络中两个节点之间的性能。
4． 网络吞吐量
网络吞吐量是指在某个时刻，在网络中的两个节点之间，提供给网络应用的剩余带宽。
网络吞吐量可以帮组寻找网络路径中的瓶颈。比如，即使 client 和 server 都被分别连接到各自的 100M Ethernet 上，但是如果这两个 100M 的Ethernet 被 10M 的 Ethernet 连接起来，那么 10M 的 Ethernet 就是网络的瓶颈。
网络吞吐量非常依赖于当前的网络负载情况。因此，为了得到正确的网络吞吐量，最好在不同时间（一天中的不同时刻，或者一周中不同的天）分别进行测试，只有这样才能得到对网络吞吐量的全面认识。
有些网络应用程序在开发过程的测试中能够正常运行，但是到实际的网络环境中却无法正常工作（由于没有足够的网络吞吐量）。这是因为测试只是在空闲的网络环境中，没有考虑到实际的网络环境中还存在着其它的各种网络流量。所以，网络吞吐量定义为剩余带宽是有实际意义的。
5． 网络带宽容量
与网络吞吐量不同，网络带宽容量指的是在网络的两个节点之间的最大可用带宽。这是由组成网络的设备的能力所决定的。
测试网络带宽容量有两个困难之处：在网络存在其它网络流量的时候，如何得知网络的最大可用带宽；在测试过程中，如何对现有的网络流量不造成影响。网络测试工具一般采用 packet pairs 和 packet trains 技术来克服这样的困难。
2、常用的命令工具
（1）通过ping命令检测网络的连通性
（2）通过netstat –i组合检测网络接口状况
（3）通过netstat –r组合检测系统的路由表信息
（4）通过sar –n组合显示系统的网络运行状态
netstat -antl 查看所有tcp status：
注意：可以通过netstat查看是否timewait过多的情况，导致端口不够用，在短连接服务中且大并发情况下，要不系统的net.ipv4.tcp_tw_reuse、net.ipv4.tcp_tw_recycle两个选项打开，允许端口重用。
linux查看tcp的状态命令：
1)、netstat -nat 查看TCP各个状态的数量
2)、lsof -i:port 可以检测到打开套接字的状况
3)、 sar -n SOCK 查看tcp创建的连接数
4)、tcpdump -iany tcp port 9000 对tcp端口为9000的进行抓包
5)、tcpdump dst port 9000 -w dump9000.pcap 对tcp目标端口为9000的进行抓包保存pcap文件wireshark分析。
6)、tcpdump tcp port 9000 -n -X -s 0 -w tcp.cap 对tcp/http目标端口为9000的进行抓包保存pcap文件wireshark分析。
3、网络吞吐量监测
监测网络吞吐量最好的办法是在两个系统之间发送流量并统计其延迟和速度。
3）测试工具：使用 iptraf 监测本地吞吐量
简单安装：yum install -y iptraf
在centos7.2使用的命令是iptraf-ng：
使用iptraf-ng -d eth0
iptraf 工具可提供以太网卡的吞吐量情况：
# iptraf -d eth0
上面的数据显示被测试系统正以 61mbps（7.65M）频率发送数据，相比于 100mbps 网络这有点低。
使用iptraf 命令找出流量使用情况和接口、端口信息
输入命令： iptraf
然后iptraf 会给出如下所示的输出。结果给出了两样东西，源地址和网络端口号。在第一次出现的welcome屏幕上按下Enter，就可以看见具体的选项了。一旦你选择了在所有接口之上的“IP traffic monitor”选项：
你会看到如下的输出结果。
4、使用 netperf 监测
与 iptraf 的动态监测不一样的是 netperf 使用可控方式测试网络， 这一点对测试一个客户端到一个高负载服务器之间的吞吐量很有帮助，netperf 工具是以 C/S 模式运行。
首先需要在服务器上运行 netperf 服务端：
在服务端启动server# netserver
Unable to start netserver with 'IN(6)ADDR_ANY' port '12865' and family AF_UNSPEC
4.1、在client端测试吞吐量
# /usr/local/bin/netperf -H 10.165.112.121 -l 10 [-t TCP_STREAM]
吞吐量的测试结果为900.42Mbits/秒
从netperf的结果输出中，我们可以知道以下的一些信息：
1） 远端系统（即server）使用大小为87380字节的socket接收缓冲
2） 本地系统（即client）使用大小为16384字节的socket发送缓冲
3） 向远端系统发送的测试分组大小为16384字节
4） 测试经历的时间为10.03秒
5） 吞吐量的测试结果为900.42Mbits/秒
在默认情况下，netperf向发送的测试分组大小设置为本地系统所使用的socket发送缓冲大小。
TCP_STREAM方式下与测试相关的局部参数如下表所示：
参数 说明
-W send,recv 设置本地,远端系统接收测试分组的大小: Set the number of send,recv buffers
通过修改以上的参数，并观察结果的变化，我们可以确定是什么因素影响了连接的吞吐量。例如，如果怀疑路由器由于缺乏足够的缓冲区空间，使得转发大的分组时存在问题，就可以增加测试分组（-W）的大小，以观察吞吐量的变化：
/usr/local/bin/netperf -H 10.165.112.121 -l 10 -W 2048
在这里，测试分组的大小减少到2048字节，而吞吐量却没有很大的变化（与前面例子中测试分组大小为16K字节相比）。相反，如果吞吐量有了较大的提升，则说明在网络中间的路由器确实存在缓冲区的问题。
4.2、测试请求/应答（request/response）网络流量的性能
另一类常见的网络流量类型是应用在client/server结构中的request/response模式。在每次交易（transaction）中，client向server发出小的查询分组，server接收到请求，经处理后返回大的结果数据。
1． TCP_RR
TCP_RR方式的测试对象是多次TCP request和response的交易过程，但是它们发生在同一个TCP连接中，这种模式常常出现在数据库应用中。数据库的client程序与server程序建立一个TCP连接以后，就在这个连接中传送数据库的多次交易过程。
/usr/local/bin/netperf -H 10.165.112.121 -l 10 -t TCP_RR
Netperf输出的结果也是由两行组成。
第一行显示本地系统的情况，
第二行显示的是远端系统的信息。
数据显示网络可支持交易速率psh/ack为3642.74次/秒。
注意到这里每次交易中的request (PSH)和response (ACK)分组的大小都为1K个字节，不具有很大的实际意义。
可以通过测试相关的参数来改变request和response分组的大小，TCP_RR方式下的参数如下表所示：
参数 说明
-r req,resp 设置request和reponse分组的大小
通过使用-r参数，下面使用32个字节的请求和2048个字节 的应答, 我们可以进行更有实际意义的测试：
netperf -H 10.165.112.121 -l 10 -t TCP_RR -r 32,2048
2． TCP_CRR
与TCP_RR不同，TCP_CRR为每次交易建立一个新的TCP连接。最典型的应用就是HTTP，每次HTTP交易是在一条单独的TCP连接中进行的。因此，由于需要不停地建立新的TCP连接，并且在交易结束后拆除TCP连接，交易率一定会受到很大的影响。
netperf -H 10.165.112.121 -l 10 -t TCP_CRR -r 2048,32768
请求交易速率也明显的降低了，只有1607.33次/秒。
5、sar查看网卡性能
sar查看网卡性能：sar -n DEV 1 100
Linux 2.6.32-431.20.3.el6.x86_64 (iZ25ug3hg9iZ) 09/18/2014 _x86_64_ (4 CPU)
04:01:23 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
04:01:24 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
04:01:24 PM eth0 4.04 0.00 0.16 0.00 0.00 0.00 0.00
04:01:24 PM eth1 26.26 0.00 1.17 0.00 0.00 0.00 0.00
各列含义：
IFACELAN接口
rxpck/s每秒钟接收的数据包
txpck/s每秒钟发送的数据包
rxbyt/s或者rxkB/s每秒钟接收的字节数（上传速度，网卡入流量）
txbyt/s或者txkB/s每秒钟发送的字节数（下载速度，网卡出流量）
rxcmp/s每秒钟接收的压缩数据包
txcmp/s每秒钟发送的压缩数据包
rxmcst/s每秒钟接收的多播数据包
其实中间的IFACELAN bond0是虚拟设备。在RH中，多个物理网卡帮定为一个逻辑bonding设备，通过把多个物理网卡帮定为一个逻辑设备，可以实现增加带宽吞吐量，提供冗余。如何进行虚拟化和模式选择，请参考下面两篇文章。
6、实际遇到的问题
我们实际遇到的问题：
我们在服务器tcpdump抓包发现存在的TCP Retransmission的现象
从图中可以看到TCP三次握手的第一步SYN出现重传。客户端发送SYN后如果没有收到服务器放的ACK确认，就会导致重传的发生，因为客户端机器认为远程机器没有收到包，而发生重新发送SYN包的事件。
既然在服务器上抓包能捕获SYN的请求，那就说明服务器端接收到了请求但是没有回应ACK包：
我们查看内核参数中打开了net.ipv4.tcp_tw_recycle = 1, 在tcp_tw_recycle模式下，服务器判断是无效连接的条件是：
1、来自对端的tcp syn请求携带时间戳
2、本机在MSL时间内接收过来自同一台ip机器的tcp数据
3、新连接的时间戳小于上次tcp数据的时间戳
以上条件满足时，连接请求会被拒绝
因此在高并发的情况下，就有可能导致服务器收到SYN但是不会向客户端发送SYN+ACK包。因为MSL时间内接收过来自同一台ip机器的tcp数据，导致服务器认为包不可信而丢弃。
我们通过 netperf 监测TCP的应答/响应性能对比：
打开net.ipv4.tcp_tw_recycle = 1，请求交易速率只有594.97次/秒：
关闭net.ipv4.tcp_tw_recycle = 0，请求交易速率提高到了1406.29次/秒：
