基于Linux內(nèi)核模式的PPPoE優(yōu)化與實現(xiàn)
PPPOE(Point.to.Point Protoeol over Ethernet)是將PPP協(xié)議封裝在以太網(wǎng)幀上進行傳輸,它的通信過程分為探測(Discovery)和PPP會話(Session)2個階段。PPPoE Discovery階段主要是客戶機確定AC(Access Concentrator)以及客戶機與AC協(xié)商Session ID。而PPPoE Sess-ion用于完成數(shù)據(jù)包的接收與發(fā)送,同時它也用于完成PPP鏈路的協(xié)商(LCP),以及網(wǎng)絡(luò)層的控制協(xié)商(IPCP)等。
傳統(tǒng)的PPPoE先會用Raw socket讀取數(shù)據(jù),然后采用用戶態(tài)程序?qū)ζ浞獍獍?,然后再發(fā)送給內(nèi)核。但是這種方法會引起大量的內(nèi)核空間與用戶空間的上下文切換,從而帶來不必要的開銷。而對于實現(xiàn)于內(nèi)核態(tài)的PPPoE,它會把所有的封包以及解包實現(xiàn)于內(nèi)核,這樣就大大提高PPPoE的效率。
1 PPPoE協(xié)議概述
1. 1 PPPoE Discovery階段
在PPPoE Discovery階段,客戶機首先廣播一個PADI(0x09)幀。收到PADI幀的一個或多個服務(wù)器會發(fā)送PADO(0x07)幀,這個包中包含了服務(wù)器的各種標(biāo)識。然后,客戶機會選擇其中一個服務(wù)器發(fā)送PADR(0x19),表明主機選擇了這個服務(wù)器。最終,收到PADR(0x65)幀的服務(wù)器會為新的會話分配資源并向客戶機發(fā)送PADS(0x65)。當(dāng)此階段完成,這兩次的對話完成了SESSION_ID以及雙方物理地址,為后續(xù)數(shù)據(jù)會話打好基礎(chǔ)。
同時PPP協(xié)議還提供了一個PADT請求,該請求用于結(jié)束這次PPPoE會話。這個請求可以由任何一方發(fā)出,同時代表這次回話的結(jié)束,圖1描述整個discovery過程。
1.2 PPPoE Session階段
PPPoE Discovery階段是為整個PPPoE會話獲取雙方物理地址以及Session_ID,這個Session_ID就成為了雙方的通信憑證,在整個會話過程中保持不變。PPP幀數(shù)據(jù)被封在以太幀中,它在以太幀的標(biāo)識為0x8864,當(dāng)碰到0x8864時,就認為是一個PPPoE包。
在PPPoE Session階段,PPPoE除數(shù)據(jù)傳輸以外,還提供了鏈路的協(xié)商(LCP),以及網(wǎng)絡(luò)層的控制協(xié)商(IPCP)等其他服務(wù)。對于LCP,它主要用于配置和測試數(shù)據(jù)通信鏈路,用來協(xié)商PPP協(xié)議的一些配置參數(shù)選項;處理不同大小的數(shù)據(jù)幀:檢測鏈路環(huán)路和一些鏈路的錯誤;終止一條鏈路,其作用類似于IP層的ICMP協(xié)議。而對于IPCP,它主要用于動態(tài)地協(xié)商客戶機與服務(wù)器雙方IP,實際的數(shù)據(jù)報文交換過程中主要涉及Config-Request、Config-Ack、Config-Nak和Config-Re-ject。圖2描述IPCP協(xié)商IP的過程。
2 PPPOE設(shè)計實現(xiàn)
從上述PPPoE協(xié)議描述中,了解到整個PPPoE會話包括Discovery、鏈路協(xié)商和數(shù)據(jù)傳輸3種交互。這3種數(shù)據(jù)中,數(shù)據(jù)傳輸最重要,數(shù)據(jù)量最大。對于用戶空間模式的PPPoE,數(shù)據(jù)包收發(fā)需要通過pty,由用戶空間的PPPoE進程處理PPPoE包頭后通過Raw socket收發(fā)。也就是說所有的PPPoE數(shù)據(jù)封包結(jié)果都在用戶空間執(zhí)行,這樣就大大增加了內(nèi)核空間與用戶空間數(shù)據(jù)切換的次數(shù)。為了減少這種開銷。這里采用一個內(nèi)核模塊來處理數(shù)據(jù)的封包解包,這樣就大大減少了內(nèi)核空間與用戶空間數(shù)據(jù)切換的次數(shù),提高效率。所以對內(nèi)核空間模式的PPPoE的處理策略是:Discovery以及鏈路協(xié)商交互全部在用戶空間完成,而數(shù)據(jù)的封解包則通過一個內(nèi)核模塊在內(nèi)核空間完成。
2.1 PPPoE會話初始化
PPPoE的初始化包括整個Discovery階段以及Session階段的IPCP和LCP等其他鏈路協(xié)商過程,所有的工作都在用戶空間完成,圖3描述了整個初始化的流程。
首先通過Raw socket發(fā)送PADS、PADR、PADO、PADI,當(dāng)這個請求完成后,得到遠端服務(wù)器的MAC地址以及雙方建立起來的Session_ID。由于后面的內(nèi)核封包需要用到這些數(shù)據(jù),所以需要將這些數(shù)據(jù)切換到內(nèi)核空間去。由于數(shù)據(jù)量較小,則采用proc文件系統(tǒng)完成內(nèi)核空間與用戶空間的數(shù)據(jù)切換。
對于proc中的數(shù)據(jù),設(shè)計以下數(shù)據(jù)格式:接口名詞SMAC DMAC SESSION_ID RX TX。
其中“接口名詞”為接口名稱,設(shè)計中不再用虛擬PPP接口傳輸數(shù)據(jù),而是將數(shù)據(jù)遷移到物理網(wǎng)卡上,這樣在某種程度上減輕了路由模塊的負擔(dān),但需要去proc文件讀取接口名稱以此判斷該物理接口是否啟用PPPoE撥號。“SMAC”和“DMAC”參數(shù)為雙方的MAC地址,在內(nèi)核封包中用到。“SESSION_ID”雙方建立起來的Session_ID,也用于內(nèi)核封包。而“RX”和“TX”是用于記錄最后一次解包與封包的時間點,該數(shù)據(jù)用于按需撥號。
在建立好PPP連接后就進行IPCP協(xié)商,這個過程將為協(xié)商到雙方的IP的地址,并將這個IP地址配置到物理口上,而這些數(shù)據(jù)將通過PPP口通信。除此之外,還需要為PPPoE鏈路配置相應(yīng)的路由、更新ARP列表以及獲取相應(yīng)的DNS服務(wù)器地址。
2.2 PPPoE數(shù)據(jù)接收
PPPoE數(shù)據(jù)接收主要是對數(shù)據(jù)進行解包,其全部動作在內(nèi)核空間完成。當(dāng)一個PPPoE數(shù)據(jù)包從網(wǎng)卡驅(qū)動里面讀出來時,是一個完整的PPPoE包。而上層模塊無法識別這樣的包,所以需要將中間的那些PPP協(xié)議數(shù)據(jù)從包中剝離出來,使其變成一個普通的IP數(shù)據(jù)包,圖4描述了PPPoE接收數(shù)據(jù)的整體流程。
當(dāng)從網(wǎng)卡驅(qū)動上讀取數(shù)據(jù)時,也就是獲取數(shù)據(jù)的SKB,首先需要判斷這個SKB是否有效,然后再判斷該網(wǎng)卡是否起動了PPPoE服務(wù),很顯然這里需要讀取proc的接口信息。如果已經(jīng)PPPoE撥號服務(wù),還需要判斷該包是不是一個LCP或者IPCP等其他協(xié)商數(shù)據(jù),也就是判斷協(xié)議域的數(shù)據(jù)是不是0X0021。因為如果是協(xié)商數(shù)據(jù),則不需要解包,而直接將其轉(zhuǎn)發(fā)到PPP虛擬接口上。對于具體的解包過程將進行代碼分析。解完包以后該數(shù)據(jù)包就屬于普通的IP包,后續(xù)流程與普通的IP包處理相同。
2.3 PPPoE數(shù)據(jù)發(fā)送
PPPoE數(shù)據(jù)發(fā)送流程基本上是數(shù)據(jù)接收的逆過程,圖5描述整個數(shù)據(jù)發(fā)送過程。首先從用戶空間或者FORWARDING模塊獲取一個數(shù)據(jù)包,這個數(shù)據(jù)包屬于正常的IP包。很顯然這個包是無法發(fā)送到PPP鏈路上的,因為PPPoE服務(wù)器并不識別這樣的數(shù)據(jù)包。所以需要利用proc文件中的Session_ID、遠端MAC和本地MAC數(shù)據(jù)來封裝IP包,使其成為一個標(biāo)準(zhǔn)的PPP包。
2.4 核心代碼實現(xiàn)
整個PPPoE內(nèi)核模式撥號的核心代碼主要集中在內(nèi)核模塊上,該模塊主要功能有proc文件讀寫、數(shù)據(jù)包的封裝、解包等操作,下面是這個內(nèi)核模塊的包封裝的部分程序。
以上只是部分代碼,由于代碼太多,而且很多代碼和項目的硬件抽象層模塊(HAL)息息相關(guān),所以在此不再詳細闡述。具體可以參考Lin-ux內(nèi)核中pppoe模塊里面的代碼,雖然工作的層次有點不一樣,但是總體的思路是一樣的,本文的實現(xiàn)代碼基本上也是參考的Linux內(nèi)核中PP-PoE的代碼。
3 結(jié)束語
本文主要描述了PPPoE內(nèi)核模式撥號的設(shè)計與實現(xiàn),該模式將封包動作從用戶空間轉(zhuǎn)移到內(nèi)核空間,從而大大降低了內(nèi)核空間與用戶空間切換的次數(shù),目前這種內(nèi)核模式下的撥號已經(jīng)大量地應(yīng)用于各種網(wǎng)關(guān)產(chǎn)品中。雖然PPPoE是一種非常成熟的技術(shù),Linux內(nèi)核也已開始支持PP-PoE內(nèi)核態(tài)撥號,同時由卡耐基梅隆大學(xué)開發(fā)的PPPD開源項目已經(jīng)廣泛應(yīng)用于各種網(wǎng)關(guān)產(chǎn)品中,但是熟悉整個內(nèi)核態(tài)撥號的流程是非常重要的,同時PPPD目前還存在一些BUG,在項目開發(fā)的過程中還需做大量修改。本文提供解決方案有別于傳統(tǒng)的通過PPP虛擬接口來傳輸數(shù)據(jù)的方案,在某種程度上也降低了路由模塊的工作任務(wù),尤其是需要實現(xiàn)多路PPPoE的時候。另外該設(shè)計方案在Linux2.6.18上已經(jīng)成功通過測試,并投入使用。