點對點協議PPP
在通信鏈路較差的年代，在數據鏈路層使用可靠傳輸協議曾經是一種好方法，比較簡單的點對點PPP協議則是目前使用最廣泛的數據鏈路層協議。
PPP協議的特點
互聯網用戶通過都要連接到某個ISP才能接入到互聯網。PPP協議就是用戶計算機和ISP進行通信時所使用的數據鏈路層協議。如圖(圖3-9)
ppp協議是IETF在1992年制定的，現在的PPP協議在1994年就已經成為了互聯網的正式標准[RFC 1661]。
PPP協議應該滿足的需求
IEFE認為，在設計PPP協議的時候就應該從以下方面考慮：
-
簡單
數據鏈路層沒有必要提供比IP協議更多的功能，因此，對數據鏈路層的幀，不需要糾錯，不需要排序號，也不需要流量控制。 -
封裝成幀
PPP協議必須規定特殊的字符作為幀定界符(即標志一個幀的開始字符和結束字符)，以便接收端從收到的比特流中能夠准確地找出幀的開始和結束位置。 -
透明性
PPP協議必須保持數據傳輸的透明性，也就是說，如果數據當中出現了與幀定界符一樣的比特組合的時候，就要采取有效的措施來解決這個問題。 -
多種網絡協議
PPP協議能夠在同一條物理鏈路上同時支持多種網路層協議的運行，當點對點鏈路所連接的是局域網或者路由器的時候，PPP協議必須同時支持在鏈路所連接的局域網或者路由器上運行的各種網絡協議。 -
多種類型鏈路
除了要支持多種網絡層協議，還要支持在多種類型上的數據鏈路上運行。 -
差錯檢測
PPP協議必須能夠對接收端接收到的數據幀進行幀檢測，如果出現錯誤，立即丟棄掉這個錯誤的幀，如果接收到的錯誤幀不丟棄，就會在網絡上繼續向前到網絡層進行轉發，這回白白丟棄掉很多的網絡資源。 -
檢測連接狀態
PPP協議必須要有一種能夠自動檢測鏈路是否在正常工作的機制。 -
最大傳輸單元
PPP協議必須對每一種類型的點對點鏈路設置最大傳輸單元MTU的標准默認值(1500字節)，這樣做是為了促進各種實現之間的可操作性。如果高層協議發送的分組超過了MTU值，PPP就會丟棄掉這樣的幀，並返回差錯，報告給上層，需要注意的是，MTU是數據鏈路層的幀可以載荷的數據部分的最大長度，而不是幀的總長度。 -
網絡層地址協商
PPP協議必須提供一種使通信的兩個網絡層(例如：兩個IP層)的實體能夠通過協商知道或者能夠配置彼此的網絡地址。協商的算法應該盡可能的簡單，並且能夠在所有的請款下該得到結果。這對撥號連接的鏈路特別的重要，因為如果僅僅在鏈路層建立了連接而不知道對方的網絡層地址，則不能夠保證早網絡層傳輸分組。 -
數據壓縮協商
PPP協議必須能夠提供一種方法協商使用數據壓縮算法。但是PPP協議並不要求將數據壓縮到標准化。
在TCP/IP協議族中，可靠傳輸由傳輸層的TCP協議控制，因此數據鏈里層的PPP協議不需要進行糾錯，不需要設置序列號，也不需要進行流量控制。PPP協議不支持多點線路(即一個主站和鏈路上的多個從站i紀念性通信，它只支持點對點的鏈路通信。此外，PPP協議支支持全雙工鏈路)。
PPP協議的組成
PPP協議有以下三部分
-
一個將完整的IP數據報封裝到串行鏈路上。
-
一個用來建立，配置和測試數據鏈路層的鏈路控制協議LCP(Link Control Protocol)。通信的雙方可以協商一些選項。
-
一套網絡控制協議NCP，其中的每一個協議支持不同的網絡層協議，如IP層，DECnet等。
PPP協議的幀格式
各字段的意義
如圖
PPP幀的首部和尾部分別為四個字段和兩個字段。
- 首部的第一個字段和尾部的第二個字段都是標志字段，規定為0x7E(01111110),標志着一個幀的開始或者結束，因此標志字段就是PPP幀的定界符。連續兩幀之間只需要用一個標志字段，如果出現連續兩個標志字段，則表示是一個空的PPP幀，應當丟棄。
2.首部當中的地址字段A規定為0xFF,控制字段C規定為0x03(00000011)。(這兩個字段沒有實際什么用途)
-
PPP首部的第四個字段是2字節的協議字段
- 當協議字段為0x0021,代表的是IP數據報;
- 當協議字段為0xC021,代表的是鏈路控制協議LCP數據;
- 當協議字段為0x8021,代表的是網絡層的控制數據;
-
信息字段的長度是可變的，但不能超過1500字節。
-
尾部的第一個字段(2字節)是使用CRC的幀檢驗序列FCS。
字節填充
當信息字段出現了0x7E這樣的比特流，就必須采取必要措施使得不會被接收端認為這是幀定界符號。
當PPP使用異步傳輸的時候(逐個字符發送)，把每一個0x7E字節轉變為兩個字節序列(0x7D和0x5E),若信息字段中出現了0x7D或者0x5E這樣的轉義字符，則把0x7D轉變為2字節序列(0x7D和0x5D)；如果出現了控制字符，例如0x03(在控制字符串表示傳輸結束)，就變成2字節序列(0x7D,0x23)。由於在發送端進行了字節填充，因此在鏈路上傳送的信息字節數就超過了原來的字節數。但接收端在收到字節后再進行與發送端字節填充相反的交換，就可以正確的恢復出原來的信息。
0比特填充
當PPP使用同步傳輸的時候(一連串的比特發送)，PPP協議采用的是0比特字節填充來實現透明傳輸。
具體做法是(如上圖)：在發送端，先掃描整個信息段(通常使用硬件掃描，也可以使用軟件，不過比較慢)，只要發現有5個連續的1，就立即填入一個0，因此經過這種0比特填充后的數據，就可以保證再信息字段中不會出現幀界定符號(01111110)，接收端在接收到一個幀的時候，先找到一個標志字段F(7E)邊界,接着再用硬件對其中的比特流進行掃描。每當發現連續的5個1的時候，就把這個連續的5個1后面的0刪除掉，以還原成原來的信息比特流(如圖3-11)，這樣就保證了透明傳輸：在傳輸的數據比特流過程中可以傳送任意組合的比特流，而不會引起幀邊界的錯誤判斷。
PPP協議的工作狀態
剛才我們討論了PPP幀的格式和PPP幀是怎么組成的。但是PPP鏈路到底一開始是怎么被初始化的呢？當用戶撥號進入ISP后，就建立的一條從用戶個人電腦到ISP的ISP連接，這時，用戶個人電腦向ISP發送一系列的鏈路控制協議LCP分組(封裝成多個PPP幀)，以便建立LCP連接，這些分組及其響應選擇了將要使用的一些PPP參數。接着還要進行網絡層配置，網絡控制協議NCP給新接入的用戶個人電腦分配了一個臨時的IP地址，這樣，用戶個人電腦就可以成為了互聯網上一個有IP地址的主機了。
當用戶通信完畢后，NCP就釋放網絡層連接，收回原來分配出去的IP地址，接着LCP釋放數據鏈路層的連接，最后釋放的是物理層的連接。
上述過程可用圖3-12的狀態圖描述：
PPP鏈路的起始和終止狀態永遠是圖中的鏈路靜止狀態，這時候用戶電腦和ISP的路由器之間並不存在物理層的連接。
當用戶電腦通過調制解調器呼叫路由器的時候(屏幕上的連接按鈕)，路由器就能檢測到調制解調器發出的載波信號，在雙方建立了物理層連接之后，PPP就進入了鏈路建立狀態，其目的是建立LCP連接。
這時候LCP開始協商一些配置項，即發送LCP的配置請求幀，這是個PPP幀，其協議字段為LCP的協議代碼(0xC021)，而信息字段包含特定的配置請求。鏈路的另一端可以發送以下幾種響應的一種：
-
配置確認幀：所有選項都接受。
-
配置否認幀：所有配置都理解但不能接受。
-
配置拒絕幀：選項中有的無法識別或者不能接受，需要協商。
協商結束后就建立了LCP鏈路，接着就進入鑒別狀態，在這一狀態，只允許傳送LCP協議的分組，鑒別協議的分組以及監控鏈路質量的分組，如果鑒別失敗，則轉到鏈路終止狀態，若鑒別成功，則進入網絡層協議狀態。
在網絡層協議狀態中，PPP鏈路的兩端的網絡控制協議NCP根據網絡層的不同協議互相交換網絡層網絡層特定的網絡控制分組。這個步驟很重要的，因為現在的路由器能夠同時支持網絡層協議。總之，PPP協議的兩端的網絡層可以運行不同的網絡層協議，但仍然可以使用同一個PPP協議進行通信。
當網絡層配置完畢后，鏈路就進入可進行通信的鏈路打開狀態，鏈路的兩個PPP端點可以彼此發送分組。兩個PPP端點還可以發送回送請求LCP分組和回送回答LCP分組，以檢查鏈路的狀態。
數據傳輸結束后，可以由鏈路的一端發送終止請求LCP分組請求終止鏈路連接，在收到對方發送過來的LCP分組后，轉到鏈路終止狀態，如果鏈路出現故障，也會從鏈路打開狀態轉到鏈路終止狀態，當調制解調器的載波停止后，則返回到鏈路靜止狀態。