一、廣域網傳輸
之前講解的都是關於局域網的數據傳輸，這次講解的是廣域網的傳輸。
廣域網簡稱WAN，是一種跨越超大的、地域性的計算機網絡集合。通常跨省、市、甚至一個國家。廣域網包括很多子網，子網可以是局域網；也可以是小型的廣域網。
由於串行通信有着傳輸距離遠、成本低的特點，所以遠距離、超遠距離的通信中較常使用串行通信。
二、傳輸協議及方式
在廣域網的傳輸中，有幾種協議，本文章說明一下HDLC、PPP。
三、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地址。
四、PPP
1. 什么是PPP
PPP協議是一種點到點鏈路層協議，主要用於在全雙工的同異步鏈路上進行點到點的數據傳輸。
2. PPP協議的優點
①PPP協議既支持同步傳輸也支持異步傳輸。而X.25、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的協商完成。
五、擴展---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，另外一端一旦收到此報文，連接隨即關閉。