章節回顧：
《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鏈路）在交互通信和大塊數據傳輸這兩種情況下。