L2TP與PPP交互的一種方法

(湖北工業大學　湖北　武漢　430074)

引言

隨著VPN(虛擬專用網)組網需求的普及，各種VPN技術應運而生，L2TP(二層隧道協議)作為一種VPN隧道技術，適用于純IP網絡，是由IETF(因特網工程任務組)制定的標準協議。L2TP 協議提供了對PPP(點到點協議)鏈路層數據包的隧道傳輸支持，允許二層鏈路端點和PPP 會話點駐留在不同設備上，并采用包交換技術進行信息交互，從而擴展了PPP模型。雖然L2TP成為了IETF有關二層隧道協議的工業標準，但是在具體實現上每個系統都有自己的方案。

作為一種VPN隧道技術，L2TP承載的是PPP協議報文，在協議實現中自然與PPP功能模塊密不可分。但是站在軟件工程的角度上，二者應該是獨立的個體，不能相互耦合。所以在實現L2TP協議功能模塊時面臨的一個問題就是如何與PPP功能模塊解耦。使得L2TP功能模塊成為一個低耦合高內聚的獨立模塊。

降低軟件模塊間耦合度的方法有很多，軟件系統千差萬別，模塊間的解耦方法同樣多種多樣。我們在L2TP功能模塊的開發過程中，對如何降低L2TP與PPP功能模塊間的耦合度進行了深入的分析，提出了本文所述的一種降低它們之間耦合度的方法，使得L2TP的處理效率更高，大大提升了系統的整體吞吐量，為滿足大容量的隧道及會話打下了基礎。

一、軟件耦合概述

軟件設計中通常用耦合度和內聚度作為衡量模塊獨立程度的標準。劃分模塊的一個準則就是高內聚低耦合。耦合度是對模塊間關聯程度的度量。耦合的強弱取決于模塊間接口的復雜性、調度模塊的方式以及通過界面傳送數據的多少。模塊間的耦合度是指模塊之間的依賴關系，包括控制關系、調用關系、數據傳遞關系。模塊間聯系越多，其耦合性越強，同時表明其獨立性越差。降低模塊間的耦合度能減少模塊間的影響，防止對某一模塊修改所引起的“牽一發動全身”的水波效應，保證系統設計順利進行。

耦合衡量不同模塊彼此間互相依賴(連接)的緊密程度，是對一個軟件結構內不同模塊之間互連程度的度量。耦合強弱取決于模塊間接口的復雜程度，進入或訪問一個模塊的點，以及通過接口的數據。

在軟件設計中應該追求盡可能松散耦合的系統。在這樣的系統中可以研究、測試或維護任何一個模塊，而不需要對系統的其他模塊有很多了解。此外，由于模塊間聯系簡單，發生在一處的錯誤傳播到整個系統的可能性就很小。因此，模塊間的耦合程度強烈影響著系統的可理解性、可測試性、可靠性和可維護性。

如果兩個模塊中的每一個都能獨立地工作而不需要另一個模塊的存在，那么它們彼此完全獨立，這意為著模塊間無任何連接，耦合程度最低。但是，在一個軟件系統中不可能所有模塊之間都沒有任何連接。

如果兩個模塊彼此間通過參數交換信息，而且交換的信息僅僅是數據，那么這種耦合稱為數據耦合。如果傳遞的信息中有控制信息(盡管有時這種控制信息以數據的形式出現)，則這種耦合稱為控制耦合。當兩個或多個模塊通過一個公共數據環境相互作用時，它們之間的耦合稱為公共環境耦合。如果兩個模塊共享的數據很多，都通過參數傳遞可能很不方便，這時可以利用公共環境耦合。最高程度的耦合是內容耦合。如果出現下列情況之一，兩個模塊間就發生了內容耦合。

(1)一個模塊訪問另一個模塊的內部數據；

(2)一個模塊不通過正常入口而轉到另一個模塊的內部；

(3)兩個模塊由一部分程序代碼重疊；

(4)一個模塊有多個入口。

總之，我們的設計原則是盡量使用數據耦合，少用控制耦合，限制公共環境耦合的范圍，完全不用內容耦合。

二、實現L2TP與PPP脫耦的方案

L2TP的一個典型應用場景如圖1所示：

圖1　L2TP的典型應用場景

LAC表示L2TP訪問集中器(L2TP Access Concentrator)，是附屬在交換網絡上的具有PPP端系統和L2TP協議處理能力的設備，LAC一般是一個網絡接入服務器NAS，主要用于通過PSTN/ISDN網絡為用戶提供接入服務。LNS表示L2TP網絡服務器(L2TP Network Server)，是PPP端系統上用于處理L2TP協議服務器端部分的設備。

圖2　呼叫請求會話連接流程

LAC端呼叫請求會話連接流程如圖2所示，PPP請求會話連接時，是由PPP模塊向L2TP模塊發起的請求，需要調用L2TP會話連接請求的處理過程，而為了模塊間的獨立性，PPP模塊不能直接調用L2TP模塊的這個處理過程，否則就會造成內容耦合。

為了解決這種問題，在此設計了一種事件通告的方式傳遞模塊間的信息，當PPP模塊需要請求會話連接時，發送一個L2TP會話連接請求的事件，然后L2TP通過監聽該事件進行相應的會話連接處理。通過這種方式，不僅對模塊間進行了解耦合，而且實現了撥號請求與L2TP會話連接請求間的異步處理，提高了大容量會話的處理效率。

圖3　串行模式撥號處理時序示意圖

如圖3所示為未采用事件通告方式，模塊間直接調用的串行處理模式下的撥號時序示意圖，在這種方式下，由于L2TP會話處理較為復雜，耗時較多，而當請求處理未完成時，撥號2的請求被阻塞，直到一段時間后客戶端的重新撥號請求才被響應，此處夸大了L2TP會話處理的時間，不過可以想象，當有大量撥號請求時，由于不能及時響應，會導致部分撥號由于多次請求得不到處理而終止。

圖4　異步模式撥號處理時序示意圖

如圖4所示為采用事件通告方式，通過異步處理撥號請求的處理時序示意圖，由于收到撥號請求后，發送相應事件的處理能夠快速處理完成，所以能夠及時響應后續的撥號請求。在大容量撥號請求時，大大降低了由于處理不及時而導致撥號未被響應而失敗的可能性。

三、測試結果及分析

圖5　測試拓撲

為了驗證該方法的有效性，如圖5所示搭建測試環境。測試儀表可模擬大量PPPOE客戶端，與LAC間通過以太網連接，LAC與LNS間通過三層IP網絡連接，以便建立L2TP隧道。

為了對比串行模式和異步模式下的性能差異，分別在兩種方式下使用大量客戶端進行撥號連接，記錄下一次性撥號連接成功的數量，同時客戶端的數量以1000個開始，然后再以1000為增量遞增客戶端數量，直到記錄下10000個客戶端一次性撥號連接成功的數量。經過試驗，記錄數據如下表1所示。

表1　測試記錄

從實驗數據可以觀察到，串行模式下，客戶端數量在5600個左右達到了閾值，而異步方式下，閾值提升到了9400左右，性能提升很大。

由此我們得出結論：正是由于異步模式較串行模式能更快速地響應客戶端，所以在大量客戶端幾乎同時發起撥號請求時，異步方式下能夠成功連接的數量更多，對用戶來說更加的友好。同時對于軟件項目來說，模塊間的耦合度降低，后期更易于維護相關功能。

四、結束語

本文在軟件工程學的理論指導下，在L2TP的軟件模塊實現中，通過設計一種PPP與L2TP模塊間內部通信的一種方式，將兩個功能模塊進行了一定程度的解耦合，同時達到了一定程度的性能提升，經過實驗驗證，大大提升了系統的整體吞吐量，對用戶體驗更加的友好。雖然本文是針對隧道協議實現中的一種具體方案應用，但是其中的思想對其他方面的應用也具有一定的參考價值。

【參考文獻】

[1]張海藩.軟件工程導論(第5版)[M].北京：清華大學出版社，2008.97-99.

[2]Wei Luo，Carlos Pignataro，Dmitry Bokotey，et al.第二層VPN體系結構[M].北京：人民郵電出版社，2006.361-362.

[3]IETF RFC1661-1994，The Point-to-Point Protocol(PPP)[S].

[4]IETF RFC2661-1999，Layer Two Tunneling Protocol“L2TP”[S].