章節回顧：
《TCP/IP詳解卷1：協議》第3章 IP：網際協議（1）-讀書筆記
《TCP/IP詳解卷1：協議》第3章 IP：網際協議（2）-讀書筆記
《TCP/IP詳解卷1：協議》第4章 ARP：地址解析協議-讀書筆記
《TCP/IP詳解卷1：協議》第5章 RARP：逆地址解析協議-讀書筆記
《TCP/IP詳解卷1：協議》第6章 ICMP：Internet控制報文協議-讀書筆記
《TCP/IP詳解卷1：協議》第11章 UDP：使用者資料包協議-讀書筆記
《TCP/IP詳解卷1：協議》第17、18章 TCP：傳輸控制協議（1）-讀書筆記
《TCP/IP詳解卷1：協議》第17、18章 TCP：傳輸控制協議（2）-讀書筆記
《TCP/IP詳解卷1：協議》第19章 TCP的互動資料流-讀書筆記
1、引言
從圖1-4可以看出，在TCP/IP協議族中，鏈路層主要有三個目的：
（1）為IP模組傳送和接收IP資料包；
（2）為ARP模組傳送ARP請求和接收ARP應答。
（3）為RARP傳送RARP請求和接收RARP應答。
TCP/IP支援多種不同的鏈路層協議，這取決於網路所使用的硬體，如乙太網、令牌環網、FDDI（光纖分散式資料介面）及RS-232序列線路等。
2、乙太網和IEEE 802封裝
（1）乙太網
乙太網一般是指數字裝置公司(Digital Equipment Corp.)、英特爾和Xerox公司在1982年聯合公佈的一個標準。它是當今TCP/IP採用的主要的區域網技術，它採用一種稱作CSMA/CD的媒體接入方法，意思是帶衝突檢測的載波偵聽多路接入。它的速率為10Mb/s，地址為48 bit。
（2）IEEE 802封裝
IEEE 802委員會公佈了一個稍有不同的標準集，其中802.3針對整個CSMA/CD網路，802.4針對令牌匯流排網路，802.5針對令牌環網路。這三者的共同特性由802.2標準來定義，那就是802網路共有的邏輯鏈路控制（LLC）。
注意：IEEE 802.2和802.3定義了一個與乙太網不同的幀格式。
（3）相關RFC文件
在TCP/IP中，乙太網IP資料包的封裝是在RFC 894中定義的。IEEE 802網路的IP資料包封裝是在RFC 1042中定義的。
主機需求RFC要求每臺Internet主機都與一個10Mb/s的乙太網電纜相連線：
1）必須能傳送和接收採用RFC 894（乙太網）封裝格式的分組。
2）應該能接收與RFC 894混合的RFC 1042（IEEE 802）封裝格式的分組。
3）也許能夠傳送採用RFC 1042格式封裝的分組。
最常使用的封裝格式是RFC 894定義的格式。圖2-1顯示了兩種不同形式的封裝格式。
兩種封裝格式的說明：
（1）兩種幀格式都採用48bit（6位元組）的目的地址和源地址（802.3允許使用16 bi的地址，但一般是48 bi地址），稱為硬體地址。ARP和RARP協議對32 bi的IP地址和48 bit的硬體地址進行對映。
（2）在802標準定義的幀格式中，長度欄位是指它後續資料的位元組長度，但不包括CRC檢驗碼。乙太網的型別欄位定義了後續資料的型別。
（3）在乙太網幀格式中，型別欄位之後就是資料；而在802幀格式中，跟隨在後面的是3位元組的802.2 LLC和5位元組的802.2 SNAP。
（4）CRC欄位用於幀內後續位元組差錯的迴圈冗餘碼檢驗（檢驗和）。
（5）802.3標準定義的幀和乙太網的幀都有最小長度要求。802.3規定資料部分必須至少為38位元組，而對於乙太網，則要求最少要有46位元組。
3、SLIP：序列線路IP
SLIP的全稱是Serial Line IP。它是一種在序列線路上對IP資料包進行封裝的簡單形式。SLIP適用於家庭中每臺計算機幾乎都有的RS-232串列埠和高速調變解調器接入Internet。下面的規則描述了SLIP協議定義的幀格式：
（1） IP資料包以一個稱作END（0xc0）的特殊字元結束。同時，為了防止資料包到來之前的線路噪聲被當成資料包內容，大多數實現在資料包的開始處也傳一個END字元。
（2）如果IP報文中某個字元為END，那麼就要連續傳輸兩個位元組0xdb和0xdc來取代它。0xdb這個特殊字元被稱作SLI的ESC字元。
（3）如果IP報文中某個字元為SLIP的ESC字元，那麼就要連續傳輸兩個位元組0xdb和0xdd來取代它。
圖2-2中的例子就是含有一個END字元和一個ESC字元的IP報文。
SLIP是一種簡單的幀封裝方法，值得一提的缺陷：
（1） 每一端必須知道對方的IP地址。沒有辦法把本端的IP地址通知給另一端。
（2）資料幀中沒有型別欄位（類似於乙太網中的型別欄位）。如果一條序列線路用於SLIP，那麼它不能同時使用其他協議。
（3）SLIP沒有在資料幀中加上檢驗和（類似於乙太網中的CRC欄位）。如果SLIP傳輸報文被線路噪聲影響而發生錯誤，只能通過上層協議來發現。
儘管存在這些缺點，SLIP仍然是一種廣泛使用的協議。
4、壓縮的SLIP
由於序列線路的速率通常較低（19200b/s或更低），而且通訊經常是互動式的，因此在SLIP線路上有許多小的TCP分組進行交換。為了傳送1個位元組的資料需要20個位元組的IP首部和20個位元組的TCP首部，總數超過40個位元組。
提出一個被稱作CSLIP（壓縮SLIP）的新協議，它一般能把上面的40個位元組壓縮到3或5個位元組。它能在CSLIP的每一端維持多達16個TCP連線，並且知道其中每個連線的首部中的某些欄位一般不會發生變化。對於那些發生變化的欄位，大多數只是一些小的數字和的改變。這些被壓縮的首部大大地縮短了互動響應時間。
5、PPP：點對點協議
PPP點對點協議修改了SLIP協議中的所有缺陷。包括三個部分：
（1）在序列鏈路上封裝IP資料包的方法。PPP既支援資料為8位和無奇偶檢驗的非同步模式，還支援面向位元的同步連結。
（2）建立、配置及測試資料鏈路的鏈路控制協議（LCP：Link Control Protocol）。它允許通訊雙方進行協商，以確定不同的選項。
（3）針對不同網路層協議的網路控制協議（NCP：Network Control Protocol）體系。
圖2-3是PPP資料幀的格式。
（1）每一幀都以標誌字元0x7e開始和結束。緊接著是一個地址位元組，值始終是0xff，然後是一個值為0x03的控制位元組。
（2）協議欄位，類似於乙太網中型別欄位的功能。當它的值為0x0021時，表示資訊欄位是一個 IP資料包；值為0xc021時，表示資訊欄位是鏈路控制資料；值為0x8021時，表示資訊欄位是網路控制資料。
（3）CRC欄位（或FCS，幀檢驗序列）是一個迴圈冗餘檢驗碼，以檢測資料幀中的錯誤。
（4）標誌字元0x7e出現在資訊欄位中時，PPP需要對它進行轉義。
總的來說，PPP比SLIP具有下面這些優點：
（1）PPP支援在單根序列線路上執行多種協議，不只是IP協議；
（2）每一幀都有迴圈冗餘檢驗；
（3）通訊雙方可以進行IP地址的動態協商(使用IP網路控制協議)；
（4）與CSLIP類似，對TCP和IP報文首部進行壓縮；
（5）鏈路控制協議可以對多個資料鏈路選項進行設定。
為這些優點付出的代價是在每一幀的首部增加3個位元組，當建立鏈路時要傳送幾幀協商資料，以及更為複雜的實現。
6、環回介面
大多數產品都支援環回介面，以允許執行在同一臺主機上的客戶程式和伺服器程式通過TCP/IP進行通訊。A類網路號127就是為環回介面預留的，大多數系統把IP地址127.0.0.1分配給這個介面，並命名為localhost。一個傳給環回介面的IP資料包不能在任何網路上出現。
一旦傳輸層檢測到目的端地址是環回地址時，應該可以省略部分傳輸層和所有網路層的邏輯操作。但是大多數的產品還是照樣完成傳輸層和網路層的所有過程，只是當IP資料包離開網路層時把它返回給自己。圖2-4是環回介面處理IP資料包的簡單過程。
圖2-4的說明：
（1）傳給環回地址（一般是127.0.0.1）的任何資料均作為IP輸入。
（2）傳給廣播地址或多播地址的資料包復制一份傳給環回介面，然後送到乙太網上。這是因為廣播傳送和多播傳送的定義包含主機本身。
（3）任何傳給該主機IP地址的資料均送到環回介面。
（4）環回介面可以被看作是網路層下面的另一個鏈路層。網路層把一份資料包傳送給環回介面，就像傳給其他鏈路層一樣，只不過環回介面把它返回到IP的輸入佇列中。從圖2-4可以看出，送給主機本身IP地址的IP資料包一般不出現在相應的網路上。
7、最大傳輸單元MTU
乙太網和802.3對資料幀的長度都有一個限制，其最大值分別是1500和1492位元組。鏈路層的這個特性稱作MTU，最大傳輸單元。不同型別的網路大多數都有一個上限。如果IP層有一個資料包要傳，而且資料的長度比鏈路層的MTU還大，那麼IP層就需要進行分片，把資料包分成若干片，這樣每一片都小於MTU。
8、路徑MTU
當在同一個網路上的兩臺主機互相進行通訊時，該網路的MTU是非常重要的。但是如果兩臺主機之間的通訊要通過多個網路，那麼每個網路的鏈路層就可能有不同的MTU。重要的不是兩臺主機所在網路的MTU的值，重要的是兩臺通訊主機路徑中的最小MTU。它被稱作路徑MTU。
兩臺主機之間的路徑MTU不一定是個常數。它取決於當時所選擇的路由。而選路不一定是對稱的（從A到B的路由可能與從B到A的路由不同），因此路徑MTU在兩個方向上不一定是一致的。
9、序列線路吞吐量計算
如果線路速率是9600b/s，而一個位元組有8bit，加上一個起始位元和一個停止位元，那麼線路的速率就是960B/s（位元組/秒）。以這個速率傳輸一個1024位元組的分組需要1066ms。如果用SLIP連結執行一個互動式應用程式，同時還執行另一個應用程式如FTP傳送或接收1024位元組的資料，那麼一般來說就必須等待一半的時間（533ms）才能把互動式應用程式的分組資料傳送出去。
對於互動應用來說，等待533ms是不能接受的。研究表明，互動響應時間超過100~200ms就被認為是不好的，這是傳送一份互動報文出去後，直到接收到響應資訊（通常是出現一個回顯字元）為止的往返時間。
注意：我們對平均等待時間的計算（傳輸最大資料幀所需時間的一半）只適用於SLIP鏈路（或PPP鏈路）在互動通訊和大塊資料傳輸這兩種情況下。