技術標籤：wireshark使用

常見的網路問題

小包問題也叫愚笨視窗綜合症(Silly Window Syndrome)

常常會有這樣的情況，應用層傳遞給TCP傳輸層的資料很小，要比TCP(20Bytes)+ IP(20Byte)頭部的大小還要小，這樣其實是一種浪費，我們把這樣的問題叫愚笨視窗綜合症，也叫小包問題。

延遲確認(Delayed ACK) 與 Nagle 演算法

延遲確認是一種常見的TCP互動式場景策略，常見的例子(愚笨視窗綜合症)就是SSH與遠端伺服器建立連線之後在命令列輸入的每一個字母在傳送方開啟延遲確認的TCP選項之後，傳送方發給接收方的網路包中如果除了確認收到報文之外沒有什麼資訊需要回復給傳送方，那麼接收方就會等待一個超時的時間(TCP協議規定這個值應當小於500ms rfc1122

Nagle演算法是通過在傳送方維護一個“buffer”，將傳送包體大小積累到一個MSS之後傳送網路包。

if there is new data to send then    if the window size ≥ MSS and available data is ≥ MSS then        send complete MSS segment now    else        if there is unconfirmed data still in the pipe then            enqueue data in the buffer until an acknowledge is received        else            send data immediately        end if    end ifend if
 

本質上也是通過在通道中減少網路包的傳送數量來優化網路傳輸。

聽起來兩種機制都是沒有什麼問題的，都是在解決特定環境下的特定問題。但是如果傳送方開啟了Nagle演算法與此同時接收方也開啟了延遲確認，在傳送方出現write-write-read這樣的報文組合的時候就有可能出現等待到一個延遲確認超時時間後的網路等待。

如何解決延遲確認與Nagle演算法衝突的問題

兩種思路：

• 在應用層，避免出現 write-wirte-read這樣的網路呼叫
• 在傳輸協議層，在傳送方關閉Nagle演算法機制或者在接收方關閉DelayACK

對於關閉DelayedACK：

TCP_QUICKACKtcp_delack_min
 

# echo 1 > /proc/sys/net/ipv4/tcp_delack_min

RHEL - realtime tuning - Reduce TCP Delayed ack timeout

對於關閉 Nagle 演算法：

在TCP連線選項中選擇 TCP_NO_DELAY

網路包重傳

協議中的重傳場景：

超時重傳

出現擁塞，當傳送方的原包發出後經過一個RTO的超時等待時間後就會重傳這個網路包。

超時重傳之後，擁塞視窗(傳送視窗)的大小也需要調整，協議中建議 cnwnd = min ( traffic_in_flight / 2, 2)。

快速重傳

如果接收方收到一組亂序的網路包，按照協議它應當連續傳送3個重複ack，當傳送方收到這樣的ACK後需要啟動快速重傳機制。

具體細節詳見下面wireshark抓包分析截圖：

網路包亂序

接收方收到亂序包需要根據協議傳送重複的3個ACK確認包，隨後傳送方會有快速重傳的機制將接收方的ACK包重傳，而無視RTO的超時限制。

細節參見上方快速重傳Wireshark抓包分析截圖。

網路傳輸慢速

慢啟動與網路擁塞點

計劃使用FTP協議傳輸大檔案，進行網路抓包分析，得出類似下面的 time/sequence graph(steven)：

// TODO

TCP傳送視窗

LRO(Large Recieve offload)

WireShark 如何解決

檢視超時重傳的方法

Analysis -> Expert information

Note 類資訊中Summary 部分為 “this frame is a (suspected) retransmission “

使用Wireshark自動分析

• 檢視分析的摘要資訊

Analysis -> Expert information

• 選定需要檢視的TCP連線，檢視TCP stream Graph 等統計資訊

Statistics -> TCP Stream Graph

Time-Sequence Graph(steven)

有用的幾個WireShark配置

常用的幾個網路命令

• 使用ICMP傳送指定大小的網路包(macOS)

ping  -s  -D -c 

其中 -D 引數表示 在 IP 包中flag設定中 DF(Don’t Fragment) 標誌

• WireShark中列出超過200ms的ack報文(查詢疑似延遲確認報文)

tcp.analysis.ack_rtt>0.1 and tcp.len==0

文中名詞解釋

MSS(Maximum Segment Size)

TCP的3次握手會將雙方的MSS值告訴對方，將MSS值加上TCP頭和IP頭的長度就知道了下面的MTU的大小。

MTU(Maximum Trasmission Unit)

MTU = MSS + TCP Head length(一般是20Bytes) + IP Head leagth(20Bytes)

通常的大多數網路中MTU的大小在 1500 Bytes，而開啟了巨幀(Jumbo Frame)的網路MTU的大小在 9000 Bytes。