對(duì)于PPP協(xié)議的基礎(chǔ)內(nèi)容，PPP數(shù)據(jù)幀以及PPP模式我們都做了介紹。那么這里我們?cè)賮碇v解一下PPP協(xié)議的LCP數(shù)據(jù)報(bào)文的內(nèi)容。通過前面的文章，我們知道，LCP數(shù)據(jù)報(bào)文是在鏈路建立階段被交換的，它作為PPP的凈載荷被封裝在PPP數(shù)據(jù)幀的信息域中。在鏈路建立階段的整個(gè)過程中信息域的內(nèi)容是在變化的，它包括很多種類型的報(bào)文，所以這些報(bào)文也要通過相應(yīng)的字段來區(qū)分。

PPP數(shù)據(jù)幀的協(xié)議域固定填充0xC021。

代碼域的長(zhǎng)度為一個(gè)字節(jié)，主要是用來標(biāo)識(shí)LCP數(shù)據(jù)報(bào)文的類型的。在鏈路建立階段時(shí)，接收方收到LCP數(shù)據(jù)報(bào)文的代碼域無法識(shí)別時(shí)，就會(huì)向?qū)Χ税l(fā)送一個(gè)LCP的代碼拒絕報(bào)文（Code-Reject報(bào)文）。

標(biāo)識(shí)域也是一個(gè)字節(jié)，其目的是用來匹配請(qǐng)求和響應(yīng)報(bào)文。一般而言在進(jìn)入鏈路建立階段時(shí)，通信雙方無論哪一端都會(huì)連續(xù)發(fā)送幾個(gè)配置請(qǐng)求報(bào)文（Config-Request報(bào)文），而這幾個(gè)請(qǐng)求報(bào)文的數(shù)據(jù)域可能是完全一樣的，而僅僅是它們的標(biāo)識(shí)域不同罷了。通常一個(gè)配置請(qǐng)求報(bào)文的ID是從0x01開始逐步加1的，當(dāng)對(duì)端接收到該配置請(qǐng)求報(bào)文后，無論使用何種報(bào)文（回應(yīng)報(bào)文可能是Config-Ack、Config-Nak和Config-Reject三種報(bào)文中的一種）來回應(yīng)對(duì)方，但必須要求回應(yīng)報(bào)文中的ID（標(biāo)識(shí)域）要與接收?qǐng)?bào)文中的ID一致，當(dāng)通信設(shè)備收到回應(yīng)后就可以將該回應(yīng)與發(fā)送時(shí)的進(jìn)行比較來決定下一步的操作。

長(zhǎng)度域的內(nèi)容 = 總字節(jié)數(shù)據(jù)（代碼域+標(biāo)志域+長(zhǎng)度域+數(shù)據(jù)域）。長(zhǎng)度域所指示字節(jié)數(shù)之外的字節(jié)將被當(dāng)作填充字節(jié)而忽略掉，而且該域的內(nèi)容不能超過MRU的值。

數(shù)據(jù)域的內(nèi)容根據(jù)不同的LCP數(shù)據(jù)報(bào)文的內(nèi)容也是不一樣的。

下面說一下LCP包括的幾種報(bào)文類型，不同的報(bào)文在標(biāo)識(shí)域中所填充的內(nèi)容也不同。

LCP報(bào)文主要分為1、鏈路配置報(bào)文；2、鏈路終止報(bào)文；3、鏈路維護(hù)報(bào)文。

鏈路配置報(bào)文主要包括Config-Request、Config-Ack、Config-Nak和Config-Reject四種報(bào)文。

當(dāng)通信雙方需要建立鏈路時(shí)，無論哪一方都需要發(fā)送Config-Request報(bào)文并攜帶每一端自已所希望協(xié)商的配置參數(shù)選項(xiàng)。

當(dāng)接收方收到Config-Request報(bào)文時(shí)，會(huì)在剩下的三種類型的報(bào)文中選擇一種來響應(yīng)對(duì)方的請(qǐng)求報(bào)文，到底選擇哪種報(bào)文來響應(yīng)對(duì)方需依據(jù)以下兩個(gè)條件：

不能完全識(shí)別配置參數(shù)選項(xiàng)的類型域，我們知道一個(gè)Config-Request報(bào)文中會(huì)同時(shí)攜帶多個(gè)配置參數(shù)選項(xiàng)，而對(duì)于一個(gè)支持PPP協(xié)議的通信設(shè)備也不一定會(huì)支持上表中所有列出的配置選項(xiàng)，即使支持，也可能在實(shí)際應(yīng)用中關(guān)閉掉某些選項(xiàng)功能。（例如：當(dāng)使用PPP協(xié)議通信的一端可能將一些無用的配置選項(xiàng)都關(guān)閉了，而僅支持0x01和0x03兩個(gè)配置參數(shù)選項(xiàng)，因此當(dāng)對(duì)方發(fā)送的Config-Request報(bào)文中含有0x04配置選項(xiàng)時(shí)，對(duì)于本端而言這個(gè)配置參數(shù)選項(xiàng)就無法識(shí)別，也即是不支持這個(gè)配置參數(shù)選項(xiàng)的協(xié)商）。

如果能支持完全識(shí)別配置參數(shù)選項(xiàng)，但接收端也可能不認(rèn)可Config-Request報(bào)文中配置參數(shù)選項(xiàng)數(shù)據(jù)域中的內(nèi)容（例如：當(dāng)一端發(fā)送魔術(shù)字配置參數(shù)選項(xiàng)中的魔術(shù)字為全0，而對(duì)端認(rèn)為應(yīng)該為其它值，這種情況就屬于不支持配置參數(shù)選項(xiàng)中的內(nèi)容）。

所以依據(jù)上面的兩個(gè)條件，我們就可以明確在回應(yīng)對(duì)方配置請(qǐng)求報(bào)文時(shí)，采用何種報(bào)文回應(yīng)。

當(dāng)接收Config-Request報(bào)文的一端能識(shí)別發(fā)送過來的所有配置參數(shù)選項(xiàng)且認(rèn)可所有配置參數(shù)選項(xiàng)數(shù)據(jù)域的內(nèi)容時(shí)，接收端將會(huì)給對(duì)端回一個(gè)Config-Ack報(bào)文并將配置請(qǐng)求報(bào)文中的配置參數(shù)選項(xiàng)原封不動(dòng)的放置在Config-Ack報(bào)文的數(shù)據(jù)域內(nèi)（根據(jù)協(xié)議的規(guī)定是不可改變配置參數(shù)選項(xiàng)的順序）。當(dāng)配置請(qǐng)求報(bào)文的發(fā)送端收到Config-Ack報(bào)后，則會(huì)從當(dāng)前階段進(jìn)入到下一個(gè)階段。

當(dāng)接收Config-Request報(bào)文的一端能識(shí)別發(fā)送端所發(fā)送過來的所有配置參數(shù)選項(xiàng)，但對(duì)部分配置參數(shù)選項(xiàng)數(shù)據(jù)域中的內(nèi)容不認(rèn)可時(shí)，接收端將會(huì)給對(duì)端回應(yīng)一個(gè)Config-Nak報(bào)文，（注意，是能夠識(shí)別，只是對(duì)部分參數(shù)內(nèi)容不認(rèn)可，所以不是Config-Reject報(bào)文）該報(bào)文中只攜帶不認(rèn)可的配置參數(shù)選項(xiàng)，而這些配置參數(shù)選項(xiàng)的數(shù)據(jù)內(nèi)容為本端希望的值。然而當(dāng)接收端收到Config-Nak報(bào)文后，會(huì)重新發(fā)送Config-Request報(bào)文，而這個(gè)Config-Request報(bào)文與上一次所發(fā)送的Config-Request報(bào)文區(qū)別在于那些被對(duì)端不認(rèn)可的配置參數(shù)選項(xiàng)的內(nèi)容被填寫到剛剛協(xié)商完后再次發(fā)送的Config-Request報(bào)文中（Config-Nak報(bào)文發(fā)送回來的那些配置參數(shù)選項(xiàng)）。

當(dāng)接收Config-Request報(bào)文的一端不能識(shí)別所有的發(fā)送端發(fā)送過來的配置參數(shù)選項(xiàng)時(shí)，此時(shí)接收端將會(huì)向?qū)Χ嘶匾粋€(gè)Config-Reject報(bào)文，該報(bào)文中的數(shù)據(jù)域只攜帶那些不能識(shí)別的配置參數(shù)選項(xiàng)（當(dāng)配置參數(shù)選項(xiàng)的類型域不識(shí)別時(shí)）。當(dāng)對(duì)端接收到Config-Reject報(bào)文后，同樣會(huì)再次發(fā)送一個(gè)Config-Request報(bào)文，這個(gè)配置請(qǐng)求報(bào)文與上一次發(fā)送的區(qū)別在于將不可識(shí)別的那些配置參數(shù)選項(xiàng)給刪除了。

鏈路終止報(bào)文分為Terminate-Request和Terminate-Reply兩種報(bào)文。LCP報(bào)文中提供了一種機(jī)制來關(guān)閉一個(gè)點(diǎn)對(duì)點(diǎn)的連接，想要關(guān)斷鏈路的一端會(huì)持續(xù)發(fā)送Terminate-Request報(bào)文，直到收到一個(gè)Terminate-Reply為止。接收端一旦收到了一個(gè)Terminate-Request報(bào)文后，必須回應(yīng)一個(gè)Terminate-Reply報(bào)文，同時(shí)等待對(duì)端先將鏈路斷開后，再完成本端的所有斷開的操作。

LCP的鏈路終止報(bào)文的數(shù)據(jù)域與鏈路配置報(bào)文的數(shù)據(jù)域不一樣，鏈路終止報(bào)文中無需攜帶各配置參數(shù)選項(xiàng)。對(duì)于鏈路終止報(bào)文也同樣需要ID一致，當(dāng)接收到Terminate-Reply報(bào)文才會(huì)做鏈路終止操作。

最后說一下魔術(shù)字的含義，這是在鏈路建立過程中比較重要的一個(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ú)一無二的魔術(shù)字。一般來說魔術(shù)字的選擇會(huì)采用設(shè)備的系列號(hào)、網(wǎng)絡(luò)硬件地址或時(shí)鐘。雙方產(chǎn)生相同魔術(shù)字的可能性不能說是沒有的，但應(yīng)盡量避免，通常這種情況是發(fā)產(chǎn)在相同廠商的設(shè)備進(jìn)行互連時(shí)，因?yàn)橐粋€(gè)廠商所生產(chǎn)的設(shè)備產(chǎn)生魔術(shù)字的方法是一樣的。

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

1.鏈路實(shí)際不存在環(huán)路，而是由于對(duì)方在產(chǎn)生魔術(shù)字時(shí)與接收端產(chǎn)生的一致，但實(shí)際這種情況出現(xiàn)的概率是很小的。當(dāng)Config-Nak被對(duì)端接收到后，應(yīng)該發(fā)送一個(gè)Config-Request報(bào)文（此報(bào)文中的魔術(shù)字為Nak報(bào)文中的），當(dāng)對(duì)端接收到后，與上次比較，由于接收端已經(jīng)在Nak報(bào)文中產(chǎn)生了一個(gè)不同的魔術(shù)字，此時(shí)接收端收到的Config-Request報(bào)文中的魔術(shù)字與上次配置請(qǐng)求報(bào)文中不一樣，所以接收端可斷定鏈路不存在環(huán)路。

2.鏈路實(shí)際上確實(shí)存在環(huán)路，一段時(shí)間后Config-Nak報(bào)文會(huì)返回到發(fā)送該報(bào)文的同一端。這時(shí)接收端比較這個(gè)Config-Nak報(bào)文與上一次發(fā)出去的一樣，因此鏈路存在環(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è)過程不斷地重復(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)文來檢測(cè)鏈路環(huán)路是否被解除，當(dāng)接收端收到Echo-Reply報(bào)文時(shí)，就認(rèn)為鏈路環(huán)路被解除，從而就可能進(jìn)行后續(xù)的PPP的過程。

好了，基本上通過3篇PPP閑談，我們可以比較徹底的了解PPP協(xié)議的工作機(jī)制和特點(diǎn)，其實(shí)，會(huì)者不難，協(xié)議都是人制訂的，只有簡(jiǎn)單易用的協(xié)議才會(huì)最終保留下來，就像TCP/IP打敗OSI一樣。所以，只要靜下心來，沒有什么高深的。可能這3篇文章里面有部分個(gè)人理解錯(cuò)誤的地方，希望大家可以多提意見，大家共同進(jìn)步。