排除網路問題可能很棘手，任何故障排除工作的第一步就是檢查相應網路部件的統計數字。然而，如果那些統計數字表明一切都很好，可是網路問題依然出現，那麼你就只好引入故障排除界的“瑞士軍刀”――資料包分析。雖說市面上有好多出色的收費產品可用於分析資料包，不過我還是青睞開源工具Wireshark()。
在分析涉及負載均衡系統的問題時，需要解答的第一個問題就是負載均衡系統是不是處於透明模式下。在透明模式下，負載均衡系統會將原始客戶機的IP地址作為源IP地址來傳送。而在非透明模式下，負載均衡系統會使用負載均衡系統的虛擬IP地址(VIP)對伺服器請求進行網路地址轉換(NAT)處理。非透明模式是最常見的實施模式。
現在你準備獲取跟蹤檔案。在理想情況下，下圖中的每一個點都會插入分路器(tap)。要是你沒有分路器，可以使用SPAN(交換機埠分析器)或交換機上的映象埠來捕獲流量。或者你也可以對防火牆和負載均衡系統的入站和出站埠使用tcpdump命令。關鍵在於同時捕獲所有四個位置的資料包，分析來自四個不同有利位置的會話。
你捕獲了資料後，必須找到出現在所有四個跟蹤檔案中的單一會話。通常，你只要過濾相應的兩個IP地址就可以了。但是記住負載均衡系統在伺服器端執行NAT，所以過濾客戶機IP地址並不適用於伺服器端痕跡。
進入到第4層可以解決這個問題。你可以按照TCP報頭中的序列號進行過濾。不過要小心;Wireshark在預設情況下顯示相對序列號，你到頭來會遇到數百個序列號為1的資料包。關鍵在於關閉TCP引數選項中的相對序列號。只要只要取消勾選該選項，實際的十進位制數就會顯示，而不是相對會話開始的序列號。一旦你過濾了所有四個痕跡檔案中的同一序列號，你在每個檔案中應該有一個數據包。
如果你的負載均衡系統在NAT端建立自己的.資料包發往伺服器，棘手問題就來了。序列欄位然後不再從頭到尾都一樣。這種場景下使用的最佳欄位就是應用層所特有的欄位。如果是HTTP，我建議使用Cookie欄位;如果是HTTPS，則建議使用Client Hello中的Random Bytes欄位。
最後，你面對在多個地方捕獲的單一會話，可以分析其痕跡了。首先，尋找資料包丟失現象。在Wireshark的專家分析語言中，那些丟失的資料包會被標為“Previous segment not captured”(未捕捉到的先前片段)。這會出現在一個或多個痕跡檔案中，但並不出現在所有痕跡檔案中。比如說，如果你在防火牆痕跡的出站端(而不是入站端)看到來自伺服器的響應，就知道防火牆丟失了資料包。
分析資料包丟失現象後，檢查TCP握手機制，確保TCP選項在一路當中並沒有被篡改。當沿途中的某個裝置建立自己的資料包，而不是以透明方式一路傳送時，視窗縮放(windows scaling)和選擇性確認(Selective Acknowledgements)往往會消失。那兩個選項對吞吐量而言很重要，不應該去掉。
在痕跡中要關注的最後一個問題是很高的增量時間(delta time)。如果捕獲了四個不同位置的資料，你就真正能夠檢視什麼東西在新增延遲(要是果真有什麼東西的話)。先看一下握手機制。使用同步請求(SYN)與同步響應(SYN/ACK)的間隔時間作為基準。看一下離客戶機最近的防火牆入站端留下的痕跡中的其餘請求和響應。
針對那些增量時間為一秒或更長的請求/響應組合，逐步檢查每個痕跡，直到你找到哪個埠在增添延遲為止。是處理器使用激增的防火牆嗎?還是跟蹤NAT表有問題的負載均衡系統?也許是併發連線數量太多的伺服器。仔細檢查痕跡，可以告訴你哪裡有問題，哪裡沒有問題。
設定資料包捕獲機制可能在網路滅火行動中會佔用寶貴的時間，不過從長遠來看它可以節省大量的時間。
