ppp协议功能

ppp协议功能

首先看看”SLIP“协议。改协议能够理解为PPP的一个简化版本，对于加深对PPP协议的理解有些帮助。    此外，经过观察“SLIP”协议的一些不足，可让咱们更加深刻的理解PPP协议的设计的巧妙和针对性 SLIP简单封装方式的缺陷： 由于没有一个协商的过程，因此不少参数（好比ip地址）就须要实现直到 没有一个域来指定上层协议，因此这里确定只能使用一种协议，并且由于没有实现协商的机制，因此动态的决定没法实现 没有校验和，某些错误没法及时发现。而须要等到上层协议来处理。浪费系统资源 注意ppp和咱们经常使用的以太网没什么必然的联系。都属于数据链路层。 地址域(Add),数据帧(Ctrl的控制域也没有实际意义 考虑到ppp协议是点对点协议，因此ppp协议无需以太网哪一种mac地址。 协议域标示包装数据包内数据的协议 ip协议就不说拉，重点讲下上面四种协议 LCP协议 代码域：标示”子协议“ 标识域：至关于报文ID。 长度域：长度域内容 = 总字节数据（代码域+标志域+长度域+数据域）。长度域所指示字节数以外的字节将被看成填充字节而忽略掉 LCP数据报文的分类 1.链路配置报文，主要用来创建和配置一条链路的。包括Config-Request 、Config-Ack 、Config-Nak 和Config-Reject 其中类型域包含 配置过程当中的一些协商问题 当接收Config-Request报文的一端能识别发送过来的全部配置参数选项且承认全部配置参数选项数据域的内容时，接收端将会给对端回一个Config-Ack报文并将配置请求报文中的配置参数选项原封不动的放置在 Config-Ack报文的数据域内（根据协议的规定是不可改变配置参数选项的顺序）。当配置请求报文的发送端收到Config-Ack报后，则会从当前阶段进入到下一个阶段。 当接收Config-Request报文的一端能识别发送端所发送过来的全部配置参数选项，但对部分配置参数选项数据域中的内容不承认时，接收端将会给对端回应一个Config-Nak报文，该报文中只携带不承认的配置参数选 项， 而这些配置参数选项的数据内容为本端但愿的值。然而当接收端收到Config-Nak 报文后， 会从新发送Config-Request 报文， 而这个Config-Request报文与上一次所发送的Config-Request报文区别在于那些被对端不承认的配置参数选项的内容被填写到刚刚协 商完后再次发送的Config-Request报文中（Config-Nak报文发送回来的那些配置参数选项）。 当接收Config-Request报文的一端不能识别全部的发送端发送过来的配置参数选项时，此时接收端将会向对端回一个Config-Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项（当配置参数选项的类 型域不识别时）。当对端接收到Config-Reject报文后，一样会再次发送一个Config-Request报文，这个配置请求报文与上一次发送的区别在于将不可识别的那些配置参数选项给删除了。 链路终止报文，主要用来终止一条链路的。包括Terminate-Request和Terminate-Reply 链路维护报文，主要用来维护和调试链路的。除上述两种报文类型之外，剩余的全部报文类型均归属链路维护报 维护报文的产生 当接收端发现LCP报文的代码域是一个不合法的值时，将会向发送端回应一个Code-Reject报文，在回应报文中会将所拒绝报文的内容附加上。 当 接收端发现所接收到的数据帧的协议域是一个不合法的值时，将会向发送端回应一个Protocol-Reject报文，发送端收到该拒绝报文后将中止发送该 种协议类型的数据报文了。Protocol-Reject报文只能在LCP的状态机处于Opened状态时才可被处理，而在其它状态接收到该报文将被丢 弃。在Protocol-Reject报文的数据域内将携带所拒绝报文的协议类型和报文内容。 Echo-Request报文和Echo- Reply报文主要用来检测双向链路上自环的问题，除此以外还可附带作一些链路质量的测试和其它功能。当LCP状态机处于Opened状态时，若是接收到 了Echo-Request，就需向对端回送一个Echo-Reply报文。不然在其它LCP状态下，该类型的报文会被丢弃。这种类型数据报文的长度域后 不是直接跟数据域，而是要插入4个字节的Magic-Number（魔术字），该魔术字是在LCP的Config-Request的配置参数选项协商时获 得的。 NCP协议 NCP协议主要包括IPCP、IPXCP等，但咱们在实际当中最常碰见的也只有IPCP协议了 注意：NCP不是一个具体的协议，而是好比IPCP,IPXCP等协议的一个统称。 IPCP IPCP控制协议主要是负责完成IP网络层协议通讯所需配置参数的选项协商的。IPCP在运行的过程中，主要是完成点对点通讯设备的两端动态的协商IP地址。 协议报文和lcp相似。包类型是lcp的一个子集，经常使用的如Config-Request、Config-Ack、Config-Nak和Config-Reject 静态协商，也便是不协商。点对点的通讯设备两端在PPP协商以前已配置好了IP地址，因此就无须在网络层协议阶段协商IP地址，而双方惟一要作的就是告诉对方自身的IP地址。 双方分别将本身的ip和其余可选的信息告诉对方 动态协商，也便是一端配置为动态获取IP地址，另外一端经过手动方式配置IP地址，且容许给对端分配IP地址，这个过程实际上可与窄带拨号上网的过程相一致 sender首先将ip域置于0，以向receiver动态一个ip地址。后面四个和静态协商一致。 认证协议 PPP协议也提供了可选的认证配置参数选项，缺省状况下点对点通讯的两端是不进行认证的。在LCP的Config-Request报文中不可一次携带多种认证配置选项，必须两者择其一（PAP/CHAP） 注意认证过程在lcp和ncp中间进行 PAP PAP认证是两次握手（单方向）。 用户名和密码使用明文，安全性较差 CHAP      开始由验证方向被验证方发送一段随机的报文，并加上本身的主机名。当被验证方收到验证方的验证请求，从中提取出验证方所发送过来的主机名，而后根据 该主机名在被验证方设备的后台数据库中去查找相同的用户名的记录，当查找到后就使用该用户名所对应的密钥，而后根据这个密钥、报文ID和验证方发送的随机 报文用Md5加密算法生成应答，随后将应答和本身的主机名送回，一样验证方收到被验证方发送回应后，提取被验证方的用户名，而后去查找本方一致用户名后， 根据该用户名所对应的密钥、保留报文ID和随机报文用Md5加密算法生成结果，和刚刚被验证方所返回的应答进行比较，相同则返回Ack，不然返回Nak