很多人都在詬病Linux內核協議棧收包效率低，不管他們是真的懂還是一點都不懂只是聽別人說的，反正就是在一味地懟Linux內核協議棧，他們的武器貌似只有DPDK。

但是，Linux內核協議棧收包效率真的很低，這是為什么？有沒有辦法去嘗試著優化？而不是動不動就DPDK。

我們從最開始說起。

Linux內核作為一個通用操作系統內核，脫胎于UNIX那一套現代操作系統理論。

但一開始不知道怎么回事將網絡協議棧的實現塞進了內核態，從此它就一直在內核態了。既然網絡協議棧的處理在內核態進行，那么網絡數據包必然是在內核態被處理的。無論如何，數據包要先進入內核態，這就涉及到了進入內核態的方式：

• 外部可以從兩個方向進入內核-從用戶態系統調用進入或者從硬件中斷進入。

也就是說，系統在任意時刻，必然處在兩個上下文中的一個：

1. 進程上下文
2. 中斷上下文 (在非中斷線程化的系統，也就是任意進程上下文)

收包邏輯的協議棧處理顯然是自網卡而上的，它顯然是在中斷上下文中，而數據包往用戶進程的數據接收處理，顯然是在應用程序的進程上下文中， 數據包通過socket在兩個上下文中被轉接。

在socket層的數據包轉接處，必然存在著一個隊列緩存，這是一個典型的 生產者-消費者 模型，中斷上下文的終點作為生產者將數據包入隊，而進程上下文作為消費者從隊列消費數據包：

非常清爽的一個圖，這個圖是 兩個上下文接力處理協議棧收包邏輯的必然結果 ，讓我們加入一些實際必須要考慮的問題后，我們會發現這幅圖并不是那么清爽，然后再回過頭看如何來優化。

既然兩個上下文都要在任意可能的時刻操作同一個socket進行數據包的轉交，那么必須有一個同步機制保護socket元數據以及數據包skb本身。

由于Linux內核中斷，軟中斷可能處在任意進程上下文，唯一的同步方案幾乎就是spinlock了，于是，真正的圖示應該是下面的樣子：

現在可以說，類似上面的這種這種保護是非常必要的，特別是對于TCP而言。

我們知道，TCP是基于事務的有狀態傳輸協議，而且攜帶復雜的流控和擁塞控制機制，這些機制所依托的就是socket當前的一些狀態數據，比如inflight，lost，retrans等等，這些狀態數據在發包和接收ACK/SACK期間會不斷變化，所以說：

• 在一個上下文完成一次事務傳輸之前，必須鎖定socket狀態數據。

比方說發包流程。數據包的發送可以出現在兩個上下文中：

1. 進程上下文：系統調用觸發的發包。
2. 中斷上下文：ACK/SACK觸發的發包。

任何一個上下文的發包過程必須被TCP協議本身比如擁塞控制，流量控制這些所終止，而不能被中途切換到另一個上下文中，所以必須鎖定。

問題是，上圖中的鎖定是不是太狠了些，中斷上下文自旋時間完全取決于進程上下文的行文，這不利于軟中斷的快速返回，極大地降低了系統的響應度。

于是，需要把鎖的粒度進行細分。Linux內核并沒有在橫向上將鎖的粒度做劃分，而是在縱向上，采用兩個層次的鎖機制：

我們看到的Linux內核在處理收包邏輯時的backlog，其實抽象出來就是上面的二級鎖，它是不是很像Windows的IRQL機制呢？伴隨著APC，DPC，你可以把暫時由于高level的IRQL阻滯而無法執行的邏輯放入DPC：

由于進程上下文對socket的low鎖占有，中斷上下文將skb排入次level的backlog隊列，當進程上下文釋放low鎖的時候，順序執行次level被排入的任務，即處理backlog中的skb。

事實上這是一種非常常見且通用的設計，除了Windows的IRQL，Linux中斷的上半部/下半部也是這種基于思想設計的。

前面說了，TCP的一次事務可能非常 復雜耗時 ，并且必須一次完成，這意味著期間必須持有socket low鎖，以發包邏輯 tcp_write_xmit 函數為例，其內部循環發包，直到受到窗口限制而終止，每一次tcp_transmit_skb返回耗時3微秒～5微秒，平均4微秒，以每次發送4個包為例，在這期間，若使用spinlock，那么中斷上下文的收包路徑將自旋16微秒，16微秒對于spinlock而言有點久了，于是采用兩級的lock機制，非常有效！

backlog隊列機制有效降低了中斷上下文的spin時延，提高了系統的響應度，非常不錯。

但問題是，UDP有必要這樣嗎？

首先，UDP是無狀態的，收包和發包都無需事務，協議棧對UDP的處理，從來都是單個報文粒度的，因此只需要保護唯一的socket接收隊列即可，即 sk_receive_queue 。

需要保護的接收隊列操作區間都是指令級別的時延，采用一把單一的 sk_receive_queue->lock 足矣。

確實，在Linux 2.6.25版本內核之前，就是這么干的。而自從2.2版本內核，TCP就已經采用二級鎖backlog隊列了。

然而，在2.6.25版本內核中，Linux協議棧的UDP收包路徑，轉而采用了兩層鎖的backlog隊列機制，和TCP一樣的邏輯：

顯然這非常沒有必要。如果你有多個線程同時操作一個UDP socket，將會直面這個熱點，但事實上，你很難遭遇這樣的場景，如果非要說一個，那么DNS服務器可能首當其中。

之所以在2.6.25版本內核引入了二級鎖backlog隊列，大致是考慮到UDP需要統計內存全局記賬，以防UDP吃盡系統內存，可以review一下 sk_rmem_schedule 函數的邏輯。而在2.6.25版本內核之前，UDP的內存使用是不記賬的，由于UDP本身沒有任何類似流控，擁塞控制之類的約束機制，很容易被惡意程序將系統內存吃盡。

因此，除了sk_receive_queue需要保護，內存記賬邏輯也是需要保護的，比如累加當前skb對內存的占用到全局數據結構。但即便如此，把這些統計數據的更新都塞入到spinlock的保護區域，也還是要比兩級lock要好。

在我看來，之所以引入二級鎖backlog機制來保護內存記賬邏輯，這是在 借鑒 TCP的代碼，或者說 抄代碼 更直接些。這個攜帶backlog隊列機制的UDP收包代碼存在了好多年，一直在4.9內核才終結。

事實上，僅僅下面的邏輯就可以了：

簡單直接！Linux內核的UDP處理邏輯在4.10版本也確實去掉了兩級的lock。恢復到了2.6.25內核版本之前的邏輯。

上面的優化帶來了可觀的性能收益，但是卻并不值得炫耀。

因為上面的優化更像是解決了一個bug，這個bug是在2.6.25版本內核因為借鑒TCP的backlog實現而引入的，而事實上，UDP并不需要這種花哨的backlog邏輯。所以說，上面的效果并非優化而帶來的效果，而是解了一個bug帶來的效果。

但是為什么遲至4.10版本才發現并解決這個問題的呢？

我想這件事可能跟QUIC有關。

用得少的邏輯自然就不容易發現問題，這就好比David Miller在2.6版本內核引入IPv6實現的那幾個bug，就是因為IPv6用的人少，所以一直在很晚的4.23+版本內核才被發現被解決。對于UDP，一直到2.6.24版本其實現都挺好，符合邏輯，2.6.25引入的二級鎖bug同樣是因為UDP本身用的少而沒有被發現。

在QUIC之前，很少有那種有來有回的持續全雙工UDP長連接，基本都是request/response的oneshot類型的連接。然而QUIC卻是類似TCP的全雙工協議，在數據發送端持續發送大塊數據的同時，伴隨著的是接收大量的ACK報文，這顯然和TCP一樣，也是一種反饋控制的方式來驅動數據的發送。

QUIC是有確認機制的，但是處理確認卻不是在內核進行的，內核只是一個快速將確認包收到用戶態QUIC處理進程的一個通路，這個通路越快越好！

也就是說，QUIC的ACK報文的接收效率會影響其數據的發送效率。

隨著QUIC的大規模部署，人們才開始逐漸關注其背后UDP的收包效率問題。

擺脫了二級鎖的backlog隊列之后，僅僅是為UDP后續的優化掃清了障礙，這才是真正剛剛開始。擺在UDP的內核協議棧收包效率面前的，有一個現成的靶子，那就是DPDK。

挺煩DPDK的，說實話，被人天天說的東西都挺煩。不過你得先把內核協議棧的UDP性能優化到接近DPDK，再把這種鄙視當后話來講才更酷。

由于UDP的處理非常簡單，因此實現一個能和DPDK對接的UDP用戶態協議棧則并不是一件難事。而TCP則相反，它非常復雜，所以DPDK很少有完整處理TCP端到端邏輯的，大多數都只是做類似中間節點DPI這種事。目前都沒有幾個好用的基于DPDK的TCP實現，但是UDP實現卻很多。

DPDK的偽粉絲拿UDP說事的，比拿TCP說事，成本要低很多。

好吧，那為什么DPDK處理UDP收包效率那么高？

答案很簡單， DPDK是在進程上下文輪詢接收UDP數據包的！也就是說，它擺脫了兩個問題：

1. 進程上下文和中斷上下文操作共享數據的鎖問題。
2. 進程上下文和中斷上下文切換導致的cache miss問題。

這兩點其實也就是 “為什么內核協議棧性能干不過用戶態協議棧” 的要點。當然，Linux內核協議棧無法擺脫這兩點問題，也就回答了本文的題目中的第一個問題， “Linux內核UDP收包為什么效率低？” 。

不同的上下文異步操作同一份數據，鎖是必不可少的。關于鎖的話題已經爛大街了。

現在僅就cache來討論，中斷上下文和進程上下文之間的切換，也有一個明顯的case：

中斷上下文中修改了socket的元統計數據，該修改會表現在cache中，然而當其wakeup該socket的處理進程后，切換到進程上下文的recv系統調用，其也或讀或寫這個統計數據，伴隨著cache的flush以及cache的一致性同步。

如果這些操作統一在進程上下文中進行，cache的利用率將會高效很多。當然，回到UDP收包不合理的backlog隊列機制，其實backlog本身存在的目的之一，就是為了讓進程上下文去處理，以提高cache的利用率，減少不必要的flush。然而，初衷未必能達到效果，在傳輸層用backlog將skb推給進程上下文去處理，已經太晚了，何必不再網卡就給進程上下文呢？就像DPDK那樣。

其實Linux內核社區早就意識到了這兩點，早在3.11版本內核中引入的busy poll機制就是為了解決鎖和切換問題的。busy poll的思想非常簡單，那就是：

不再需要軟中斷上下文往接收隊列里“推”數據包，而改成自己在進程上下文里主動從網卡上“拉”數據包。

落實到代碼上，那就是在進程上下文的recvmsg函數中直接調用napi的收包函數，從ring buffer里拿數據，自己調用netif_receive_skb。

如果busy poll總能執行，它總是能拉取到自己下一個需要的數據包，那么這基本就是DPDK的效率了，然而和DPDK一樣，這并不是一個統一的解決方案，輪詢固然對于收包有收益，但中斷是不能丟的，用CPU的自旋輪詢換取收包效率，這買賣代價太大，畢竟Linux內核并非專職收包的。

當然了，也許內核態實現協議棧本身就是一種錯誤，但這個話題有點跑偏，畢竟我們就是要優化內核協議棧的，而不是放棄它。

現在，我們不能指望busy poll擔當所有的性能問題，仍然要依靠中斷。既然依靠中斷，鎖的問題就是優化的重點。

以雙核CPU為例，假設CPU0專職處理中斷，而收包進程則綁定在CPU1上，我們很快能意識到， CPU0和CPU1對于每一個skb的enqueue和dequeue均在爭搶socket的sk_receive_queue的spinlock 。

優化措施顯而易見， 將多個skb聚集起來，一次性入接收隊列 。顯然，這需要兩個隊列：

1. 維護聚集隊列：由中斷上下文將skb推入該隊列。
2. 維護接收隊列：進程上下文從該隊列拉取skb。

接收隊列為空時，交換聚集隊列和接收隊列。

這樣，同樣在上述雙核CPU的情況下，只有在上面的第3點的操作中，才需要鎖保護。

考慮到機器的CPU并非雙核，可能是任意核，收包進程也未必綁定任何CPU，因此上述每一個隊列均需要一把鎖保護，無論如何， 和單隊列相比，雙隊列情況下，鎖的競爭減少了一半！

如此一來，雙隊列解除了中斷上下文和進程上下文之間的鎖競爭。

來看一下對比圖示：

引入雙隊列后：

即便已經很不錯了，但是：

• 中斷上下文中不同CPU可能會收到同一個socket的skb，CPU依然會在聚集隊列的鎖上蹦跶。
• 不同的CPU上的進程也可能會處理同一個socket，本意是合作，卻需要接收隊列的鎖來將其操作串行化。

沒辦法，通用的操作系統內核只能做到這里了，如果要解決以上的問題，就需要按照任何和角色明確綁CPU核心了，然而這也就不再是通用的內核了。最終，你會在內核里聞到DPDK的腐臭味，超級惡心。

對了，我暫且將雙隊列區分為了 聚集隊列 和 接收隊列 ，更好的名字可能是 backlog隊列 和 接收隊列 。中斷上下文總是操作backlog隊列，而進程上下文在接收隊列為空時，交換backlog隊列為接收隊列。然而，backlog隊列這個名字在我看來非常臭名昭著，所以，暫且不用它了。

…

我想本文應該就要結束了，確實沒有源碼分析，事實上，我覺得我寫的這篇要比下面的這種有意思的多，然而可能在網上能找到的基本都是這種 非常詳細的源碼分析：

哈哈…

我為什么沒有談UDP的GRO，LRO機制，因為太不通用了。但是另一方面，如果應用程序加以稍微支持，UDP的GRO，LRO將會帶來非常可觀的收益，別忘了，內核只是UDP報文的一個通路即可，既然是通路，它便不包含處理邏輯，越快通過，越好。如果你在乎高吞吐，那么就GRO唄，如下：

UDP的通用L4 GRO相當于一個非常簡單的5層協議，應用程序按照len字段稍加解析拆分即可，這將極大減少系統調用的次數，減少上下文切換帶來的cache miss損耗。