前兩天弄有線通的事情弄的鬱悶了，所以就研究了網路效能測試。以後不用也是浪費，大家需要就看看吧。
1.目標
測試目的往往是測試清楚幾個值，包括:IP包傳輸往返時延(RTT)，IP包時延變化(抖動)，IP包丟失率(Lost rate)，IP業務可用性，還有頻寬(Bandwidth)。
2.適用標準
RFC 1242， RFC1944， RFC2285， RFC2432。
中華人民共和國資訊產業部令第36號(http://www.chinanetcom.com.cn/mj/dxsc.asp?Unid=3810)
IP網路技術要求– 網路效能引數與指標(YD/T 1171-2001)
3.測試平臺和工具
我們假定基於POSIX相容平臺測試，演示用的例子來自Debian Etch/Kernel 2.6.17-2-686。Windows下所需要工具可以參考移植工具。
iperf 網路頻寬測試工具
paratrace 被動路由測試工具
hping2 網路聯通和時延測試工具
wireshark(ethereal) 抓包分析工具
p0f 被動指紋分析工具
4.測試物件，方法，和結果分析
以下為例項測試，引數需要根據具體情況變化。
4.1.測試網路頻寬
在伺服器端執行iperf -s。
在客戶端執行iperf -c 192.168.0.2
100Mbps網路環境下，得到結果為92.6Mbps，摺合為11.5MB/s。即資料極限傳輸速度。
4.2.測試網路IP包傳輸往返時延(RTT)和IP包時延變化(抖動)
分主動被動方法，被動方法用wireshark抓包分析。下面主要介紹主動方法：
執行hping2 www.google.com -p 80。得到
56 packets transmitted, 56 packets received, 0% packet loss
round-trip min/avg/max = 242.5/269.9/381.1 ms
即在主動建立的到www.google.com的TCP連線中(預設為TCP，可以使用UDP，ICMP，IP，具體請看hping2 –help)，丟包率為0。平均傳輸延遲為269.9，抖動為138.6。
注：按照《中華人民共和國資訊產業部令第36號》，往返時延平均值≤200毫秒，時延變化平均值≤80毫秒。此處已經超標。但因為測試環境和適用條件不完全吻合，因此無法作為有效證據。
4.3.IP包丟失率(Lost rate)
也分主動方法和被動方法，主動方法見上。被動方法是用wireshark抓包後，通過tpc.analysis.lost_segment標誌分析丟包數量和總體數量。具體為。
用wireshark抓包。
用( tcp.srcport == 7007 || tcp.dstport == 7007 )&&(tcp.analysis.retransmission||tcp.analysis.lost_segment||tcp.analysis.ack_lost_segment)過濾。7007為aMule埠。
另存，其中會顯示丟包和總體數目。此處一般都3%-9%。
用( tcp.srcport != 7007 && tcp.dstport != 7007 )&&(tcp.analysis.retransmission||tcp.analysis.lost_segment||tcp.analysis.ack_lost_segment)過濾。
另存，此時是非7007埠丟包和總體數目。此處一般是0.18%-0.32%。
主動方法在測試網路硬性聯通上比較方便，但是對於特殊封鎖造成的丟包(例如BT/ED封鎖)。由於主動TCP測試不會被封鎖，因此無法得到有效資料。需要在實際環境中使用被動方法測試。
此處丟包率總體值一般都超過了3%，根據《中華人民共和國資訊產業部令第36號》，IP包丟失率平均值≤2％。此處已經超標，但基於和上文同樣理由，無法作為有效證據。
4.4.IP業務可用性
如果在測試中，連續5分鐘平均丟包超過75%，則可以認定為無效。
4.5.問題出現點定位
假定出現問題，那麼我們可以假設，問題應當出現在從當前機器到目標機器中的某個路由器上。
如果多個目標機器通訊出現問題，我們可以猜測，問題很大可能出現在這些機器共同經過的某個路由器上。
所以，我們需要跟蹤每個IP的連線。windows下是tracert。
$traceroute www.google.com
1 192.168.0.1 (192.168.0.1) 2 ms 1 ms 0 ms
2 10.119.16.1 (10.119.16.1) 23 ms 25 ms 13 ms
3 reserve.cableplus.com.cn (219.233.244.141) 15 ms 11 ms 16 ms
4 * * *
5 reserve.cableplus.com.cn (219.233.238.205) 14 ms 10 ms 18 ms
6 202.96.222.77 (202.96.222.77) 13 ms 15 ms 14 ms
7 202.101.63.226 (202.101.63.226) 32 ms 19 ms 17 ms
8 202.97.33.38 (202.97.33.38) 84 ms 78 ms 82 ms
9 202.97.33.178 (202.97.33.178) 61 ms 65 ms 69 ms
10 202.97.4.46 (202.97.4.46) 106 ms 103 ms 104 ms
11 216.239.47.232 (216.239.47.232) 94 ms 99 ms 112 ms
12 216.239.47.237 (216.239.47.237) 224 ms 195 ms 196 ms
13 72.14.233.53 (72.14.233.53) 185 ms 181 ms 195 ms
14 72.14.232.139 (72.14.232.139) 208 ms 213 ms 240 ms
15 72.14.233.129 (72.14.233.129) 205 ms 66.249.94.227 (66.249.94.227) 193 ms 209 ms
16 72.14.233.131 (72.14.233.131) 193 ms 195 ms 202 ms
17 216.239.49.66 (216.239.49.66) 209 ms 204 ms 244 ms
18 66.102.7.99 (66.102.7.99) 198 ms 193 ms 195 ms
當然，如果是禁止了ICMP TTL超時的死報文回覆。就會測定不出路由，這時候需要用paratrace。結果是一樣的，不過沒有被封鎖的危險。