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

對于任何一種故障排查流程來講，首先要做的肯定是檢查整套實體的統計信息。然而，即使統計信息顯示一切運轉正常，我們仍然不能就此排除存在網絡問題的可能性。接下來，我們要做的就是引入故障排查領域的中立處理手段——數據包分析。雖然目前已經有大量優秀的收費數據包分析產品可供選擇，但我個人更青睞開源Wireshark。

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

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

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

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

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

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

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

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

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

在網絡排查工作當中，設置數據包捕捉可能會占用大量寶貴時間，但從長久角度看、這卻是一種節約時間的良好習慣。