訂閱
糾錯(cuò)
加入自媒體

Linux內(nèi)核源代碼:tcp/ip協(xié)議棧的調(diào)用

6 數(shù)據(jù)鏈路層流程

6.1 發(fā)送端

功能上,在物理層提供比特流服務(wù)的基礎(chǔ)上,建立相鄰結(jié)點(diǎn)之間的數(shù)據(jù)鏈路,通過(guò)差錯(cuò)控制提供數(shù)據(jù)幀(Frame)在信道上無(wú)差錯(cuò)的傳輸,并進(jìn)行各電路上的動(dòng)作系列。

數(shù)據(jù)鏈路層在不可靠的物理介質(zhì)上提供可靠的傳輸。

該層的作用包括:物理地址尋址、數(shù)據(jù)的成幀、流量控制、數(shù)據(jù)的檢錯(cuò)、重發(fā)等。在這一層,數(shù)據(jù)的單位稱為幀(frame)。數(shù)據(jù)鏈路層協(xié)議的代表包括:SDLC、HDLC、PPP、STP、幀中繼等。

實(shí)現(xiàn)上,Linux 提供了一個(gè) Network device 的抽象層,其實(shí)現(xiàn)在 linux/net/core/dev.c。具體的物理網(wǎng)絡(luò)設(shè)備在設(shè)備驅(qū)動(dòng)中(driver.c)需要實(shí)現(xiàn)其中的虛函數(shù)。Network Device 抽象層調(diào)用具體網(wǎng)絡(luò)設(shè)備的函數(shù)。

發(fā)送端調(diào)用dev_queue_xmit,這個(gè)函數(shù)實(shí)際上調(diào)用__dev_queue_xmit:

發(fā)現(xiàn)它調(diào)用了dev_h(yuǎn)ard_start_xmit函數(shù):

調(diào)用xmit_one:

調(diào)用trace_net_dev_start_xmit,實(shí)際上調(diào)用__net_dev_start_xmit函數(shù):

到此,調(diào)用鏈結(jié)束。gdb調(diào)試如下:

6.2 接收端

簡(jiǎn)要過(guò)程:

一個(gè) package 到達(dá)機(jī)器的物理網(wǎng)絡(luò)適配器,當(dāng)它接收到數(shù)據(jù)幀時(shí),就會(huì)觸發(fā)一個(gè)中斷,并將通過(guò) DMA 傳送到位于 linux kernel 內(nèi)存中的 rx_ring。

網(wǎng)卡發(fā)出中斷,通知 CPU 有個(gè) package 需要它處理。中斷處理程序主要進(jìn)行以下一些操作,包括分配 skb_buff 數(shù)據(jù)結(jié)構(gòu),并將接收到的數(shù)據(jù)幀從網(wǎng)絡(luò)適配器I/O端口拷貝到skb_buff 緩沖區(qū)中;

從數(shù)據(jù)幀中提取出一些信息,并設(shè)置 skb_buff 相應(yīng)的參數(shù),這些參數(shù)將被上層的網(wǎng)絡(luò)協(xié)議使用,例如skb->protocol;

終端處理程序經(jīng)過(guò)簡(jiǎn)單處理后,發(fā)出一個(gè)軟中斷(NET_RX_SOFTIRQ),通知內(nèi)核接收到新的數(shù)據(jù)幀。

內(nèi)核 2.5 中引入一組新的 API 來(lái)處理接收的數(shù)據(jù)幀,即 NAPI。所以,驅(qū)動(dòng)有兩種方式通知內(nèi)核:(1) 通過(guò)以前的函數(shù)netif_rx;(2)通過(guò)NAPI機(jī)制。該中斷處理程序調(diào)用 Network device的 netif_rx_schedule 函數(shù),進(jìn)入軟中斷處理流程,再調(diào)用 net_rx_action 函數(shù)。

該函數(shù)關(guān)閉中斷,獲取每個(gè) Network device 的 rx_ring 中的所有 package,最終 pacakage 從 rx_ring 中被刪除,進(jìn)入 netif _receive_skb 處理流程。

netif_receive_skb 是鏈路層接收數(shù)據(jù)報(bào)的最后一站。它根據(jù)注冊(cè)在全局?jǐn)?shù)組 ptype_all 和 ptype_base 里的網(wǎng)絡(luò)層數(shù)據(jù)報(bào)類型,把數(shù)據(jù)報(bào)遞交給不同的網(wǎng)絡(luò)層協(xié)議的接收函數(shù)(INET域中主要是ip_rcv和arp_rcv)。該函數(shù)主要就是調(diào)用第三層協(xié)議的接收函數(shù)處理該skb包,進(jìn)入第三層網(wǎng)絡(luò)層處理。

入口函數(shù)是net_rx_action:

發(fā)現(xiàn)調(diào)用napi_poll,實(shí)質(zhì)上調(diào)用napi_gro_receive函數(shù):

napi_gro_receive 會(huì)直接調(diào)用 netif_receive_skb_core。而它會(huì)調(diào)用__netif_receive_skb_one_core,將數(shù)據(jù)包交給上層 ip_rcv 進(jìn)行處理。

調(diào)用結(jié)束之后,通過(guò)軟中斷通知CPU,至此,調(diào)用鏈結(jié)束。gdb驗(yàn)證如下:

7 物理層流程

7.1 發(fā)送端

物理層在收到發(fā)送請(qǐng)求之后,通過(guò) DMA 將該主存中的數(shù)據(jù)拷貝至內(nèi)部RAM(buffer)之中。在數(shù)據(jù)拷貝中,同時(shí)加入符合以太網(wǎng)協(xié)議的相關(guān)header,IFG、前導(dǎo)符和CRC。對(duì)于以太網(wǎng)網(wǎng)絡(luò),物理層發(fā)送采用CSMA/CD,即在發(fā)送過(guò)程中偵聽(tīng)鏈路沖突。

一旦網(wǎng)卡完成報(bào)文發(fā)送,將產(chǎn)生中斷通知CPU,然后驅(qū)動(dòng)層中的中斷處理程序就可以刪除保存的 skb 了。

7.2 接收端

一個(gè) package 到達(dá)機(jī)器的物理網(wǎng)絡(luò)適配器,當(dāng)它接收到數(shù)據(jù)幀時(shí),就會(huì)觸發(fā)一個(gè)中斷,并將通過(guò) DMA 傳送到位于 linux kernel 內(nèi)存中的 rx_ring。

網(wǎng)卡發(fā)出中斷,通知 CPU 有個(gè) package 需要它處理。中斷處理程序主要進(jìn)行以下一些操作,包括分配 skb_buff 數(shù)據(jù)結(jié)構(gòu),并將接收到的數(shù)據(jù)幀從網(wǎng)絡(luò)適配器I/O端口拷貝到skb_buff 緩沖區(qū)中;從數(shù)據(jù)幀中提取出一些信息,并設(shè)置 skb_buff 相應(yīng)的參數(shù),這些參數(shù)將被上層的網(wǎng)絡(luò)協(xié)議使用,例如skb->protocol;

終端處理程序經(jīng)過(guò)簡(jiǎn)單處理后,發(fā)出一個(gè)軟中斷(NET_RX_SOFTIRQ),通知內(nèi)核接收到新的數(shù)據(jù)幀。

內(nèi)核 2.5 中引入一組新的 API 來(lái)處理接收的數(shù)據(jù)幀,即 NAPI。所以,驅(qū)動(dòng)有兩種方式通知內(nèi)核:(1) 通過(guò)以前的函數(shù)netif_rx;(2)通過(guò)NAPI機(jī)制。該中斷處理程序調(diào)用 Network device的 netif_rx_schedule 函數(shù),進(jìn)入軟中斷處理流程,再調(diào)用 net_rx_action 函數(shù)。

該函數(shù)關(guān)閉中斷,獲取每個(gè) Network device 的 rx_ring 中的所有 package,最終 pacakage 從 rx_ring 中被刪除,進(jìn)入 netif _receive_skb 處理流程。

netif_receive_skb 是鏈路層接收數(shù)據(jù)報(bào)的最后一站。它根據(jù)注冊(cè)在全局?jǐn)?shù)組 ptype_all 和 ptype_base 里的網(wǎng)絡(luò)層數(shù)據(jù)報(bào)類型,把數(shù)據(jù)報(bào)遞交給不同的網(wǎng)絡(luò)層協(xié)議的接收函數(shù)(INET域中主要是ip_rcv和arp_rcv)。該函數(shù)主要就是調(diào)用第三層協(xié)議的接收函數(shù)處理該skb包,進(jìn)入第三層網(wǎng)絡(luò)層處理。

8 時(shí)序圖展示和總結(jié)

時(shí)序圖如下:

本次實(shí)驗(yàn)主要是通過(guò)分析Linux內(nèi)核源代碼,一步步地通過(guò)gdb進(jìn)行調(diào)試函數(shù)調(diào)用鏈,最終清楚了tcp/ip協(xié)議棧的調(diào)用過(guò)程。因?yàn)闀r(shí)間有限,部分細(xì)節(jié)可能會(huì)有錯(cuò)誤,希望讀者多加指正。

<上一頁(yè)  1  2  3  4  
聲明: 本文由入駐維科號(hào)的作者撰寫,觀點(diǎn)僅代表作者本人,不代表OFweek立場(chǎng)。如有侵權(quán)或其他問(wèn)題,請(qǐng)聯(lián)系舉報(bào)。

發(fā)表評(píng)論

0條評(píng)論,0人參與

請(qǐng)輸入評(píng)論內(nèi)容...

請(qǐng)輸入評(píng)論/評(píng)論長(zhǎng)度6~500個(gè)字

您提交的評(píng)論過(guò)于頻繁,請(qǐng)輸入驗(yàn)證碼繼續(xù)

  • 看不清,點(diǎn)擊換一張  刷新

暫無(wú)評(píng)論

暫無(wú)評(píng)論

    掃碼關(guān)注公眾號(hào)
    OFweek人工智能網(wǎng)
    獲取更多精彩內(nèi)容
    文章糾錯(cuò)
    x
    *文字標(biāo)題:
    *糾錯(cuò)內(nèi)容:
    聯(lián)系郵箱:
    *驗(yàn) 證 碼:

    粵公網(wǎng)安備 44030502002758號(hào)