半年前我以源碼的方式描述了網(wǎng)絡(luò)包的接收過程。之后不斷有粉絲提醒我還沒聊發(fā)送過程呢。好，安排！

在開始今天的文章之前，我先來請大家思考幾個小問題。

• 問1：我們在查看內(nèi)核發(fā)送數(shù)據(jù)消耗的 CPU 時，是應(yīng)該看 sy 還是 si ？

• 問2：為什么你服務(wù)器上的 /proc/softirqs 里 NET_RX 要比 NET_TX 大的多的多？

• 問3：發(fā)送網(wǎng)絡(luò)數(shù)據(jù)的時候都涉及到哪些內(nèi)存拷貝操作？

這些問題雖然在線上經(jīng)?？吹?#xff0c;但我們似乎很少去深究。如果真的能透徹地把這些問題理解到位，我們對性能的掌控能力將會變得更強。

帶著這三個問題，我們開始今天對 Linux 內(nèi)核網(wǎng)絡(luò)發(fā)送過程的深度剖析。還是按照我們之前的傳統(tǒng)，先從一段簡單的代碼作為切入。如下代碼是一個典型服務(wù)器程序的典型的縮微代碼：

int?main(){fd?=?socket(AF_INET,?SOCK_STREAM,?0);bind(fd,?...);listen(fd,?...);cfd?=?accept(fd,?...);//?接收用戶請求read(cfd,?...);//?用戶請求處理dosometing();?//?給用戶返回結(jié)果send(cfd,?buf,?sizeof(buf),?0); }

今天我們來討論上述代碼中，調(diào)用 send 之后內(nèi)核是怎么樣把數(shù)據(jù)包發(fā)送出去的。本文基于Linux 3.10，網(wǎng)卡驅(qū)動采用Intel的igb網(wǎng)卡舉例。

預(yù)警：本文共有一萬多字，25 張圖，長文慎入！

開發(fā)內(nèi)功修煉

飛哥有鵝廠、搜狗 10 年多的開發(fā)工作經(jīng)驗。通過本號，我把多年中對于性能的一些深度思考分享給大家。

57篇原創(chuàng)內(nèi)容

Official Account

一、Linux 網(wǎng)絡(luò)發(fā)送過程總覽

我覺得看 Linux 源碼最重要的是得有整體上的把握，而不是一開始就陷入各種細(xì)節(jié)。

我這里先給大家準(zhǔn)備了一個總的流程圖，簡單闡述下 send 發(fā)送了的數(shù)據(jù)是如何一步一步被發(fā)送到網(wǎng)卡的。

在這幅圖中，我們看到用戶數(shù)據(jù)被拷貝到內(nèi)核態(tài)，然后經(jīng)過協(xié)議棧處理后進(jìn)入到了 RingBuffer 中。隨后網(wǎng)卡驅(qū)動真正將數(shù)據(jù)發(fā)送了出去。當(dāng)發(fā)送完成的時候，是通過硬中斷來通知 CPU，然后清理 RingBuffer。

因為文章后面要進(jìn)入源碼，所以我們再從源碼的角度給出一個流程圖。

雖然數(shù)據(jù)這時已經(jīng)發(fā)送完畢，但是其實還有一件重要的事情沒有做，那就是釋放緩存隊列等內(nèi)存。

那內(nèi)核是如何知道什么時候才能釋放內(nèi)存的呢，當(dāng)然是等網(wǎng)絡(luò)發(fā)送完畢之后。網(wǎng)卡在發(fā)送完畢的時候，會給 CPU 發(fā)送一個硬中斷來通知 CPU。更完整的流程看圖：

注意，我們今天的主題雖然是發(fā)送數(shù)據(jù)，但是硬中斷最終觸發(fā)的軟中斷卻是 NET_RX_SOFTIRQ，而并不是 NET_TX_SOFTIRQ ！！！（T 是 transmit 的縮寫，R 表示 receive）

意不意外，驚不驚喜？？？

所以這就是開篇問題 1 的一部分的原因（注意，這只是一部分原因）。

問1：在服務(wù)器上查看 /proc/softirqs，為什么 NET_RX 要比 NET_TX 大的多的多？

傳輸完成最終會觸發(fā) NET_RX，而不是 NET_TX。所以自然你觀測 /proc/softirqs 也就能看到 NET_RX 更多了。

好，現(xiàn)在你已經(jīng)對內(nèi)核是怎么發(fā)送網(wǎng)絡(luò)包的有一個全局上的把握了。不要得意，我們需要了解的細(xì)節(jié)才是更有價值的地方，讓我們繼續(xù)！！

二、網(wǎng)卡啟動準(zhǔn)備

現(xiàn)在的服務(wù)器上的網(wǎng)卡一般都是支持多隊列的。每一個隊列上都是由一個 RingBuffer 表示的，開啟了多隊列以后的的網(wǎng)卡就會對應(yīng)有多個 RingBuffer。

網(wǎng)卡在啟動時最重要的任務(wù)之一就是分配和初始化 RingBuffer，理解了 RingBuffer 將會非常有助于后面我們掌握發(fā)送。因為今天的主題是發(fā)送，所以就以傳輸隊列為例，我們來看下網(wǎng)卡啟動時分配 RingBuffer 的實際過程。

在網(wǎng)卡啟動的時候，會調(diào)用到 __igb_open 函數(shù)，RingBuffer 就是在這里分配的。

//file:?drivers/net/ethernet/intel/igb/igb_main.c static?int?__igb_open(struct?net_device?*netdev,?bool?resuming) {struct?igb_adapter?*adapter?=?netdev_priv(netdev);//分配傳輸描述符數(shù)組err?=?igb_setup_all_tx_resources(adapter);//分配接收描述符數(shù)組err?=?igb_setup_all_rx_resources(adapter);//開啟全部隊列netif_tx_start_all_queues(netdev); }

在上面 __igb_open 函數(shù)調(diào)用 igb_setup_all_tx_resources 分配所有的傳輸 RingBuffer, 調(diào)用 igb_setup_all_rx_resources 創(chuàng)建所有的接收 RingBuffer。

//file:?drivers/net/ethernet/intel/igb/igb_main.c static?int?igb_setup_all_tx_resources(struct?igb_adapter?*adapter) {//有幾個隊列就構(gòu)造幾個?RingBufferfor?(i?=?0;?i?<?adapter->num_tx_queues;?i++)?{igb_setup_tx_resources(adapter->tx_ring[i]);} }

真正的 RingBuffer 構(gòu)造過程是在 igb_setup_tx_resources 中完成的。

//file:?drivers/net/ethernet/intel/igb/igb_main.c int?igb_setup_tx_resources(struct?igb_ring?*tx_ring) {//1.申請?igb_tx_buffer?數(shù)組內(nèi)存size?=?sizeof(struct?igb_tx_buffer)?*?tx_ring->count;tx_ring->tx_buffer_info?=?vzalloc(size);//2.申請?e1000_adv_tx_desc?DMA?數(shù)組內(nèi)存tx_ring->size?=?tx_ring->count?*?sizeof(union?e1000_adv_tx_desc);tx_ring->size?=?ALIGN(tx_ring->size,?4096);tx_ring->desc?=?dma_alloc_coherent(dev,?tx_ring->size,&tx_ring->dma,?GFP_KERNEL);//3.初始化隊列成員tx_ring->next_to_use?=?0;tx_ring->next_to_clean?=?0; }

從上述源碼可以看到，實際上一個 RingBuffer 的內(nèi)部不僅僅是一個環(huán)形隊列數(shù)組，而是有兩個。

1）igb_tx_buffer 數(shù)組：這個數(shù)組是內(nèi)核使用的，通過 vzalloc 申請的。
2）e1000_adv_tx_desc 數(shù)組：這個數(shù)組是網(wǎng)卡硬件使用的，硬件是可以通過 DMA 直接訪問這塊內(nèi)存，通過 dma_alloc_coherent 分配。

這個時候它們之間還沒有啥聯(lián)系。將來在發(fā)送的時候，這兩個環(huán)形數(shù)組中相同位置的指針將都將指向同一個 skb。這樣，內(nèi)核和硬件就能共同訪問同樣的數(shù)據(jù)了，內(nèi)核往 skb 里寫數(shù)據(jù)，網(wǎng)卡硬件負(fù)責(zé)發(fā)送。

最后調(diào)用 netif_tx_start_all_queues 開啟隊列。另外，對于硬中斷的處理函數(shù) igb_msix_ring 其實也是在 __igb_open 中注冊的。

三、accept 創(chuàng)建新 socket

在發(fā)送數(shù)據(jù)之前，我們往往還需要一個已經(jīng)建立好連接的 socket。

我們就以開篇服務(wù)器縮微源代碼中提到的 accept 為例，當(dāng) accept 之后，進(jìn)程會創(chuàng)建一個新的 socket 出來，然后把它放到當(dāng)前進(jìn)程的打開文件列表中，專門用于和對應(yīng)的客戶端通信。

假設(shè)服務(wù)器進(jìn)程通過 accept 和客戶端建立了兩條連接，我們來簡單看一下這兩條連接和進(jìn)程的關(guān)聯(lián)關(guān)系。

其中代表一條連接的 socket 內(nèi)核對象更為具體一點的結(jié)構(gòu)圖如下。

為了避免喧賓奪主，accept 詳細(xì)的源碼過程這里就不介紹了，感興趣請參考?《圖解 | 深入揭秘 epoll 是如何實現(xiàn) IO 多路復(fù)用的！》。一文中的第一部分。

今天我們還是把重點放到數(shù)據(jù)發(fā)送過程上。

四、發(fā)送數(shù)據(jù)真正開始

4.1 send 系統(tǒng)調(diào)用實現(xiàn)

send 系統(tǒng)調(diào)用的源碼位于文件 net/socket.c 中。在這個系統(tǒng)調(diào)用里，內(nèi)部其實真正使用的是 sendto 系統(tǒng)調(diào)用。整個調(diào)用鏈條雖然不短，但其實主要只干了兩件簡單的事情，

• 第一是在內(nèi)核中把真正的 socket 找出來，在這個對象里記錄著各種協(xié)議棧的函數(shù)地址。

• 第二是構(gòu)造一個 struct msghdr 對象，把用戶傳入的數(shù)據(jù)，比如 buffer地址、數(shù)據(jù)長度啥的，統(tǒng)統(tǒng)都裝進(jìn)去.

剩下的事情就交給下一層，協(xié)議棧里的函數(shù) inet_sendmsg 了，其中 inet_sendmsg 函數(shù)的地址是通過 socket 內(nèi)核對象里的 ops 成員找到的。大致流程如圖。

有了上面的了解，我們再看起源碼就要容易許多了。源碼如下：

//file:?net/socket.c SYSCALL_DEFINE4(send,?int,?fd,?void?__user?*,?buff,?size_t,?len,unsigned?int,?flags) {return?sys_sendto(fd,?buff,?len,?flags,?NULL,?0); }SYSCALL_DEFINE6(......) {//1.根據(jù)?fd?查找到?socketsock?=?sockfd_lookup_light(fd,?&err,?&fput_needed);//2.構(gòu)造?msghdrstruct?msghdr?msg;struct?iovec?iov;iov.iov_base?=?buff;iov.iov_len?=?len;msg.msg_iovlen?=?1;msg.msg_iov?=?&iov;msg.msg_flags?=?flags;......//3.發(fā)送數(shù)據(jù)sock_sendmsg(sock,?&msg,?len); }

從源碼可以看到，我們在用戶態(tài)使用的 send 函數(shù)和 sendto 函數(shù)其實都是 sendto 系統(tǒng)調(diào)用實現(xiàn)的。send 只是為了方便，封裝出來的一個更易于調(diào)用的方式而已。

在 sendto 系統(tǒng)調(diào)用里，首先根據(jù)用戶傳進(jìn)來的 socket 句柄號來查找真正的 socket 內(nèi)核對象。接著把用戶請求的 buff、len、flag 等參數(shù)都統(tǒng)統(tǒng)打包到一個 struct msghdr 對象中。

接著調(diào)用了 sock_sendmsg => __sock_sendmsg ==> ?__sock_sendmsg_nosec。在__sock_sendmsg_nosec 中，調(diào)用將會由系統(tǒng)調(diào)用進(jìn)入到協(xié)議棧，我們來看它的源碼。

//file:?net/socket.c static?inline?int?__sock_sendmsg_nosec(...) {......return?sock->ops->sendmsg(iocb,?sock,?msg,?size); }

通過第三節(jié)里的 socket 內(nèi)核對象結(jié)構(gòu)圖，我們可以看到，這里調(diào)用的是 sock->ops->sendmsg 實際執(zhí)行的是 inet_sendmsg。這個函數(shù)是 AF_INET 協(xié)議族提供的通用發(fā)送函數(shù)。

4.2 傳輸層處理

1）傳輸層拷貝

在進(jìn)入到協(xié)議棧 inet_sendmsg 以后，內(nèi)核接著會找到 socket 上的具體協(xié)議發(fā)送函數(shù)。對于 TCP 協(xié)議來說，那就是 tcp_sendmsg（同樣也是通過 socket 內(nèi)核對象找到的）。

在這個函數(shù)中，內(nèi)核會申請一個內(nèi)核態(tài)的 skb 內(nèi)存，將用戶待發(fā)送的數(shù)據(jù)拷貝進(jìn)去。注意這個時候不一定會真正開始發(fā)送，如果沒有達(dá)到發(fā)送條件的話很可能這次調(diào)用直接就返回了。大概過程如圖：

我們來看 inet_sendmsg 函數(shù)的源碼。

//file:?net/ipv4/af_inet.c int?inet_sendmsg(......) {......return?sk->sk_prot->sendmsg(iocb,?sk,?msg,?size); }

在這個函數(shù)中會調(diào)用到具體協(xié)議的發(fā)送函數(shù)。同樣參考第三節(jié)里的 socket 內(nèi)核對象結(jié)構(gòu)圖，我們看到對于 TCP 協(xié)議下的 socket 來說，來說 sk->sk_prot->sendmsg 指向的是 tcp_sendmsg（對于 UPD 來說是 udp_sendmsg）。

tcp_sendmsg 這個函數(shù)比較長，我們分多次來看它。先看這一段

//file:?net/ipv4/tcp.c int?tcp_sendmsg(...) {while(...){while(...){//獲取發(fā)送隊列skb?=?tcp_write_queue_tail(sk);//申請skb?并拷貝......}} } //file:?include/net/tcp.h static?inline?struct?sk_buff?*tcp_write_queue_tail(const?struct?sock?*sk) {return?skb_peek_tail(&sk->sk_write_queue); }

理解對 socket 調(diào)用 tcp_write_queue_tail 是理解發(fā)送的前提。如上所示，這個函數(shù)是在獲取 socket 發(fā)送隊列中的最后一個 skb。skb 是 struct sk_buff 對象的簡稱，用戶的發(fā)送隊列就是該對象組成的一個鏈表。

我們再接著看 tcp_sendmsg 的其它部分。

//file:?net/ipv4/tcp.c int?tcp_sendmsg(struct?kiocb?*iocb,?struct?sock?*sk,?struct?msghdr?*msg,size_t?size) {//獲取用戶傳遞過來的數(shù)據(jù)和標(biāo)志iov?=?msg->msg_iov;?//用戶數(shù)據(jù)地址iovlen?=?msg->msg_iovlen;?//數(shù)據(jù)塊數(shù)為1flags?=?msg->msg_flags;?//各種標(biāo)志//遍歷用戶層的數(shù)據(jù)塊while?(--iovlen?>=?0)?{//待發(fā)送數(shù)據(jù)塊的地址unsigned?char?__user?*from?=?iov->iov_base;while?(seglen?>?0)?{//需要申請新的?skbif?(copy?<=?0)?{//申請?skb，并添加到發(fā)送隊列的尾部skb?=?sk_stream_alloc_skb(sk,select_size(sk,?sg),sk->sk_allocation);//把?skb?掛到socket的發(fā)送隊列上skb_entail(sk,?skb);}//?skb?中有足夠的空間if?(skb_availroom(skb)?>?0)?{//拷貝用戶空間的數(shù)據(jù)到內(nèi)核空間，同時計算校驗和//from是用戶空間的數(shù)據(jù)地址?skb_add_data_nocache(sk,?skb,?from,?copy);}?......

這個函數(shù)比較長，不過其實邏輯并不復(fù)雜。其中 msg->msg_iov 存儲的是用戶態(tài)內(nèi)存的要發(fā)送的數(shù)據(jù)的 buffer。接下來在內(nèi)核態(tài)申請內(nèi)核內(nèi)存，比如 skb，并把用戶內(nèi)存里的數(shù)據(jù)拷貝到內(nèi)核態(tài)內(nèi)存中。這就會涉及到一次或者幾次內(nèi)存拷貝的開銷。

至于內(nèi)核什么時候真正把 skb 發(fā)送出去。在 tcp_sendmsg 中會進(jìn)行一些判斷。

//file:?net/ipv4/tcp.c int?tcp_sendmsg(...) {while(...){while(...){//申請內(nèi)核內(nèi)存并進(jìn)行拷貝//發(fā)送判斷if?(forced_push(tp))?{tcp_mark_push(tp,?skb);__tcp_push_pending_frames(sk,?mss_now,?TCP_NAGLE_PUSH);}?else?if?(skb?==?tcp_send_head(sk))tcp_push_one(sk,?mss_now);??}continue;}} }

只有滿足 forced_push(tp) 或者 skb == tcp_send_head(sk) 成立的時候，內(nèi)核才會真正啟動發(fā)送數(shù)據(jù)包。其中 forced_push(tp) 判斷的是未發(fā)送的數(shù)據(jù)數(shù)據(jù)是否已經(jīng)超過最大窗口的一半了。

條件都不滿足的話，這次的用戶要發(fā)送的數(shù)據(jù)只是拷貝到內(nèi)核就算完事了！

2）傳輸層發(fā)送

假設(shè)現(xiàn)在內(nèi)核發(fā)送條件已經(jīng)滿足了，我們再來跟蹤一下實際的發(fā)送過程。對于上小節(jié)函數(shù)中，當(dāng)滿足真正發(fā)送條件的時候，無論調(diào)用的是 __tcp_push_pending_frames 還是 tcp_push_one 最終都實際會執(zhí)行到 tcp_write_xmit。

所以我們直接從 tcp_write_xmit 看起，這個函數(shù)處理了傳輸層的擁塞控制、滑動窗口相關(guān)的工作。滿足窗口要求的時候，設(shè)置一下 TCP 頭然后將 skb 傳到更低的網(wǎng)絡(luò)層進(jìn)行處理。

我們來看下 tcp_write_xmit 的源碼。

//file:?net/ipv4/tcp_output.c static?bool?tcp_write_xmit(struct?sock?*sk,?unsigned?int?mss_now,?int?nonagle,int?push_one,?gfp_t?gfp) {//循環(huán)獲取待發(fā)送?skbwhile?((skb?=?tcp_send_head(sk)))?{//滑動窗口相關(guān)cwnd_quota?=?tcp_cwnd_test(tp,?skb);tcp_snd_wnd_test(tp,?skb,?mss_now);tcp_mss_split_point(...);tso_fragment(sk,?skb,?...);......//真正開啟發(fā)送tcp_transmit_skb(sk,?skb,?1,?gfp);} }

可以看到我們之前在網(wǎng)絡(luò)協(xié)議里學(xué)的滑動窗口、擁塞控制就是在這個函數(shù)中完成的，這部分就不過多展開了，感興趣同學(xué)自己找這段源碼來讀。我們今天只看發(fā)送主過程，那就走到了 tcp_transmit_skb。

//file:?net/ipv4/tcp_output.c static?int?tcp_transmit_skb(struct?sock?*sk,?struct?sk_buff?*skb,?int?clone_it,gfp_t?gfp_mask) {//1.克隆新?skb?出來if?(likely(clone_it))?{skb?=?skb_clone(skb,?gfp_mask);......}//2.封裝?TCP?頭th?=?tcp_hdr(skb);th->source??=?inet->inet_sport;th->dest??=?inet->inet_dport;th->window??=?...;th->urg???=?...;......//3.調(diào)用網(wǎng)絡(luò)層發(fā)送接口err?=?icsk->icsk_af_ops->queue_xmit(skb,?&inet->cork.fl); }

第一件事是先克隆一個新的 skb，這里重點說下為什么要復(fù)制一個 skb 出來呢？

是因為 skb 后續(xù)在調(diào)用網(wǎng)絡(luò)層，最后到達(dá)網(wǎng)卡發(fā)送完成的時候，這個 skb 會被釋放掉。而我們知道 TCP 協(xié)議是支持丟失重傳的，在收到對方的 ACK 之前，這個 skb 不能被刪除。所以內(nèi)核的做法就是每次調(diào)用網(wǎng)卡發(fā)送的時候，實際上傳遞出去的是 skb 的一個拷貝。等收到 ACK 再真正刪除。

第二件事是修改 skb 中的 TCP header，根據(jù)實際情況把 TCP 頭設(shè)置好。這里要介紹一個小技巧，skb 內(nèi)部其實包含了網(wǎng)絡(luò)協(xié)議中所有的 header。在設(shè)置 TCP 頭的時候，只是把指針指向 skb 的合適位置。后面再設(shè)置 IP 頭的時候，在把指針挪一挪就行，避免頻繁的內(nèi)存申請和拷貝，效率很高。

tcp_transmit_skb 是發(fā)送數(shù)據(jù)位于傳輸層的最后一步，接下來就可以進(jìn)入到網(wǎng)絡(luò)層進(jìn)行下一層的操作了。調(diào)用了網(wǎng)絡(luò)層提供的發(fā)送接口icsk->icsk_af_ops->queue_xmit()。

在下面的這個源碼中，我們的知道了 queue_xmit 其實指向的是 ip_queue_xmit 函數(shù)。

//file:?net/ipv4/tcp_ipv4.c const?struct?inet_connection_sock_af_ops?ipv4_specific?=?{.queue_xmit????=?ip_queue_xmit,.send_check????=?tcp_v4_send_check,... }

自此，傳輸層的工作也就都完成了。數(shù)據(jù)離開了傳輸層，接下來將會進(jìn)入到內(nèi)核在網(wǎng)絡(luò)層的實現(xiàn)里。

4.3 網(wǎng)絡(luò)層發(fā)送處理

Linux 內(nèi)核網(wǎng)絡(luò)層的發(fā)送的實現(xiàn)位于 net/ipv4/ip_output.c 這個文件。傳輸層調(diào)用到的 ip_queue_xmit 也在這里。（從文件名上也能看出來進(jìn)入到 IP 層了，源文件名已經(jīng)從 tcp_xxx 變成了 ip_xxx。）

在網(wǎng)絡(luò)層里主要處理路由項查找、IP 頭設(shè)置、netfilter 過濾、skb 切分（大于 MTU 的話）等幾項工作，處理完這些工作后會交給更下層的鄰居子系統(tǒng)來處理。

我們來看網(wǎng)絡(luò)層入口函數(shù) ip_queue_xmit 的源碼：

//file:?net/ipv4/ip_output.c int?ip_queue_xmit(struct?sk_buff?*skb,?struct?flowi?*fl) {//檢查?socket?中是否有緩存的路由表rt?=?(struct?rtable?*)__sk_dst_check(sk,?0);if?(rt?==?NULL)?{//沒有緩存則展開查找//則查找路由項，?并緩存到?socket?中rt?=?ip_route_output_ports(...);sk_setup_caps(sk,?&rt->dst);}//為?skb?設(shè)置路由表skb_dst_set_noref(skb,?&rt->dst);//設(shè)置?IP?headeriph?=?ip_hdr(skb);iph->protocol?=?sk->sk_protocol;iph->ttl??????=?ip_select_ttl(inet,?&rt->dst);iph->frag_off?=?...;//發(fā)送ip_local_out(skb); }

ip_queue_xmit 已經(jīng)到了網(wǎng)絡(luò)層，在這個函數(shù)里我們看到了網(wǎng)絡(luò)層相關(guān)的功能路由項查找，如果找到了則設(shè)置到 skb 上（沒有路由的話就直接報錯返回了）。

在 Linux 上通過 route 命令可以看到你本機的路由配置。

在路由表中，可以查到某個目的網(wǎng)絡(luò)應(yīng)該通過哪個 Iface（網(wǎng)卡），哪個 Gateway（網(wǎng)卡）發(fā)送出去。查找出來以后緩存到 socket 上，下次再發(fā)送數(shù)據(jù)就不用查了。

接著把路由表地址也放到 skb 里去。

//file:?include/linux/skbuff.h struct?sk_buff?{//保存了一些路由相關(guān)信息unsigned?long??_skb_refdst; }

接下來就是定位到 skb 里的 IP 頭的位置上，然后開始按照協(xié)議規(guī)范設(shè)置 IP header。

再通過 ip_local_out 進(jìn)入到下一步的處理。

//file:?net/ipv4/ip_output.c?? int?ip_local_out(struct?sk_buff?*skb) {//執(zhí)行?netfilter?過濾err?=?__ip_local_out(skb);//開始發(fā)送數(shù)據(jù)if?(likely(err?==?1))err?=?dst_output(skb);......

在 ip_local_out => __ip_local_out => nf_hook 會執(zhí)行 netfilter 過濾。如果你使用 iptables 配置了一些規(guī)則，那么這里將檢測是否命中規(guī)則。如果你設(shè)置了非常復(fù)雜的 netfilter 規(guī)則，在這個函數(shù)這里將會導(dǎo)致你的進(jìn)程 CPU 開銷會極大增加。

還是不多展開說，繼續(xù)只聊和發(fā)送有關(guān)的過程 dst_output。

//file:?include/net/dst.h static?inline?int?dst_output(struct?sk_buff?*skb) {return?skb_dst(skb)->output(skb); }

此函數(shù)找到到這個 skb 的路由表（dst 條目） ，然后調(diào)用路由表的 output 方法。這又是一個函數(shù)指針，指向的是 ip_output 方法。

//file:?net/ipv4/ip_output.c int?ip_output(struct?sk_buff?*skb) {//統(tǒng)計.....//再次交給?netfilter，完畢后回調(diào)?ip_finish_outputreturn?NF_HOOK_COND(NFPROTO_IPV4,?NF_INET_POST_ROUTING,?skb,?NULL,?dev,ip_finish_output,!(IPCB(skb)->flags?&?IPSKB_REROUTED)); }

在 ip_output 中進(jìn)行一些簡單的，統(tǒng)計工作，再次執(zhí)行 netfilter 過濾。過濾通過之后回調(diào) ip_finish_output。

//file:?net/ipv4/ip_output.c static?int?ip_finish_output(struct?sk_buff?*skb) {//大于?mtu?的話就要進(jìn)行分片了if?(skb->len?>?ip_skb_dst_mtu(skb)?&&?!skb_is_gso(skb))return?ip_fragment(skb,?ip_finish_output2);elsereturn?ip_finish_output2(skb); }

在 ip_finish_output 中我們看到，如果數(shù)據(jù)大于 MTU 的話，是會執(zhí)行分片的。

實際 MTU 大小確定依賴 MTU 發(fā)現(xiàn)，以太網(wǎng)幀為 1500 字節(jié)。之前 QQ 團(tuán)隊在早期的時候，會盡量控制自己數(shù)據(jù)包尺寸小于 MTU，通過這種方式來優(yōu)化網(wǎng)絡(luò)性能。因為分片會帶來兩個問題：1、需要進(jìn)行額外的切分處理，有額外性能開銷。2、只要一個分片丟失，整個包都得重傳。所以避免分片既杜絕了分片開銷，也大大降低了重傳率。

在 ip_finish_output2 中，終于發(fā)送過程會進(jìn)入到下一層，鄰居子系統(tǒng)中。

//file:?net/ipv4/ip_output.c static?inline?int?ip_finish_output2(struct?sk_buff?*skb) {//根據(jù)下一跳 IP 地址查找鄰居項，找不到就創(chuàng)建一個nexthop?=?(__force?u32)?rt_nexthop(rt,?ip_hdr(skb)->daddr);??neigh?=?__ipv4_neigh_lookup_noref(dev,?nexthop);if?(unlikely(!neigh))neigh?=?__neigh_create(&arp_tbl,?&nexthop,?dev,?false);//繼續(xù)向下層傳遞int?res?=?dst_neigh_output(dst,?neigh,?skb); }

4.4 鄰居子系統(tǒng)

鄰居子系統(tǒng)是位于網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層中間的一個系統(tǒng)，其作用是對網(wǎng)絡(luò)層提供一個封裝，讓網(wǎng)絡(luò)層不必關(guān)心下層的地址信息，讓下層來決定發(fā)送到哪個 MAC 地址。

而且這個鄰居子系統(tǒng)并不位于協(xié)議棧 net/ipv4/ 目錄內(nèi)，而是位于 net/core/neighbour.c。因為無論是對于 IPv4 還是 IPv6 ，都需要使用該模塊。

在鄰居子系統(tǒng)里主要是查找或者創(chuàng)建鄰居項，在創(chuàng)造鄰居項的時候，有可能會發(fā)出實際的 arp 請求。然后封裝一下 MAC 頭，將發(fā)送過程再傳遞到更下層的網(wǎng)絡(luò)設(shè)備子系統(tǒng)。大致流程如圖。

理解了大致流程，我們再回頭看源碼。在上面小節(jié) ip_finish_output2 源碼中調(diào)用了 __ipv4_neigh_lookup_noref。它是在 arp 緩存中進(jìn)行查找，其第二個參數(shù)傳入的是路由下一跳 IP 信息。

//file:?include/net/arp.h extern?struct?neigh_table?arp_tbl; static?inline?struct?neighbour?*__ipv4_neigh_lookup_noref(struct?net_device?*dev,?u32?key) {struct?neigh_hash_table?*nht?=?rcu_dereference_bh(arp_tbl.nht);//計算?hash?值，加速查找hash_val?=?arp_hashfn(......);for?(n?=?rcu_dereference_bh(nht->hash_buckets[hash_val]);n?!=?NULL;n?=?rcu_dereference_bh(n->next))?{if?(n->dev?==?dev?&&?*(u32?*)n->primary_key?==?key)return?n;} }

如果查找不到，則調(diào)用 __neigh_create 創(chuàng)建一個鄰居。

//file:?net/core/neighbour.c struct?neighbour?*__neigh_create(......) {//申請鄰居表項struct?neighbour?*n1,?*rc,?*n?=?neigh_alloc(tbl,?dev);//構(gòu)造賦值memcpy(n->primary_key,?pkey,?key_len);n->dev?=?dev;n->parms->neigh_setup(n);//最后添加到鄰居?hashtable?中rcu_assign_pointer(nht->hash_buckets[hash_val],?n);......

有了鄰居項以后，此時仍然還不具備發(fā)送 IP 報文的能力，因為目的 MAC 地址還未獲取。調(diào)用 dst_neigh_output 繼續(xù)傳遞 skb。

//file:?include/net/dst.h static?inline?int?dst_neigh_output(struct?dst_entry?*dst,?struct?neighbour?*n,?struct?sk_buff?*skb) {......return?n->output(n,?skb); }

調(diào)用 output，實際指向的是 neigh_resolve_output。在這個函數(shù)內(nèi)部有可能會發(fā)出 arp 網(wǎng)絡(luò)請求。

//file:?net/core/neighbour.c int?neigh_resolve_output(){//注意：這里可能會觸發(fā) arp 請求if?(!neigh_event_send(neigh,?skb))?{//neigh->ha?是?MAC?地址dev_hard_header(skb,?dev,?ntohs(skb->protocol),neigh->ha,?NULL,?skb->len);//發(fā)送dev_queue_xmit(skb);} }

當(dāng)獲取到硬件 MAC 地址以后，就可以封裝 skb 的 MAC 頭了。最后調(diào)用 dev_queue_xmit 將 skb 傳遞給 Linux 網(wǎng)絡(luò)設(shè)備子系統(tǒng)。

4.5 網(wǎng)絡(luò)設(shè)備子系統(tǒng)

鄰居子系統(tǒng)通過 dev_queue_xmit 進(jìn)入到網(wǎng)絡(luò)設(shè)備子系統(tǒng)中來。

//file:?net/core/dev.c? int?dev_queue_xmit(struct?sk_buff?*skb) {//選擇發(fā)送隊列txq?=?netdev_pick_tx(dev,?skb);//獲取與此隊列關(guān)聯(lián)的排隊規(guī)則q?=?rcu_dereference_bh(txq->qdisc);//如果有隊列，則調(diào)用__dev_xmit_skb?繼續(xù)處理數(shù)據(jù)if?(q->enqueue)?{rc?=?__dev_xmit_skb(skb,?q,?dev,?txq);goto?out;}//沒有隊列的是回環(huán)設(shè)備和隧道設(shè)備...... }

開篇第二節(jié)網(wǎng)卡啟動準(zhǔn)備里我們說過，網(wǎng)卡是有多個發(fā)送隊列的（尤其是現(xiàn)在的網(wǎng)卡）。上面對 netdev_pick_tx 函數(shù)的調(diào)用就是選擇一個隊列進(jìn)行發(fā)送。

netdev_pick_tx 發(fā)送隊列的選擇受 XPS 等配置的影響，而且還有緩存，也是一套小復(fù)雜的邏輯。這里我們只關(guān)注兩個邏輯，首先會獲取用戶的 XPS 配置，否則就自動計算了。代碼見 netdev_pick_tx => __netdev_pick_tx。

//file:?net/core/flow_dissector.c u16?__netdev_pick_tx(struct?net_device?*dev,?struct?sk_buff?*skb) {//獲取?XPS?配置int?new_index?=?get_xps_queue(dev,?skb);//自動計算隊列if?(new_index?<?0)new_index?=?skb_tx_hash(dev,?skb);}

然后獲取與此隊列關(guān)聯(lián)的 qdisc。在 linux 上通過 tc 命令可以看到 qdisc 類型，例如對于我的某臺多隊列網(wǎng)卡機器上是 mq disc。

#tc?qdisc qdisc?mq?0:?dev?eth0?root

大部分的設(shè)備都有隊列（回環(huán)設(shè)備和隧道設(shè)備除外），所以現(xiàn)在我們進(jìn)入到 __dev_xmit_skb。

//file:?net/core/dev.c static?inline?int?__dev_xmit_skb(struct?sk_buff?*skb,?struct?Qdisc?*q,struct?net_device?*dev,struct?netdev_queue?*txq) {//1.如果可以繞開排隊系統(tǒng)if?((q->flags?&?TCQ_F_CAN_BYPASS)?&&?!qdisc_qlen(q)?&&qdisc_run_begin(q))?{......}//2.正常排隊else?{//入隊q->enqueue(skb,?q)//開始發(fā)送__qdisc_run(q);} }

上述代碼中分兩種情況，1 是可以 bypass（繞過）排隊系統(tǒng)的，另外一種是正常排隊。我們只看第二種情況。

先調(diào)用 q->enqueue 把 skb 添加到隊列里。然后調(diào)用 __qdisc_run 開始發(fā)送。

//file:?net/sched/sch_generic.c void?__qdisc_run(struct?Qdisc?*q) {int?quota?=?weight_p;//循環(huán)從隊列取出一個?skb?并發(fā)送while?(qdisc_restart(q))?{//?如果發(fā)生下面情況之一，則延后處理：//?1.?quota?用盡//?2.?其他進(jìn)程需要?CPUif?(--quota?<=?0?||?need_resched())?{//將觸發(fā)一次?NET_TX_SOFTIRQ?類型?softirq__netif_schedule(q);break;}} }

在上述代碼中，我們看到 while 循環(huán)不斷地從隊列中取出 skb 并進(jìn)行發(fā)送。注意，這個時候其實都占用的是用戶進(jìn)程的系統(tǒng)態(tài)時間(sy)。只有當(dāng) quota 用盡或者其它進(jìn)程需要 CPU 的時候才觸發(fā)軟中斷進(jìn)行發(fā)送。

所以這就是為什么一般服務(wù)器上查看 /proc/softirqs，一般 NET_RX 都要比 NET_TX 大的多的第二個原因。對于讀來說，都是要經(jīng)過 NET_RX 軟中斷，而對于發(fā)送來說，只有系統(tǒng)態(tài)配額用盡才讓軟中斷上。

我們來把精力在放到 qdisc_restart 上，繼續(xù)看發(fā)送過程。

static?inline?int?qdisc_restart(struct?Qdisc?*q) {//從?qdisc?中取出要發(fā)送的?skbskb?=?dequeue_skb(q);...return?sch_direct_xmit(skb,?q,?dev,?txq,?root_lock); }

qdisc_restart 從隊列中取出一個 skb，并調(diào)用 sch_direct_xmit 繼續(xù)發(fā)送。

//file:?net/sched/sch_generic.c int?sch_direct_xmit(struct?sk_buff?*skb,?struct?Qdisc?*q,struct?net_device?*dev,?struct?netdev_queue?*txq,spinlock_t?*root_lock) {//調(diào)用驅(qū)動程序來發(fā)送數(shù)據(jù)ret?=?dev_hard_start_xmit(skb,?dev,?txq); }

4.6 軟中斷調(diào)度

在 4.5 咱們看到了如果系統(tǒng)態(tài) CPU 發(fā)送網(wǎng)絡(luò)包不夠用的時候，會調(diào)用 __netif_schedule 觸發(fā)一個軟中斷。該函數(shù)會進(jìn)入到 __netif_reschedule，由它來實際發(fā)出 NET_TX_SOFTIRQ 類型軟中斷。

軟中斷是由內(nèi)核線程來運行的，該線程會進(jìn)入到 net_tx_action 函數(shù)，在該函數(shù)中能獲取到發(fā)送隊列，并也最終調(diào)用到驅(qū)動程序里的入口函數(shù) dev_hard_start_xmit。

//file:?net/core/dev.c static?inline?void?__netif_reschedule(struct?Qdisc?*q) {sd?=?&__get_cpu_var(softnet_data);q->next_sched?=?NULL;*sd->output_queue_tailp?=?q;sd->output_queue_tailp?=?&q->next_sched;......raise_softirq_irqoff(NET_TX_SOFTIRQ); }

在該函數(shù)里在軟中斷能訪問到的 softnet_data 里設(shè)置了要發(fā)送的數(shù)據(jù)隊列，添加到了 output_queue 里了。緊接著觸發(fā)了 NET_TX_SOFTIRQ 類型的軟中斷。（T 代表 transmit 傳輸）

軟中斷的入口代碼我這里也不詳細(xì)扒了，感興趣的同學(xué)參考《圖解Linux網(wǎng)絡(luò)包接收過程》一文中的 3.2 小節(jié) - ksoftirqd內(nèi)核線程處理軟中斷。

我們直接從 NET_TX_SOFTIRQ softirq 注冊的回調(diào)函數(shù) net_tx_action講起。用戶態(tài)進(jìn)程觸發(fā)完軟中斷之后，會有一個軟中斷內(nèi)核線程會執(zhí)行到 net_tx_action。

牢記，這以后發(fā)送數(shù)據(jù)消耗的 CPU 就都顯示在 si 這里了，不會消耗用戶進(jìn)程的系統(tǒng)時間了。

//file:?net/core/dev.c static?void?net_tx_action(struct?softirq_action?*h) {//通過?softnet_data?獲取發(fā)送隊列struct?softnet_data?*sd?=?&__get_cpu_var(softnet_data);//?如果?output?queue?上有?qdiscif?(sd->output_queue)?{//?將?head?指向第一個?qdischead?=?sd->output_queue;//遍歷?qdsics?列表while?(head)?{struct?Qdisc?*q?=?head;head?=?head->next_sched;//發(fā)送數(shù)據(jù)qdisc_run(q);}} }

軟中斷這里會獲取 softnet_data。前面我們看到進(jìn)程內(nèi)核態(tài)在調(diào)用 __netif_reschedule 的時候把發(fā)送隊列寫到 softnet_data 的 output_queue 里了。軟中斷循環(huán)遍歷 sd->output_queue 發(fā)送數(shù)據(jù)幀。

來看 qdisc_run，它和進(jìn)程用戶態(tài)一樣，也會調(diào)用到 __qdisc_run。

//file:?include/net/pkt_sched.h static?inline?void?qdisc_run(struct?Qdisc?*q) {if?(qdisc_run_begin(q))__qdisc_run(q); }

然后一樣就是進(jìn)入 qdisc_restart => sch_direct_xmit，直到驅(qū)動程序函數(shù) dev_hard_start_xmit。

4.7 igb 網(wǎng)卡驅(qū)動發(fā)送

我們前面看到，無論是對于用戶進(jìn)程的內(nèi)核態(tài)，還是對于軟中斷上下文，都會調(diào)用到網(wǎng)絡(luò)設(shè)備子系統(tǒng)中的 dev_hard_start_xmit 函數(shù)。在這個函數(shù)中，會調(diào)用到驅(qū)動里的發(fā)送函數(shù) igb_xmit_frame。

在驅(qū)動函數(shù)里，將 skb 會掛到 RingBuffer上，驅(qū)動調(diào)用完畢后，數(shù)據(jù)包將真正從網(wǎng)卡發(fā)送出去。

我們來看看實際的源碼：

//file:?net/core/dev.c int?dev_hard_start_xmit(struct?sk_buff?*skb,?struct?net_device?*dev,struct?netdev_queue?*txq) {//獲取設(shè)備的回調(diào)函數(shù)集合?opsconst?struct?net_device_ops?*ops?=?dev->netdev_ops;//獲取設(shè)備支持的功能列表features?=?netif_skb_features(skb);//調(diào)用驅(qū)動的?ops?里面的發(fā)送回調(diào)函數(shù)?ndo_start_xmit?將數(shù)據(jù)包傳給網(wǎng)卡設(shè)備skb_len?=?skb->len;rc?=?ops->ndo_start_xmit(skb,?dev); }

其中 ndo_start_xmit 是網(wǎng)卡驅(qū)動要實現(xiàn)的一個函數(shù)，是在 net_device_ops 中定義的。

//file:?include/linux/netdevice.h struct?net_device_ops?{netdev_tx_t??(*ndo_start_xmit)?(struct?sk_buff?*skb,struct?net_device?*dev);}

在 igb 網(wǎng)卡驅(qū)動源碼中，我們找到了。

//file:?drivers/net/ethernet/intel/igb/igb_main.c static?const?struct?net_device_ops?igb_netdev_ops?=?{.ndo_open??=?igb_open,.ndo_stop??=?igb_close,.ndo_start_xmit??=?igb_xmit_frame,?... };

也就是說，對于網(wǎng)絡(luò)設(shè)備層定義的 ndo_start_xmit， igb 的實現(xiàn)函數(shù)是 igb_xmit_frame。這個函數(shù)是在網(wǎng)卡驅(qū)動初始化的時候被賦值的。具體初始化過程參見《圖解Linux網(wǎng)絡(luò)包接收過程》一文中的 2.4 節(jié)，網(wǎng)卡驅(qū)動初始化。

所以在上面網(wǎng)絡(luò)設(shè)備層調(diào)用 ops->ndo_start_xmit 的時候，會實際上進(jìn)入 igb_xmit_frame 這個函數(shù)中。我們進(jìn)入這個函數(shù)來看看驅(qū)動程序是如何工作的。

//file:?drivers/net/ethernet/intel/igb/igb_main.c static?netdev_tx_t?igb_xmit_frame(struct?sk_buff?*skb,struct?net_device?*netdev) {......return?igb_xmit_frame_ring(skb,?igb_tx_queue_mapping(adapter,?skb)); }netdev_tx_t?igb_xmit_frame_ring(struct?sk_buff?*skb,struct?igb_ring?*tx_ring) {//獲取TX?Queue?中下一個可用緩沖區(qū)信息first?=?&tx_ring->tx_buffer_info[tx_ring->next_to_use];first->skb?=?skb;first->bytecount?=?skb->len;first->gso_segs?=?1;//igb_tx_map 函數(shù)準(zhǔn)備給設(shè)備發(fā)送的數(shù)據(jù)。igb_tx_map(tx_ring,?first,?hdr_len); }

在這里從網(wǎng)卡的發(fā)送隊列的 RingBuffer 中取下來一個元素，并將 skb 掛到元素上。

igb_tx_map 函數(shù)處理將 skb 數(shù)據(jù)映射到網(wǎng)卡可訪問的內(nèi)存 DMA 區(qū)域。

//file:?drivers/net/ethernet/intel/igb/igb_main.c static?void?igb_tx_map(struct?igb_ring?*tx_ring,struct?igb_tx_buffer?*first,const?u8?hdr_len) {//獲取下一個可用描述符指針tx_desc?=?IGB_TX_DESC(tx_ring,?i);//為?skb->data?構(gòu)造內(nèi)存映射，以允許設(shè)備通過?DMA?從?RAM?中讀取數(shù)據(jù)dma?=?dma_map_single(tx_ring->dev,?skb->data,?size,?DMA_TO_DEVICE);//遍歷該數(shù)據(jù)包的所有分片,為?skb?的每個分片生成有效映射for?(frag?=?&skb_shinfo(skb)->frags[0];;?frag++)?{tx_desc->read.buffer_addr?=?cpu_to_le64(dma);tx_desc->read.cmd_type_len?=?...;tx_desc->read.olinfo_status?=?0;}//設(shè)置最后一個descriptorcmd_type?|=?size?|?IGB_TXD_DCMD;tx_desc->read.cmd_type_len?=?cpu_to_le32(cmd_type);/*?Force?memory?writes?to?complete?before?letting?h/w?know?there*?are?new?descriptors?to?fetch*/wmb(); }

當(dāng)所有需要的描述符都已建好，且 skb 的所有數(shù)據(jù)都映射到 DMA 地址后，驅(qū)動就會進(jìn)入到它的最后一步，觸發(fā)真實的發(fā)送。

4.8 發(fā)送完成硬中斷

當(dāng)數(shù)據(jù)發(fā)送完成以后，其實工作并沒有結(jié)束。因為內(nèi)存還沒有清理。當(dāng)發(fā)送完成的時候，網(wǎng)卡設(shè)備會觸發(fā)一個硬中斷來釋放內(nèi)存。

在《圖解Linux網(wǎng)絡(luò)包接收過程》?一文中的 3.1 和 3.2 小節(jié)，我們詳細(xì)講述過硬中斷和軟中斷的處理過程。

在發(fā)送完成硬中斷里，會執(zhí)行 RingBuffer 內(nèi)存的清理工作，如圖。

再回頭看一下硬中斷觸發(fā)軟中斷的源碼。

//file:?drivers/net/ethernet/intel/igb/igb_main.c static?inline?void?____napi_schedule(...){list_add_tail(&napi->poll_list,?&sd->poll_list);__raise_softirq_irqoff(NET_RX_SOFTIRQ); }

這里有個很有意思的細(xì)節(jié)，無論硬中斷是因為是有數(shù)據(jù)要接收，還是說發(fā)送完成通知，從硬中斷觸發(fā)的軟中斷都是 NET_RX_SOFTIRQ。這個我們在第一節(jié)說過了，這是軟中斷統(tǒng)計中 RX 要高于 TX 的一個原因。

好我們接著進(jìn)入軟中斷的回調(diào)函數(shù) igb_poll。在這個函數(shù)里，我們注意到有一行 igb_clean_tx_irq，參見源碼：

//file:?drivers/net/ethernet/intel/igb/igb_main.c static?int?igb_poll(struct?napi_struct?*napi,?int?budget) {//performs?the?transmit?completion?operationsif?(q_vector->tx.ring)clean_complete?=?igb_clean_tx_irq(q_vector);... }

我們來看看當(dāng)傳輸完成的時候，igb_clean_tx_irq 都干啥了。

//file:?drivers/net/ethernet/intel/igb/igb_main.c static?bool?igb_clean_tx_irq(struct?igb_q_vector?*q_vector) {//free?the?skbdev_kfree_skb_any(tx_buffer->skb);//clear?tx_buffer?datatx_buffer->skb?=?NULL;dma_unmap_len_set(tx_buffer,?len,?0);//?clear?last?DMA?location?and?unmap?remaining?buffers?*/while?(tx_desc?!=?eop_desc)?{} }

無非就是清理了 skb，解除了 DMA 映射等等。到了這一步，傳輸才算是基本完成了。

為啥我說是基本完成，而不是全部完成了呢？因為傳輸層需要保證可靠性，所以 skb 其實還沒有刪除。它得等收到對方的 ACK 之后才會真正刪除，那個時候才算是徹底的發(fā)送完畢。

最后

用一張圖總結(jié)一下整個發(fā)送過程

了解了整個發(fā)送過程以后，我們回頭再來回顧開篇提到的幾個問題。

1.我們在監(jiān)控內(nèi)核發(fā)送數(shù)據(jù)消耗的 CPU 時，是應(yīng)該看 sy 還是 si ？

在網(wǎng)絡(luò)包的發(fā)送過程中，用戶進(jìn)程（在內(nèi)核態(tài)）完成了絕大部分的工作，甚至連調(diào)用驅(qū)動的事情都干了。只有當(dāng)內(nèi)核態(tài)進(jìn)程被切走前才會發(fā)起軟中斷。發(fā)送過程中，絕大部分（90%）以上的開銷都是在用戶進(jìn)程內(nèi)核態(tài)消耗掉的。

只有一少部分情況下才會觸發(fā)軟中斷（NET_TX 類型），由軟中斷 ksoftirqd 內(nèi)核進(jìn)程來發(fā)送。

所以，在監(jiān)控網(wǎng)絡(luò) IO 對服務(wù)器造成的 CPU 開銷的時候，不能僅僅只看 si，而是應(yīng)該把 si、sy 都考慮進(jìn)來。

2. 在服務(wù)器上查看 /proc/softirqs，為什么 NET_RX 要比 NET_TX 大的多的多？

之前我認(rèn)為 NET_RX 是讀取，NET_TX 是傳輸。對于一個既收取用戶請求，又給用戶返回的 Server 來說。這兩塊的數(shù)字應(yīng)該差不多才對，至少不會有數(shù)量級的差異。但事實上，飛哥手頭的一臺服務(wù)器是這樣的：

經(jīng)過今天的源碼分析，發(fā)現(xiàn)這個問題的原因有兩個。

第一個原因是當(dāng)數(shù)據(jù)發(fā)送完成以后，通過硬中斷的方式來通知驅(qū)動發(fā)送完畢。但是硬中斷無論是有數(shù)據(jù)接收，還是對于發(fā)送完畢，觸發(fā)的軟中斷都是 NET_RX_SOFTIRQ，而并不是 NET_TX_SOFTIRQ。

第二個原因是對于讀來說，都是要經(jīng)過 NET_RX 軟中斷的，都走 ksoftirqd 內(nèi)核進(jìn)程。而對于發(fā)送來說，絕大部分工作都是在用戶進(jìn)程內(nèi)核態(tài)處理了，只有系統(tǒng)態(tài)配額用盡才會發(fā)出 NET_TX，讓軟中斷上。

綜上兩個原因，那么在機器上查看 NET_RX 比 NET_TX 大的多就不難理解了。

3.發(fā)送網(wǎng)絡(luò)數(shù)據(jù)的時候都涉及到哪些內(nèi)存拷貝操作？

這里的內(nèi)存拷貝，我們只特指待發(fā)送數(shù)據(jù)的內(nèi)存拷貝。

第一次拷貝操作是內(nèi)核申請完 skb 之后，這時候會將用戶傳遞進(jìn)來的 buffer 里的數(shù)據(jù)內(nèi)容都拷貝到 skb 中。如果要發(fā)送的數(shù)據(jù)量比較大的話，這個拷貝操作開銷還是不小的。

第二次拷貝操作是從傳輸層進(jìn)入網(wǎng)絡(luò)層的時候，每一個 skb 都會被克隆一個新的副本出來。網(wǎng)絡(luò)層以及下面的驅(qū)動、軟中斷等組件在發(fā)送完成的時候會將這個副本刪除。傳輸層保存著原始的 skb，在當(dāng)網(wǎng)絡(luò)對方?jīng)]有 ack 的時候，還可以重新發(fā)送，以實現(xiàn) TCP 中要求的可靠傳輸。

第三次拷貝不是必須的，只有當(dāng) IP 層發(fā)現(xiàn) skb 大于 MTU 時才需要進(jìn)行。會再申請額外的 skb，并將原來的 skb 拷貝為多個小的 skb。

這里插入個題外話，大家在網(wǎng)絡(luò)性能優(yōu)化中經(jīng)常聽到的零拷貝，我覺得這有點點夸張的成分。TCP 為了保證可靠性，第二次的拷貝根本就沒法省。如果包再大于 MTU 的話，分片時的拷貝同樣也避免不了。

看到這里，相信內(nèi)核發(fā)送數(shù)據(jù)包對于你來說，已經(jīng)不再是一個完全不懂的黑盒了。本文哪怕你只看懂十分之一，你也已經(jīng)掌握了這個黑盒的打開方式。這在你將來優(yōu)化網(wǎng)絡(luò)性能時你就會知道從哪兒下手了。

轉(zhuǎn)載文章：https://mp.weixin.qq.com/s/rpEoQT0aVbJqiaB_2XWVmQ

總結(jié)

以上是生活随笔為你收集整理的拆解 Linux 网络包发送过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。