網絡基礎篇之HDLC、PPP（原理）

1、廣域網傳輸

　　以前講解的都是關於局域網的數據傳輸，此次講解的是廣域網的傳輸。

　　廣域網簡稱WAN，是一種跨越超大的、地域性的計算機網絡集合。一般跨省、市、甚至一個國家。廣域網包括不少子網，子網能夠是局域網；也能夠是小型的廣域網。

 　　因爲串行通訊有着傳輸距離遠、成本低的特色，因此遠距離、超遠距離的通訊中較常使用串行通訊。

 

2、傳輸協議及方式

　　在廣域網的傳輸中，有幾種協議，本文章說明一下HDLC、PPP。

 

3、HDLC

　　1. 什麼是HDLC

　　HDLC是高級數據鏈路控制協議，是一種數據鏈路層的協議。HDLC是一個ISO標準的面向位的數據鏈路協議,其在同步串行數據鏈路上封裝數據，最經常使用於點對點連接。HDLC主要有如下幾個特性：

　　① 協議不依賴於任何一種字符編碼集。

　　② 數據報文可透明傳輸，用於透明傳輸的「0比特插入法」易於硬件實現。

　　③ 全雙工通訊，沒必要等待確承認連續發送數據報文，有較高的數據鏈路傳輸效率。

　　④ 全部幀採用CRC校驗，並對信息幀進行編號，可防止漏收或重收，傳輸可靠性高。

　　⑤ 傳輸控制功能與處理功能分離，具備較大的靈活性和較完善的控制功能。

　　⑥ HDLC的主要缺點在於，沒有指定字段來標識已封裝的第三層協議。所以，已經基於HDLC定義了其餘幾種協議。

 

　　2. HDLC支持兩種類型的傳輸模式：同步傳輸模式和異步傳輸模式。

　　異步傳輸模式：是以字節爲單位來傳輸數據，而且須要採用額外的起始位和中止位來標記每一個字節的開始和結束。所以，每一個字節的發送都須要額外的開銷。能夠面向點對點或點對多點的傳輸。

　　同步傳輸模式：是以幀爲單位來傳輸數據，在通訊時須要使用時鐘來同步本端和對端設備的通訊。只能用於面向點對點的傳輸。DCE（數據通訊設備），提供了一個用於同步DCE設備和DTE設備之間數據傳輸的時鐘信號，一般狀況下使用DCE產生的時鐘信號。

 

　　3. HDLC幀結構

　　一個完整的HDLC幀最多由六個字段組成：標誌字段（Flag）、地址字段（Address）、控制字段（Control）、信息字段（Information）、幀校驗序列字段（FCS）構成。

　　① 標誌字段：這是一個8位序列，標記幀的開始和結束。 標誌的位模式是01111110。也能夠做爲幀與幀之間的填充字符。

　　② 地址字段：包含接收者的地址。 若是該幀是由主站發送的，則它包含從站的地址。 若是它是從站發送的，則包含主站的地址。 地址字段能夠從1個字節到幾個字節。

　　③ 控制字段：用於構成各類命令及響應，以便對鏈路進行監控。長度1或2字節。

　　④ 信息字段：承載來自網絡層的數據。它的長度有FCS字段或通信節點的緩存容量來決定。使用較多的上限是1000-2000比特；下限是0（S幀）。

　　⑤ 幀校驗字段：這是一個2字節或4字節的幀檢查序列，用於對兩個標誌字段之間的內容進行錯誤檢測。使用的是標準代碼CRC（循環冗餘代碼）。

 

　　4. 根據不一樣的控制字段分爲不一樣類型的幀

　　① I幀：I幀或信息幀承載來自網絡層的用戶數據。 它們還包括附帶在用戶數據上的流和錯誤控制信息。 I幀控制字段的第一位爲0。

　　

　　② S幀：S幀或監控幀不包含信息字段。當不須要負載時，它們用於流和錯誤控制。S幀的前兩位控制域爲1 0。

　　

　　③ U幀 -U幀或未編號的幀用於多種其餘功能，例如連接管理（鏈路的創建與拆除）。 若是須要，它可能包含一個信息字段。 U幀控制字段的前兩位爲1 1。

　　

 

 　　5. HDLC接口地址租用

　　接口沒有IP地址，就沒法生產路由，也就沒法轉發數據報文。IP地址借用容許一個沒有IP地址的接口從其餘的接口上借用IP地址，這樣能夠避免一個接口獨佔IP地址，從而形成IP地址的浪費。通常是借用loopback接口的IP地址。由於這類接口老是處於活躍（active）狀態，於是能提供穩定可用的IP地址。

 

4、PPP

　　1. 什麼是PPP

　　PPP協議是一種點到點鏈路層協議，主要用於在全雙工的同異步鏈路上進行點到點的數據傳輸。

 

　　2. PPP協議的優勢

　　①PPP協議既支持同步傳輸也支持異步傳輸。而X.2五、FR等鏈路層協議僅支持同步傳輸；SLIP僅支持異步傳輸。

　　②PPP協議具備很好的擴展性，在以太網中時，能夠擴展爲PPPoE。

　　③PPP協議提供了LCP（鏈路控制協議）用於鏈路層參數的協商；提供了NCP（網絡控制協議）用於網絡層參數的協商。

　　④PPP協議提供了CHAP（質詢握手認證協議）、PAP（密碼身份驗證協議），更好的保證了網絡的安全性。

　　⑤無重傳機制，網絡開銷小，速度快。

 

　　3. PPP鏈接的創建過程

　　① Dead階段：此階段表示物理層不可用。當通訊雙方檢測到物理線路激活時，會從Dead階段變爲Establish階段（鏈路創建階段）。

　　② Estblish階段：此階段進行LCP參數協商。內容包括最大接收單元MRU、認證方式等選項。當協商成功後，會進入Opened狀態，表示底層鏈路已經創建；反之，則返回到Dead階段。

　　③ Authenticate階段：此階段無關緊要（多數狀況下是有的）。若是須要認證，則在底層鏈路創建過程當中必須進行認證。認證經過或無認證，則進入Network階段；反之，則進入終止階段，再返回到Dead階段。

　　④ Network階段：此階段進行NCP協商。經過NCP協商來選擇和配置一個網絡層協議並進行網絡參數的協商。只有相應的網絡參數協商成功後，纔會創建網絡層通訊。反之，則會進入終止階段，在進入Dead階段。

　　⑤ 當NCP協商成功後，PPP鏈路將保持通訊狀態。

　　⑥ Terminate階段：此階段全部資源都被釋放，通訊雙方將回到Dead階段。

 

　　4. PPP幀格式

　　

 　　PPP幀格式與HDLC協議的幀格式相相似。

　　①Flag域標識一個物理幀的起始與結束，該字節爲二進制序列01111110（0X7E）。

　　②PPP幀的地址域根HDLC的地址域有差別。PPP幀的地址域爲固定的11111111（0XFF）。是一個廣播地址。

　　③PPP幀的默認控制域爲00000011（0X03），表示無序號幀。

　　④FCS是個16位的校驗和，用於檢測PPP幀的完整性。

　　⑤協議字段用於表示PPP幀封裝的協議報文類型：0XC021表明LCP報文；0XC023表PAP報文；0XC223表明CHAP報文。

　　⑥信息字段包含協議中指定協議的數據包。數據字段的默認最大長度（不包含協議字段）稱爲最大接收單元MRU（MRU缺省值爲1500字節）。

　　⑦Code字段。主要用於標識LCP數據報文的類型。

　　⑧Identifier域爲1字節，用於匹配和響應請求

　　⑨Length字段表示該LCP報文的總長度。

　　⑩數據字段承載各類TLV（Type/Length/Value）參數用於協商配置選項。（包括最大接收單元，認證協議等等）

 

　　5. LCP

　　LCP（鏈路控制協議）：LCP能夠自動檢測鏈路環境（如是否存在環路）；協商鏈路參數（如數據包最大長度）；提供認證功能（只有認證成功後纔會創建鏈接）。

　　5.1. LCP報文類型共有四種：

　　① Configure-Request（配置請求）：鏈路層協商過程過程當中發送的第一個報文，該報文表示點對點雙方開始進行鏈路層參數的協商。

　　② Configure-Ack（配置響應）：收到對端發來的Configure-Request報文，若是參數取值徹底接受，則以此報文進行響應。

　　③ Configure-Nak（配置不響應）：收到對端發來的Configure-Request報文，若是參數取值不被接受，則以此報文進行響應並攜帶本端可接受的配置參數。

　　④ Configure-Reject（配置拒絕）：收到對端發來的Configure-Request報文，若是參數取值不被徹底接受，則以此報文進行響應並攜帶本端不能接受的配置參數。

　　5.2. LCP協商常見參數：

　　① 最大接收單元MRU：表示PPP數據幀中Information字段和Padding字段的總長度。在VRP平臺上。MRU參數使用接口上配置的最大傳輸單元（MTU）來表示。MRU參數缺省值爲1500字節。

　　② 認證協議：認證對端使用的認證協議。經常使用的PPP認證協議有PAP與CHAP，一條PPP鏈路可使用不一樣的認證協議，可是被認證方必須支持認證方的認證協議並配置正確的用戶名和密碼等信息。

　　③ 魔術字：用以檢測鏈路和其餘異常狀況。在Config-Request的配置選項參數中進行發送時會隨機產生一個數字並一塊發出，當設備收到一個Config-Request報文時，會與上次發送發送的Config-Request報文中的魔術字進行對比。（不相同的設備產生的魔術字可能相同，只不過機率很是低而已，但不是不可能）。若不相同，則表示沒有環路；若相同，則設備會發送Config-Nak報文並從新生成新的魔術字進行發送。再次收到Config-Nak報文時，依舊進行魔術字的對比。若不相同則表示沒有環路；若相同則會從新發送Config-Request報文，若一直相同會隨着對比次數，存在環路的可能性愈來愈大，等到了必定的級別，則認爲網絡中存在環路。

　　5.3. LCP認證過程

　　① PAP認證過程：

　　a. 被認證方將配置的用戶名和密碼信息使用Authenticate-Request報文以明文方式發送給認證方。

　　b.認證方收到被認證方發送的用戶名和密碼以後，根據本地配置的用戶名和密碼數據庫進行匹配，若匹配，則返回Authenticate-Ack報文表示認證成功。不然返回Authenticate-Nak報文，表示失敗。

　　② CHAP認證過程：

　　a. 認證方發送一個Challenge報文給被認證方，報文中包含Identifier信息與一個隨機產生的Challenge字符串，此Identifier極爲後續報文使用的Identifier。

　　b. 被認證方收到此Challenge報文後，進行一次加密運算，運算公式爲MD5（Identifier + 密碼 + Challenge）。從而獲得一個16字節長的摘要信息，而後將此信息和在端口上配置的CHAP用戶名一塊兒封裝在Response報文中迴應認證方。

　　c. 認證方收到被認證方發送的Response報文後，按照其中封裝的用戶名查找對應的密碼，獲得密碼後，按照上面的計算公式也進行一次計算，計算結果與Response報文中的進行對比，相同則認證成功，不相同則認證失敗。

　　在CHAP認證方式中，因爲密碼是加密以後傳輸，全部極大的提升了安全性。

 

　　6. NCP（IPCP）

　　NCP（網絡控制協議）：每個NCP對應了一種網絡協議，用於網絡地址等參數的協商。下面說下NCP中的IPCP（IP Control Protocol）協議。

　　IPCP使用與LCP相同的協商機制、報文類型，但不是調用LCP，只是工做方式、報文類型等和LCP相同，協商方式有兩種，具體協商過程：

　　6.1. IPCP靜態地址協商

　　① 每一端都要發送包含本端的IP地址的Configure-Request報文給對端。

　　② 每一端都會收到包含對端的IP地址的Configure-Request報文，檢查其中的IP地址，若IP地址是一個合法的單播IP且和本端的IP地址不衝突，則認爲對端可使用該IP地址，而且迴應一個Configure-Ack報文。

 

　　6.2. IPCP動態地址協商

　　① 協商端（沒有IP地址）向被協商端發送一個Configure-RequestA報文，因爲協商端沒有IP地址，所以此報文中包含的IP地址爲0.0.0.0。表示向被協商端請求IP地址。

　　② 被協商端收到Configure-Request報文以後，認爲其中的IP地址不合法，使用Configure-Nak迴應一個新的IP地址（需提早創建IP Pool，而且與端口進行關聯）。

　　③ 協商端收到Configure-Nak報文後，更新本端的IP地址，以後從新發送一個Configure-Request報文，此報文包含新的IP地址。

　　④ 被協商端收到新的Configure-Request報文後，認爲其中的IP是合法的地址，迴應一個Configure-Ack報文。而且也會將包含本端IP地址的Configure-Request報文發送給協商端。

　　⑤ 協商端收到被協商端發送的Configure-Request報文後，認爲其中的IP地址合法，會迴應一個Configure-Ack報文。至此，IPCP的協商完成。

 

5、擴展---PPPoE

　　1. DSL（Digital Subscriber Line）應用

　　爲解決在網絡服務提供商與最終用戶之間的「最後一千米」的傳輸瓶頸問題，使用銅纜電話線路接入因特網。在使用DSL接入網絡時，用戶需安裝調制解調器（也就是你們熟知的「貓」），而後經過現有的電話線與DSLAM（數字用戶線路接入複用器）相連。DSLAM是各類DSL系統的局端設備，屬於「最後一千米」接入設備。

　　以後，DSLAM經過異步傳輸（ATM）網絡或者Ethernet（以太網）網絡將用戶的數據轉發給BRAS（寬帶遠程接入服務器）。BRAS是面向帶寬網絡應用的接入網關，位於骨幹網的邊緣層。

 

　　2. PPPoE在DSL中的應用

　　因爲PPP協議能夠提供良好的訪問控制和計費功能，因而有PPP協議擴展而成的PPPoE協議。此協議能夠在以太網絡中進行傳輸PPP報文。此協議具備適用範圍廣、安全性高、計費方便等特色，深受寬帶接入運營商的承認且被普遍應用。

 

　　3. PPPoE的報文格式

　　

　　PPPoE報文是適用Ethernet格式進行封裝的。

　　① DMAC： 表示目的設備的MAC地址，一般爲以太網絡單播目的地址或者以太網絡廣播地址（0xFFFFFFFF）。

　　② SMAC：表示源設備的MAC地址。

　　③ Type：表示協議類型字段。0x8863表示PPPoE發現階段的報文；0x8864表示PPPoE會話階段的報文。

　　④ FCS：進行報文完整性校驗。

　　PPPoE字段表示：

　　① Ver：表示PPPoE的版本號，值爲0x01。

　　② Type：表示類型，值爲0x01。

　　③ Code：表示PPPoE報文類型，不一樣的取值對應不一樣的PPPoE報文類型（下面會細說明）。

　　④ Session ID：與以太網SMAC和DMAC一塊兒定義了一個PPPoE會話。

　　⑤ Length：表示PPPoE報文的Payload長度，不包括以太網頭部和PPPoE頭部的長度。

　　

　　4. PPPoE協議報文類型

　　① PADI（PPPoE Active Discovery Initiation）：用戶主機發起的PPPoE服務器探測報文。源MAC爲客戶端MAC地址；目的MAC爲廣播地址；Code字段爲0x09；Session ID字段爲0x0000。

　　② PADO（PPPoE Active Discovery Offer）：PPPoE服務器收到PADI報文後的迴應報文。源MAC爲PPPoE服務器MAC地址；目的MAC爲客戶端MAC地址；Code字段爲0x07；Session ID字段爲0x0000。

　　③ PPPoE服務器迴應的PADO報文後，單播發起請求報文。源MAC爲客戶端MAC地址；目的MAC爲選定的PPPoE服務器MAC地址；Code字段爲0x19；Session ID字段爲0x0000。

　　④ 分配一個惟一會話進程ID，經過此報文發送給客戶端。源MAC爲發出報文的PPPoE服務器MAC地址；目的MAC爲客戶端MAC地址；Code字段爲0x09；Session ID字段爲PPPoE服務器爲會話而產生的Session ID。

　　⑤ PADT（PPPoE Active Discovery Terminate）：

 

　　5. 創建回話過程

　　會話過程分爲三個階段

　　5.1 發現階段（PPPoE協商階段）：獲取對方以太網地址；肯定惟一的PPPoE會話。

　　① 客戶端在以太網中廣播一個PADI報文，此報文包含了客戶端所須要的服務信息。全部PPPoE服務器收到PADI報文後，會將報文中包含的請求與本身提供的服務進行對比。

　　② 全部PPPoE服務器收到PADI報文後，會將報文中包含的請求與本身提供的服務進行對比。若PPPoE服務器能夠知足客戶端的服務請求，就會回覆一個PADO報文，因此一個客戶端可能會收到多個PPPoE服務器發出的PADO報文。

　　③ 客戶端收到PADO報文後，會從中選擇最早收到的PADO報文所對應的PPPoE服務器爲指定PPPoE服務器，而且發送一個PADR報文給指定PPPoE服務器。

　　④ PPPoE服務器收到PADR服務器後，會生成一個惟一的Session ID來標識與客戶端的會話，並經過PADS報文將Session ID發送給客戶端。

　　⑤ 當客戶端收到PPPoE服務器發出的PADS報文後，會話創建成功，進入會話階段。

　　5.2 會話階段：包括兩部分 PPP協商階段 與 PPP報文傳輸階段 。

　　① PPP協商階段：此階段與普通PPP協商方式一致，分爲LCP、認證、NCP三個階段。

　　② PPP報文傳輸階段：協商成功後，就能夠承載PPP數據報文，在這一階段傳輸的數據包中的Session ID必須與發現階段PPPoE服務器生成而且發送給客戶端的Session ID保持一致。

　　5.3 會話終結階段：會話創建以後的任意時刻，發送報文結束PPPoE會話。

 　　當PPPoE服務器端或客戶端但願關閉鏈接時，便會發送PADT報文（那一端但願關閉就由那一端發送），Session ID爲但願關閉的鏈接的Session ID，另一端一旦收到此報文，鏈接隨即關閉。