2. PPP 協議位於TCP/IP協議棧中哪一層？其主要功能是什麼？
PPP協議處於TCP/IP協議棧中的鏈路層（第二層），是一種提供在點到點鏈路上傳輸封裝網絡層數據包的數據鏈路層協議；PPP的主要功能是用來在支持全雙工的同異步鏈路上進行點到點之間的數據傳輸。
3. PPP 主要由哪幾類協議組成？各類協議的功能是什麼？
PPP定義了一整套的協議，其組成及功能如下：
(1) 鏈路控制協議（LCP：Link Control Protocol），主要用來建立、拆除和監控數據鏈路。
(2) 網絡層控制協議（NCP：Network Control Protocol），主要用來協商在該數據鏈路上所傳輸的數據包的格式與類型。
(3) 擴展協議族，主要用於提供對PPP功能的進一步支持。例如用於網絡安全方面的驗證的PAP和CHAP。
4. PPP 協議有哪些特點？
PPP協議的特點如下：
(1) PPP協議與其他鏈路層協議不同，PPP既支持同步鏈路又支持異步鏈路，而如X25、FR 等數據鏈路層協議只對同步鏈路提供支持；
(2) PPP協議具有各種NCP協議，如IPCP、IPCPv6、IPXCP協議，它更好地支持了網絡層協議；
(3) PPP協議具有驗證協議PAP、CHAP，它更好了保證了網絡的安全性；
(4) PPP協議更容易擴充。
5. LCP 協商哪些內容，過程如何？
PPP在建立鏈路之前要進行一系列的協商，PPP 首先進行LCP協商，協商內容包括MRU（最大傳輸單元）、魔術字（magic number）、 驗證方式異步字符映射等選項（詳見RFC1661）；LCP協商成功後才進入Establish(鏈路建立)階段；任何階段的協商失敗都將導致鏈路的拆除，MRU用於協商PPP鏈路的最大包傳輸能力，該選項向對端指出本端能夠接收的最大報文長度，它以字節爲單位，指出Information+Padding的長度，不包括framing、Protocol、FCS和任何爲透明傳輸所填充的比特或字節。該選項的缺省值爲1500字節。該選項實際上指出本端的一種能力，但並不要求對端一定要最大化使用這種能力。
例如，本端在配置選項中聲明MRU爲2048 字節，這並不是說要求對端發送的任何報文都要達到2048字節，若對端能滿足MRU選項，則回Config ACK報文，若不滿足，則回Config NAK報文；魔術字主要用於檢測鏈路自環，PPP靠發送Echo Request和Echo Reply報文來檢測自環和維護鏈路狀態；如連續發現有超過最大自環允許數目，Echo Request報文中魔術字與上次發送魔術字相同，則判定網絡發生自環現象。如鏈路發生自環，則就需採取相應措施對鏈路復位；另外，LCP發送Config Request時也可以檢測自環，LCP發現自環後，在發送一定數目的報文後也會復位鏈路，如果PPP發送的Echo
Request報文產生丟失，則在連續丟失最大允許丟失的個數之後，將鏈路復位，以免過多的無效數據傳輸。異步字符映射用於同異步轉換。
6. PAP與CHAP的驗證過程分別是由哪方發起的？PAP和CHAP的最大不同點是什麼？
PAP是首先由被驗證方將自己的用戶名及密碼送給驗證方；而CHAP驗證是首先由驗證方發起；驗證過程的主要區別爲：PAP爲明文傳送密碼，而在CHAP驗證過程中密碼是不在線傳送的，屬於密文傳送。
7. PAP的詳細驗證過程是什麼樣的？
PAP爲兩次握手協議，詳細驗證過程如下：當兩端鏈路可相互傳輸數據時，被驗證方發送本端的用戶名及口令到驗證方，驗證方根據本端的用戶表（或Radius服務器）查看是否有此用戶，口令是否正確。如正確則會給對端發送ACK報文，通告對端已被允許進入下一階段協商；否則發送NAK報文，通告對端驗證失敗。一次認證失敗並不會直接將鏈路關閉，只有當驗證不過次數達到一定值時，纔會關閉鏈路，來防止因誤傳、網絡干擾等造成不必要的LCP重新協商過程。
8. CHAP的詳細驗證過程是什麼樣的？
CHAP爲三次握手協議，其單向驗證過程分爲兩種情況：驗證方配置了用戶名和驗證方沒有配置用戶名。
l 驗證方配置了用戶名的CHAP驗證過程如下：
(1) 驗證方主動發起驗證請求，驗證方向被驗證方發送一些隨機產生的報文（Challenge），並同時將本端的用戶名附帶上一起發送給被驗證方；
(2) 被驗證方接到驗證方的驗證請求後，根據此報文中驗證方的用戶名在本端的用戶表查找該用戶對應的密碼，如果在用戶表找到了與驗證方用戶名相同的用戶，便利用報文ID、此用戶的密鑰（密碼）和MD5算法對該隨機報文進行加密，將生成的密文和被驗證方自己的用戶名發回驗證方（Response）；
(3) 驗證方用自己保存的被驗證方密碼和MD5算法對原隨機報文加密，比較二者的密文，根據比較結果返回不同的響應（Acknowledge or Not Acknowledge）。
l 驗證方沒有配置用戶名的CHAP驗證過程如下：
(1) 驗證方主動發起驗證請求，驗證方向被驗證方發送一些隨機產生的報文（Challenge）；
(2) 被驗證方接到驗證方的驗證請求後，利用報文ID、配置的CHAP密碼和MD5算法對該隨機報文進行加密，將生成的密文和自己的用戶名發回驗證方（Response）；
(3) 驗證方用自己保存的被驗證方密碼和MD5算法對原隨機報文加密，比較二者的密文，根據比較結果返回不同的響應（Acknowledge or Not Acknowledge）。
9. PPP LCP協商中的MRU選項是如何取值的？
PPP LCP協商的MRU（Maximum-Receive-Unit 最大接收單元）是針對PPP報文而言，指發送端PPP報文中信息域的長度不能超過MRU，否則接收端不負責處理，可能會將報文丟棄。
大多數廠家不提供MRU的設置命令而是把MTU的配置值作爲本端MRU的值與對端協商MRU。最終PPP鏈路的MTU的取值應該是：MIN（配置MTU，MIN（本端MRU，對端MRU））
因此，封裝PPP的接口上的MTU值被改變後，如想讓這個改變立即生效，就需觸發LCP重新協商。
這裏描述的是普通PPP的情形，MP、PPPOX等PPP應用的MTU的最終取值更加複雜一些。
MRU選項是LCP協商成功的必要選項，這個選項最終必須協商成功，不能忽略，最終PPP雙方必須確認這個選項，不能否認或拒絕。
10. PPP LCP協商中的ACCM選項有什麼意義？
ACCM（Async-Control-Character-Map 異步控制字符映射）選項是在異步鏈路上用來通知對端哪些字符被本端用於控制，必須被轉義（映射）。
PPP幀中FLAG字段的值是0X7E（實際上大多鏈路層協議幀中FLAG字段都是這個值）。當這個值出現在幀內容中時需對它進行轉義，同步鏈路中，這個過程是通過位比特填充的技術完成的（即在第5個1與第6個1之間填充0）。異步鏈路中，特殊字符0X7D被用做轉義字符，對一些字符進行轉義。由於異步鏈路中，有些串行接口驅動程序或MODEM需要用一些字符作爲控制字符使用，字符的範圍是0X00－0X1F（0-31）所以需要對這些字符進行轉義處理，大多數情況下並不是這個範圍內的所有字符都作爲控制字符，因此PPP
LCP提供這個選項用來告訴對端，本端將哪些字符作爲控制字符處理，請對端將這些字符轉義後發送。
ACCM選項用一個32位整數的位的值來表示哪些字符用作控制字符，譬如0X000A0000，第17位與第19位爲1，說明字符17（XON）與字符19（XOFF）作爲控制字符使用，需要進行轉義。
在異步鏈路上，尤其是低帶寬、高時延的異步線路（例如無線）上合理設置ACCM值可以有效避免在數據傳輸過程中引入額外時延。
異步鏈路上的LCP協商，這個選項是必要選項，必須協商成功。
11. PPP LCP協商中的Magic-number選項有什麼意義？
Magic-number選項用來協商雙方的魔術字，兩端魔術字不能重複，魔術字可用來檢測鏈路的環回情況。
這是一個必要選項，必須被確認否則LCP不能UP。
12. PPP LCP協商中的PFC選項有什麼意義？
PFC（Protocol-Field-Compression 協議域壓縮）選項是用來協商PPP報文的協議域是否可以被壓縮，用高位字節的最低位表示此報文是否協議域被壓縮，1表示是，0表示沒有。壓縮後協議域的兩個字節會被壓縮成一個字節，如IP報文中的0021可被壓縮爲21。實施者必須能夠接收這兩種情況（壓縮或沒有被壓縮）的報文。
13. PPP LCP協商中的ACFC選項有什麼意義？
ACFC（Address-and-Control-Field-Compression地址控制域壓縮）選項是用來協商PPP報文的地址、控制域是否可以被壓縮。壓縮後地址域和控制域會被省略。LCP報文不能進行地址控制域壓縮。
14. MP LCP協商中的MRRU選項有什麼意義？
MRRU（Multilink Maximum Received Reconstructed Unit MP最大接收重構單元）選項可用來通知對端本端要實施MP，這個選項的值是指接收端重組後的MP報文的最大值。這個選項的確認與拒絕主要用來確定對端是否支持MP鏈路的使用。該選項被拒絕後，則該通道不能作爲MP鏈路使用，而只能作爲普通PPP鏈路使用。
15. MP鏈路上的MTU是如何計算的？
一般MP鏈路上的MTU的取值依據下面的公式：
MINMRU=MIN（本端MRU，對端MRU）
MINMRRU=MIN（本端MRRU，對端MRRU）
MTU=MIN(配置MTU，MIN（MINMRU，MINMRRU）)
如果MP通道是PPPoE之類的鏈路，MP MTU還要考慮底層的MTU，會更復雜一些。