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

帶寬是什么?

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

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

# 

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包的大小超過網卡規定的大小，并且網卡不允許分片，那么則會產生丟包。

審核編輯：劉清