結(jié)合pppoe協(xié)議分析Linux網(wǎng)絡(luò)棧的實現(xiàn)方式

這個標題起得比較糾結(jié)，之前熟知的PPPOE是作為PPP協(xié)議的底層載體，而實際上它也是一個完整的協(xié)議，不過它的實現(xiàn)比較簡單，由它出發(fā)，可以很容易理清楚Linux網(wǎng)絡(luò)棧的實現(xiàn)方式。

1.總述

Linux中用戶空間的網(wǎng)絡(luò)編程，是以socket為接口，一般創(chuàng)建一個sockfd = socket(family,type,protocol)，之后以該sockfd為參數(shù)，進行各種系統(tǒng)調(diào)用來實現(xiàn)網(wǎng)絡(luò)通信功能。其中family指明使用哪種協(xié)議域（如INET、UNIX等），protocol指明該協(xié)議域中具體哪種協(xié)議（如INET中的TCP、UDP等），type表明該接口的類型（如STREAM、DGRAM等），一般設(shè)protocol=0，那么就會用該family中該type類型的默認協(xié)議（如INET中的STREAM默認就是TCP協(xié)議）。

Linux中利用module機制，層次分明地實現(xiàn)了這套協(xié)議體系，并具有很好的擴展性，其基本模塊構(gòu)成如下：

先看右邊，頂層的socket模塊提供一個sock_register()函數(shù)，供各個協(xié)議域模塊使用，在全局的net_family[]數(shù)組中增加一項；各個協(xié)議域模塊也提供一個類似的register_xx_proto()函數(shù)，供各個具體的協(xié)議使用，在該協(xié)議域私有的xx_proto[]數(shù)組中增加一項。這兩個數(shù)組中的存放的都是指針，指向的數(shù)據(jù)結(jié)構(gòu)如下圖所示：

很明顯它們是用來創(chuàng)建不同類型的socket接口的，且是一種分層次的創(chuàng)建過程，可想而知，頂層socket_create()完成一些共有的操作，如分配內(nèi)存等，然后調(diào)用下一層create；協(xié)議域內(nèi)的create()完成一些該協(xié)議域內(nèi)共有的初始化工作；最后具體協(xié)議中的create()完成協(xié)議特有的初始化。具體的下一節(jié)講。

再來看上圖右邊的，也是頂層socket模塊提供的4個函數(shù)，前兩個一般由具體協(xié)議模塊調(diào)用，由于協(xié)議棧與應用層的交互，具體的后面會講到。后兩個一般有協(xié)議域模塊調(diào)用，用于底層設(shè)備與協(xié)議棧間的交互。但這也不絕對，如在PPPOE協(xié)議中，這4個函數(shù)都由具體協(xié)議模塊調(diào)用，這是因為PPPOX協(xié)議域內(nèi)的共有部分不多，各個協(xié)議間幾乎獨立。這4個函數(shù)的功能及所用到的數(shù)據(jù)結(jié)構(gòu)，在后面具體用到時會詳細說明。

2.socket插口創(chuàng)建

首先來看一下最終創(chuàng)建好的socket插口由哪些部分組成，該結(jié)構(gòu)是相當龐大的，這里只給出框架：

基本屬性有state（listen、accept等），flags標志（blocked等），type類型，這里family和protocol都沒有了，因為它們再創(chuàng)建時使用過了，已經(jīng)被融入到socket結(jié)構(gòu)中。

File指針指向一個file結(jié)構(gòu)，在Linux中一個socket也被抽象為一個文件，所以在應用層一般通過標準的文件操作來操作它。

Ops指向一個struct proto_ops結(jié)構(gòu)，它是每種協(xié)議特有的，應用層的系統(tǒng)調(diào)用，最終映射到網(wǎng)絡(luò)棧中具體協(xié)議的操作方法。

Sk指向一個struct sock結(jié)構(gòu)，而該結(jié)構(gòu)在分配空間時，多分配了一點以作為該協(xié)議的私有部分，這里包含了該協(xié)議的具體信息，內(nèi)容相當多。首先是一個struct sock_common結(jié)構(gòu)，包含了協(xié)議的基本信息；然后是一個sk_prot_create指針，指向一個struct proto結(jié)構(gòu)體，該結(jié)構(gòu)體就是第一節(jié)中所述的，用proto_regsiter()注冊到內(nèi)核中的，它包含應用層到協(xié)議棧的交互操作和信息（也可以說成是Appàtransport layer的交互信息）；然后還有一個sk_backlog_rcv函數(shù)指針，所指函數(shù)在協(xié)議棧處理完接收到的包之后調(diào)用，一般僅是把數(shù)據(jù)包放到該socket的接收隊列中，等待APP讀?。蛔詈髤f(xié)議的私有部分里存放該協(xié)議的私有信息，如pppoe的sessionID、daddr，tcp的連接4元組等，這些信息很重要，利用它們來區(qū)分同一個協(xié)議中的多個socket。

創(chuàng)建的總體過程，第一節(jié)已講過了，下面以pppoe為例，描述一個socket插口的具體創(chuàng)建過程：

之前所述的關(guān)鍵點這里幾乎都涉及到了，要注意的是這里的struct proto結(jié)構(gòu)非常簡單，因為PPPOE協(xié)議幾乎沒有傳輸層，所以不需要有太多的中間操作，僅需要一個obj_size來指明struct sock結(jié)構(gòu)后需分配的私有結(jié)構(gòu)大小，關(guān)于私有結(jié)構(gòu)的內(nèi)容，一般在connect操作時才能初始化。

創(chuàng)建好socket之后，其中的fops，proto_ops，sk_backlog_rcv等操作是如何作用，來實現(xiàn)網(wǎng)絡(luò)通信的功能？這是后面要講述的內(nèi)容。

3.主動過程

主動過程即在應用層中通過系統(tǒng)調(diào)用，觸發(fā)socket完成某種動作，有些系統(tǒng)調(diào)用和標準的文件操作類似，因此可以直接用sockfd的fops來描述，如read、write、ioctl等，有些則是socket接口特有的，需重新定義系統(tǒng)調(diào)用接口，Linux中用SYSCALL_DEFINEn()宏來定義系統(tǒng)調(diào)用接口，如bind、accept等。這些系統(tǒng)調(diào)用一般都很簡單，最終都會去調(diào)用socket內(nèi)部proto_ops中的接口函數(shù)。

如下圖所示，在socket層，并不是所有的文件操作都適用于socket，因此其特有的socket_file_ops中只指定了部分函數(shù)；另外還封裝了幾個系統(tǒng)調(diào)用，是我們熟悉的bind、listen、connect、accept。這些系統(tǒng)調(diào)用接口都是靜態(tài)的，它們一般經(jīng)過簡單的處理，就調(diào)用具體socket中的proto_ops操作。

在協(xié)議棧中，主要是socket特有的proto_ops操作，但對于一些復雜的協(xié)議，如TCP，還需要其它一些操作來支持，這些接口都放在struct sock中的struct proto中。PPPOE協(xié)議比較簡單，不需要struct proto的操作來支持，但其中的obj_size仍然重要，如前所述。

如上圖所示，PPPOE協(xié)議中，并不是所有協(xié)議操作都需要，如bind、accept等，下面選幾個來詳細看一下socket的主動過程的工作。

Ioctl系統(tǒng)調(diào)用：ioctl是通過標準的文件操作來調(diào)用的，具體如下圖所示：

其中頂層sock_ioctl中，對于一些特殊情況，如VLAN、BRIDGE等，它們并不是要對socket插口本身操作，而是要調(diào)用VLAN、BRIDGE模塊中的創(chuàng)建函數(shù)，這看起來有點格格不入，但為了操作方便，且保證網(wǎng)絡(luò)相關(guān)的操作都封裝在socket中，這么做也是不得已。

在pppoe_ioctl中，根據(jù)cmd進行相應操作，其中有一個值得注意的，就是PPPIOCGCHAN選項，它使得該pppoe_socket成為一個特殊的channel，這主要是pppoe為了給ppp協(xié)議提供服務(wù)而特有的，與網(wǎng)絡(luò)協(xié)議棧關(guān)系不大，以后會具體看。

Read系統(tǒng)調(diào)用：read也是標準的文件操作，但要注意，在網(wǎng)絡(luò)棧中，read并不是接收過程，而僅是從該sock的接收隊列中取出skb，提交給應用層，如下圖所示。而這些skb是如何獲得的，那是一個復雜的被動過程，下面再講。

Connect系統(tǒng)調(diào)用：connect是socket.c中封裝的一個系統(tǒng)特用，其代碼也很簡單，最終調(diào)用協(xié)議棧中的pppoe_connect接口，該接口函數(shù)是pppoe協(xié)議中一個非常重要的操作，具體如下圖所示：

首先先一下通配地址的問題，這是network programming中一個基本問題，因為各個協(xié)議用到的地址結(jié)構(gòu)不同，在應用層，為了方便可讀性，可以用協(xié)議特有的地址結(jié)構(gòu)，只要符標準的模式即可（即第一個元素為family），然后強制轉(zhuǎn)換成sockaddr*類型，傳遞給通用的系統(tǒng)調(diào)用接口。在最終調(diào)用協(xié)議模塊中的接口函數(shù)時，再轉(zhuǎn)換回來。

再看pppoe_connect中，首先由sock結(jié)構(gòu)指針得到pn指針，它們是分配在一起的（如前所述），這很容易得到，同時還得到pppoe_net結(jié)構(gòu)的指針（它是該協(xié)議中全局共有的）。然后把用戶傳遞進來的addr的數(shù)據(jù)放到socket中來，并且執(zhí)行一個set_item函數(shù)，該函數(shù)主要根據(jù)addr信息，把該socket指針放到協(xié)議全局的pppoe_net結(jié)構(gòu)中（這一步對接收過程很重要，后面會細講）。最后初始化了該socket中特有的chan結(jié)構(gòu)，并調(diào)用ppp_register_net_channel()，這主要為ppp服務(wù)，以后再看。

4.發(fā)送流程

這也是一個主動過程，在協(xié)議體系中，它是一個比較重要的過程，所以單獨列出來。Socket框架中，發(fā)送過程是通過標準的文件操作write完成的， socket的write操作為sock_aio_write()，最終會調(diào)用proto_ops->sendmsg()函數(shù)，即pppoe模塊中的pppoe_sendmsg()，如下圖所示：

首先從sock中獲得相關(guān)信息，最重要的當然是dev設(shè)備，因為pppoe的設(shè)備是選定的（由useraddr提供），而有些協(xié)議如IP，則會根據(jù)協(xié)議地址，有協(xié)議棧自動選擇dev。然后分配skb，并準備其中的package，這是每個協(xié)議的關(guān)鍵，由于pppoe協(xié)議很簡單，只需要設(shè)置好一個pppoe header即可。最后直接調(diào)用dev_queue_xmit(skb)，通過設(shè)備將該package發(fā)送出去。

5.網(wǎng)絡(luò)協(xié)議棧結(jié)構(gòu)小結(jié)

這里想講一下的是，pppoe到底是什么層的協(xié)議，鏈路層。而通過上面的描述，更準確的說法應該是，pppoe是一個完整的協(xié)議，是從應用層到設(shè)備之間的協(xié)議模塊，從這個意義上來講，它和INET域中的協(xié)議是等價的。如下圖所示：

這里講的協(xié)議是從應用層往下直到物理設(shè)備的完整過程，有些協(xié)議具有一定的相似性，（如TCP、UDP，還包括裸IP等都以IP協(xié)議為基礎(chǔ)），則把它們歸為一個協(xié)議域內(nèi)。至于協(xié)議分層，則是概念上的，如PPPOE協(xié)議的主要功能體現(xiàn)在鏈路層，則一般稱它為鏈路層協(xié)議， 而狹義上稱TCP、UDP為傳輸層協(xié)議（而前面講的廣義上的TCP、UDP則是包括傳輸層、以IP為基礎(chǔ)的網(wǎng)絡(luò)層、鏈路層的完整協(xié)議）。

有點饒人，不過沒關(guān)系，只要理解協(xié)議棧的功能就是從socket接口得到數(shù)據(jù)，封裝成一定的包結(jié)構(gòu)，最終由物理設(shè)備發(fā)送出去（接收過程反過來）。至于具體的實現(xiàn)，則是由具體協(xié)議的特點決定的，對于一些復雜協(xié)議，分層方式則是一種比較好的選擇。

而其中有些協(xié)議會比較特殊，如之前講的VLAN，它甚至從來都不會進入到協(xié)議棧，僅在設(shè)備驅(qū)動層，就被轉(zhuǎn)化成以太網(wǎng)協(xié)議，協(xié)議棧中根本不需要為它準備處理接口。再如比較典型的ICMP協(xié)議，它既可以是一個完整的協(xié)議，被應用層調(diào)用（如典型的Ping程序），也可以只作為TCP的附屬協(xié)議（只被TCP處理，對應用層不可見）。這里的PPPOE與此很類似，本文講述了其作為完整協(xié)議的工作方式，另外它也可以作為PPP協(xié)議的底層基礎(chǔ)，在下一篇中會講述其具體的實現(xiàn)方法。

6.被動過程-接收流程

接收過程是一個被動過程，在屋里設(shè)備層，它往往是由中斷觸發(fā)，其實現(xiàn)的復雜度也較發(fā)送過程高很多。在協(xié)議棧中，其實現(xiàn)也同樣與發(fā)送過程很不對稱。因為發(fā)送時，本身主機擁有控制權(quán)，而接收時，是一個數(shù)據(jù)包對多個接收模塊（一對多），只能從數(shù)據(jù)包中的信息中一點一點分析，并去尋找接收模塊。

先給出接收流程的框架，再逐步去分析其實現(xiàn)。如下圖所示：

先不看橙色部分，一個接收流程由物理設(shè)備的中斷觸發(fā)，設(shè)備驅(qū)動程序進行相應處理，得到協(xié)議棧中標準的數(shù)據(jù)結(jié)構(gòu)sk_buff（簡稱skb），并根據(jù)一個特殊的全局數(shù)據(jù)結(jié)構(gòu)packet_type，將數(shù)據(jù)交給相應的協(xié)議；協(xié)議根據(jù)自身設(shè)計特點對skb數(shù)據(jù)進行處理，并通過全局變量xx_net_id和各個協(xié)議私有的特殊數(shù)據(jù)結(jié)構(gòu)xx_net，尋找到該數(shù)據(jù)包對應的應用層socket插口，并將其放在該socket插口的接收隊列中；最后應用層在某個時刻會通過read系統(tǒng)調(diào)用讀取該數(shù)據(jù)（如第3節(jié)所講）。

6.1設(shè)備驅(qū)動層的處理

設(shè)備驅(qū)動層的接收過程在之前的篇章中已經(jīng)講過了，一般是由硬件中斷觸發(fā)，然后或是采用中斷模式、或是采用NAPI模式，總之其根本任務(wù)就是：根據(jù)設(shè)備的特點（先驗知識，如以太網(wǎng)設(shè)備驅(qū)動事先就是知道以太網(wǎng)幀的基本結(jié)構(gòu)的），將接收到的裸數(shù)據(jù)轉(zhuǎn)換成協(xié)議棧所認識的標準結(jié)構(gòu)skb（從而實現(xiàn)底層設(shè)備對上層的透明性），然后提交給相應的協(xié)議。很明顯問題有兩個，skb是什么樣的，要準備什么？怎么知道提交給誰？

準備skb結(jié)構(gòu)。首先來看一下sk_buff的構(gòu)成，如下圖所示。Skb只是一個控制結(jié)構(gòu)，實際的數(shù)據(jù)放在一個data_buf中，并由skb中一些列參數(shù)索引，具體見下圖右所示，這之中有些參數(shù)是在分配data_buf、copy數(shù)據(jù)時就決定的，如head、end、data、tail等；有些則要經(jīng)過一定的識別才能得到，如mac_header一般在設(shè)備驅(qū)動中得到，而network_header、transport_header則要到協(xié)議棧中才知道，且各個協(xié)議的處理各不相同，如PPPOE協(xié)議根本不需要只需要指明network_header，而TCP協(xié)議則有復雜的頭部信息。最終由skb->data指針和頭部長可得到app_data的位置，因此應用層可以只讀取應用數(shù)據(jù)即可。

Skb中另外一些參數(shù)也相當重要，如vlan_tci用于指明vlan的id，其用法在前面已講過。dev參數(shù)則是要貫穿整個流程的，因為該龐大結(jié)構(gòu)中的多個信息會在整個網(wǎng)絡(luò)系統(tǒng)中用到，要注意的是該參數(shù)由設(shè)備驅(qū)動程序決定，一般就是接收的物理設(shè)備，但在Linux中，網(wǎng)絡(luò)設(shè)備是由net_device結(jié)構(gòu)指示的，一個物理設(shè)備可有多個協(xié)議設(shè)備，這在VLAN、BRIDGE中很明顯，其實在PPP協(xié)議中，這也是一個關(guān)鍵點，后面會講到。Sk參數(shù)指示了該數(shù)據(jù)包屬于哪個應用層socket插口，它由具體協(xié)議根據(jù)特定方法得到，后面會講到。Protocol參數(shù)是本節(jié)的重點，它由mac_header中的字節(jié)決定。

設(shè)備驅(qū)動程序只關(guān)心mac_header，即數(shù)據(jù)包最初始的部分。前面也提到了，這需要一定的先驗知識，如ethernet設(shè)備驅(qū)動，它先驗的指導以太網(wǎng)頭部由DMAC、SMAC和兩字節(jié)的協(xié)議構(gòu)成，下面是一個RTL8012驅(qū)動的接收片段（~/dev/net/Ethernet/realtek/apt.c）：

提交協(xié)議棧。主要就是根據(jù)skb->protocol參數(shù)，當然還需要另一個重要的數(shù)據(jù)結(jié)構(gòu)packet_type。

設(shè)備驅(qū)動中最后提交過程有netif_skb_receive()函數(shù)完成，它會遍歷系統(tǒng)中所有的packet_type，找到protocol和dev（這個是啥意思）都相同，就調(diào)用該ptype中的func函數(shù)，如ip_packet中的func為ip_rcv()函數(shù)，這樣skb就到了協(xié)議棧中。

系統(tǒng)中所有全局的packet_type構(gòu)成一個list，并由全局變量ptype_all索引，另外還提供ptype_base[]全局數(shù)組，將type相同的packet_type單獨成鏈，為遍歷提供方便。

這些全局的packet_type結(jié)構(gòu)是從哪來的，這就要看第一節(jié)圖中，左邊4個函數(shù)中的一個dev_add_packet(struct packet_type*)。協(xié)議模塊在加載時，調(diào)用該函數(shù)，將自己特有的packet_type結(jié)構(gòu)注冊進內(nèi)核中，而其中的(*func)則有協(xié)議自己定義。

最后要注意的是，打開if_ether.h文件，可以看到現(xiàn)在已定義的協(xié)議protocol有_P_IP、_P_ARP、_P_8021Q、_P_PPP_SES、_P_PPP_DIS等，如果根據(jù)傳統(tǒng)的分層協(xié)議來看它們，會覺得很亂，有網(wǎng)絡(luò)層的、鏈路層的、甚至同一種協(xié)議還有兩個，但如果用第5節(jié)的概念來看，則很容易理解。再看由什么模塊注冊，TCP、UDP都是以IP協(xié)議為基礎(chǔ)，只要有INET協(xié)議域模塊注冊一個即可，而ARP雖然也屬于INET域，但它卻必須自己有一個packet_type，PPPOE協(xié)議雖然只是一個協(xié)議，但卻有兩個階段，所以它有兩個不同的packet_tpye?？梢娺@種實現(xiàn)是很靈活的，根據(jù)具體協(xié)議的特點決定。

6.2協(xié)議棧接收處理

協(xié)議棧的處理由各協(xié)議決定，如TCP協(xié)議的處理過程是相當復雜的，而這里的pppoe的處理卻非常簡單，但由它卻可以避開細節(jié)，更清楚地看到流程的梗概，如下圖所示：

可以看到pppoe協(xié)議的處理過程幾乎沒有，僅是設(shè)置了skb的network_header, transport_header，然后就利用get_item()函數(shù)找到它所屬的socket插口，直接把它提交給上層。如上圖右所示，是典型的TCP接收流程，是相當復雜的，其中TCP與IP的接頭處還需用到額外的私有數(shù)據(jù)結(jié)構(gòu)。

提交函數(shù)sk_backlog_rcv，即這里的pppoe_rcv_core(sk,skb)函數(shù)，首先判斷是否為ppp通道的數(shù)據(jù)，若是則提交給ppp協(xié)議。一般正常情況下，直接用sock_queue_rcv_skb(sk,skb)函數(shù)將它放在socket的接收隊列中。

匹配應用層接口：協(xié)議棧在對數(shù)據(jù)包進行處理后，需要確定該包屬于哪個socket插口，這個過程在內(nèi)核中有一套完整的機制來完成，其框架如下圖所示：

首先內(nèi)核有個全局結(jié)構(gòu)net_generic，其中一個最重要的元素是指針數(shù)組。然后每個協(xié)議module加載時，會調(diào)用register_pernet_device(struct pernet_operations*)（見第一節(jié)圖），pernet_operations結(jié)構(gòu)中最關(guān)鍵的兩個參數(shù)，一個是size，它指示內(nèi)核為該模塊分配一個私有數(shù)據(jù)結(jié)構(gòu)（如pppoe即為struct pppoe_net），另一個是xx_net_id，它指示由net_generic.ptr[xx_net_id]來指向該數(shù)據(jù)結(jié)構(gòu)，這樣每個協(xié)議模塊中，就可以根據(jù)自己的xx_net_id很容易尋找到內(nèi)核分配給自己的私有結(jié)構(gòu)。最后協(xié)議的私有模塊中一般也有一個指針數(shù)組，用以索引屬于它的各個socket。

工作流程就很清楚了，具體的工作方式還要看兩個函數(shù)，

就不看細節(jié)了，僅看兩個函數(shù)的原型就能明白，其中pn參數(shù)就是上面所述的用全局結(jié)構(gòu)net_generic和各協(xié)議私有xx_net_id獲得的。Set_item()函數(shù)在connect時調(diào)用（參見第3節(jié)），它根據(jù)pppox_sock中的sessionID、remoteMAC（這兩個參數(shù)由*useraddr傳入，詳見下一篇協(xié)議分析），根據(jù)一個hash算法得到一個hashInt值，然后用pn->hash_ptr[hashInt]指向該socket結(jié)構(gòu)。那反過來，接收時由這兩個參數(shù)（由數(shù)據(jù)包的協(xié)議頭中獲得）得到hashInt，便能很容易找到對應的socket了。

各個協(xié)議使用的方法及參數(shù)都不同，但思路都一樣，就是依據(jù)協(xié)議本身特有的參數(shù)（如TCP中的連接4元組），在socket創(chuàng)建、或連接的時候（接收數(shù)據(jù)之前），根據(jù)一定的算法，將它的指針放在該協(xié)議私有的xx_net中，這樣接收時就可以由數(shù)據(jù)報的協(xié)議參數(shù)找到它了。

6.3命名空間namespace

上述的socket索引方法有個繞彎的地方：就是每個協(xié)議私有的xx_net結(jié)構(gòu)可以直接由協(xié)議模塊本身分配，索引起來也方便，不要用到全局的net_generic。而目前內(nèi)核所用的方法，其實是為了另外的目的，那就是命名空間namespace。也就是虛擬多用戶的一套機制，具體的也沒細看，好像目前內(nèi)核整個namespace還沒有全部完成。

network的命名空間問題主要在于，每個協(xié)議模塊的xx_net私有結(jié)構(gòu)不僅是一個，而是由內(nèi)核全局決定的，即每注冊一個新的用戶（有點像虛擬機機制），就分配一個新的xx_net結(jié)構(gòu)，這樣多用戶間可以用參數(shù)相同的socket連接，但卻指向不同的socket。

可以看到前面所述的很多內(nèi)容中，都會有個net參數(shù)，就是為了這個作用，主要實現(xiàn)函數(shù)在namespace.c中。

7.總結(jié)

主要結(jié)合pppoe協(xié)議，學習了Linux中網(wǎng)絡(luò)棧的實現(xiàn)。由于pppoe協(xié)議本身很簡單，代碼量少，更容易抓住協(xié)議實現(xiàn)的梗概。Linux網(wǎng)絡(luò)棧，繼承Unix，采用socket插口作為主線，主要包括創(chuàng)建、協(xié)議連接、主動過程、匹配機制、被動過程等內(nèi)容。

要注意的是，實際應用中，很少有直接利用pppoe協(xié)議通信的，而是把它作為ppp協(xié)議的底層基礎(chǔ)來用，而這需要協(xié)議實現(xiàn)中的一些技巧來支持。
編輯：hfy