最近工作中遇到某個(gè)服務(wù)器應(yīng)用程序 UDP 丟包，在排查過(guò)程中查閱了很多資料，總結(jié)出來(lái)這篇文章，供更多人參考。

在開始之前，我們先用一張圖解釋 linux 系統(tǒng)接收網(wǎng)絡(luò)報(bào)文的過(guò)程。

1. 首先網(wǎng)絡(luò)報(bào)文通過(guò)物理網(wǎng)線發(fā)送到網(wǎng)卡
2. 網(wǎng)絡(luò)驅(qū)動(dòng)程序會(huì)把網(wǎng)絡(luò)中的報(bào)文讀出來(lái)放到 ring buffer 中，這個(gè)過(guò)程使用 DMA（Direct Memory Access），不需要 CPU 參與
3. 內(nèi)核從 ring buffer 中讀取報(bào)文進(jìn)行處理，執(zhí)行 IP 和 TCP/UDP 層的邏輯，最后把報(bào)文放到應(yīng)用程序的 socket buffer 中
4. 應(yīng)用程序從 socket buffer 中讀取報(bào)文進(jìn)行處理

在接收 UDP 報(bào)文的過(guò)程中，圖中任何一個(gè)過(guò)程都可能會(huì)主動(dòng)或者被動(dòng)地把報(bào)文丟棄，因此丟包可能發(fā)生在網(wǎng)卡和驅(qū)動(dòng)，也可能發(fā)生在系統(tǒng)和應(yīng)用。

之所以沒(méi)有分析發(fā)送數(shù)據(jù)流程，一是因?yàn)榘l(fā)送流程和接收類似，只是方向相反；另外發(fā)送流程報(bào)文丟失的概率比接收小，只有在應(yīng)用程序發(fā)送的報(bào)文速率大于內(nèi)核和網(wǎng)卡處理速率時(shí)才會(huì)發(fā)生。

本篇文章假定機(jī)器只有一個(gè)名字為 eth0 的 interface，如果有多個(gè) interface 或者 interface 的名字不是 eth0，請(qǐng)按照實(shí)際情況進(jìn)行分析。

NOTE：文中出現(xiàn)的 RX（receive） 表示接收?qǐng)?bào)文，TX（transmit） 表示發(fā)送報(bào)文。

確認(rèn)有 UDP 丟包發(fā)生

要查看網(wǎng)卡是否有丟包，可以使用 ethtool -S eth0 查看，在輸出中查找 bad 或者 drop 對(duì)應(yīng)的字段是否有數(shù)據(jù)，在正常情況下，這些字段對(duì)應(yīng)的數(shù)字應(yīng)該都是 0。如果看到對(duì)應(yīng)的數(shù)字在不斷增長(zhǎng)，就說(shuō)明網(wǎng)卡有丟包。

另外一個(gè)查看網(wǎng)卡丟包數(shù)據(jù)的命令是 ifconfig，它的輸出中會(huì)有 RX(receive 接收?qǐng)?bào)文)和 TX（transmit 發(fā)送報(bào)文）的統(tǒng)計(jì)數(shù)據(jù)：

~# ifconfig eth0
...
        RX packets 3553389376  bytes 2599862532475 (2.3 TiB)
        RX errors 0  dropped 1353  overruns 0  frame 0
        TX packets 3479495131  bytes 3205366800850 (2.9 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
...

此外，linux 系統(tǒng)也提供了各個(gè)網(wǎng)絡(luò)協(xié)議的丟包信息，可以使用 netstat -s 命令查看，加上 --udp 可以只看 UDP 相關(guān)的報(bào)文數(shù)據(jù)：

[root@holodesk02 GOD]# netstat -s -u
IcmpMsg:
    InType0: 3
    InType3: 1719356
    InType8: 13
    InType11: 59
    OutType0: 13
    OutType3: 1737641
    OutType8: 10
    OutType11: 263
Udp:
    517488890 packets received
    2487375 packets to unknown port received.
    47533568 packet receive errors
    147264581 packets sent
    12851135 receive buffer errors
    0 send buffer errors
UdpLite:
IpExt:
    OutMcastPkts: 696
    InBcastPkts: 2373968
    InOctets: 4954097451540
    OutOctets: 5538322535160
    OutMcastOctets: 79632
    InBcastOctets: 934783053
    InNoECTPkts: 5584838675

對(duì)于上面的輸出，關(guān)注下面的信息來(lái)查看 UDP 丟包的情況：

• packet receive errors 不為空，并且在一直增長(zhǎng)說(shuō)明系統(tǒng)有 UDP 丟包
• packets to unknown port received 表示系統(tǒng)接收到的 UDP 報(bào)文所在的目標(biāo)端口沒(méi)有應(yīng)用在監(jiān)聽(tīng)，一般是服務(wù)沒(méi)有啟動(dòng)導(dǎo)致的，并不會(huì)造成嚴(yán)重的問(wèn)題
• receive buffer errors 表示因?yàn)?UDP 的接收緩存太小導(dǎo)致丟包的數(shù)量

NOTE：并不是丟包數(shù)量不為零就有問(wèn)題，對(duì)于 UDP 來(lái)說(shuō)，如果有少量的丟包很可能是預(yù)期的行為，比如丟包率（丟包數(shù)量/接收?qǐng)?bào)文數(shù)量）在萬(wàn)分之一甚至更低。

網(wǎng)卡或者驅(qū)動(dòng)丟包

之前講過(guò)，如果 ethtool -S eth0 中有 rx_***_errors 那么很可能是網(wǎng)卡有問(wèn)題，導(dǎo)致系統(tǒng)丟包，需要聯(lián)系服務(wù)器或者網(wǎng)卡供應(yīng)商進(jìn)行處理。

# ethtool -S eth0 | grep rx_ | grep errors
     rx_crc_errors: 0
     rx_missed_errors: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     rx_errors: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0

netstat -i 也會(huì)提供每個(gè)網(wǎng)卡的接發(fā)報(bào)文以及丟包的情況，正常情況下輸出中 error 或者 drop 應(yīng)該為 0。

如果硬件或者驅(qū)動(dòng)沒(méi)有問(wèn)題，一般網(wǎng)卡丟包是因?yàn)樵O(shè)置的緩存區(qū)（ring buffer）太小，可以使用 ethtool 命令查看和設(shè)置網(wǎng)卡的 ring buffer。

ethtool -g 可以查看某個(gè)網(wǎng)卡的 ring buffer，比如下面的例子

# ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:        4096
RX Mini:    0
RX Jumbo:    0
TX:        4096
Current hardware settings:
RX:        256
RX Mini:    0
RX Jumbo:    0
TX:        256

Pre-set 表示網(wǎng)卡最大的 ring buffer 值，可以使用 ethtool -G eth0 rx 8192 設(shè)置它的值。

Linux 系統(tǒng)丟包

linux 系統(tǒng)丟包的原因很多，常見(jiàn)的有：UDP 報(bào)文錯(cuò)誤、防火墻、UDP buffer size 不足、系統(tǒng)負(fù)載過(guò)高等，這里對(duì)這些丟包原因進(jìn)行分析。

UDP 報(bào)文錯(cuò)誤

如果在傳輸過(guò)程中UDP 報(bào)文被修改，會(huì)導(dǎo)致 checksum 錯(cuò)誤，或者長(zhǎng)度錯(cuò)誤，linux 在接收到 UDP 報(bào)文時(shí)會(huì)對(duì)此進(jìn)行校驗(yàn)，一旦發(fā)明錯(cuò)誤會(huì)把報(bào)文丟棄。

如果希望 UDP 報(bào)文 checksum 及時(shí)有錯(cuò)也要發(fā)送給應(yīng)用程序，可以在通過(guò) socket 參數(shù)禁用 UDP checksum 檢查：

int disable = 1;
setsockopt(sock_fd, SOL_SOCKET, SO_NO_CHECK, (void*)&disable, sizeof(disable)

防火墻

如果系統(tǒng)防火墻丟包，表現(xiàn)的行為一般是所有的 UDP 報(bào)文都無(wú)法正常接收，當(dāng)然不排除防火墻只 drop 一部分報(bào)文的可能性。

如果遇到丟包比率非常大的情況，請(qǐng)先檢查防火墻規(guī)則，保證防火墻沒(méi)有主動(dòng) drop UDP 報(bào)文。

UDP buffer size 不足

linux 系統(tǒng)在接收?qǐng)?bào)文之后，會(huì)把報(bào)文保存到緩存區(qū)中。因?yàn)榫彺鎱^(qū)的大小是有限的，如果出現(xiàn) UDP 報(bào)文過(guò)大（超過(guò)緩存區(qū)大小或者 MTU 大?。⒔邮盏綀?bào)文的速率太快，都可能導(dǎo)致 linux 因?yàn)榫彺鏉M而直接丟包的情況。

在系統(tǒng)層面，linux 設(shè)置了 receive buffer 可以配置的最大值，可以在下面的文件中查看，一般是 linux 在啟動(dòng)的時(shí)候會(huì)根據(jù)內(nèi)存大小設(shè)置一個(gè)初始值。

• /proc/sys/net/core/rmem_max：允許設(shè)置的 receive buffer 最大值
• /proc/sys/net/core/rmem_default：默認(rèn)使用的 receive buffer 值
• /proc/sys/net/core/wmem_max：允許設(shè)置的 send buffer 最大值
• /proc/sys/net/core/wmem_dafault：默認(rèn)使用的 send buffer 最大值

但是這些初始值并不是為了應(yīng)對(duì)大流量的 UDP 報(bào)文，如果應(yīng)用程序接收和發(fā)送 UDP 報(bào)文非常多，需要講這個(gè)值調(diào)大。可以使用 sysctl 命令讓它立即生效：

sysctl -w net.core.rmem_max=26214400 # 設(shè)置為 25M

也可以修改 /etc/sysctl.conf 中對(duì)應(yīng)的參數(shù)在下次啟動(dòng)時(shí)讓參數(shù)保持生效。

如果報(bào)文報(bào)文過(guò)大，可以在發(fā)送方對(duì)數(shù)據(jù)進(jìn)行分割，保證每個(gè)報(bào)文的大小在 MTU 內(nèi)。

另外一個(gè)可以配置的參數(shù)是 netdev_max_backlog，它表示 linux 內(nèi)核從網(wǎng)卡驅(qū)動(dòng)中讀取報(bào)文后可以緩存的報(bào)文數(shù)量，默認(rèn)是 1000，可以調(diào)大這個(gè)值，比如設(shè)置成 2000：

sudo sysctl -w net.core.netdev_max_backlog=2000

系統(tǒng)負(fù)載過(guò)高

系統(tǒng) CPU、memory、IO 負(fù)載過(guò)高都有可能導(dǎo)致網(wǎng)絡(luò)丟包，比如 CPU 如果負(fù)載過(guò)高，系統(tǒng)沒(méi)有時(shí)間進(jìn)行報(bào)文的 checksum 計(jì)算、復(fù)制內(nèi)存等操作，從而導(dǎo)致網(wǎng)卡或者 socket buffer 出丟包；memory 負(fù)載過(guò)高，會(huì)應(yīng)用程序處理過(guò)慢，無(wú)法及時(shí)處理報(bào)文；IO 負(fù)載過(guò)高，CPU 都用來(lái)響應(yīng) IO wait，沒(méi)有時(shí)間處理緩存中的 UDP 報(bào)文。

linux 系統(tǒng)本身就是相互關(guān)聯(lián)的系統(tǒng)，任何一個(gè)組件出現(xiàn)問(wèn)題都有可能影響到其他組件的正常運(yùn)行。對(duì)于系統(tǒng)負(fù)載過(guò)高，要么是應(yīng)用程序有問(wèn)題，要么是系統(tǒng)不足。對(duì)于前者需要及時(shí)發(fā)現(xiàn)，debug 和修復(fù)；對(duì)于后者，也要及時(shí)發(fā)現(xiàn)并擴(kuò)容。

應(yīng)用丟包

上面提到系統(tǒng)的 UDP buffer size，調(diào)節(jié)的 sysctl 參數(shù)只是系統(tǒng)允許的最大值，每個(gè)應(yīng)用程序在創(chuàng)建 socket 時(shí)需要設(shè)置自己 socket buffer size 的值。

linux 系統(tǒng)會(huì)把接受到的報(bào)文放到 socket 的 buffer 中，應(yīng)用程序從 buffer 中不斷地讀取報(bào)文。所以這里有兩個(gè)和應(yīng)用有關(guān)的因素會(huì)影響是否會(huì)丟包：socket buffer size 大小以及應(yīng)用程序讀取報(bào)文的速度。

對(duì)于第一個(gè)問(wèn)題，可以在應(yīng)用程序初始化 socket 的時(shí)候設(shè)置 socket receive buffer 的大小，比如下面的代碼把 socket buffer 設(shè)置為 20MB：

uint64_t receive_buf_size = 20*1024*1024;  //20 MB
setsockopt(socket_fd, SOL_SOCKET, SO_RCVBUF, &receive_buf_size, sizeof(receive_buf_size));

如果不是自己編寫和維護(hù)的程序，修改應(yīng)用代碼是件不好甚至不太可能的事情。很多應(yīng)用程序會(huì)提供配置參數(shù)來(lái)調(diào)節(jié)這個(gè)值，請(qǐng)參考對(duì)應(yīng)的官方文檔；如果沒(méi)有可用的配置參數(shù)，只能給程序的開發(fā)者提 issue 了。

很明顯，增加應(yīng)用的 receive buffer 會(huì)減少丟包的可能性，但同時(shí)會(huì)導(dǎo)致應(yīng)用使用更多的內(nèi)存，所以需要謹(jǐn)慎使用。

另外一個(gè)因素是應(yīng)用讀取 buffer 中報(bào)文的速度，對(duì)于應(yīng)用程序來(lái)說(shuō)，處理報(bào)文應(yīng)該采取異步的方式

包丟在什么地方

想要詳細(xì)了解 linux 系統(tǒng)在執(zhí)行哪個(gè)函數(shù)時(shí)丟包的話，可以使用 dropwatch 工具，它監(jiān)聽(tīng)系統(tǒng)丟包信息，并打印出丟包發(fā)生的函數(shù)地址：

# dropwatch -l kas
Initalizing kallsyms db
dropwatch > start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring

1 drops at tcp_v4_do_rcv+cd (0xffffffff81799bad)
10 drops at tcp_v4_rcv+80 (0xffffffff8179a620)
1 drops at sk_stream_kill_queues+57 (0xffffffff81729ca7)
4 drops at unix_release_sock+20e (0xffffffff817dc94e)
1 drops at igmp_rcv+e1 (0xffffffff817b4c41)
1 drops at igmp_rcv+e1 (0xffffffff817b4c41)

通過(guò)這些信息，找到對(duì)應(yīng)的內(nèi)核代碼處，就能知道內(nèi)核在哪個(gè)步驟中把報(bào)文丟棄，以及大致的丟包原因。

此外，還可以使用 linux perf 工具監(jiān)聽(tīng) kfree_skb（把網(wǎng)絡(luò)報(bào)文丟棄時(shí)會(huì)調(diào)用該函數(shù)） 事件的發(fā)生：

sudo perf record -g -a -e skb:kfree_skb
sudo perf script

關(guān)于 perf 命令的使用和解讀，網(wǎng)上有很多文章可以參考。

總結(jié)

• UDP 本身就是無(wú)連接不可靠的協(xié)議，適用于報(bào)文偶爾丟失也不影響程序狀態(tài)的場(chǎng)景，比如視頻、音頻、游戲、監(jiān)控等。對(duì)報(bào)文可靠性要求比較高的應(yīng)用不要使用 UDP，推薦直接使用 TCP。當(dāng)然，也可以在應(yīng)用層做重試、去重保證可靠性
• 如果發(fā)現(xiàn)服務(wù)器丟包，首先通過(guò)監(jiān)控查看系統(tǒng)負(fù)載是否過(guò)高，先想辦法把負(fù)載降低再看丟包問(wèn)題是否消失
• 如果系統(tǒng)負(fù)載過(guò)高，UDP 丟包是沒(méi)有有效解決方案的。如果是應(yīng)用異常導(dǎo)致 CPU、memory、IO 過(guò)高，請(qǐng)及時(shí)定位異常應(yīng)用并修復(fù)；如果是資源不夠，監(jiān)控應(yīng)該能及時(shí)發(fā)現(xiàn)并快速擴(kuò)容
• 對(duì)于系統(tǒng)大量接收或者發(fā)送 UDP 報(bào)文的，可以通過(guò)調(diào)節(jié)系統(tǒng)和程序的 socket buffer size 來(lái)降低丟包的概率
• 應(yīng)用程序在處理 UDP 報(bào)文時(shí)，要采用異步方式，在兩次接收?qǐng)?bào)文之間不要有太多的處理邏輯