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].