對網(wǎng)絡(luò)問題進行故障排查往往是件棘手的任務(wù)，而負載均衡器的存在則會帶來其它更為復(fù)雜的挑戰(zhàn)。我們很難判斷負載均衡器單純是在丟棄數(shù)據(jù)包、以某種方式變更數(shù)據(jù)包還是導(dǎo)致網(wǎng)絡(luò)整體延遲水平上升。不過在今天的文章中，我們將共享幾項常見技巧，相信它們能幫助各位更加輕松地發(fā)現(xiàn)問題所在。

對于任何一種故障排查流程來講，首先要做的肯定是檢查整套實體的統(tǒng)計信息。然而，即使統(tǒng)計信息顯示一切運轉(zhuǎn)正常，我們?nèi)匀徊荒芫痛伺懦嬖诰W(wǎng)絡(luò)問題的可能性。接下來，我們要做的就是引入故障排查領(lǐng)域的中立處理手段——數(shù)據(jù)包分析。雖然目前已經(jīng)有大量優(yōu)秀的收費數(shù)據(jù)包分析產(chǎn)品可供選擇，但我個人更青睞開源Wireshark。

當(dāng)對包含負載均衡器的網(wǎng)絡(luò)體系進行問題分析時，首先要解決的問題就是該負載均衡器是否處于透明模式。在透明模式下，負載均衡器會將原有客戶IP作為源IP。而在非透明模式下，該負載均衡器則會利用虛擬IP地址——或者簡稱VIP——向服務(wù)器發(fā)送請求。一般情況下，負載均衡器大多會以非透明模式運行。

現(xiàn)在大家已經(jīng)準(zhǔn)備好對文件進行追蹤了。在理想狀態(tài)下，我們可以在下圖中的每個點內(nèi)設(shè)置分接器。如果不具備分接器，大家也可以利用SPAN或者交換機上的鏡像端口捕捉相關(guān)流量。當(dāng)然，大家也可以在防火墻以及負載均衡器上的入站與出站端口使用tcpdump。其中的關(guān)竅在于，我們必須在全部四個位置一次性捕捉數(shù)據(jù)包，從而通過四種不同的角度審視傳輸會話。

在捕捉到數(shù)據(jù)之后，大家必須從全部四個跟蹤文件當(dāng)中找到同時存在的單一會話。一般來講，大家能夠通過過濾器找出請求與完成的兩個IP地址。不過請注意，負載均衡器是在服務(wù)器端執(zhí)行NAT的，因此對客戶端IP進行過濾對服務(wù)器端追蹤工作并無效果。

從第四層出發(fā)則能夠解決這一難題。大家可以在TCP報頭當(dāng)中過濾序列號。不過需要注意的是，Wireshark會在默認情況下顯示相關(guān)序列號，因此我們最終可能會得到成百上千個以序列號1開頭的數(shù)據(jù)包。解決問題的關(guān)鍵在于關(guān)閉TCP設(shè)置當(dāng)中的相關(guān)序列號功能。只需要取消勾選項，過濾結(jié)果就會顯示實際十位序列號，而非作為會話開頭的***位數(shù)字。在對全部四個跟蹤文件進行相同序列號過濾之后，大家應(yīng)該會在每個文件中找到對應(yīng)的惟一數(shù)據(jù)包。

麻煩的部分在于，如果大家的負載均衡器在NAT端自行創(chuàng)建出了指向服務(wù)器的數(shù)據(jù)包，那么各個文件當(dāng)中的序列字段將不再完全相同。在這種情況下，最理想的辦法是從應(yīng)用層內(nèi)選擇惟一字段。對于HTTP，我建議大家使用Cookie字段;而對于HTTPS，Client Hello中的Random Bytes字段則最為合適。

***，我們終于能夠捕捉到單一會話，并對該痕跡進行訪問了。首先，查看丟包情況。在Wireshark Expert Analysis當(dāng)中，這些數(shù)據(jù)包會被標(biāo)為“Previous segment no captured(即前段未被捕捉)。”這種情況可能出現(xiàn)在一個或者多個跟蹤文件當(dāng)中，但不會是全部。舉例來說，如果大家在防火墻跟蹤文件的出站端而非入站端發(fā)現(xiàn)了來自服務(wù)器的響應(yīng)，那么就會判斷出該數(shù)據(jù)包被防火墻丟棄。

在丟包查找完成后，檢查TCP握手以確保各TCP選項沒有在路徑中受到篡改。當(dāng)路徑中的某個對話框自行創(chuàng)建數(shù)據(jù)包、而非以透明化方式直接經(jīng)過時，則窗口縮放與選擇性應(yīng)答會出現(xiàn)消失趨勢。這兩個選項對于評估數(shù)據(jù)吞吐量而言非常重要，千萬不要忽略。

***一個需要解決的問題就是在跟蹤文件中尋找高時間增量。通過對四個不同檢查點進行數(shù)據(jù)捕捉，大家肯定能夠發(fā)現(xiàn)的就是延遲水平的提升。首先查看握手，并以同步請求(SYN)與同步響應(yīng)(SYN/ACK)之間的時間長度作為參考基準(zhǔn)。查看跟蹤文件中指向最接近客戶端的防火墻的入站請求與響應(yīng)。

對于那些時間增量達到1秒甚至更高的請求/響應(yīng)組合，我們需要排查整個追蹤過程，直到找出顯著增加延遲水平的對應(yīng)端口。其是否來自CPU處于運行峰值的防火墻?還是某個未能正常追蹤其NAT表的負載均衡器?當(dāng)然，也可能是存在太多并發(fā)連接的服務(wù)器。排查整個追蹤流程將幫助大家了解問題的出現(xiàn)位置，同時明確哪些位置運轉(zhuǎn)正常。

在網(wǎng)絡(luò)排查工作當(dāng)中，設(shè)置數(shù)據(jù)包捕捉可能會占用大量寶貴時間，但從長久角度看、這卻是一種節(jié)約時間的良好習(xí)慣。