来自：http://adreaman.com/0412ppp-pppoe-pptp-l2tp-vpn-synopsis-no1.html
PPP
PPP是一种 数据链路层协议，遵循HDLC（高级数据链路控制协议）族的一般报文格式。PPP是为了在点对点物理链路(例如RS232串口链路、电话ISDN线路等)上传输OSI模型中的网络层报文而设计的，它改进了之前的一个点对点协议–SLIP协议–只能同时运行一个网络协议、无容错控制、无授权等许多缺陷，PPP是现在最流行的点对点链路控制协议。
上图中PPP的flag字段恒为0x7f，地址(adress)字段恒为0xff，控制(control)字段恒为0×03.协议（protocol）字段表示PPP报文中封装的payload（data字段）的类型，如果为0×0021，则表示PPP封装的IP报文，0x002B表示IPX报文，0×0029表示AppleTalk报文，这几种都属于PPP的数据报文；如果为0×8021则表示PPP的LCP报文（用来协商连接），如果为0xC021则属于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领域发挥了重要的作用，这些将在后面的文章中展开介绍。
上一篇文章简略的介绍了PPP协议，它帮助人们在简单的点对点链路上实现了上层协议的封装。但是，目前丰富多彩的互联网世界是承载在复杂、庞大的广域网上，灵活方便的非点对点的以太网络是现代网络世界的主要常用媒介，那PPP是否已经远离了我们呢？答案是否定的，实际上，现在我在家中利用ADSL接入ISP登录到我的博客来写这篇文章，这一过程就离不开PPP协议，且听我慢慢道来。
就让我用我们最熟悉的上网为例来讲解吧。早期，人们用计算机外接modem(调制解调器)再通过电话线拨号来接入ISP（Internet接入服务提供商）连接Internet，就使用了PPP协议，具体来说，就是在“用户拨出计算机 – 用户modem – ISP modem -接入服务器”这样一条点对点链路上，使用PPP封装了IP报文来实现用户至Internet网络接入服务器之间IP报文的流控和计费等功能，如下图：
上图中，”电话线“这一串行连接是通过用户电话拨入电话局提供的接入号码来建立起来的，”拨号“这一概念，也就发端于此。这种拨号方式，用户计算机与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物理线路不会很远）来管理用户。
而如果采取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将在本系列文行的后续文章中介绍）。这样，一是解决方案更加灵活，另外，由于管理设备可以位于更高（更靠近网络核心）的位置，集中管理的用户可以更多，可以降低运营商的成本。
解释到这里，我觉得我这个解释是很合理可信的：PPPoE虚拟拨号的使用使得PPP接入连接（也就是客户）的认证、授权点位置更加灵活，可是将其设置在更接近网路的核心的位置。我认为，PPPoE这种协议的存在，重要的是提供了一种PPP报文的封装方式，至于具体如何封装并不是决定性的，用Ethernet封装就是PPPoE，用ATM封装就是PPPoA。但是，为什么普通modem拨号和ISDN没有采用这样的PPPoE拨号呢？我真的解释不了，因为，理论上是绝对可行的。
本文中讲到了PPPoE协议，但是截至目前，只是讲到用它封装了PPP帧然后放在专线链路（ADSL/ISDN）上传输。至于为什么要用PPPoE，以及PPPoE的具体本领，还是下篇文章再向大家介绍吧。下次再见～
本文参考资料：
在前文（参见本系列文章的“之二”－ 普通modem、ISDN以及ADSL拨号中的PPP应用场景）我们了解到了PPP在拨号介入网络中的应用场景，今天，就详细介绍一下PPPoE协议。先看一幅PPPoE接入场景图：
用户在自己的PC上拨号以建立到达图中SSG设备的PPPoE通道。
下图和上图结构相同，在细节上画的更清晰了一些：
从用户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)对照表：
。。。。。。。。。。。。。。。。
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报文提供了一种创建虚拟点对点隧道链路的协商方式和封装方式。
参考资料：
在前文中，已经为读者介绍了PPPoE的场景和协议。与PPPoE类似的PPP frame的常见封装方式还有PPTP和L2TP，同样，他们也被用在虚拟拨号的应用场景中。
PPTP是来自于微软为首的几个公司的虚拟拨号协议。同PPPoE虚拟拨号的一样，核心思路也是分为了两部分，先协商一条虚拟的点对点“链路”，然后在此链路上传输PPP封装的报文。PPTP的链路协商报文是使用IP协议的TCP头来封装PPTP报文的(TCP为其保证了可靠性和重传机制)，通过协商建立好连接后，封装在PPTP头内的PPP报文是通过IP协议的GRE头来封装的。所以，PPTP有一个天生的劣势，就是它只能承载在IP之上（当然，如果需要，你也可以再将IP承载在其他协议），我觉得，这就是依赖TCP来保证可靠传输的代价。
而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一起讨论。
参考资料：
Point-to-Point Tunneling Protocol (PPTP)
下一节将介绍PPTP, L2TP, 和VPN
8115
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
