某年某月某一天，我在WLW上寫了半篇沒CTRL+S的博文 深研《TCP/IP詳解卷1》——鏈路層，突然間室友做飯搞個功率很大的電磁鍋弄的跳閘了，停電了！於是一段很長的篇幅就這樣被這無情的斷電給抹殺了。。能做的只有：從頭再來！
TCP/IP協議的分層封裝實現使得每一層看起來像是完全獨立特行的，以至於我們可以認爲不同主機間每一層的數據傳遞直接是兩個同層的傳遞，這意味着我們可以完全忽視所有中間過程而把注意力集中在我們關注的層次；比如兩個不同主機間鏈路層的幀傳遞我們僅需要關注這一層即可，以至於底下的物理層線路怎麼去傳遞的，可以完全不用關心。對於鏈路層而言，其主要作用有三點：
（1）接收和發送IP層傳來的數據；
（2）爲ARP模塊接收應答和發送ARP請求；
（3）爲RARP模塊接收RARP應答和發送RARP請求；
ARP和RARP是兩種比較重要的地址解析協議，在此先將其視爲同IP層在一個層次的協議向下發送或向上傳遞（鏈路層）數據，相應的鏈路層對其進行應答。既然鏈路層要發送和接收數據，它就必須對數據進行處理：即封裝成符合要求的幀；鏈路層比較常見的兩種處理協議時：SLIP協議和PPP協議。對於PPP協議倒是個很熟悉的字眼了。而令我一直不解的是：國內絕大部分大學計算機網絡教科書中對於現今依然普遍使用的SLIP協議卻隻字不提，亦或許僅僅是所謂的大綱要求吧。。 鏈路層各種協議都遵循3個基本原則：封裝成幀，差錯檢測和透明傳輸；以下會詳細探討，我的文章不會按照卷一書中的的講解順序去記錄每個知識點，搞不懂緣何TCP/IP的作者總是提前提出很多未知名詞並大加引用，到了之後的章節才進行這種名詞解釋的寫作習慣，MTU就是個很好的例證，它在本章節近乎最後的地方纔解釋，卻在之前用過很多次了：
MTU（最大傳輸單元）
每種鏈路層協議都會規定其所限定的最大傳輸數據段長度，這便是MTU。以太網和RFC 802.3分別對MTU值的限定是：1500和1492字節（注意這並不意味着MTU只能是這麼大），當IP層傳下來的數據段或從底層獲取的數據段大於這個長度時，這便會造就幀丟失的情況。所以IP層在想下層傳遞數據時，必須先將數據進行分片。至於具體分片原則會在後續有關IP層的章節說明。
原則1：分裝成幀
將數據封裝成幀即在一段數據的前後分別加上幀頭SOF和幀尾EOT，以此便形成了完整的幀。如下圖所示（真實的幀結構比這複雜些，在此說明3個原理時進行了簡化處理，以下2個原則不再進行說明）：
特別注意MTU並非指幀的最大長度，通常而言是指除掉幀頭和幀尾之外的中間數據最大長度。由於數據有了開始和結束符，於是在傳送過程中若是突然出現了中斷，那麼可能會出現只有幀頭沒有幀尾的情況，如此的話當數據傳送到下一個數據鏈路時由於檢測到不是一個完整的幀，便可以直接扔掉此幀。
原則2：透明傳輸
現在假定，SOH和EOT的編碼都是0XEE，那麼如果所要傳送的數據部分出現了一個0XEE，這便會出現幀邊界出錯的情況，如下圖所示：
鏈路層在處理數據時會誤把數據部分的SOH(OXEE)當成是界定符來處理，於是後面的部分數據部分SOH後面部分便會被丟掉而沒有傳輸。爲了處理這種幀由於數據部分出現幀邊界的情況，於是就引入了類似C語言中轉義字符的處理方式。C語言中的轉義字符爲“\”，在這裏我們假定用ESC來充當這種轉義字符，那麼在數據部分便會被處理成如下這樣的格式：
這樣的話，當數據傳送到下個數據鏈路層進行處理的時候，每讀到一個ESC，其後的SOH就不會被認定爲一個界定符了。倘若數據段中也出現一個純內容的ESC呢？處理方式也類似，即直接在其前面增加一個ESC字符，當下一個數據鏈路層接收到兩個ESC字符時，便會刪除其中一個。
原則3：差錯檢測
實際的幀結構比上面的要複雜些，可能會如下所示（卷一原圖）：
這是RFC 802.3規定的幀結構，除了數據段外，不僅僅只有幀頭和幀尾那麼簡單。目前我們只需關心最後的CRC段，這部分由4個字節表示，是通過一種CRC運算得出的檢驗碼，對於CRC運算的具體方法其實比較簡單，在此我不進行詳述，可以去看看（這裏）。 其本質類似於我們平時對一些數據進行MD5加密，只不過CRC運算的結果肯定爲0，當接收端接收到數據後使用同樣的方式進行檢測，得到的結果若爲0則證明傳輸沒有出現差錯，如果不爲0則肯定出現了差錯，於是丟掉當前幀。這樣的話，可以看到鏈路層的這種檢錯傳輸機制保證了傳輸到目的主機的幀肯定是正確的（因爲錯誤的幀都會被丟棄）。
SLIP協議
這種協議的用途在卷一中一筆帶過，百度百科對其解釋是“SLIP（Serial Line Internet Protocol，串行線路網際協議），該協議是Windows遠程訪問的一種舊工業標準，主要在Unix遠程訪問服務器中使用，現今仍然用於連接某些 ISP。因爲SLIP協議是面向低速串行線路的，可以用於專用線路，也可以用於撥號線路，Modem的傳輸速率在1200bps到19200bps”。
事實上，這是種比較簡單的協議，其基本結構類似於在上述 原則2 中講解的結構，對幀的處理方式也一樣，但沒有目標地址，沒有CRC段，也沒有類型段，於是便出現了以下三個缺點：
（1）沒有辦法把本端的IP地址通知給另一端；
（2）沒有辦法進行幀校驗，如果傳輸過程中可能由於線路噪聲而改變了某些數據的值（把0變爲1或1變爲0），這些校驗工作也必須由鏈路層的上層來完成；
（3）由於沒有類型段，所以一條線路不能同時傳送SLIP和其它類型的鏈路層協議（如PPP），因爲不同協議對幀的封裝方式不同，造就同一個數據傳送段被封裝成不同的幀，倘若一條用於SLIP傳送的線路同時傳送SLIP和PPP協議的幀類型，那麼到達目的主機的鏈路層後便全部當做SLIP協議的幀封裝格式進行解析，所造就的後果不堪設想。
CSLIP協議（壓縮的SLIP協議）
假如我們需要用SLIP協議傳送一個字節數據的幀，那麼經過上層（IP層和運輸層）的處理後，最終到達鏈路層的數據會達40個字節，其實主要是加些協議首部，後續章節會詳述。CSLIP協議通過某種壓縮處理把通常數據段較小的SLIP協議壓縮成很簡短的幀，從而大大提高了傳輸效率。在這裏40個字節或許會被壓縮成3到5個字節進行傳輸，從而大大提高了運行效率。而今基本所有的SLIP協議的產品均支持CSLIP協議。
PPP協議（點對點協議）
相較於SLIP的所有缺點而言，PPP協議則沒有任何其所具有的缺點。通常我們通過撥號連接於某個ISP（internet service provider，互聯網服務提供商，如電信）連接時，便用到這個協議。對於PPP協議的幀結構如下圖：
開始和結尾的標誌字段便是前面原則１所說的SOF和EOT了，固定爲0XFF。地址段和控制段均是固定的0XFF和0X03。而協議段通常用來指定數據段的類型，0X0021表示爲IP數據報，0XC021表示鏈路控制數據，0X8021表示網絡控制數據。
同樣的，PPP協議也遵循 原則2；相較於SLIP而言，其所具有的優勢如下：
（1）由於協議段的存在，其支持在單根串行線路上傳輸多種協議，不只是IP協議；
（2）有了CRC校驗，保證了數據傳輸的正確性；
（3）與CSLIP類似，可以對幀進行壓縮處理；
環回接口（LookBack接口）
卷一種並沒有詳細說明環回接口的原理，只是單純的說明了其進行數據傳送時所經過的線路原則。環回接口通常只是個虛接口（IP地址），由於一個路由器有多個接口，如果其中一個接口中斷了連接，則可以通過其它接口來訪問這個路由器。若爲一個路由器選擇一個接口作爲其唯一標示，而這些物理接口又可能會隨時DOWN掉，於是得重新選擇一個接口作爲其ID。環回接口就是用來標示一個路由器的唯一ID，可進行手動指定，不會隨物理接口狀態的變化而變化。
之所以把環回接口也放到鏈路層是因爲其所充當的角色類似於一個鏈路層。當網絡層把一個數據傳送到一個環回接口時，通常會出現以下三種情況：
（1）傳給環回地址的數據直接會被返回到IP輸入隊列中，即直接會傳送到IP層；
（2）傳給廣播或多播地址的數據通常會複製一份到環回接口（即傳給自己），因爲廣播或多播定義本身包含主機本身；
（3）任何傳給當前主機IP地址的數據均送到環回接口。
事實上，如果一個主機在給自己傳送數據，那麼這些數據永遠不會被傳送到網絡上，因爲很多以太網設備驅動都不能都回它們發出去的數據。這也便要求一個主機必須能處理自己發送出去的數據。
鏈路層，到此結束！
今晚的風，好涼快……