對于網絡協議的學習，我們也已經持續一段時間了，前一陣子我們講解了PPP協議的一些基礎概念，那么這里，我們再來針對PPP數據幀的格式進行一下充分的說明。前面我們也曾說過，可以說現在家里的ADSL都是通過PPP協議進行鏈路的搭建，想要了解PPP，個人認為有3個關鍵的知識點。

1、PPP數據幀的格式；

2、PPP的幾種報文；

3、PPP的狀態轉移

首先說說的PPP數據幀的格式，因為PPP是鏈路層協議，所以我們將它的數據單位稱為幀

每一個PPP數據幀均是以一個標志字節起始和結束的，該字節為0x7E（這樣很容易區分出每個PPP幀）

緊接在起始標志字節后的一個字節是地址域，該字節為0xFF。我們熟知網絡是分層的，且對等層之間進行相互通信，而下層為上層提供服務。當對等層進行通信時首先需獲知對方的地址，而對不同的網絡，在數據鏈路層則表現為需要知道對方的MAC地址、X.121地址、ATM地址等；在網絡層則表現為需要知道對方的IP地址、IPX地址等；而在傳輸層則需要知道對方的協議端口號。例如如果兩個以太網上的主機希望能夠通信的話，首先發送端需獲知對端的MAC地址。但由于PPP協議是被運用在點對點的鏈路上的特殊性，它不像廣播或多點訪問的網絡一樣，因為點對點的鏈路就可以唯一標示對方，因此使用PPP協議互連的通信設備的兩端無須知道對方的數據鏈路層地址，所以該字節已無任何意義，按照協議的規定將該字節填充為全1的廣播地址。同地址域一樣，PPP數據幀的控制域也沒有實際意義，按照協議的規定通信雙方將該字節的內容填充為0x03。（既然無意義，就可以隨便賦值了吧，呵呵，只要大家都遵守一個標準就行）

就PPP協議本身而言，我們最關心的內容應該是它的協議域和信息域。協議域可用來區分PPP數據幀中信息域所承載的數據報文的內容。協議域的內容必須依據ISO 3309的地址擴展機制所給出的規定。該機制規定協議域所填充的內容必須為奇數，也即是要求低字節的最低位為“1”，高字節的最低位為“0”。如果當發送端發送的PPP數據幀的協議域字段不符合上述規定，則接收端會認為此數據幀是不可識別的，那么接收端會向發送端發送一個Protocol-Reject報文，在該報文尾部將完整地填充被拒絕的報文。

信息域缺省時最大長度不能超過1500字節，其中包括填充域的內容，1500字節大小等于PPP協議中配置參數選項MRU（Maximum Receive Unit）的缺省值，在實際應用當中可根據實際需要進行信息域最大封裝長度選項的協商。信息域如果不足1500字節時可被填充，但不是必須的，如果填充則需通信雙方的兩端能辨認出有用與無用的信息方可正常通信。

協議域和信息域是需要合在一起看的，目前主要用到的協議類型有LCP、NCP和普通的IP協議，而他們相對應的協議域字段則為0×C021、0×8021和0×0021，可以看到應證了這句話：也即是要求低字節的最低位為“1”，高字節的最低位為“0”。而后面的信息根據不同協議包含了不同的報文內容。

0×C021 LCP數據報文 校驗

0×8021 NCP數據報文 校驗

0×0021 IP數據報文  校驗

其實這3種不同協議就對應PPP協議在運行過程中的不同狀態，以后會在PPP狀態轉移中介紹到，我們可以很容易根據PPP幀的協議域就判斷目前處于PPP的哪個階段。遇到PPP問題，我們通常通過抓包，然后判斷PPP哪個階段有問題，再進行分析和問題定位。注意一點的就是，NCP不是一種協議，它的全稱是網絡控制協議，也就是說最后雙方都遵循的數據傳輸協議，可以是IPCP，也可以是IPXCP。

CRC校驗域主要是對PPP數據幀傳輸的正確性進行檢測的，當然在數據幀中引入了一些傳輸的保證機制是好的，但可以反過來說，同樣我們會引入更多的開銷，這樣可能會增加應用層交互的延遲。

最后給大家一個通過Ethereal抓下來的PPP幀，對應上面的說明，看看大家是否可以看懂：

7E FF 03 C021 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E

至于信息域里面的東西，還可以再細分，之后在PPP報文里面再說。

這是我把書上的東西，進行自己的理解，加以通俗化，希望初學的XDJM能夠看的懂一點，估計大家還在夢鄉中吧，呵呵。