1外潜、背景知識(shí)：數(shù)據(jù)鏈路層協(xié)議完成什么功能

我們知道，數(shù)據(jù)鏈路層協(xié)議運(yùn)行在物理層之上贞间，網(wǎng)絡(luò)層之下。而底層的物理層雹仿，只能提供簡(jiǎn)單的bit流的物理信道增热，功能非常原始，如果直接使用物理層進(jìn)行通訊胧辽，肯定是非常不方便的峻仇，所以數(shù)據(jù)鏈路層會(huì)在底層物理層提供的功能基礎(chǔ)之上，提供一些增值服務(wù)邑商，方便上面的網(wǎng)絡(luò)層使用摄咆。所以可能認(rèn)為數(shù)據(jù)鏈路層是對(duì)物理層功能的增強(qiáng)。如果您想用盡量少的詞來(lái)記住數(shù)據(jù)鏈路層人断，那就是：“幀和介質(zhì)訪問(wèn)控制”吭从。典型的數(shù)據(jù)鏈路層功能包括：

1.1、報(bào)文成幀問(wèn)題

為了使傳輸中發(fā)生差錯(cuò)后只將有錯(cuò)的有限數(shù)據(jù)進(jìn)行重發(fā)恶迈，同時(shí)涩金，也為了上層使用起來(lái)更加方便，數(shù)據(jù)鏈路層將比特流組合成以幀為單位傳送暇仲。每個(gè)幀除了要傳送的數(shù)據(jù)外步做，還包括校驗(yàn)碼，以使接收方能發(fā)現(xiàn)傳輸中的差錯(cuò)奈附。幀的組織結(jié)構(gòu)必須設(shè)計(jì)成使接收方能夠 明確地從物理層收到的比特流中對(duì)其進(jìn)行識(shí)別全度，也即能從比特流中區(qū)分出幀的起始與終止，這就所謂的報(bào)文成幀問(wèn)題斥滤。

• 能在bit流中標(biāo)識(shí)出一個(gè)幀的起止位置
• 能對(duì)一幀報(bào)文的完整性做一定的校驗(yàn)

1.2将鸵、鏈路的建立管理與維護(hù)

當(dāng)鏈路兩端的節(jié)點(diǎn)要進(jìn)行通信前，必須

• 首先確認(rèn)對(duì)方已處于就緒狀態(tài)中跌，如果對(duì)端還沒(méi)有就緒咨堤，本端就開始發(fā)送通訊，所有信息必然會(huì)丟失漩符，這樣的通訊是沒(méi)有任何價(jià)值的一喘。并交換一些必要的信息以對(duì)幀序號(hào)初始化，然后才能建立連接。
• 在傳輸過(guò)程中則要能維持該連接凸克。如果出現(xiàn)差錯(cuò)议蟆，需要重新初始化，重新自動(dòng)建立連接萎战。
• 傳輸完畢后則要釋放連接咐容。數(shù)據(jù)連路層連接的建立維持和釋放就稱作鏈路管理。
• 在多個(gè)站點(diǎn)共享同一物理信道的情況下（例如在LAN中）如何在要求通信的站點(diǎn)間分配和管理信道也屬于數(shù)據(jù)鏈路層管理的范疇蚂维。
• 與物理信道通訊密切相關(guān)的戳粒，還有另外一個(gè)問(wèn)題，是通訊端的編址問(wèn)題虫啥。（比如以太網(wǎng)的MAC地址）

1.3蔚约、可靠性問(wèn)題

數(shù)據(jù)鏈路層的可靠性，包括兩個(gè)子問(wèn)題涂籽，第一個(gè)是差錯(cuò)控制苹祟，第二個(gè)是流量控制。

• 差錯(cuò)控制：在數(shù)據(jù)通信過(guò)程中可能會(huì)因物理鏈路性能和網(wǎng)絡(luò)通信環(huán)境等因素评雌，難免會(huì)出現(xiàn)一些傳送錯(cuò)誤树枫，但為了確保數(shù)據(jù)通信的準(zhǔn)確，又必須使得這些錯(cuò)誤發(fā)生的幾率盡可能低景东。這一功能也是在數(shù)據(jù)鏈路層實(shí)現(xiàn)的砂轻，就是它的”差錯(cuò)控制”功能。差錯(cuò)控制通常使用一些冗余編解碼技術(shù)耐薯，達(dá)到發(fā)現(xiàn)錯(cuò)誤舔清，甚至修正錯(cuò)誤的目的。
• 流量控制：在雙方的數(shù)據(jù)通信中曲初，如何控制數(shù)據(jù)通信的流量同樣非常重要体谒。它既可以確保數(shù)據(jù)通信的有序進(jìn)行，還可避免通信過(guò)程中不會(huì)出現(xiàn)因?yàn)榻邮辗絹?lái)不及接收而造成的數(shù)據(jù)丟失臼婆。這就是數(shù)據(jù)鏈路層的”流量控制”功能健蕊。數(shù)據(jù)的發(fā)送與接收必須遵循一定的傳送速率規(guī)則裹粤，可以使得接收方能及時(shí)地接收發(fā)送方發(fā)送的數(shù)據(jù)把鉴。并且當(dāng)接收方來(lái)不及接收時(shí)检盼，就必須及時(shí)控制發(fā)送方數(shù)據(jù)的發(fā)送速率，使兩方面的速率基本匹配颁独。

2彩届、PPP協(xié)議要解決哪些問(wèn)題

PPP協(xié)議是一個(gè)數(shù)據(jù)鏈路層協(xié)議，所以它會(huì)解決標(biāo)準(zhǔn)數(shù)據(jù)鏈路層協(xié)議的所有問(wèn)題誓酒，包括

1.成幀問(wèn)題 ：將物理層的bit流轉(zhuǎn)換為二層幀
2.鏈路維護(hù)：鏈路的建立樟蠕，維護(hù)與拆除
3.可靠性問(wèn)題：差錯(cuò)控制與流量控制

除此之外贮聂，PPP協(xié)議還提供了很多其他的附加功能，正是因?yàn)檫@些功能的提供寨辩，使得PPP協(xié)議稱為一個(gè)使用非常廣泛的鏈路層協(xié)議吓懈。

1. PPP具有身份驗(yàn)證功能
2. PPP具有錯(cuò)誤檢測(cè)以及糾錯(cuò)能力，支持?jǐn)?shù)據(jù)壓縮靡狞；
3. PPP支持多種網(wǎng)絡(luò)協(xié)議耻警，比如TCP/IP、NetBEUI甸怕、NWLINK等甘穿；
4. PPP具有動(dòng)態(tài)分配IP地址的能力；

3. PPP協(xié)議如何解決這些問(wèn)題

3.1梢杭、成幀問(wèn)題

PPP協(xié)議為串行鏈路上傳輸?shù)臄?shù)據(jù)報(bào)定義了一種封裝方法扒磁，它基于高層數(shù)據(jù)鏈路控制（HDLC）標(biāo)準(zhǔn)。

PPP協(xié)議的幀結(jié)構(gòu)

• 開始結(jié)束標(biāo)記：PPP幀以標(biāo)志字符01111110開始和結(jié)束

• 地址字段： 長(zhǎng)度為1字節(jié)式曲，內(nèi)容為標(biāo)準(zhǔn)廣播地址11111111（0xFF）。我們熟知網(wǎng)絡(luò)是分層的缸榛，且對(duì)等層之間進(jìn)行相互通信吝羞，而下層為上層提供服務(wù)。當(dāng)對(duì)等層進(jìn)行通信時(shí)首先需獲知對(duì)方的地址内颗，而對(duì)不同的網(wǎng)絡(luò)钧排，在數(shù)據(jù)鏈路層則表現(xiàn)為需要知道對(duì)方的MAC地址、X.121地址均澳、ATM地址等恨溜；在網(wǎng)絡(luò)層則表現(xiàn)為需要知道對(duì)方的IP地址、IPX地址等找前；而在傳輸層則需要知道對(duì)方的協(xié)議端口號(hào)糟袁。例如如果兩個(gè)以太網(wǎng)上的主機(jī)希望能夠通信的話，首先發(fā)送端需獲知對(duì)端的MAC地址躺盛。但由于PPP協(xié)議是被運(yùn)用在點(diǎn)對(duì)點(diǎn)的鏈路上的特殊性项戴，它不像廣播或多點(diǎn)訪問(wèn)的網(wǎng)絡(luò)一樣，因?yàn)辄c(diǎn)對(duì)點(diǎn)的鏈路就可以唯一標(biāo)示對(duì)方槽惫，因此使用PPP協(xié)議互連的通信設(shè)備的兩端無(wú)須知道對(duì)方的數(shù)據(jù)鏈路層地址周叮，所以該字節(jié)已無(wú)任何意義，按照協(xié)議的規(guī)定將該字節(jié)填充為全1的廣播地址界斜。

• 控制字段： 為00000011仿耽。同地址域一樣，PPP數(shù)據(jù)幀的控制域也沒(méi)有實(shí)際意義各薇，按照協(xié)議的規(guī)定通信雙方將該字節(jié)的內(nèi)容填充為0x03项贺。（既然無(wú)意義，就可以隨便賦值了吧，呵呵敬扛，只要大家都遵守一個(gè)標(biāo)準(zhǔn)就行）

• 協(xié)議字段： 長(zhǎng)度為2個(gè)字節(jié)晰洒，其值代表其后的數(shù)據(jù)字段所屬的網(wǎng)絡(luò)層協(xié)議，如：0x0021代表IP協(xié)議啥箭，0xC021代表LCP數(shù)據(jù)谍珊，0x8021代表NCP數(shù)據(jù)等。數(shù)據(jù)字段包含協(xié)議字段中指定的協(xié)議的數(shù)據(jù)報(bào)急侥，長(zhǎng)度為0～1500字節(jié)砌滞。CRC字段為整個(gè)幀的循環(huán)冗余校驗(yàn)碼，用來(lái)檢測(cè)傳輸中可能出現(xiàn)的數(shù)據(jù)錯(cuò)誤坏怪。

即使使用所有的幀頭字段贝润，PPP協(xié)議幀也只需要8個(gè)字節(jié)就可以形成封裝。如果在低速鏈路上或者帶寬需要付費(fèi)的情況下铝宵，PPP協(xié)議允許只使用最基本的字段打掘，將幀頭的開銷壓縮到2或4個(gè)字節(jié)的長(zhǎng)度，這就是所謂的PPP幀頭壓縮鹏秋。

3.2尊蚁、鏈路的建立、管理與維護(hù)

PPP協(xié)議有兩個(gè)重要部分組成：LCP和NCP侣夷，LCP就是其中用來(lái)進(jìn)行鏈路層的通道建立横朋、管理與維護(hù)的部分。

PPP協(xié)議的分層體系架構(gòu) - LCP在PPP中的位置

一次完整的PPP會(huì)話過(guò)程包括四個(gè)階段: 鏈路建立階段百拓、確定鏈路質(zhì)量階段琴锭、網(wǎng)絡(luò)層控制協(xié)議階段和鏈路終止階段。

PPP會(huì)話協(xié)商過(guò)程

• (1) 鏈路建立階段：PPP通信雙方用鏈路控制協(xié)議交換配置信息衙传，一旦配置信息交換成功决帖，鏈路即宣告建立。配置信息通常都使用默認(rèn)值粪牲，只有不依賴于網(wǎng)絡(luò)控制協(xié)議的配置選項(xiàng)才在此時(shí)由鏈路控制協(xié)議配置古瓤。值得注意的是，在鏈路建立的過(guò)程中腺阳，任何非鏈路控制協(xié)議的包都會(huì)被沒(méi)有任何通告地丟棄落君。

• (2) 鏈路質(zhì)量確定階段：這個(gè)階段在某些文獻(xiàn)中也稱為鏈路認(rèn)證階段。鏈路控制協(xié)議負(fù)責(zé)測(cè)試鏈路的質(zhì)量是否能承載網(wǎng)絡(luò)層的協(xié)議亭引。在這個(gè)階段中绎速，鏈路質(zhì)量測(cè)試是PPP協(xié)議提供的一個(gè)可選項(xiàng)，也可不執(zhí)行焙蚓。同時(shí)纹冤，如果用戶選擇了驗(yàn)證協(xié)議洒宝，驗(yàn)證的過(guò)程將在這個(gè)階段完成。PPP支持兩種驗(yàn)證協(xié)議：密碼驗(yàn)證協(xié)議（PAP）和握手鑒權(quán)協(xié)議(CHAP)萌京。

• (3) 網(wǎng)絡(luò)層控制協(xié)議階段：PPP會(huì)話雙方完成上述兩個(gè)階段的操作后雁歌，開始使用相應(yīng)的網(wǎng)絡(luò)層控制協(xié)議配置網(wǎng)絡(luò)層的協(xié)議，如：IP知残、IPX等靠瞎。

• (4) 鏈路終止階段：鏈路控制協(xié)議用交換鏈路終止包的方法終止鏈路。引起鏈路終止的原因很多：載波丟失求妹、認(rèn)證失敗乏盐、鏈路質(zhì)量失敗、空閑周期定時(shí)器期滿或管理員關(guān)閉鏈路等制恍。

3.2.1父能、鏈路層參數(shù)協(xié)商（LCP）

LCP會(huì)進(jìn)行一些鏈路層參數(shù)的協(xié)商，只有通過(guò)LCP協(xié)商之后净神，才會(huì)啟動(dòng)后續(xù)的認(rèn)證和網(wǎng)絡(luò)層參數(shù)協(xié)商過(guò)程

LCP報(bào)文格式

一次LCP協(xié)商過(guò)程如下：

一次LCP協(xié)商過(guò)程

• 1何吝、RTA進(jìn)入Link Establishment，物理層向數(shù)據(jù)鏈路層發(fā)送up事件
• 2鹃唯、RTA首先進(jìn)入LCP第一個(gè)狀態(tài)岔霸，即Request-Sent狀態(tài)，并向外發(fā)送Configure-Request報(bào)文
• 3俯渤、如果RTB同意協(xié)商的參數(shù)，回復(fù)一個(gè)Configure-Ack報(bào)文（主要協(xié)商MRU型宝、MagicNum）
• 4八匠、只要收到Configure-Ack報(bào)文后，進(jìn)入LCP第二狀態(tài)趴酣，即Opened狀態(tài)梨树，表示本RTA的Link Establishment階段協(xié)商結(jié)束，并向下一狀態(tài)躍遷岖寞。

至此抡四，LCP兩個(gè)狀態(tài)完成，可以向下一個(gè)階段Network Layer Protocol或者Autiontication躍遷

在Link Establishment階段仗谆，P2P雙方至少發(fā)一個(gè)Config-Request報(bào)文指巡，該報(bào)文中包含了發(fā)送方對(duì)于所有的配置參數(shù)的期望值。

• 1隶垮、如果對(duì)方對(duì)于自己發(fā)送的Config-Request回應(yīng)了一個(gè)Config-Ack藻雪，則說(shuō)明對(duì)方已經(jīng)認(rèn)可了自己提出的所有配置參數(shù)的期望值；
• 2狸吞、如果對(duì)方對(duì)于自己發(fā)送的Config-Request回應(yīng)了一個(gè)Config-Nak勉耀，則說(shuō)明對(duì)方否定了自己提出的所有配置參數(shù)或者部分配置參數(shù)的期望值指煎，這也就意味著自己必須修改相應(yīng)配置參數(shù)的期望值，然后向?qū)Ψ街匦掳l(fā)送一個(gè)Config-Request報(bào)文便斥，且等待對(duì)方新的回應(yīng)至壤；
• 3、如果雙方最終收到對(duì)方發(fā)送的Config-Ack報(bào)文枢纠，則說(shuō)明對(duì)方對(duì)于自己提出的配置參數(shù)的協(xié)商已經(jīng)取得了一致像街，這同時(shí)也標(biāo)志著Link Establishment階段順利結(jié)束。

3.2.2京郑、PPP的安全認(rèn)證（PAP宅广、CHAP）

PPP相對(duì)其他協(xié)議的一個(gè)非常重要的功能特性是其內(nèi)置了安全認(rèn)證機(jī)制，這也是該協(xié)議在用戶接入側(cè)被廣泛使用的一個(gè)重要原因些举。安全認(rèn)證過(guò)程內(nèi)置在協(xié)議規(guī)程中跟狱，并且在鏈路建立起來(lái)之前被執(zhí)行。很好的保證了接入鏈路的安全性户魏。

驗(yàn)證過(guò)程在PPP協(xié)議中為可選項(xiàng)驶臊。在連接建立后進(jìn)行連接者身份驗(yàn)證的目的是為了防止有人在未經(jīng)授權(quán)的情況下成功連接，從而導(dǎo)致泄密叼丑。PPP協(xié)議支持兩種驗(yàn)證協(xié)議：

(1) 口令驗(yàn)證協(xié)議(PAP): 口令驗(yàn)證協(xié)議的原理是由發(fā)起連接的一端反復(fù)向認(rèn)證端發(fā)送用戶名/口令對(duì)关翎，直到認(rèn)證端響應(yīng)以驗(yàn)證確認(rèn)信息或者拒絕信息。

簡(jiǎn)單口令認(rèn)證協(xié)議PAP

(2) 握手鑒權(quán)協(xié)議（CHAP）：CHAP用三次握手的方法周期性地檢驗(yàn)對(duì)端的節(jié)點(diǎn)鸠信。其原理是：認(rèn)證端向?qū)Χ税l(fā)送“挑戰(zhàn)”信息纵寝，對(duì)端接到“挑戰(zhàn)”信息后用指定的算法計(jì)算出應(yīng)答信息然后發(fā)送給認(rèn)證端，認(rèn)證端比較應(yīng)答信息是否正確從而判斷驗(yàn)證的過(guò)程是否成功星立。如果使用CHAP協(xié)議爽茴，認(rèn)證端在連接的過(guò)程中每隔一段時(shí)間就會(huì)發(fā)出一個(gè)新的“挑戰(zhàn)”信息，以確認(rèn)對(duì)端連接是否經(jīng)過(guò)授權(quán)绰垂。

CHAP握手鑒權(quán)協(xié)議

這兩種驗(yàn)證機(jī)制共同的特點(diǎn)就是簡(jiǎn)單室奏，比較適合于在低速率鏈路中應(yīng)用。但簡(jiǎn)單的協(xié)議通常都有其他方面的不足劲装，最突出的便是安全性較差胧沫。一方面，口令驗(yàn)證協(xié)議的用戶名/口令以明文傳送占业，很容易被竊热拊埂；另一方面谦疾，如果一次驗(yàn)證沒(méi)有通過(guò)窖逗，PAP并不能阻止對(duì)端不斷地發(fā)送驗(yàn)證信息，因此容易遭到強(qiáng)制攻擊餐蔬。

挑戰(zhàn)握手協(xié)議的優(yōu)點(diǎn)在于密鑰不在網(wǎng)絡(luò)中傳送碎紊，不會(huì)被竊聽(tīng)佑附。由于使用三次握手的方法，發(fā)起連接的一方如果沒(méi)有收到“挑戰(zhàn)信息”就不能進(jìn)行驗(yàn)證仗考，因此在某種程度上挑戰(zhàn)握手協(xié)議不容易被強(qiáng)制攻擊音同。但是，CHAP中的密鑰必須以明文形式存在秃嗜，不允許被加密权均，安全性無(wú)法得到保障。密鑰的保管和分發(fā)也是CHAP的一個(gè)難點(diǎn)锅锨，在大型網(wǎng)絡(luò)中通常需要專門的服務(wù)器來(lái)管理密鑰叽赊。

3.2.3、PPP網(wǎng)絡(luò)層協(xié)商（NCP）

在完成安全認(rèn)證后必搞，PPP還支持上層網(wǎng)絡(luò)層協(xié)議一些參數(shù)的協(xié)商必指，這也是PPP非常有特點(diǎn)的一個(gè)設(shè)計(jì)。不同的上層網(wǎng)絡(luò)層協(xié)議恕洲，可能會(huì)有不同的協(xié)商內(nèi)容塔橡。PPP協(xié)議為上層網(wǎng)絡(luò)層參數(shù)協(xié)商定義了一套標(biāo)準(zhǔn)的規(guī)程，同時(shí)又支持多種不同的上層協(xié)議進(jìn)行協(xié)商霜第。設(shè)計(jì)的可擴(kuò)展性非常好葛家。

NCP協(xié)議主要包括IPCP、IPXCP等泌类，但我們?cè)趯?shí)際當(dāng)中最常遇見(jiàn)的也只有IPCP協(xié)議

3.2.3.1癞谒、IPCP控制協(xié)議

IPCP控制協(xié)議主要是負(fù)責(zé)完成IP網(wǎng)絡(luò)層協(xié)議通信所需配置參數(shù)的選項(xiàng)協(xié)商，負(fù)責(zé)建立刃榨，使能和中止IP模塊扯俱。IPCP在運(yùn)行的過(guò)程當(dāng)中，主要是完成點(diǎn)對(duì)點(diǎn)通信設(shè)備的兩端動(dòng)態(tài)的協(xié)商IP地址喇澡。IPCP包在PPP沒(méi)有達(dá)到網(wǎng)絡(luò)層協(xié)議階段以前不能進(jìn)行交換，如果有IPCP包在到達(dá)此階段前到達(dá)會(huì)被拋棄殊校。

IPCP到底需要協(xié)商一些什么參數(shù)呢晴玖？最重要的是下面兩項(xiàng)：

• 一是關(guān)于IP報(bào)文的壓縮方式，也就是協(xié)商雙方在傳遞IP報(bào)文的時(shí)候为流，IP報(bào)文是采用標(biāo)準(zhǔn)的呕屎、非壓縮形式的報(bào)文格式呢，還是采用壓縮形式的報(bào)文格式敬察；
• 二是關(guān)于接口的IP地址秀睛，因?yàn)?strong>PPP沒(méi)有ARP協(xié)議，本地怎么知道對(duì)端接口IP地址是不是合法的莲祸，怎么知道對(duì)端是不是和本地的接口IP地址沖突呢蹂安？所以希望協(xié)商雙方的接口IP地址合法性椭迎，代替了ARP協(xié)議功能。

IPCP控制協(xié)議協(xié)商有兩種方式：靜態(tài)和動(dòng)態(tài)：

靜態(tài)協(xié)商田盈，也即不協(xié)商畜号。點(diǎn)對(duì)點(diǎn)的通信設(shè)備兩端在PPP協(xié)商之前已配置好自身IP地址，所以不用在Network階段協(xié)商IP地址允瞧，而雙方唯一要做的就是告訴對(duì)方自身的IP地址简软，并且對(duì)方是否承認(rèn)我的IP地址合法。在IPCP控制協(xié)議完成整個(gè)配置的過(guò)程時(shí)述暂，最理想的情況將會(huì)看到如圖所示的四種報(bào)文痹升，而無(wú)其它報(bào)文再被發(fā)送。

靜態(tài)協(xié)商過(guò)程

在靜態(tài)協(xié)商時(shí)畦韭，發(fā)送方和接收方都同時(shí)發(fā)送Config-Request報(bào)文疼蛾，其中option中只含有該接口IP地址，當(dāng)對(duì)端收到該報(bào)文后廊驼，會(huì)發(fā)送一個(gè)Config-Ack報(bào)文据过，且Config-Ack中帶著對(duì)方的IP地址，這個(gè)目的是告訴對(duì)端："單播IP地址妒挎，且和我沒(méi)有沖突绳锅，請(qǐng)放心使用"，其實(shí)和ARP功能一樣酝掩。 剛進(jìn)入網(wǎng)絡(luò)層協(xié)議階段時(shí)鳞芙， IPCP的狀態(tài)機(jī)是initial的，但當(dāng)完成了上述的整個(gè)過(guò)程后期虾， IPCP的狀態(tài)機(jī)改變?yōu)镺pened原朝，雙方也就可以開始網(wǎng)絡(luò)層數(shù)據(jù)網(wǎng)的傳送了

動(dòng)態(tài)協(xié)商 也即是一端配置為動(dòng)態(tài)獲取IP地址；另一端通過(guò)手動(dòng)方式配置IP地址镶苞，且允許給對(duì)端分配IP地址喳坠，類似DHCP分配地址給對(duì)方

動(dòng)態(tài)協(xié)商IP地址過(guò)程

1、Client沒(méi)有配置IP地址茂蚓，所以在IPCP的Config-Request報(bào)文的IP地址配置參數(shù)配置選項(xiàng)中的IP地址填充全0（也即是0.0.0.0）壕鹉；
2、當(dāng)Server收到這個(gè)Config-Request報(bào)文時(shí)聋涨，收到Client配置請(qǐng)求報(bào)文后會(huì)檢測(cè)IP地址的內(nèi)容晾浴，如果發(fā)現(xiàn)為全0，則認(rèn)為對(duì)端的這個(gè)IP地址是我要分配給對(duì)方IP地址牍白，并將希望分配給對(duì)方的IP地址填充到Config-Nak報(bào)文內(nèi)脊凰，這樣就回應(yīng)一個(gè)Config-Nak報(bào)文。
3茂腥、Client收到Config-Nak報(bào)文后狸涌，就會(huì)有自己的IP地址切省，重新發(fā)送一個(gè)Config-Request報(bào)文，這個(gè)報(bào)文中的IP地址配置選項(xiàng)為Server在Config-Nak報(bào)文中所提供的杈抢。靜態(tài)分配的IP地址数尿，對(duì)client路由器而言，會(huì)在該接口上產(chǎn)生一條到對(duì)端接口的32位主機(jī)路由
4惶楼、Server收到后右蹦，只需發(fā)送一個(gè)Config-Ack報(bào)文，告訴Client歼捐，就表示接收方的IP地址配置完成何陆。

3.3、PPP其他特性1 - 鏈路質(zhì)量監(jiān)控

PPP內(nèi)置了的鏈路質(zhì)量檢測(cè)機(jī)制豹储， PPP 通過(guò)定義鏈路質(zhì)量報(bào)告包 （Link-Quality-Report Packet）和它的詳細(xì)處理過(guò)程贷盲，為鏈路質(zhì)量監(jiān)控詳細(xì)說(shuō)明了監(jiān)控機(jī)制。 PPP 沒(méi)有具體說(shuō)明鏈路質(zhì)量監(jiān)控策略――如何斷定鏈路質(zhì)量或者當(dāng)鏈路不充分時(shí)該怎么 做剥扣。這個(gè)被留做一個(gè)實(shí)現(xiàn)決策巩剖，并且在鏈路的各端可能是有差別的。用各種各樣的方法去實(shí) 現(xiàn)這一決策是被允許甚至鼓勵(lì)的钠怯。鏈路質(zhì)量監(jiān)控機(jī)制說(shuō)明書保證了使用不同策略的兩個(gè)實(shí)現(xiàn) 可以實(shí)現(xiàn)通信和進(jìn)行內(nèi)部操作佳魔。

3.4、PPP其他特性2 - 環(huán)路檢測(cè)

Magic-Number： 魔數(shù)字段用于輔助檢測(cè)鏈路自環(huán)晦炊。這是在鏈路建立過(guò)程中比較重要的一個(gè)參數(shù)鞠鲜，這個(gè)參數(shù)是在Config-Request里面被協(xié)商的，主要的作用是防止環(huán)路断国，如果在雙方不協(xié)商魔術(shù)字的情況下贤姆，某些LCP的數(shù)據(jù)報(bào)文需要使用魔術(shù)字時(shí)，那么只能是將魔術(shù)字的內(nèi)容填充為全0稳衬；反之霞捡，則填充為配置參數(shù)選項(xiàng)協(xié)商后的結(jié)果

魔術(shù)字在目前所有的設(shè)備當(dāng)中都是需要進(jìn)行協(xié)商的，它被放在Config-Request的配置選項(xiàng)參數(shù)中進(jìn)行發(fā)送薄疚，而且需要由自身的通信設(shè)備獨(dú)立產(chǎn)生碧信，協(xié)議為了避免雙方可能產(chǎn)生同樣的魔術(shù)字，從而導(dǎo)致通信出現(xiàn)不必要的麻煩输涕，因此要求由設(shè)備采用一些隨機(jī)方法產(chǎn)生一個(gè)獨(dú)一無(wú)二的魔術(shù)字。一般來(lái)說(shuō)魔術(shù)字的選擇會(huì)采用設(shè)備的系列號(hào)慨畸、網(wǎng)絡(luò)硬件地址或時(shí)鐘莱坎。雙方產(chǎn)生相同魔術(shù)字的可能性不能說(shuō)是沒(méi)有的，但應(yīng)盡量避免寸士，通常這種情況是發(fā)產(chǎn)在相同廠商的設(shè)備進(jìn)行互連時(shí)檐什，因?yàn)橐粋€(gè)廠商所生產(chǎn)的設(shè)備產(chǎn)生魔術(shù)字的方法是一樣的碴卧。

我們知道魔術(shù)字產(chǎn)生的作用是用來(lái)幫助檢測(cè)鏈路是否存在環(huán)路，當(dāng)接收端B收到一個(gè)Config-Request報(bào)文時(shí)乃正，會(huì)將此報(bào)文與上一次所接收到（應(yīng)該是上一次發(fā)送出）的Config-Request進(jìn)行比較住册，如果兩個(gè)報(bào)文中所含的魔術(shù)字不一致的話，表明鏈路不存在環(huán)路瓮具。但如果一致的話荧飞，接收端B認(rèn)為鏈路可能存在環(huán)路，但不一定存在環(huán)路名党，還需進(jìn)一步確認(rèn)叹阔。此時(shí)接收端B將發(fā)送一個(gè)Config-Nak報(bào)文，并在該報(bào)文中攜帶一個(gè)重新產(chǎn)生的魔術(shù)字传睹，而且此時(shí)在未接收到任何Config-Request或Config-Nak報(bào)文之前耳幢，接收端B也不會(huì)發(fā)送任何的Config-Request報(bào)文。這時(shí)我們假設(shè)可能會(huì)有以下兩種情況發(fā)生：

1.鏈路實(shí)際不存在環(huán)路欧啤，而是由于對(duì)方A在產(chǎn)生魔術(shù)字時(shí)與接收端B產(chǎn)生的一致睛藻，但實(shí)際這種情況出現(xiàn)的概率是很小的。當(dāng)Config-Nak被對(duì)端A接收到后邢隧，A應(yīng)該發(fā)送一個(gè)Config-Request報(bào)文（此報(bào)文中的魔術(shù)字為接收到的Nak報(bào)文中的）店印，當(dāng)B接收到后，與上次的Config-Request比較府框，由于接收端B已經(jīng)在上一次的Nak報(bào)文中產(chǎn)生了一個(gè)不同的魔術(shù)字吱窝，此時(shí)接收端B收到的Config-Request報(bào)文中的魔術(shù)字與上次B發(fā)出的Config-Request配置請(qǐng)求報(bào)文中不一樣，所以接收端B可斷定鏈路不存在環(huán)路迫靖。
2.鏈路實(shí)際上確實(shí)存在環(huán)路院峡，一段時(shí)間后Config-Nak報(bào)文會(huì)返回到發(fā)送該報(bào)文的同一端B。這時(shí)接收端B比較這個(gè)Config-Nak報(bào)文與上一次發(fā)出去的Config-Nak報(bào)文一樣系宜，因此鏈路存在環(huán)路的可能性又增大了照激。我們知道當(dāng)一端收到了一個(gè)Config-Nak報(bào)文時(shí)，又會(huì)發(fā)送一個(gè)Config-Request報(bào)文（該報(bào)文中的魔術(shù)字與Config-Nak中的一致）盹牧，這樣又回到了最初的狀態(tài)俩垃，在這條鏈路上就會(huì)不斷的出現(xiàn)Config-Request、Config-Nak報(bào)文汰寓，因此這樣周而復(fù)始下去口柳，接收端就會(huì)認(rèn)為PPP鏈路存在環(huán)路的可能性在不斷增加，當(dāng)達(dá)到一定數(shù)量級(jí)時(shí)有滑，就可認(rèn)為此鏈路存在環(huán)路跃闹。（注意，不是第一次受到相同的魔術(shù)字就判斷有環(huán)路的）

但在實(shí)際應(yīng)用中根據(jù)不同設(shè)備實(shí)現(xiàn)PPP協(xié)議的方法，我們?cè)阪溌翻h(huán)路檢測(cè)時(shí)可采用兩種方法望艺。第一種機(jī)制就是如上面所述的苛秕，這個(gè)過(guò)程不斷地重復(fù)，最終可能會(huì)給LCP狀態(tài)機(jī)發(fā)一個(gè)Down事件找默，這時(shí)可能會(huì)使LCP的狀態(tài)機(jī)又回到初始化階段艇劫，又開始新一輪的協(xié)商。當(dāng)然對(duì)于某些設(shè)備還會(huì)采用第二種機(jī)制惩激，就是不產(chǎn)生任何事件去影響當(dāng)前LCP的狀態(tài)機(jī)店煞，而是停留在請(qǐng)求發(fā)送狀態(tài)。但這時(shí)認(rèn)為鏈路有環(huán)路的一端設(shè)備需要不斷的向鏈路上發(fā)送Echo-Request報(bào)文來(lái)檢測(cè)鏈路環(huán)路是否被解除咧欣，當(dāng)接收端收到Echo-Reply報(bào)文時(shí)浅缸，就認(rèn)為鏈路環(huán)路被解除，從而就可能進(jìn)行后續(xù)的PPP的過(guò)程魄咕。

3.5衩椒、PPP其他特性3 - 報(bào)文壓縮

PPP在LCP和NCP協(xié)商期間，都可以對(duì)各自的報(bào)文或報(bào)文頭協(xié)商是否需要啟用壓縮機(jī)制哮兰。比如PPP頭的壓縮毛萌，或者IP報(bào)文的壓縮等。

3.6喝滞、PPP的可靠性

PPP是一個(gè)不可靠的二層協(xié)議阁将，PPP并不提供關(guān)于流量控制，差錯(cuò)控制等可靠性機(jī)制右遭，他把這些問(wèn)題留給上層協(xié)議去解決做盅。

其實(shí)這是很明智的做法，OSI七層模型中窘哈，各個(gè)層次都有相應(yīng)的差錯(cuò)控制協(xié)議吹榴，比如二層鏈路層的等停協(xié)議或滑動(dòng)窗口協(xié)議，到了傳輸層（如TCP）滚婉，又有自己的可靠性協(xié)議图筹。這樣反反復(fù)復(fù)的各個(gè)層面都在做同樣的事情，浪費(fèi)了資源让腹，并且?guī)?lái)了額外的復(fù)雜度远剩。

PPP將可靠性問(wèn)題留給上層去解決，自己則將更多的精力集中在上層沒(méi)有解決的問(wèn)題域上骇窍。最終取得了更好的效果瓜晤。（PPP協(xié)議的廣泛使用就是一個(gè)這種效果的一個(gè)很好的證明）

參考文獻(xiàn)：

https://wenku.baidu.com/view/7f7391fef9c75fbfc77da26925c52cc58bd690d1.html

PPP協(xié)議詳解及舉例
https://wenku.baidu.com/view/118ad274580216fc700afd5f.html

PPP基本原理（HW）
http://forum.huawei.com/enterprise/thread-364813.html