图解分析 Linux 网络包发送过程
大家好,下面的文章轉(zhuǎn)發(fā)一個(gè)鵝廠同學(xué)的文章,這篇文章從應(yīng)用到內(nèi)核,寫的非常不錯(cuò),希望大家分析某個(gè)技術(shù)也可以從這方面入手。
-----
大家好,我是飛哥!
半年前我以源碼的方式描述了網(wǎng)絡(luò)包的接收過(guò)程。之后不斷有粉絲提醒我還沒(méi)聊發(fā)送過(guò)程呢。好,安排!
在開(kāi)始今天的文章之前,我先來(lái)請(qǐng)大家思考幾個(gè)小問(wèn)題。
問(wèn)1:我們?cè)诓榭磧?nèi)核發(fā)送數(shù)據(jù)消耗的 CPU 時(shí),是應(yīng)該看 sy 還是 si ?
問(wèn)2:為什么你服務(wù)器上的 /proc/softirqs 里 NET_RX 要比 NET_TX 大的多的多?
問(wèn)3:發(fā)送網(wǎng)絡(luò)數(shù)據(jù)的時(shí)候都涉及到哪些內(nèi)存拷貝操作?
這些問(wèn)題雖然在線上經(jīng)常看到,但我們似乎很少去深究。如果真的能透徹地把這些問(wèn)題理解到位,我們對(duì)性能的掌控能力將會(huì)變得更強(qiáng)。
帶著這三個(gè)問(wèn)題,我們開(kāi)始今天對(duì) Linux 內(nèi)核網(wǎng)絡(luò)發(fā)送過(guò)程的深度剖析。還是按照我們之前的傳統(tǒng),先從一段簡(jiǎn)單的代碼作為切入。如下代碼是一個(gè)典型服務(wù)器程序的典型的縮微代碼:
int?main(){fd?=?socket(AF_INET,?SOCK_STREAM,?0);bind(fd,?...);listen(fd,?...);cfd?=?accept(fd,?...);//?接收用戶請(qǐng)求read(cfd,?...);//?用戶請(qǐng)求處理dosometing();?//?給用戶返回結(jié)果send(cfd,?buf,?sizeof(buf),?0); }今天我們來(lái)討論上述代碼中,調(diào)用 send 之后內(nèi)核是怎么樣把數(shù)據(jù)包發(fā)送出去的。本文基于Linux 3.10,網(wǎng)卡驅(qū)動(dòng)采用Intel的igb網(wǎng)卡舉例。
預(yù)警:本文共有一萬(wàn)多字,25 張圖,長(zhǎng)文慎入!
一、Linux 網(wǎng)絡(luò)發(fā)送過(guò)程總覽
我覺(jué)得看 Linux 源碼最重要的是得有整體上的把握,而不是一開(kāi)始就陷入各種細(xì)節(jié)。
我這里先給大家準(zhǔn)備了一個(gè)總的流程圖,簡(jiǎn)單闡述下 send 發(fā)送了的數(shù)據(jù)是如何一步一步被發(fā)送到網(wǎng)卡的。
在這幅圖中,我們看到用戶數(shù)據(jù)被拷貝到內(nèi)核態(tài),然后經(jīng)過(guò)協(xié)議棧處理后進(jìn)入到了 RingBuffer 中。隨后網(wǎng)卡驅(qū)動(dòng)真正將數(shù)據(jù)發(fā)送了出去。當(dāng)發(fā)送完成的時(shí)候,是通過(guò)硬中斷來(lái)通知 CPU,然后清理 RingBuffer。
因?yàn)槲恼潞竺嬉M(jìn)入源碼,所以我們?cè)購(gòu)脑创a的角度給出一個(gè)流程圖。
雖然數(shù)據(jù)這時(shí)已經(jīng)發(fā)送完畢,但是其實(shí)還有一件重要的事情沒(méi)有做,那就是釋放緩存隊(duì)列等內(nèi)存。
那內(nèi)核是如何知道什么時(shí)候才能釋放內(nèi)存的呢,當(dāng)然是等網(wǎng)絡(luò)發(fā)送完畢之后。網(wǎng)卡在發(fā)送完畢的時(shí)候,會(huì)給 CPU 發(fā)送一個(gè)硬中斷來(lái)通知 CPU。更完整的流程看圖:
注意,我們今天的主題雖然是發(fā)送數(shù)據(jù),但是硬中斷最終觸發(fā)的軟中斷卻是 NET_RX_SOFTIRQ,而并不是 NET_TX_SOFTIRQ !!!(T 是 transmit 的縮寫,R 表示 receive)
意不意外,驚不驚喜???
所以這就是開(kāi)篇問(wèn)題 1 的一部分的原因(注意,這只是一部分原因)。
問(wèn)1:在服務(wù)器上查看 /proc/softirqs,為什么 NET_RX 要比 NET_TX 大的多的多?
傳輸完成最終會(huì)觸發(fā) NET_RX,而不是 NET_TX。所以自然你觀測(cè) /proc/softirqs 也就能看到 NET_RX 更多了。
好,現(xiàn)在你已經(jīng)對(duì)內(nèi)核是怎么發(fā)送網(wǎng)絡(luò)包的有一個(gè)全局上的把握了。不要得意,我們需要了解的細(xì)節(jié)才是更有價(jià)值的地方,讓我們繼續(xù)!!
二、網(wǎng)卡啟動(dòng)準(zhǔn)備
現(xiàn)在的服務(wù)器上的網(wǎng)卡一般都是支持多隊(duì)列的。每一個(gè)隊(duì)列上都是由一個(gè) RingBuffer 表示的,開(kāi)啟了多隊(duì)列以后的的網(wǎng)卡就會(huì)對(duì)應(yīng)有多個(gè) RingBuffer。
網(wǎng)卡在啟動(dòng)時(shí)最重要的任務(wù)之一就是分配和初始化 RingBuffer,理解了 RingBuffer 將會(huì)非常有助于后面我們掌握發(fā)送。因?yàn)榻裉斓闹黝}是發(fā)送,所以就以傳輸隊(duì)列為例,我們來(lái)看下網(wǎng)卡啟動(dòng)時(shí)分配 RingBuffer 的實(shí)際過(guò)程。
在網(wǎng)卡啟動(dòng)的時(shí)候,會(huì)調(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);//開(kāi)啟全部隊(duì)列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è)隊(duì)列就構(gòu)造幾個(gè)?RingBufferfor?(i?=?0;?i?<?adapter->num_tx_queues;?i++)?{igb_setup_tx_resources(adapter->tx_ring[i]);} }真正的 RingBuffer 構(gòu)造過(guò)程是在 igb_setup_tx_resources 中完成的。
//file:?drivers/net/ethernet/intel/igb/igb_main.c int?igb_setup_tx_resources(struct?igb_ring?*tx_ring) {//1.申請(qǐng)?igb_tx_buffer?數(shù)組內(nèi)存size?=?sizeof(struct?igb_tx_buffer)?*?tx_ring->count;tx_ring->tx_buffer_info?=?vzalloc(size);//2.申請(qǐng)?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.初始化隊(duì)列成員tx_ring->next_to_use?=?0;tx_ring->next_to_clean?=?0; }從上述源碼可以看到,實(shí)際上一個(gè) RingBuffer 的內(nèi)部不僅僅是一個(gè)環(huán)形隊(duì)列數(shù)組,而是有兩個(gè)。
1)igb_tx_buffer 數(shù)組:這個(gè)數(shù)組是內(nèi)核使用的,通過(guò) vzalloc 申請(qǐng)的。
2)e1000_adv_tx_desc 數(shù)組:這個(gè)數(shù)組是網(wǎng)卡硬件使用的,硬件是可以通過(guò) DMA 直接訪問(wèn)這塊內(nèi)存,通過(guò) dma_alloc_coherent 分配。
這個(gè)時(shí)候它們之間還沒(méi)有啥聯(lián)系。將來(lái)在發(fā)送的時(shí)候,這兩個(gè)環(huán)形數(shù)組中相同位置的指針將都將指向同一個(gè) skb。這樣,內(nèi)核和硬件就能共同訪問(wèn)同樣的數(shù)據(jù)了,內(nèi)核往 skb 里寫數(shù)據(jù),網(wǎng)卡硬件負(fù)責(zé)發(fā)送。
最后調(diào)用 netif_tx_start_all_queues 開(kāi)啟隊(duì)列。另外,對(duì)于硬中斷的處理函數(shù) igb_msix_ring 其實(shí)也是在 __igb_open 中注冊(cè)的。
三、accept 創(chuàng)建新 socket
在發(fā)送數(shù)據(jù)之前,我們往往還需要一個(gè)已經(jīng)建立好連接的 socket。
我們就以開(kāi)篇服務(wù)器縮微源代碼中提到的 accept 為例,當(dāng) accept 之后,進(jìn)程會(huì)創(chuàng)建一個(gè)新的 socket 出來(lái),然后把它放到當(dāng)前進(jìn)程的打開(kāi)文件列表中,專門用于和對(duì)應(yīng)的客戶端通信。
假設(shè)服務(wù)器進(jìn)程通過(guò) accept 和客戶端建立了兩條連接,我們來(lái)簡(jiǎn)單看一下這兩條連接和進(jìn)程的關(guān)聯(lián)關(guān)系。
其中代表一條連接的 socket 內(nèi)核對(duì)象更為具體一點(diǎn)的結(jié)構(gòu)圖如下。
為了避免喧賓奪主,accept 詳細(xì)的源碼過(guò)程這里就不介紹了,感興趣請(qǐng)參考 《圖解 | 深入揭秘 epoll 是如何實(shí)現(xiàn) IO 多路復(fù)用的!》
今天我們還是把重點(diǎn)放到數(shù)據(jù)發(fā)送過(guò)程上。
四、發(fā)送數(shù)據(jù)真正開(kāi)始
4.1 send 系統(tǒng)調(diào)用實(shí)現(xiàn)
send 系統(tǒng)調(diào)用的源碼位于文件 net/socket.c 中。在這個(gè)系統(tǒng)調(diào)用里,內(nèi)部其實(shí)真正使用的是 sendto 系統(tǒng)調(diào)用。整個(gè)調(diào)用鏈條雖然不短,但其實(shí)主要只干了兩件簡(jiǎn)單的事情,
第一是在內(nèi)核中把真正的 socket 找出來(lái),在這個(gè)對(duì)象里記錄著各種協(xié)議棧的函數(shù)地址。
第二是構(gòu)造一個(gè) struct msghdr 對(duì)象,把用戶傳入的數(shù)據(jù),比如 buffer地址、數(shù)據(jù)長(zhǎng)度啥的,統(tǒng)統(tǒng)都裝進(jìn)去.
剩下的事情就交給下一層,協(xié)議棧里的函數(shù) inet_sendmsg 了,其中 inet_sendmsg 函數(shù)的地址是通過(guò) socket 內(nèi)核對(duì)象里的 ops 成員找到的。大致流程如圖。
有了上面的了解,我們?cè)倏雌鹪创a就要容易許多了。源碼如下:
從源碼可以看到,我們?cè)谟脩魬B(tài)使用的 send 函數(shù)和 sendto 函數(shù)其實(shí)都是 sendto 系統(tǒng)調(diào)用實(shí)現(xiàn)的。send 只是為了方便,封裝出來(lái)的一個(gè)更易于調(diào)用的方式而已。
在 sendto 系統(tǒng)調(diào)用里,首先根據(jù)用戶傳進(jìn)來(lái)的 socket 句柄號(hào)來(lái)查找真正的 socket 內(nèi)核對(duì)象。接著把用戶請(qǐng)求的 buff、len、flag 等參數(shù)都統(tǒng)統(tǒng)打包到一個(gè) struct msghdr 對(duì)象中。
接著調(diào)用了 sock_sendmsg => __sock_sendmsg ==> ?__sock_sendmsg_nosec。在__sock_sendmsg_nosec 中,調(diào)用將會(huì)由系統(tǒng)調(diào)用進(jìn)入到協(xié)議棧,我們來(lái)看它的源碼。
//file:?net/socket.c static?inline?int?__sock_sendmsg_nosec(...) {......return?sock->ops->sendmsg(iocb,?sock,?msg,?size); }通過(guò)第三節(jié)里的 socket 內(nèi)核對(duì)象結(jié)構(gòu)圖,我們可以看到,這里調(diào)用的是 sock->ops->sendmsg 實(shí)際執(zhí)行的是 inet_sendmsg。這個(gè)函數(shù)是 AF_INET 協(xié)議族提供的通用發(fā)送函數(shù)。
4.2 傳輸層處理
1)傳輸層拷貝
在進(jìn)入到協(xié)議棧 inet_sendmsg 以后,內(nèi)核接著會(huì)找到 socket 上的具體協(xié)議發(fā)送函數(shù)。對(duì)于 TCP 協(xié)議來(lái)說(shuō),那就是 tcp_sendmsg(同樣也是通過(guò) socket 內(nèi)核對(duì)象找到的)。
在這個(gè)函數(shù)中,內(nèi)核會(huì)申請(qǐng)一個(gè)內(nèi)核態(tài)的 skb 內(nèi)存,將用戶待發(fā)送的數(shù)據(jù)拷貝進(jìn)去。注意這個(gè)時(shí)候不一定會(huì)真正開(kāi)始發(fā)送,如果沒(méi)有達(dá)到發(fā)送條件的話很可能這次調(diào)用直接就返回了。大概過(guò)程如圖:
我們來(lái)看 inet_sendmsg 函數(shù)的源碼。
在這個(gè)函數(shù)中會(huì)調(diào)用到具體協(xié)議的發(fā)送函數(shù)。同樣參考第三節(jié)里的 socket 內(nèi)核對(duì)象結(jié)構(gòu)圖,我們看到對(duì)于 TCP 協(xié)議下的 socket 來(lái)說(shuō),來(lái)說(shuō) sk->sk_prot->sendmsg 指向的是 tcp_sendmsg(對(duì)于 UPD 來(lái)說(shuō)是 udp_sendmsg)。
tcp_sendmsg 這個(gè)函數(shù)比較長(zhǎng),我們分多次來(lái)看它。先看這一段
//file:?net/ipv4/tcp.c int?tcp_sendmsg(...) {while(...){while(...){//獲取發(fā)送隊(duì)列skb?=?tcp_write_queue_tail(sk);//申請(qǐng)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); }理解對(duì) socket 調(diào)用 tcp_write_queue_tail 是理解發(fā)送的前提。如上所示,這個(gè)函數(shù)是在獲取 socket 發(fā)送隊(duì)列中的最后一個(gè) skb。skb 是 struct sk_buff 對(duì)象的簡(jiǎn)稱,用戶的發(fā)送隊(duì)列就是該對(duì)象組成的一個(gè)鏈表。
我們?cè)俳又?tcp_sendmsg 的其它部分。
這個(gè)函數(shù)比較長(zhǎng),不過(guò)其實(shí)邏輯并不復(fù)雜。其中 msg->msg_iov 存儲(chǔ)的是用戶態(tài)內(nèi)存的要發(fā)送的數(shù)據(jù)的 buffer。接下來(lái)在內(nèi)核態(tài)申請(qǐng)內(nèi)核內(nèi)存,比如 skb,并把用戶內(nèi)存里的數(shù)據(jù)拷貝到內(nèi)核態(tài)內(nèi)存中。這就會(huì)涉及到一次或者幾次內(nèi)存拷貝的開(kāi)銷。
至于內(nèi)核什么時(shí)候真正把 skb 發(fā)送出去。在 tcp_sendmsg 中會(huì)進(jìn)行一些判斷。
只有滿足 forced_push(tp) 或者 skb == tcp_send_head(sk) 成立的時(shí)候,內(nèi)核才會(huì)真正啟動(dòng)發(fā)送數(shù)據(jù)包。其中 forced_push(tp) 判斷的是未發(fā)送的數(shù)據(jù)數(shù)據(jù)是否已經(jīng)超過(guò)最大窗口的一半了。
條件都不滿足的話,這次的用戶要發(fā)送的數(shù)據(jù)只是拷貝到內(nèi)核就算完事了!
2)傳輸層發(fā)送
假設(shè)現(xiàn)在內(nèi)核發(fā)送條件已經(jīng)滿足了,我們?cè)賮?lái)跟蹤一下實(shí)際的發(fā)送過(guò)程。對(duì)于上小節(jié)函數(shù)中,當(dāng)滿足真正發(fā)送條件的時(shí)候,無(wú)論調(diào)用的是 __tcp_push_pending_frames 還是 tcp_push_one 最終都實(shí)際會(huì)執(zhí)行到 tcp_write_xmit。
所以我們直接從 tcp_write_xmit 看起,這個(gè)函數(shù)處理了傳輸層的擁塞控制、滑動(dòng)窗口相關(guān)的工作。滿足窗口要求的時(shí)候,設(shè)置一下 TCP 頭然后將 skb 傳到更低的網(wǎng)絡(luò)層進(jìn)行處理。
我們來(lái)看下 tcp_write_xmit 的源碼。
可以看到我們之前在網(wǎng)絡(luò)協(xié)議里學(xué)的滑動(dòng)窗口、擁塞控制就是在這個(gè)函數(shù)中完成的,這部分就不過(guò)多展開(kāi)了,感興趣同學(xué)自己找這段源碼來(lái)讀。我們今天只看發(fā)送主過(guò)程,那就走到了 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?出來(lái)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); }第一件事是先克隆一個(gè)新的 skb,這里重點(diǎn)說(shuō)下為什么要復(fù)制一個(gè) skb 出來(lái)呢?
是因?yàn)?skb 后續(xù)在調(diào)用網(wǎng)絡(luò)層,最后到達(dá)網(wǎng)卡發(fā)送完成的時(shí)候,這個(gè) skb 會(huì)被釋放掉。而我們知道 TCP 協(xié)議是支持丟失重傳的,在收到對(duì)方的 ACK 之前,這個(gè) skb 不能被刪除。所以內(nèi)核的做法就是每次調(diào)用網(wǎng)卡發(fā)送的時(shí)候,實(shí)際上傳遞出去的是 skb 的一個(gè)拷貝。等收到 ACK 再真正刪除。
第二件事是修改 skb 中的 TCP header,根據(jù)實(shí)際情況把 TCP 頭設(shè)置好。這里要介紹一個(gè)小技巧,skb 內(nèi)部其實(shí)包含了網(wǎng)絡(luò)協(xié)議中所有的 header。在設(shè)置 TCP 頭的時(shí)候,只是把指針指向 skb 的合適位置。后面再設(shè)置 IP 頭的時(shí)候,在把指針挪一挪就行,避免頻繁的內(nèi)存申請(qǐng)和拷貝,效率很高。
tcp_transmit_skb 是發(fā)送數(shù)據(jù)位于傳輸層的最后一步,接下來(lái)就可以進(jìn)入到網(wǎng)絡(luò)層進(jìn)行下一層的操作了。調(diào)用了網(wǎng)絡(luò)層提供的發(fā)送接口icsk->icsk_af_ops->queue_xmit()。
在下面的這個(gè)源碼中,我們的知道了 queue_xmit 其實(shí)指向的是 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ù)離開(kāi)了傳輸層,接下來(lái)將會(huì)進(jìn)入到內(nèi)核在網(wǎng)絡(luò)層的實(shí)現(xiàn)里。
4.3 網(wǎng)絡(luò)層發(fā)送處理
Linux 內(nèi)核網(wǎng)絡(luò)層的發(fā)送的實(shí)現(xiàn)位于 net/ipv4/ip_output.c 這個(gè)文件。傳輸層調(diào)用到的 ip_queue_xmit 也在這里。(從文件名上也能看出來(lái)進(jìn)入到 IP 層了,源文件名已經(jīng)從 tcp_xxx 變成了 ip_xxx。)
在網(wǎng)絡(luò)層里主要處理路由項(xiàng)查找、IP 頭設(shè)置、netfilter 過(guò)濾、skb 切分(大于 MTU 的話)等幾項(xiàng)工作,處理完這些工作后會(huì)交給更下層的鄰居子系統(tǒng)來(lái)處理。
我們來(lái)看網(wǎng)絡(luò)層入口函數(shù) ip_queue_xmit 的源碼:
ip_queue_xmit 已經(jīng)到了網(wǎng)絡(luò)層,在這個(gè)函數(shù)里我們看到了網(wǎng)絡(luò)層相關(guān)的功能路由項(xiàng)查找,如果找到了則設(shè)置到 skb 上(沒(méi)有路由的話就直接報(bào)錯(cuò)返回了)。
在 Linux 上通過(guò) route 命令可以看到你本機(jī)的路由配置。
在路由表中,可以查到某個(gè)目的網(wǎng)絡(luò)應(yīng)該通過(guò)哪個(gè) Iface(網(wǎng)卡),哪個(gè) Gateway(網(wǎng)卡)發(fā)送出去。查找出來(lái)以后緩存到 socket 上,下次再發(fā)送數(shù)據(jù)就不用查了。
接著把路由表地址也放到 skb 里去。
//file:?include/linux/skbuff.h struct?sk_buff?{//保存了一些路由相關(guān)信息unsigned?long??_skb_refdst; }接下來(lái)就是定位到 skb 里的 IP 頭的位置上,然后開(kāi)始按照協(xié)議規(guī)范設(shè)置 IP header。
再通過(guò) ip_local_out 進(jìn)入到下一步的處理。
在 ip_local_out => __ip_local_out => nf_hook 會(huì)執(zhí)行 netfilter 過(guò)濾。如果你使用 iptables 配置了一些規(guī)則,那么這里將檢測(cè)是否命中規(guī)則。如果你設(shè)置了非常復(fù)雜的 netfilter 規(guī)則,在這個(gè)函數(shù)這里將會(huì)導(dǎo)致你的進(jìn)程 CPU 開(kāi)銷會(huì)極大增加。
還是不多展開(kāi)說(shuō),繼續(xù)只聊和發(fā)送有關(guān)的過(guò)程 dst_output。
//file:?include/net/dst.h static?inline?int?dst_output(struct?sk_buff?*skb) {return?skb_dst(skb)->output(skb); }此函數(shù)找到到這個(gè) skb 的路由表(dst 條目) ,然后調(diào)用路由表的 output 方法。這又是一個(gè)函數(shù)指針,指向的是 ip_output 方法。
//file:?net/ipv4/ip_output.c int?ip_output(struct?sk_buff?*skb) {//統(tǒng)計(jì).....//再次交給?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)行一些簡(jiǎn)單的,統(tǒng)計(jì)工作,再次執(zhí)行 netfilter 過(guò)濾。過(guò)濾通過(guò)之后回調(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 的話,是會(huì)執(zhí)行分片的。
實(shí)際 MTU 大小確定依賴 MTU 發(fā)現(xiàn),以太網(wǎng)幀為 1500 字節(jié)。之前 QQ 團(tuán)隊(duì)在早期的時(shí)候,會(huì)盡量控制自己數(shù)據(jù)包尺寸小于 MTU,通過(guò)這種方式來(lái)優(yōu)化網(wǎng)絡(luò)性能。因?yàn)榉制瑫?huì)帶來(lái)兩個(gè)問(wèn)題:1、需要進(jìn)行額外的切分處理,有額外性能開(kāi)銷。2、只要一個(gè)分片丟失,整個(gè)包都得重傳。所以避免分片既杜絕了分片開(kāi)銷,也大大降低了重傳率。
在 ip_finish_output2 中,終于發(fā)送過(guò)程會(huì)進(jìn)入到下一層,鄰居子系統(tǒng)中。
//file:?net/ipv4/ip_output.c static?inline?int?ip_finish_output2(struct?sk_buff?*skb) {//根據(jù)下一跳 IP 地址查找鄰居項(xiàng),找不到就創(chuàng)建一個(gè)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ù)鏈路層中間的一個(gè)系統(tǒng),其作用是對(duì)網(wǎng)絡(luò)層提供一個(gè)封裝,讓網(wǎng)絡(luò)層不必關(guān)心下層的地址信息,讓下層來(lái)決定發(fā)送到哪個(gè) MAC 地址。
而且這個(gè)鄰居子系統(tǒng)并不位于協(xié)議棧 net/ipv4/ 目錄內(nèi),而是位于 net/core/neighbour.c。因?yàn)闊o(wú)論是對(duì)于 IPv4 還是 IPv6 ,都需要使用該模塊。
在鄰居子系統(tǒng)里主要是查找或者創(chuàng)建鄰居項(xiàng),在創(chuàng)造鄰居項(xiàng)的時(shí)候,有可能會(huì)發(fā)出實(shí)際的 arp 請(qǐng)求。然后封裝一下 MAC 頭,將發(fā)送過(guò)程再傳遞到更下層的網(wǎng)絡(luò)設(shè)備子系統(tǒng)。大致流程如圖。
理解了大致流程,我們?cè)倩仡^看源碼。在上面小節(jié) ip_finish_output2 源碼中調(diào)用了 __ipv4_neigh_lookup_noref。它是在 arp 緩存中進(jìn)行查找,其第二個(gè)參數(shù)傳入的是路由下一跳 IP 信息。
如果查找不到,則調(diào)用 __neigh_create 創(chuàng)建一個(gè)鄰居。
//file:?net/core/neighbour.c struct?neighbour?*__neigh_create(......) {//申請(qǐng)鄰居表項(xiàng)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);......有了鄰居項(xiàng)以后,此時(shí)仍然還不具備發(fā)送 IP 報(bào)文的能力,因?yàn)槟康?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,實(shí)際指向的是 neigh_resolve_output。在這個(gè)函數(shù)內(nèi)部有可能會(huì)發(fā)出 arp 網(wǎng)絡(luò)請(qǐng)求。
//file:?net/core/neighbour.c int?neigh_resolve_output(){//注意:這里可能會(huì)觸發(fā) arp 請(qǐng)求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)通過(guò) dev_queue_xmit 進(jìn)入到網(wǎng)絡(luò)設(shè)備子系統(tǒng)中來(lái)。
開(kāi)篇第二節(jié)網(wǎng)卡啟動(dòng)準(zhǔn)備里我們說(shuō)過(guò),網(wǎng)卡是有多個(gè)發(fā)送隊(duì)列的(尤其是現(xiàn)在的網(wǎng)卡)。上面對(duì) netdev_pick_tx 函數(shù)的調(diào)用就是選擇一個(gè)隊(duì)列進(jìn)行發(fā)送。
netdev_pick_tx 發(fā)送隊(duì)列的選擇受 XPS 等配置的影響,而且還有緩存,也是一套小復(fù)雜的邏輯。這里我們只關(guān)注兩個(gè)邏輯,首先會(huì)獲取用戶的 XPS 配置,否則就自動(dòng)計(jì)算了。代碼見(jiàn) 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);//自動(dòng)計(jì)算隊(duì)列if?(new_index?<?0)new_index?=?skb_tx_hash(dev,?skb);}然后獲取與此隊(duì)列關(guān)聯(lián)的 qdisc。在 linux 上通過(guò) tc 命令可以看到 qdisc 類型,例如對(duì)于我的某臺(tái)多隊(duì)列網(wǎng)卡機(jī)器上是 mq disc。
#tc?qdisc qdisc?mq?0:?dev?eth0?root大部分的設(shè)備都有隊(duì)列(回環(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.如果可以繞開(kāi)排隊(duì)系統(tǒng)if?((q->flags?&?TCQ_F_CAN_BYPASS)?&&?!qdisc_qlen(q)?&&qdisc_run_begin(q))?{......}//2.正常排隊(duì)else?{//入隊(duì)q->enqueue(skb,?q)//開(kāi)始發(fā)送__qdisc_run(q);} }上述代碼中分兩種情況,1 是可以 bypass(繞過(guò))排隊(duì)系統(tǒng)的,另外一種是正常排隊(duì)。我們只看第二種情況。
先調(diào)用 q->enqueue 把 skb 添加到隊(duì)列里。然后調(diào)用 __qdisc_run 開(kāi)始發(fā)送。
//file:?net/sched/sch_generic.c void?__qdisc_run(struct?Qdisc?*q) {int?quota?=?weight_p;//循環(huán)從隊(duì)列取出一個(gè)?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)不斷地從隊(duì)列中取出 skb 并進(jìn)行發(fā)送。注意,這個(gè)時(shí)候其實(shí)都占用的是用戶進(jìn)程的系統(tǒng)態(tài)時(shí)間(sy)。只有當(dāng) quota 用盡或者其它進(jìn)程需要 CPU 的時(shí)候才觸發(fā)軟中斷進(jìn)行發(fā)送。
所以這就是為什么一般服務(wù)器上查看 /proc/softirqs,一般 NET_RX 都要比 NET_TX 大的多的第二個(gè)原因。對(duì)于讀來(lái)說(shuō),都是要經(jīng)過(guò) NET_RX 軟中斷,而對(duì)于發(fā)送來(lái)說(shuō),只有系統(tǒng)態(tài)配額用盡才讓軟中斷上。
我們來(lái)把精力在放到 qdisc_restart 上,繼續(xù)看發(fā)送過(guò)程。
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 從隊(duì)列中取出一個(gè) 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ū)動(dòng)程序來(lái)發(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ò)包不夠用的時(shí)候,會(huì)調(diào)用 __netif_schedule 觸發(fā)一個(gè)軟中斷。該函數(shù)會(huì)進(jìn)入到 __netif_reschedule,由它來(lái)實(shí)際發(fā)出 NET_TX_SOFTIRQ 類型軟中斷。
軟中斷是由內(nèi)核線程來(lái)運(yùn)行的,該線程會(huì)進(jìn)入到 net_tx_action 函數(shù),在該函數(shù)中能獲取到發(fā)送隊(duì)列,并也最終調(diào)用到驅(qū)動(dòng)程序里的入口函數(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ù)里在軟中斷能訪問(wèn)到的 softnet_data 里設(shè)置了要發(fā)送的數(shù)據(jù)隊(duì)列,添加到了 output_queue 里了。緊接著觸發(fā)了 NET_TX_SOFTIRQ 類型的軟中斷。(T 代表 transmit 傳輸)
軟中斷的入口代碼我這里也不詳細(xì)扒了,感興趣的同學(xué)參考《圖解Linux網(wǎng)絡(luò)包接收過(guò)程》
我們直接從 NET_TX_SOFTIRQ softirq 注冊(cè)的回調(diào)函數(shù) net_tx_action講起。用戶態(tài)進(jìn)程觸發(fā)完軟中斷之后,會(huì)有一個(gè)軟中斷內(nèi)核線程會(huì)執(zhí)行到 net_tx_action。
牢記,這以后發(fā)送數(shù)據(jù)消耗的 CPU 就都顯示在 si 這里了,不會(huì)消耗用戶進(jìn)程的系統(tǒng)時(shí)間了。
//file:?net/core/dev.c static?void?net_tx_action(struct?softirq_action?*h) {//通過(guò)?softnet_data?獲取發(fā)送隊(duì)列struct?softnet_data?*sd?=?&__get_cpu_var(softnet_data);//?如果?output?queue?上有?qdiscif?(sd->output_queue)?{//?將?head?指向第一個(gè)?qdischead?=?sd->output_queue;//遍歷?qdsics?列表while?(head)?{struct?Qdisc?*q?=?head;head?=?head->next_sched;//發(fā)送數(shù)據(jù)qdisc_run(q);}} }軟中斷這里會(huì)獲取 softnet_data。前面我們看到進(jìn)程內(nèi)核態(tài)在調(diào)用 __netif_reschedule 的時(shí)候把發(fā)送隊(duì)列寫到 softnet_data 的 output_queue 里了。軟中斷循環(huán)遍歷 sd->output_queue 發(fā)送數(shù)據(jù)幀。
來(lái)看 qdisc_run,它和進(jìn)程用戶態(tài)一樣,也會(huì)調(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ū)動(dòng)程序函數(shù) dev_hard_start_xmit。
4.7 igb 網(wǎng)卡驅(qū)動(dòng)發(fā)送
我們前面看到,無(wú)論是對(duì)于用戶進(jìn)程的內(nèi)核態(tài),還是對(duì)于軟中斷上下文,都會(huì)調(diào)用到網(wǎng)絡(luò)設(shè)備子系統(tǒng)中的 dev_hard_start_xmit 函數(shù)。在這個(gè)函數(shù)中,會(huì)調(diào)用到驅(qū)動(dòng)里的發(fā)送函數(shù) igb_xmit_frame。
在驅(qū)動(dòng)函數(shù)里,將 skb 會(huì)掛到 RingBuffer上,驅(qū)動(dòng)調(diào)用完畢后,數(shù)據(jù)包將真正從網(wǎng)卡發(fā)送出去。
我們來(lái)看看實(shí)際的源碼:
其中 ndo_start_xmit 是網(wǎng)卡驅(qū)動(dòng)要實(shí)現(xiàn)的一個(gè)函數(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ū)動(dòng)源碼中,我們找到了。
//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,?... };也就是說(shuō),對(duì)于網(wǎng)絡(luò)設(shè)備層定義的 ndo_start_xmit, igb 的實(shí)現(xiàn)函數(shù)是 igb_xmit_frame。這個(gè)函數(shù)是在網(wǎng)卡驅(qū)動(dòng)初始化的時(shí)候被賦值的。具體初始化過(guò)程參見(jiàn)《圖解Linux網(wǎng)絡(luò)包接收過(guò)程》
所以在上面網(wǎng)絡(luò)設(shè)備層調(diào)用 ops->ndo_start_xmit 的時(shí)候,會(huì)實(shí)際上進(jìn)入 igb_xmit_frame 這個(gè)函數(shù)中。我們進(jìn)入這個(gè)函數(shù)來(lái)看看驅(qū)動(dòng)程序是如何工作的。
//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?中下一個(gè)可用緩沖區(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ā)送隊(duì)列的 RingBuffer 中取下來(lái)一個(gè)元素,并將 skb 掛到元素上。
igb_tx_map 函數(shù)處理將 skb 數(shù)據(jù)映射到網(wǎng)卡可訪問(wèn)的內(nèi)存 DMA 區(qū)域。
當(dāng)所有需要的描述符都已建好,且 skb 的所有數(shù)據(jù)都映射到 DMA 地址后,驅(qū)動(dòng)就會(huì)進(jìn)入到它的最后一步,觸發(fā)真實(shí)的發(fā)送。
4.8 發(fā)送完成硬中斷
當(dāng)數(shù)據(jù)發(fā)送完成以后,其實(shí)工作并沒(méi)有結(jié)束。因?yàn)閮?nèi)存還沒(méi)有清理。當(dāng)發(fā)送完成的時(shí)候,網(wǎng)卡設(shè)備會(huì)觸發(fā)一個(gè)硬中斷來(lái)釋放內(nèi)存。
在《圖解Linux網(wǎng)絡(luò)包接收過(guò)程》
在發(fā)送完成硬中斷里,會(huì)執(zhí)行 RingBuffer 內(nèi)存的清理工作,如圖。
再回頭看一下硬中斷觸發(fā)軟中斷的源碼。
這里有個(gè)很有意思的細(xì)節(jié),無(wú)論硬中斷是因?yàn)槭怯袛?shù)據(jù)要接收,還是說(shuō)發(fā)送完成通知,從硬中斷觸發(fā)的軟中斷都是 NET_RX_SOFTIRQ。這個(gè)我們?cè)诘谝还?jié)說(shuō)過(guò)了,這是軟中斷統(tǒng)計(jì)中 RX 要高于 TX 的一個(gè)原因。
好我們接著進(jìn)入軟中斷的回調(diào)函數(shù) igb_poll。在這個(gè)函數(shù)里,我們注意到有一行 igb_clean_tx_irq,參見(jiàn)源碼:
//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);... }我們來(lái)看看當(dāng)傳輸完成的時(shí)候,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)?{} }無(wú)非就是清理了 skb,解除了 DMA 映射等等。到了這一步,傳輸才算是基本完成了。
為啥我說(shuō)是基本完成,而不是全部完成了呢?因?yàn)閭鬏攲有枰WC可靠性,所以 skb 其實(shí)還沒(méi)有刪除。它得等收到對(duì)方的 ACK 之后才會(huì)真正刪除,那個(gè)時(shí)候才算是徹底的發(fā)送完畢。
最后
用一張圖總結(jié)一下整個(gè)發(fā)送過(guò)程
了解了整個(gè)發(fā)送過(guò)程以后,我們回頭再來(lái)回顧開(kāi)篇提到的幾個(gè)問(wèn)題。
1.我們?cè)诒O(jiān)控內(nèi)核發(fā)送數(shù)據(jù)消耗的 CPU 時(shí),是應(yīng)該看 sy 還是 si ?
在網(wǎng)絡(luò)包的發(fā)送過(guò)程中,用戶進(jìn)程(在內(nèi)核態(tài))完成了絕大部分的工作,甚至連調(diào)用驅(qū)動(dòng)的事情都干了。只有當(dāng)內(nèi)核態(tài)進(jìn)程被切走前才會(huì)發(fā)起軟中斷。發(fā)送過(guò)程中,絕大部分(90%)以上的開(kāi)銷都是在用戶進(jìn)程內(nèi)核態(tài)消耗掉的。
只有一少部分情況下才會(huì)觸發(fā)軟中斷(NET_TX 類型),由軟中斷 ksoftirqd 內(nèi)核進(jìn)程來(lái)發(fā)送。
所以,在監(jiān)控網(wǎng)絡(luò) IO 對(duì)服務(wù)器造成的 CPU 開(kāi)銷的時(shí)候,不能僅僅只看 si,而是應(yīng)該把 si、sy 都考慮進(jìn)來(lái)。
2. 在服務(wù)器上查看 /proc/softirqs,為什么 NET_RX 要比 NET_TX 大的多的多?
之前我認(rèn)為 NET_RX 是讀取,NET_TX 是傳輸。對(duì)于一個(gè)既收取用戶請(qǐng)求,又給用戶返回的 Server 來(lái)說(shuō)。這兩塊的數(shù)字應(yīng)該差不多才對(duì),至少不會(huì)有數(shù)量級(jí)的差異。但事實(shí)上,飛哥手頭的一臺(tái)服務(wù)器是這樣的:
經(jīng)過(guò)今天的源碼分析,發(fā)現(xiàn)這個(gè)問(wèn)題的原因有兩個(gè)。
第一個(gè)原因是當(dāng)數(shù)據(jù)發(fā)送完成以后,通過(guò)硬中斷的方式來(lái)通知驅(qū)動(dòng)發(fā)送完畢。但是硬中斷無(wú)論是有數(shù)據(jù)接收,還是對(duì)于發(fā)送完畢,觸發(fā)的軟中斷都是 NET_RX_SOFTIRQ,而并不是 NET_TX_SOFTIRQ。
第二個(gè)原因是對(duì)于讀來(lái)說(shuō),都是要經(jīng)過(guò) NET_RX 軟中斷的,都走 ksoftirqd 內(nèi)核進(jìn)程。而對(duì)于發(fā)送來(lái)說(shuō),絕大部分工作都是在用戶進(jìn)程內(nèi)核態(tài)處理了,只有系統(tǒng)態(tài)配額用盡才會(huì)發(fā)出 NET_TX,讓軟中斷上。
綜上兩個(gè)原因,那么在機(jī)器上查看 NET_RX 比 NET_TX 大的多就不難理解了。
3.發(fā)送網(wǎng)絡(luò)數(shù)據(jù)的時(shí)候都涉及到哪些內(nèi)存拷貝操作?
這里的內(nèi)存拷貝,我們只特指待發(fā)送數(shù)據(jù)的內(nèi)存拷貝。
第一次拷貝操作是內(nèi)核申請(qǐng)完 skb 之后,這時(shí)候會(huì)將用戶傳遞進(jìn)來(lái)的 buffer 里的數(shù)據(jù)內(nèi)容都拷貝到 skb 中。如果要發(fā)送的數(shù)據(jù)量比較大的話,這個(gè)拷貝操作開(kāi)銷還是不小的。
第二次拷貝操作是從傳輸層進(jìn)入網(wǎng)絡(luò)層的時(shí)候,每一個(gè) skb 都會(huì)被克隆一個(gè)新的副本出來(lái)。網(wǎng)絡(luò)層以及下面的驅(qū)動(dòng)、軟中斷等組件在發(fā)送完成的時(shí)候會(huì)將這個(gè)副本刪除。傳輸層保存著原始的 skb,在當(dāng)網(wǎng)絡(luò)對(duì)方?jīng)]有 ack 的時(shí)候,還可以重新發(fā)送,以實(shí)現(xiàn) TCP 中要求的可靠傳輸。
第三次拷貝不是必須的,只有當(dāng) IP 層發(fā)現(xiàn) skb 大于 MTU 時(shí)才需要進(jìn)行。會(huì)再申請(qǐng)額外的 skb,并將原來(lái)的 skb 拷貝為多個(gè)小的 skb。
這里插入個(gè)題外話,大家在網(wǎng)絡(luò)性能優(yōu)化中經(jīng)常聽(tīng)到的零拷貝,我覺(jué)得這有點(diǎn)點(diǎn)夸張的成分。TCP 為了保證可靠性,第二次的拷貝根本就沒(méi)法省。如果包再大于 MTU 的話,分片時(shí)的拷貝同樣也避免不了。
看到這里,相信內(nèi)核發(fā)送數(shù)據(jù)包對(duì)于你來(lái)說(shuō),已經(jīng)不再是一個(gè)完全不懂的黑盒了。本文哪怕你只看懂十分之一,你也已經(jīng)掌握了這個(gè)黑盒的打開(kāi)方式。這在你將來(lái)優(yōu)化網(wǎng)絡(luò)性能時(shí)你就會(huì)知道從哪兒下手了。
推薦閱讀:
專輯|Linux文章匯總
專輯|程序人生
專輯|C語(yǔ)言
我的知識(shí)小密圈
關(guān)注公眾號(hào),后臺(tái)回復(fù)「1024」獲取學(xué)習(xí)資料網(wǎng)盤鏈接。
歡迎點(diǎn)贊,關(guān)注,轉(zhuǎn)發(fā),在看,您的每一次鼓勵(lì),我都將銘記于心~
總結(jié)
以上是生活随笔為你收集整理的图解分析 Linux 网络包发送过程的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: mysql 插入语句语法_SQL 插入数
- 下一篇: Linux操作寄存器前为什么要iorem