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ò)誤,希望讀者多加指正。

發(fā)表評(píng)論
請(qǐng)輸入評(píng)論內(nèi)容...
請(qǐng)輸入評(píng)論/評(píng)論長(zhǎng)度6~500個(gè)字
最新活動(dòng)更多
-
3月27日立即報(bào)名>> 【工程師系列】汽車電子技術(shù)在線大會(huì)
-
4月30日立即下載>> 【村田汽車】汽車E/E架構(gòu)革新中,新智能座艙挑戰(zhàn)的解決方案
-
5月15-17日立即預(yù)約>> 【線下巡回】2025年STM32峰會(huì)
-
即日-5.15立即報(bào)名>>> 【在線會(huì)議】安森美Hyperlux™ ID系列引領(lǐng)iToF技術(shù)革新
-
5月15日立即下載>> 【白皮書(shū)】精確和高效地表征3000V/20A功率器件應(yīng)用指南
-
5月16日立即參評(píng) >> 【評(píng)選啟動(dòng)】維科杯·OFweek 2025(第十屆)人工智能行業(yè)年度評(píng)選
推薦專題
- 1 UALink規(guī)范發(fā)布:挑戰(zhàn)英偉達(dá)AI統(tǒng)治的開(kāi)始
- 2 北電數(shù)智主辦酒仙橋論壇,探索AI產(chǎn)業(yè)發(fā)展新路徑
- 3 “AI寒武紀(jì)”爆發(fā)至今,五類新物種登上歷史舞臺(tái)
- 4 降薪、加班、裁員三重暴擊,“AI四小龍”已折戟兩家
- 5 國(guó)產(chǎn)智駕迎戰(zhàn)特斯拉FSD,AI含量差幾何?
- 6 光計(jì)算迎來(lái)商業(yè)化突破,但落地仍需時(shí)間
- 7 東陽(yáng)光:2024年扭虧、一季度凈利大增,液冷疊加具身智能打開(kāi)成長(zhǎng)空間
- 8 地平線自動(dòng)駕駛方案解讀
- 9 封殺AI“照騙”,“淘寶們”終于不忍了?
- 10 優(yōu)必選:營(yíng)收大增主靠小件,虧損繼續(xù)又逢關(guān)稅,能否乘機(jī)器人東風(fēng)翻身?