PPP协议运行原理(一)

任何第3层的协议要通过拨号或者专用链路穿越广域网时，都必须封装一种数据链路层的协议（比如，PPP、SLIP——串行链路Internet协议、ARAP——AppleTalk远程接入协议）。尽管某些公司仍然使用Novell IPX和AppleTalk协议为主机提供远程接入，但是TCP/IP已经成为了今天企业网中使用的主要协议。
今天，在广域网的数据链路层主要有两种用于封装TCP/IP的协议：SLIP和PPP
SLIP——使用TCP/IP进行点对点连接的标准协议。SLIP是PPP的前身，因其只支持IP协议和异步传输方式而且没有验证机制，所以已经很少在新设计的网络中出现了。
PPP——点对点协议，通过异步或同步电路提供路由器到路由器或者主机到网络的连接。这些电路可能是拨号或者租用线路。
PPP支持IP、IPX和AppleTalk等多种网络层协议，还支持如下特性：
同步/异步传输方式
动态地址分配
PAP认证
CHAP认证
MLP（多链路捆绑）

本篇文章描述的就是这个PPP协议。

PPP的分层结构：

PPP协议的运行分为四个阶段：
第一阶段：建立链路（LCP）
第二阶段：验证（PAP/CHAP）
第三阶段：网络控制协商（NCP）
第四阶段：终止PPP链路（LCP）

PPP协议工作的第一阶段我们称为链路建立的阶段，在这个阶段中PPP首先使用LCP（链路控制协议）在链路两端建立连接。在该阶段中PPP不只是在数据链路层搭建链路而且还在链路的两端动态协商一些参数，比如双方使用的认证方式、是否支持压缩和MLP（多链路捆绑）等。
LCP若要完成建立、配置、测试和终止数据链路连接的工作就需要通信两端互相交换LCP报文。那都有哪几类LCP报文呢？LCP报文基本上有三类：
链路配置报文——用来建立和配置一条链路
链路维护报文——用来维护和调试链路
链路终止报文——用来终止一条链路
LCP协议在链路两端建立连接时还会经历4种状态，如果一切进行顺利的话，随着这4种状态的结束，链路两端的连接将会搭建成功。
第1种状态机：“Initial（初始化状态）”或“Starting（准启动状态）”
该状态机发生在链路无效阶段：该阶段双方物理连接已搭建好，但通信的两端没有激活（封装）PPP，或者物理连接根本就没有搭建好。
第2种状态机：Request-Sent（请求发送）
第3种状态机：Ack-Sent（确认发送）
第4种状态机：Open（打开）
除了第1种状态机，其余3种状态机都发生在第一阶段(链路的建立阶段)。
链路建立阶段：当通信双方的两端都检测到链路上有载波信号时，且双方都已封装了PPP协议就标志着通信的两端已进入到链路建立阶段了。该阶段的通信发生在数据链路层，也是PPP协议最为关键和复杂的阶段。在这个阶段首先链路两端的LCP会由链路无效阶段的“Initial”或“Starting”状态过渡到“Request-Sent（请求发送）”状态。在Request-Sent（请求发送）状态下，双方会发送上面提到的LCP三种报文中的“链路配置报文”。链路配置报文又细分以下四种：
1、Config-Request（配置请求）
2、Config-Ack（配置确认）
3、Config-NAK（配置非确认）
4、Config-Reject（配置拒绝）
在“Request-Sent（请求发送）”状态下，通信双方的任何一方都会先发送Config-Request报文。Config-Request报文结构如下：

Code：Configuration Request (0x01)
Identifier：0x00
Length：17
Options：(13 bytes)
Maximum Receive Unit：1480
Magic number：0x7a9b5da2
Callback：3 bytes
Operation：Location is determined during CBCP negotiation (0x06)

报文中的Code(代码)后面添写的是报文的名称，如本例中的报文是“Configuration Request (0x01) (配置请求)”报文。
“Identifier”指的是“标识”，每个链路配置报文都会携带一个“标识”，双方在建立连接的过程中可能要发送多个Config-Request报文，这个“标识”会区别本方或对方发送的这些Config-Request报文，第一个Config-Request 报文的“标识”通常由“0x00”开始，那第二Config-Request报文的标识就变为了“0x01”，以此类推……；
“Length”表明这个“Config-Request”报文的长度，本例为17字节；
“Options(选项)”用于动态协商一些参数，比如本例中的Maximum Receive Unit(最大接收单元)、Magic number(魔术字)、Callback(回拨)等等；
通信两端中的任何一方收到Config-Request报文后，各自的LCP状态机就立即由“Request-Sent（请求发送）”状态进入“Ack-Sent（确认发送）”状态。处于“Ack-Sent（确认发送）”状态中的一方会向对方发送“Config-Ack（配置确认）”报文。Config-Ack（配置确认）报文结构如下：
Code：Configuration Ack (0x02)
Identifier：0x01
Length：17
Options：(13 bytes)
Maximum Receive Unit：1480
Magic number：0x7a9b5da2
Callback：3 bytes
Operation：Location is determined during CBCP negotiation (0x06)

从以上两个“链路配置报文”结构可以看出Config-Ack（配置确认）报文与Config-Request（配置请求）报文不同之处在于“Code(代码)”这个字段后填写的内容。从这两个报文可以看出发送方的“Code(代码)”是“0x00”，而接收方回复的“Code(代码)”是“0x01”，其他字段没有什么不同。无论通信双方的哪一端接收到对端发送的Config-Ack报文，接收方的LCP的状态机都会发生改变，LCP状态机就从当前的“Ack-Sent（确认发送）”状态进入到最后的opened(打开)状态。
前面的内容中我们看到LCP协议的选项字段会协商双方的认证方式，比如协商双方使用PAP还是CHAP等。缺省(默认)情况下链路两端的设备是不需要进行认证的，如果通信的双方没有配置任何认证方式，而且双方也不需要NCP协议来协商如何分配IP地址的问题，双方仅仅只是想通过PPP实现数据链路层的连接而已，那么链路两端的设备在经历了前面提到的LCP四种状态后就已经完成了链路层的连接了。可是多数情况下，链路两端设备都会出于安全方面的考虑进行PPP认证，也就是进行PAP或CHAP协商。关于PAP或CHAP的协商验证在后面还会详细说明。除此之外双方可能还要在LCP选项字段中协商一些其他参数，比如是否支持压缩、多链路捆绑、回拨等参数。下面我们就来看看LCP选项中的这些参数是如何进行协商的。
通信两端收到对方发送的“Config-Request（配置请求）”报文后，会查看该报文中的选项字段。比如通信两端的设备分别为A和B，设备A发送的“Config-Request（配置请求）”报文的选项字段需要协商认证方式(CHAP)、最大传输单元这两项。设备B发送的“Config-Request（配置请求）”报文中的选项需要协商认证方式(PAP)、最大传输单元和回拨这三项。当A收到B发送的“Config-Request（配置请求）”报文后，由于A并不支持回拨这一属性，所以A会向B发送“链路配置报文”中的第四种报文——Config-Reject（配置拒绝）报文。“Config-Reject（配置拒绝）”报文表明接收方对于发送方发送的“Config-Request（配置请求）”报文中选项提到的某个配置参数不予接受。比如本例中的A会通过“Config-Reject”报文向B通告“回拨”这个属性是A所不能接受的。B接收到A发送的“Config-Reject”报文后，会再向A发送一个“Config-Request（配置请求）”报文，在该报文中B会将选项中的“回拨”属性删除。如果此时A和B双方采用的认证方式也不同(假如A使用CHAP进行认证而B使用PAP进行认证)，那么A或B会向对方发送“链路配置报文”中的第三种报文——Config-NAK（配置非确认）报文。“Config-NAK（配置非确认）”与“Config-Reject（配置拒绝）”的区别是：当接收到“Config-Request（配置请求）”报文的一端能够识别发送方所发送过来的所有配置参数，但对某些配置参数中的具体协商内容不认可时，接收方将会给对端回应一个“Config-Nak（配置非确认）”报文。而“Config-Reject（配置拒绝）”报文是对收到的“Config-Request（配置请求）”报文中的某些配置参数不认可（而不是参数中的具体内容不认可）而向对方发送的报文。比如前面提到的A对B发送过来的“回拨”参数不认可，所以A向B发送“Config-Reject（配置拒绝）”报文表明自己对“回拨”这一参数不予接受。再比如本例中A又向B发送了“Config-Nak（配置非确认）”报文，说明A对B发送的“Config-Request（配置请求）”报文中提到的“认证”这一参数是认可的，但对B在“认证”这一参数中使用“PAP进行认证”不予接受，所以A才向B发送“Config-Nak（配置非确认）”报文。该报文中的选项会携带A所支持的认证协议——CHAP这个参数。B收到该“Config-Nak（配置非确认）”报文后就会向A再发送另一个“Config-Request（配置请求）”报文，在这个“Config-Request（配置请求）”报文中B将自己原来的PAP认证方式更改为A支持的CHAP认证方式(当然，前提是设备B已经被管理员配置为可同时支持PAP和CHAP两种认证方式，而A只支持CHAP认证)，最后A再向B发送一个“Config-Ack（配置确认）”报文，对双方使用的CHAP这种认证方式表示同意和确认。经过设备A和设备B这样地反复协商和交互，通信双方在LCP子层的协商最终完成。如果双方在这个协商过程中出现了协商配置参数不匹配、不统一或协商配置参数匹配但参数中的具体内容不匹配都会导致协商失败。从LCP协商的过程看，双方秉承的基本原则是“求同摒异”。
待续……