千鋒教育-做有情懷、有良心、有品質的職業教育機構

                    手機站
                    千鋒教育

                    千鋒學習站 | 隨時隨地免費學

                    千鋒教育

                    掃一掃進入千鋒手機站

                    領取全套視頻
                    千鋒教育

                    關注千鋒學習站小程序
                    隨時隨地免費學習課程

                    【熱點話題】 零基礎學IT IT學習教程 IT學習筆記 IT技術干貨 IT培訓機構 IT應聘面試 IT職場就業 Java培訓機構哪些好
                    當前位置:首頁  >  關于學院  >  技術干貨  > 如何使用Wireshark分析TCP吞吐瓶頸

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

                    來源:千鋒教育
                    發布人:syq
                    時間: 2022-09-15 09:44:19 1663206259

                      Debug 網絡質量的時候,我們一般會關注兩個因素:延遲和吞吐量(帶寬)。延遲比較好驗證,Ping 一下或者 mtr[1] 一下就能看出來。這篇文章分享一個 debug 吞吐量的辦法。

                    使用Wireshark分析TCP

                      看重吞吐量的場景一般是所謂的長肥管道(Long Fat Networks, LFN, rfc7323[2]). 比如下載大文件。吞吐量沒有達到網絡的上限,主要可能受 3 個方面的影響:發送端出現了瓶頸、接收端出現了瓶頸、中間的網絡層出現了瓶頸。

                      發送端出現瓶頸一般的情況是 buffer 不夠大,因為發送的過程是,應用調用 syscall,將要發送的數據放到 buffer 里面,然后由系統負責發送出去。如果 buffer 滿了,那么應用會阻塞住(如果使用 block 的 API 的話),直到 buffer 可用了再繼續 write,生產者和消費者模式。

                    Debug 網絡質量的時候372

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

                      TCP 為了優化傳輸效率(注意這里的傳輸效率,并不是單純某一個 TCP 連接的傳輸效率,而是整體網絡的效率),會保護接收端,發送的數據不會超過接收端的 buffer 大小 (Flow control)。數據發送到接受端,也是和上面介紹的過程類似,kernel 先負責收好包放到 buffer 中,然后上層應用程序處理這個 buffer 中的內容,如果接收端的 buffer 過小,那么很容易出現瓶頸,即應用程序還沒來得及處理就被填滿了。那么如果數據繼續發過來,buffer 存不下,接收端只能丟棄。

                      保護網絡,發送的數據不會 overwhelming 網絡 (Congestion Control, 擁塞控制), 如果中間的網絡出現瓶頸,會導致長肥管道的吞吐不理想;

                      對于接收端的保護,在兩邊連接建立的時候,會協商好接收端的 buffer 大小 (receiver window size, rwnd), 并且在后續的發送中,接收端也會在每一個 ack 回包中報告自己剩余和接受的 window 大小。這樣,發送端在發送的時候會保證不會發送超過接收端 buffer 大小的數據。(意思是,發送端需要負責,receiver 沒有 ack 的總數,不會超過 receiver 的 buffer.)

                    Debug 網絡質量的時候1034

                      對于網絡的保護,原理也是維護一個 Window,叫做 Congestion window,擁塞窗口,cwnd, 這個窗口就是當前網絡的限制,發送端不會發送超過這個窗口的容量(沒有 ack 的總數不會超過 cwnd)。

                      怎么找到這個 cwnd 的值呢?

                      這個就是關鍵了,默認的算法是 cubic, 也有其他算法可以使用,比如 Google 的 BBR

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

                      發送的包沒有收到 ACK

                      cwnd 已經等于 rwnd 了

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

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

                      但實際造成第 1 點的情況并不一定是網絡吞吐瓶頸,而可能是以下幾種情況:

                      網絡達到了瓶頸

                      網絡質量問題丟包

                      中間網絡設備延遲了包的送達,導致發送端沒有在預期時間內收到 ACK

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

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

                      rwnd 查看方式

                      這個 window size 直接就在 TCP header 里面,抓下來就能看這個字段。

                    Debug 網絡質量的時候1706

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

                    Debug 網絡質量的時候1840

                      cwnd 查看方式

                      Congestion control 是發送端通過算法得到的一個動態變量,會試試調整,并不會體現在協議的傳輸數據中。所以要看這個,必須在發送端的機器上看。

                      在 Linux 中可以使用 ss -i 選項將 TCP 連接的參數都打印出來。

                    Debug 網絡質量的時候1970

                      這里展示的單位是 TCP MSS.即實際大小是 1460bytes * 10.

                      Wireshark 分析

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

                      首先,打開的方式如下:

                    Debug 網絡質量的時候2144

                      然后你會看到如下的圖。

                    Debug 網絡質量的時候2158

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

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

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

                      所以,你如果看到如上圖所示,那么說明你看反了,因為數據的 Sequence Number 并沒有增加過,說明幾乎沒有發送過數據,需要點擊 Switch Direction。

                    Debug 網絡質量的時候2478

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

                      這里面有 3 條線,含義如下:

                    Debug 網絡質量的時候2539

                      除此之外,另外還有兩種線:

                    Debug 網絡質量的時候2555

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

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

                      丟包

                    Debug 網絡質量的時候2771

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

                      吞吐受到接收 window size 限制

                    Debug 網絡質量的時候2842

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

                      吞吐受到網絡質量限制

                    Debug 網絡質量的時候2953

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

                    Debug 網絡質量的時候2997

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

                    聲明:本站稿件版權均屬千鋒教育所有,未經許可不得擅自轉載。

                    10年以上業內強師集結,手把手帶你蛻變精英

                    請您保持通訊暢通,專屬學習老師24小時內將與您1V1溝通

                    免費領取

                    今日已有369人領取成功

                    劉同學 138****2860 剛剛成功領取
                    王同學 131****2015 剛剛成功領取
                    張同學 133****4652 剛剛成功領取
                    李同學 135****8607 剛剛成功領取
                    楊同學 132****5667 剛剛成功領取
                    岳同學 134****6652 剛剛成功領取
                    梁同學 157****2950 剛剛成功領取
                    劉同學 189****1015 剛剛成功領取
                    張同學 155****4678 剛剛成功領取
                    鄒同學 139****2907 剛剛成功領取
                    董同學 138****2867 剛剛成功領取
                    周同學 136****3602 剛剛成功領取

                    推薦閱讀

                    最新文章

                    開班信息
                    北京校區
                    • 北京校區
                    • 大連校區
                    • 廣州校區
                    • 成都校區
                    • 杭州校區
                    • 長沙校區
                    • 合肥校區
                    • 南京校區
                    • 上海校區
                    • 深圳校區
                    • 武漢校區
                    • 鄭州校區
                    • 西安校區
                    • 青島校區
                    • 重慶校區
                    • 太原校區
                    • 沈陽校區

                    成·人免费午夜在线观看