如何排查網絡丟包問題

要明白一個知識點，首先要快速的對這個知識點建立一個概念模型，有了概念模型之後，再在這個模型上不斷的去填充一些細節的東西，會有助於我們把握知識的本質。

帶寬是什麼?

帶寬是網絡被髮送的能力，它會受到網卡複製網絡包到內核緩衝區或者搬運內核緩衝區的網絡包到網卡緩衝區能力的影響，也會受到接收窗口或擁塞窗口的影響，也就是說如果對端接收能力變小，那麼帶寬是不能提升上去的。

當整個網絡的鏈路變長以後，網絡的情況是很複雜的。網絡包有可能會經過多個路由器或者不同運營商之間的線路去進行數據交換，而不同代理商之間的網絡流量是極其龐大的，它會導致你的網絡包產生丟包或者重發的狀況，針對於這種情況，平時在部署服務節點時候，如果有能力在設計鏈路的時候最好能夠避免這種不同代理商之間的網絡交換，優化整個網絡傳輸的鏈路選擇能力，這也是 cdn 提供全局加速的一個原理。

cdn 原理是能夠在世界各地部署很多個節點，然後每個節點之間的一個鏈路選擇是通過服務運營商精心編排過的，它能夠保證你的整個網絡的鏈路是經過優化的，能夠讓你的網絡包更少的產生丟包或者是重發的狀況。

網絡包的收發過程

我們得明白一個網絡包是如何經過應用程序的,

一般應用程序發起一個網絡請求，這個網絡請求的數據會寫到內核的套接字緩衝區當中，然後內核會對這個套接字緩衝區的數據去加上 tcp 頭或 udp 頭，然後又經由 ip 層，再加上一個 ip 頭，中間會經過防火牆的一系列規則對這個網絡包進行過濾，看是丟棄還是繼續往網卡上面去發送，最終到達鏈路層之後，這個網絡包會經由鏈路層去發到網卡上的環形緩衝區上，最後由網卡發送到整個網絡當中，其中每一環都是有可能會發生丟包的。

理解了網絡包的收發過程，建立起了這樣一種概念模型之後，會有助於我們對丟包問題的排查。

如何去衡量網絡情況的好壞

對應用服務進行監控的時候，如何去衡量網絡情況的好壞，一般也用來衡量硬件資源的好壞。

一個通用套路，一般我們會先看一下，在系統層面上網絡指標的一個表現，再看下具體是哪個進程造成這種表現的異常，再去定位到問題代碼。

具體對網絡而言，如何從系統的層面或者是我們要使用哪些工具去看這個網絡的好壞？

從系統層面看網絡有幾個重要的指標，MBS 代表網卡每秒發送多少或者是接收多少個 M 字節，Mbps 是每秒多少 M 比特位。通常說的帶寬的單位就是 Mbps，一般 100M 帶寬的話換算成 MBS 等於 Mbps 除以 8。

平時選擇服務器節點的時候，除了帶寬，還有 pps 就是每秒發送、接收包的數量，它也是有限制的。

當我們在遇到網絡性能問題的時候，首先可以去觀察你的機器節點上這兩個指標是否是已經達到了一個瓶頸的狀態。如果帶寬只有 100Mbps，然後通過工具查看機器上面的節點帶寬，馬上就要超過這個值的時候，很有可能這個時候帶寬已經成爲瓶頸，可能要對機器的配額去進行升級。

sar

# 使用sar每一秒統計一次網絡接口的活動狀況，連續顯示5次

sar -n DEV 1 5

• IFACE 是網卡接口名稱

• rxpck/s、txpck/s 每秒收或發的數據包數量

• rxkB/s、txkB/s 每秒收或發的字節數，以 kB/s 爲單位

• rxcmp/s、txcmp/s 每秒收或發的壓縮過的數據包數量

• rxmcst/s 每秒收到的多播 (多播是一點對多點的通信) 數據包

看完了整個系統層面的網絡情況，可以再精細點的從進程的角度去看這個問題。

iftop

# https://www.tecmint.com/iftop-linux-network-bandwidth-monitoring-tool/

yum  -y install libpcap libpcap-devel ncurses ncurses-devel

yum install epel-release

yum install -y iftop

iftop -P

能夠列出這個系統裏面每一條鏈接的一個 Mbps，能夠找出哪個 ip 消耗流量最多。更多的時候其實不是系統網絡達到瓶頸，而是進程處理網絡包的能力跟不上。

nethogs

yum install nethogs

# 查看進程佔用帶寬的情況
nethogs ens33

列出每個進程的收發流量的數據，找出哪個進程是最消耗流量的，能夠更方便的讓我們去定位哪個進程出的問題。

go trace 這個工具能夠去分析出網絡調度帶來的延遲問題，其實也能夠從側面去反饋出你的程序在某一塊代碼上面可能是在進行頻繁的網絡調度，有可能是進行頻繁調度之後，比較消耗帶寬，從而可能間接的反映出延遲會略有提高，go trace 也能夠從讓我們在網絡性能問題當中能夠比較間接去找出一塊問題的代碼。

網絡性能當中比較重要的一個點就是如何查找你的一個丟包問題，對於上面的圖 [網絡包傳輸過程]，從上到下依次分析，先看應用層，通過 listen 這個方法去監聽套接字的時候，在三次握手的時候，會有兩個隊列，首先服務器接收到客戶端的 syn 包的時候，會創建一個半連接隊列 ，這個半連接隊列會將那些還沒有完成三次握手但是卻發送了一個 syn 包的這種連接放到裏面，會回覆客戶端一個 syn+ack，客戶端收到了這個 ack 和 syn 包之後，會回覆給服務端一個 ack，這個時候內核就會將這個連接放到全連接隊列，當服務器調用 accept 方法的時候，會將這條連接從全連接隊列裏取出來，所以這個時候涉及了兩個隊列，如果這兩個隊列滿了的話，就會可能會產生丟包的行爲。

首先來看一下半連接隊列，它是由內核參數決定的，這個也是可以調整的。通過三次握手，才能夠去建立連接，但是由於這種隊列的機制很有可能在併發量大的時候，會產生隊列滿了，然後丟包的行爲，所以內核提供了一個 tcp_syncookies 參數，它能夠去啓用 tcp_syncookies 這個機制，當半連接隊列溢出的時候，它能夠讓內核不直接去丟棄這個新包，而是回覆帶有 syncookie 的包，這個時候客戶端再去向服務器進行請求的時候，它會去驗證這個 syncookie，這樣能夠防止半連接隊列溢出的時候造成服務不可用的一個情況。

如何去確定是由於半連接隊列溢出導致的丟包?

通過 dmesg 去日誌裏面去搜尋 tcp drop，是能夠發現丟包的情況，dmesg 是一個內核的日誌記錄，我們能夠從裏面去找出一些內核的行爲，

dmesg|grep "TCP: drop open erquest form"

然後看下全連接隊列該怎麼看，通過 ss 命令的話，能夠去看到你的服務在 listen 的時候，全連接隊列的大小

ss -lnt

# -l 顯示正在監聽 
# -n 不解析服務名稱
# -t 只顯示 tcp socket

對於你的那個監聽服務而言，它的一個 Send-Q，就是代表當前全連接隊列長度，也就是當前已完成三次握手並等待服務端 accept() 的 TCP 連接。Recv-Q 是指當前全連接隊列的大小，上面的輸出結果說明監聽 9000 端口的 TCP 服務，最大全連接長度爲 128。Recv-Q 一般都是爲 0，如果存在一種大於 0 的情況並且會持續一個較長時間的話，就說明你的服務處理連接的能力比較慢了，會導致全連接隊列過滿或者丟棄，這個時候應該會加快你的服務處理連接的能力。

ss 命令對於狀態爲 ESTAB 的連接，它看的不是你這個監聽服務，而是去看一條已經建立好的連接相關指標，Recv-Q 是代表收到但未被應用程序讀取的一個字節數，Send-Q 已發送但未收到確認的字節數，通過這兩個指標，能夠去看到是應用程序對一個數據的處理能力慢，還是說是客戶端對接收的數據處理的比較慢的情況，一般這兩個值也都是爲 0，如果有其中一個不爲 0 ，你可能要去排查一下是客戶端的問題還是服務器的問題。

當全連接隊列滿了之後，內核默認會將包丟棄，但是也已可指定內核的一個其他行爲，如果是將 tcp_abort_on_overflow 這個值設爲 1 的話，那會直接發一個 reset 的包給客戶端，直接將這個連接斷開掉，表示廢掉這個握手過程和這個連接。

經過應用層之後，網絡包會到達到傳輸層，傳輸層會有防火牆的存在，如果防火牆開啓的話，那和防火牆有關的連接跟蹤表：nf_conntrack 這個是 linux 爲每個經過內核網絡棧的數據包，會生成一個連接的記錄項，當服務器處理過多時，這個連接記錄項所在的連接跟蹤表就會被打滿，然後服務器就會丟棄新建連接的數據包，所以有時候丟包有可能是防火牆的連接跟蹤表設計的太小了。

那如何去看連接跟蹤表的大小呢

# 查看nf_conntrack表最大連接數

cat /proc/sys/net/netfilter/nf_conntrack_max

# 查看nf_conntrack表當前連接數

cat /proc/sys/net/netfilter/nf_conntrack_count

通過這個文件看連接跟蹤表的一個最大連接數 nf_conntrack_max，所以在丟包的時候，可以對這一部分去進行排查，看下連接跟蹤表是不是被打滿了。

網絡包經過傳輸層之後，再來看網絡層和物理層，提到網絡層和物理層，就要看網卡了，通過 netstat 命令，能夠去看整個機器上面網卡的丟包和收包的情況。

RX-DRP 這個指標數據，如果它大於 0，說明這個網卡是有丟包情況，這裏記錄的是從開機到目前爲止的數據情況，所以在分析的時候，隔一定的時間去看這個指標是否有上漲。

RX-OVR 指標說明這個網卡的環形緩衝區滿了之後產生的丟棄行爲。

通過 netstat 能夠分析網卡丟包的情況，

# netstat可以統計網路丟包以及環形緩衝區溢出

netstat -i

netstat 還能夠統計網絡協議層的丟包情況，

MTU

應用層的網絡包通過網絡層的時候會根據數據包的大小去進行分包發送。

當 tcp 數據包的大小發送網絡層之後，網絡層發現這個包會大於它的 mtu 值，這個數據包會進行一個分包的操作。在進行網卡設置的時候，會設置爲你的傳輸層包，如果大於了 mtu 這個值，那就可以直接將這個網絡包丟棄，這也是在現實生活中經常會碰到的一個丟包問題。

所以你在檢查鏈路的時候，通常鏈路長了可能不太好排查，鏈路短一點，可能會很容易看到整條鏈路當中 mtu 的情況，看一下是不是每條鏈路上對應的每個網卡的 mtu 指標是不一樣的，如果不一樣的話，有可能會造成你的丟包問題，因爲一個包的轉發跟網絡上面設置的 mtu 值大小有關係，比如設置爲大於 mtu 之後會把這個包給丟棄掉。如果發送的 mtu 包的大小超過網卡規定的大小，並且網卡不允許分片，那麼則會產生丟包。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/k0s0kYSpCdF8SHBotuWCrg