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

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

代碼域的長度為一個字節(jié)，主要是用來標識LCP數(shù)據報文的類型的。在鏈路建立階段時，接收方收到LCP數(shù)據報文的代碼域無法識別時，就會向對端發(fā)送一個LCP的代碼拒絕報文（Code-Reject報文）。

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

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

數(shù)據域的內容根據不同的LCP數(shù)據報文的內容也是不一樣的。

下面說一下LCP包括的幾種報文類型，不同的報文在標識域中所填充的內容也不同。

LCP報文主要分為1、鏈路配置報文；2、鏈路終止報文；3、鏈路維護報文。

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

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

當接收方收到Config-Request報文時，會在剩下的三種類型的報文中選擇一種來響應對方的請求報文，到底選擇哪種報文來響應對方需依據以下兩個條件：

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

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

所以依據上面的兩個條件，我們就可以明確在回應對方配置請求報文時，采用何種報文回應。

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

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

當接收Config-Request報文的一端不能識別所有的發(fā)送端發(fā)送過來的配置參數(shù)選項時，此時接收端將會向對端回一個Config-Reject報文，該報文中的數(shù)據域只攜帶那些不能識別的配置參數(shù)選項（當配置參數(shù)選項的類型域不識別時）。當對端接收到Config-Reject報文后，同樣會再次發(fā)送一個Config-Request報文，這個配置請求報文與上一次發(fā)送的區(qū)別在于將不可識別的那些配置參數(shù)選項給刪除了。

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

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

最后說一下魔術字的含義，這是在鏈路建立過程中比較重要的一個參數(shù)，這個參數(shù)是在Config-Request里面被協(xié)商的，主要的作用是防止環(huán)路，如果在雙方不協(xié)商魔術字的情況下，某些LCP的數(shù)據報文需要使用魔術字時，那么只能是將魔術字的內容填充為全0；反之，則填充為配置參數(shù)選項協(xié)商后的結果。

魔術字在目前所有的設備當中都是需要進行協(xié)商的，它被放在Config-Request的配置選項參數(shù)中進行發(fā)送，而且需要由自身的通信設備獨立產生，協(xié)議為了避免雙方可能產生同樣的魔術字，從而導致通信出現(xiàn)不必要的麻煩，因此要求由設備采用一些隨機方法產生一個獨一無二的魔術字。一般來說魔術字的選擇會采用設備的系列號、網絡硬件地址或時鐘。雙方產生相同魔術字的可能性不能說是沒有的，但應盡量避免，通常這種情況是發(fā)產在相同廠商的設備進行互連時，因為一個廠商所生產的設備產生魔術字的方法是一樣的。

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

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

2.鏈路實際上確實存在環(huán)路，一段時間后Config-Nak報文會返回到發(fā)送該報文的同一端。這時接收端比較這個Config-Nak報文與上一次發(fā)出去的一樣，因此鏈路存在環(huán)路的可能性又增大了。我們知道當一端收到了一個Config-Nak報文時，又會發(fā)送一個Config-Request報文（該報文中的魔術字與Config-Nak中的一致），這樣又回到了最初的狀態(tài)，在這條鏈路上就會不斷的出現(xiàn)Config-Request、Config-Nak報文，因此這樣周而復始下去，接收端就會認為PPP鏈路存在環(huán)路的可能性在不斷增加，當達到一定數(shù)量級時，就可認為此鏈路存在環(huán)路。（注意，不是第一次受到相同的魔術字就判斷有環(huán)路的）

但在實際應用中根據不同設備實現(xiàn)PPP協(xié)議的方法，我們在鏈路環(huán)路檢測時可采用兩種方法。第一種機制就是如上面所述的，這個過程不斷地重復，最終可能會給LCP狀態(tài)機發(fā)一個Down事件，這時可能會使LCP的狀態(tài)機又回到初始化階段，又開始新一輪的協(xié)商。當然對于某些設備還會采用第二種機制，就是不產生任何事件去影響當前LCP的狀態(tài)機，而是停留在請求發(fā)送狀態(tài)。但這時認為鏈路有環(huán)路的一端設備需要不斷的向鏈路上發(fā)送Echo-Request報文來檢測鏈路環(huán)路是否被解除，當接收端收到Echo-Reply報文時，就認為鏈路環(huán)路被解除，從而就可能進行后續(xù)的PPP的過程。

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