Linux性能之网络

所有的子系统中，最后说明网络，是由于网络是最难进行监控的。这是由于网络是比较抽象的一个。当监控网络的性能的时候，有许多的因素需要考虑。这些因素包括延迟、冲突、拥塞、误码丢包等等。接下来，将讲一下怎么去检测网络的性能（本小节涉及到关于网络的命令有ethtool、iptraf、iperf、netperf、tcptrace）。

首先是，以太网的配置设置。

除非是显式地改变，所有以太网的速度都是自动协商的。这是由于一个网络环境中有多个网络设备，各个设备的速度是不同的，是全双工还是半双工也不同，采用这种方式是极其有效地方式。以下示例的系统，有一块100Base Tx（ps：100表示100Mbps，Base表示采用基带传输，T表示使用的材料，这个表示使用双绞线进行传输）的网卡，协商后的速率却是10Mbps。使用ethtool工具可以很明显地看到这一点：

# ethtool eth0

结果如下：

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

然后使用下面的命令可以设置网卡速率为100Mbps并关闭自动协商速率选项。

# ethtool -s eth0 speed 100 duplex full autoneg off

然后再看看是否生效

# ethtool eth0

结果如下：

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

网络的吞吐量：

知道怎么查看网卡具体的配置，现在看看怎么监控网络的吞吐量。仅通过一个网卡接口当前同步，并不能说明它存在带宽问题。控制或者调整两个主机之间的交换机、网线、路由器是不可能的。测试一个网络吞吐量最好的方式是两个系统之间发送数据，然后测量其速度与延迟之类的数据。

这里首先使用iptraf (ps：了解此程序可登录这里http://iptraf.seul.org)测试本地吞吐量，iptraf显示了每一块以太网接口的吞吐量的情况（ps：流量监控的命令还可以用ifstat、iftop这两个命令）。终端输入下面的命令：

# iptraf –d eth0

监控的结果如下：

从这个监控的结果中可以看出，发送数据的速率为61Mbps，这个速度低于100Mbps。

测试完本地的吞吐量后，接下来我们测试端点的吞吐量，使用的工具是netperf。与iptraf通过被动第指定接口的方式监控流量不同，netperf容许系统管理员测试整个网络的吞吐量。这一点对于测试一个客户主机到一个高负载的服务器（文件或者web服务器）的吞吐量非常有用。netperf可以运行在client和server两种模式下。为了实现一个基本的吞吐量的测试，必须在服务器上运行netperf服务器：

# netserver
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC

通过netperf可以执行多个测试，众多测试中有个标准的吞吐量测试，以下是局域网内，客户端执行一个30s的基于TCP的吞吐量的测试：

# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.230 (192.168.1.230) 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   30.02  89.46

从上面的输出可以看出来，网络的吞吐量维持在89Mbps左右，也并未达到100Mbps。

将此局域网移到54Mbps的无线网络的环境里面，距离路由器10英尺，可以看到吞吐量大幅度地下降，用笔记本测试时候，吞吐量只有14Mbps，而不是54Mbps。

# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.215 (192.168.1.215) 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   30.10  14.09

距离路由器50英尺，并且在路由器的下一层楼，减少到了5Mbps

#netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.215 (192.168.1.215) 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   30.64  5.05

测试公网时候降低到1Mbps以下

#netperf -H litemail.org -p 1500 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
litemail.org (72.249.104.148) 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   31.58  0.93

最后一个测试下VPN服务器，这个是所有测试中吞吐量最差的，仅仅有0.5Mbps。下面是测试结果：

#netperf -H 10.0.1.129 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
10.0.1.129 (10.0.1.129) 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   31.99  0.51

另一个比较有用的测试是，使用netperf来监控每秒TCP连接的数目以及响应连接发生的数目，这个测试通过创建一个简单的TCP连接，然后通过这个连接发送多个请求或者接受请求的队列（ACK包的来回发送都是以1字节）。这个过程和RDBMS执行多个数据传输过程类似，或者和一个邮件服务器在一个连接里面通过管道处理多个消息。以下的例子显示的就是在30秒内，TCP的请求与回应：

#netperf -t TCP_RR -H 192.168.1.230 -l 30
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 192.168.1.230 (192.168.1.230) port 0 AF_INET
Local /Remote
Socket Size  Request Resp. Elapsed  Trans.
Send   Recv  Size    Size  Time     Rate
bytes  Bytes bytes   bytes secs.    per sec
16384  87380    1      1   30.00    4453.80
16384 87380

从上面的输出可以看出，此网络支持传输速度为每秒4453 psh/ack，并使用1个字节的有效载荷。这一点现实中是不可能，因为在许多请求中，特别是回应中，会远远大于一个字节。在实际的系统中，netperf使用一个默认的数值，2k作为请求数据，32k作为回应数据，然后有如下的结果：

#netperf -t TCP_RR -H 192.168.1.230 -l 30 -- -r 2048,32768
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.230 (192.168.1.230) port 0 AF_INET
Local /Remote
Socket Size  Request Resp. Elapsed Trans.
Send   Recv  Size    Size  Time    Rate
bytes  Bytes bytes   bytes secs.   per sec
16384  87380 2048    32768 30.00   222.37
16384 87380

选择默认值之后，传输速率明显降低下来每秒222个传输连接。

利用iperf测试网络的利用率

在检查两个端点之间的连接时候，iperf与netperf的作用相似。不同的是iperf有许多围绕TCP/UDP更加深入的检测，比如窗大小和QoS的设置。此工具用来调整TCP/IP栈，然后测试这些栈的有效性。iperf可运行在sever或者client模式下，默认使用的端口为5001.

在服务器端开启服务使用下面的命令：

# iperf -s -D
Running Iperf Server as a daemon
The Iperf daemon process ID : 3655
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

下面我们在无线网络的环境里，客户端执行iperf进行网络吞吐量的迭代测试，并且此无线网络环境是满载的，有多个主机在下载镜像文件。然后客户端连接到服务器，每60秒测试一次带宽，每5秒打印一次结果：

# iperf -c 192.168.1.215 -t 60 -i 5
------------------------------------------------------------
Client connecting to 192.168.1.215, TCP port 5001
TCP window size: 25.6 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.224.150 port 51978 connected with
192.168.1.215 port 5001
[ ID] Interval       Transfer      Bandwidth
[ 3] 0.0- 5.0 sec    6.22 MBytes    10.4 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 5.0-10.0 sec    6.05 MBytes    10.1 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 10.0-15.0 sec   5.55 MBytes    9.32 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 15.0-20.0 sec   5.19 MBytes    8.70 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 20.0-25.0 sec   4.95 MBytes    8.30 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 25.0-30.0 sec   5.21 MBytes    8.74 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 30.0-35.0 sec   2.55 MBytes    4.29 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 35.0-40.0 sec   5.87 MBytes    9.84 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 40.0-45.0 sec   5.69 MBytes    9.54 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 45.0-50.0 sec   5.64 MBytes    9.46 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 50.0-55.0 sec   4.55 MBytes    7.64 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 55.0-60.0 sec   4.47 MBytes    7.50 Mbits/sec
[ ID] Interval       Transfer       Bandwidth
[ 3] 0.0-60.0 sec    61.9 MBytes    8.66 Mbits/sec

其他网络流量影响这个单一主机的带框，在60秒的间隔时间内，在4Mbits~10Mbits之间波动。

除了可以测试TCP，iperf也可以测试UDP，测试其数据包的丢失及其抖动。下面的iperf测试在54Mbps的无线网络环境里面。如前面的例子所展示，当前网络的吞吐量仅仅是54Mbits的九分之一。

#iperf -c 192.168.1.215 -b 10M
WARNING: option -b implies udp testing
------------------------------------------------------------
Client connecting to 192.168.1.215, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 107 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.224.150 port 33589 connected with 192.168.1.215 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 11.8 MBytes 9.90 Mbits/sec
[ 3] Sent 8420 datagrams
[ 3] Server Report:
[ ID] Interval     Transfer    Bandwidth      Jitter   Lost/Total  Datagrams
[ 3] 0.0-10.0 sec  6.50 MBytes 5.45 Mbits/sec 0.480 ms 3784/ 8419   (45%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order

本应当传输10M，当前只有5.45Mbit传输，包的丢失率在45%。

利用tcptrace分析独立的连接。tcptrace会显出出一次TCP连接详细的信息。此程序利用基于libpcap的文件，实现分析特定的TCP会话层。此程序可以抓取TCP流中难以抓取的信息，这些信息包括：

1、TCP重传信息。需要被重新发送的包的数量以及数据的大小。

2、TCP窗的大小。检测出慢连接中小窗的大小。

3、整个连接的吞吐量。

4、连接持续时间。

tcptrace的rpm安装包的地址：http://pkgs.repoforge.org/tcptrace/。tcptrace命令使用基于libpcap的文件作为输入。不带任何命令选项的时候，程序列出所有文件中抓取到的所有唯一的连接。下面的例子就是利用一个基于libpcap的文件bigstuff，对程序进行验证：

# tcptrace bigstuff
1 arg remaining, starting with 'bigstuff'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004
146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:01.634065, 89413 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
1: 192.168.1.60:pcanywherestat - 192.168.1.102:2571 (a2b) 404> 450<
2: 192.168.1.60:3356 - ftp.strongmail.net:21 (c2d) 35> 21<
3: 192.168.1.60:3825 - ftp.strongmail.net:65023 (e2f) 5> 4<
(complete)
4: 192.168.1.102:1339 - 205.188.8.194:5190 (g2h) 6> 6<
5: 192.168.1.102:1490 - cs127.msg.mud.yahoo.com:5050 (i2j) 5> 5<
6: py-in-f111.google.com:993 - 192.168.1.102:3785 (k2l) 13> 14<

上面的输出，每一个连接都有一个数字和它相关，都有源主机与目的主机。tcptrace使用最广泛的选项是-l与-o，这两个选项可以提供特定连接的详细参数。

下面的例子列出了bigbuff文件中#1号连接所有的信息。

# tcptrace -l -o1 bigstuff
1 arg remaining, starting with 'bigstuff'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004
146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:00.529361, 276008 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
32 TCP connections traced:
TCP connection 1:
host a: 192.168.1.60:pcanywherestat
host b: 192.168.1.102:2571
complete conn: no (SYNs: 0) (FINs: 0)
first packet: Sun Jul 20 15:58:05.472983 2008
last packet: Sun Jul 20 16:00:04.564716 2008
elapsed time: 0:01:59.091733
total packets: 854
filename: bigstuff
a->b:                    b->a:
total packets: 404             total packets: 450
ack pkts sent: 404             ack pkts sent: 450
pure acks sent: 13             pure acks sent: 320
sack pkts sent: 0              sack pkts sent: 0
dsack pkts sent: 0             dsack pkts sent: 0
max sack blks/ack: 0           max sack blks/ack: 0
unique bytes sent: 52608       unique bytes sent: 10624
actual data pkts: 391          actual data pkts: 130
actual data bytes: 52608       actual data bytes: 10624
rexmt data pkts: 0             rexmt data pkts: 0
rexmt data bytes: 0            rexmt data bytes: 0
zwnd probe pkts: 0             zwnd probe pkts: 0
zwnd probe bytes: 0            zwnd probe bytes: 0
outoforder pkts: 0             outoforder pkts: 0
pushed data pkts: 391          pushed data pkts: 130
SYN/FIN pkts sent: 0/0         SYN/FIN pkts sent: 0/0
urgent data pkts: 0  pkts      urgent data pkts: 0 pkts
urgent data bytes: 0 bytes     urgent data bytes: 0 bytes
mss requested: 0 bytes         mss requested: 0 bytes
max segm size: 560 bytes       max segm size: 176 bytes
min segm size: 48 bytes        min segm size: 80 bytes
avg segm size: 134 bytes       avg segm size: 81 bytes
max win adv: 19584 bytes       max win adv: 65535 bytes
min win adv: 19584 bytes       min win adv: 64287 bytes
zero win adv: 0 times          zero win adv: 0 times
avg win adv: 19584 bytes       avg win adv: 64949 bytes
initial window: 160 bytes      initial window: 0 bytes
initial window: 2 pkts         initial window: 0 pkts
ttl stream length: NA          ttl stream length: NA
missed data: NA                missed data: NA
truncated data: 36186 bytes    truncated data: 5164 bytes
truncated packets: 391 pkts    truncated packets: 130 pkts
data xmit time: 119.092 secs   data xmit time: 116.954 secs
idletime max: 441267.1 ms      idletime max: 441506.3 ms
throughput: 442 Bps            throughput: 89 Bps

计算重新传输的百分比：

确定那个连接有严重的重传问题并分析，这一点貌似是不可能的。tcptrace利用过滤和布尔表达式锁定问题连接。在一个有多个连接饱和的网络环境里，所有的连接都会重传的可能性是有的。这里的重点是那个连接重传的次数最多。

下面的例子中，tcptrace命令使用一个过滤器定位重传超过100段的连接：

# tcptrace -f'rexmit_segs>100' bigstuff
Output filter: ((c_rexmit_segs>100)OR(s_rexmit_segs>100))
1 arg remaining, starting with 'bigstuff'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004
146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:00.687788, 212431 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
16: ftp.strongmail.net:65014 - 192.168.1.60:2158 (ae2af) 18695> 9817<

从上面的数据中可以看出#16号连接超过了100次重传，然后我们分析第#16连接的详细情况：

# tcptrace -l -o16 bigstuff
arg remaining, starting with 'bigstuff'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004
146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:01.355964, 107752 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
32 TCP connections traced:
================================
TCP connection 16:
host ae: ftp.strongmail.net:65014
host af: 192.168.1.60:2158
complete conn: no (SYNs: 0) (FINs: 1)
first packet: Sun Jul 20 16:04:33.257606 2008
last packet: Sun Jul 20 16:07:22.317987 2008
elapsed time: 0:02:49.060381
total packets: 28512
filename: bigstuff
ae->af:                 af->ae:
<snip>
unique bytes sent: 25534744     unique bytes sent: 0
actual data pkts: 18695         actual data pkts: 0
actual data bytes: 25556632     actual data bytes: 0
rexmt data pkts: 1605           rexmt data pkts: 0
rexmt data bytes: 2188780       rexmt data bytes: 0

然后根据上面的信息计算重传率：

rexmt/actual * 100 = 重传率，所以根据上面计算重传率为1605*100/18695，最终的结果为8.5%。慢连接的原因就是这8.5%的重传率所导致的。

接下来我们计算重传的时间。tcptrace附带了一系列的模块，呈现出的数据也是不同的维度（协议、端口、时间等等）。其中部分的模块可以在一个运行的时间段内查看TCP性能。你可以准确地检测出来何时发生一系列的重传，和其他性能数据相综合，锁定瓶颈所在。

下面的例子是怎么利用tcptrace创建一个时间片文件：

#tcptrace –xslice bigsuff

这个命令在当前工作路径下创建了一个名为slice.dat的文件，这个特殊的文件中包含了在8秒内重传的信息：

# more slice.dat
date              segs    bytes    rexsegs rexbytes    new    active
--------------- -------- -------- -------- -------- -------- --------
22:19:41.913288    46      5672     0        0         1        1
22:19:56.913288    131    25688     0        0         0        1
22:20:11.913288    0       0        0        0         0        0
22:20:56.913288    23077 19123956   40      59452      0        1
22:21:11.913288    26357 21624373   5       7500       0        1
22:21:26.913288    20975 17248491   3       4500       12       13
22:21:41.913288    24234 19849503   10      15000      3        5
22:21:56.913288    27090 22269230   36      53999      0        2

网络监控总结：

1、检查网络接口，使所有的网卡工作在合适的速度上。

2、检查所有的网卡的吞吐量，确保其和网络速度一致。

3、监控网络流量类型以确保系统合适的流量优先级。