点对点通信、数据链路层、点对点链路、PPP、PPPOE、PPTP、L2TP-VPN简介

点对点通信

       点对点通信实现网内任意两个用户之间的信息交换。电台收到带有点对点通信标识信息的数据后，比较系统号和地址码，系统号和地址码都与本地相符时，将数据传送到用户终端，否则将数据丢掉，不传送到用户终端。点对点通信时，只有1个用户可收到信息。

点对点连接是两个系统或进程之间的专用通信链路。想象一下直接连接两个系统的一条线路。两个系统独占此线路进行通信。点对点通信的对立面是广播，在广播通信中，一个系统可以向多个系统传输。

电话呼叫是面向电路的两部电话机之间的点对点链路。但是，呼叫通常是通过电话公司中继线多路复用的；因此虽然电路本身可能是虚拟的,但用户在进行点对点通信会话。

端到端连接是指通过交换网络的两个系统间的连接。例如,因特网由路由器网状网组成。数据分组沿着逐跳路径从一个路由器到下一个路由器,一直到达目的地。每一跳都包括路由器之间的物理点对点链路。因此，一个路由路径包括多个点对点链路。在ATM和帧中继环境中，端到端路径称为虚电路，它穿越一组预定义的点对点链路。

共享的LAN，如以太网，提供了一种点对点通信的形式。请记住，在共享的LAN上，所有的节点都在监听缆路上的信号，因此支持广播。但是，当一个节点向另一节点发送帧时，只有那个节点接收到帧，可以说两个节点通过共享媒体进行点对点通信。

通过多点链路的点到多点连接是可能的。多点是指信号由基站到用户端是以点到多点的方式传送的，而信号由用户端到基站则是以点对点的方式传送的。大型机和它的终端就是一个例子。提供多点连接的设备通常是一个智能控制器,它管理来自与它相连的多个设备的信息流。

点对点通信在OSI协议栈的物理、数据链路层和网络层中定义。

数据链路层

“链路”和“数据链路”并不是一回事：

链路（link）：是一条点到点的物理线路，中间没有任何其他交换节点，即物理链路。在进行数据通信时，两个计算机之间的通信路径往往要经过许多段这样的链路。可见，链路只是一条路径的组成部分。

数据链路（data link）：除了物理线路外，还必须有通信协议来控制这些数据的传输。若把实现这些协议的硬件和软件加到链路上，就构成了数据链路，即逻辑链路。现在最常用的方法是使用网络适配器来实现这些协议的硬件和软件。一般的适配器都包括了数据链路层和物理层这两层的功能。

早期的数据通信协议曾叫做通信规程(procedure)。因此，在数据链路层，规程和协议是同义语。

数据链路层的协议数据单元是——帧。

数据链路层的三个基本问题是：

（1）帧定界：数据链路层的发送端应该让对方接收端的数据链路层知道，所发送的帧从什么地方开始和从什么地方结束。即帧定界问题。

（2）透明传输：数据链路层传送的数据的比特组合必须是不受限制的。数据链路层协议不能禁止传送某种特殊的比特组合。

（3）差错检测：当接收端检测出有差错的帧时，根据协议的不同，可以有不同的处理方法。丢弃出错帧或立即通知发送端。

图4－1（a）表示用户主机H1通过电话线上网，中间经过3个路由器（R1，R2和R3）接入到远程主机H2。所经过的网络可以上多种的，如电话网、局域网和广域网。当主机H1向主机H2发送数据时，从协议的层次上看，数据的流动如图4—1(b)所示。主机H1和主机H2都有完整的五层协议栈，但在互联网的核心部分的路由器的协议栈只有下面的3层。数据进入路由器后要先从物理层E到网络层，在转发表中找到下一跳的地址后，再下到物理转发出去。因此，数据从主机H，传送到主机H2需要在路径中的各结点的协议栈向上和向下流动多次，如图中的双向浅灰色箭头所示。

然而，当我们专门研究数据链路层的问题时，在许多情况下我们只关心在协议栈中水平方向的各数据链路层。于是，当主机H1向主机H2发送数据时，我们可以想像数据就是在数据链路层从左向右沿水平方向传送，如图4．2中从左到右的粗箭头所示，即通过以下这样的链路：

H1的链路层→Rl的链路层→R2的链路层→R3的链路层→H2的链路层

帧定界

帧定界(framing)就是确定帧的界限。在发送帧时，发送方的数据链路层在帧的前后都各加入事先商定好的标记，使得接收方在收到这个帧后，就能根据这种标记识别帧的开始和结束，以及帧里面装入的数据部分的准确位置。图4-4表示用帧首部和帧尾部进行帧定界的一般概念。

网络层的IP数据报传送到数据链路层就成为帧的数据部分。在帧的数据部分的前面和后面分别添加上首部和尾部，构成了一个完整的帧。因此，帧长等于数据部分的长度加上帧首部和帧尾部的长度。首部和尾部的主要作用是进行帧定界，但还可以包括一些其他的控制信息。在发送帧时，是从帧首部开始发送。各种数据链路层协议都要对帧首部和帧尾部的格式有非常明确的规定。显然，为了提高帧传送效率，应当使帧的数据部分长度尽可能地大于首部和尾部的长度。但是，每一种链路层协议都规定了帧的数据部分的长度上限――最大传送单元MTU(Maximum Transfer Unit)。图4．4给出了为帧定界用的首部和尾部的位置，以及帧的数据部分与MTU的关系。

当数据是由可打印的ASCII码组成的文本文件时，帧定界可以使用特殊的帧定界符。我们知道，ASCII码是7位编码，一共可组合成128个不同的ASCII码，其中可打印的有95个，而不可打印的控制字符有33个。如图4．5所示的例子可说明帧定界的概念。控制字符SOH(Start Of　Header)放在一帧的最前面，表示帧的首部开始。另一个控制字符EOT （End Of　Transmission)表示帧的结束。请注意，SOH和EOT分别是这两个控制字符的名称。字符SOH和字符EOT的十六进制编码分别是01和04。不要误认为SOH(或EOT)是S、O、H(或E、O、T)三个字符。

对帧进行定界是非常必要的。可能有的读者会这样想：既然发送方发送的数据是以帧为单位，那么，在接收方就可以从收到的数据很自然地找出帧的长度范围。但是，我们必须考虑到，数据在物理层的实际传送方式可能是多样的。例如，在物理层常常采用异步传送，即一次只传送一个字符(如使用RS232接口)。因此，在接收方的物理层是断断续续地接收到单个的数据字符(每个字符之间相隔的时间并不确定)，而不是一次就收到一个完整的帧。但有了帧定界的控制字符，接收方就可以准确界定一个帧开始和结束的位置。．

在同步传输的情况下，发送方是连续地发送数据帧。在接收方怎样从连续的比特流中找出每一个帧开始和结束的位置呢？这还要借助于帧定界的特殊标记。

再看一种情况。假定发送方在尚未发送完一个帧时突然出现故障，但随后很快又恢复正常，于是，重新发送刚才未发送完的帧(当然必须从头开始发送)。由于使用了帧定界符，在接收方就知道前面收到的数据是个不完整的帧(只有首部开始符SOH，而没有传输结束符EOT)，必须丢弃。而后面收到的数据有明确的帧定界符(SOH和EOT)，因此，这是一个完整的帧，应当收下。

 透明传输

由于帧的开始和结束的标记是使用专门指明的控制字符，因此，所传输的数据中的任何一个字符一定不允许和用做帧定界的控制字符一样，否则就会出现帧定界的错误。

当传送的帧是用文本文件组成的帧时(文本文件中的字符都是从键盘上输入的)，其数据部分显然不会出现像SOH或EOT这样的帧定界控制字符。可见，不管从键盘上输入什么字符都可以放在这样的帧中传输过去，因此这样的传输就是透明传输。

但当数据部分是非ASCII码的文本文件时(如二进制代码的计算机程序或图像等)，情况就不同了。如果数据中的某个字节的二进制代码恰好和SOH或EOT这种控制字符一样，如图4—6所示，数据链路层就会错误地“找到帧的边界”，把部分帧收下(误认为是个完整的帧)，而把剩下的那部分数据丢弃(这部分找不到帧定界控制字符SOH)。

像图4．6所示的帧的传输显然就不是“透明传输”，因为当遇到数据中出现字符“EOT”时就传不过去了，数据中的“EOT”将被接收方错误地解释为“传输结束”的控制字符。但实际上在数据中出现的字符“EOT”并非控制字符而仅仅是数据。

为了解决透明传输问题，就必须设法使数据中可能出现的控制字符“SOH”和“EOT”在接收方不被解释为控制字符。具体的方法是每当在数据中出现字符“SOH”或“EOT”时就将其转换为另一个字符，而这个字符是不会被错误解释为控制字符的。这种方法称为字节插入。例如，可以采用如下的约定(显然可以有多种不同的约定)：

上面的控制字符“ESC”叫做转义符(escape　character)，在标准键盘的左上角，它的十六进制编码是1 B。为什么对数据中出现的“ESC”也必须进行转换呢 本来控制字符ESC并不会和帧定界标记弄混。但由于我们把SOH和EOT都转换为由ESC开始的两个字符，因此，如果不对数据中出现的ESC进行处理，那么，当数据中碰巧出现“ESC x”或“EOT y”这样的两字符组合时，在接收方就会被错误地还原为字符SOH或EOT。把ESC转换为两字符组合ESC z就可以避免出现这样的情况。图4—7表示在数据中碰巧出现了4个控制字符“ESC”、“EOT”、“ESC”和“SOH”。

可以看出，按以上规则转换后所发送的数据已经不再出现对帧定界的控制字符SOH和EOT了。在接收方，只要进行相应的逆变换就可以很方便地还原出原来的数据。使用这种字节插入法就可实现透明传输。

在4. 3. 2节我们还要介绍另一种实现透明传输的方法—比特插入。

 差错检测

现实的通信链路都不会是理想的，这就是说，比特在传输过程中可能会产生差错：1变成了0或0变成了1。在一定的时间内，传输错误的比特占所传输的比特总数的比率称为误码率BER(Bit Error Rate)。例如，误码率为10^－10时，表示平均每传送10¹⁰个比特就会出现一个比特的差错。误码率与信噪比有很大的关系。如果设法提高信噪比，就可以使误码率减小。由于实际的通信链路并非理想的，它不可能使误码率下降到零。因此，为了保证数据传输的可靠性，在计算机网络传输数据时，都必须采用各种差错检测措施。在数据链路层广泛使用了循环冗余检验CRC(cyclic Redundancy check)的检错技术。

下面我们通过一个简单的例子来说明循环冗余检验的原理。

在发送方，设待传送的数据M=101001(共k位，这里k=6)。在数据M的后面添加供差错检测用的n位冗余码一起发送(即一共发送k+n位)。在所要发送的数据后面增加n位的冗余码，虽然增大了数据传输的开销，但却可以进行差错检测。当传输可能出现差错时，付出这种代价是必须的。

这n位冗余码可用以下方法得出。先用二进制的模2运算进行2ⁿ乘M的运算，这相当于在M后面添加n个0。得到的(k+n)位的数除以收发双方事先商定的长度为(n+1)位的数P，得出商是p而余数是R(n位)。至于P是怎样选定的，下面还要介绍。在图4—8所示的例子中，设n=3，除数P=1101。经模2除法运算后的结果是：商Q=110101，而余数R=001(n位)。这个余数R就作为冗余码添加在数据M的后面发送出去。这种为了进行检错而添加的冗余码常称为帧检验序列FCS（Frame Check Sequence)。因此，加上FCS后发送的数据是101001001（即2ⁿM+FCS)，共有(k+n )位。

顺便说一下，循环冗余检验CRC和帧检验序列FCS并不是同一个概念。CRC是一种检错方法，而FCS是添加在数据后面的冗余码，在检错方法上可以选用CRC，但也可不选用CRC。

在接收方对接收到的帧进行CRC检验。把收到的帧除以同样的P(模2运算)，得出余数R。如果数据在传输过程中没有差错，则得出的余数显然应为0(读者可自己进行这样的运算。被除数现在是101001001，而除数是P=1101，看余数是否为0)。若数据在传输过程中出现误码，则得不出余数为0的结果。或者更严格地讲，这时得出余数为0的概率极小。实际上只要经过仔细的挑选，并使用位数足够多的除数P，那么，出现CRC检测不到的差错概率就可忽略不计。

总之，在接收方经过CRC检验后，

·若得出的余数R=0，则认为这个帧没有差错，就接受(accept)这个帧。

·若余数R≠0，则认为这个帧有差错(当然无法确定究竟是哪一位或哪几位出现了差错)，就丢弃这个帧。

一种较方便的方法是用多项式来表示循环冗余检验过程，就是使用多项式相应的系数来表示上述二进制数字中的1和0。例如，可以用多项式P(X)=X³+X²+X+1来表示上面的除数P=1101(最高位对应于X³，最低位对应于X)。多项式P(X)称为生成多项式。现在广泛使用的生成多项式P(X)有以下几种：

CRC－16= X¹⁶＋X¹⁵＋X²＋1

CRC－CCITT= X¹⁶＋X¹⁵＋X⁵＋1

CRC－32＝X³²＋X²⁶＋X²³＋X²²＋X¹⁶＋X¹²＋X¹¹＋X¹⁰＋X⁸＋X⁷＋X⁵＋X⁴＋X²＋X＋1

在数据链路层，在发送方帧检验序列FCS的生成和在接收方的CRC捡验都是用硬件完成的，处理很迅速，因此并不会延误数据的传输。

最后再强调一下，循环冗余检验CRC差错检测技术只能做到无差错接受，即：“凡是接收方数据链路层接受的帧，我们都能以非常接近于1的概率认为这些帧在传输过程中没有产生差错”(请注意，接收方丢弃的帧虽然曾被暂时接收下来，但最终没有被接受)，或更简单些，可以近似地认为：“凡是接收方数据链路层接受的帧均无传输差错”。

请注意，采用CRC差错检测技术后，我们并没有使数据链路层变成具有“可靠传输”的功能。所谓“可靠传输”就是发送方发送什么，接收方就收到什么。也就是说，接收方接受的帧应当是无差错、无丢失、无重复，同时还按发送的顺序接收。例如，发送方发送了100个帧。到达接收方后，能通过CRC检查的只有一个。那么，接收方就只接受这一个传输正确的帧。这仍然是“无差错接受”，但远远不是“可靠传输”，因为有99个帧由于出现差错而被接收方丢弃了。

那么，我们应不应当把数据链路层做成是可靠传输的？以前OSI的观点是必须把数据链路层做成是可靠传输的。因此，他们在有CRC检错的基础上，增加了确认和重传机制。意思是收到正确的帧要向发送方发送一个确认。发送方在一定的期限内若没有收到确认，就认为出现了差错，就重传这个帧，直到收到确认为止。这种方法在历史上曾经起到好的作用。但现在的通信线路的质量已经大大提高了，通信链路质量不好引起差错的概率已经大大降低。因此，因特网广泛使用的数据链路层协议都不使用确认和重传机制，即不把数据链路层做成具有可靠传输的功能(因为这要付出相当大的代价)。如果在数据链路层传输数据时出现了差错，并且需要进行改正的话，那么，改正差错的任务就由运输层的TCP协议来完成。实践证明，这样做可以使整个通信效率大大提高。

在本教材的第一版中采用了以前OSI的思路，也就是在数据链路层增加确认和重传机制(例如停止等待协议和滑动窗口机制)。但现在看来这已是多余的，因此，我们把确认和重传机制改为在运输层的TCP中讨论。这样做比较符合因特网的实际情况。

点对点链路

在wan中，点对点链路（point to point link）提供了从客户端通过某个电信运营商网络。点对点链路也称为租用线路，因为它所建立的路径对于每条通过电信运营商设施连接的远程网络都是永久而且固定的。

点对点链路不使用arp协议，因为在设置这些链路时已经告知了内核，链路两端的ip地址，所以说不需要arp协议来实现ip地址和不同网络技术硬件地址的动态映射。（注：这段话应该有问题，因为点对点链路只是一条物理链路）

PPP协议的特点

对于点对点的链路，点对点协议PPP协议是目前使用得最广泛的数据链路层协议。我们知道，用户接入因特网有多种途径，如通过电话线拨号入网或各种宽带入网，但不管怎样，总是要通过某个因特网服务提供者ISP才能接入到因特网。从用户计算机到ISP的链路所使用的数据链路层协议就是PPP协议，如图4-9所示。

 

每一个ISP都已经从因特网的管理机构或从一个更大的ISP申请到一批IP地址。ISP还有与因特网通过高速通信专线相连的路由器。大的ISP拥有属于自己通信线路，而小的ISP则向电信公司租用通信线路。用户在某一个ISP缴费登记后(有的ISP是出售上网卡)，就可用自己的计算机通过调制解调器、电话线接入到该ISP。用户在接通ISP后，ISP就分配给该用户一个临时的IP地址(IP地址将在第7章中详细讨论)。用户计算机在获得了临时的IP地址后，就成为连接在因特网上的主机，因而就可使用因特网所提供的各种服务。当用户结束通信并断开连接后，ISP就把刚才分配给该用户的IP地址收回，以便再分配给后面拨号入网的其他用户使用。

PPP协议是IETF在1992年制定的。经过1993年和1994年的修订，现在的PPP协议已成为因特网的正式标准[RFC 1661]。

 

PPP协议应满足的需求

IETF认为，在设计PPP协议时必须考虑以下的多方面需求[RFC 1547]。

(1) 简单。经过非常慎重的考虑，IETF在设计因特网体系结构时已把其中最复杂的部分放在TCP协议中，而网际协议IP则相对比较简单，它提供的是不可靠的数据报服务。在这种情况下，数据链路层没有必要提供比IP更多的功能。因此，对数据链路层的帧，不需要纠错，不需要序号，也不需要流量控制。如果添加这些功能，就会和运输层的某些功能重复，因而降低了通信效率。当然，在误码率较高的无线链路上可能会需要更为复杂的链路层协议。因此，IETF把“简单”作为首要的需求。

简单的设计还可使协议不容易出错，因而使得不同厂商对_办议的不同实现的互操作性提高了。我们知道，协议标准化的一个主要目的就是提高协议的互操作性。

(2)封装成帧。　PPP协议必须能够正确和有效地把网络层交下来的分组(即IP数据报)封装成数据链路层的帧，再发送出去。接收方在收到帧后，必须能够准确地找出帧的开始和结束位置，以及帧中所封装的数据(即IP分组)的开始和结束位置。为此，PPP协议必须规定特殊的字符作为帧定界符(即标志一个帧的开始和结束的字符)。帧定界是指接收方从收到的比特流中应当能准确地找出一帧的开始和结束在什么地方。

(3)透明性。　PPP协议必须保证数据传输的透明性。这就是不能限制网络层交下来的分组数据中不许出现某种比特组合。只要不出现传输差错，所有的数据(包括高层协议的首部)都必须原封不动地传送到相邻结点。如果数据中碰巧出现了和帧定界符一样的比特组合时，就要采取有效的措施来解决这个问题(见4.2. 2节关于透明传输的讨论)。

(4)多种网络层协议。　PPP协议必须能够在在同一条物理链路上同时支持多种网络层协议(如IP和IPX等)的运行。当点对点链路所连接的是局域网或路由器时，PPP协议必须同时支持在链路所连接的局域网或路由器上运行的所有协议。虽然在因特网的环境下IP是网络层的主流协议，但链路层的PPP协议仍需支持其他的网络层协议。

(5)多种类型链路。　除了要支持多种网络层的协议外，PPP还必须能够在多种类型的链路上运行。例如，串行的(一次只发送一个比特)或并行的(一次并行地发送多个比特)，同步的或异步的，低速的或高速的，电的或光的，交换的或非交换的。

这里特别要提到的是在1999年公布的在以太网上运行的PPP，即PPP over Ethernet，简称为PPPoE[RFC 2516]，这就是PPP协议能够适应多种类型链路的一个例子。PPPoE是为宽带上网的主机使用的链路层协议。宽带上网时由于数据传输速率较高，因此，可以让多个用户共享一条宽带链路。例如，一个具有20个人工作的实验室，他们使用的计算机都连接在一个以太网。这时，可以向ISP只申请一条宽带上网线路，而大家都使用，PPPoE数据链路层协议通过连接到ISP的共享宽带链路下载的文件，会按照每个计算机不同的硬件地址(见5．3．1节)而传送到相应的计算机。如果所有的用户都正好在同一时刻下载文件，那么，每一个用户分配到的数据传输速率当然也就下降了。

(6)差错检测(error detection)。PPP协议必须能够对接收方收到的帧进行检测，并立即丢弃有差错的帧。虽然TCP协议有能保证端到端可靠交付的差错控制机制，但若在数据链路层不进行差错检测，那么，已出现差错的帧(这种出错的帧已无用处)就还要在网络中继续向前转发，因而白白浪费了许多网络的资源。因此，在数据链路层对收到的帧进行检错并不是多余的。然而，在数据链路层一般没有必要去纠错。纠错是不仅发现差错，而且还把差错改正过来。在数据链路层进行纠错的代价太高，通常是得不偿失的。

(7)连接的活跃度。 PPP协议必须具有一种机制来自动检测出链路上连接的活跃度(liveness)，也就是说，必须能够及时(不超过几分钟)检测出一条链路是处于正常工作状态，还是已经出了故障。当出了故障的链路隔了一段时间后又重新恢复正常工作时，这种及时检测功能特别有用。

(8)最大传送单元。 PPP协议必须对每一种类型的点对点链路设置最大传送单元MTU的标准默认值。这样做是为了促进各种实现之间的互操作性。如果高层协议发送的分组过长并超过MTU的数值，PPP就要丢弃这样的帧，并返回差错。为了有效地传送以太网的帧，MTU的默认值至少是1500字节。再强调一下，MTU是数据链路层的帧可以载荷的数据部分的最大长度，而不是帧的总长度。在RFC 1661中，MTU被称为最大接收单元MRU(Maximum　Receive Unit)。

(9)网络层地址协商。　PPP协议必须提供一种机制使通信的两个网络层(例如，两个IP层)能够通过协商知道或配置彼此的网络层地址（NCP分配的IP地址）。协商的算法应当尽可能简单，并且能够在所有的情况下都能得出协商结果。这对拨号连接的链路特别重要，因为仅仅在链路层建立了连接而不知道对方网络层地址时，还不能够保证网络层能够传送分组。

(10)数据压缩协商。PPP协议必须提供一种方法来协商使用数据压缩算法。但PPP协议并不要求将数据压缩算法进行标准化。

PPP协议不需要的功能

在RFC 1547中还明确了PPP协议不需要的功能。

(1)纠错(error correction)。　在TCP／IP族中，可靠传输由运输层的TCP协议负责，而数据链路层的PPP协议则没有纠错的责任。这就是说，PPP协议是不可靠传输协议。虽然当链路的误码率较高时，增加纠错功能可阱提高链路的性能，但对．PPP协议的基本实现，则不要求有纠错这一机制。

(2)流量控制。　我们知道，发送方发送数据的速率必须使接收方来得及接收。当接收方来不及接收时，到达接收方缓存的帧就要排队等候处理。当队列溢出时就发生帧的丢失。因此，接收方应对发送方发送数据的速率进行流量控制。在TCP/IP族中，端到端的流量控铷由TCP负责，因而链路级的PPP协议就不需要再重复进行流量控制。这样做符合前面讲的PPP协议的第一个需求―――“简单”。

(3)序号。　PPP协议不需要序号。许多流行的数据链路层协议，如停止等待协议或连续ARQ{协议都是使用序号的。但为了使协议简单，PPP协议并不试图使协议向后兼容。在噪声较大的环境下，如无线网络，则可以使用有编号的工作方式，这样就可以提供可靠传输服务。这种工作方式定义在RFC 1663中，这里不再讨论。

(4)多点线路。　PPP协议不支持多点线路(即一个发送站轮流和链路上的多个接收站进行通信)。PPP协议只支持一个发送方和一个接收方的链路通信。

(5)半双工或单工链路。　PPP协议不支持半双工或单工链路(因为这两种链路目前已很少使用)，而只支持全双工链路。

PPP协议的组成

PPP协议有三个组成部分：

(1)一个将IP数据报封装到串行链路的方法。PPP既支持异步链路(无奇偶检验的8比特数据)，也支持面向比特的同步链路。IP数据报在PPP帧中就是其信息部分。这个信息部分的长度受最大传送单元MTU的限制。

(2)一个用来建立、配置和测试数据链路连接的链路控制协议LCP （Link control　Protocol)。通信的双方可协商一些选项。在RFC 166l中定义了11种类型的LCP分组。

(3)一套网络控制协议NCP(Network control Protocol)，其中的每一个协议支持不同的网络层协议，如IP、OSI的网络层、DECnet、以及AppleTalk等。

PPP协议的帧格式

各字段的意义

PPP的帧格式如图4．10所示。PPP帧的首部和尾部分别为四个和两个字段。

首部的第一个字段和尾部的第二个字段都是标志字段F(Flag)，规定为0x7E(符号“0x”表示它后面的字符是用十六进制表示的。十六进制的7E的二进制表示是01111110)。标志字段表示一个帧的开始或结束。因此，标志字段就是PPP帧的定界符。连续两帧之间只需要用一个标志字段。如果出现连续两个标志字段，就表示这是一个空帧，应当丢弃。

首部中的地址字段A规定为0xFF(即11111111)，控制字段c规定为0x03(即00000011)。最初曾考虑以后再对这两个字段的值进行其他定义，但至今也没有给出。可见，这两个字段实际上并没有携带PPP帧的信息。

PPP首部的第四个字段是2字节的协议字段。当协议字段为0x0021时，PPP帧的信息字段就是IP数据报，0x002B表示IPX报文，0x0029表示AppleTalk报文，这些属于PPP的数据报文。若为0xC021，则信息字段是PPP链路控制协议LCP的数据，而0x8021表示这是网络控制协议NCP的数据，这些属于PPP的控制报文。

信息字段的长度是可变的，不超过1500字节。

尾部中的第一个字段(2字节)是使用CRC的帧检验序列FCS。

字节填充

当信息字段中出现和标志字段一样的比特(Ox7E)组合时，就必须采取一些措施使这种形式上和标志字段一样的比特组合不出现在信息字段中。

当PPP使用异步传输时，它把转义符定义为0x7D，并使用字节填充，具体做法如下：

(1)把信息字段中出现的每一个0x7E字节转变成为2字节序列(0x7D，0x5E)。

(2)若信息字段中出现一个0x7D的字节(即出现了和转义字符一样的比特组合)，则把0x7D转变成为2字节序列(0x7D，0x5D)。

(3)若信息字段中出现ASCII码的控制字符(即数值小于0x20的字符)，则在该字符前面要加入一个0x7D字节，同时将该字符的编码加以改变。这样做的目的是防止这些表面上的ASCII码控制符(在被传输的数据中当然已不是控制符了)被错误地解释为控制符。

零比特填充

PPP协议用在SONET/SDH链路时，是使用同步传输(一连串的比特连续传送)，而不是异步传输(逐个字符地传送)。在这种情况下，PPP协议采用零比特填充方法来实现透明传输。

零比特填充的具体做法是：

发送方：先扫描整个信息字段(通常是用硬件实现，但也可用软件实现，只是会慢些)。只要发现有5个连续1，则立即填入一个0。因此，经过这种零比特填充后的数据，就可以保证在信息字段中不会出现6个连续1。

接收方：在收到一个帧时，先找到标志字段F以确定一个帧的边界，接着再用硬件对其中的比特流进行扫描。每当发现5个连续1后的一个0删除，以还原成原来的信息比特流。

由于在发送方进行了字节填充，因此，在链路上传送的信息字节数就超过了原来的信息字节数。但接收方在收到数据后再进行与发送方字节填充相反的逆变换，因而可以正确地恢复出原来的信息。

如图4，11所示。这样就保证了透明传输：在所传送的数据比特流中可以传送任意组合的比特流，而不会引起对帧定界的判断错误。

 PPP协议的工作状态

上一节我们通过PPP帧的格式讨论了PPP帧是怎样组成的。但PPP链路一开始是怎样被初始化的？当用户拨号接入ISP，就建立了一条物理层的连接。这时，用户PC机向ISP发送一系列的LCP分组(封装成多个PPP帧)。这些分组及其确认选择了将要使用的一些PPP参数。接着就进行网络层配置，NCP给新接入的用户PC机分配一个临时的IP地址。这样，用户PC机就成为因特网上的一个主机了。

当用户通信完毕时，NCP释放网络层连接，收回原来分配出去的IP地址。接着，LCP释放数据链路层连接。最后释放的是物理层的连接。

上述过程可用图4．12的状态图来描述。

1、PPP链路的起始和终止状态永远是图4-12中的“静止状态”，这时并不存在物理层的连接。

2、当检测到调制解调器的载波信号，并建立物理层连接后，PPP就进入链路的“建立状态”。这时LCP开始协商一些配置选项，即发送LCP的配置请求帧(configure-request)。这是个PPP帧，其协议字段配置为LCP对应的代码，而信息字段包含特定的配置请求。链路的另一端可以发送以下几种响应：

(1)配置确认帧(configure-ack)：所有选项都接受。

(2)配置否认帧(configure-nac)：所有选项都理解但不能接受。

(3)配置拒绝帧(configure-reject)：选项有的无法识别或不能接受，需要协商。

LCP配置选项包括链路上的最大帧长、所使用的鉴别协议(authentication protocol)的规约(如果有的话)，以及不使用PPP帧中的地址和控制字段(因为这两个字段的值是固定的，没有任何信息量，可以在PPP帧的首部中省略这两个字节)。

3、协商结束后就进入“鉴别状态”。

4、若通信的双方鉴别身份成功，则进入“网络状态”。这时PPP链路的两端互相交换网络层特定的网络控制分组（NCP）。如果在PPP链路上运行的是IP，则使用IP控制协议IPCP(IP Control Protocol)来对PPP链路的每一端配置IP模块(如分配IP地址)。和LCP分组封装成PPP一样，IPCP分组也封装成PPP帧(其中的协议字段为0x8021)在PPP链路上传送（0x8021是NCP的协议代吗，这里又说IPCP的协议字段是0x8021，那是不是说明NCP只是一套虚拟的协议框架，具体到特定网络层就对应特定的协议，比如TCP/IP中的网络层就使用IPCP协议进行IP配置？）。

5、当网络层配置完毕后，链路就进入可进行数据通信的“打开状态”。两个PPP端点还可发送回送请求LCP分组(echo－request)和回送应答LCP分组（echo－reply）以检查链路的状态。

6、数据传输结束后，链路的一端发出终止请求LCP分组(terminate-request)请求终止链路连接，而当收到对方发来的终止确认LCP分组(terminate-ack)后，就转到“终止状态”。

7、当载波停止后则回到“静止状态”。

PPP协议概览

PPP是一种数据链路层协议，遵循HDLC（高级数据链路控制协议）族的一般报文格式。PPP是为了在点对点物理链路(例如RS232串口链路、电话ISDN线路等)上传输OSI模型中的网络层报文而设计的，它改进了之前的一个点对点协议–SLIP协议–只能同时运行一个网络协议、无容错控制、无授权等许多缺陷，支持多种网络层协议，能够在多种类型链路上运行（串行、并行、同步、异步、低速、高速等链路），PPP是现在最流行的点对点链路控制协议。

上图中PPP协议中

flag字段恒为0x7f，

地址(adress)字段恒为0xff，

控制(control)字段恒为0x03。

协议（protocol）字段表示PPP报文中封装的payload（data字段）的类型，如果为0x0021，则表示PPP封装的IP报文，0x002B表示IPX报文，0x0029表示AppleTalk报文，这几种都属于PPP的数据报文；如果为0xC021则表示PPP的LCP报文（用来协商连接），如果为0x8021则属于PPP的NCP报文（用来协商封装的三层协议），这些属于PPP的控制报文。

PPP协议状态机如下图所示：

在上图的链接建立阶段，PPP使用LCP报文来协商连接（一种发送配置请求，然后接收响应的简单“握手”过程，不做过多介绍，感兴趣可以去细读RFC1661），协商中双方获得当前点对点连接的状态配置等，之后的“鉴别”阶段使用哪种鉴别方式也在这个协商中确定下来。

鉴别阶段是可选的，如果链接协商阶段并没有设置鉴别方式，则将忽略本阶段直接进入“网络”阶段。鉴别阶段使用建立阶段的链接协商确定下来的鉴别方式来为连接授权，以起到保证点对点连接安全，防止非法终端接入点对点链路的功能。常用的鉴别认证方式有CHAP和PAP方式。

CHAP方式的原理是：

由一端定期发起挑战“challenge”，收到“challenge”的一端将收到的“challenge”报文中的密钥使用之前双发协商好的一种算法加密后再把结果发回发起端，这种算法应该是结果唯一（不同输入必得到不同输出）且不可逆（由输出无法得到输入）的，发起端也使用该算法计算后验证结果是否正确来为对端授权认证。

一个常用的方案实例是：发起端发送随机长度及内容的字符串加上自己的用户名作为“密钥”发送出来，接受到“challenge”的一方将收到的字符串和与对方用户名相对应的本端用户的密码使用MD5算法计算后发回，然后发起端将收到的计算结果和本端MD5计算该随机字符串加自己密码的结果相对照，如果双发一致，则认证成功。

PAP方式简单很多，原理：

直接由被验证方将自己的用户名和密码明文方式发送给对端，由对端对用户名和密码验证来决定是否认证成功。所以，比较而言，CHAP是一种相对更安全一些的验证方式。

需要注意的是，PPP两端双方向的鉴权方式可以不同，即A端为B端鉴权时使用PAP方式（B发送自己的用户名和密码给请A认证），而同时B端使用CHAP方式为A端鉴权（B向A发起CHAP挑战），是完全可以的。

如果鉴别阶段成功，则PPP状态机进入“网络”阶段。这个阶段主要是使用NCP报文来协商将PPP封装怎样的网络层的问题。NCP报文及协商流程和LCP极为相似，就不过多介绍了。

经过网络阶段后，PPP状态机进入OPEN打开状态，在这个状态下，PPP链路上的三层数据报文即可正常通信了。

参考链接：

RFC 1661 The Point-to-Point Protocol

RFC 1994 PPP Challenge Handshake Authentication Protocol

RFC 1334 PPP Authentication Protocols

由于点对点链路的私密性和专有性以及PPP协议在这种点对点链路上的较完美的设计，在TCP/IP广域互联网时代的今天，PPP又在虚拟私有专用网也就是VPN领域发挥了重要的作用，这些将在后面的文章中展开介绍。

普通modem、ISDN以及ADSL拨号中的PPP应用场景

上一篇文章简略的介绍了PPP协议，它帮助人们在简单的点对点链路上实现了上层协议的封装。但是，目前丰富多彩的互联网世界是承载在复杂、庞大的广域网上，灵活方便的非点对点的以太网络是现代网络世界的主要常用媒介，那PPP是否已经远离了我们呢？答案是否定的，实际上，现在我在家中利用ADSL接入ISP登录到我的博客来写这篇文章，这一过程就离不开PPP协议，且听我慢慢道来。

就让我用我们最熟悉的上网为例来讲解吧。早期，人们用计算机外接modem(调制解调器)再通过电话线拨号来接入ISP（Internet接入服务提供商）连接Internet，就使用了PPP协议，具体来说，就是在“用户拨出计算机 – 用户modem – ISP modem -接入服务器”这样一条点对点链路上，使用PPP封装了IP报文来实现用户至Internet网络接入服务器之间IP报文的流控和计费等功能（注：PPP是链路层协议，点对点链路两端的设备物理层只要发现PPP的起止符号，就知道目前线路上传输的是PPP数据），如下图：

点对点链路拨号接入ISP

上图中，“电话线”这一串行连接是通过用户电话拨入电话局提供的接入号码来建立起来的，“拨号”这一概念，也就发端于此。这种拨号方式，用户计算机与ISP接入服务器之间的连接线路完全占用了电话线的信道，所以用户在使用计算机接入网络之后，电话就处于占线状态，不能再同时接入语音电话。并且，这种使用modem通过电话线传输模拟信号的接入方式，最高就只能达到56kbps的上网速率（实际使用时，由于链路问题，连这个速率都很难达到），生活在2009年的我们可以想象那时网民的生活是多么的水深火热…

针对于上述缺陷，人们利用ISDN（综合业务数字网）技术改进了网络接入方案。使用ISDN技术，我们可以在依然使用原来的普通电话线的情况下，在电话线上传输数字信号。这是通过在电话线上建立ISDN信道来实现的，ISDN的BRI(基础速率接口)支持2个B信道+1个D信道总共128kbps的连接速率，我们使用MLPPP（多链路PPP）协议将ISDN提供的多条点对点链路复合为一条点对点链路，这样就可以利用BRI的128kbps速率高速（相对于原来的modem方式）接入网络了。同时，ISDN可以在一条电话线线路上同时接入多个终端设备（计算机、电话等）同时使用。这一切，只需要将上图中的调制解调器换为ISDN接入设备即可。

和ISDN技术类似的，我们现在经常听到和使用的ADSL技术，也是在一定程度上对传统电话线路的信道使用方式进行了优化改造。ADSL是xDSL技术族的一员，传输速率可以达到Mbps数量级，xDSL有ADSL、VDSL、HDSL等多种模型，他们的区别就在于信号传输速率和传输距离上，其中ADSL在这些指标上显示出其非常适合作为家庭接入Internet的特点，所以人们普遍采用了ADSL。

其实，ISDN和ADSL相对于传统modem拨号方式，只是改变了承载信号的物理层。

讲上面这些ISDN和ADSL的内容，目的是为了逐步引出这篇文章的主角 – PPPoE，但是，说真的，直到写完了上面的内容，外加查了很久的资料，我也没真正找到确实可信的论据来证明为什么在ADSL物理链路上我们要选择使用PPPoE来接入ISP…? ^o^?? （使用PPPoE协议可将PPP帧之外再封装上一层PPPoE头，以达到在Ethernet网络这种非点对点链路上传输PPP帧的目的。）

当然，虽然没有找到直接论据，但是分析了众多的资料后我是有收获的，我可以说说自己的理解，有不对之处还请各位指点。

传统的modem拨号和ISDN拨号都是用modem拨ISP的一个号码，也就是得到ISP分配的一条电话线连接来建立起点对点物理链路的，而ADSL也是类似的物理层拓扑，所以我想应该也是可以同样的拨号方式直接接入ISP的。但是，为什么现实中ADSL不是这样来使用的呢，为什么要在ADSL物理层之上再封装“ethernet层+PPPoE层”然后再承载PPP而不是直接在ADSL物理层上承载PPP呢？ISP运营商到底出于什么考虑呢？

如果在ADSL网络上直接封装PPP，则这条点对点链路是起始于用户的ADSL猫，终结于ISP运营商的DSLAM设备，也就是ADSL物理链路的终点。对于用户的管理与认证授权控制必须要放在DSLAM设备上（当然PPP支持远程授权，但这无疑将增加复杂度和风险），这样，ISP必须在很接近用户物理位置也就是网络的末梢底层的地方（因为ADSL物理线路不会很远）来管理用户。

（DSLAM是Digital Subscriber Line Access Multiplexer的简称，中文称呼数字用户线路接入复用器。DSLAM是各种DSL系统的局端设备，属于最后一公里接入设备（the last mile），其功能是接纳所有的DSL线路，汇聚流量，相当于一个二层交换机。）

ADSL拨号接入ISP网络时的PPP链路

而如果采取PPPoE的方式，先将PPP封装在PPPoE内，再在PPPoE外封装Ethernet头，然后再将这Ethernet帧通过ATM或LAPD(Link Access Procedure on the D channel)等链路层协议封装在ADSL或ISDN物理连接上。这样，点对点链路的起点将是封装PPPoE的用户计算机，终点可以是DSLAM，也可以是DSLAM之后的更高层的BAS设备或其他哪里，就看PPPoE服务器被设置在哪里了（PPPoE报文在PPPoE服务器被解开），如上图这种经典的应用场景中PPP链路就直到LNS设备才终结（PC到DSLAM之间是ADSL点对点链路承载PPPoE，DSLAM到BAS之间是ATM链路承载PPPoE，在BAS设备将PPP从PPPoE封装中解出，然后，从BAS到LNS设备之间使用L2TP协议承载了PPP报文，L2TP将在本系列文行的后续文章中介绍）。这样，一是解决方案更加灵活，另外，由于管理设备可以位于更高（更靠近网络核心）的位置，集中管理的用户可以更多，可以降低运营商的成本。

（BAS (Broadband Access Server/ Broadband Remote Access Server) 中文译名： 宽带接入服务器，是一种设置在网络汇聚层的用户接入服务设备，可以智能化地实现用户的汇聚、认证、计费等服务，还可以根据用户的需要，方便地提供多种IP增值业务。）

（LNS表示L2TP网络服务器（L2TP Network Server），是PPP端系统上用于处理L2TP协议服务器端部分的设备。它作为L2TP隧道的另一侧端点，是LAC的对端设备，是被LAC进行隧道传输的PPP会话的逻辑终止端点。）

(

ATM是Asynchronous Transfer Mode异步传输模式的缩写，是实现B-ISDN的业务的核心技术之一。ATM是以信元为基础的一种分组交换和复用技术。它是一种为了多种业务设计的通用的面向连接的传输模式。它适用于局域网和广域网，它具有高速数据传输率和支持许多种类型如声音、数据、传真、实时视频、CD质量音频和图像的通信。 ATM采用面向连接的传输方式，将数据分割成固定长度的信元，通过虚连接进行交换。ATM集交换、复用、传输为一体，在复用上采用的是异步时分复用方式，通过信息的首部或标头来区分不同信道。

其特征：基于信元的分组交换技术；快速交换技术；面向连接的信元交换；预约带宽。

其优点：吸取电路交换实时性好，分组交换灵活性强的优点；采取定长分组（信元）作为传输和交换的单位；具有优秀的服务质量；目前最高的速度为10gb/s,即将达到40gb/s.。

其缺点：信元首部开销太大；技术复杂且价格昂贵。

)

解释到这里，我觉得我这个解释是很合理可信的：PPPoE虚拟拨号的使用使得PPP接入连接（也就是客户）的认证、授权点位置更加灵活，可以将其设置在更接近网路的核心的位置。我认为，PPPoE这种协议的存在，重要的是提供了一种PPP报文的封装方式，至于具体如何封装并不是决定性的，用Ethernet封装就是PPPoE，用ATM封装就是PPPoA。但是，为什么普通modem拨号和ISDN没有采用这样的PPPoE拨号呢？我真的解释不了，因为，理论上是绝对可行的。

本文中讲到了PPPoE协议，但是截至目前，只是讲到用它封装了PPP帧然后放在专线链路（ADSL/ISDN）上传输。至于为什么要用PPPoE，以及PPPoE的具体本领，还是下篇文章再向大家介绍吧。下次再见～

本文参考资料：

• PPPoE wikipedia
• Solaris PPP
• 多业务接入认证技术白皮书
• ISDN技术介绍
• ISDN协议的划分及其介绍
• ADSL技术综述

PPPoE协议与场景

在前文（参见本系列文章的“之二”－普通modem、ISDN以及ADSL拨号中的PPP应用场景）我们了解到了PPP在拨号介入网络中的应用场景，今天，就详细介绍一下PPPoE协议。先看一幅PPPoE接入场景图：

PPPoE场景1

用户在自己的PC上拨号以建立到达图中SSG设备的PPPoE通道。

下图和上图结构相同，在细节上画的更清晰了一些：

PPPoE场景2

从用户PC到modem，从modem到DSLAM，从DSLAM到PPPoE Server的链路和协议栈在前文中都介绍了，读者可以在本场景图中自己回味一下。不清楚或者有疑问的地方欢迎和Hans做深入探讨。

下面介绍PPPoE协议的细节：

上图第一行为Ethernet frame的格式，当ethernet type类型为0×8863时，表示payload承载的是PPPoE协商报文，当类型为0×8864时，表示承载的是PPPoE的会话数据报文。Payload部分就是PPPoE报文的内容了。

第二行中是PPPoE的报文头中，版本、类型字段的数值恒为0×01。Code字段在各种报文中的数值不同，在后面会一一介绍。会话ID表示此报文为哪个PPPoE会话的报文。长度字段表示后面Payload字段的长度。在这个层次上的Payload是一组PPPoE标记（Tag）。

第三行就显示了PPPoE Tag的组织格式，是以一串常见的TLV（类型、长度、值）三元组组成的。

标记(Tag)对照表：

标记类型Type

标记说明

0×0000

表示PPPOE报文数据域中一串标记的结束，为了保证版本的兼容性而保留，在有些报文中有应用。

0×0101

服务名，主要用来表明网络侧所能提供给用户的一些服务。

0×0102

访问集中器名，当用户侧接收到了AC的回应的PADO报文时，就可从所携带的标记中获知访问集中器的名字，而且还可以据此来选择相应的访问集中器。

0×0103

主机唯一标识，类似于PPP数据报文中的标识域，主要是用来匹配发送和接收端的，因为对于广播式的网络中会同时存在很多个PPPOE的数据报文。

0×0104

AC-Cookies，主要被用来防止恶意性DOS功击。

0×0105

销售商的标识符。

0×0110

中继会话ID，对于PPPOE的数据报文也同样可以像DHCP报文一样被中断到另外的AC上终结，这个字段则是用来维护另一个连接的。

0×0201

服务名错误，当请求的服务名不被对端所接受时，会在响应的报文中携带这个标记。

0×0202

访问集中器名出错。

0×0203

一般性错误。

PPPoE的协商流程：

1、PADI（PPPOE Active Discovery Initiation）报文

这是用户主机发起（广播方式）的一个PPPoE服务器探测报文。code字段为0×09，会话ID为0×0000（此时还没有会话session），必须需要包含0×0101标记，这个标记表示主机需要的服务。有时还会带上0×0103这个tag，表示主机的唯一标识。

2、PADO（PPPOE Active Discovery Offer）报文

这是PPPoE服务器收到PADI报文之后的回应报文（目的MAC地址为客户端主机的MAC地址）。当PPPoE报文收到PADI报文后，如果此服务器可以回应主机0×0101标记请求的服务，则可以回应PADO报文。PADO的code字段为0×07，会话ID为0×0000。此报文必须包含0×0102标记以及一些针对收到的PADI报文的确认标记。

3、PADR（PPPOE Active Discovery Request）报文

这是用户主机收到PPPoE服务器回应的PADO报文后，单播（目的地址为此用户选定的那个PPPoE主机的MAC）发起的请求报文。code字段为0×19，session ID为0×0000。包含了0×0101标识。

4、PADS（PPPOE Active Discovery Session-confirmation）报文

PPPoE服务器会为这个会话分配一个唯一的会话ID，并在发送给主机的PADS报文中携带上这个会话ID。当然如果PPPoE服务器不满足用户所申请的服务的话，则会向用户发送一个PADS报文，而其中携带一个服务名错误的标记，而且此时该PADS报文中的会话ID填充0×0000。code为0×65。至此，session ID不再为0x0000，一个PPPoE会话建立成功了，用户和服务器两点之间可以进行会话，也就是可以发送PPP报文了。

5、PADT（PPPOE Active Discovery Terminate）报文

当用户或者服务器需要终止会话时，可以发送这种PADT报文。code字段为0xA7。session ID为希望终止的会话ID。此报文不需要附加任何的tag标识。

PPPoE的会话数据报文

一旦经过前面介绍的协商之后，PPPoE的会话就建立成功了，客户端和服务器获得了会话ID，也就是建立了一条点对点的隧道（tunnel）。此时两端之间就可以发送会话报文，也就是PPP报文了。此时ethernet报文头的type字段为0×8864。PPPoE头的code字段为0×00。此时PPPoE承载的payload就是PPP报文了。

总结：PPPoE为非点对点链路的以太网物理链路上承载PPP报文提供了一种创建虚拟点对点隧道链路的协商方式和封装方式。

参考资料：

1、通过PPPoE为DSL用户提供服务

2、PPPoE基础架构（思科6400UAC）

3、PPPoE标准RFC

PPTP和L2TP简介

在前文中，已经为读者介绍了PPPoE的场景和协议。与PPPoE类似的PPP frame的常见封装方式还有PPTP和L2TP，同样，他们也被用在虚拟拨号的应用场景中。

PPTP

PPTP是来自于微软为首的几个公司的虚拟拨号协议。同PPPoE虚拟拨号的一样，核心思路也是分为了两部分，先协商一条虚拟的点对点“链路”，然后在此链路上传输PPP封装的报文。

PPTP的链路协商报文是使用IP协议的TCP头来封装PPTP报文的(TCP为其保证了可靠性和重传机制)。

通过协商建立好连接后，封装在PPTP头内的PPP报文是通过IP协议的GRE头来封装的。所以，PPTP有一个天生的劣势，就是它只能承载在IP之上（当然，如果需要，你也可以再将IP承载在其他协议），我觉得，这就是依赖TCP来保证可靠传输的代价。

L2TP

而L2TP就要灵活的多。L2TP是思科公司的L2F协议的进化（很多地方介绍L2TP是L2F和PPTP二者合二为一的进化，但是从协议的设计来看，我觉得L2TP与L2F要比与PPTP显得亲近的多）。与PPTP不同，L2TP的链路控制报文和封装PPP数据报文用L2TP头封装后，统一使用一种方式传输－－ （如果是IP协议承载，就封装在UDP头内，此外，也可以封装在FrameRelay,ATM,X.25等协议）。L2TP的链路控制报文的保序、重传等可靠性是通过自己的L2TP头内的报文序列号来控制实现的。

L2TP的一条点对点tunnel可以承载n条PPP会话，在一条tunnel不同的会话可以使用会话ID来互相区分，而PPTP只能承载一路会话。
L2TP在IP网络上一般都使用IPSEC来进行加密实现安全性。PPTP有微软设计的MPP加密方式来加密。

此文主要点出了L2TP和PPTP的各自特点和基本应用方式，对于L2TP和PPTP的协议细节，网络上资料很多，RFC的讲述非常翔实，本文就不作过多的讲述了。如果有对其某些方面感兴趣的朋友，欢迎和Hans一起讨论。

参考资料：

Understanding PPTP

Point-to-Point Tunneling Protocol (PPTP)

CISCO L2F RFC

L2TP wikipedia

L2TP Encyclopedia

http://adreaman.com/0412ppp-pppoe-pptp-l2tp-vpn-synopsis-no1.html

http://www.360doc.com/content/10/0413/16/163747_22867488.shtml

http://www.cnblogs.com/kzloser/archive/2012/07/08/2581644.html