之前文章《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次/秒：
