用Wireshark的IO Graph功能分析网络质量.docx

用Wireshark的IO Graph功能分析网络质量本次测试组网如下：本次实验，先测试http下载文件（090s时间段，以下称之为一阶段）；然后测试http上传文件（100135s时间段和135200s阶段，以下称之二、三阶段）。用tc限定路由器：下行限速100kps，下行延时80ms，上行不设限。相关tc命令如下：tc qdisc add dev eth2 root handle 1: htb default 2;tc class add dev eth2 parent 1: classid 1:2 htb rate 100kbit ceil 150kbit;tc qdisc add dev eth2 parent 1:2 handle 2: netem delay 80ms 30ms distribution normal;分析Throughput打开Wireshark软件，选择菜单 Statistics - IO Graph，下同不再赘述。set X-Axis Tick interval to 1 secset Y-Axis Unit to Bits/Tick默认会自动显示“Graph 1”（黑色线）【有时可能需要点击一下“Graph 1”按钮】查看下载情况调整Y-Axis的Scale到200000，可看到一阶段下载，限速基本在100kps，tc控制的还是比较精准的。查看上传情况调整Y-Axis的Scale到1000000，可看到二阶段上传保持在500kbps，调整Y-Axis的Scale到Auto，可看到三阶段上传保持在5Mbps。由于下行限速，所以实际上传时的下行ACK也受到影响，所以上传的速度一直上不去。如果要查看单向的流速，可设置Filter。查看下行tcp.srcport=873，可看到下行一直受限查看上行tcp.dstport=873分析RTT查看RTT最好用发送端上的抓包，计算发出数据到收到ACK之间的时间差，更准确set X-Axis Tick interval to 1 secset Y-Axis Unit to Advancedset Filter: to tcp.dstport=873set Calc: to AVGtcp.analysis.ack_rtt点一下“Graph 2”按钮以画图（红色）查看下行RTT，平均80ms（注意：下行RTT是通过分析上行ACK来估算，tcp.dstport=873）下行RTT，一阶段约80ms，二、三阶段约为零（因为此时间段没有下行数据，所以就没有下行RTT）查看上行RTT，平均100ms（注意：上行RTT是通过分析下行ACK来估算，tcp.srcport=873）上行RTT，一阶段约为零（因为此时间段没有上行数据，所以就没有上行RTT），三阶段约100ms分析bytes-in-flight和rwnd查看bytes-in-flight和rwnd最好用发送端上的抓包set X-Axis Tick interval to 1 secset Y-Axis Unit to Advancedset Filter: to tcp.srcport=80set Calc: to MAXtcp.analysis.bytes_in_flight点一下“Graph 3”按钮以画图（绿色）set Filter: to tcp.dstport=80set Calc: to MAXtcp.window_size点一下“Graph 4”按钮以画图（蓝色色）当发现bytes-in-flight等于rwnd时，说明发送端已经把接收端的rwnd撑满了，这往往表明接收端的rwnd偏小，管道的BDP很可能大于rwnd，此时应该扩大接收端的rwnd参数。比如下图ingress侧的抓包，说明客户端的rwnd有点小。当发现bytes-in-flight明显小于rwnd时，说明此时rwnd不是瓶颈。此时rwnd足够大，bytes-in-flight基本是等于BDP。通过ping来获得RTT，由此，通过bytes-in-flight / RTT可估算出实际的带宽。比如下图egress侧的抓包，bytes-in-flight约为60000。而RTT经过ping测试，大约为7ms，因此，egress侧实际带宽应该在60000*8/0.007=65.4Mbps本次实验一阶段，bytes-in-flight远小于rwnd，所以rwnd不是问题一阶段，bytes-in-flight约为1000，RTT约为80ms，因此实际带宽可计算出1000*8/0.08=100kbps与分析Throughput时看到的基本一致。上行分析三阶段，bytes-in-flight远小于r