ppp協議在進行lcp協商的時候，雙方是互相傳送configure-request，然後向對方回應configure-ack，也可以只有一 方傳送，另一方回應。
ppp協議與其他鏈路層協議不同 既支援同步鏈路又支援非同步鏈路，而如x25 framerelay等資料鏈路層協議只對同步鏈路提供支援；
具有各種ncp協議 如ipcp, ipxcp更好地支援了網路層協議；
具有驗證協議chap pap 更好了保證了網路的安全性；
易擴充；
ppp的協商過程
ppp在建立鏈路之前要進行一系列的協商過程，過程如下：ppp首先 進行lcp協商，協商內容包括：mtu(最大傳輸單元)、魔術字(magic number)、驗證方式、非同步字元對映等選項(詳見rfc1661) lcp協商成功後，進入establish(鏈路建立)階段，如配置了chap或pap驗證，便進入chap或pap驗證階段，驗證通過後才會進入網路階 段協商(ncp)，如ipcpipxcp、bcp的協商，任何階段的協商失敗都將導致鏈路的拆除，魔術字，主要用於檢測鏈路自環，ppp靠傳送echo request、echo reply報文來檢測自環和維護鏈路狀態，如連續發現有超過最大自環允許數目echo request報文中魔術字與上次傳送魔術字相同，則判定網路發生自環現象，如鏈路發生自環，則就需採取相應措施對鏈路復位 另外，lcp傳送config request時也可以檢測自環，lcp發現自環後，在傳送一定數目的報文後也會復位鏈路，如果ppp傳送的echo request 報文產生丟失，則在連續丟失最大允許丟失的個數之後，將鏈路復位，以免過多的無效資料傳輸，非同步字元對映用於同非同步轉換。
pap的驗證過程
pap為兩次握手協議，它通過使用者名稱及口令來對使用者進行驗證。pap驗證過程如下：當 兩端鏈路可相互傳輸資料時，被驗證方傳送本端的使用者名稱及口令到驗證方，驗證方根據本端的使用者表或radius伺服器，檢視是否有此使用者，口令是否正確，如 正確則會給對端傳送ack報文，通告對端已被允許進入下一階段協商，否則傳送nak報文，通告對端驗證失敗，此時並不會直接將鏈路關閉，只有當驗證不過次 數達到一定值時，才會關閉鏈路，來防止因誤傳、網路干擾等造成不必要的lcp重新協商過程。pap的特點是在網路上以明文的方式傳遞使用者名稱及口令，如在傳 輸過程中被截獲便有可能對網路安全造成極大的威脅。因此，它適用於對網路安全要求相對較低的環境。
chap的驗證過程
chap 為三次握手協議，它的特點是：只在網路上傳輸使用者名稱，而並不傳輸使用者口令，因此，它的安全性要比pap高。chap的驗證過程為：首先由驗證方向被驗證方 傳送一些隨機產生的報文，並同時將本端的主機名附帶上一起傳送給被驗證方，被驗證方接到對端對本端的驗證請求(challenge)時，便根據此報文中驗 證方的主機名和本端的使用者表查詢使用者口令字，如找到使用者表中與驗證方主機名相同的使用者，便利用報文id，此使用者的金鑰用md5演算法生成應 答，response 隨後將應答和自己的主機名送回，驗證方接到此應答後，用報文id、本方保留的口令字（金鑰）和隨機報文用md5演算法得出結果，與被驗證方應答比較，根據比 較結果返回相應的結果。
比較
LCP的引入筆記
高階資料結構 前面介紹了幾種演算法構造字尾陣列，雖然得到的字尾陣列已經能處理一些簡單的問題，但是為了讓其能夠具有與字尾樹相媲美的字串處理能力，需要引入輔助工具 lcp longest common prefix,最長公共字首 對於字串st1和st2,它們的最長公共字首lcp str st1,st2 ...
SDP offer answer協商原則
規則1 初始offer必須在invite訊息或者第乙個可靠的非失敗型響應中。理解 初始的offer不能在prack ack update中 規則2 如果初始offer在invite訊息中，answer必須出現在乙個可靠的非失敗型響應中 補充 當可靠的1 響應和2 響應都攜帶了sdp，那麼兩者的sdp...
自協商原理
自協商原理 自協商是通過一種叫做快速連線脈衝的訊號實現的，簡稱flp.自協商雙方通過flp來進行交換資料 1.如果一端是固定模式 無論是10m 100m 另外一端是自協商模式，即便能夠協商成功，自協商的那一端也將只能工作在半雙工模式。2.如果一端工作在全雙工模式，另外一端工作在半雙工模式 包括自協商...