所謂丟包，是指在網(wǎng)絡(luò)數(shù)據(jù)的收發(fā)過程中，由于種種原因，數(shù)據(jù)包還沒傳輸?shù)綉?yīng)用程序中，就被丟棄了。這些被丟棄包的數(shù)量，除以總的傳輸包數(shù)，也就是我們常說的丟包率。丟包率是網(wǎng)絡(luò)性能中最核心的指標之一。丟包通常會帶來嚴重的性能下降，特別是對 TCP 來說，丟包通常意味著網(wǎng)絡(luò)擁塞和重傳，進而還會導(dǎo)致網(wǎng)絡(luò)延遲增大、吞吐降低。

一、 哪里可能丟包

接下來，我就以最常用的反向代理服務(wù)器 Nginx 為例，帶你一起看看如何分析網(wǎng)絡(luò)丟包的問題。執(zhí)行下面的 hping3 命令，進一步驗證 Nginx 是不是可以正常訪問。這里我沒有使用 ping，是因為 ping 基于 ICMP 協(xié)議，而 Nginx 使用的是 TCP 協(xié)議。

從 hping3 的輸出中，我們可以發(fā)現(xiàn)，發(fā)送了 10 個請求包，卻只收到了 5 個回復(fù)，50%的包都丟了。再觀察每個請求的 RTT 可以發(fā)現(xiàn)，RTT 也有非常大的波動變化，小的時候只有 3ms，而大的時候則有 3s。根據(jù)這些輸出，我們基本能判斷，已經(jīng)發(fā)生了丟包現(xiàn)象。可以猜測，3s 的 RTT ，很可能是因為丟包后重傳導(dǎo)致的。

那到底是哪里發(fā)生了丟包呢？排查之前，我們可以回憶一下 Linux 的網(wǎng)絡(luò)收發(fā)流程，先從理論上分析，哪里有可能會發(fā)生丟包。你不妨拿出手邊的筆和紙，邊回憶邊在紙上梳理，思考清楚再繼續(xù)下面的內(nèi)容。在這里，為了幫你理解網(wǎng)絡(luò)丟包的原理，我畫了一張圖，你可以保存并打印出來使用

從圖中你可以看出，可能發(fā)生丟包的位置，實際上貫穿了整個網(wǎng)絡(luò)協(xié)議棧。換句話說，全程都有丟包的可能。

• 在兩臺 VM 連接之間，可能會發(fā)生傳輸失敗的錯誤，比如網(wǎng)絡(luò)擁塞、線路錯誤等；
• 在網(wǎng)卡收包后，環(huán)形緩沖區(qū)可能會因為溢出而丟包；
• 在鏈路層，可能會因為網(wǎng)絡(luò)幀校驗失敗、QoS 等而丟包；
• 在 IP 層，可能會因為路由失敗、組包大小超過 MTU 等而丟包；
• 在傳輸層，可能會因為端口未監(jiān)聽、資源占用超過內(nèi)核限制等而丟包；
• 在套接字層，可能會因為套接字緩沖區(qū)溢出而丟包；
• 在應(yīng)用層，可能會因為應(yīng)用程序異常而丟包；
• 此外，如果配置了 iptables 規(guī)則，這些網(wǎng)絡(luò)包也可能因為 iptables 過濾規(guī)則而丟包

當(dāng)然，上面這些問題，還有可能同時發(fā)生在通信的兩臺機器中。不過，由于我們沒對 VM2做任何修改，并且 VM2 也只運行了一個最簡單的 hping3 命令，這兒不妨假設(shè)它是沒有問題的。為了簡化整個排查過程，我們還可以進一步假設(shè)， VM1 的網(wǎng)絡(luò)和內(nèi)核配置也沒問題。接下來，就可以從協(xié)議棧中，逐層排查丟包問題。

二、 鏈路層

當(dāng)鏈路層由于緩沖區(qū)溢出等原因?qū)е戮W(wǎng)卡丟包時，Linux 會在網(wǎng)卡收發(fā)數(shù)據(jù)的統(tǒng)計信息中記錄下收發(fā)錯誤的次數(shù)。可以通過 ethtool 或者 netstat ，來查看網(wǎng)卡的丟包記錄。

RX-OK、RX-ERR、RX-DRP、RX-OVR ，分別表示接收時的總包數(shù)、總錯誤數(shù)、進入 Ring Buffer 后因其他原因（如內(nèi)存不足）導(dǎo)致的丟包數(shù)以及 Ring Buffer 溢出導(dǎo)致的丟包數(shù)。

TX-OK、TX-ERR、TX-DRP、TX-OVR 也代表類似的含義，只不過是指發(fā)送時對應(yīng)的各個指標。

這里我們沒有發(fā)現(xiàn)任何錯誤，說明虛擬網(wǎng)卡沒有丟包。不過要注意，如果用 tc 等工具配置了 QoS，那么 tc 規(guī)則導(dǎo)致的丟包，就不會包含在網(wǎng)卡的統(tǒng)計信息中。所以接下來，我們還要檢查一下 eth0 上是否配置了 tc 規(guī)則，并查看有沒有丟包。添加 -s 選項，以輸出統(tǒng)計信息：

可以看到， eth0 上配置了一個網(wǎng)絡(luò)模擬排隊規(guī)則（qdisc netem），并且配置了丟包率為 30%（loss 30%）。再看后面的統(tǒng)計信息，發(fā)送了 8 個包，但是丟了 4個?？磥響?yīng)該就是這里導(dǎo)致 Nginx 回復(fù)的響應(yīng)包被 netem 模塊給丟了。

既然發(fā)現(xiàn)了問題，解決方法也很簡單，直接刪掉 netem 模塊就可以了。執(zhí)行下面的命令，刪除 tc 中的 netem 模塊：

刪除后，重新執(zhí)行之前的 hping3 命令，看看現(xiàn)在還有沒有問題：

不幸的是，從 hping3 的輸出中可以看到還是 50% 的丟包，RTT 的波動也仍舊很大，從 3ms 到 1s。顯然，問題還是沒解決，丟包還在繼續(xù)發(fā)生。不過，既然鏈路層已經(jīng)排查完了，我們就繼續(xù)向上層分析，看看網(wǎng)絡(luò)層和傳輸層有沒有問題。

三、 網(wǎng)絡(luò)層和傳輸層

在網(wǎng)絡(luò)層和傳輸層中，引發(fā)丟包的因素非常多。不過，其實想確認是否丟包，是非常簡單的事，因為 Linux 已經(jīng)為我們提供了各個協(xié)議的收發(fā)匯總情況。執(zhí)行 netstat -s 命令，可以看到協(xié)議的收發(fā)匯總，以及錯誤信息：

etstat 匯總了 IP、ICMP、TCP、UDP 等各種協(xié)議的收發(fā)統(tǒng)計信息。不過，我們的目的是排查丟包問題，所以這里主要觀察的是錯誤數(shù)、丟包數(shù)以及重傳數(shù)?？梢钥吹?，只有 TCP 協(xié)議發(fā)生了丟包和重傳，分別是：

• 11 次連接失敗重試（11 failed connection attempts）
• 4 次重傳（4 segments retransmitted）
• 11 次半連接重置（11 resets received for embryonic SYN_RECV sockets）
• 4 次 SYN 重傳（TCPSynRetrans）
• 7 次超時（TCPTimeouts）

這個結(jié)果告訴我們，TCP 協(xié)議有多次超時和失敗重試，并且主要錯誤是半連接重置。換句話說，主要的失敗，都是三次握手失敗。不過，雖然在這兒看到了這么多失敗，但具體失敗的根源還是無法確定。所以，我們還需要繼續(xù)順著協(xié)議棧來分析。接下來的幾層又該如何分析呢？

四、 iptables

首先，除了網(wǎng)絡(luò)層和傳輸層的各種協(xié)議，iptables 和內(nèi)核的連接跟蹤機制也可能會導(dǎo)致丟包。所以，這也是發(fā)生丟包問題時我們必須要排查的一個因素。

先來看看連接跟蹤，要確認是不是連接跟蹤導(dǎo)致的問題，只需要對比當(dāng)前的連接跟蹤數(shù)和最大連接跟蹤數(shù)即可。

可以看到，連接跟蹤數(shù)只有 182，而最大連接跟蹤數(shù)則是 262144。顯然，這里的丟包，不可能是連接跟蹤導(dǎo)致的。

接著，再來看 iptables。回顧一下 iptables 的原理，它基于 Netfilter 框架，通過一系列的規(guī)則，對網(wǎng)絡(luò)數(shù)據(jù)包進行過濾（如防火墻）和修改（如 NAT）。這些 iptables 規(guī)則，統(tǒng)一管理在一系列的表中，包括 filter、nat、mangle（用于修改分組數(shù)據(jù)） 和 raw（用于原始數(shù)據(jù)包）等。而每張表又可以包括一系列的鏈，用于對 iptables 規(guī)則進行分組管理。

對于丟包問題來說，最大的可能就是被 filter 表中的規(guī)則給丟棄了。要弄清楚這一點，就需要我們確認，那些目標為 DROP 和 REJECT 等會棄包的規(guī)則，有沒有被執(zhí)行到?？梢灾苯硬樵?DROP 和 REJECT 等規(guī)則的統(tǒng)計信息，看看是否為0。如果不是 0 ，再把相關(guān)的規(guī)則拎出來進行分析。

從 iptables 的輸出中，你可以看到，兩條 DROP 規(guī)則的統(tǒng)計數(shù)值不是 0，它們分別在INPUT 和 OUTPUT 鏈中。這兩條規(guī)則實際上是一樣的，指的是使用 statistic 模塊，進行隨機 30% 的丟包。0.0.0.0/0 表示匹配所有的源 IP 和目的 IP，也就是會對所有包都進行隨機 30% 的丟包?？雌饋恚@應(yīng)該就是導(dǎo)致部分丟包的“罪魁禍首”了。

執(zhí)行下面的兩條 iptables 命令，刪除這兩條 DROP 規(guī)則。

再次執(zhí)行剛才的 hping3 命令，看看現(xiàn)在是否正常

這次輸出你可以看到，現(xiàn)在已經(jīng)沒有丟包了，并且延遲的波動變化也很小?？磥?，丟包問題應(yīng)該已經(jīng)解決了。

不過，到目前為止，我們一直使用的 hping3 工具，只能驗證案例 Nginx 的 80 端口處于正常監(jiān)聽狀態(tài)，卻還沒有訪問 Nginx 的 HTTP 服務(wù)。所以，不要匆忙下結(jié)論結(jié)束這次優(yōu)化，我們還需要進一步確認，Nginx 能不能正常響應(yīng) HTTP 請求。我們繼續(xù)在終端二中，執(zhí)行如下的 curl 命令，檢查 Nginx 對 HTTP 請求的響應(yīng)：

奇怪，hping3 的結(jié)果顯示Nginx 的 80 端口是正常狀態(tài)，為什么還是不能正常響應(yīng) HTTP 請求呢？別忘了，我們還有個大殺器——抓包操作。看來有必要抓包看看了。

五、 tcpdump

執(zhí)行下面的 tcpdump 命令，抓取 80 端口的包

然后，切換到終端二中，再次執(zhí)行前面的 curl 命令：

等到 curl 命令結(jié)束后，再次切換回終端一，查看 tcpdump 的輸出：

從 tcpdump 的輸出中，我們就可以看到：

• 前三個包是正常的 TCP 三次握手，這沒問題；
• 但第四個包卻是在 3 秒以后了，并且還是客戶端（VM2）發(fā)送過來的 FIN 包，說明客戶端的連接關(guān)閉了

根據(jù) curl 設(shè)置的 3 秒超時選項，你應(yīng)該能猜到，這是因為 curl 命令超時后退出了。用 Wireshark 的 Flow Graph 來表示，

你可以更清楚地看到上面這個問題：

這里比較奇怪的是，我們并沒有抓取到 curl 發(fā)來的 HTTP GET 請求。那究竟是網(wǎng)卡丟包了，還是客戶端就沒發(fā)過來呢？

可以重新執(zhí)行 netstat -i 命令，確認一下網(wǎng)卡有沒有丟包問題：

從 netstat 的輸出中，你可以看到，接收丟包數(shù)（RX-DRP）是 344，果然是在網(wǎng)卡接收時丟包了。不過問題也來了，為什么剛才用 hping3 時不丟包，現(xiàn)在換成 GET 就收不到了呢？還是那句話，遇到搞不懂的現(xiàn)象，不妨先去查查工具和方法的原理。我們可以對比一下這兩個工具：

• hping3 實際上只發(fā)送了 SYN 包；
• curl 在發(fā)送 SYN 包后，還會發(fā)送 HTTP GET 請求。HTTP GET本質(zhì)上也是一個 TCP 包，但跟 SYN 包相比，它還攜帶了 HTTP GET 的數(shù)據(jù)。

通過這個對比，你應(yīng)該想到了，這可能是 MTU 配置錯誤導(dǎo)致的。為什么呢？

其實，仔細觀察上面 netstat 的輸出界面，第二列正是每個網(wǎng)卡的 MTU 值。eth0 的 MTU只有 100，而以太網(wǎng)的 MTU 默認值是 1500，這個 100 就顯得太小了。當(dāng)然，MTU 問題是很好解決的，把它改成 1500 就可以了。

修改完成后，再切換到終端二中，再次執(zhí)行 curl 命令，確認問題是否真的解決了：

非常不容易呀，這次終于看到了熟悉的 Nginx 響應(yīng)，說明丟包的問題終于徹底解決了。