ppp協議功能

ppp協議功能

首先看看」SLIP「協議。改協議能夠理解爲PPP的一個簡化版本，對於加深對PPP協議的理解有些幫助。    此外，經過觀察「SLIP」協議的一些不足，可讓咱們更加深刻的理解PPP協議的設計的巧妙和針對性 SLIP簡單封裝方式的缺陷： 由於沒有一個協商的過程，因此不少參數（好比ip地址）就須要實現直到 沒有一個域來指定上層協議，因此這裏確定只能使用一種協議，並且由於沒有實現協商的機制，因此動態的決定沒法實現 沒有校驗和，某些錯誤沒法及時發現。而須要等到上層協議來處理。浪費系統資源 注意ppp和咱們經常使用的以太網沒什麼必然的聯繫。都屬於數據鏈路層。 地址域(Add),數據幀(Ctrl的控制域也沒有實際意義 考慮到ppp協議是點對點協議，因此ppp協議無需以太網哪一種mac地址。 協議域標示包裝數據包內數據的協議 ip協議就不說拉，重點講下上面四種協議 LCP協議 代碼域：標示」子協議「 標識域：至關於報文ID。 長度域：長度域內容 = 總字節數據（代碼域+標誌域+長度域+數據域）。長度域所指示字節數以外的字節將被看成填充字節而忽略掉 LCP數據報文的分類 1.鏈路配置報文，主要用來創建和配置一條鏈路的。包括Config-Request 、Config-Ack 、Config-Nak 和Config-Reject 其中類型域包含 配置過程當中的一些協商問題 當接收Config-Request報文的一端能識別發送過來的全部配置參數選項且承認全部配置參數選項數據域的內容時，接收端將會給對端回一個Config-Ack報文並將配置請求報文中的配置參數選項原封不動的放置在 Config-Ack報文的數據域內（根據協議的規定是不可改變配置參數選項的順序）。當配置請求報文的發送端收到Config-Ack報後，則會從當前階段進入到下一個階段。 當接收Config-Request報文的一端能識別發送端所發送過來的全部配置參數選項，但對部分配置參數選項數據域中的內容不承認時，接收端將會給對端迴應一個Config-Nak報文，該報文中只攜帶不承認的配置參數選 項， 而這些配置參數選項的數據內容爲本端但願的值。然而當接收端收到Config-Nak 報文後， 會從新發送Config-Request 報文， 而這個Config-Request報文與上一次所發送的Config-Request報文區別在於那些被對端不承認的配置參數選項的內容被填寫到剛剛協 商完後再次發送的Config-Request報文中（Config-Nak報文發送回來的那些配置參數選項）。 當接收Config-Request報文的一端不能識別全部的發送端發送過來的配置參數選項時，此時接收端將會向對端回一個Config-Reject報文，該報文中的數據域只攜帶那些不能識別的配置參數選項（當配置參數選項的類 型域不識別時）。當對端接收到Config-Reject報文後，一樣會再次發送一個Config-Request報文，這個配置請求報文與上一次發送的區別在於將不可識別的那些配置參數選項給刪除了。 鏈路終止報文，主要用來終止一條鏈路的。包括Terminate-Request和Terminate-Reply 鏈路維護報文，主要用來維護和調試鏈路的。除上述兩種報文類型之外，剩餘的全部報文類型均歸屬鏈路維護報 維護報文的產生 當接收端發現LCP報文的代碼域是一個不合法的值時，將會向發送端迴應一個Code-Reject報文，在迴應報文中會將所拒絕報文的內容附加上。 當 接收端發現所接收到的數據幀的協議域是一個不合法的值時，將會向發送端迴應一個Protocol-Reject報文，發送端收到該拒絕報文後將中止發送該 種協議類型的數據報文了。Protocol-Reject報文只能在LCP的狀態機處於Opened狀態時纔可被處理，而在其它狀態接收到該報文將被丟 棄。在Protocol-Reject報文的數據域內將攜帶所拒絕報文的協議類型和報文內容。 Echo-Request報文和Echo- Reply報文主要用來檢測雙向鏈路上自環的問題，除此以外還可附帶作一些鏈路質量的測試和其它功能。當LCP狀態機處於Opened狀態時，若是接收到 了Echo-Request，就需向對端回送一個Echo-Reply報文。不然在其它LCP狀態下，該類型的報文會被丟棄。這種類型數據報文的長度域後 不是直接跟數據域，而是要插入4個字節的Magic-Number（魔術字），該魔術字是在LCP的Config-Request的配置參數選項協商時獲 得的。 NCP協議 NCP協議主要包括IPCP、IPXCP等，但咱們在實際當中最常碰見的也只有IPCP協議了 注意：NCP不是一個具體的協議，而是好比IPCP,IPXCP等協議的一個統稱。 IPCP IPCP控制協議主要是負責完成IP網絡層協議通訊所需配置參數的選項協商的。IPCP在運行的過程中，主要是完成點對點通訊設備的兩端動態的協商IP地址。 協議報文和lcp相似。包類型是lcp的一個子集，經常使用的如Config-Request、Config-Ack、Config-Nak和Config-Reject 靜態協商，也便是不協商。點對點的通訊設備兩端在PPP協商以前已配置好了IP地址，因此就無須在網絡層協議階段協商IP地址，而雙方惟一要作的就是告訴對方自身的IP地址。 雙方分別將本身的ip和其餘可選的信息告訴對方 動態協商，也便是一端配置爲動態獲取IP地址，另外一端經過手動方式配置IP地址，且容許給對端分配IP地址，這個過程實際上可與窄帶撥號上網的過程相一致 sender首先將ip域置於0，以向receiver動態一個ip地址。後面四個和靜態協商一致。 認證協議 PPP協議也提供了可選的認證配置參數選項，缺省狀況下點對點通訊的兩端是不進行認證的。在LCP的Config-Request報文中不可一次攜帶多種認證配置選項，必須兩者擇其一（PAP/CHAP） 注意認證過程在lcp和ncp中間進行 PAP PAP認證是兩次握手（單方向）。 用戶名和密碼使用明文，安全性較差 CHAP      開始由驗證方向被驗證方發送一段隨機的報文，並加上本身的主機名。當被驗證方收到驗證方的驗證請求，從中提取出驗證方所發送過來的主機名，而後根據 該主機名在被驗證方設備的後臺數據庫中去查找相同的用戶名的記錄，當查找到後就使用該用戶名所對應的密鑰，而後根據這個密鑰、報文ID和驗證方發送的隨機 報文用Md5加密算法生成應答，隨後將應答和本身的主機名送回，一樣驗證方收到被驗證方發送迴應後，提取被驗證方的用戶名，而後去查找本方一致用戶名後， 根據該用戶名所對應的密鑰、保留報文ID和隨機報文用Md5加密算法生成結果，和剛剛被驗證方所返回的應答進行比較，相同則返回Ack，不然返回Nak