某年某月某一天，我在WLW上寫了半篇沒CTRL+S的博文 深研《TCP/IP詳解卷1》——鏈路層，突然間室友做飯搞個功率很大的電磁鍋弄的跳閘了，停電了！于是一段很長的篇幅就這樣被這無情的斷電給抹殺了。。能做的只有：從頭再來！

TCP/IP協(xié)議的分層封裝實現(xiàn)使得每一層看起來像是完全獨立特行的，以至于我們可以認(rèn)為不同主機(jī)間每一層的數(shù)據(jù)傳遞直接是兩個同層的傳遞，這意味著我們可以完全忽視所有中間過程而把注意力集中在我們關(guān)注的層次；比如兩個不同主機(jī)間鏈路層的幀傳遞我們僅需要關(guān)注這一層即可，以至于底下的物理層線路怎么去傳遞的，可以完全不用關(guān)心。對于鏈路層而言，其主要作用有三點：

（1）接收和發(fā)送IP層傳來的數(shù)據(jù)；

（2）為ARP模塊接收應(yīng)答和發(fā)送ARP請求；

（3）為RARP模塊接收RARP應(yīng)答和發(fā)送RARP請求；

ARP和RARP是兩種比較重要的地址解析協(xié)議，在此先將其視為同IP層在一個層次的協(xié)議向下發(fā)送或向上傳遞（鏈路層）數(shù)據(jù)，相應(yīng)的鏈路層對其進(jìn)行應(yīng)答。既然鏈路層要發(fā)送和接收數(shù)據(jù)，它就必須對數(shù)據(jù)進(jìn)行處理：即封裝成符合要求的幀；鏈路層比較常見的兩種處理協(xié)議時：SLIP協(xié)議和PPP協(xié)議。對于PPP協(xié)議倒是個很熟悉的字眼了。而令我一直不解的是：國內(nèi)絕大部分大學(xué)計算機(jī)網(wǎng)絡(luò)教科書中對于現(xiàn)今依然普遍使用的SLIP協(xié)議卻只字不提，亦或許僅僅是所謂的大綱要求吧。。 鏈路層各種協(xié)議都遵循3個基本原則：封裝成幀，差錯檢測和透明傳輸；以下會詳細(xì)探討，我的文章不會按照卷一書中的的講解順序去記錄每個知識點，搞不懂緣何TCP/IP的作者總是提前提出很多未知名詞并大加引用，到了之后的章節(jié)才進(jìn)行這種名詞解釋的寫作習(xí)慣，MTU就是個很好的例證，它在本章節(jié)近乎最后的地方才解釋，卻在之前用過很多次了：

MTU（最大傳輸單元）

每種鏈路層協(xié)議都會規(guī)定其所限定的最大傳輸數(shù)據(jù)段長度，這便是MTU。以太網(wǎng)和RFC 802.3分別對MTU值的限定是：1500和1492字節(jié)（注意這并不意味著MTU只能是這么大），當(dāng)IP層傳下來的數(shù)據(jù)段或從底層獲取的數(shù)據(jù)段大于這個長度時，這便會造就幀丟失的情況。所以IP層在想下層傳遞數(shù)據(jù)時，必須先將數(shù)據(jù)進(jìn)行分片。至于具體分片原則會在后續(xù)有關(guān)IP層的章節(jié)說明。

原則1：分裝成幀

將數(shù)據(jù)封裝成幀即在一段數(shù)據(jù)的前后分別加上幀頭SOF和幀尾EOT，以此便形成了完整的幀。如下圖所示（真實的幀結(jié)構(gòu)比這復(fù)雜些，在此說明3個原理時進(jìn)行了簡化處理，以下2個原則不再進(jìn)行說明）：

特別注意MTU并非指幀的最大長度，通常而言是指除掉幀頭和幀尾之外的中間數(shù)據(jù)最大長度。由于數(shù)據(jù)有了開始和結(jié)束符，于是在傳送過程中若是突然出現(xiàn)了中斷，那么可能會出現(xiàn)只有幀頭沒有幀尾的情況，如此的話當(dāng)數(shù)據(jù)傳送到下一個數(shù)據(jù)鏈路時由于檢測到不是一個完整的幀，便可以直接扔掉此幀。

原則2：透明傳輸

現(xiàn)在假定，SOH和EOT的編碼都是0XEE，那么如果所要傳送的數(shù)據(jù)部分出現(xiàn)了一個0XEE，這便會出現(xiàn)幀邊界出錯的情況，如下圖所示：

鏈路層在處理數(shù)據(jù)時會誤把數(shù)據(jù)部分的SOH(OXEE)當(dāng)成是界定符來處理，于是后面的部分?jǐn)?shù)據(jù)部分SOH后面部分便會被丟掉而沒有傳輸。為了處理這種幀由于數(shù)據(jù)部分出現(xiàn)幀邊界的情況，于是就引入了類似C語言中轉(zhuǎn)義字符的處理方式。C語言中的轉(zhuǎn)義字符為“\”，在這里我們假定用ESC來充當(dāng)這種轉(zhuǎn)義字符，那么在數(shù)據(jù)部分便會被處理成如下這樣的格式：

這樣的話，當(dāng)數(shù)據(jù)傳送到下個數(shù)據(jù)鏈路層進(jìn)行處理的時候，每讀到一個ESC，其后的SOH就不會被認(rèn)定為一個界定符了。倘若數(shù)據(jù)段中也出現(xiàn)一個純內(nèi)容的ESC呢？處理方式也類似，即直接在其前面增加一個ESC字符，當(dāng)下一個數(shù)據(jù)鏈路層接收到兩個ESC字符時，便會刪除其中一個。

原則3：差錯檢測

實際的幀結(jié)構(gòu)比上面的要復(fù)雜些，可能會如下所示（卷一原圖）：

這是RFC 802.3規(guī)定的幀結(jié)構(gòu)，除了數(shù)據(jù)段外，不僅僅只有幀頭和幀尾那么簡單。目前我們只需關(guān)心最后的CRC段，這部分由4個字節(jié)表示，是通過一種CRC運(yùn)算得出的檢驗碼，對于CRC運(yùn)算的具體方法其實比較簡單，在此我不進(jìn)行詳述，可以去看看（這里）。 其本質(zhì)類似于我們平時對一些數(shù)據(jù)進(jìn)行MD5加密，只不過CRC運(yùn)算的結(jié)果肯定為0，當(dāng)接收端接收到數(shù)據(jù)后使用同樣的方式進(jìn)行檢測，得到的結(jié)果若為0則證明傳輸沒有出現(xiàn)差錯，如果不為0則肯定出現(xiàn)了差錯，于是丟掉當(dāng)前幀。這樣的話，可以看到鏈路層的這種檢錯傳輸機(jī)制保證了傳輸?shù)侥康闹鳈C(jī)的幀肯定是正確的（因為錯誤的幀都會被丟棄）。

SLIP協(xié)議

這種協(xié)議的用途在卷一中一筆帶過，百度百科對其解釋是“SLIP（Serial Line Internet Protocol，串行線路網(wǎng)際協(xié)議），該協(xié)議是Windows遠(yuǎn)程訪問的一種舊工業(yè)標(biāo)準(zhǔn)，主要在Unix遠(yuǎn)程訪問服務(wù)器中使用，現(xiàn)今仍然用于連接某些 ISP。因為SLIP協(xié)議是面向低速串行線路的，可以用于專用線路，也可以用于撥號線路，Modem的傳輸速率在1200bps到19200bps”。

事實上，這是種比較簡單的協(xié)議，其基本結(jié)構(gòu)類似于在上述 原則2 中講解的結(jié)構(gòu)，對幀的處理方式也一樣，但沒有目標(biāo)地址，沒有CRC段，也沒有類型段，于是便出現(xiàn)了以下三個缺點：

（1）沒有辦法把本端的IP地址通知給另一端；

（2）沒有辦法進(jìn)行幀校驗，如果傳輸過程中可能由于線路噪聲而改變了某些數(shù)據(jù)的值（把0變?yōu)?或1變?yōu)?），這些校驗工作也必須由鏈路層的上層來完成；

（3）由于沒有類型段，所以一條線路不能同時傳送SLIP和其它類型的鏈路層協(xié)議（如PPP），因為不同協(xié)議對幀的封裝方式不同，造就同一個數(shù)據(jù)傳送段被封裝成不同的幀，倘若一條用于SLIP傳送的線路同時傳送SLIP和PPP協(xié)議的幀類型，那么到達(dá)目的主機(jī)的鏈路層后便全部當(dāng)做SLIP協(xié)議的幀封裝格式進(jìn)行解析，所造就的后果不堪設(shè)想。

CSLIP協(xié)議（壓縮的SLIP協(xié)議）

假如我們需要用SLIP協(xié)議傳送一個字節(jié)數(shù)據(jù)的幀，那么經(jīng)過上層（IP層和運(yùn)輸層）的處理后，最終到達(dá)鏈路層的數(shù)據(jù)會達(dá)40個字節(jié)，其實主要是加些協(xié)議首部，后續(xù)章節(jié)會詳述。CSLIP協(xié)議通過某種壓縮處理把通常數(shù)據(jù)段較小的SLIP協(xié)議壓縮成很簡短的幀，從而大大提高了傳輸效率。在這里40個字節(jié)或許會被壓縮成3到5個字節(jié)進(jìn)行傳輸，從而大大提高了運(yùn)行效率。而今基本所有的SLIP協(xié)議的產(chǎn)品均支持CSLIP協(xié)議。

PPP協(xié)議（點對點協(xié)議）

相較于SLIP的所有缺點而言，PPP協(xié)議則沒有任何其所具有的缺點。通常我們通過撥號連接于某個ISP（internet service provider，互聯(lián)網(wǎng)服務(wù)提供商，如電信）連接時，便用到這個協(xié)議。對于PPP協(xié)議的幀結(jié)構(gòu)如下圖：

開始和結(jié)尾的標(biāo)志字段便是前面原則１所說的SOF和EOT了，固定為0XFF。地址段和控制段均是固定的0XFF和0X03。而協(xié)議段通常用來指定數(shù)據(jù)段的類型，0X0021表示為IP數(shù)據(jù)報，0XC021表示鏈路控制數(shù)據(jù)，0X8021表示網(wǎng)絡(luò)控制數(shù)據(jù)。

同樣的，PPP協(xié)議也遵循 原則2；相較于SLIP而言，其所具有的優(yōu)勢如下：

（1）由于協(xié)議段的存在，其支持在單根串行線路上傳輸多種協(xié)議，不只是IP協(xié)議；

（2）有了CRC校驗，保證了數(shù)據(jù)傳輸?shù)恼_性；

（3）與CSLIP類似，可以對幀進(jìn)行壓縮處理；

環(huán)回接口（LookBack接口）

卷一種并沒有詳細(xì)說明環(huán)回接口的原理，只是單純的說明了其進(jìn)行數(shù)據(jù)傳送時所經(jīng)過的線路原則。環(huán)回接口通常只是個虛接口（IP地址），由于一個路由器有多個接口，如果其中一個接口中斷了連接，則可以通過其它接口來訪問這個路由器。若為一個路由器選擇一個接口作為其唯一標(biāo)示，而這些物理接口又可能會隨時DOWN掉，于是得重新選擇一個接口作為其ID。環(huán)回接口就是用來標(biāo)示一個路由器的唯一ID，可進(jìn)行手動指定，不會隨物理接口狀態(tài)的變化而變化。

之所以把環(huán)回接口也放到鏈路層是因為其所充當(dāng)?shù)慕巧愃朴谝粋€鏈路層。當(dāng)網(wǎng)絡(luò)層把一個數(shù)據(jù)傳送到一個環(huán)回接口時，通常會出現(xiàn)以下三種情況：

（1）傳給環(huán)回地址的數(shù)據(jù)直接會被返回到IP輸入隊列中，即直接會傳送到IP層；

（2）傳給廣播或多播地址的數(shù)據(jù)通常會復(fù)制一份到環(huán)回接口（即傳給自己），因為廣播或多播定義本身包含主機(jī)本身；

（3）任何傳給當(dāng)前主機(jī)IP地址的數(shù)據(jù)均送到環(huán)回接口。

事實上，如果一個主機(jī)在給自己傳送數(shù)據(jù)，那么這些數(shù)據(jù)永遠(yuǎn)不會被傳送到網(wǎng)絡(luò)上，因為很多以太網(wǎng)設(shè)備驅(qū)動都不能都回它們發(fā)出去的數(shù)據(jù)。這也便要求一個主機(jī)必須能處理自己發(fā)送出去的數(shù)據(jù)。

鏈路層，到此結(jié)束！

今晚的風(fēng)，好涼快……

本文出自 “酋長 ” 博客，請務(wù)必保留此出處http://clement.blog.51cto.com/2235236/957843