Wireshark分析藝術【讀書總結】

  • 2019 年 12 月 12 日
  • 筆記

Wireshark分析藝術【讀書總結】

一，Wireshark實戰操作

介面的操作分析

三板斧之一：查看統計、屬性資訊

性能分析三板斧之一：

【統計->捕獲文件屬性】 Statistics -> Summary，查看文件屬性資訊，如平均速度、包大小、包數等等

判斷流量高低峰、是否過載

[圖片上傳失敗…(image-7200fa-1541746330755)]

三板斧之二：查看分析專家資訊

性能分析三板斧之二：

【分析->專家資訊】 Wireshark ->Analyze -> Expert Infos -> Notes，查看抓包的統計資訊

查看是否有Notes、Warnings、errors之類的資訊，看看是否有相關警告和錯誤，判斷網路品質、重傳亂序等

[圖片上傳失敗…(image-1e2d8b-1541746330755)]

三板斧之三：查看服務響應時間

性能分析三板斧之三：

【統計->服務響應時間】 statistics -> Service Response Time -> xxxxx（如：ONC-RPC -> Program:NFS）

查看各項操作的服務響應時間，判斷是否過載

將seq使用相對值來替代真實值

Edit->Preferences->Protocols->TCP,勾選 Relative Sequence Numbers

啟用之前就是相對值了。

查看TCP StreamGraph

Statistics -> TCP StreamGraph -> TCP Sequence Graph（Stevens）

查看數據傳輸情況，如傳輸的是否均勻、是否有TCP Zero Windows之類的

欄位含義&提示資訊

欄位含義就是wireshark的一些提示資訊,也就是wireshark抓包的一些info資訊，這些提示資訊都是Info這一欄中體現。

1，[Packer size limited during caputre]

如果某個包被標記提示[Packer size limited during caputre]，說明這個包沒有抓全，可以進一步查看下面的frame資訊。一般這個情況是抓包的姿勢不對。某些作業系統中，tcpdump默認只抓取每個幀的前96個位元組，因此tcpdump抓包的時候，可以通過 -s參數指定要抓取的位元組數

2，[TCP ACKed unseen segment]

如果wireshark發現被Ack的那個包沒有抓到，就會提示[TCP ACKed unseen segment]，不過這個提示大部分情況都可以忽略。因為大都情況下，剛開始抓包的時候，都是只抓到了後面的Ack而沒有抓到前面的ACK

3，[TCP Previous segment not captured]

TCP數據傳輸中，除了三次握手和四次握手之外，同一台機器發出的數據段應該是連續的，即後一個包的Seq等於前一個包的Seq+Len，正確情況都應該是這樣；如果發現後一個包的Seq大於前一個包的Seq+Len，那麼就說明中間丟了一段數據，如果丟失的數據在整個網路包中都找不到，wireshark就會提示[TCP Previous segment not captured]，

出現這種情況的兩個可能性：

  • 數據包真的丟了
  • 數據包並沒有真丟，只是抓包工具漏掉了
    • 如果確認Ack包中包含了沒有抓到的包，那就是抓包工具漏掉了，否則就是真丟了

4，[TCP Out-of-Order]

TCP數據傳輸中，除了三次握手和四次握手之外，同一台機器發出的數據段應該是連續的，即後一個包的Seq等於前一個包的Seq+Len，正確情況都應該是這樣；或者說後一個包的Seq應該會大於等於前一個包的Seq+Len，如果wireshark發現後一個包的Seq小於前一個包的Seq+Len，那麼就認為是亂序了，就會提示[TCP Out-of-Order]。

一般而言，小跨度的亂序影響不大，如果是大跨度的亂序則會導致快速重傳。舉例如下，如果一個包的順序是1、2、3、4、5被打亂成2、1、3、4、5則屬於小跨度亂序，影響不大；如果被打亂成2、3、4、5、1，則會觸發足夠多的Dup ACK，從而導致1號包的重傳。

5，[TCP Dup ACK]

當亂序或者丟包發生時，接收方就會收到一些Seq號比期望值大的包，TCP協議每收到一個這種包就會ACK一次期望的Seq值，通過這個方式告知發送方，因此就產生了一些重複的Ack。Wireshark抓到這些重複的Ack就會提示[TCP Dup ACK].

6，[TCP Fast Retransmission]

當發送方連續收到3個或者以上[TCP Dup ACK]時，就意識到之前發的包可能丟了，於是根據RFC的規定就會開始快速重傳。[TCP Dup ACK]是接收方回應給發送方的，因此發送方就能夠感知到併當連續收到3個以上的時候就開啟快速重傳。

快重傳演算法規定，發送方只要一連收到3個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計數器時間到期。

7，[TCP Retransmission]

如果一個包真的丟了，又沒有後續包可以在接收方觸發[Dup Ack]，那麼就不會開啟快速重傳，這種情況發送方只能等到超時後再發送重傳，超時重傳的包就會被wireshark標記並提示[TCP Retransmission]

TCP 超時與重傳應該是 TCP 最複雜的部分之一，超時重傳是 TCP 保證可靠傳輸的基礎。當 TCP 在發送數據時，數據和 ack 都有可能會丟失，因此，TCP 通過在發送時設置一個定時器來解決這種問題。如果定時器溢出還沒有收到確認，它就重傳數據。關鍵之處就在於超時和重傳的策略，需要考慮兩方面：

  • 超時時間設置
  • 重傳的頻率（次數）

在 Linux 較高的內核版本中，比如 3.15 中，已經有了至少 9 個定時器：超時重傳定時器，持續定時器，ER延遲定時器，PTO定時器，ACK延遲定時器，SYNACK定時器，保活定時器，FIN_WAIT2定時器，TIME_WAIT定時器。

8，[TCP zerowindow]

TCP包中「win=xxx」代表接收窗口的大小，表示這個包的發送方當前還有多少緩衝區可以接受數據。當wireshark發行一個包中的「win=0」時，就會標記提示[TCP zerowindow]，表示緩衝區已經滿了，無法再接收數據了。

一般的，在緩衝區滿之前，窗口大小應該是逐漸減小的過程。

9，[TCP window Full]

如果一個包的發送方已經把對方所聲明的接收窗口大小耗盡了，就會被wireshark標記為[TCP window Full]。比如某一端在握手時聲明自己的接收窗口只有65535，也就意味著對端最多只能給他發送65535位元組的數據而無需確認，即「在途位元組數」最多只能是65535，當wireshark計算出對端已經有65535位元組未被確認時，就會發生這個提示。

[TCP window Full]和上面的[TCP zerowindow]比較容易混淆，前者表示這個包的發送方暫時沒有辦法再發送數據了；後者表示這個包的發送方沒有辦法再接收數據了；兩者都會意味著要暫停數據傳輸

10，[TCP segment of reassembled PDU]

只有在Edit->Preferences->Protocols->TCP菜單里啟用了Allow sub dissector to reassemble TCP streams後，才有可能收到這個提示。這個表示可以把屬於同一個應用層PDU的TCP包虛擬的集中起來

11，[Continuation to #]

只有在Edit->Preferences->Protocols->TCP菜單里關閉了Allow sub dissector to reassemble TCP streams後，才有可能收到這個提示。

12，[Time-to-live-exceeded(Fragment reasembly time execeeded)]

（Fragment reasembly time execeeded）表示這個包的發送方之前收到了一些分片，但是由於某些原因導致遲遲無法組裝起來。

比如傳輸過程中有一些分片被丟包了，那麼接收方就無法組裝起來，然後就通過這個ICMP的方式告知發送方

ICMP是（Internet Control Message Protocol）Internet控制報文協議。它是TCP/IP協議族的一個子協議，用於在IP主機、路由器之間傳遞控制消息。控制消息是指網路通不通、主機是否可達、路由是否可用等網路本身的消息。這些控制消息雖然並不傳輸用戶數據，但是對於用戶數據的傳遞起著重要的作用。

二，Wireshark分析TCP協議

TCP抓包協議基礎

TCP控制欄位

在TCP層，有個FLAGS欄位，這個欄位有以下幾個標識：SYN, FIN, ACK, PSH, RST, URG.

抓包顯示的控制欄位形態如下：

[SYN] ：建立連接、發起包 [FIN] ：關閉連接、結束包 [PSH] ：DATA數據傳輸 [ACK] ：ACK回應 [RST] ：RESET、連接重置

另外兩個常用欄位：

[Len] ：數據包長度 [Seq] ：數據包序列號

ACK是可能與SYN，FIN等同時使用的，比如SYN和ACK可能同時為1，它表示的就是建立連接之後的響應，如果只是單個的一個SYN，它表 示的只是建立連接

當出現FIN包或RST包時，我們便認為客戶端與伺服器端斷開了連接 當出現SYN和SYN＋ACK包時，我們認為客戶端與伺服器建立了一個連接

抓包方向（client or server）

  • 抓包的時候，不管是通過wireshark抓包，還是通過tcpdump抓包，都需要看看是從客戶端方向抓包，還是從服務端方向抓包，不同的方向，抓包的情況完全不一樣，因為網路（公網、實際環境）上有很多異常情況發生。

TCP的Ack

對應http而言，一般就是request->reponse，一問一答。但對應TCP而言，並不一定每個包都會ACK。TCP的ACK是一種累積的ACK，也就是表示在我這個ACK之前的所有其他ACK都已經確認收到了。

比如，97號包的ACK=65701，96號包的Seq+Len=64273+1428=65701，那麼就是表示97號的ACK是對96號的回應，也就是96號之前的其他沒有被顯示ACK的包，其實都已經通過97號包ACK了，這樣發送方也就知道了在96號之前發出去的所有包對方都已經收到並ACK了。

MSL、TTL、RTT

  • MSL（Maximum Segment Lifetime），表示「報文最大生存時間」，是所有報文都遵循的在網路上存在的最長時間，超過這個時間報文將被丟棄
    • RFC 793中規定MSL為2分鐘，實際應用中常用的是30秒，1分鐘和2分鐘等。
    • 2MSL即兩倍的MSL，TCP的TIME_WAIT狀態也稱為2MSL等待狀態
  • TTL（Time to live），表示生存時間，是ip頭的一個域，生存時間是由源主機來設置一個初始值，但TTL不是存的具體時間，而是表示可以經過的最大路由數。
    • 根據RFC 1812，一個網路包的TTL每減去1就表示它經過一次路由。一般TTL的初始值為64，如果某個ACK包的TTL是62，則意味著是是距離此設備兩跳的設備發出來的。
    • TTL在wireshark抓包中的形態如Time to live: 62
    • TTL=0則數據報將被丟棄，同時發送ICMP報文通知源主機
    • 一般在快取、連接心跳中也用到TTL這個，他們和TCP協議中的TTL是有區別的，快取、連接心跳中的TTL表示的就是數據快取or剩餘的時間。
  • RTT（round-trip time），表示客戶到伺服器往返所花時間，TCP含有動態估算RTT的演算法
    • TCP會持續估算一個給定連接的RTT，因為RTT受網路傳輸擁塞程式的變化而變化

MAC地址解析

Protocol = ARP Source 和 Destination 都是MAC地址格式如 00:60:48:ff:12:31

抓包分析中，如果網路不通，發出去收不到ACK等等之類的，要再進一步看看每個包的MAC地址是否正確，反之有多個MAC地址導致的一些問題

TCP握手和揮手協議

TCP三次握手&判斷回包

  • 三次握手協議
    • client->server : [SYN] Seq=X win=xxx Len=0 MSS=xxx
    • server->client : [SYN, ACK] Seq=Y，ACK=X+1 win=xxx Len=0 MSS=xxx
    • client->server : [ACK] Seq=X+1，Ack=Y+1 win=xxx Len=0
  • 抓包數據，如何判斷一個包是上一個包的回包呢？根據TCP協議，下一個包的Ack的值如果等於上一個包的Seq + Len，則表示是其回包
    • 上一個和下一個，很多情況下並不是連續的，也行下一個回包距離上一個包已經過了很多包了，因為重傳、延遲的原因的
  • 三次握手的時候會相互聲明各自的MSS

TCP四次揮手&三次揮手

  • TCP四次揮手協議
    • client->server : FIN Seq=X，ACK=Y
    • server->client : Seq=Y，ACK=X+1
    • server->client : FIN Seq=Y，ACK=X+1
    • client->server : Seq=X+1，Ack=Y+1
  • 正常而言，都會有這樣的四次揮手，但是如果有延遲確認，那麼四次揮手就變成了3次揮手，省掉了四次揮手中的第二個包
    • client->server : FIN Seq=X，ACK=Y
    • server->client : FIN Seq=Y，ACK=X+1
    • client->server : Seq=X+1，Ack=Y+1

TCP擁塞控制演算法

在途位元組數

  • 在途位元組數【bytes in flight】，表示的是已經發送出去，但是還沒有被確認的位元組數，這個確認指的是對端發出ACK確認，這個就是所謂的網路承載量；如果在途位元組數超過網路承載量，那麼就會發生丟包重傳
    • 這個「當前」僅僅從抓包上的網路包序號去看就可以了，並不需要這兩個包有什麼關係，也正因為這兩個包沒有關係，所以才是計算出在途位元組數的方式
    • 這個Len，一般而言，不應該超過TCP的MSS（最大數據欄位），這個值是1388，注意對比MTU（1500）
    • 在途位元組數 = 當前發送方的【Seq + Len】 – 當前接收方的【ACK】

網路擁塞

  • 網路擁塞點：超過網路承載量而導致的網路擁塞。發生擁塞時的在途位元組數就是該時刻的網路擁塞點，估算網路擁塞點只需要簡單找到擁塞時的在途位元組數即可
    • 從發送方的視角，相當於是站在了CPU視角，這樣抓包看到的應該是分段前的打包。從接收方視角，相當於是站在了網卡視角，那麼看到的就應該是分段後的多個小包
    • LSO出現的意義在於目前網卡經常是千兆、萬兆，這樣CPU的負擔很重。比如625MB/s的網路流量大約需要耗費5GHz的CPU，因此為了緩解CPU的負擔，就把一些分段的工作直接交給網卡去執行了，
    • 取最小值是因為這樣最保守，這樣才能真正保證網路不會擁塞；取完之後要設置Linux的發送窗口
    • 假如Seq+Len-Ack = 103122，這個單位表示位元組，也就是100KB，這個100KB就是最大的發送窗口，因此需要設置Linux系統中發送窗口的值
    • 擁塞的特徵就是連串的丟包、丟包後又會重傳；wireshark、tcpdump等抓包工具可以標識出重傳包
    • 根據抓包工具，找到一連串重傳包中的第一個包，然後根據該包重傳的Seq值找到對應的原始包，最後，計算該原始包發送時刻的在途位元組數，這個就標識當前的擁塞點
    • Wireshark ->Analyze -> Expert Info -> Notes菜單可以看到重傳統計
    • 通過在途位元組數只是估算 網路擁塞點，並不一定很精確，可以取樣多次然後找到合適的值；多次取樣後的數據，其實保守的話應該取最小值而不是平均值
    • 前面有說的，數據包的Len最大不應該超過1388，但是實際抓包分析過程中，卻會發現實際的Len可能是1338的兩倍或者N倍，這個是什麼原因呢？這是因為有一個所謂的LSO。
    • 一般網路工作方式是：應用層把產生的數據交給TCP層，TCP再根據MSS大小進行分段，分段由CPU負責進行，最後再交給網卡
    • 如果啟用了LSO：TCP層就把大於MSS的數據塊直接交給了網卡，讓網卡去負責分段工作。

一些實戰經驗告訴我們，Wireshark ->Analyze -> Expert Info -> Notes統計中的重傳率如果超過了0.1%，就需要採取一些措施了。但是現實網路環境下，要低於0.01%的重傳是基本不可能的。

發送窗口

  • 客戶端發送窗口的兩個因素：網路上的擁塞窗口（cwnd）和伺服器上的接收窗口
    • 如果是「慢啟動」階段，那麼下一個RTT的包的cwnd應該要遠遠大於上一個包的cwnd
    • 如果是「擁塞避免」階段，那麼下一個RTT的包的cwnd應該要增加一個MSS（乙太網中的MSS約為1460位元組）。
    • 如果不符合上述兩種情況，比如cwnd增長的非常慢，那麼就需要根據cwnd的計算方式去分析了
    • cwnd的增長方式是：先「慢啟動」、再進入「擁塞避免」，前者起點低但是能夠快速增長、後者起點高但是每一個RTT只能增加一個MSS（RTT指往返時間，也就是到了下一個從同一個方向傳輸的包）
    • 根據抓包的數據，點開詳情，查看其「Bytes in flight」值，可以簡單等同與cwnd

TCP Nagle演算法和延遲確認Delayed ACK

  1. Nagle演算法：
    • 是為了減少廣域網的小分組數目，從而減小網路擁塞的出現；
    • 該演算法要求一個tcp連接上最多只能有一個未被確認的未完成的小分組，在該分組ack到達之前不能發送其他的小分組，tcp需要收集這些少量的分組，並在ack到來時以一個分組的方式發送出去；其中小分組的定義是小於MSS的任何分組；
    • 該演算法的優越之處在於它是自適應的，確認到達的越快，數據也就發哦送的越快；而在希望減少微小分組數目的低速廣域網上，則會發送更少的分組；
       if there is new data to send        if the window size >= MSS and available data is >= MSS          send complete MSS segment now        else          if there is unconfirmed data still in the pipe            enqueue data in the buffer until an acknowledge is received          else            send data immediately          end if        end if      end if
  1. 延遲ACK：

如果tcp對每個數據包都發送一個ack確認，那麼只是一個單獨的數據包為了發送一個ack代價比較高，所以tcp會延遲一段時間，如果這段時間內有數據發送到對端，則捎帶發送ack，如果在延遲ack定時器觸發時候，發現ack尚未發送，則立即單獨發送；

延遲ACK好處：

(1) 避免糊塗窗口綜合症； (2) 發送數據的時候將ack捎帶發送，不必單獨發送ack； (3) 如果延遲時間內有多個數據段到達，那麼允許協議棧發送一個ack確認多個報文段；

  1. 當Nagle遇上延遲ACK：

試想如下典型操作，寫-寫-讀，即通過多個寫小片數據向對端發送單個邏輯的操作，兩次寫數據長度小於MSS，當第一次寫數據到達對端後，對端延遲ack，不發送ack，而本端因為要發送的數據長度小於MSS，所以nagle演算法起作用，數據並不會立即發送，而是等待對端發送的第一次數據確認ack；這樣的情況下，需要等待對端超時發送ack，然後本段才能發送第二次寫的數據，從而造成延遲；

  1. 關閉Nagle演算法：

使用TCP套接字選項TCP_NODELAY可以關閉套接字選項;

如下場景考慮關閉Nagle演算法：

(1) 對端不向本端發送數據，並且對延時比較敏感的操作；這種操作沒法捎帶ack； (2) 如上寫-寫-讀操作；對於此種情況，優先使用其他方式，而不是關閉Nagle演算法：

TCP和UDP的區別、對比

主要區別

TCP和UDP的區別如TCP是可靠的、UDP是不可靠的，但是實際中的表現是何為可靠？何為不可靠？具體協議的ACK有何區別？

不管對於TCP還是UDP，都可能會被分片，這是由於乙太網的MSS決定的；不同在於分片傳輸的處理：

  • UDP而言，如果分片傳輸導致某些分片丟失，則接收方無法完成重組，這樣發送方會將所有分片重傳，如果發生重傳則效率就會比較低。
    • UDP不可靠就在於此，沒有一個機制保證數據被安全送達，需要應用層去負責重傳
  • TCP而言，TCP的分段機制可以把數據包拆小後封裝在多個包里，這樣就避免了被網路層分片。重傳而言，TCP只需要重傳丟失的那個包而不需要重傳整個包
    • TCP可靠也在於此，TCP會有機制保證數據被安全送達，而不需要應用層去處理重傳
    • 因為TCP只會重傳丟失的某個包而不是整個包，因此重傳效率比UDP高很多

UDP 比 TCP 更適合語音

語音通話的場景在於不能接受延遲，但是可以接受音質稍差。這樣的話，UDP傳輸的時候，如果有些包丟失，應用層可以選擇忽略並繼續傳輸其他包，丟到一些包只會影響到音質，但是保證了流暢性。TCP而言，會重傳每個包，只要丟包就重傳，這樣就會導致有一定的延遲，在語音中如果有延遲則並不可取。

因此，TCP和UDP，各自有各自的適合場景。語音、影片中，UDP更合適，像聲網、linphone等都是UDP去處理音影片。基礎、核心協議交互中必須採用TCP。

TCP和UDP的效率問題

TCP在傳輸過程都需要往返時間來確認也就是ACK，而UDP則無需確認，那麼UDP的效率一定比TCP高嗎？這個是不一定的，雖然UDP可以一直往外不停的發包，不用等待ACK；但是TCP有發送窗口的存在，如果發送窗口小，並沒有佔滿頻寬，那麼肯定受到往返時間的約束使得效率稍低，但是如果只要窗口足夠大並且合適，跑滿頻寬，那麼TCP也是可以不受往返時間的約束而源源不斷的傳輸數據。

舉例：馬路上只有一輛車來回跑去拉貨，回程過程相當於空跑（回程相當於TCP的ACK），這樣TCP的效率當然低。但是如果在不擁塞的情況下，盡量提高車輛數量，是的馬路上的車被剛好充滿，這樣總體的傳輸效率提高了，並且回程的ACK也不受影響。

數據包分片、MTU、MSS

數據包分片和重組

分組交換，把大的數據分割成小包，這樣可以實現鏈路共享，而不至於因為某一方阻塞所有。既然要分割成小包，那麼必然要確定一個最大的包大小，這個就是MTU（Maximum Transmission Unit）最大傳輸單位，值為1500位元組。如果除去20個位元組的包頭結構，那麼一個IP包最大的包大小為1500-20=1480位元組。如果要傳輸的數據塊超過1480位元組，那麼網路層就會將其分片處理，封裝為多個網路包傳輸。對於TCP而言，TCP協議層會主動把數據分成小段後再交給網路層，TCP的最大分段大小稱之為MSS（Maximum Segment Size），這個MSS被設置為MTU減去IP頭和TCP頭之後的大小，這樣剛好可以滿足一個MTU。因為UDP沒有MSS的概念，因此就只能交給網路層去處理分片了。

但是需要注意的是，目前有些網路是Jumbo Frame（巨幀）或者PPPOE這樣的設備，那麼他們的MTU則不是1500位元組。目前發送方並沒有一個好的機制來確定最佳分片大小，應該盡量使得網路中的設備的MTU保持一致。如果網路中的設備的MTU不一致，那麼TCP協議如何適配MTU呢？我們知道TCP建連的時候必須要先進行三次握手，TCP在前兩個握手包中會相互聲明自己的MSS。如果client端聲明自己的MSS=8960（巨幀），server端申明自己的MSS=1460，那麼client在三次握手後就知道了server端的MSS，因此當client想要發送大於server端MSS的包的時候就會主動將自己的MSS降低為server端的MSS大小，從而適配接收方的MTU，可見，TCP協議層做了非常多的優化和處理

既然有分片，那麼接收方必然要進行分片重組，通過抓包工具可以得知，分片的每個包都包含了off=xxx，ID=xxx這樣的資訊，接收方會把ID相同的分片按照off偏移量進行重組。那麼接收方又如何得知那個包才是最後的分片呢？然後什麼時候開始重組呢？這裡就在於最後一個分片包有一個特殊的Flag，叫More fragment = 0，抓包中的表現形式是..0. ... = More fragment: Not set，這個就表示它是最後一個分片，然後可以開始重組包了。如果是其他分片包，形如..1. ... = More fragment: set則表示接收方需要快取，等待其他分片傳輸完成

MTU的實戰

如果client端的MTU=9000，server端的MTU=1500，那麼當client請求server端的時候，client的包經過路由器時候，要麼就被丟包，要麼就被分片。如果這個巨幀包在網路層攜帶了DF（Don't fragment）標誌則被丟棄（設置則表示不允許分片），如果沒有設置則進行分片傳輸。需要注意的是，這種情況下如果丟包了重傳還是會被丟棄，就成了黑洞了。

測試中，可以通過ping命令模擬這樣的情況：

成功：  ping xxx.xxx.xxx.xxx -l 1472 -f -n 1    失敗：  ping xxx.xxx.xxx.xxx -l 1473 -f -n 1

-f 參數表示設置DF標誌 -l 參數表示請求位元組

當請求位元組設置為1472的時候，因為ICMP頭部為8位元組、IP頭為20位元組，因此1472+8+20=1500，剛好是一個MTU，因此可以ping成功。但是第二個1473+8+20=1501位元組超過MTU了，又因為設置了DF標誌表示不允許分片，因此傳輸失敗，一般這樣的情況下，路由器會回復Packet needs to be fragmented but DF set。

抓包的時候，如果發現一直重傳，某個某些相對較大的包（查看Len值）才重傳，那麼可以通過ping xxx.xxx.xxx.xxx -l [Len] -f值進行測試驗證，通過這個ping指定的[Len]的大小變化來尋得規律，可能就會發現網路上某個設備的MTU並非1500，這樣導致了超過這個就重傳的現象。

特殊的流控和頻寬

client 和 server端直接一定有交換機、路由器等設備，如果server端是萬兆網卡，client端是千兆網卡，就有可能使得server端發送過快導致數據堵在交換機上，從而交換機在堵滿之後發生丟包。但是一般而言，server端的頻寬本應該要大於client端才算合理，為了避免擁塞，因此需要有一種流控機制，允許交換機在過載時告知server端放慢速度或者暫停傳輸。

有一種「暫停幀」，就能夠滿足這樣的需求：當交換機的緩衝區即將被填滿時發送給server端一個暫停幀，當server端等待一會兒再發，這樣就可以避免溢出丟包，也避免丟包後的重傳。server端等待多久則由暫停幀中的pause_time指定，這樣server端在等待pause_time後才會開始繼續發送。當然交換機還可以給server端發送一個pause_time=0的暫停幀，告知server端，我已經消化完了，可以立即發送了。

注意，這的流控和TCP的流控是不一樣的

三，用Wireshark分析方法論

  1. 通過wireshark排查問題，需要分析網路包，在網路包中尋找一些線索，然後根據網路協議作出推斷，接著就是一個一個去否定，然後最終找到問題所在
  2. 需要能夠理解底層TCP協議，要能夠清楚每一個欄位表示的含義
  3. 要善用Wireshark的一些統計、分析工具；過濾器等
  4. 發送發抓包和接收抓包是有極大區別的
  5. 要善用「三板斧「的操作流程和步驟去分析問題

VirMach 便宜 VPS

QNews

QNews