利用抓包軟件定位mac電腦僅僅訪問某網址慢的異常情況

一個同事在辦公室用mac電腦碰到一種很奇怪的網絡訪問異常的情況。網絡不可達並不意外，網絡訪問慢才能你如坐針尖。

當時的網絡訪問異常是這樣的：

（1）mac電腦---通過wifi模式---接入到無線路由器（AP）---通過網線---接入到公司辦公室內網網口----訪問Internet。

現象：mac電腦從百度網盤下載或者是直接看高清電影網速均很快，但是唯獨訪問一個web郵箱網址很慢。

（2）mac電腦---通過網線---接入到公司辦公室內網網口----訪問Internet。

現象：所有網址都很快，包括之前訪問慢的某郵箱網址。

一、初步定位

站在網絡運維的角度，初步懷疑是網間丟包或者AP有異常。

針對這個訪問慢的某郵箱網址，通過ping、tracert等方式進行進一步分析。重複多次發現，ping延時很少，tracert跳轉也看不出異常，網間丟包的可能性被排除。

針對AP，排查配置準確性。AP通常有WAN和LAN兩種配置模式。配置爲WAN模式，WAN網口會構建出一個內部局域網。WAN網口會對應兩個IP，其中一個是公司內網分配的IP地址（192.168.86.37），另外一個IP是內部局域網的網關（這個IP網段可以自己設置，我們設置爲192.168.100.1）。此時mac電腦獲取到的IP地址，是192.168.100.67，是AP分配的內部局域網地址。mac電腦訪問外部，需要通過AP進行一次地址轉換。配置爲LAN模式，AP類似於一個有線轉wifi的轉換器。此時mac電腦獲取到的IP地址，公司內網分配的IP地址。mac電腦訪問外部，無需通過AP進行一次地址轉換。通過變更AP的配置模式，發現MAC電腦獲取到的IP地址與上述分析一致，兩種模式下訪問某郵箱網址仍然很慢。

目前AP配置並未異常，進一步分析AP性能是否符合預期。故進一步分析故障場景，發現AP和MAC電腦之間有線和無線時，訪問現象有較大差別。這時候總結故障現象如下：

（1）mac電腦-------（wifi）---------AP（LAN/WAN模式）------網線--- 公司內網-----Internet:

現象：web方式訪問某郵箱網址很慢，其餘網址均很快

（2）mac電腦-------（網線）---------AP（LAN/WAN模式）-----網線-----公司內網----Internet:

現象：所有網址都很快，包括之前訪問慢的某郵箱網址

這時候故障基本聚焦在AP在wifi環境下性能，以及爲啥“單單訪問某郵箱網址慢，其餘網址很快”的這種現象。

二、抓包軟件出手

在上述情況下，若要進一步分析出異常，只能從數據包層面入手了。可以用wireshock軟件，也可以用其餘商用抓包軟件。我這邊採用了科來網絡分析系統9.1版本，安裝在自己電腦上，可以針對電腦不同網卡抓包，還可以針對抓取到的數據包進行詳細分析。需要註明的是，科來軟件不支持mac電腦。針對這種情況有兩種解決方案，一是在mac電腦上安裝一個64位虛擬機，通過虛擬機安裝科來並進行抓包分析；二是直接找個其他型號window電腦，省心省事。

1、抓包

打開科來軟件，選擇左上角的“實時分析”，然後再選取對應的網絡接口，單擊下方“開始”按鈕就可以進行抓包。

抓包設置：爲定位電腦通過有線/wifi兩種方式接入AP的差異，我們分別針對電腦的有線接入/無線接入兩種方式，分別進行抓包。

電腦設置：爲區分“某訪問慢的郵箱網址”和"其餘網址都很快"的情況，每次抓包時，電腦都同時打開三個軟件，並進行如下操作。

（1）視屏播放：打開優酷或者其它類似視屏網站，播放高清視屏，查看視屏是否卡頓。

（2）網盤文件下載：打開百度網盤或者其它類似網站，進行文件下載，並查看文件下載速度。

（3）訪問慢的郵箱文件下載：打開訪問慢的某郵箱網址，進行文件下載，並查看文件下載速度。

2、數據分析

（1）針對電腦通過有線方式接入AP：

通過電腦上的三個軟件直接發現：

• 視屏播放：視屏完全不存在卡頓。

• 網盤文件下載：百度網盤文件下載速度達到5.8MB/秒

• 慢的郵箱文件下載：打開訪問慢的某郵箱網址，文件下載速度達到3.2MB/秒

通過抓包軟件分析：

• 視屏播放：無異常。

• 網盤文件下載：無異常。

• 慢的郵箱文件下載：無異常

（2）針對電腦通過有wifi方式接入AP：

通過電腦上的三個軟件直接發現：

• 視屏播放：視屏完全不存在卡頓。

• 網盤文件下載：百度網盤文件下載速度達到588KB/秒

• 
  

• 慢的郵箱文件下載：打開訪問慢的某郵箱網址，文件下載速度達到23.9KB/秒

• 
  

  
  

通過抓包軟件分析：

因爲都是通過http方式，因此在科來軟件上我們來分析數據包的TCP會話情況（單擊中間一列對話框的TCP會話選項）。可以從下面圖片中看到，最上面的百度雲的TCP會話連接，第二行是某訪問慢的郵箱的TCP會話連接。

同時，還可以進步一分析每個TCP會話的詳細情況，單擊對應的會話選項即可。

• 網盤文件下載：

• 此時整個網絡質量都變差了，整個網絡對話過程中，有1個重傳包。在客戶端（192.168.100.182，自己電腦）側發出了較多的重複ACK請求。需要說明的是，客戶端要連續發出3個同一個序列號的ack請求，服務端纔會針對整個數據包進行一次重發。若是服務端連續收到3個ack請求並再次重發一次數據包，這時候可以定義爲有一個重傳包。

• 慢的郵箱文件下載：

• 此時整個網絡質量都變差了，整個網絡對話過程中，有554個重傳包。在客戶端（192.168.100.182，自己電腦）側發出了較多的重複ACK請求（對應圖片紅色箭頭）。同時，服務端也重複發了554個數據包（對應圖片右端紅色長方形）。同時，還有一個顯著特徵，這個TCP會話中數據包間的等待延時普遍較長，進行有170ms或者300ms這種較長等待時間（對應圖片箭頭間較大間隔塊）。

三、結果分析

通過上面數據分析可以發現，AP在wif模式下網絡質量顯著變差，存在較多數據丟包情況，因此無論是訪問百度網盤還是某特別慢的郵箱，其下載速度均明顯減低。爲啥訪問某郵箱特別慢呢，首先是電腦到至郵箱網址的網間質量相對較差，如會話間延時相對較長，經過AP無線模式將此問題再次放大，顯著超出了影響訪問感知的臨界狀態，即經常有連續3次以上的重複ack請求導致大量數據重傳，影響數據包下載速度。

網絡可達但是慢這種情況，算是網絡維護相對挑戰的事情之一啦，也是很多網絡運維工程師比較頭疼的一個問題。通過抓包和分析軟件，對定位和分析故障還是有較大幫助的。

很有意思的一次故障排查，生活中處處充滿意外和驚喜。