共計(jì) 1479 字 | 建議閱讀時(shí)間 3 分鐘

網(wǎng)銀系統(tǒng)的網(wǎng)絡(luò)環(huán)境示意圖如下：

客戶端訪問網(wǎng)銀系統(tǒng)外網(wǎng)地址，然后經(jīng)過F5負(fù)載均衡設(shè)備轉(zhuǎn)發(fā)數(shù)據(jù)，直接訪問SSL加密設(shè)備，再通過SSL設(shè)備轉(zhuǎn)發(fā)給網(wǎng)銀系統(tǒng)WEB服務(wù)器。

結(jié)合網(wǎng)銀系統(tǒng)網(wǎng)絡(luò)拓?fù)浼皵?shù)據(jù)的走向，網(wǎng)銀系統(tǒng)訪問較慢的原因有以下幾點(diǎn)：

• 網(wǎng)銀系統(tǒng)訪問流量太大，出口鏈路擁塞；

• 網(wǎng)絡(luò)響應(yīng)延時(shí)較大；

• 網(wǎng)絡(luò)設(shè)備轉(zhuǎn)發(fā)故障；

• 網(wǎng)銀服務(wù)器本身響應(yīng)較慢。

對1小時(shí)內(nèi)網(wǎng)銀系統(tǒng)外網(wǎng)出口流量進(jìn)行統(tǒng)計(jì)，總流量為919MB，峰值流量為5Mbps，平均流量為2.2Mbps。如下圖：

在TCP的連接過程中，客戶端和服務(wù)器端在網(wǎng)絡(luò)中共傳輸三個(gè)數(shù)據(jù)包，俗稱三次握手，這三個(gè)數(shù)據(jù)包都是小包，沒有實(shí)際有效數(shù)據(jù)載荷。服務(wù)器端對客戶端TCP SYN的請求在系統(tǒng)底層響應(yīng)，響應(yīng)非?？?，該響應(yīng)同數(shù)據(jù)包在網(wǎng)絡(luò)中傳輸?shù)难舆t比可忽略，同時(shí)由于都是小包，網(wǎng)絡(luò)傳輸延遲非常小，因此在數(shù)據(jù)包分析中可以通過三次握手?jǐn)?shù)據(jù)包的時(shí)間間隔來確定網(wǎng)絡(luò)的傳輸延遲，如圖所示：

 圖?3 

如上圖所示，當(dāng)我們在客戶端和服務(wù)端的網(wǎng)絡(luò)中某一點(diǎn)捕獲到客戶端同服務(wù)端的TCP三次握手?jǐn)?shù)據(jù)包時(shí)，三個(gè)數(shù)據(jù)包在流量分析設(shè)備捕獲到的時(shí)間分別為T1,T2,和T3，這種情況下T2-T1的值可以認(rèn)為是數(shù)據(jù)包從捕獲點(diǎn)網(wǎng)絡(luò)傳送到服務(wù)器然后服務(wù)器在傳回捕獲點(diǎn)的RTT（Round Trip Time）,而T3-T2的值為數(shù)據(jù)包從捕獲點(diǎn)傳送到客戶端然后從客戶端傳送回捕獲點(diǎn)的RTT，T3-T1的值可以認(rèn)為是從客戶端到服務(wù)器的RTT。

隨機(jī)選擇系統(tǒng)外網(wǎng)出口多個(gè)完整的TCP會話，通過對TCP三次握手時(shí)間進(jìn)行分析，發(fā)現(xiàn)服務(wù)端在收到客戶端的鏈接請求后，都在1ms以內(nèi)給予了響應(yīng)。說明網(wǎng)銀系統(tǒng)內(nèi)部網(wǎng)絡(luò)正常，不存在延時(shí)。如圖：

圖?4

對外網(wǎng)出口流量進(jìn)行分析，重點(diǎn)分析持續(xù)時(shí)間較長的TCP會話，發(fā)現(xiàn)部分會話存在異常。如下圖：

圖?5 

通過TCP交易時(shí)序圖可以看出，服務(wù)端在對客戶端的第一個(gè)請求進(jìn)行確認(rèn)后，經(jīng)過了7秒才發(fā)出了響應(yīng)數(shù)據(jù)包。這段時(shí)間應(yīng)該就是導(dǎo)致客戶端訪問網(wǎng)銀系統(tǒng)緩慢的直接原因。

為了確定這個(gè)延遲產(chǎn)生的具體原因，分析SSL加密設(shè)備進(jìn)出數(shù)據(jù)，找出相同源IP的TCP會話數(shù)據(jù)進(jìn)行對比，發(fā)現(xiàn)在SSL加密設(shè)備出口處同樣出現(xiàn)服務(wù)器端在很長時(shí)間后才發(fā)出響應(yīng)數(shù)據(jù)。如圖：

圖?6

外網(wǎng)出口出現(xiàn)的故障現(xiàn)象在SSL加密設(shè)備出口同樣存在，證明這段延遲不是在SSL加密設(shè)備之前產(chǎn)生，F(xiàn)5到SSL加密設(shè)備之間的網(wǎng)絡(luò)正常。

進(jìn)一步分析SSL加密設(shè)備和網(wǎng)銀服務(wù)器交互數(shù)據(jù)，由于這部分?jǐn)?shù)據(jù)是沒有進(jìn)行加密傳輸?shù)模虼藷o法準(zhǔn)確定位到之前分析的同一個(gè)TCP會話。而通過對大量TCP會話的對比分析，發(fā)現(xiàn)SSL加密設(shè)備和網(wǎng)銀服務(wù)器之間的數(shù)據(jù)傳輸很快，所有會話都是在1S之內(nèi)完成，基本不存在響應(yīng)延時(shí)情況。如圖：

圖?7

通過以上的分析，基本可以判定由于SSL加密設(shè)備造成了網(wǎng)銀系統(tǒng)訪問緩慢的原因。而SSL加密設(shè)備在進(jìn)行數(shù)據(jù)加密之前，會進(jìn)行一個(gè)密鑰的協(xié)商，具體過程如下圖：

圖?8

結(jié)合故障數(shù)據(jù)包分析，可以發(fā)現(xiàn)出現(xiàn)延時(shí)的數(shù)據(jù)包是由SSL加密設(shè)備向客戶端響應(yīng)的Server hello數(shù)據(jù)包，因此更加可以肯定SSL加密設(shè)備就是造成故障的根本原因。

通過以上信息，我們可以做出如下判斷：

• 鏈路流量值不大，流量趨勢穩(wěn)定，沒有明顯的遞增或遞減趨勢，監(jiān)控鏈路不存在持續(xù)性擁塞問題；

• 網(wǎng)銀系統(tǒng)內(nèi)部網(wǎng)絡(luò)正常，網(wǎng)絡(luò)延時(shí)很??；

• 網(wǎng)銀系統(tǒng)訪問緩慢，應(yīng)該是由于SSL加密設(shè)備和客戶端進(jìn)行密鑰交互時(shí)，SSL加密設(shè)備響應(yīng)延遲導(dǎo)致。

通過網(wǎng)絡(luò)分析對流量的監(jiān)控，可以從網(wǎng)絡(luò)性能、服務(wù)器性能、應(yīng)用性能多視角進(jìn)行統(tǒng)一分析，快速定位到應(yīng)用故障時(shí)的故障節(jié)點(diǎn)。

- END-

延伸閱讀

【案例】如何找出偽造數(shù)據(jù)的內(nèi)網(wǎng)主機(jī)?

【案例】如何分析門戶網(wǎng)站內(nèi)容遭惡意篡改過程?

【案例】如何分析門戶網(wǎng)站遭WEB攻擊的過程？

(在對話框回復(fù)“案例匯總”，可查看往期精彩案例)