久久一区精品,国产精品秒播无毒不卡,最新中文乱码字字幕在线

TCP/IP詳解
1 概述
1.1 引言
　很多不同的廠家生產各種型號的計算機，它們運行完全不同的操作系統，但TCP/IP協議組件允許它們互相進行通信。這一點很讓人感到吃驚，因為它的作用已遠遠超出了起初的設想。TCP/IP起源于60年代末美國政府資助的一個分組交換網絡研究項目，到現在90年代已發展成為計算機之間最常應用的組網形式。它是一個真正的開放系統，因為協議組件的定義及其多種實現可以不用花錢或花很少的錢就可以公開地得到。它成為被稱作“全球互聯網”或“因特網”(Internet)的基礎，該廣域網（WAN）已包含超過100萬臺遍布世界各地的計算機。
　本章主要對TCP/IP協議組件進行概述，其目的是為本書其余章節提供充分的背景知識。如果讀者要從歷史的角度了解有關TCP/IP的早期發展情況，請參考文獻[Lynch 1993]。
1.2 分層
　網絡協議通常分不同層次進行開發，每一層分別負責不同的通信功能。一個協議組件，比如TCP/IP，是一組不同層次上的多個協議的組合。TCP/IP通常被認為是一個四層協議系統，如圖1.1所示。
圖1.1 TCP/IP協議組件的四個層次
每一層負責不同的功能：
　　1. 鏈路層，有時也稱作數據鏈路層或網絡接口層，通常包括操作系統中的設備驅動程序和計算機中對應的網絡接口卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細節。
　　2. 網絡層，有時也稱作互連網層，處理分組在網絡中的活動，例如分組的路由選擇。在TCP/IP協議組件中，網絡層協議包括IP協議（網際協議），ICMP協議（Internet互連網控制報文協議），以及IGMP協議（Internet組管理協議）。
　　3. 運輸層主要為兩臺主機上的應用程序提供端到端的通信。在TCP/IP協議組件中，有兩個互不相同的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。
　 TCP為兩臺主機提供高可靠性的數據通信。它所做的工作包括把應用程序交給它的數據分成合適的小塊交給下面的網絡層，確認接收到的分組，設置發送最后確認分組的超時時鐘等。由于運輸層提供了高可靠性的端到端的通信，因此應用層可以忽略所有這些細節。
　而另一方面，UDP則為應用層提供一種非常簡單的服務。它只是把稱作數據報的分組從一臺主機發送到另一臺主機，但并不保證該數據報能到達另一端。任何必需的可靠性必須由應用層來提供。
　這兩種運輸層協議分別在不同的應用程序中有不同的用途，這一點我們將在后面看到。
　　4. 應用層負責處理特定的應用程序細節。幾乎各種不同的TCP/IP實現都會提供下面這些通用的應用程序：
　　　．Telnet 遠程登錄
　　?。瓼TP 文件傳輸協議
　　　．SMTP 用于電子郵件的簡單郵件傳輸協議
　　?。甋NMP 簡單網絡管理協議
　另外還有許多其他應用，我們在后面章節中將介紹其中的一部分。
　假設我們在一個局域網（LAN）如以太網中有兩臺主機，二者都運行FTP協議，圖1.2列出了該過程所涉及到的所有協議。
圖1.2　局域網上運行FTP的兩臺主機
　這里，我們列舉了一個FTP客戶程序和另一個FTP服務器程序。大多數的網絡應用程序都被設計成客戶－服務器模式。服務器為客戶提供某種服務，在本例中就是訪問服務器所在主機上的文件。在遠程登錄應用程序Telnet中，為客戶提供的服務是登錄到服務器主機上。
　在同一層上，雙方都有對應的一個或多個協議進行通信。例如，某個協議允許TCP層進行通信，而另一個協議則允許兩個IP層進行通信。
　在圖1.2的右邊，我們注意到應用程序通常是一個用戶進程，而下三層則一般在（操作系統）內核中執行。盡管這不是必需的，但通常都是這樣處理的，例如UNIX操作系統。
　在圖1.2中，頂層與下三層之間還有另一個關鍵的不同之處。應用層關心的是應用程序的細節，而不是數據在網絡中的傳輸活動。下三層對應用程序一無所知，但它們要處理所有的通信細節。
　我們在圖1.2中例舉了四種不同層次上的協議。FTP是一種應用層協議，TCP是一種運輸層協議，IP是一種網絡層協議，而以太網協議則應用于鏈路層上。TCP/IP協議組件是一組不同的協議組合在一起構成的協議族。盡管通常稱該協議組件為TCP/IP，但TCP和IP只是其中的兩種協議而已。（該協議組件的另一個名字是Internet協議族(Internet Protocol Suite)。
　網絡接口層和應用層的目的是很顯然的──前者處理有關通信媒介的細節（以太網，令牌環網等），而后者處理某個特定的用戶應用程序（FTP，Telnet等）。但是，從表面上看，網絡層和運輸層之間的區別不那么明顯。為什么要把它們劃分成兩個不同的層次呢？為了理解這一點，我們必須把視野從單個網絡擴展到一組網絡。
　在80年代，網絡不斷增長的原因之一是大家都意識到只有一臺孤立的計算機構成的“孤島”沒有太大意義，于是就把這些孤立的系統組在一起形成網絡。隨著這樣的發展，到了90年代，我們又逐漸認識到這種由單個網絡構成的新的更大的“島嶼”同樣沒有太大的意義。于是，人們又把多個網絡連在一起形成一個網絡的網絡，或稱作互連網(internet)。一個互連網就是一組通過相同協議族互連在一起的網絡。
　構造互連網最簡單的方法是把兩個或多個網絡通過路由器進行連接。它是一種特殊的用于網絡互連的硬件盒。路由器的好處是為不同類型的物理網絡提供連接：以太網，令牌環網，點對點的鏈接，FDDI（光纖分布式數據接口）等等。
（下面是原書p.4①的譯文）
　　這些盒子也稱作IP路由器（IP Routers），但我們這里使用路由器(Router)這個術語。
從歷史上說，這些盒子稱作網關（gateways），在很多TCP/IP文獻中都使用這個術語。現在網關這個術語只用來表示應用層網關：一個連接兩種不同協議組件的進程（例如，TCP/IP和IBM的SNA），它為某個特定的應用程序服務（常常是電子郵件或文件傳輸）。
　圖1.3是一個包含兩個網絡的互連網：一個以太網和一個令牌環網，通過一個路由器互相連接。盡管這里是兩臺主機通過路由器進行通信，實際上以太網中的任何主機都可以與令牌環網中的任何主機進行通信。
　　在圖1.3中，我們可以劃分出端系統（end system）（兩邊的兩臺主機）和中間系統（intermediate system）（中間的路由器）。應用層和運輸層使用端到端（end-to-end）協議。在我們的圖中，只有端系統需要這兩層協議。但是，網絡層提供的卻是逐跳（hop-by-hop）協議，兩個端系統和每個中間系統都要使用它。
圖1.3　通過路由器連接的兩個網絡
　在TCP/IP協議組件中，網絡層IP提供的是一種不可靠的服務。也就是說，它只是盡可能快地把分組從源結點送到目的結點，但是并不提供任何可靠性保證。而另一方面，TCP在不可靠的IP層上提供了一個可靠的運輸層。為了提供這種可靠的服務，TCP采用了超時重傳，發送和接收端到端的確認分組等機制。由此可見，運輸層和網絡層分別負責不同的功能。
　從定義上看，一個路由器具有兩個或多個網絡接口層（因為它連接了兩個或多個網絡）。任何具有多個接口的系統英文都稱作是多接口的multihomed。一個主機也可以有多個接口，但一般不稱作路由器, 除非它的功能只是單純地把分組從一個接口傳送到另一個接口。同樣，路由器并不一定指那種在互連網中用來轉發分組的特殊硬件盒。大多數的TCP/IP實現也允許一個多接口主機來擔當路由器的功能，但是主機為此必須進行特殊的配置。在這種情況下，我們既可以稱該系統為主機（當它運行某一應用程序時，如FTP或Telnet），也可以稱之為路由器（當它把分組從一個網絡轉發到另一個網絡時）。我們在不同的場合下使用不同的術語。
　互連網的目標之一是在應用程序中隱藏所有的物理細節。雖然這一點在圖1.3由兩個網絡組成的互連網中并不很明顯，但是應用層不能關心（也不關心）一臺主機是在以太網上，而另一臺主機是在令牌環網上，它們通過路由器進行互連。隨著增加不同類型的物理網絡，可能會有20個路由器，但應用層仍然是一樣的。物理細節的隱藏使得互連網功能非常強大，也非常有用。
　連接網絡的另一個途徑是使用網橋。網橋是在鏈路層上對網絡進行互連，而路由器則是在網絡層上對網絡進行互連。網橋使得多個局域網（LAN）組合在一起，這樣對上層來說就好像是一個局域網。
　　TCP /IP傾向于使用路由器而不是網橋來連接網絡，因此我們將著重介紹路由器。文獻[Perlman 1992]的第12章對路由器和網橋進行了比較。
1.3 TCP/IP的分層
　在TCP/IP協議組件中，有很多種協議。圖1.4給出了本書將要討論的其他協議。
圖1.4 TCP/IP協議組件中不同層次的協議
　 TCP和UDP是兩種最為著名的運輸層協議，二者都使用IP作為網絡層協議。
　雖然TCP使用不可靠的IP服務，但它卻提供一種可靠的運輸層服務。本書第17章到第22章將詳細討論TCP的內部操作細節。然后，我們將介紹一些TCP的應用，如第26章中的Telnet和Rlogin，第27章中的FTP，以及第28章中的SMTP等。這些應用通常都是用戶進程。
　 UDP為應用程序發送和接收數據報。一個數據報是指從發送方傳輸到接收方的一個信息單元（例如，發送方指定的一定字節數的信息）。但是與TCP不同的是，UDP是不可靠的，它不能保證數據報能安全無誤地到達最終目的。本書第11章將討論UDP，然后在第14章（域名系統：Domain Name System），第15章（簡單文件傳輸協議Trivial File Transfer Protocol），以及第16章（引導程序協議Bootstrap Protocol）介紹使用UDP的應用程序。SNMP（簡單網絡管理協議）也使用了UDP協議，但是由于它還要處理許多其他的協議，因此本書把它留到第25章再進行討論。
　 IP是網絡層上的主要協議，同時被TCP和UDP使用。TCP和UDP的每組數據都通過端系統和每個中間路由器中的IP層在互連網中進行傳輸。在圖1.4中，我們給出了一個直接訪問IP的應用程序。這是很少見的，但也是可能的。（一些較老的路由選擇協議就是以這種方式來實現的。當然新的運輸層協議也有可能試用這種方式。）第3章主要討論IP協議，但是為了使內容更加有針對性，一些細節將留在后面的章節中進行討論。第9章和第10章討論IP如何進行路由選擇。
　 ICMP是IP協議的附屬協議。IP層用它來與其他主機或路由器交換錯誤報文和其他重要信息。第6章對ICMP的有關細節進行討論。盡管ICMP主要被IP使用，但應用程序也有可能訪問它。我們將分析兩個流行的診斷工具，Ping和Traceroute（第7章和第8章），它們都使用了ICMP。
　 IGMP是Internet組管理協議。它用來把一個UDP數據報多播到多個主機。我們在第12章中描述廣播（把一個UDP數據報發送到某個指定網絡上的所有主機）和多點傳送的一般特性，然后在第13章中對IGMP協議本身進行描述。
　 ARP（地址解析協議）和RARP（逆地址解析協議）是某些網絡接口（如以太網和令牌環網）使用的特殊協議，用來轉換IP層和網絡接口層使用的地址。我們分別在第4章和第5章對這兩種協議進行分析和介紹。
1.4 互連網的地址
　互連網上的每個接口必須有一個唯一的Internet地址（也稱作IP地址）。IP地址長32 bit。Internet地址并不采用平面形式的地址空間，如1，2，3等。IP地址具有一定的結構，五類不同的互連網地址格式如圖1.5所示。
　這些32位的地址通常寫成四個十進制的數，其中每個整數對應一個字節。這種表示方法稱作“點分十進制表示法”（dotted decimal notation）。例如，作者的系統就是一個B類地址，它表示為：140.252.13.33。
　區分各類地址的最簡單方法是看它的第一個十進制整數。圖1.6列出了各類地址的起止范圍，其中第一個十進制整數用加黑字體表示。
圖1.5五類互連網地址
圖1.6 各類IP地址的范圍
　需要再次指出的是，多接口主機具有多個IP地址，其中每個接口都對應一個IP地址。
由于互連網上的每個接口必須有一個唯一的IP地址，因此必須要有一個管理機構為接入互連網的網絡分配IP地址。這個管理機構就是互連網絡信息中心（Internet Network Information Centre）稱作InterNIC。InterNIC只分配網絡號。主機號的分配由系統管理員來負責。
（下面是原書p.8①的譯文）
　 Internet注冊服務(IP地址和DNS域名)過去由NIC來負責，其網絡地址是nic.ddn.mil。1993年4月1日，InterNIC成立?，F在，NIC只負責處理國防數據網的注冊請求，所有其他的Internet用戶注冊請求均由InterNIC負責處理，其網址是：rs.internic.net。
事實上InterNIC有三部分組成：注冊服務（rs.internic.net），目錄和數據庫服務（ds.internic.net），以及信息服務（is.internic.net）。有關InterNIC的其他信息參見習題1.8。
　有三類IP地址：單目傳送地址（目標為單個主機），廣播傳送地址（目的端為給定網絡上的所有主機），以及多目傳送地址（目的端為同一組內的所有主機）。第12章和第13章將分別討論廣播傳送和多目傳送的更多細節。
　在3.4節中，我們在介紹IP路由選擇以后將進一步介紹子網的概念。圖3.9給出了幾個特殊的IP地址：主機號和網絡號為全0或全1。
1.5 域名系統
　盡管通過IP地址可以識別主機上的網絡接口，進而訪問主機，但是人們最喜歡使用的還是主機名。在TCP/IP領域中，域名系統（DNS）是一個分布的數據庫，由它來提供IP地址和主機名之間的映射信息。我們在第14章將詳細討論DNS。
　現在，我們必須理解，任何應用程序都可以調用一個標準的庫函數來查看給定名字的主機的IP地址。類似地，系統還提供一個逆函數──給定主機的IP地址，查看它所對應的主機名。
　大多數使用主機名作為參數的應用程序也可以把IP地址作為參數。例如，在第4章中當我們用Telnet進行遠程登錄時，我們既可以指定一個主機名，也可以指定一個IP地址。
1.6 封裝
　當應用程序用TCP傳送數據時，數據被送入協議棧中，然后逐個通過每一層直到被當作一串比特流送入網絡。其中每一層對收到的數據都要增加一些首部信息（有時還要增加尾部信息），該過程如圖1.7所示。TCP傳給IP的數據單元稱作TCP報文段或簡稱為TCP段（TCP segment）。IP傳給網絡接口層的數據單元稱作IP數據報(IP datagram)。通過以太網傳輸的比特流稱作幀(frame)。
　圖1.7中幀頭和幀尾下面所標注的數字是典型以太網幀首部的字節長度。在后面的章節中我們將詳細討論這些幀頭的具體含義。
　以太網數據幀的物理特性是其長度必須在46－1500字節之間。我們將在4.5節遇到最小長度的數據幀，在2.8節中遇到最大長度的數據幀。
（下面是原書p.9①的譯文）
　所有的Internet標準和大多數有關TCP/IP的書都使用octet這個術語來表示字節。使用這個過分雕琢的術語是有歷史原因的，因為TCP/IP的很多工作都是在DEC-10系統上進行的，但是它并不使用8 bit的字節。由于現在幾乎所有的計算機系統都采用8 bit的字節，因此我們在本書中使用字節（byte）這個術語。
　更準確地說，圖1.7中IP和網絡接口層之間傳送的數據單元應該是分組（packet）。分組既可以是一個IP數據報，也可以是IP數據報的一個片（fragment）。我們將在11.5節討論IP數據報分片的詳細情況。
　 UDP數據與TCP數據基本一致。唯一的不同是UDP傳給IP的信息單元稱作UDP數據報（UDP datagram），而且UDP的首部長為8字節。

圖1.7　數據進入協議棧時的封裝過程
　回想第6頁中的圖1.4，由于TCP，UDP，ICMP和IGMP都要向IP傳送數據，因此IP必須在生成的IP首部中加入某種標識，以表明數據屬于哪一層。為此，IP在首部中存入一個長度為8比特的數值，稱作協議域。1表示為ICMP協議，2表示為IGMP協議，6表示為TCP協議，17表示為UDP協議。
　類似地，許多應用程序都可以使用TCP或UDP來傳送數據。運輸層協議在生成報文首部時要存入一個應用程序的標識符。TCP和UDP都用一個16 bit的端口號來表示不同的應用程序。TCP和UDP把源端口號和目的端口號分別存入報文首部中。
　網絡接口分別要發送和接收IP，ARP和RARP數據，因此也必須在以太網的幀首部中加入某種形式的標識，以指明生成數據的網絡層協議。為此，以太網的幀首部也有一個16 bit的幀類型域。
1.7 分用（Demultiplexing）
　當目的主機收到一個以太網數據幀時，數據就開始從協議棧中由底向上升，同時去掉各層協議加上的報文首部。每層協議盒都要去檢查報文首部中的協議標識，以確定接收數據的上層協議。這個過程稱作分用，圖1.8顯示了該過程是如何發生的。
圖1.8　以太網數據幀的分用過程
（下面是原書p.11①的譯文）
　為協議ICMP和IGMP定位一直是一件很棘手的事情。在圖1.4中，我們把它們與IP放在同一層上，那是因為事實上它們是IP的附屬協議。但是在這里，我們又把它們放在IP層的上面，這是因為ICMP和IGMP報文都被封裝在IP數據報中。
　對于ARP和RARP我們也遇到類似的難題。在這里我們把它們放在以太網設備驅動程序的上方，這是因為它們和IP數據報一樣，都有各自的以太網數據幀類型。但在圖2.4中，我們又把ARP作為以太網設備驅動程序的一部分，放在IP層的下面，其原因在邏輯上是合理的。
　當進一步描述TCP的細節時，我們將看到協議確實是通過目的端口號，源IP地址和源端口號進行解包的。
1.8 客戶服務器模型
　大部分網絡應用程序在編寫時都假設一端是客戶，另一端是服務器，其目的是為了讓服務器為客戶提供一些特定的服務。
　我們可以將這種服務分為兩種類型：重復型或并發型。重復型服務器通過以下步驟進行交互：
I1. 等待一個客戶請求的到來。
I2. 處理客戶請求。
I3. 發送響應給發送請求的客戶。
I4. 返回I1步驟。
重復型服務器主要的問題發生在I2狀態。在這個時候，它不能為其他客戶機提供服務。
相應地，并發型服務器采用以下步驟：
C1. 等待一個客戶請求的到來
C2. 啟動一個新的服務器來處理這個客戶的請求。在這期間可能生成一個新的進程、任務或線程，并依賴底層操作系統的支持。這個步驟如何進行取決于操作系統。生成的新服務器對客戶的全部請求進行處理。處理結束后，終止這個新服務器。
C3.返回C1步驟。
　并發服務器的優點在于它是利用生成其他服務器的方法來處理客戶的請求。也就是說，每個客戶都有它自己對應的服務器。如果操作系統允許多任務，那么就可以同時為多個客戶同時服務。
　我們對服務器，而不是對客戶進行分類的原因是因為對于一個客戶來說，它通常并不能夠辨別自己是與一個重復型服務器或并發型服務器進行對話。
　一般來說，TCP服務器是并發的，而UDP服務器是重復的，但也存在一些例外。我們將在11.12節對UDP對其服務器產生的影響進行詳細討論，并在18.11節對TCP對其服務器的影響進行討論。
1.9 端口號
　我們前面已經指出過，TCP和UDP采用16比特的端口號來識別應用程序。那么這些端口號是如何選擇的呢？
　服務器一般都是通過人們所熟知的端口號來識別的。例如，對于每個TCP/IP實現來說，FTP服務器的TCP端口號都是21，每個Telnet服務器的TCP端口號都是23，每個TFTP(簡單文件傳輸協議)服務器的UDP端口號都是69。任何TCP/IP實現所提供的服務都用眾所周知的1－1023之間的端口號。這些人們所熟知的端口號由Internet端口號分配機構（Internet Assigned Numbers Authority, IANA）來管理。
（下面是原書p.13①的譯文）
　到1992年為止，人們所熟知的端口號介于1－255之間。256－1023之間的端口號通常都是由Unix系統占用，以提供一些特定的Unix服務──也就是說，提供一些只有Unix系統才有的，而其他操作系統可能不提供的服務?，F在IANA管理1－1023之間所有的端口號。
Internet擴展服務與Unix特定服務之間的一個差別就是Telnet和Rlogin。它們二者都允許我們通過計算機網絡登錄到其他主機上。Telnet是采用端口號為23的TCP/IP標準且幾乎可以在所有操作系統上進行實現。相反，Rlogin最開始時只是為Unix系統設計的（盡管許多非Unix系統現在也提供該服務），因此在80年代初，它的有名端口號為513。
　客戶端通常對它所使用的端口號并不關心，只需保證該端口號在本機上是唯一的就可以了?？蛻舳丝谔栍址Q作臨時端口號（即存在時間很短暫）。這是因為它通常只是在用戶運行該客戶程序時才存在，而服務器則只要主機開著的，其服務就運行。
　大多數TCP/IP實現給臨時端口分配1024－5000之間的端口號。大于5000的端口號是為其他服務器預留的（Internet上并不常用的服務)。我們可以在后面看見許多這樣的給臨時端口分配端口號的例子。
（下面是原書p.13②的譯文）
Solaris 2.2是一個很有名的例外。通常TCP和UDP的缺省臨時端口號從32768開始。在E.4節中，我們將詳細描述系統管理員如何對配置選項進行修改以改變這些缺省項。
大多數Unix系統的file/etc/services都包含了人們熟知的端口號。為了找到Telnet服務器和域名系統的端口號，我們可以運行以下語句：
（見原書p.13的③）
保留端口號
　 Unix系統有保留端口號的概念。只有具有超級用戶特權的進程才允許給它自己分配一個保留端口號。
　這些端口號介于1到1023之間，一些應用程序（如有名的Rlogin，26.2節）將它作為客戶與服務器之間身份認證的一部分。
1.10 標準化過程
　究竟是誰控制著TCP/IP協議組件，又是誰在定義新的標準以及其他類似的事情？事實上，有四個小組在負責Internet技術。
　　1. Internet協會（ISOC: Internet Society）是一個推動、支持和促進Internet不斷增長和發展的專業組織，它把Internet作為全球研究通信的基礎設施。
　　2. Internet體系結構委員會（IAB：Internet Architecture Board）是一個技術監督和協調的機構。它由國際上來自不同專業的15個志愿者組成，其職能是負責Internet標準的最后編輯和技術審核。IAB隸屬于ISOC。
　　3. Internet工程專門小組（IETF：Internet Engineering Task Force）是一個面向近期標準的組織，它分為9個領域（應用，尋徑和尋址，安全等等）。IETF開發成為Internet標準的規約。為幫助IETF主席，又成立了Internet工程指導小組（IESG：Internet Engineering Steering Group）。
　　4. Internet研究專門小組主要對長遠的項目進行研究。
　　IRTF和IETF都隸屬于IAB。文獻[Crocker 1993]提供了關于Internet內部標準化進程更為詳細的信息，同時還介紹了它的早期歷史。
1.11 RFC
　　所有關于Internet的正式標準都以RFC（Request for Comment）文檔出版。另外，大量的RFC并不是正式的標準，出版的目的只是為了提供信息。RFC的篇幅從1頁到200頁不等。每一項都用一個數字來標識，如RFC 1122，數字越大說是RFC的內容越新。
所有的RFC都可以通過電子郵件或用FTP從Internet上免費獲取。如果發送下面這份電子郵件，你就會收到一份獲取RFC的方法清單：
To: rfc-info@ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
　最新的RFC索引總是搜索信息的起點。這個索引列出了RFC被替換或局部更新的時間。
下面是一些重要的RFC文檔：
　　1. 賦值RFC（Assigned Numbers RFC）列出了所有Internet協議中使用的數字和常數。至本書出版時為止，最新RFC的編號是1340 [Reynolds and Postel 1992]。所有著名的Internet端口號都列在這里。
　當這個RFC被更新時（通常每年至少更新一次），索引清單會列出RFC 1340被替換的時間?！　　?
　　2. Internet正式協議標準，目前是RFC 1600[Postel 1994]。這個RFC描述了各種Internet協議的標準化現狀。每種協議都處于下面幾種標準化狀態之一：標準，草案標準，提議標準，實驗標準，信息標準，和歷史標準。另外，對每種協議都有一個要求的層次：必需的，建議的，可選擇的，限制使用的，或者不推薦的。
　與賦值RFC一樣，這個RFC也定期更新。請一定隨時查看最新版本。
　　3. 主機需求RFC，1122和1123[Braden 1989a, 1989b]。RFC 1122針對鏈路層，網絡層和運輸層，RFC 1123針對應用層。這兩個RFC對早期重要的RFC文檔作了大量的糾正和解釋。如果要查看有關協議更詳細的細節內容，它們通常是一個入口點。它們列出了協議中關于“必須”，“應該”，“可以”，“不應該”或者“不能”等特性及其實現細節。
　　文獻[Borman 1993b]提供了有關這兩個RFC的實用內容。RFC 1127[Braden 1989c]對工作小組開發主機需求RFC過程中的討論內容和結論進行了非正式的總結。
　　4．路由器需求RFC，目前正式版是RFC 1009[Braden and Postel 1987]，但一個新版已接近完成[Aknqyust 1993]。它與主機需求RFC類似，但是只單獨描述了路由器的需求。
1.12 標準的簡單服務
　有一些標準的簡單服務幾乎每種實現都要提供。在本書中我們將使用其中的一些服務程序，而客戶程序通常選擇Telnet。圖1.9描述了這些服務。從該圖我們可以看出，當使用TCP和UDP提供相同的服務時，一般選擇相同的端口號.
（下面是原書p.15①的譯文）
　如果仔細檢查這些標準的簡單服務以及其他標準的TCP/IP服務（如Telnet, FTP, SMTP等）的端口號時，我們發現它們都是奇數。這是有歷史原因的，因為這些端口號都是從NCP端口號派生出來的。（NCP，即網絡控制協議，是ARPANET的運輸層協議，是TCP的前身。NCP是單工的，不是全雙工的，因此每個應用程序需要兩個連接，需預留一對奇數和偶數端口號。當TCP和UDP成為標準的運輸層協議時，每個應用程序只需要一個端口號，因此就使用了NCP中的奇數。
（以下是原書p.16圖1.9的譯文）
名字
TCP端口號
UDP端口號
RFC
描述
echo
7
7
862
服務器返回客戶發送的所有內容。
discard
9
9
863
服務器丟棄客戶發送的所有內容。
daytime
13
13
867
服務器以可讀形式返回時間和日期。
chargen
19
19
864
當客戶發送一個數據報時，TCP服務器發送一串連續的字符流，直到客戶中斷連接。UDP服務器發送一個隨機長度的數據報。
time
37
37
868
服務器返回一個二進制形式的32 bit數，表示從UTC時間1900年1月1日午夜至今的秒數。
圖1.9 大多數實現都提供的標準的簡單服務
1.13 互連網
　在圖1.3中，我們列舉了一個由兩個網絡組成的互連網－一個以太網和一個令牌環網。在1.4節和1.9節中，我們討論了世界范圍內的互連網－Internet，以及集中分配IP地址的需要（InterNIC），還討論了著名的端口號（IANA）。internet這個詞第一個字母是否大寫決定了它具有不同的含義。
　 internet意思是用一個共同的協議族把多個網絡連接在一起。而Internet指的是世界范圍內通過TCP/IP互相通信的所有主機集合（超過100萬臺）。Internet是一個internet（互連網），但internet不等于Internet。
1.14 實現
　既成事實標準的TCP/IP軟件實現來自于位于伯克利的加利福尼亞大學的計算機系統研究小組。從歷史上看，軟件是隨同4.x BSD系統（Berkeley Software Distribution）的網絡版一起發布的。它的源代碼是許多其他實現的基礎。
　圖1.10列舉了各種BSD版本發布的時間，并標注了重要的TCP/IP特性。列在左邊的BSD網絡版，其所有的網絡源代碼可以公開得到：包括協議本身以及許多應用程序和工具（如Telnet和FTP）。
　　在本書中，我們將使用“伯克利派生系統”來指SunOS 4.x, SVR4, 以及AIX 3.2等那些基于伯克利源代碼開發的系統。這些系統有很多共同之處，經常包含相同的錯誤。
（以下是原書p.17圖1.10的譯文）
　　　　　 4.2BSD (1983) 第一個廣泛可用的TCP/IP發布
　　　　　　　　　　　　　　　　 4.3BSD (1986)　TCP性能得到改善
　　　　　　　　　　　　　　　　 4.3BSD Tahoe (1988) 啟動慢，擁塞避免措施
BSD網絡軟件1.0版(1989)：Net/1　
　　　　4.3BSD Reno(1990) TCP首部預測，SLIP首部壓縮
　　　　路由表修改
BSD網絡軟件2.0版(1991)：Net/2
　　　　4.4BSD(1993) 多播，長胖管道修改
4.4BSD-Lite (1994)
又稱為Net/3
圖1.10 不同的BSD版及其重要的TCP/IP特性
　起初關于Internet的很多研究現在仍然在伯克利系統中應用－新的擁塞控制算法（21.7節），多目傳送（12.4節），“又長又胖的管道”修改（24.3節），以及其他類似的研究。
1.15 應用編程接口
　使用TCP/IP協議的應用程序通常采用兩種應用編程接口（API）：socket和TLI（運輸層接口：Transport Layer Interface）。前者有時稱作“Berkeley socket”，表明它是從伯克利版發展而來的。后者起初是由AT&T開發的，有時稱作XTI（X/Open傳輸接口），以承認X/Open這個自己定義標準的國際計算機生產產商所做的工作。XTI實際上是TLI的一個超集。
本書不是一本編程方面的書，但是偶爾會引用一些內容來說明TCP/IP的特性，不管大多數的API（socket）是否提供它們。所有關于socket和TLI的編程細節請參閱文獻[Stevens 1990]。
1.16　測試網絡
　圖1.11是本書中所有的例子運行的測試網絡。為閱讀時參考方便，該圖還復制在本書的封面內側。
圖1.11 本書例子運行的測試網絡，所有的IP地址均從140.252開始編址。
　在這個圖中（作者的子網），大多數的例子都運行在下面四個系統中。圖中所有的IP地址屬于B類地址，網絡號為140.252。所有的主機名屬于.tuc.noao.edu這個域。（noao代表National Optical Astronomy Observatories，tuc代表Tucson）。例如，右下方的系統有一個完整的名字: svr4.tuc.noao.edu，其IP地址是：140.252.13.34。每個方框上方的名稱是該主機運行的操作系統。這一組系統和網絡上的主機及路由器運行于不同的TCP/IP實現。
　需要指出的是，noao.edu這個域中的網絡和主機要比圖1.11中的多得多。這里列出來的只是本書中將要用到的系統。
　在3.4節中，我們將描述這個網絡所用到的子網形式，在4.6中我們將更介紹sun與netb之間的拔號SLIP的有關細節。2.4節將詳細討論SLIP。
1.17　小結
　本章快速地瀏覽了TCP/IP協議族，介紹了我們在后面的章節中將要詳細討論的許多術語和協議。
　 TCP/IP協議族分為四層：鏈路層，網絡層，運輸層和應用層，每一層各有不同的責任。在TCP/IP中，網絡層和運輸層之間的區別是最為關鍵的：網絡層（IP）提供點到點的服務，而運輸層（TCP和UDP）提供端到端的服務。
　一個互連網是網絡的網絡。構造互連網的共同基石是路由器，它們在IP層把網絡連在一起。第一個字母大寫的Internet是指分布在世界各地的大型互連網，其中包括1萬多個網絡和超過100萬臺主機。
　在一個互連網上，每個接口都用IP地址來標識，盡管用戶習慣使用主機名而不是IP地址。域名系統為主機名和IP地址之間提供動態的映射。端口號用來標識互相通信的應用程序。服務器使用眾所周知的端口號，而客戶使用臨時設定的端口號。

習題
1.1 請計算最多有多少個A類、B類和C類網絡號。
1.2 用匿名FTP（見27.3節）從主機nic.merit.edu 上獲取文件nsfnet/statistics/history.netcount。該文件包含在NSFNET網絡上登記的國內和國外的網絡數。畫一坐標系，橫坐標代表年，縱坐標代表網絡總數的對數值?？v坐標的最大值是習題1.1的結果。如果數據顯示一個明顯的趨勢，請估計按照當前的編址體制推算，何時會用完所有的網絡地址。（3.10節討論解決該難題的建議。）
1.3 獲取一份主機需求RFC拷貝[Braden 1989a]，閱讀有關應用于TCP/IP協議族每一層的穩健性原則。這個原則的參考對象是什么？
1.4 獲取一份最新的賦值RFC拷貝?！皅uote of the day"協議的有名端口號是什么？哪個RFC對該協議進行了定義？
1.5 如果你有一個接入TCP/IP互連網的主機帳號，它的主IP地址是多少？這臺主機是否接入了Internet？它是多接口主機嗎？
1.6 獲取一份RFC 1000的拷貝，了解RFC這個術語從何而來。
1.7 與Internet協會聯系， isoc@isoc.org 或者+1 703 648 9888，了解有關加入的情況。
1.8 用匿名FTP從主機is.internic.net處獲取文件about-internic/information-about-the-internic。
1－1
2 鏈路層
2.1 引言
　從圖1.4我們可以看出，在TCP/IP協議族中，鏈路層主要有三個目的：（1）為IP模塊發送和接收IP數據報；（2）為ARP模塊發送ARP請求和接收ARP應答；（3）為RARP發送RARP請求和接收RARP應答。TCP/IP支持多種不同的鏈路層協議，這取決于網絡所使用的硬件，如以太網，令牌環網，FDDI（光纖分布式數據接口），RS－232串行線路等。
　在本章中，我們將詳細討論以太網鏈路層協議，兩個串行接口鏈路層協議（SLIP和PPP），以及大多數實現都包含的環回（loopback）驅動程序。以太網和SLIP是本書中大多數例子使用的鏈路層。我們對MTU（最大傳輸單元）進行了介紹，這個概念在本書的后面章節中將多次遇到。我們還討論了如何為串行線路選擇MTU。
2.2 以太網和IEEE 802封裝
　　以太網這個術語一般是指數字設備公司（Digital Equipment Corp.）、英特爾公司（Intel Corp.）、和Xerox公司聯合在1982年公布的一個標準。它是當今TCP/IP采用的主要的局域網技術。它采用一種稱作CSMA/CD的媒體接入方法，其意思是載波偵聽多路接入/沖突檢測（Carrier Sense, Multiple Access with Collision Detection）。它的速率為10 Mb/s，地址為48 bit。
　幾年后，IEEE（電子電氣工程師協會）802委員會公布了一個稍有不同的標準集，其中802.3針對了整個CSMA/CD網絡，802.4針對令牌總線網絡，802.5針對令牌環網絡。這三者的共同特性由802.2標準來定義，那就是802網絡共有的邏輯鏈路控制（LLC）。不幸的是，802.2和802.3定義了一個與以太網不同的幀格式。文獻[Stallings 1987]對所有的IEEE 802標準進行了詳細的介紹。
　　在TCP/IP世界中，以太網IP數據報的封裝是在RFC 894[Hornig 1984]中定義的，IEEE 802網絡的IP數據報封裝是在RFC 1042[Postel and Reynolds 1988]中定義的。主機需求RFC要求每臺Internet主機都與一個10Mbit/s的以太網電纜相連接：
　　1. 必須能發送和接收采用RFC 894（以太網）封裝格式的分組。
　　2. 應該能接收與RFC 894混合的RFC 1042（IEEE 802）封裝格式的分組。
　　3. 也許能夠發送采用RFC 1042格式封裝的分組。如果主機能同時發送兩種類型的分組數據，那么發送的分組必須是可以設置的，而且默認條件下必須是RFC 894分組。
　　最常使用的封裝格式是RFC 894定義的格式。圖2.1顯示了兩種不同形式的封裝格式。圖中每個方框下面的數字是它們的字節長度。
　　兩種幀格式都采用48 bit（6字節）的目標地址和源地址。（802.3允許使用16 bit的地址，但一般是48 bit地址。）這就是我們在本書中所稱的硬件地址。ARP和RARP協議（第4章和第5章）對32 bit的IP地址和48 bit的硬件地址進行映射。
　接下來的2個字節在兩種幀格式中互不相同。在802標準定義的幀格式中，長度字段是指它后續數據的字節長度，但不包括CRC檢驗碼。以太網的類型字段定義了后續數據的類型。在802標準定義的幀格式中，類型字段則由后續的子網接入協議（Sub-network Access Protocol，SNAP）的首部給出。幸運的是，802定義的有效長度值與以太網的有效類型值無一相同，這樣，就可以對兩種幀格式進行區分。
　在以太網幀格式中，類型字段之后就是數據，而在802幀格式中，跟隨在后面的是3字節的802.2 LLC和5字節的802.2 SNAP。目的服務訪問點（Destination Service Access Point, DSAP）和源服務訪問點（Source Service Access Point, SSAP）的值都設為0xaa。ctrl字段的值設為3。隨后的3個字節org code都置為0。再接下來的2個字節類型字段和以太網幀格式一樣。（其他類型字段值可以參見RFC 1340 [Reynolds and Postel 1992]）。
　 CRC字段用于幀內后續字節差錯的循環冗余碼檢驗（檢驗和）。（它也被稱為FCS或幀檢驗序列）
　 802.3標準定義的幀和以太網的幀都有最小長度要求。802.3規定數據部分必須至少為38字節，而對于以太網，則要求最少要有46字節。為了保證這一點，必須在不足的空間插入填充（pad）字節。我們在開始觀察線路上的分組時將遇到這種最小長度的情況。
　在本書中，我們在需要的時候將給出以太網的封裝格式，因為這是最為常見的封裝格式。
圖2.1 IEEE 802.2/802.3（RFC 1042）和以太網的封裝格式（RFC 894）
2.3 尾部封裝
　　RFC 893[Leffler and Karels 1984]描述了另一種用于以太網的封裝格式，稱作尾部封裝（trailer encapsulation）。這是一個早期BSD系統在DEC VAX機上運行時的試驗格式，它通過調整IP數據報中字段的次序來提高性能。在以太網數據幀中，開始的那部分是變長的字段（IP首部和TCP首部）。把它們移到尾部（在CRC之前），這樣當把數據復制到內核時，就可以把數據幀中的數據部分映射到一個硬件頁面，節省內存到內存的復制過程。TCP數據報的長度是512字節的整數倍，正好可以用內核中的頁表來處理。兩臺主機通過協商使用ARP擴展協議對數據幀進行尾部封裝。這些數據幀需定義不同的以太網幀類型值。
　現在，尾部封裝已遭到反對，因此我們不對它舉任何例子。有興趣的讀者請參閱RFC 893以及文獻[Leffler et al. 1989]的11.8節。
2.4 SLIP：串行線路IP
　　SLIP的全稱是Serial Line IP。它是一種在串行線路上對IP數據報進行封裝的簡單形式，在RFC 1055[Romkey 1988]中有詳細描述。SLIP適用于家庭中每臺計算機幾乎都有的RS-232串行端口和高速調制解調器接入Internet。
　　下面的規則描述了SLIP協議定義的幀格式：
　 1．IP數據報以一個稱作END（0xc0）的特殊字符結束。同時，為了防止數據報到來之前的線路噪聲被當成數據報內容，大多數實現在數據報的開始處也傳一個END字符。（如果有線路噪聲，那么END字符將結束這份錯誤的報文。這樣當前的報文得以正確的傳輸，而前一個錯誤報文交給上層后，會被發現其內容毫無意義而被丟棄。）
　 2．如果IP報文中某個字符為END，那么就要連續傳輸兩個字節0xdb, 0xdc來取代它。0xdb這個特殊字符被稱作SLIP的ESC字符，但是它的值與ASCII碼的ESC字符（0x1b）不同。
　　3．如果IP報文中某個字符為SLIP的ESC字符，那么就要連續傳輸兩個字節0xdb,0xdd來取代它。
　圖2.2中的例子就是含有一個END字符和一個ESC字符的IP報文。在這個例子中，在串行線路上傳輸的總字節數是原IP報文長度再加4個字節。
　 SLIP是一種簡單的幀封裝方法，還有一些值得一提的缺陷：
　　1. 每一端必須知道對方的IP地址。沒有辦法把本端的IP地址通知給另一端。
　　2. 數據幀中沒有類型字段（類似于以太網中的類型字段）。如果一條串行線路用于SLIP，那么它不能同時使用其他協議。
　　3. SLIP沒有在數據幀中加上檢驗和（類似于以太網中的CRC字段）。如果SLIP傳輸的報文被線路噪聲影響而發生錯誤，只能通過上層協議來發現。（另一種方法是，新型的調制解調器可以檢測并糾正錯誤報文。）這樣，上層協議提供某種形式的CRC就顯得很重要。在第3章和第17章中，我們將看到IP首部和TCP首部及其數據始終都有檢驗和。在第11章中，我們將看到UDP首部及其數據的檢驗和卻是可選的。
圖2.2 SLIP報文的封裝
　盡管存在這些缺點，SLIP仍然是一種廣泛使用的協議。
（下面是原書p.25①的譯文）
　　SLIP的歷史要追溯到1984年，Rick Adams第一次在4.2BSD系統中實現。盡管它本身的描述是一種非標準的協議，但是隨著調制解調器的速率和可靠性的提高，SLIP越來越流行。現在，它的許多產品可以公開獲得，而且很多產家都支持這種協議。
2.5 壓縮的SLIP
　　由于串行線路的速率通常較低（19200 b/s或更低），而且通信經常是交互式的（如Telnet和Rlogin，二者都使用TCP），因此在SLIP線路上有許多小的TCP分組進行交換。為了傳送1個字節的數據需要20個字節的IP首部和20個字節的TCP首部，總數超過40個字節。（19.2節描述了Rlogin會話過程中，當敲入一個簡單命令時這些小報文傳輸的詳細情況。）
　既然承認這些性能上的缺陷，于是人們提出一個被稱作CSLIP（即壓縮SLIP）的新協議，它在RFC 1144[Jacobson 1990a]中被詳細描述。CSLIP一般能把上面的40個字節壓縮到3或5個字節。它能在CSLIP的每一端維持多達16個TCP連接，并且知道其中每個連接的首部中的某些字段一般不會發生變化。對于那些發生變化的字段，大多數只是一些小的數字和的改變。這些被壓縮的首部大大地縮短了交互響應時間。
（下面是原書p.25②的譯文）
　現在大多數的SLIP產品都支持CSLIP。作者所在的子網（參見封面內頁）中有兩條SLIP鏈路，它們均是CSLIP鏈路。
2.6　PPP：點對點協議
　 PPP，點對點協議修改了SLIP協議中的所有缺陷。PPP包括以下三個部分：
　 1．在串行鏈路上封裝IP數據報的方法。PPP既支持數據為8位和無奇偶檢驗的異步模式（如大多數計算機上都普遍存在的串行接口），還支持面向比特的同步鏈接。
　 2．建立、配置及測試數據鏈路的鏈路控制協議（LCP：Link Control Protocol）。它允許通信雙方進行協商，以確定不同的選項。
　 3．針對不同網絡層協議的網絡控制協議（NCP：Network Control Protocol）體系。當前RFC定義的網絡層有IP，OSI網絡層，DECnet，以及AppleTalk。例如，IP NCP允許雙方商定是否對報文首部進行壓縮，類似于CSLIP。（縮寫詞NCP也可用在TCP的前面）。
　　RFC 1548[Simpson 1993]描述了報文封裝的方法和鏈路控制協議。RFC 1332[McGregor 1992]描述了針對IP的網絡控制協議。
　 PPP數據幀的格式看上去很像ISO的HDLC（高層數據鏈路控制）標準。圖2.3是PPP數據幀的格式。
圖2.3 PPP數據幀的格式
　每一幀都以標志字符0x7e開始和結束。緊接著是一個地址字節，值始終是0xff，然后是一個值為0x03的控制字節。
　接下來是協議字段，類似于以太網中類型字段的功能。當它的值為0x0021時表示信息字段是一個IP數據報，值為0xc021時表示信息字段是鏈路控制數據，值為0x8021時表示信息字段是網絡控制數據。
　 CRC字段（或FCS，幀校驗序列）是一個循環冗余檢驗碼，以檢測數據幀中的錯誤。
　由于標志字符的值是0x7e，因此當該字符出現在信息字段中時，PPP需要對它進行轉義。在同步鏈路中，該過程是通過一種稱作比特填充(bit stuffing)的硬件技術來完成的[Tanenbaum 1989]。在異步鏈路中，特殊字符0x7d用作轉義字符。當它出現在PPP數據幀中時，那么緊接著的字符的第六個比特要取其補碼，具體實現過程如下：
　　1. 當遇到字符0x7e時，需連續傳送兩個字符：0x7d和0x5e，以實現標志字符的轉義。
　　2. 當遇到轉義字符0x7d時，需連續傳送兩個字符：0x7d和0x5d，以實現轉義字符的轉義。
　　3. 默認情況下，如果字符的值小于0x20（比如，一個ASCII控制字符），一般都要進行轉義。例如，遇到字符0x01時需連續傳送0x7d和0x21兩個字符。（這時，第六個比特取補碼后變為1，而前面兩種情況均把它變為0。）
　這樣做的原因是防止它們出現在雙方主機的串行接口驅動程序或調制解調器中，因為有時它們會把這些控制字符解釋成特殊的含義。另一種可能是用鏈路控制協議來指定是否需要對這32個字符中的某一些值進行轉義。默認情況下是對所有的32個字符都進行轉義。
　與SLIP類似，由于PPP經常用于低速的串行鏈路，因此減少每一幀的字節數可以降低應用程序的交互時延。利用鏈路控制協議，大多數的產品通過協商可以省略標志符和地址字段，并且把協議字段由2個字節減少到1個字節。如果我們把PPP的幀格式與前面的SLIP的幀格式（圖2.2）進行比較會發現，PPP只增加了3個額外的字節：1個字節留給協議字段，另2個給CRC字段使用。另外，使用IP網絡控制協議，大多數的產品可以通過協商采用Van Jacobson報文首部壓縮方法（對應于CSLIP壓縮），減小IP和TCP首部長度。
　總的來說，PPP比SLIP具有下面這些優點：（1）PPP支持在單根串行線路上運行多種協議，不只是IP協議；（2）每一幀都有循環冗余檢驗；（3）通信雙方可以進行IP地址的動態協商（使用IP網絡控制協議）；（4）與CSLIP類似，對TCP和IP報文首部進行壓縮；（5）鏈路控制協議可以對多個數據鏈路選項進行設置。為這些優點我們付出的代價是在每一幀的首部增加3個字節，當建立鏈路時要發送幾幀協商數據，以及更為復雜的實現。
（下面是原書p.27①的譯文）
　盡管PPP比SLIP有更多的優點，但是現在的SLIP用戶仍然比PPP用戶多。隨著產品越來越多，產家也開始逐漸支持PPP，因此最終PPP應該取代SLIP。
2.7 環回接口
　　大多數的產品都支持環回接口（Loopback Interface），以允許運行在同一臺主機上的客戶程序和服務器程序通過TCP/IP進行通信。A類網絡號127就是為環回接口預留的。根據慣例，大多數系統把IP地址127.0.0.1分配給這個接口，并命名為localhost。一個傳給環回接口的IP數據報不能在任何網絡上出現。
　我們想象，一旦傳輸層檢測到目的端地址是環回地址時，應該可以省略部分傳輸層和所有網絡層的邏輯操作。但是大多數的產品還是照樣完成傳輸層和網絡層的所有過程，只是當IP數據報離開網絡層時把它返回給自己。
　　圖2.4是環回接口處理IP數據報的簡單過程。
圖2.4　環回接口處理IP數據報的過程
　　需要指出圖中的關鍵點是：
　　1. 傳給環回地址（一般是127.0.0.1 ）的任何數據均作為IP輸入。
　　2. 傳給廣播地址或多播地址的數據報復制一份傳給環回接口，然后送到以太網上。這是因為廣播傳送和多播傳送的定義（第12章）包含主機本身。
　　3. 任何傳給該主機IP地址的數據均送到環回接口。
　看上去用傳輸層和IP層的方法來處理環回數據似乎效率不高，但它簡化了設計，因為環回接口可以被看作是網絡層下面的另一個鏈路層。網絡層把一份數據報傳送給環回接口，就像傳給其他鏈路層一樣，只不過環回接口把它返回到IP的輸入隊列中。
　在圖2.4中，另一個隱含的意思是送給主機本身IP地址的IP數據報一般不出現在相應的網絡上。例如，在一個以太網上，分組一般不被傳出去然后讀回來。某些BSD以太網的設備驅動程序的注釋說明，許多以太網接口卡不能讀回它們自己發送出去的數據。由于一臺主機必須處理發送給自己的IP數據報，因此圖2.4所示的過程是最為簡單的處理辦法。
（下面是原書p.29①的譯文）
　 4.4BSD系統定義了變量useloopback，并初始化為1。但是，如果這個變量置為0，以太網驅動程序就會把本地分組送到網絡，而不是送到環回接口上。它也許不能工作，這取決于你所使用的以太網接口卡和設備驅動程序。
2.8 最大傳輸單元MTU
　正如我們在圖2.1看到的那樣，以太網和802.3對數據幀的長度都有一個限制，其最大值分別是1500和1492字節。鏈路層的這個特性稱作MTU，最大傳輸單元。不同類型的網絡大多數都有一個上限。
　如果IP層有一個數據報要傳，而且數據的長度比鏈路層的MTU還大，那么IP層就需要進行分片（fragmentation），把數據報分布若干片，這樣每一片都小于MTU。我們將在11.5節討論IP分片的過程。
　　圖2.5列出了一些典型的MTU值，它們摘自RFC 1191[Mogul and Deering 1990]。點到點的鏈路層（如SLIP和PPP）的MTU并非指的是網絡媒體的物理特性。相反，它是一個邏輯限制，目的是為交互使用提供足夠快的響應時間。在2.10節中，我們將看到這個限制值是如何計算出來的。
　在3.9節中，我們將用netstat命令打印出網絡接口的MTU。
圖2.5 幾種常見的最大傳輸單元（MTU）
2.9 路徑MTU
　當在同一個網絡上的兩臺主機互相進行通信時，該網絡的MTU是非常重要的。但是如果兩臺主機之間的通信要通過多個網絡，那么每個網絡的鏈路層就可能有不同的MTU。重要的不是兩臺主機所在網絡的MTU的值，重要的是兩臺通信主機路徑中的最小MTU。它被稱作路徑MTU。
　兩臺主機之間的路徑MTU不一定是個常數。它取決于當時所選擇的路由。而路由選擇不一定是對稱的（從A到B的路由可能與從B到A的路由不同），因此路徑MTU在兩個方向上不一定是一致的。
　　RFC 1191[Mogul and Deering 1990]描述了路徑MTU的發現機制，即在任何時候確定路徑MTU的方法。我們在介紹了ICMP和IP分片方法以后再來看它是如何操作的。在11.6節中，我們將看到ICMP的不可到達錯誤就采用這種發現方法。在11.7節中，我們還會看到，traceroute程序也是用這個方法來確定到達目標節點的路徑MTU。在 11.8節和24.2節，我們將介紹當產品支持路徑MTU的發現方法時，UDP和TCP是如何進行操作的。
2.10 串行線路吞吐量計算
　　如果線路速率是9600 b/s，而一個字節有8 bit，加上一個起始比特和一個停止比特，那么線路的速率就是960 B/s（字節/秒）。以這個速率傳輸一個1024字節的分組需要1066 ms。如果我們用SLIP鏈接運行一個交互式應用程序，同時還運行另一個應用程序如FTP發送或接收1024字節的數據，那么一般來說我們就必須等待一半的時間（533 ms）才能把交互式應用程序的分組數據發送出去。
　假定我們的交互分組數據可以在其它“大塊”分組數據發送之前被發送出去。大多數的SLIP實現確實提供這類服務排隊方法，把交互數據放在大塊的數據前面。交互通信一般有Telnet，Rlogin，以及FTP的控制部分（用戶的命令，而不是數據）。
（下面是原書p.31①的譯文）
　這種服務排隊方法是不完善的。它不能影響已經進入下游（如串行驅動程序）隊列的非交互數據。同時，新型的調制解調器具有很大的緩沖區，因此非交互數據可能已經進入該緩沖區了。
　　對于交互應用來說，等待533 ms是不能接受的。關于人的有關研究表明，交互響應時間超過100-200 ms就被認為是不好的[Jacobson 1990a]。這是發送一份交互報文出去后，直到接收到響應信息（通常是出現一個回顯字符）為止的往返時間。
　把SLIP的MTU縮短到256就意味著鏈路傳輸一幀最長需要266 ms，它的一半是133 ms（這是我們一般需要等待的時間）。這樣情況會好一些，但仍然不完美。我們選擇它的原因（與64或128相比）是因為大塊數據提供良好的線路利用率（如大文件傳輸）。假設CSLIP的報文首部是5個字節，數據幀總長為261個字節，256個字節的數據使線路的利用率為98.1%，幀頭占了1.9%，這樣的利用率是很不錯。如果把MTU降到256以下，那么將降低傳輸大塊數據的最大吞吐量。
　在圖2.5列出的MTU值中，點對點鏈路的MTU是296個字節。假設數據為256字節，TCP和IP首部占40個字節。由于MTU是IP向鏈路層查詢的結果，因此該值必須包括通常的TCP和IP首部。這樣就會導致IP如何進行分片的決策。IP對于CSLIP的壓縮情況一無所知。
　我們對平均等待時間的計算（傳輸最大數據幀所需時間的一半）只適用于SLIP鏈路（或PPP鏈路）在交互通信和大塊數據傳輸這兩種情況下。當只有交互通信時，如果線路速率是9600 b/s，那么任何方向上的1字節數據（假設有5個字節的壓縮幀頭）往返一次都大約需要12.5 ms。它比前面提到的100-200 ms足夠小。需要注意的是，由于幀頭從40個字節壓縮到5個字節，使得1字節數據往返時間從85 ms減到12.5 ms。
　不幸的是，當使用新型的糾錯和壓縮調制解調器時，這樣的計算就更難了。這些調制解調器所采用的壓縮方法使得在線路上傳輸的字節數大大減少，但糾錯機制又會增加傳輸的時間。不過，這些計算是我們進行合理決策的入口點。
　在后面的章節中，我們將用這些串行線路吞吐量的計算來驗證數據從串行線路止通過的時間。
2.11 小結
　本章討論了Internet協議族中的最底層協議，鏈路層協議。我們比較了以太網和IEEE 802.2/802.3的封裝格式，以及SLIP和PPP的封裝格式。由于SLIP和PPP經常用于低速的鏈路，二者都提供了壓縮不常變化的公共字段的方法。這使交互性能得到提高。
　大多數的實現都提供環回接口。訪問這個接口可以通過特殊的環回地址，一般為127.0.0.1，也可以通過發送IP數據報給主機所擁有的任一IP地址。當環回數據回到上層的協議棧中時，它已經過傳輸層和IP層完整的處理過程。
　我們描述了很多鏈路都具有一個重要特性，MTU，相關的一個概念是路徑MTU。根據典型的串行線路MTU，我們對SLIP和CSLIP鏈路的傳輸時延進行了計算。
　本章內容只覆蓋了當今TCP/IP所采用部分數據鏈路公共技術。TCP/IP成功的原因之一是它幾乎能在任何數據鏈路技術上運行。
習題
2.1 如果你的系統支持netstat(1)命令（參見3.9小節），那么請用它確定系統上的接口及其MTU。

2－1
3　IP：網際協議
3.1 引言
　 IP是TCP/IP協議族中最為核心的協議。所有的TCP，UDP，ICMP，及IGMP數據都以IP數據報格式傳輸（圖1.4）。許多剛開始接觸TCP/IP的人對IP提供不可靠、無連接的數據報傳送服務感到很奇怪，特別是那些具有X.25或SNA背景知識的人。
　不可靠（unreliable）的意思是它不能保證IP數據報能成功地到達目的地。IP僅提供最好的傳輸服務。如果發生某種錯誤時，如某個路由器暫時用完了緩沖區，IP有一個簡單的錯誤處理算法：丟棄該數據報，然后發送ICMP消息報給信源端。任何要求的可靠性必須由上層來提供（如TCP）。
　無連接（connectionless）這個術語的意思是IP并不維護任何關于后續數據報的狀態信息。每個數據報的處理是相互獨立的。這也說明，IP數據報可以不按發送順序接收。如果一信源向相同的信宿發送兩個連續的數據報（先是A，然后是B），每個數據報都是獨立地進行路由選擇，可能選擇不同的路線，因此B可能在A到達之前先到達。
　在本章，我們將簡要介紹IP首部中的各個字段，討論IP路由選擇和子網的有關內容。我們還要介紹兩個有用的命令：ifconfig和netstat。關于IP首部中一些字段的細節，我們將留在以后使用這些字段的時候再進行討論。RFC 791[Postel 1981a]是IP的正式規約文件。
3.2　IP首部
　 IP數據報的格式如圖3.1所示。普通的IP首部長為20個字節，除非含有選項字段。
圖3.1 IP數據報格式及首部中的各字段
　　我們來分析圖3.1中的首部。最高位在左邊，記為0 bit，最低位在右邊，記為31 bit。
　　4個字節的32 bit值以下面的次序傳輸：首先是0-7 bit，其次8-15 bit，然后16-23 bit，最后是24-31 bit。這種傳輸次序稱作big endian字節次序。由于TCP/IP首部中所有的二進制整數在網絡中傳輸時都要求以這種次序，因此它又稱作網絡字節次序。以其他形式存儲二進制整數的機器，如little endian格式，則必須在傳輸數據之前把首部轉換成網絡字節次序。
　目前的協議版本號是4，因此IP有時也稱作IPv4。3.10節將對一種新版的IP協議進行討論。
　　首部長度指的是首部占32 bit字的數目，包括任何先期選項。由于它是一個4比特字段，因此首部最長為60個字節。在第8章中，我們將看到這種限制使某些選項如路由記錄選項在當今已沒有什么用處。普通IP數據報（沒有任何選擇項）該字段的值是5。
　　服務類型（TOS）字段包括一個3 bit的優先權子字段（現在已被忽略），4 bit的TOS子字段，和1 bit未用位但必須置0。4 bit的TOS分別代表：最小時延，最大吞吐量，最高可靠性，最小費用。4 bit中只能置其中1 bit。如果所有4 bit均為0，那么就意味著是普遍服務。RFC 1340 [Reynolds and Postel 1992]描述了所有的標準應用如何設置這些服務類型。RFC 1349 [Almquist 1992]對該RFC進行了修正，更為詳細地描述了TOS的特性。
　圖3.2列出了對不同應用建議的TOS值。在最后一列中，我們給出的是十六進制值，因為這就是在后面我們將要看到的tcpdump命令輸出。
圖3.2 服務類型字段推薦值
　 Telnet和Rlogin這兩個交互應用要求最小的傳輸時延，因為人們主要用它們來傳輸少量的交互數據。另一方面，FTP文件傳輸則要求有最大的吞吐量。最高可靠性被指明給網絡管理（SNMP）和路由選擇協議。用戶網絡新聞（Usenet news, NNTP）是唯一要求最小費用的應用。
　現在大多數的TCP/IP實現都不支持TOS特性，但是自4.3BSD Reno以后的新版系統都對它進行了設置。另外，新的路由協議如OSPF和IS-IS都能根據這些字段的值進行路由決策。
（下面是原書p.35①的譯文）
　在2.10節中，我們提到SLIP一般提供基于服務類型的排隊方法，允許對交互通信數據在處理大塊數據之前進行處理。由于大多數的實現都不使用TOS字段，因此這種排隊機制由SLIP自己來判斷和處理，驅動程序先查看協議字段（確定是否是一個TCP段），然后檢查TCP信源和信宿的端口號，以判斷是否是一個交互服務。一個驅動程序的注釋這樣認為，這種“令人厭惡的處理方法”是必需的，因為大多數實現都不允許應用程序設置TOS字段。
　總長度字段是指整個IP數據報的長度，以字節為單位。利用首部長度字段和總長度字段，我們就可以知道IP數據報中數據內容的起始位置和長度。由于該字段長16比特，所以IP數據報最長可達65535字節。（回憶圖2.5，超級通道的MTU為65535。它的意思其實不是一個真正的MTU－—它使用了最長的IP數據報。）當數據報被分片時，該字段的值也隨著變化，這一點我們將在11.5節中進一步描述。
　盡管可以傳送一個長達65535字節的IP數據報，但是大多數的鏈路層都會對它進行分片。而且，主機也要求不能接收超過576字節的數據報。由于TCP把用戶數據分成若干片，因此一般來說這個限制不會影響TCP。我們在后面的章節中將遇到大量使用UDP的應用（RIP，TFTP，BOOTP，DNS，以及SNMP），它們都限制用戶數據報長度為512字節，小于576字節。但是，事實上現在大多數的實現（特別是那些支持網絡文件系統，NFS的實現）允許超過8192字節的IP數據報。
　總長度字段是IP首部中必要的內容，因為一些數據鏈路（如以太網）需要填充一些數據以達到最小長度。盡管以太網的最小幀長為46字節（圖2.1），但是IP數據可能會更短。如果沒有總長度字段，那么IP層就不知道46字節中有多少是IP數據報的內容。
　標識字段唯一地標識主機發送的每一份數據報。通常每發送一份報文它的值就會加1。我們在11.5節介紹分片和重組時再詳細討論它。同樣，在討論分片時我們再來分析標志字段和片偏移字段。

（下面是原書p.36①的譯文）
　　RFC 791 [Postel 1981a]認為標識字段應該由讓IP發送數據報的上層來選擇。假設有兩個連續的IP數據報，其中一個是

分享到：