深入分析Linux網(wǎng)絡(luò)丟包問(wèn)題
所謂丟包，是指在網(wǎng)絡(luò)數(shù)據(jù)的收發(fā)過(guò)程中，由于種種原因，數(shù)據(jù)包還沒(méi)傳輸?shù)綉?yīng)用程序中，就被丟棄了。這些被丟棄包的數(shù)量，除以總的傳輸包數(shù)，也就是我們常說(shuō)的丟包率。丟包率是網(wǎng)絡(luò)性能中最核心的指標(biāo)之一。丟包通常會(huì)帶來(lái)嚴(yán)重的性能下降，特別是對(duì) TCP 來(lái)說(shuō)，丟包通常意味著網(wǎng)絡(luò)擁塞和重傳，進(jìn)而還會(huì)導(dǎo)致網(wǎng)絡(luò)延遲增大、吞吐降低。
一、 哪里可能丟包
接下來(lái)，我就以最常用的反向代理服務(wù)器 Nginx 為例，帶你一起看看如何分析網(wǎng)絡(luò)丟包的問(wèn)題。執(zhí)行下面的 hping3 命令，進(jìn)一步驗(yàn)證 Nginx 是不是可以正常訪(fǎng)問(wèn)。這里我沒(méi)有使用 ping，是因?yàn)?ping 基于 ICMP 協(xié)議，而 Nginx 使用的是 TCP 協(xié)議。
#-c表示發(fā)送10個(gè)請(qǐng)求，-S表示使用TCPSYN，-p指定端口為80 hping3-c10-S-p80192.168.0.30 HPING192.168.0.30(eth0192.168.0.30):Sset,40headers+0databytes len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=3win=5120rtt=7.5ms len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=4win=5120rtt=7.4ms len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=5win=5120rtt=3.3ms len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=7win=5120rtt=3.0ms len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=6win=5120rtt=3027.2ms ---192.168.0.30hpingstatistic--- 10packetstransmitted,5packetsreceived,50%packetloss round-tripmin/avg/max=3.0/609.7/3027.2ms
從 hping3 的輸出中，我們可以發(fā)現(xiàn)，發(fā)送了 10 個(gè)請(qǐng)求包，卻只收到了 5 個(gè)回復(fù)，50%的包都丟了。再觀察每個(gè)請(qǐng)求的 RTT 可以發(fā)現(xiàn)，RTT 也有非常大的波動(dòng)變化，小的時(shí)候只有 3ms，而大的時(shí)候則有 3s。根據(jù)這些輸出，我們基本能判斷，已經(jīng)發(fā)生了丟包現(xiàn)象。可以猜測(cè)，3s 的 RTT ，很可能是因?yàn)閬G包后重傳導(dǎo)致的。
那到底是哪里發(fā)生了丟包呢？排查之前，我們可以回憶一下 Linux 的網(wǎng)絡(luò)收發(fā)流程，先從理論上分析，哪里有可能會(huì)發(fā)生丟包。你不妨拿出手邊的筆和紙，邊回憶邊在紙上梳理，思考清楚再繼續(xù)下面的內(nèi)容。在這里，為了幫你理解網(wǎng)絡(luò)丟包的原理，我畫(huà)了一張圖，你可以保存并打印出來(lái)使用
從圖中你可以看出，可能發(fā)生丟包的位置，實(shí)際上貫穿了整個(gè)網(wǎng)絡(luò)協(xié)議棧。換句話(huà)說(shuō)，全程都有丟包的可能。
在兩臺(tái) VM 連接之間，可能會(huì)發(fā)生傳輸失敗的錯(cuò)誤，比如網(wǎng)絡(luò)擁塞、線(xiàn)路錯(cuò)誤等；
在網(wǎng)卡收包后，環(huán)形緩沖區(qū)可能會(huì)因?yàn)橐绯龆鴣G包；
在鏈路層，可能會(huì)因?yàn)榫W(wǎng)絡(luò)幀校驗(yàn)失敗、QoS 等而丟包；
在 IP 層，可能會(huì)因?yàn)槁酚墒 ⒔M包大小超過(guò) MTU 等而丟包；
在傳輸層，可能會(huì)因?yàn)槎丝谖幢O(jiān)聽(tīng)、資源占用超過(guò)內(nèi)核限制等而丟包；
在套接字層，可能會(huì)因?yàn)樘捉幼志彌_區(qū)溢出而丟包；
在應(yīng)用層，可能會(huì)因?yàn)閼?yīng)用程序異常而丟包；
此外，如果配置了 iptables 規(guī)則，這些網(wǎng)絡(luò)包也可能因?yàn)?iptables 過(guò)濾規(guī)則而丟包
當(dāng)然，上面這些問(wèn)題，還有可能同時(shí)發(fā)生在通信的兩臺(tái)機(jī)器中。不過(guò)，由于我們沒(méi)對(duì) VM2做任何修改，并且 VM2 也只運(yùn)行了一個(gè)最簡(jiǎn)單的 hping3 命令，這兒不妨假設(shè)它是沒(méi)有問(wèn)題的。為了簡(jiǎn)化整個(gè)排查過(guò)程，我們還可以進(jìn)一步假設(shè)， VM1 的網(wǎng)絡(luò)和內(nèi)核配置也沒(méi)問(wèn)題。接下來(lái)，就可以從協(xié)議棧中，逐層排查丟包問(wèn)題。
二、 鏈路層
當(dāng)鏈路層由于緩沖區(qū)溢出等原因?qū)е戮W(wǎng)卡丟包時(shí)，Linux 會(huì)在網(wǎng)卡收發(fā)數(shù)據(jù)的統(tǒng)計(jì)信息中記錄下收發(fā)錯(cuò)誤的次數(shù)。可以通過(guò) ethtool 或者 netstat ，來(lái)查看網(wǎng)卡的丟包記錄。
netstat-i KernelInterfacetable IfaceMTURX-OKRX-ERRRX-DRPRX-OVRTX-OKTX-ERRTX-DRPTX-OVRFlg eth0100310008000BMRU lo6553600000000LRU
RX-OK、RX-ERR、RX-DRP、RX-OVR ，分別表示接收時(shí)的總包數(shù)、總錯(cuò)誤數(shù)、進(jìn)入 Ring Buffer 后因其他原因（如內(nèi)存不足）導(dǎo)致的丟包數(shù)以及 Ring Buffer 溢出導(dǎo)致的丟包數(shù)。
TX-OK、TX-ERR、TX-DRP、TX-OVR 也代表類(lèi)似的含義，只不過(guò)是指發(fā)送時(shí)對(duì)應(yīng)的各個(gè)指標(biāo)。
這里我們沒(méi)有發(fā)現(xiàn)任何錯(cuò)誤，說(shuō)明虛擬網(wǎng)卡沒(méi)有丟包。不過(guò)要注意，如果用 tc 等工具配置了 QoS，那么 tc 規(guī)則導(dǎo)致的丟包，就不會(huì)包含在網(wǎng)卡的統(tǒng)計(jì)信息中。所以接下來(lái)，我們還要檢查一下 eth0 上是否配置了 tc 規(guī)則，并查看有沒(méi)有丟包。添加 -s 選項(xiàng)，以輸出統(tǒng)計(jì)信息：
tc-sqdiscshowdeveth0 qdiscnetem800d:rootrefcnt2limit1000loss30% Sent432bytes8pkt(dropped4,overlimits0requeues0) backlog0b0prequeues0
可以看到， eth0 上配置了一個(gè)網(wǎng)絡(luò)模擬排隊(duì)規(guī)則（qdisc netem），并且配置了丟包率為 30%（loss 30%）。再看后面的統(tǒng)計(jì)信息，發(fā)送了 8 個(gè)包，但是丟了 4個(gè)。看來(lái)應(yīng)該就是這里導(dǎo)致 Nginx 回復(fù)的響應(yīng)包被 netem 模塊給丟了。
既然發(fā)現(xiàn)了問(wèn)題，解決方法也很簡(jiǎn)單，直接刪掉 netem 模塊就可以了。執(zhí)行下面的命令，刪除 tc 中的 netem 模塊：
tcqdiscdeldeveth0rootnetemloss30%
刪除后，重新執(zhí)行之前的 hping3 命令，看看現(xiàn)在還有沒(méi)有問(wèn)題：
hping3-c10-S-p80192.168.0.30 HPING192.168.0.30(eth0192.168.0.30):Sset,40headers+0databytes len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=0win=5120rtt=7.9ms len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=2win=5120rtt=1003.8ms len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=5win=5120rtt=7.6ms len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=6win=5120rtt=7.4ms len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=9win=5120rtt=3.0ms ---192.168.0.30hpingstatistic--- 10packetstransmitted,5packetsreceived,50%packetloss round-tripmin/avg/max=3.0/205.9/1003.8ms
不幸的是，從 hping3 的輸出中可以看到還是 50% 的丟包，RTT 的波動(dòng)也仍舊很大，從 3ms 到 1s。顯然，問(wèn)題還是沒(méi)解決，丟包還在繼續(xù)發(fā)生。不過(guò)，既然鏈路層已經(jīng)排查完了，我們就繼續(xù)向上層分析，看看網(wǎng)絡(luò)層和傳輸層有沒(méi)有問(wèn)題。
三、 網(wǎng)絡(luò)層和傳輸層
在網(wǎng)絡(luò)層和傳輸層中，引發(fā)丟包的因素非常多。不過(guò)，其實(shí)想確認(rèn)是否丟包，是非常簡(jiǎn)單的事，因?yàn)?Linux 已經(jīng)為我們提供了各個(gè)協(xié)議的收發(fā)匯總情況。執(zhí)行 netstat -s 命令，可以看到協(xié)議的收發(fā)匯總，以及錯(cuò)誤信息：
netstat-s #輸出 Ip: Forwarding:1//開(kāi)啟轉(zhuǎn)發(fā) 31totalpacketsreceived//總收包數(shù) 0forwarded//轉(zhuǎn)發(fā)包數(shù) 0incomingpacketsdiscarded//接收丟包數(shù) 25incomingpacketsdelivered//接收的數(shù)據(jù)包數(shù) 15requestssentout//發(fā)出的數(shù)據(jù)包數(shù) Icmp: 0ICMPmessagesreceived//收到的ICMP包數(shù) 0inputICMPmessagefailed//收到ICMP失敗數(shù) ICMPinputhistogram: 0ICMPmessagessent//ICMP發(fā)送數(shù) 0ICMPmessagesfailed//ICMP失敗數(shù) ICMPoutputhistogram: Tcp: 0activeconnectionopenings//主動(dòng)連接數(shù) 0passiveconnectionopenings//被動(dòng)連接數(shù) 11failedconnectionattempts//失敗連接嘗試數(shù) 0connectionresetsreceived//接收的連接重置數(shù) 0connectionsestablished//建立連接數(shù) 25segmentsreceived//已接收?qǐng)?bào)文數(shù) 21segmentssentout//已發(fā)送報(bào)文數(shù) 4segmentsretransmitted//重傳報(bào)文數(shù) 0badsegmentsreceived//錯(cuò)誤報(bào)文數(shù) 0resetssent//發(fā)出的連接重置數(shù) Udp: 0packetsreceived ... TcpExt: 11resetsreceivedforembryonicSYN_RECVsockets//半連接重置數(shù) 0packetheaderspredicted TCPTimeouts:7//超時(shí)數(shù) TCPSynRetrans:4//SYN重傳數(shù) ...
etstat 匯總了 IP、ICMP、TCP、UDP 等各種協(xié)議的收發(fā)統(tǒng)計(jì)信息。不過(guò)，我們的目的是排查丟包問(wèn)題，所以這里主要觀察的是錯(cuò)誤數(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 次超時(shí)（TCPTimeouts）
這個(gè)結(jié)果告訴我們，TCP 協(xié)議有多次超時(shí)和失敗重試，并且主要錯(cuò)誤是半連接重置。換句話(huà)說(shuō)，主要的失敗，都是三次握手失敗。不過(guò)，雖然在這兒看到了這么多失敗，但具體失敗的根源還是無(wú)法確定。所以，我們還需要繼續(xù)順著協(xié)議棧來(lái)分析。接下來(lái)的幾層又該如何分析呢？
四、 iptables
首先，除了網(wǎng)絡(luò)層和傳輸層的各種協(xié)議，iptables 和內(nèi)核的連接跟蹤機(jī)制也可能會(huì)導(dǎo)致丟包。所以，這也是發(fā)生丟包問(wèn)題時(shí)我們必須要排查的一個(gè)因素。
先來(lái)看看連接跟蹤，要確認(rèn)是不是連接跟蹤導(dǎo)致的問(wèn)題，只需要對(duì)比當(dāng)前的連接跟蹤數(shù)和最大連接跟蹤數(shù)即可。
#主機(jī)終端中查詢(xún)內(nèi)核配置 $sysctlnet.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_max=262144 $sysctlnet.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_count=182
可以看到，連接跟蹤數(shù)只有 182，而最大連接跟蹤數(shù)則是 262144。顯然，這里的丟包，不可能是連接跟蹤導(dǎo)致的。
接著，再來(lái)看 iptables。回顧一下 iptables 的原理，它基于 Netfilter 框架，通過(guò)一系列的規(guī)則，對(duì)網(wǎng)絡(luò)數(shù)據(jù)包進(jìn)行過(guò)濾（如防火墻）和修改（如 NAT）。這些 iptables 規(guī)則，統(tǒng)一管理在一系列的表中，包括 filter、nat、mangle（用于修改分組數(shù)據(jù)） 和 raw（用于原始數(shù)據(jù)包）等。而每張表又可以包括一系列的鏈，用于對(duì) iptables 規(guī)則進(jìn)行分組管理。
對(duì)于丟包問(wèn)題來(lái)說(shuō)，最大的可能就是被 filter 表中的規(guī)則給丟棄了。要弄清楚這一點(diǎn)，就需要我們確認(rèn)，那些目標(biāo)為 DROP 和 REJECT 等會(huì)棄包的規(guī)則，有沒(méi)有被執(zhí)行到。可以直接查詢(xún) DROP 和 REJECT 等規(guī)則的統(tǒng)計(jì)信息，看看是否為0。如果不是 0 ，再把相關(guān)的規(guī)則拎出來(lái)進(jìn)行分析。
iptables-tfilter-nvL #輸出 ChainINPUT(policyACCEPT25packets,1000bytes) pktsbytestargetprotoptinoutsourcedestination 6240DROPall--**0.0.0.0/00.0.0.0/0statisticmoderandomprobability0.29999999981 ChainFORWARD(policyACCEPT0packets,0bytes) pktsbytestargetprotoptinoutsourcedestination ChainOUTPUT(policyACCEPT15packets,660bytes) pktsbytestargetprotoptinoutsourcedestination 6264DROPall--**0.0.0.0/00.0.0.0/0statisticmoderandomprobability0.29999999981
從 iptables 的輸出中，你可以看到，兩條 DROP 規(guī)則的統(tǒng)計(jì)數(shù)值不是 0，它們分別在INPUT 和 OUTPUT 鏈中。這兩條規(guī)則實(shí)際上是一樣的，指的是使用 statistic 模塊，進(jìn)行隨機(jī) 30% 的丟包。0.0.0.0/0 表示匹配所有的源 IP 和目的 IP，也就是會(huì)對(duì)所有包都進(jìn)行隨機(jī) 30% 的丟包。看起來(lái)，這應(yīng)該就是導(dǎo)致部分丟包的“罪魁禍?zhǔn)住绷恕?/p>
執(zhí)行下面的兩條 iptables 命令，刪除這兩條 DROP 規(guī)則。
root@nginx:/#iptables-tfilter-DINPUT-mstatistic--moderandom--probability0.30-jDROP root@nginx:/#iptables-tfilter-DOUTPUT-mstatistic--moderandom--probability0.30-jDROP
再次執(zhí)行剛才的 hping3 命令，看看現(xiàn)在是否正常
hping3-c10-S-p80192.168.0.30 #輸出 HPING192.168.0.30(eth0192.168.0.30):Sset,40headers+0databytes len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=0win=5120rtt=11.9ms len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=1win=5120rtt=7.8ms ... len=44ip=192.168.0.30ttl=63DFid=0sport=80flags=SAseq=9win=5120rtt=15.0ms ---192.168.0.30hpingstatistic--- 10packetstransmitted,10packetsreceived,0%packetloss round-tripmin/avg/max=3.3/7.9/15.0ms
這次輸出你可以看到，現(xiàn)在已經(jīng)沒(méi)有丟包了，并且延遲的波動(dòng)變化也很小。看來(lái)，丟包問(wèn)題應(yīng)該已經(jīng)解決了。
不過(guò)，到目前為止，我們一直使用的 hping3 工具，只能驗(yàn)證案例 Nginx 的 80 端口處于正常監(jiān)聽(tīng)狀態(tài)，卻還沒(méi)有訪(fǎng)問(wèn) Nginx 的 HTTP 服務(wù)。所以，不要匆忙下結(jié)論結(jié)束這次優(yōu)化，我們還需要進(jìn)一步確認(rèn)，Nginx 能不能正常響應(yīng) HTTP 請(qǐng)求。我們繼續(xù)在終端二中，執(zhí)行如下的 curl 命令，檢查 Nginx 對(duì) HTTP 請(qǐng)求的響應(yīng)：
$curl--max-time3http://192.168.0.30 curl:(28)Operationtimedoutafter3000millisecondswith0bytesreceived
奇怪，hping3 的結(jié)果顯示Nginx 的 80 端口是正常狀態(tài)，為什么還是不能正常響應(yīng) HTTP 請(qǐng)求呢？別忘了，我們還有個(gè)大殺器——抓包操作。看來(lái)有必要抓包看看了。
五、 tcpdump
執(zhí)行下面的 tcpdump 命令，抓取 80 端口的包
tcpdump-ieth0-nnport80 #輸出 tcpdump:verboseoutputsuppressed,use-vor-vvforfullprotocoldecode listeningoneth0,link-typeEN10MB(Ethernet),capturesize262144bytes
然后，切換到終端二中，再次執(zhí)行前面的 curl 命令：
curl--max-time3http://192.168.0.30 curl:(28)Operationtimedoutafter3000millisecondswith0bytesreceived
等到 curl 命令結(jié)束后，再次切換回終端一，查看 tcpdump 的輸出：
1400.589235IP10.255.255.5.39058>172.17.0.2.80:Flags[S],seq332257715,win29200,options[mss1418,sackOK,TSval486800541ecr0,nop,wscale7],length0
1400.589277IP172.17.0.2.80>10.255.255.5.39058:Flags[S.],seq1630206251,ack332257716,win4880,options[mss256,sackOK,TSval2509376001ecr486800541,nop,wscale7],length0
1400.589894IP10.255.255.5.39058>172.17.0.2.80:Flags[.],ack1,win229,options[nop,nop,TSval486800541ecr2509376001],length0
1403.589352IP10.255.255.5.39058>172.17.0.2.80:Flags[F.],seq76,ack1,win229,options[nop,nop,TSval486803541ecr2509376001],length0
1403.589417IP172.17.0.2.80>10.255.255.5.39058:Flags[.],ack1,win40,options[nop,nop,TSval2509379001ecr486800541,nop,nop,sack1{76:77}],length0
從 tcpdump 的輸出中，我們就可以看到：
前三個(gè)包是正常的 TCP 三次握手，這沒(méi)問(wèn)題；
但第四個(gè)包卻是在 3 秒以后了，并且還是客戶(hù)端（VM2）發(fā)送過(guò)來(lái)的 FIN 包，說(shuō)明客戶(hù)端的連接關(guān)閉了
根據(jù) curl 設(shè)置的 3 秒超時(shí)選項(xiàng)，你應(yīng)該能猜到，這是因?yàn)?curl 命令超時(shí)后退出了。用 Wireshark 的 Flow Graph 來(lái)表示，
你可以更清楚地看到上面這個(gè)問(wèn)題：
這里比較奇怪的是，我們并沒(méi)有抓取到 curl 發(fā)來(lái)的 HTTP GET 請(qǐng)求。那究竟是網(wǎng)卡丟包了，還是客戶(hù)端就沒(méi)發(fā)過(guò)來(lái)呢？
可以重新執(zhí)行 netstat -i 命令，確認(rèn)一下網(wǎng)卡有沒(méi)有丟包問(wèn)題：
netstat-i KernelInterfacetable IfaceMTURX-OKRX-ERRRX-DRPRX-OVRTX-OKTX-ERRTX-DRPTX-OVRFlg eth01001570344094000BMRU lo6553600000000LRU
從 netstat 的輸出中，你可以看到，接收丟包數(shù)（RX-DRP）是 344，果然是在網(wǎng)卡接收時(shí)丟包了。不過(guò)問(wèn)題也來(lái)了，為什么剛才用 hping3 時(shí)不丟包，現(xiàn)在換成 GET 就收不到了呢？還是那句話(huà)，遇到搞不懂的現(xiàn)象，不妨先去查查工具和方法的原理。我們可以對(duì)比一下這兩個(gè)工具：
hping3 實(shí)際上只發(fā)送了 SYN 包；
curl 在發(fā)送 SYN 包后，還會(huì)發(fā)送 HTTP GET 請(qǐng)求。HTTP GET本質(zhì)上也是一個(gè) TCP 包，但跟 SYN 包相比，它還攜帶了 HTTP GET 的數(shù)據(jù)。
通過(guò)這個(gè)對(duì)比，你應(yīng)該想到了，這可能是 MTU 配置錯(cuò)誤導(dǎo)致的。為什么呢？
其實(shí)，仔細(xì)觀察上面 netstat 的輸出界面，第二列正是每個(gè)網(wǎng)卡的 MTU 值。eth0 的 MTU只有 100，而以太網(wǎng)的 MTU 默認(rèn)值是 1500，這個(gè) 100 就顯得太小了。當(dāng)然，MTU 問(wèn)題是很好解決的，把它改成 1500 就可以了。
ifconfigeth0mtu1500
修改完成后，再切換到終端二中，再次執(zhí)行 curl 命令，確認(rèn)問(wèn)題是否真的解決了：
curl--max-time3http://192.168.0.30/ #輸出 ...Thankyouforusingnginx.