如果你對(duì)Linux是如何實(shí)現(xiàn) 對(duì)用戶原始的網(wǎng)絡(luò)包進(jìn)行協(xié)議頭封裝與解析，為什么會(huì)粘包拆包，期間網(wǎng)絡(luò)包經(jīng)歷了哪些緩沖區(qū)、經(jīng)歷了幾次拷貝(CPU、DMA)，TCP又是如何實(shí)現(xiàn)滑動(dòng)/擁塞窗口 這幾個(gè)話題感興趣的話，不妨看下去吧。

1. Linux發(fā)送HTTP網(wǎng)絡(luò)包圖像

圖像解析

寫入套接字緩沖區(qū)(添加TcpHeader)

用戶態(tài)進(jìn)程通過write()系統(tǒng)調(diào)用切到內(nèi)核態(tài)將用戶進(jìn)程緩沖區(qū)中的HTTP報(bào)文數(shù)據(jù)通過Tcp Process處理程序?yàn)镠TTP報(bào)文添加TcpHeader，并進(jìn)行CPU copy寫入套接字發(fā)送緩沖區(qū)，每個(gè)套接字會(huì)分別對(duì)應(yīng)一個(gè)Send-Q(發(fā)送緩沖區(qū)隊(duì)列)、Recv-Q(接收緩沖區(qū)隊(duì)列)，可以通過ss -nt語(yǔ)句獲取當(dāng)前的套接字緩沖區(qū)的狀態(tài)；

# ss -nt
State   Recv-Q   Send-Q         Local Address:Port              Peer Address:Port
ESTAB   0        0              192.168.183.130:52454           192.168.183.130:14465
State   Recv-Q   Send-Q         Local Address:Port              Peer Address:Port
ESTAB   0        1024           192.168.183.130:52454           192.168.183.130:14465
State   Recv-Q   Send-Q         Local Address:Port              Peer Address:Port
ESTAB   0        2048           192.168.183.130:52454           192.168.183.130:14465
......
State   Recv-Q   Send-Q         Local Address:Port              Peer Address:Port
ESTAB   0        13312          192.168.183.130:52454           192.168.183.130:14465
State   Recv-Q   Send-Q         Local Address:Port              Peer Address:Port
ESTAB   0        14336          192.168.183.130:52454           192.168.183.130:14465
State   Recv-Q   Send-Q         Local Address:Port              Peer Address:Port
ESTAB   0        14480          192.168.183.130:52454           192.168.183.130:14465

套接字緩沖區(qū)發(fā)送隊(duì)列由一個(gè)個(gè)struct sk_buff 結(jié)構(gòu)體的鏈表組成，其中一個(gè)sk_buff數(shù)據(jù)結(jié)構(gòu)對(duì)應(yīng)一個(gè)網(wǎng)絡(luò)包；這個(gè)結(jié)構(gòu)體后面會(huì)詳細(xì)講，是Linux實(shí)現(xiàn)網(wǎng)絡(luò)協(xié)議棧的核心數(shù)據(jù)結(jié)構(gòu)。

IP層

接著對(duì)TCP包在IP Layer層進(jìn)行網(wǎng)絡(luò)包IpHeader的組裝，并經(jīng)由QDisc(排隊(duì)規(guī)則)進(jìn)行轉(zhuǎn)發(fā)；

數(shù)據(jù)鏈路層/物理層

接著網(wǎng)卡設(shè)備通過DMA Engine將內(nèi)存中RingBuffer的Tx.ring塊中的IP包(sk_buff)copy到網(wǎng)卡自身的內(nèi)存中，并生成CRC等校驗(yàn)數(shù)據(jù)形成數(shù)據(jù)鏈路包頭部并進(jìn)行網(wǎng)絡(luò)傳輸。

2. sk_buff數(shù)據(jù)結(jié)構(gòu)解析

通過對(duì)sk_buff數(shù)據(jù)結(jié)構(gòu)解析的過程中，我們回答文章頭部的幾個(gè)問題，以及窺見Linux中的一些設(shè)計(jì)思想；

進(jìn)行協(xié)議頭的增添

我們知道，按照網(wǎng)絡(luò)棧的設(shè)定，發(fā)送網(wǎng)絡(luò)包時(shí)，每經(jīng)過一層，都會(huì)增加對(duì)應(yīng)協(xié)議層的協(xié)議首部，因此Linux采用在sk_buff中的一個(gè)Union結(jié)構(gòu)體進(jìn)行標(biāo)識(shí)：

struct sk_buff {
    union {
           struct tcphdr*th; // TCP Header
           struct udphdr*uh; // UDP Header
           struct icmphdr*icmph; // ICMP Header
           struct igmphdr*igmph; 
           struct iphdr*ipiph; // IPv4 Header
           struct ipv6hdr*ipv6h; // IPv6 Header
           unsigned char*raw; // MAC Header
    } h;
}

結(jié)構(gòu)體中存儲(chǔ)的是指向內(nèi)存中各種協(xié)議的首部地址的指針，而在發(fā)送數(shù)據(jù)包的過程中，sk_buff中的data指針指向最外層的協(xié)議頭；

網(wǎng)絡(luò)包的大小占用

考慮一個(gè)包含2bytes的網(wǎng)絡(luò)包，需要包括 預(yù)留頭(64 bytes) + Mac頭(14bytes) + IP頭(20bytes) + Tcp頭(32bytes) + 有效負(fù)載為2bytes(len) + skb_shared_info(320bytes) = 452bytes，向上取整后為512bytes；sk_buff這個(gè)存儲(chǔ)結(jié)構(gòu)占用256bytes；則一個(gè)2bytes的網(wǎng)絡(luò)包需要占用512+256=768bytes(truesize)的內(nèi)存空間；

因此當(dāng)發(fā)送這個(gè)網(wǎng)絡(luò)包時(shí)：

• Case1：不存在緩沖區(qū)積壓，則新建一個(gè)sk_buff進(jìn)行網(wǎng)絡(luò)包的發(fā)送；

skb->truesize = 768 
skb->datalen  = 0 skb_shared_info 結(jié)構(gòu)有效負(fù)載 (非線性區(qū)域)
skb->len      = 2 有效負(fù)載 (線性區(qū)域 + 非線性區(qū)域(datalen)，這里暫時(shí)不考慮協(xié)議頭部)

• Case2：如果緩沖區(qū)積壓(存在未被ACK的已經(jīng)發(fā)送的網(wǎng)絡(luò)包-即SEND-Q中存在sk_buff結(jié)構(gòu))，Linux會(huì)嘗試將當(dāng)前包合并到SEND-Q的最后一個(gè)sk_buff結(jié)構(gòu)中(粘包)；考慮我們上述的768bytes的結(jié)構(gòu)體為SEND-Q的最后一個(gè)sk_buff，當(dāng)用戶進(jìn)程繼續(xù)調(diào)用write系統(tǒng)調(diào)用寫入2kb的數(shù)據(jù)時(shí)，前一個(gè)數(shù)據(jù)包還未達(dá)到MSS/MTU的限制、整個(gè)緩沖區(qū)的大小未達(dá)到SO_SENDBUF指定的限制，會(huì)進(jìn)行包的合并，packet data = 2 + 2，頭部的相關(guān)信息都可以進(jìn)行復(fù)用，因?yàn)樘捉幼志彌_區(qū)與套接字是一一對(duì)應(yīng)的；

tail_skb->truesize = 768 
tail_skb->datalen  = 0
tail_skb->len      = 4 (2 + 2)

發(fā)送窗口

我們?cè)趧?chuàng)建套接字的時(shí)候，通過SO_SENDBUF指定了發(fā)送緩沖區(qū)的大小，如果設(shè)置了大小為2048KB，則Linux在真實(shí)創(chuàng)建的時(shí)候會(huì)設(shè)置大小2048*2=4096，因?yàn)閘inux除了要考慮用戶的應(yīng)用層數(shù)據(jù)，還需要考慮linux自身數(shù)據(jù)結(jié)構(gòu)的開銷-協(xié)議頭部、指針、非線性內(nèi)存區(qū)域結(jié)構(gòu)等...

sk_buff結(jié)構(gòu)中通過sk_wmem_queued標(biāo)識(shí)發(fā)送緩沖區(qū)已經(jīng)使用的內(nèi)存大小，并在發(fā)包時(shí)檢查當(dāng)前緩沖區(qū)大小是否小于SO_SENDBUF指定的大小，如果不滿足則阻塞當(dāng)前線程，進(jìn)行睡眠，等待發(fā)送窗口中有包被ACK后觸發(fā)內(nèi)存free的回調(diào)函數(shù)喚醒后繼續(xù)嘗試發(fā)送；

接收窗口(擁塞窗口)

    |<---------- RCV.BUFF ---------------->|
          1             2            3
    |<-RCV.USER->|<--- RCV.WND ---->|
----|------------|------------------|------|----
              RCV.NXT

接收窗口主要分為3部分：

• RCV.USER 為積壓的已經(jīng)收到但尚未被用戶進(jìn)程通過read等系統(tǒng)調(diào)用獲取的網(wǎng)絡(luò)數(shù)據(jù)包；當(dāng)用戶進(jìn)程獲取后窗口的左端會(huì)向右移動(dòng)，并觸發(fā)回調(diào)函數(shù)將該數(shù)據(jù)包的內(nèi)存free掉；

• RCV.WND 為未使用的，推薦返回給該套接字的客戶端發(fā)送方當(dāng)前剩余的可發(fā)送的bytes數(shù)，即擁塞窗口的大?。?/span>

• 第三部分為未使用的，尚未預(yù)先內(nèi)存分配的，并不計(jì)算在擁塞窗口的大小中；

進(jìn)入網(wǎng)卡驅(qū)動(dòng)層

NIC (network interface card)在系統(tǒng)啟動(dòng)過程中會(huì)向系統(tǒng)注冊(cè)自己的各種信息，系統(tǒng)會(huì)分配RingBuffer隊(duì)列及一塊專門的內(nèi)核內(nèi)存區(qū)用于存放傳輸上來的數(shù)據(jù)包。每個(gè) NIC 對(duì)應(yīng)一個(gè)R x.ring 和一個(gè) Tx.ring。一個(gè) RingBuffer 上同一個(gè)時(shí)刻只有一個(gè) CPU 處理數(shù)據(jù)。

每個(gè)網(wǎng)絡(luò)包對(duì)應(yīng)的網(wǎng)卡存儲(chǔ)在sk_buff結(jié)構(gòu)的dev_input中；

RingBuffer隊(duì)列內(nèi)存放的是一個(gè)個(gè)描述符(Descriptor)，其有兩種狀態(tài)：ready 和 used。

• 初始時(shí) Descriptor 是空的，指向一個(gè)空的 sk_buff，處在 ready 狀態(tài)。

• 網(wǎng)卡收到網(wǎng)絡(luò)包：當(dāng)NIC有網(wǎng)絡(luò)數(shù)據(jù)包傳入時(shí)，DMA負(fù)責(zé)從NIC取數(shù)據(jù)，并在Rx.ring上按順序找到下一個(gè)ready的Descriptor，將數(shù)據(jù)存入該 Descriptor指向的sk_buff中，并標(biāo)記槽為used。

• 網(wǎng)卡發(fā)送網(wǎng)絡(luò)包：當(dāng)sk_buff已經(jīng)在內(nèi)核空間被寫入完成時(shí)，網(wǎng)卡的DMA Engine檢測(cè)到Tx.ring有數(shù)據(jù)包完成時(shí)，觸發(fā)DMA Copy將數(shù)據(jù)傳輸?shù)骄W(wǎng)卡內(nèi)存中，并封裝MAC幀。

不同的網(wǎng)絡(luò)包發(fā)送函數(shù)有幾次拷貝？

read then write

常見的場(chǎng)景中，當(dāng)我們要在網(wǎng)絡(luò)中發(fā)送一個(gè)文件，那么首先需要通過read系統(tǒng)調(diào)用陷入內(nèi)核態(tài)讀取 PageCache 通過CPU Copy數(shù)據(jù)頁(yè)到用戶態(tài)內(nèi)存中，接著將數(shù)據(jù)頁(yè)封裝成對(duì)應(yīng)的應(yīng)用層協(xié)議報(bào)文，并通過write系統(tǒng)調(diào)用陷入內(nèi)核態(tài)將應(yīng)用層報(bào)文CPU Copy到套接字緩沖區(qū)中，經(jīng)過TCP/IP處理后形成IP包，最后通過網(wǎng)卡的DMA Engine將RingBuffer Tx.ring中的sk_buff進(jìn)行DMA Copy到網(wǎng)卡的內(nèi)存中，并將IP包封裝為幀并對(duì)外發(fā)送。

PS：如果PageCache中不存在對(duì)應(yīng)的數(shù)據(jù)頁(yè)緩存，則需要通過磁盤DMA Copy到內(nèi)存中。

因此read then write需要兩次系統(tǒng)調(diào)用(4次上下文切換，因?yàn)橄到y(tǒng)調(diào)用需要將用戶態(tài)線程切換到內(nèi)核態(tài)線程進(jìn)行執(zhí)行)，兩次CPU Copy、兩次DMA Copy。

sendFile

用戶線程調(diào)用sendFile系統(tǒng)調(diào)用陷入內(nèi)核態(tài)，sendFile無需拷貝PageCache中的數(shù)據(jù)頁(yè)到用戶態(tài)內(nèi)存中中，而是通過內(nèi)核線程將 PageCache 中的數(shù)據(jù)頁(yè)直接通過CPU Copy拷貝到套接字緩沖區(qū)中，再經(jīng)由相同的步驟經(jīng)過一次網(wǎng)卡DMA對(duì)外傳輸。

因此sendFile需要一次系統(tǒng)調(diào)用，一次CPU Copy；

相比于write，sendFile少了一次PageCache拷貝到內(nèi)存的開銷，但是需要限制在網(wǎng)絡(luò)傳輸?shù)氖俏募?yè)，而不是用戶緩沖區(qū)中的匿名頁(yè)，并且因?yàn)橥耆趦?nèi)核態(tài)進(jìn)行數(shù)據(jù)copy，因此無法添加用戶態(tài)的協(xié)議數(shù)據(jù)；

Kafka因?yàn)榛?a target="_blank">操作系統(tǒng)文件系統(tǒng)進(jìn)行數(shù)據(jù)存儲(chǔ)，并且文件量比較大，因此比較適合通過sendFile進(jìn)行網(wǎng)絡(luò)傳輸?shù)膶?shí)現(xiàn)；

但是sendFile仍然需要一次內(nèi)核線程的CPU Copy，因此零拷貝更偏向于無需拷貝用戶態(tài)空間中的數(shù)據(jù)。

mmap + write

相比于sendFile直接在內(nèi)核態(tài)進(jìn)行文件傳輸，mmap則是通過在進(jìn)程的虛擬地址空間中映射PageCache，再經(jīng)過write進(jìn)行網(wǎng)絡(luò)寫入；比較適用于小文件的傳輸，因?yàn)閙map并沒有立即將數(shù)據(jù)拷貝到用戶態(tài)空間中，所以較大文件會(huì)導(dǎo)致頻繁觸發(fā)虛擬內(nèi)存的 page fault 缺頁(yè)異常；

RocketMQ 選擇了 mmap+write 這種零拷貝方式，適用于消息這種小塊文件的數(shù)據(jù)持久化和傳輸。