# 如何使用 Wireshark 分析 TCP 吞吐瓶頸

Debug 網路質量的時候，我們一般會關注兩個因素：延遲和吞吐量（頻寬）。延遲比較好驗證，Ping 一下或者 mtr 一下就能看出來。正巧，我在3A平臺購買了雲伺服器，可以測試一個 debug 吞吐量的辦法。

看重吞吐量的場景一般是所謂的長肥管道。 比如下載大檔案。吞吐量沒有達到網路的上限，主要可能受 3 個方面的影響：

1. 傳送端出現了瓶頸
2. 接收端出現了瓶頸
3. 中間的網路層出現了瓶頸

傳送端出現瓶頸一般的情況是 buffer 不夠大，因為傳送的過程是，應用呼叫 syscall，將要傳送的資料放到 buffer 裡面，然後由系統負責傳送出去。如果 buffer 滿了，那麼應用會阻塞住（如果使用 block 的 API 的話），直到 buffer 可用了再繼續 write，生產者和消費者模式。

![圖片](https://f.pz.al/pzal/2022/09/09/8a3d2fe620372.png)

傳送端出現瓶頸一般都比較好排查，甚至透過應用的日誌看何時阻塞住了即可。大部分情況都是第 2，3 種情況，比較難以排查。這種情況發生在，傳送端的應用已經將內容寫入到了系統的 buffer 中，但是系統並沒有很快的傳送出去。

TCP 為了最佳化傳輸效率（注意這裡的傳輸效率，並不是單純某一個 TCP 連線的傳輸效率，而是整體網路的效率），會:

1. 保護接收端，傳送的資料不會超過接收端的 buffer 大小 (Flow control)。資料傳送到接受端，也是和上面介紹的過程類似，kernel 先負責收好包放到 buffer 中，然後上層應用程式處理這個 buffer 中的內容，如果接收端的 buffer 過小，那麼很容易出現瓶頸，即應用程式還沒來得及處理就被填滿了。那麼如果資料繼續發過來，buffer 存不下，接收端只能丟棄。
2. 保護網路，傳送的資料不會 overwhelming 網路 (Congestion Control, 擁塞控制), 如果中間的網路出現瓶頸，會導致長肥管道的吞吐不理想；

對於接收端的保護，在兩邊連線建立的時候，會協商好接收端的 buffer 大小 (receiver window size, rwnd), 並且在後續的傳送中，接收端也會在每一個 ack 回包中報告自己剩餘和接受的 window 大小。

這樣，傳送端在傳送的時候會保證不會傳送超過接收端 buffer 大小的資料。（意思是，傳送端需要負責，receiver 沒有 ack 的總數，不會超過 receiver 的 buffer.）

![圖片](https://f.pz.al/pzal/2022/09/09/45a84723a4563.png)

對於網路的保護，原理也是維護一個 Window，叫做 Congestion window，擁塞視窗，cwnd, 這個視窗就是當前網路的限制，傳送端不會傳送超過這個視窗的容量（沒有 ack 的總數不會超過 cwnd）。

怎麼找到這個 cwnd 的值呢？

這個就是關鍵了，預設的演算法是 cubic, 也有其他演算法可以使用，比如 Google 的 **BBR**[3].

主要的邏輯是，慢啟動(Slow start), 傳送資料來測試，如果能正確收到 receiver 那邊的 ack，說明當前網路能容納這個吞吐，將 cwnd x 2，然後繼續測試。直到下面一種情況發生：

1. 傳送的包沒有收到 ACK
2. cwnd 已經等於 rwnd 了

第 2 點很好理解，說明網路吞吐並不是一個瓶頸，瓶頸是在接收端的 buffer 不夠大。cwnd 不能超過 rwnd，不然會 overload 接收端。

對於第 1 點，本質上，傳送端是用丟包來檢測網路狀況的，如果沒有發生丟包，表示一切正常，如果發生丟包，說明網路處理不了這個傳送速度，這時候傳送端會直接將 cwnd 減半。

但實際造成第 1 點的情況並不一定是網路吞吐瓶頸，而可能是以下幾種情況：

1. 網路達到了瓶頸
2. 網路質量問題丟包
3. 中間網路裝置延遲了包的送達，導致傳送端沒有在預期時間內收到 ACK

2 和 3 原因都會造成 cwnd 下降，無法充分利用網路吞吐。

以上就是基本的原理，下面介紹如何定位這種問題。

## rwnd 檢視方式

這個 window size 直接就在 TCP header 裡面，抓下來就能看這個欄位。

![圖片](https://f.pz.al/pzal/2022/09/09/d9db56fd1e6d7.png)

但是真正的 window size 需要乘以 factor, factor 是在 **TCP 握手節點透過 TCP Options 協商的**[4]。所以如果分析一條 TCP 連線的 window size，必須抓到握手階段的包，不然就不可以知道協商的 factor 是多少。

![圖片](https://f.pz.al/pzal/2022/09/09/86074d3eee14e.png)

## cwnd 檢視方式

Congestion control 是傳送端透過演算法得到的一個動態變數，會試試調整，並不會體現在協議的傳輸資料中。所以要看這個，必須在傳送端的機器上看。

在 Linux 中可以使用 `ss -i` 選項將 TCP 連線的引數都列印出來。

![圖片](https://f.pz.al/pzal/2022/09/09/95ee7ba6a80fa.png)

這裡展示的單位是 **TCP MSS.**[5] 即實際大小是 1460bytes * 10.

## Wireshark 分析

Wireshark 提供了非常使用的統計功能，可以讓你一眼就能看出當前的瓶頸是發生在了哪裡。但是第一次開啟這個圖我不會看，一臉懵逼，也沒查到資料要怎麼看。好在我**同事**[6]會，他把我教會了，我在這裡記錄一下，把你也教會。

首先，開啟的方式如下：

![圖片](https://f.pz.al/pzal/2022/09/09/0f0b44186533d.png)

然後你會看到如下的圖。

![圖片](https://f.pz.al/pzal/2022/09/09/bebe0e6cf484b.png)

首先需要明確，tcptrace 的圖表示的是單方向的資料傳送，因為 tcp 是雙工協議，兩邊都能傳送資料。其中最上面寫了你當前在看的圖資料是從 10.0.0.1 傳送到 192.168.0.1 的，然後按右下角的按鈕可以切換看的方向。

X 軸表示的是時間，很好理解。

然後理解一下 Y 軸表示的 Sequence Number, 就是 TCP 包中的 Sequence Number，這個很關鍵。圖中所有的資料，都是以 Sequence Number 為準的。

所以，你如果看到如上圖所示，那麼說明你看反了，因為資料的 Sequence Number 並沒有增加過，說明幾乎沒有傳送過資料，需要點選 Switch Direction。

![圖片](https://f.pz.al/pzal/2022/09/09/71849b6ee649b.png)

這就對了，可以看到我們傳輸的 Sequence Number 在隨著時間增加而增加。

這裡面有 3 條線，含義如下：

![圖片](https://f.pz.al/pzal/2022/09/09/9ab0b4346fb5d.png)

除此之外，另外還有兩種線：

![圖片](https://f.pz.al/pzal/2022/09/09/f27f5f8e0771f.png)

需要始終記住的是 Y 軸是 Sequence Number，紅色的線表示 SACK 的線表示這一段 Sequence Number 我已經收到了，然後配合黃色線表示 ACK 過的 Sequence Number，那麼傳送端就會知道，在中間這段空擋，包丟了，紅色線和黃色線縱向的空白，是沒有被 ACK 的包。所以，需要重新傳輸。而藍色的線就是表示又重新傳輸了一遍。

學會了看這些圖，我們可以認識幾種常見的 pattern：

### 丟包

![圖片](https://f.pz.al/pzal/2022/09/09/c49bdbd2cb00e.png)

很多紅色 SACK，說明接收端那邊重複在說：中間有一個包我沒有收到，中間有一個包我沒有收到。

### 吞吐受到接收 window size 限制

![圖片](https://f.pz.al/pzal/2022/09/09/09e55f6ab19aa.png)

從這個圖可以看出，黃色的線（接收端一 ACK）一上升，藍色就跟著上升（傳送端就開始發），直到填滿綠色的線（window size）。說明網路並不是瓶頸，可以調大接收端的 buffer size.

### 吞吐受到網路質量限制

![圖片](https://f.pz.al/pzal/2022/09/09/e6952bea1ee67.png)

從這張圖中可以看出，接收端的 window size 遠遠不是瓶頸，還有很多空閒。

![圖片](https://f.pz.al/pzal/2022/09/09/6fd0c1006e2c6.png)

放大可以看出，中間有很多丟包和重傳，並且每次只傳送一點點資料，這說明很有可能是 cwnd 太小了，受到了擁塞控制演算法的限制。

如何使用 Wireshark 分析 TCP 吞吐瓶頸

相關文章