1、背景知识：数据链路层协议完成什么功能
我们知道，数据链路层协议运行在物理层之上，网络层之下。而底层的物理层，只能提供简单的bit流的物理信道，功能非常原始，如果直接使用物理层进行通讯，肯定是非常不方便的，所以数据链路层会在底层物理层提供的功能基础之上，提供一些增值服务，方便上面的网络层使用。所以可能认为数据链路层是对物理层功能的增强。如果您想用尽量少的词来记住数据链路层，那就是：“帧和介质访问控制”。典型的数据链路层功能包括：
1.1、报文成帧问题
为了使传输中发生差错后只将有错的有限数据进行重发，同时，也为了上层使用起来更加方便，数据链路层将比特流组合成以帧为单位传送。每个帧除了要传送的数据外，还包括校验码，以使接收方能发现传输中的差错。帧的组织结构必须设计成使接收方能够 明确地从物理层收到的比特流中对其进行识别，也即能从比特流中区分出帧的起始与终止，这就所谓的报文成帧问题。
- 能在bit流中标识出一个帧的起止位置
- 能对一帧报文的完整性做一定的校验
1.2、链路的建立管理与维护
当链路两端的节点要进行通信前，必须
- 首先确认对方已处于就绪状态，如果对端还没有就绪，本端就开始发送通讯，所有信息必然会丢失，这样的通讯是没有任何价值的。并交换一些必要的信息以对帧序号初始化，然后才能建立连接。
- 在传输过程中则要能维持该连接。如果出现差错，需要重新初始化，重新自动建立连接。
- 传输完毕后则要释放连接。数据连路层连接的建立维持和释放就称作链路管理。
- 在多个站点共享同一物理信道的情况下（例如在LAN中）如何在要求通信的站点间分配和管理信道也属于数据链路层管理的范畴。
- 与物理信道通讯密切相关的，还有另外一个问题，是通讯端的编址问题。（比如以太网的MAC地址）
1.3、可靠性问题
数据链路层的可靠性，包括两个子问题，第一个是差错控制，第二个是流量控制。
- 差错控制：在数据通信过程中可能会因物理链路性能和网络通信环境等因素，难免会出现一些传送错误，但为了确保数据通信的准确，又必须使得这些错误发生的几率尽可能低。这一功能也是在数据链路层实现的，就是它的”差错控制”功能。差错控制通常使用一些冗余编解码技术，达到发现错误，甚至修正错误的目的。
- 流量控制：在双方的数据通信中，如何控制数据通信的流量同样非常重要。它既可以确保数据通信的有序进行，还可避免通信过程中不会出现因为接收方来不及接收而造成的数据丢失。这就是数据链路层的”流量控制”功能。数据的发送与接收必须遵循一定的传送速率规则，可以使得接收方能及时地接收发送方发送的数据。并且当接收方来不及接收时，就必须及时控制发送方数据的发送速率，使两方面的速率基本匹配。
2、PPP协议要解决哪些问题
PPP协议是一个数据链路层协议，所以它会解决标准数据链路层协议的所有问题，包括
1.成帧问题 ：将物理层的bit流转换为二层帧
2.链路维护：链路的建立，维护与拆除
3.可靠性问题：差错控制与流量控制
除此之外，PPP协议还提供了很多其他的附加功能，正是因为这些功能的提供，使得PPP协议称为一个使用非常广泛的链路层协议。
- PPP具有身份验证功能
- PPP具有错误检测以及纠错能力，支持数据压缩；
- PPP支持多种网络协议，比如TCP/IP、NetBEUI、NWLINK等；
- PPP具有动态分配IP地址的能力；
3. PPP协议如何解决这些问题
3.1、成帧问题
PPP协议为串行链路上传输的数据报定义了一种封装方法，它基于高层数据链路控制（HDLC）标准。
开始结束标记：PPP帧以标志字符01111110开始和结束
地址字段： 长度为1字节，内容为标准广播地址11111111（0xFF）。我们熟知网络是分层的，且对等层之间进行相互通信，而下层为上层提供服务。当对等层进行通信时首先需获知对方的地址，而对不同的网络，在数据链路层则表现为需要知道对方的MAC地址、X.121地址、ATM地址等；在网络层则表现为需要知道对方的IP地址、IPX地址等；而在传输层则需要知道对方的协议端口号。例如如果两个以太网上的主机希望能够通信的话，首先发送端需获知对端的MAC地址。但由于PPP协议是被运用在点对点的链路上的特殊性，它不像广播或多点访问的网络一样，因为点对点的链路就可以唯一标示对方，因此使用PPP协议互连的通信设备的两端无须知道对方的数据链路层地址，所以该字节已无任何意义，按照协议的规定将该字节填充为全1的广播地址。
控制字段： 为00000011。同地址域一样，PPP数据帧的控制域也没有实际意义，按照协议的规定通信双方将该字节的内容填充为0x03。（既然无意义，就可以随便赋值了吧，呵呵，只要大家都遵守一个标准就行）
协议字段： 长度为2个字节，其值代表其后的数据字段所属的网络层协议，如：0x0021代表IP协议，0xC021代表LCP数据，0x8021代表NCP数据等。数据字段包含协议字段中指定的协议的数据报，长度为0～1500字节。CRC字段为整个帧的循环冗余校验码，用来检测传输中可能出现的数据错误。
即使使用所有的帧头字段，PPP协议帧也只需要8个字节就可以形成封装。如果在低速链路上或者带宽需要付费的情况下，PPP协议允许只使用最基本的字段，将帧头的开销压缩到2或4个字节的长度，这就是所谓的PPP帧头压缩。
3.2、链路的建立、管理与维护
PPP协议有两个重要部分组成：LCP和NCP，LCP就是其中用来进行链路层的通道建立、管理与维护的部分。
一次完整的PPP会话过程包括四个阶段: 链路建立阶段、确定链路质量阶段、网络层控制协议阶段和链路终止阶段。
- (1) 链路建立阶段：PPP通信双方用链路控制协议交换配置信息，一旦配置信息交换成功，链路即宣告建立。配置信息通常都使用默认值，只有不依赖于网络控制协议的配置选项才在此时由链路控制协议配置。值得注意的是，在链路建立的过程中，任何非链路控制协议的包都会被没有任何通告地丢弃。
(2) 链路质量确定阶段：这个阶段在某些文献中也称为链路认证阶段。链路控制协议负责测试链路的质量是否能承载网络层的协议。在这个阶段中，链路质量测试是PPP协议提供的一个可选项，也可不执行。同时，如果用户选择了验证协议，验证的过程将在这个阶段完成。PPP支持两种验证协议：密码验证协议（PAP）和握手鉴权协议(CHAP)。
(3) 网络层控制协议阶段：PPP会话双方完成上述两个阶段的操作后，开始使用相应的网络层控制协议配置网络层的协议，如：IP、IPX等。
(4) 链路终止阶段：链路控制协议用交换链路终止包的方法终止链路。引起链路终止的原因很多：载波丢失、认证失败、链路质量失败、空闲周期定时器期满或管理员关闭链路等。
3.2.1、链路层参数协商（LCP）
LCP会进行一些链路层参数的协商，只有通过LCP协商之后，才会启动后续的认证和网络层参数协商过程
一次LCP协商过程如下：
- 1、RTA进入Link Establishment，物理层向数据链路层发送up事件
- 2、RTA首先进入LCP第一个状态，即Request-Sent状态，并向外发送Configure-Request报文
- 3、如果RTB同意协商的参数，回复一个Configure-Ack报文（主要协商MRU、MagicNum）
- 4、只要收到Configure-Ack报文后，进入LCP第二状态，即Opened状态，表示本RTA的Link Establishment阶段协商结束，并向下一状态跃迁。
至此，LCP两个状态完成，可以向下一个阶段Network Layer Protocol或者Autiontication跃迁
在Link Establishment阶段，P2P双方至少发一个Config-Request报文，该报文中包含了发送方对于所有的配置参数的期望值。
- 1、如果对方对于自己发送的Config-Request回应了一个Config-Ack，则说明对方已经认可了自己提出的所有配置参数的期望值；
- 2、如果对方对于自己发送的Config-Request回应了一个Config-Nak，则说明对方否定了自己提出的所有配置参数或者部分配置参数的期望值，这也就意味着自己必须修改相应配置参数的期望值，然后向对方重新发送一个Config-Request报文，且等待对方新的回应；
- 3、如果双方最终收到对方发送的Config-Ack报文，则说明对方对于自己提出的配置参数的协商已经取得了一致，这同时也标志着Link Establishment阶段顺利结束。
3.2.2、PPP的安全认证（PAP、CHAP）
PPP相对其他协议的一个非常重要的功能特性是其内置了安全认证机制，这也是该协议在用户接入侧被广泛使用的一个重要原因。安全认证过程内置在协议规程中，并且在链路建立起来之前被执行。很好的保证了接入链路的安全性。
验证过程在PPP协议中为可选项。在连接建立后进行连接者身份验证的目的是为了防止有人在未经授权的情况下成功连接，从而导致泄密。PPP协议支持两种验证协议：
(1) 口令验证协议(PAP): 口令验证协议的原理是由发起连接的一端反复向认证端发送用户名/口令对，直到认证端响应以验证确认信息或者拒绝信息。
简单口令认证协议PAP
(2) 握手鉴权协议（CHAP）：CHAP用三次握手的方法周期性地检验对端的节点。其原理是：认证端向对端发送“挑战”信息，对端接到“挑战”信息后用指定的算法计算出应答信息然后发送给认证端，认证端比较应答信息是否正确从而判断验证的过程是否成功。如果使用CHAP协议，认证端在连接的过程中每隔一段时间就会发出一个新的“挑战”信息，以确认对端连接是否经过授权。
CHAP握手鉴权协议
这两种验证机制共同的特点就是简单，比较适合于在低速率链路中应用。但简单的协议通常都有其他方面的不足，最突出的便是安全性较差。一方面，口令验证协议的用户名/口令以明文传送，很容易被窃取；另一方面，如果一次验证没有通过，PAP并不能阻止对端不断地发送验证信息，因此容易遭到强制攻击。
挑战握手协议的优点在于密钥不在网络中传送，不会被窃听。由于使用三次握手的方法，发起连接的一方如果没有收到“挑战信息”就不能进行验证，因此在某种程度上挑战握手协议不容易被强制攻击。但是，CHAP中的密钥必须以明文形式存在，不允许被加密，安全性无法得到保障。密钥的保管和分发也是CHAP的一个难点，在大型网络中通常需要专门的服务器来管理密钥。
3.2.3、PPP网络层协商（NCP）
在完成安全认证后，PPP还支持上层网络层协议一些参数的协商，这也是PPP非常有特点的一个设计。不同的上层网络层协议，可能会有不同的协商内容。PPP协议为上层网络层参数协商定义了一套标准的规程，同时又支持多种不同的上层协议进行协商。设计的可扩展性非常好。
NCP协议主要包括IPCP、IPXCP等，但我们在实际当中最常遇见的也只有IPCP协议
3.2.3.1、IPCP控制协议
IPCP控制协议主要是负责完成IP网络层协议通信所需配置参数的选项协商，负责建立，使能和中止IP模块。IPCP在运行的过程当中，主要是完成点对点通信设备的两端动态的协商IP地址。IPCP包在PPP没有达到网络层协议阶段以前不能进行交换，如果有IPCP包在到达此阶段前到达会被抛弃。
IPCP到底需要协商一些什么参数呢？最重要的是下面两项：
- 一是关于IP报文的压缩方式，也就是协商双方在传递IP报文的时候，IP报文是采用标准的、非压缩形式的报文格式呢，还是采用压缩形式的报文格式；
- 二是关于接口的IP地址，因为PPP没有ARP协议，本地怎么知道对端接口IP地址是不是合法的，怎么知道对端是不是和本地的接口IP地址冲突呢？所以希望协商双方的接口IP地址合法性，代替了ARP协议功能。
IPCP控制协议协商有两种方式：静态和动态：
静态协商，也即不协商。点对点的通信设备两端在PPP协商之前已配置好自身IP地址，所以不用在Network阶段协商IP地址，而双方唯一要做的就是告诉对方自身的IP地址，并且对方是否承认我的IP地址合法。在IPCP控制协议完成整个配置的过程时，最理想的情况将会看到如图所示的四种报文，而无其它报文再被发送。
静态协商过程
在静态协商时，发送方和接收方都同时发送Config-Request报文，其中option中只含有该接口IP地址，当对端收到该报文后，会发送一个Config-Ack报文，且Config-Ack中带着对方的IP地址，这个目的是告诉对端："单播IP地址，且和我没有冲突，请放心使用"，其实和ARP功能一样。 刚进入网络层协议阶段时， IPCP的状态机是initial的，但当完成了上述的整个过程后， IPCP的状态机改变为Opened，双方也就可以开始网络层数据网的传送了
动态协商 也即是一端配置为动态获取IP地址；另一端通过手动方式配置IP地址，且允许给对端分配IP地址，类似DHCP分配地址给对方
动态协商IP地址过程
1、Client没有配置IP地址，所以在IPCP的Config-Request报文的IP地址配置参数配置选项中的IP地址填充全0（也即是0.0.0.0）；
2、当Server收到这个Config-Request报文时，收到Client配置请求报文后会检测IP地址的内容，如果发现为全0，则认为对端的这个IP地址是我要分配给对方IP地址，并将希望分配给对方的IP地址填充到Config-Nak报文内，这样就回应一个Config-Nak报文。
3、Client收到Config-Nak报文后，就会有自己的IP地址，重新发送一个Config-Request报文，这个报文中的IP地址配置选项为Server在Config-Nak报文中所提供的。静态分配的IP地址，对client路由器而言，会在该接口上产生一条到对端接口的32位主机路由
4、Server收到后，只需发送一个Config-Ack报文，告诉Client，就表示接收方的IP地址配置完成。
3.3、PPP其他特性1 - 链路质量监控
PPP内置了的链路质量检测机制， PPP 通过定义链路质量报告包 （Link-Quality-Report Packet）和它的详细处理过程，为链路质量监控详细说明了监控机制。 PPP 没有具体说明链路质量监控策略――如何断定链路质量或者当链路不充分时该怎么 做。这个被留做一个实现决策，并且在链路的各端可能是有差别的。用各种各样的方法去实 现这一决策是被允许甚至鼓励的。链路质量监控机制说明书保证了使用不同策略的两个实现 可以实现通信和进行内部操作。
3.4、PPP其他特性2 - 环路检测
Magic-Number： 魔数字段用于辅助检测链路自环。这是在链路建立过程中比较重要的一个参数，这个参数是在Config-Request里面被协商的，主要的作用是防止环路，如果在双方不协商魔术字的情况下，某些LCP的数据报文需要使用魔术字时，那么只能是将魔术字的内容填充为全0；反之，则填充为配置参数选项协商后的结果
魔术字在目前所有的设备当中都是需要进行协商的，它被放在Config-Request的配置选项参数中进行发送，而且需要由自身的通信设备独立产生，协议为了避免双方可能产生同样的魔术字，从而导致通信出现不必要的麻烦，因此要求由设备采用一些随机方法产生一个独一无二的魔术字。一般来说魔术字的选择会采用设备的系列号、网络硬件地址或时钟。双方产生相同魔术字的可能性不能说是没有的，但应尽量避免，通常这种情况是发产在相同厂商的设备进行互连时，因为一个厂商所生产的设备产生魔术字的方法是一样的。
我们知道魔术字产生的作用是用来帮助检测链路是否存在环路，当接收端B收到一个Config-Request报文时，会将此报文与上一次所接收到（应该是上一次发送出）的Config-Request进行比较，如果两个报文中所含的魔术字不一致的话，表明链路不存在环路。但如果一致的话，接收端B认为链路可能存在环路，但不一定存在环路，还需进一步确认。此时接收端B将发送一个Config-Nak报文，并在该报文中携带一个重新产生的魔术字，而且此时在未接收到任何Config-Request或Config-Nak报文之前，接收端B也不会发送任何的Config-Request报文。这时我们假设可能会有以下两种情况发生：
1.链路实际不存在环路，而是由于对方A在产生魔术字时与接收端B产生的一致，但实际这种情况出现的概率是很小的。当Config-Nak被对端A接收到后，A应该发送一个Config-Request报文（此报文中的魔术字为接收到的Nak报文中的），当B接收到后，与上次的Config-Request比较，由于接收端B已经在上一次的Nak报文中产生了一个不同的魔术字，此时接收端B收到的Config-Request报文中的魔术字与上次B发出的Config-Request配置请求报文中不一样，所以接收端B可断定链路不存在环路。
2.链路实际上确实存在环路，一段时间后Config-Nak报文会返回到发送该报文的同一端B。这时接收端B比较这个Config-Nak报文与上一次发出去的Config-Nak报文一样，因此链路存在环路的可能性又增大了。我们知道当一端收到了一个Config-Nak报文时，又会发送一个Config-Request报文（该报文中的魔术字与Config-Nak中的一致），这样又回到了最初的状态，在这条链路上就会不断的出现Config-Request、Config-Nak报文，因此这样周而复始下去，接收端就会认为PPP链路存在环路的可能性在不断增加，当达到一定数量级时，就可认为此链路存在环路。（注意，不是第一次受到相同的魔术字就判断有环路的）
但在实际应用中根据不同设备实现PPP协议的方法，我们在链路环路检测时可采用两种方法。第一种机制就是如上面所述的，这个过程不断地重复，最终可能会给LCP状态机发一个Down事件，这时可能会使LCP的状态机又回到初始化阶段，又开始新一轮的协商。当然对于某些设备还会采用第二种机制，就是不产生任何事件去影响当前LCP的状态机，而是停留在请求发送状态。但这时认为链路有环路的一端设备需要不断的向链路上发送Echo-Request报文来检测链路环路是否被解除，当接收端收到Echo-Reply报文时，就认为链路环路被解除，从而就可能进行后续的PPP的过程。
3.5、PPP其他特性3 - 报文压缩
PPP在LCP和NCP协商期间，都可以对各自的报文或报文头协商是否需要启用压缩机制。比如PPP头的压缩，或者IP报文的压缩等。
3.6、PPP的可靠性
PPP是一个不可靠的二层协议，PPP并不提供关于流量控制，差错控制等可靠性机制，他把这些问题留给上层协议去解决。
其实这是很明智的做法，OSI七层模型中，各个层次都有相应的差错控制协议，比如二层链路层的等停协议或滑动窗口协议，到了传输层（如TCP），又有自己的可靠性协议。这样反反复复的各个层面都在做同样的事情，浪费了资源，并且带来了额外的复杂度。
PPP将可靠性问题留给上层去解决，自己则将更多的精力集中在上层没有解决的问题域上。最终取得了更好的效果。（PPP协议的广泛使用就是一个这种效果的一个很好的证明）
参考文献：
https://wenku.baidu.com/view/7f7391fef9c75fbfc77da26925c52cc58bd690d1.html
PPP协议详解及举例
https://wenku.baidu.com/view/118ad274580216fc700afd5f.html
PPP基本原理（HW）
http://forum.huawei.com/enterprise/thread-364813.html
