其實抓包不是難事，很多人都會，下個Protocol Analyzer，比如Network Monitor、Wireshark，打開點記下就可以抓了。我主要有三個問題：

1. 你為什麼想都要抓包？你的問題是否能通過抓包獲取答案？
2. 在什麼情況下抓包可以幫助你發現答案？
3. 如潮水般湧入的網絡包瞬間就能淹沒Protocol Analyzer的Packet List，你要從何下手？

今天就簡單來談一下這幾個問題

抓包可使用的場景很多，排錯、驗證、測試、核對等等，我就舉幾個例子來說明吧。

Case I：客戶在一台存儲上啟用了SNMP服務，随後想通過驗證UDP161/162的偵聽狀态來确認服務是否确實啟動了。

詳情I：最簡單的方式就是用進入存儲的OS運行類似netstat –anop查看UDP端口狀态，還有些同學會條件反射的說telnet一下呗。客戶玩得比較高級，用一個叫做nmap的工具做端口掃描，發現掃描結果是Open | Filtered，這又算哪門子意思？除非找到這些工具的使用說明，否則無法明白其輸出的意思。但有的時候就是沒有太多參考文檔，比如netstat顯示的UDP端口狀态列都是空的，沒有任何狀态，這代表什麼呢？其實網絡抓包可以幫助我們。你可以在telnet的同時抓包，結果會發現telnet發起了TCP SYN包，立刻就被對端給Reset掉了，所以用telnet的提議是錯誤的，用TCP去驗證一個UDP端口是否在偵聽，顯然是南轅北轍了。同樣，做nmap掃描的同時抓包，你會發現原來UDP使用ICMP返回消息來判斷端口狀态。如果端口關閉，那麼對端會返回port unreachable，如果沒有任何ICMP返回呢？那就說明中間存在包過濾邏輯，這也是為什麼客戶的nmap掃描顯示open | filtered，nmap也無法确認端口狀态，因為沒有任何ICMP消息返回。所以，客戶的掃描結果不能判斷端口狀态，必須采取其它手段。不過這不是這個case的重點，我們的重點是可以通過抓包看到應用程序的行為。

總結：判斷端口狀态的方式很多，但你是否采用了正确的方式，完全可以通過抓包來判斷，它會告訴你一個應用程序的行為，幫助你發現原因。

Case II：客戶發現應用程序與服務器之間的通信很慢。

詳情II：為什麼拿這個case來說，因為抓包和對TCP的分析在這個case裡幾乎就直接問題原因所在了。通過分析TCP分段，我們發現了traffic pattern的變化，延遲由正常的幾個ms逐漸轉變為了十幾個ms，并在之後的流量中看到了Window Full以及最終的ZeroWindow消息。對TCP熟悉的同學立馬能夠判斷出接收端存在處理能力的問題，導緻無法及時清理TCP接收緩存，使得隊列長度越來越長，根據Little Law和Utilization Law，響應時間會呈指數上升，這也為什麼我們會觀察到響應時間的變化。還有同學提問中間的交換機/路由器是否有可能發生這樣的過載？當然是肯定的，但我們這個case裡不是這個問題，為什麼？因為我們抓包沒有看到任何重傳。

總結：抓包在這個case幫你排除了看起來最有可能是網絡問題的問題，TCP的行為非常清晰的指出了問題所在。

Case III：Http下載失敗

詳情III：抓包下載過程，發現下載失敗是因為TCP reset，但又是什麼導緻TCP reset呢？客戶是一家web hosting網站，提供文件下載，他說這不是個案，有很多他們的客戶抱怨說下載失敗。因此我們初步會懷疑是服務器端的問題。在抓包後，我們發現數據傳輸開始是正常的，數據包長度都為1460bytes，而且客戶端也在不時的Ack數據。直到某個數據沒有被Ack，随後變發現了tcp reset。仔細觀察後發現，沒有被Ack的那個包的長度并非1460bytes，而其它所有數據包都是1460bytes。至此，雖然不能100%确認問題所在，但是你有理由讓服務器端的應用開發人員做Application debugging，為什麼服務器端應用程序會改變發包大小，當然對TCP來講，這不是問題，比如TCP sender buffer就是隻有這麼點數據。但突然之間的大小變化，以及Ack的奇怪行為讓我們有理由懷疑，服務器端程序的邏輯或許存在問題。

總結：在海量數據下，如何做到火眼晶晶找出數據包的不同是需要練習的。

Case IV：這并非是一個問題，還是要教會我們如何懷疑任何存在疑點的延遲。

詳情 IV：理論上，你應該很清楚自己網絡内所有的delay component，因為它們都是可以通過計算獲得的。但有的時候，無法解釋的延遲，就需要你理解協議和看包的能力。在這個case中，我們遇到的是TCP Nagle和Delayed-Ack算法之間的臨時通信死鎖問題。Nagle隻允許一次發送一個小包（<MSS），除非收到Ack；而Delayed Ack要求至少收到兩個包，否則不Ack；如此一來，兩種就會較勁，直至Delayed-Ack timer超時，通常會有200ms的延遲。因此，在這種情況下，對延遲非常敏感的應用很容易超時報錯，甚至crash。你完全可以抓包，而理解TCP行為和解釋不正當的200ms延遲就是你的任務了。通常來說，在如今的一個健康的LAN内，不可能會有200ms網絡延遲，一定是協議或應用本身的行為，而抓包給你機會去證明這一切。

Case V：NFS mount失敗

詳情V：這是我自己的一個case，我并不熟悉NFS，隻是在測試VNX時，NFS mount失敗。抓包後發現整個MOUNT過程涉及了RPC、port-mapper、NFS、MOUNT四種上層協議。于是我就下載了所有RFC掃了一遍，發現協議消息本身的數據結構和消息編号在RFC文檔内都能找到。對于我見到的錯誤消息，找到對應的報錯協議RFC并搜索該錯誤，立馬就能找到對應的解釋，原來是權限問題。到VNX上調了一下，問題就解決了。

總結：抓包可以幫住你揭示一些隐藏在上層協議下面的東西，你以為自己隻是在做nfs mount，但其實涉及了不同的協議，任何一個出現問題，都會發生失敗。抓包顯示的錯誤消息，幫助你知道應該搜索哪個文檔，哪個關鍵字，直指問題所在。這也有助于你學習新的協議。

最後，給到大家一些建議：

• 網絡包在大部分時候能夠告訴你真相，所以用好它很有價值。
• 網絡包告訴你發生了什麼，但不會告訴你為什麼發生，理解協議行為和分析是你的任務。
• 不要隻看文檔，嘗試抓一下包，因為真相可能和文檔是不同的。
• 面對海量數據包，需要訓練你的眼睛和大腦來過濾消息
• TCP其實是老好人，不要總是責怪它。理解它，分析它，你會發現錯誤大部分時候是在别的地方。
• 新一代數據中心網絡十分複雜，用好工具，會幫你解決很多難題。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!