[TOC]
Wireshark分析藝術【讀書總結】
一，Wireshark實戰操作
介面的操作分析
三板斧之一：檢視統計、屬性資訊
效能分析三板斧之一：
【統計->捕獲檔案屬性】 Statistics -> Summary，檢視檔案屬性資訊，如平均速度、包大小、包數等等
判斷流量高低峰、是否過載
三板斧之二：檢視分析專家資訊
效能分析三板斧之二：
【分析->專家資訊】 Wireshark ->Analyze -> Expert Infos -> Notes，檢視抓包的統計資訊
檢視是否有Notes、Warnings、errors之類的資訊，看看是否有相關警告和錯誤，判斷網路質量、重傳亂序等
三板斧之三：檢視服務響應時間
效能分析三板斧之三：
【統計->服務響應時間】 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確認，這個就是所謂的網路承載量；如果在途位元組數超過網路承載量，那麼就會發生丟包重傳
- 在途位元組數 = 當前傳送方的【Seq + Len】 - 當前接收方的【ACK】
- 這個“當前”僅僅從抓包上的網路包序號去看就可以了，並不需要這兩個包有什麼關係，也正因為這兩個包沒有關係，所以才是計算出在途位元組數的方式
- 這個Len，一般而言，不應該超過TCP的MSS（最大資料欄位），這個值是1388，注意對比MTU（1500）
- 在途位元組數 = 當前傳送方的【Seq + Len】 - 當前接收方的【ACK】
網路擁塞
- 網路擁塞點：超過網路承載量而導致的網路擁塞。發生擁塞時的在途位元組數就是該時刻的網路擁塞點，估算網路擁塞點只需要簡單找到擁塞時的在途位元組數即可
- 擁塞的特徵就是連串的丟包、丟包後又會重傳；wireshark、tcpdump等抓包工具可以標識出重傳包
- 根據抓包工具，找到一連串重傳包中的第一個包，然後根據該包重傳的Seq值找到對應的原始包，最後，計算該原始包傳送時刻的在途位元組數，這個就標識當前的擁塞點
- 假如Seq+Len-Ack = 103122，這個單位表示位元組，也就是100KB，這個100KB就是最大的傳送視窗，因此需要設定Linux系統中傳送視窗的值
- Wireshark ->Analyze -> Expert Info -> Notes選單可以看到重傳統計
- 通過在途位元組數只是估算 網路擁塞點，並不一定很精確，可以取樣多次然後找到合適的值；多次取樣後的資料，其實保守的話應該取最小值而不是平均值
- 取最小值是因為這樣最保守，這樣才能真正保證網路不會擁塞；取完之後要設定Linux的傳送視窗
- 前面有說的，資料包的Len最大不應該超過1388，但是實際抓包分析過程中，卻會發現實際的Len可能是1338的兩倍或者N倍，這個是什麼原因呢？ 這是因為有一個所謂的LSO。
- 一般網路工作方式是：應用層把產生的資料交給TCP層，TCP再根據MSS大小進行分段，分段由CPU負責進行，最後再交給網路卡
- 如果啟用了LSO：TCP層就把大於MSS的資料塊直接交給了網路卡，讓網路卡去負責分段工作。
- 從傳送方的視角，相當於是站在了CPU視角，這樣抓包看到的應該是分段前的打包。從接收方視角，相當於是站在了網路卡視角，那麼看到的就應該是分段後的多個小包
- LSO出現的意義在於目前網路卡經常是千兆、萬兆，這樣CPU的負擔很重。比如625MB/s的網路流量大約需要耗費5GHz的CPU，因此為了緩解CPU的負擔，就把一些分段的工作直接交給網路卡去執行了，
一些實戰經驗告訴我們，Wireshark ->Analyze -> Expert Info -> Notes統計中的重傳率如果超過了0.1%，就需要採取一些措施了。但是現實網路環境下，要低於0.01%的重傳是基本不可能的。
傳送視窗
- 客戶端傳送視窗的兩個因素：網路上的擁塞視窗（cwnd）和伺服器上的接收視窗
- cwnd的增長方式是：先“慢啟動”、再進入“擁塞避免”，前者起點低但是能夠快速增長、後者起點高但是每一個RTT只能增加一個MSS（RTT指往返時間，也就是到了下一個從同一個方向傳輸的包）
- 根據抓包的資料，點開詳情，檢視其“Bytes in flight”值，可以簡單等同與cwnd
- 如果是“慢啟動”階段，那麼下一個RTT的包的cwnd應該要遠遠大於上一個包的cwnd
- 如果是“擁塞避免”階段，那麼下一個RTT的包的cwnd應該要增加一個MSS（乙太網中的MSS約為1460位元組）。
- 如果不符合上述兩種情況，比如cwnd增長的非常慢，那麼就需要根據cwnd的計算方式去分析了
TCP Nagle演算法和延遲確認Delayed ACK
- 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
複製程式碼- 延遲ACK：
如果tcp對每個資料包都傳送一個ack確認，那麼只是一個單獨的資料包為了傳送一個ack代價比較高，所以tcp會延遲一段時間，如果這段時間內有資料傳送到對端，則捎帶傳送ack，如果在延遲ack定時器觸發時候，發現ack尚未傳送，則立即單獨傳送；
延遲ACK好處：
(1) 避免糊塗視窗綜合症； (2) 傳送資料的時候將ack捎帶傳送，不必單獨傳送ack； (3) 如果延遲時間內有多個資料段到達，那麼允許協議棧傳送一個ack確認多個報文段；
- 當Nagle遇上延遲ACK：
試想如下典型操作，寫-寫-讀，即通過多個寫小片資料向對端傳送單個邏輯的操作，兩次寫資料長度小於MSS，當第一次寫資料到達對端後，對端延遲ack，不傳送ack，而本端因為要傳送的資料長度小於MSS，所以nagle演算法起作用，資料並不會立即傳送，而是等待對端傳送的第一次資料確認ack；這樣的情況下，需要等待對端超時傳送ack，然後本段才能傳送第二次寫的資料，從而造成延遲；
- 關閉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分析方法論
-
通過wireshark排查問題，需要分析網路包，在網路包中尋找一些線索，然後根據網路協議作出推斷，接著就是一個一個去否定，然後最終找到問題所在
-
需要能夠理解底層TCP協議，要能夠清楚每一個欄位表示的含義
-
要善用Wireshark的一些統計、分析工具；過濾器等
-
傳送發抓包和接收抓包是有極大區別的
-
要善用“三板斧“的操作流程和步驟去分析問題