今天這篇文章，主要嘗試回答下面兩個問題：

• 內(nèi)核從網(wǎng)卡那里收到一個網(wǎng)絡(luò)包，到最終將其所攜帶的payload完整遞交給應(yīng)用層，中間涉及到多少個隊列?
• 為什么需要這么多各種各樣的隊列呢?

來吧，進入正題。

1. 大圖介紹

照例，先來介紹一下為本文所準備的大圖。這張圖是在之前的文章用圖之上修改而來，主要是添加了在TCP層所涉及到的隊列。據(jù)說這叫重復(fù)利用。

這張圖用來描繪內(nèi)核從物理網(wǎng)卡以及虛擬網(wǎng)卡接收到網(wǎng)絡(luò)包之后的數(shù)據(jù)流。

估計你注意到了圖中的 1(1.a、1.b)，2(2.a、2.b、2.c)，3 這樣的標號。對內(nèi)核而言，1和2是網(wǎng)絡(luò)包的接收入口，而3是網(wǎng)絡(luò)包的處理入口。

具體來說，1和2表示線路1和線路2，它倆分別代表網(wǎng)絡(luò)包從物理網(wǎng)卡進入內(nèi)核以及從虛擬網(wǎng)卡進入內(nèi)核所涉及到的一些關(guān)鍵操作。標號3表示的是內(nèi)核線程從這個入口位置獲取待處理網(wǎng)絡(luò)設(shè)備。

圖中最右邊是TCP/IP協(xié)議棧。對于一個skb而言，協(xié)議棧對其的處理是在內(nèi)核線程這個上下文中進行的。了解到這點很重要，我們總得知道到底是誰在替我們負重前行。

圖中的藍色寬箭頭表示網(wǎng)絡(luò)包流向用戶態(tài)的數(shù)據(jù)通道。但箭頭在TCP層由實心變成了空心，這是因為對于不同類型的網(wǎng)路包，用戶態(tài)所拿到的數(shù)據(jù)是不一樣的。在TCP層之下的所有層，大家處理的數(shù)據(jù)結(jié)構(gòu)都是skb。而到了TCP層則需要關(guān)心這個skb到底是與握手相關(guān)還是與數(shù)據(jù)包相關(guān)。

如你所料，skb穿過鏈路層和IP層的時候，會涉及到bridge-netfilter和netfilter(iptables)所設(shè)置的基于規(guī)則的過濾過程，還有路由過程。

圖 1：數(shù)據(jù)接收流程中的隊列鳥瞰圖

我們從左到右，從下至上，順著網(wǎng)絡(luò)包流過的路徑，看看沿途中會碰到哪些隊列。

我們說Network namespace用來隔離包括網(wǎng)卡(Network Interface)、回環(huán)設(shè)備(Loopback Device)、網(wǎng)絡(luò)棧、IP地址、端口等等在內(nèi)的網(wǎng)絡(luò)資源。下文所提的各類隊列也是這樣一種被隔離了的資源，所以圖1中所畫的所有這些隊列在不同的network ns中都各有一份。

2. RingBuffer

每個網(wǎng)卡在內(nèi)存里會有若干個隊列，每個這樣的隊列叫做RingBuffer。顧名思義，它是一個環(huán)形緩沖區(qū)。當物理網(wǎng)卡收到網(wǎng)絡(luò)包，會通過DMA將其拷貝到RingBuffer。當RingBuffer滿的時候，新來的數(shù)據(jù)包將給丟棄。

這是網(wǎng)絡(luò)包碰到的第一個隊列。那么誰負責將這個隊列里面的網(wǎng)絡(luò)包消費掉呢?答案是內(nèi)核線程，也即圖中的ksoftirqd。詳見后文。

3. Per CPU 隊列

每個CPU有一個自己專屬的數(shù)據(jù)結(jié)構(gòu)softnet_data。其上附有兩個隊列poll_list和input_pkt_queue。這兩個隊列里的內(nèi)容都由ksoftirqd來消費。圖1中所標示的ksoftirqd/4表示這個內(nèi)核線程與第4個CPU核綁定在一起，也即它只會處理這個核所擁有的softnet_data上的數(shù)據(jù)。

3.1 input_pkt_queue

物理網(wǎng)卡由RingBuffer來緩存網(wǎng)絡(luò)包，那虛擬網(wǎng)卡要發(fā)送出去的數(shù)據(jù)暫存在哪里呢?如圖1中2.a所示，放在input_pkt_queue這個隊列里。這個過程是在函數(shù)enqueue_to_backlog()中完成的。

3.2 poll_list

所有的待處理的網(wǎng)卡會掛到每個CPU專屬的poll_list上。我們可以將poll_list想象成晾曬香腸的架子，而每個網(wǎng)絡(luò)設(shè)備則如同香腸一樣掛到架子上面等待ksoftirqd處理。

待處理的網(wǎng)卡包括物理網(wǎng)卡和虛擬網(wǎng)卡。簡單地來說，只要需要圖1中的內(nèi)核線程處理網(wǎng)絡(luò)包，就需要將這個網(wǎng)卡掛載到poll_list隊列上。

那么這個掛載動作是由誰完成的呢?

• 對于物理網(wǎng)卡，由中斷服務(wù)程序負責將網(wǎng)卡掛到poll_list上。如圖1中步驟1.a所示。
• 對于虛擬網(wǎng)卡，如veth或者lo，則在enqueue_to_backlog()函數(shù)中將虛擬網(wǎng)卡掛到poll_list上。如圖1中步驟2.b所示。

到這里，我們已經(jīng)碰到了三種不同的隊列了，前兩者緩存數(shù)據(jù)，而后者緩存設(shè)備列表。其中RingBuffer和input_pkt_queue隊列都用于緩存網(wǎng)絡(luò)包，只是一個服務(wù)的對象是物理網(wǎng)卡而另一個則是虛擬網(wǎng)卡。poll_list隊列用于緩存需要內(nèi)核線程處理的設(shè)備。

無論網(wǎng)絡(luò)包是位于哪個隊列里，內(nèi)核線程的啟動意味著網(wǎng)絡(luò)包開始進入TCP/IP協(xié)議棧。下面我們來看看在協(xié)議棧處理過程中用到的隊列有哪幾個。

4. listening socket所用隊列

對于服務(wù)器而言，一個典型的架構(gòu)是 “監(jiān)聽線程+工作線程池” 組合。下面是偽代碼。

void main(){
  int listening_socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

  // 綁定 ip 和端口
  bind(listening_socket, ...);

  // 監(jiān)聽
  listen(listening_socket, 3 /*backlog*/);

  while(accept_socket = accept(listening_socket)){
     // 將accept_socket交給一個worker thread去讀取網(wǎng)絡(luò)數(shù)據(jù)
     pthread_t worker_thread;
     new_sock = malloc(sizeof(int));
     *new_sock = client_sock;

     // 創(chuàng)建一個工作線程
     if( pthread_create( &worker_thread , NULL ,  connection_handler , (void*) new_sock) < 0)
     {
       return 1;
     }
     ...
  }
}

這段代碼的骨架挺簡單，主線程為listening thread，用于創(chuàng)建一個listening_socket，并負責基于它來接收客戶端的TCP連接。每一次客戶端與服務(wù)器的成功連接都會使得accept()函數(shù)返回一個accept_socket，listening thread還會創(chuàng)建一個work thread并讓它基于accept_socket與客戶端通信。

這些work thread匯聚成了一個工作線程池。當然，實際工作的代碼可不會創(chuàng)建無數(shù)個work thread，當已創(chuàng)建的work thread數(shù)量到達一個閾值后，創(chuàng)建動作就需要轉(zhuǎn)變成從線程池中提溜一個線程出來這樣的操作。

我將這段代碼中與本文相關(guān)的關(guān)鍵點列在這里：

• 這段代碼完成了 “監(jiān)聽線程+工作線程池” 組合這樣的骨架。
• 監(jiān)聽線程操作的socket是listening_socket。
• 監(jiān)聽線程針對listening_socket，設(shè)置了一個大小為3的backlog。
• 工作線程操作的socket是accept_socket。

在內(nèi)核中，為每個listening socket 維護了兩個隊列，它們都與連接管理相關(guān)。

• 已經(jīng)建立了連接的隊列，這些連接暫時還沒有被work thread領(lǐng)走。隊列里面的每個連接已經(jīng)完成了三次握手，且處于ESTABLISHED狀態(tài)。這個隊列的名字叫 icsk_accept_queue，如圖1中accept_queue所示 。
• 還沒有完全建立連接的隊列，隊列里面的每個連接還沒有完成三次握手，處于 SYN_REVD 的狀態(tài)。這個隊列也叫半連接隊列，syn queue。

示例代碼中，在調(diào)用listen()函數(shù)的時候，將backlog設(shè)置為3。它的作用其實是在控制這個icsk_accept_queue的大小。而syn queue大小則可以通過 /proc/sys/net/ipv4/tcp_max_syn_backlog配置。

服務(wù)端調(diào)用 accept() 函數(shù)，其實是從第一個隊列icsk_accept_queue中拿出一個已經(jīng)完成的連接進行數(shù)據(jù)處理。如果這個隊列里是空的，那表示目前還沒有已完成握手的連接，那就把listening thread阻塞等待吧，反正它暫時也沒其它事可做。

5. accept socket所用隊列

每個accept socket包含有4種不同的隊列：backlog隊列、prequeue隊列、sk_receive_queue隊列和out_of_order_queue隊列。

其中prequeue隊列在17年后的Linux版本中已經(jīng)取消了，故本文略過這個隊列。

5.1 backlog 隊列

當網(wǎng)絡(luò)包到達TCP，但是與之相關(guān)的accpet socket沒有被用戶態(tài)進程讀取中，那么協(xié)議棧會調(diào)用tcp_add_backlog()將這個網(wǎng)絡(luò)包暫存至backlog隊列中。這樣做的目的是讓內(nèi)核線程可以盡快處理下一個網(wǎng)絡(luò)包。

什么情況下會出現(xiàn)accpet socket沒有被用戶態(tài)進程讀取呢?比如work thread通過read()讀取到一段數(shù)據(jù)后便開始直接處理這段數(shù)據(jù)而耽擱了下一段數(shù)據(jù)的讀取。

注意這個地方的backlog隊列和前文listening socket處所提及的backlog參數(shù)是兩回事。

5.2 sk_receive_queue和out_of_order_queue隊列

當然如果work thread因為調(diào)用read()被阻塞了，表示它正在這個accpet socket上急切地等待數(shù)據(jù)的到來，這個時候協(xié)議棧就會把網(wǎng)絡(luò)包優(yōu)先通過函數(shù)skb_copy_datagram_msg()直接給它了。但work thread處理能力也有限度，一直給它喂數(shù)據(jù)也會噎死它，那更多的網(wǎng)絡(luò)包就需要sk_receive_queue隊列和out_of_order_queue隊列的幫忙了。

sk_receive_queue隊列的作用很好理解，它里面存放的是按照seq number排好序的數(shù)據(jù)。但我們都知道跨internet的傳輸會使得網(wǎng)絡(luò)包以亂序方式到達，這個時候就需要把這些亂序的包先放到out_of_order_queue隊列排隊了。

應(yīng)用程序可以讀取到sk_receive_queue隊列和backlog隊列中的內(nèi)容，但無法直接訪問out_of_order_queue隊列。為了體現(xiàn)這一點，二哥在圖1中特意做了處理：out_of_order_queue隊列沒有出現(xiàn)在通往用戶態(tài)的數(shù)據(jù)通道上。當協(xié)議棧發(fā)現(xiàn)out_of_order_queue隊列中的亂續(xù)包和新到的包可以拼湊成完整有序的數(shù)據(jù)流后，就將網(wǎng)絡(luò)包從out_of_order_queue隊列移動到sk_receive_queue隊列。

5.3 消費隊列

work thread所調(diào)用的read()函數(shù)在內(nèi)核態(tài)最終通過函數(shù)tcp_recvmsg()來讀取暫存在sk_receive_queue中的數(shù)據(jù)。

每次這個sk_receive_queue隊列中的內(nèi)容處理完畢后，tcp_recvmsg()還會繼續(xù)處理backlog隊列里面累積的網(wǎng)絡(luò)包。

6. 為什么需要隊列

行文至此，我們來回答文首的第二個問題：為什么需要這么多各種各樣的隊列呢?

答案是：效率。

把整個面向TCP連接的網(wǎng)絡(luò)包接收處理流程稍作總結(jié)，我們會發(fā)現(xiàn)重要的參與者有如下幾個：

• 網(wǎng)卡，包括物理的和虛擬的網(wǎng)卡：負責接收網(wǎng)絡(luò)包。
• 內(nèi)核線程：消費網(wǎng)絡(luò)包，負責調(diào)用TCP/IP協(xié)議棧函數(shù)將亂序到達的網(wǎng)絡(luò)包整理還原成data streaming。
• 應(yīng)用程序：接收、消費data streaming。

網(wǎng)卡和內(nèi)核線程操作的對象都是網(wǎng)絡(luò)包，只是各自關(guān)注的焦點不同而已。它們完成自己負責的操作任務(wù)后，需要盡快地將網(wǎng)絡(luò)包交給繼任者，以便抽身去處理下一個網(wǎng)絡(luò)包。遞交網(wǎng)絡(luò)包的時候，繼任者可能正在忙，你總不能在那邊傻等對吧?這個時候隊列的出現(xiàn)就起到了很好的緩沖作用。

比如圖1中的內(nèi)核線程就是這樣，它不斷地從poll_list里面拿出需要處理的網(wǎng)卡并處理網(wǎng)卡里的網(wǎng)絡(luò)包。處理好的網(wǎng)絡(luò)包送進下文所說的幾個隊列中留待繼任者繼續(xù)處理。

我們還可以將所有這些參與者想象成制造業(yè)價值流(源于精益原則)中不同的工作中心。在這個價值流中，不同的工作中心之間通常會轉(zhuǎn)移各自的輸出(半)成品，并通過倉庫來進行一定程度的緩存，倉庫類似本文的隊列。

7. 總結(jié)

文末做一個總結(jié)。

為了可以高效地處理網(wǎng)絡(luò)包，同時又可以讓接收數(shù)據(jù)的各個重要組成模塊以松耦合的方式合作，各式各樣的隊列參與了網(wǎng)絡(luò)包的接收過程。

• RingBuffer和input_pkt_queue最先用于緩存網(wǎng)卡所接收到的網(wǎng)絡(luò)包。
• poll_list用于告訴內(nèi)核線程，當前有哪些網(wǎng)絡(luò)設(shè)備正在排隊等待它的處理。
• Server端一般用到listening socket和accept socket。

listening socket用于監(jiān)聽客戶端的連接并負責生成后者，它維護了兩個隊列，分別用于緩存已經(jīng)握手成功的但還沒有被工作線程領(lǐng)走的連接和還未完成三次握手的連接。

accept socket用于針對具體的連接進行數(shù)據(jù)通信。它用到了backlog、sk_receive_queue和out_of_order_queue這三個隊列。

文中所用高清大圖已傳至二哥的github：https://github.com/LanceHBZhang/LanceAndCloudnative。