Linux性能之网络
来源：互联网 发布：织物工艺设计软件 编辑：程序博客网 时间：2024/06/06 02:37
所有的子系统中，最后说明网络，是由于网络是最难进行监控的。这是由于网络是比较抽象的一个。当监控网络的性能的时候，有许多的因素需要考虑。这些因素包括延迟、冲突、拥塞、误码丢包等等。接下来，将讲一下怎么去检测网络的性能（本小节涉及到关于网络的命令有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/Full100baseT/Half 100baseT/FullSupports auto-negotiation: YesAdvertised link modes: 10baseT/Half 10baseT/Full100baseT/Half 100baseT/FullAdvertised auto-negotiation: YesSpeed: 10Mb/sDuplex: HalfPort: MIIPHYAD: 32Transceiver: internalAuto-negotiation: onSupports Wake-on: pumbgWake-on: dCurrent 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/Full100baseT/Half 100baseT/FullSupports auto-negotiation: YesAdvertised link modes: 10baseT/Half 10baseT/Full100baseT/Half 100baseT/FullAdvertised auto-negotiation: NoSpeed: 100Mb/sDuplex: FullPort: MIIPHYAD: 32Transceiver: internalAuto-negotiation: offSupports Wake-on: pumbgWake-on: dCurrent 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服务器：
# netserverStarting netserver at port 12865Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC通过netperf可以执行多个测试，众多测试中有个标准的吞吐量测试，以下是局域网内，客户端执行一个30s的基于TCP的吞吐量的测试：
# netperf -H 192.168.1.215 -l 30TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to192.168.1.230 (192.168.1.230) port 0 AF_INETRecv Send SendSocket Socket Message ElapsedSize Size Size Time Throughputbytes bytes bytes secs. 10^6bits/sec87380 16384 16384 30.02 89.46从上面的输出可以看出来，网络的吞吐量维持在89Mbps左右，也并未达到100Mbps。
将此局域网移到54Mbps的无线网络的环境里面，距离路由器10英尺，可以看到吞吐量大幅度地下降，用笔记本测试时候，吞吐量只有14Mbps，而不是54Mbps。
# netperf -H 192.168.1.215 -l 30TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to192.168.1.215 (192.168.1.215) port 0 AF_INETRecv Send SendSocket Socket Message ElapsedSize Size Size Time Throughputbytes bytes bytes secs. 10^6bits/sec87380 16384 16384 30.10 14.09距离路由器50英尺，并且在路由器的下一层楼，减少到了5Mbps
#netperf -H 192.168.1.215 -l 30TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to192.168.1.215 (192.168.1.215) port 0 AF_INETRecv Send SendSocket Socket Message ElapsedSize Size Size Time Throughputbytes bytes bytes secs. 10^6bits/sec87380 16384 16384 30.64 5.05测试公网时候降低到1Mbps以下
#netperf -H litemail.org -p 1500 -l 30TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET tolitemail.org (72.249.104.148) port 0 AF_INETRecv Send SendSocket Socket Message ElapsedSize Size Size Time Throughputbytes bytes bytes secs. 10^6bits/sec87380 16384 16384 31.58 0.93最后一个测试下VPN服务器，这个是所有测试中吞吐量最差的，仅仅有0.5Mbps。下面是测试结果：
#netperf -H 10.0.1.129 -l 30TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to10.0.1.129 (10.0.1.129) port 0 AF_INETRecv Send SendSocket Socket Message ElapsedSize Size Size Time Throughputbytes bytes bytes secs. 10^6bits/sec87380 16384 16384 31.99 0.51另一个比较有用的测试是，使用netperf来监控每秒TCP连接的数目以及响应连接发生的数目，这个测试通过创建一个简单的TCP连接，然后通过这个连接发送多个请求或者接受请求的队列（ACK包的来回发送都是以1字节）。这个过程和RDBMS执行多个数据传输过程类似，或者和一个邮件服务器在一个连接里面通过管道处理多个消息。以下的例子显示的就是在30秒内，TCP的请求与回应：
#netperf -t TCP_RR -H 192.168.1.230 -l 30TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INETto 192.168.1.230 (192.168.1.230) port 0 AF_INETLocal /RemoteSocket Size Request Resp. Elapsed Trans.Send Recv Size Size Time Ratebytes Bytes bytes bytes secs. per sec16384 87380 1 1 30.00 4453.8016384 87380从上面的输出可以看出，此网络支持传输速度为每秒4453 psh/ack，并使用1个字节的有效载荷。这一点现实中是不可能，因为在许多请求中，特别是回应中，会远远大于一个字节。在实际的系统中，netperf使用一个默认的数值，2k作为请求数据，32k作为回应数据，然后有如下的结果：
#netperf -t TCP_RR -H 192.168.1.230 -l 30 -- -r 2048,32768TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to192.168.1.230 (192.168.1.230) port 0 AF_INETLocal /RemoteSocket Size Request Resp. Elapsed Trans.Send Recv Size Size Time Ratebytes Bytes bytes bytes secs. per sec16384 87380 2048 32768 30.00 222.3716384 87380选择默认值之后，传输速率明显降低下来每秒222个传输连接。
利用iperf测试网络的利用率
在检查两个端点之间的连接时候，iperf与netperf的作用相似。不同的是iperf有许多围绕TCP/UDP更加深入的检测，比如窗大小和QoS的设置。此工具用来调整TCP/IP栈，然后测试这些栈的有效性。iperf可运行在sever或者client模式下，默认使用的端口为5001.
在服务器端开启服务使用下面的命令：
# iperf -s -DRunning Iperf Server as a daemonThe Iperf daemon process ID : 3655------------------------------------------------------------Server listening on TCP port 5001TCP 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 5001TCP window size: 25.6 KByte (default)------------------------------------------------------------[ 3] local 192.168.224.150 port 51978 connected with192.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 10MWARNING: option -b implies udp testing------------------------------------------------------------Client connecting to 192.168.1.215, UDP port 5001Sending 1470 byte datagramsUDP 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 bigstuff1 arg remaining, starting with 'bigstuff'Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004146108 packets seen, 145992 TCP packets tracedelapsed wallclock time: 0:00:01.634065, 89413 pkts/sec analyzedtrace file elapsed time: 0:09:20.358860TCP 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 bigstuff1 arg remaining, starting with 'bigstuff'Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004146108 packets seen, 145992 TCP packets tracedelapsed wallclock time: 0:00:00.529361, 276008 pkts/sec analyzedtrace file elapsed time: 0:09:20.358860TCP connection info:32 TCP connections traced:TCP connection 1:host a: 192.168.1.60:pcanywherestathost b: 192.168.1.102:2571complete conn: no (SYNs: 0) (FINs: 0)first packet: Sun Jul 20 15:58:05.472983 2008last packet: Sun Jul 20 16:00:04.564716 2008elapsed time: 0:01:59.091733total packets: 854filename: bigstuffa->b: b->a:total packets: 404 total packets: 450ack pkts sent: 404 ack pkts sent: 450pure acks sent: 13 pure acks sent: 320sack pkts sent: 0 sack pkts sent: 0dsack pkts sent: 0 dsack pkts sent: 0max sack blks/ack: 0 max sack blks/ack: 0unique bytes sent: 52608 unique bytes sent: 10624actual data pkts: 391 actual data pkts: 130actual data bytes: 52608 actual data bytes: 10624rexmt data pkts: 0 rexmt data pkts: 0rexmt data bytes: 0 rexmt data bytes: 0zwnd probe pkts: 0 zwnd probe pkts: 0zwnd probe bytes: 0 zwnd probe bytes: 0outoforder pkts: 0 outoforder pkts: 0pushed data pkts: 391 pushed data pkts: 130SYN/FIN pkts sent: 0/0 SYN/FIN pkts sent: 0/0urgent data pkts: 0 pkts urgent data pkts: 0 pktsurgent data bytes: 0 bytes urgent data bytes: 0 bytesmss requested: 0 bytes mss requested: 0 bytesmax segm size: 560 bytes max segm size: 176 bytesmin segm size: 48 bytes min segm size: 80 bytesavg segm size: 134 bytes avg segm size: 81 bytesmax win adv: 19584 bytes max win adv: 65535 bytesmin win adv: 19584 bytes min win adv: 64287 byteszero win adv: 0 times zero win adv: 0 timesavg win adv: 19584 bytes avg win adv: 64949 bytesinitial window: 160 bytes initial window: 0 bytesinitial window: 2 pkts initial window: 0 pktsttl stream length: NA ttl stream length: NAmissed data: NA missed data: NAtruncated data: 36186 bytes truncated data: 5164 bytestruncated packets: 391 pkts truncated packets: 130 pktsdata xmit time: 119.092 secs data xmit time: 116.954 secsidletime max: 441267.1 ms idletime max: 441506.3 msthroughput: 442 Bps throughput: 89 Bps计算重新传输的百分比：
确定那个连接有严重的重传问题并分析，这一点貌似是不可能的。tcptrace利用过滤和布尔表达式锁定问题连接。在一个有多个连接饱和的网络环境里，所有的连接都会重传的可能性是有的。这里的重点是那个连接重传的次数最多。
下面的例子中，tcptrace命令使用一个过滤器定位重传超过100段的连接：
# tcptrace -f'rexmit_segs>100' bigstuffOutput 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, 2004146108 packets seen, 145992 TCP packets tracedelapsed wallclock time: 0:00:00.687788, 212431 pkts/sec analyzedtrace file elapsed time: 0:09:20.358860TCP connection info:16: ftp.strongmail.net:65014 - 192.168.1.60:2158 (ae2af) 18695> 9817<从上面的数据中可以看出#16号连接超过了100次重传，然后我们分析第#16连接的详细情况：
# tcptrace -l -o16 bigstuffarg remaining, starting with 'bigstuff'Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004146108 packets seen, 145992 TCP packets tracedelapsed wallclock time: 0:00:01.355964, 107752 pkts/sec analyzedtrace file elapsed time: 0:09:20.358860TCP connection info:32 TCP connections traced:================================TCP connection 16:host ae: ftp.strongmail.net:65014host af: 192.168.1.60:2158complete conn: no (SYNs: 0) (FINs: 1)first packet: Sun Jul 20 16:04:33.257606 2008last packet: Sun Jul 20 16:07:22.317987 2008elapsed time: 0:02:49.060381total packets: 28512filename: bigstuffae->af: af->ae:<snip>unique bytes sent: 25534744 unique bytes sent: 0actual data pkts: 18695 actual data pkts: 0actual data bytes: 25556632 actual data bytes: 0rexmt data pkts: 1605 rexmt data pkts: 0rexmt 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.datdate segs bytes rexsegs rexbytes new active--------------- -------- -------- -------- -------- -------- --------22:19:41.913288 46 5672 0 0 1 122:19:56.913288 131 25688 0 0 0 122:20:11.913288 0 0 0 0 0 022:20:56.913288 23077 19123956 40 59452 0 122:21:11.913288 26357 21624373 5 7500 0 122:21:26.913288 20975 17248491 3 4500 12 1322:21:41.913288 24234 19849503 10 15000 3 522:21:56.913288 27090 22269230 36 53999 0 2网络监控总结：
1、检查网络接口，使所有的网卡工作在合适的速度上。
2、检查所有的网卡的吞吐量，确保其和网络速度一致。
3、监控网络流量类型以确保系统合适的流量优先级。
0 0
- Linux性能之网络
- LINUX网络性能之管理工具三剑客
- LINUX网络性能之管理工具三剑客
- 性能之巅：Linux网络性能分析工具
- 调谐LINUX网络性能之网络配置文件详解[转载]
- 调谐LINUX网络性能之网络配置文件详解(转)
- 速度优化 - 调谐LINUX网络性能之调谐方法概述
- 性能之巅：Linux网络性能分析工具-netstat,ifconfig,nicstat,traceroute,tcpdump
- Linux性能监测：网络篇
- Linux性能监测：网络篇
- linux sysctl 网络性能优化
- Linux性能监测：网络篇
- linux网络发包性能优化
- Linux网络性能分析命令
- Linux 网络性能tuning向导
- Linux查看网络链接性能
- Linux 高性能网络库
- Linux下网络性能评估
- word break
- java从网络Url中下载文件例子
- NSOperationQueue—总结
- Linux系统防CC攻击自动拉黑IP增强版Shell脚本
- Win7系统封装制作的全过程
- Linux性能之网络
- 【转】LM(Levenberg-Marquard) Matlab及C语言实现
- Largest Rectangle in Histogram
- hdu 2604 Queuing 递推/DP 矩阵快速幂 Trie数辅助
- 在python中使用liblinear
- Physical Examination
- Vijos P1369难解的问题
- 小米电视2S加量不加价，你还会买吗?
- 基于cocos2dx的飞机大战学习[五]-添加三种敌机
