络硬件地址或时钟。双方产生相同魔术字的可能性不能说是没有的，但应尽量避免，通常这种情况是发产在相同厂商的设备进行互连时，因为一个厂商所生产的设备产生魔术字的 方法是一样的。
我们知道魔术字产生的作用是用来帮助检测链路是否存在环路，当接收端收到一个Config-Request 报文时， 会将此报文与上一次所接收到的Config-Request进行比较，如果两个报文中所含的魔术字不一致的话，表明链路不存在环路。但如果一致的话，接收端认为链路可能存在环路，但不一定存在环路，还需进一步确认。此时接收端将发送一个Config-Nak报文，并在该报文中携带一个重新产生的魔术字， 而且此时在未接收到任何
Config-Request 或Config-Nak 报文之前， 接收端也不会发送任何的Config-Request报文。这时我们假设可能会有以下两种情况发生： ", 链路实际不存在环路，而是由于对方在产生魔术字时与接收端产生的一致，但实际这种情况出现的概率是很小的。当Config-Nak被对端接收到后，应该发送一个Config-Request报文（此报文中的魔术字为Nak报文中的），当对端接收到后，与上次比较，由于接收端已经在Nak报文中产生了一个不同的魔术字，此时接收端收到的Config-Request报文中的魔术字与上次配置请求报文中不一样，所以接收端可断定链路不存在环路。 ", 链路实际上确实存在环路，一段时间后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的过程。 4.1.2 认证协议
PPP协议也提供了可选的认证配置参数选项，缺省情况下点对点通信的两端是不进行认证的。在LCP的Config-Request报文中不可一次携带多种认证配置选项，必须二者择其一（PAP/CHAP），选择最希望的那一种，一般是在PPP设备互连的设备上进行配置的，但一般设备会默认支持一个缺省的认证方式（PAP是大部分设备所默认的认证方式）。当对端收到该配置请求报文后，如果支持配置参数选项中的认证方式，则回应一个Config-Ack报文；否 则回应一个Config-Nak报文，并附带上自希望双方采用的认证方式。当对方接收到Config-Ack 报文后就可以开始进行认证了， 而如果收到得是Config-Nak报文，则根据自身是否支持Config-Nak报文中的认证方式来回应对方，如果支持则回应一个新的Config-Request（并携带上Config-Nak报文中所希望使用的认证协议），否则将回应一个Config-Reject报文，那么双方就无法通过认证，从而不可能建立起PPP链路。
PPP支持两种授权协议：PAP（Password Authentication Protocol）和CHAP（Challenge Hand Authentication Protocol）。
4.1.2.1 PAP认证
我们所知两个设备在使用PAP进行认证之前，应该确认那一方是验证方，那一方是被验证方。实际上对于使用PPP协议互连的两端来说，既可作为认证方，也可作为被认证方。但通常情况下，PAP只使用一个方向上的认证。一般在两端设备使用PAP协议之前，均会设备上进行一些相应的配置，对于宽带工程师而言MA5200可谓是大家最熟悉的产品了，它默认就作为验证方，但可通过使用命令PAP Authentication PAP/CHAP来更改认证方式，而对于被验证方而言只需设置用户名和密码即可。
PAP认证是两次握手，在链路建立阶段，依据设备上的配置情况，如果是使用PAP认证，则验证方在发送Config-Request报文时会携带认证配置参数选项，而对于被验证方而言则是不需要，它只需要收到该配置请求报文后根据自身的情况给对端返回相应的报文。如果点对点的两端设备采用的是PAP双向认证时，也即是它同时也作为验证方，则此时需要在配置请求报文中携带认证配置参数选项。因此，我们可以总结一下，如果对于点对点的两个设备在 PPP 链路建立的过程中使用的认证方式为PAP的话，那么验证方在其Config-Request报文中必须含有认证配置参数选项，且该认证配置参数选项的数据域为0xC023，下图为PAP认证的过程：
当通信设备的两端在收到对方返回的Config-Ack报文时，就从各自的链路建立阶段进入到认证阶段，那么作为被验证方此时需要向验证方发送PAP认证的请求报文，该请求报文携带了用户名和密码，当验证方收到该认证请求报文后，则会根据报文中的实际内容查找本地的数据库，如果该数据库中有与用户名和密码一致的选项时，则回向对方返回一个认证请求响应，告诉对方认证已通过。反之，如果用户名与密码不符，则向对方返回验证不通过的响应报文。如果双方都配置为验证方，则需要双方的两个单向验证过程都完成后，方可进入到网络层协议阶段，否则在一定次的认证失败后，则会从当前状态返回链路不可用状态。
例10： 如图4-1所示，当路由器A（被验证方）收到了路由器B 的Config-Ack报文后，因为是使用PAP认证，所以作为被验证方的路由器A应主动向验证方（路由器B）发送认证请 求报文（PAP Authenticate），用户名和密码均为163，报文的内容如下： 7E FF 03 C0 23 01 01 00 0C 03 31 36 33 03 31 36 33 7E 下划线的前四个字节是用户名，后四个字节是密码。
当路由器B收到了该报文后，会向路由器A回应一个PAP Authenticate Ack报文，报文内容 如下：
7E FF 03 80 21 02 01 00 05 00 7E 此时所回应的报文中，并未携带任何数据，如果是认证不通过，则会在返回的报文中指是 因何原因无法认证通过，可能是无此用户名或密码不匹配。
4.1.2.2 CHAP认证
与PAP认证比起来，CHAP认证更具有安全性，从前面认证过程的数据包交换过程中不然发现，采用PAP认证时，被验证是采用明文的方式直接将用户
名和密码发送给验证方的，而对于PAP认证则不一样。CHAP为三次握手协议，它只在网络上传送用户名而不传送口令，因此安全性比PAP高。在验证一开始，不像PAP一样是由被验证方发送认证请求报文了，而是由验证方向被验证方发送一段随机的报文，并加上自己的主机名，我们通称这个过程叫做挑战。当被验证方收到验证方的验证请求，从中提取出验证方所发送过来的主机名，然后根据该主机名在被验证方设备的后台数据库中去查找相同的用户名的记录，当查找到后就使用该用户名所对应的密钥，然后根据这个密钥、报文ID和验证方发送的随机报文用Md5加密算法生成应答，随后将应答和自己的主机名送回，同样验证方收到被验证方发送回应后，提取被验证方的用户名，然后去查找本地的数据库，当找到与被验证方一致用户名后，根据该用户名所对应的密钥、保留报文ID和随机报文用Md5加密算法生成结果，和刚刚被验证方所返回的应答进行比较，相同则返回Ack，否则返回Nak，下图为CHAP的认证过程：
例11： 如图4-2所示，当路由器A（被验证方）收到了路由器B 的Challenge报文后，报文 内容如下：
7E FF 03 C2 23 01 01 00 1C 10 FF 41 CF 22 AA 8E F1 B9 99 9A 79 A7 56 78 C4 A7 4d 41 35 32 30 30 41 7E 下划线的前16个字节是验证方随机产生的一段报文，后7个字节是验证方的主机名 （MA5200A），而且单个字节10表示随机报文的长度。
而此时路由器A会根据用户名所对应的密钥使用报文的ID和该报文的内容生成一个回应报 文，报文内容如下：
7E FF 03 C2 23 02 01 00 1F 10 18 86 22 FF CE 81 D0 68 FF 80 85 00 A7 E3 85 35 70 70 6B 69 73 73 40 68 75 61 7E 我们将这个回应报文与验证方发送的挑战报文进行比较，报文的代码域已由原01改为02 ， 总报文的长度有变化， 主要后而一个下划线的内容是被验证方的主机名（ppkiss@hua），而且此时回应的16个字节的报文已经是经过MD5算法加密过的。当验证方收到了这个回应报文后，会根据报文中被验证方的主机名（ppkiss@hua）在本地的数据库中去查找密钥，然后再对原发先发送的那段挑战报文进行MD5的算法加密，如果所得的结果与对方刚发过来的16个字节的加密值一样的话，则就会发送一个报文通知被验证方，你的认证已经通过，我们可以进入到下一个阶段了。在实际应用当中，我们很多都是使用PC机来进行拨号这个过程，
实际中当验证方发送挑战后，PC机只接收而并不去查本地数据库，而直接使用在拨号对话框中所输入的密码和报文的ID及报报文的内容进行MD5算法加密（这个在PC机采用PPPOE软件拨入到MA5200时就是这样的）。
下面来看一下验证通过时，验证方给被验证方所发送的一段报文内容：
7E FF 03 C2 23 03 01 00 17 57 65 6C 63 6F 6D 65 20 74 6F20 4D 41 35 32 30 30 41 2E 7E 此时所回应的报文的代码域为03，且报文的实际内容是，Welcom to MA5200A。 4.1.3 MRU（Maxium Receive Unit）
这个配置参数选项主要是Config-Request报文的发送端告诉接收端，本端接收到的PPP数据帧的数据域的最大值。通常情况下这个参数选项使用默认值（1500字节），因此在Config-Request报文中双方都不会携带这个配置参数选项。当在某些特殊应用中，可能会使用到小于1500字节或大于1500字节的情况，这时在Config-Request报文就会携带要协商的MRU配置参数选项值。 4.2 总结 ", 魔术字可以在链路配置阶段被协商，数据报文可借助魔术字来检PPP链 路是否存在环路 ", PAP（密码认证协议）认证是二次握手，它是直接在网络上传送明文的 用户名和密码，因此这种协议安全性不高 ", CHAP（挑战性握手认证协议）认证是三次握手，它只在网络上传送验 证方和被验证方的主机名，而并不传送密码，因此相比之处CHAP比 PAP更安全 ", PPP协议缺省的MRU是1500，而对于通信的双方可根据实际需要对MRU进行协商 第五章 PPP扩展协议 5.1 PPP扩展协议概述 5.1.1 MP出现的背景
我们知道ISDN可以在两个系统之间提供2B+D和30B+D多通道捆绑能务，从而为用户能够提供更多可用的带宽。诸如上述的许多链路捆绑功能需要软件和硬件的协同工作，而且更多的基于硬件来实现的。然而我们是否考虑过仅仅通过软件的实现来完成链路捆绑的功能，同时还考虑到很多实际链路的情况，对于软件在实现过程中还要能对不同速率的链路进行捆绑。我们可以通过在发送数据之前增加一定数据的字节头，其中含有为重组数据而所需的一 些字段。随着PPP的广泛应用，MP作为PPP功能扩展协议应运而生。它可为用户提供更大的带宽，实现数据的快速转发。同时，还可实现对链路资源进行动态分配，有效的利用宝贵的资源。但随着网络技术的发展，网络的带宽已不再是瓶颈，所以对于使用PPP扩展协议已没有实际意义，只在本章中简单做一下介绍，如果想进一步了解该协议，可参考相应的RFC1717或提供的参考书目。
5.1.2 MP（Multilink Protocol）协议
MP的协商较为特殊。MP配置参数选项的协商是在LCP协商过程中完成的， 协商MP配置参数选项的目的完成以下几个过程： ", 表明系统是否支持将多个物理链路捆绑成一个逻辑链路 ", 系统在多链路上接收到了对端发送的数据单元后，能够通过附加在这些数据之前的重组字段对这些分段的数据单元进行重组 ", 逻辑链路为了能够提高传输的效率，可以不使用单一PPP物理链路上的最大接收单元，可以重新协商新的逻辑链路上使用的最大接收单元进行数据报文的发送和接收。
MP协议可以用来灵活的调整点对点系统之间的多条独立物理链路，它可为整个系统提供一个虚拟链路，虚拟链路的带宽是N个链路的捆绑之和（N≥1）。而对于被捆绑的链路并未做出特殊要求，可以将同步链路和异步链路进行捆绑，同样也可将低速链路和高速链路进行捆绑。使用该协商可将多个PPP的链路捆绑成一条使用，而决定不同通道是否需进行多链路捆绑有两个条件： 只有两个链路的Discriminator和验证方式、用户完全相符时，才能对
两个链路进行捆绑。这就意味着只有当验证完成后，才能真正完成MP的协商过程。MP不会导致链路的拆除。如果配置了MP，两个链路不符合MP条件，则会建立一条新的MP通道，这同时也表明允许MP为单链路。MP的捆绑是完全依照用户进行的，只有相同用户才能进行捆绑。如一端配置了MP，另一端不支持或未配MP，则建立起来的链路为非MP链路。 5.2 总结 ", MP协议属于PPP协议的扩展协议 ", MP协议可依据终端指示符和验证方式对不同的物理链路进行捆绑
(2) GPRS数据传输设计 UDP协议 1 UDP协议的简介
UDP协议 是User Datagram Protocol的简称， 中文名是用户数据包协议，是 OSI 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。在网络中它与TCP协议一样用于处理 UDP数据包。在OSI模型中，在第四层——传输层，处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。UDP用来支持那些需要在计算机之间传输数据的网络应用。包括网络视频会议系统在内的众多的客户/服务器模式的网络应用都需要使用UDP协议。UDP协议从问世至今已经被使用了很多年，虽然其最初的光彩已经被一些类似协议所掩盖，但是即使是在今天，UDP仍然不失为一项非常实用和可行的网络传输层协议。
与所熟知的TCP（传输控制协议）协议一样，UDP协议直接位于IP（网际协议）协议的顶层。根据OSI（开放系统互连）参考模型，UDP和TCP都属于传输层协议。UDP协议的主要作用是将网络数据流量压缩成数据包的形式。一个典型的数据包就是一个二进制数据的传输单位。每一个数据包的前8个字节用来包含报头信息，剩余字节则用来包含具体的传输数据。 2.传输层协议UDP 2.1UDP协议报头
UDP报头由4个域组成，其中每个域各占用2个字节，具体如下：