|
TCP/IP詳解
1 概述 1.1 引言 很多不同的廠家生產(chǎn)各種型號的計(jì)算機(jī)，它們運(yùn)行完全不同的操作系統(tǒng)，但TCP/IP協(xié)議組件允許它們互相進(jìn)行通信。這一點(diǎn)很讓人感到吃驚，因?yàn)樗淖饔靡堰h(yuǎn)遠(yuǎn)超出了起初的設(shè)想。TCP/IP起源于60年代末美國政府資助的一個(gè)分組交換網(wǎng)絡(luò)研究項(xiàng)目，到現(xiàn)在90年代已發(fā)展成為計(jì)算機(jī)之間最常應(yīng)用的組網(wǎng)形式。它是一個(gè)真正的開放系統(tǒng)，因?yàn)閰f(xié)議組件的定義及其多種實(shí)現(xiàn)可以不用花錢或花很少的錢就可以公開地得到。它成為被稱作“全球互聯(lián)網(wǎng)”或“因特網(wǎng)”(Internet)的基礎(chǔ)，該廣域網(wǎng)（WAN）已包含超過100萬臺遍布世界各地的計(jì)算機(jī)。 本章主要對TCP/IP協(xié)議組件進(jìn)行概述，其目的是為本書其余章節(jié)提供充分的背景知識。如果讀者要從歷史的角度了解有關(guān)TCP/IP的早期發(fā)展情況，請參考文獻(xiàn)[Lynch 1993]。 1.2 分層 網(wǎng)絡(luò)協(xié)議通常分不同層次進(jìn)行開發(fā)，每一層分別負(fù)責(zé)不同的通信功能。一個(gè)協(xié)議組件，比如TCP/IP，是一組不同層次上的多個(gè)協(xié)議的組合。TCP/IP通常被認(rèn)為是一個(gè)四層協(xié)議系統(tǒng)，如圖1.1所示。 圖1.1 TCP/IP協(xié)議組件的四個(gè)層次 每一層負(fù)責(zé)不同的功能： 1. 鏈路層，有時(shí)也稱作數(shù)據(jù)鏈路層或網(wǎng)絡(luò)接口層，通常包括操作系統(tǒng)中的設(shè)備驅(qū)動程序和計(jì)算機(jī)中對應(yīng)的網(wǎng)絡(luò)接口卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細(xì)節(jié)。 2. 網(wǎng)絡(luò)層，有時(shí)也稱作互連網(wǎng)層，處理分組在網(wǎng)絡(luò)中的活動，例如分組的路由選擇。在TCP/IP協(xié)議組件中，網(wǎng)絡(luò)層協(xié)議包括IP協(xié)議（網(wǎng)際協(xié)議），ICMP協(xié)議（Internet互連網(wǎng)控制報(bào)文協(xié)議），以及IGMP協(xié)議（Internet組管理協(xié)議）。 3. 運(yùn)輸層主要為兩臺主機(jī)上的應(yīng)用程序提供端到端的通信。在TCP/IP協(xié)議組件中，有兩個(gè)互不相同的傳輸協(xié)議：TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報(bào)協(xié)議）。 TCP為兩臺主機(jī)提供高可靠性的數(shù)據(jù)通信。它所做的工作包括把應(yīng)用程序交給它的數(shù)據(jù)分成合適的小塊交給下面的網(wǎng)絡(luò)層，確認(rèn)接收到的分組，設(shè)置發(fā)送最后確認(rèn)分組的超時(shí)時(shí)鐘等。由于運(yùn)輸層提供了高可靠性的端到端的通信，因此應(yīng)用層可以忽略所有這些細(xì)節(jié)。 而另一方面，UDP則為應(yīng)用層提供一種非常簡單的服務(wù)。它只是把稱作數(shù)據(jù)報(bào)的分組從一臺主機(jī)發(fā)送到另一臺主機(jī)，但并不保證該數(shù)據(jù)報(bào)能到達(dá)另一端。任何必需的可靠性必須由應(yīng)用層來提供。 這兩種運(yùn)輸層協(xié)議分別在不同的應(yīng)用程序中有不同的用途，這一點(diǎn)我們將在后面看到。 4. 應(yīng)用層負(fù)責(zé)處理特定的應(yīng)用程序細(xì)節(jié)。幾乎各種不同的TCP/IP實(shí)現(xiàn)都會提供下面這些通用的應(yīng)用程序： ?。甌elnet 遠(yuǎn)程登錄 ?。瓼TP 文件傳輸協(xié)議 ?。甋MTP 用于電子郵件的簡單郵件傳輸協(xié)議 ?。甋NMP 簡單網(wǎng)絡(luò)管理協(xié)議 另外還有許多其他應(yīng)用，我們在后面章節(jié)中將介紹其中的一部分。 假設(shè)我們在一個(gè)局域網(wǎng)（LAN）如以太網(wǎng)中有兩臺主機(jī)，二者都運(yùn)行FTP協(xié)議，圖1.2列出了該過程所涉及到的所有協(xié)議。 圖1.2 局域網(wǎng)上運(yùn)行FTP的兩臺主機(jī) 這里，我們列舉了一個(gè)FTP客戶程序和另一個(gè)FTP服務(wù)器程序。大多數(shù)的網(wǎng)絡(luò)應(yīng)用程序都被設(shè)計(jì)成客戶－服務(wù)器模式。服務(wù)器為客戶提供某種服務(wù)，在本例中就是訪問服務(wù)器所在主機(jī)上的文件。在遠(yuǎn)程登錄應(yīng)用程序Telnet中，為客戶提供的服務(wù)是登錄到服務(wù)器主機(jī)上。 在同一層上，雙方都有對應(yīng)的一個(gè)或多個(gè)協(xié)議進(jìn)行通信。例如，某個(gè)協(xié)議允許TCP層進(jìn)行通信，而另一個(gè)協(xié)議則允許兩個(gè)IP層進(jìn)行通信。 在圖1.2的右邊，我們注意到應(yīng)用程序通常是一個(gè)用戶進(jìn)程，而下三層則一般在（操作系統(tǒng)）內(nèi)核中執(zhí)行。盡管這不是必需的，但通常都是這樣處理的，例如UNIX操作系統(tǒng)。 在圖1.2中，頂層與下三層之間還有另一個(gè)關(guān)鍵的不同之處。應(yīng)用層關(guān)心的是應(yīng)用程序的細(xì)節(jié)，而不是數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸活動。下三層對應(yīng)用程序一無所知，但它們要處理所有的通信細(xì)節(jié)。 我們在圖1.2中例舉了四種不同層次上的協(xié)議。FTP是一種應(yīng)用層協(xié)議，TCP是一種運(yùn)輸層協(xié)議，IP是一種網(wǎng)絡(luò)層協(xié)議，而以太網(wǎng)協(xié)議則應(yīng)用于鏈路層上。TCP/IP協(xié)議組件是一組不同的協(xié)議組合在一起構(gòu)成的協(xié)議族。盡管通常稱該協(xié)議組件為TCP/IP，但TCP和IP只是其中的兩種協(xié)議而已。（該協(xié)議組件的另一個(gè)名字是Internet協(xié)議族(Internet Protocol Suite)。 網(wǎng)絡(luò)接口層和應(yīng)用層的目的是很顯然的──前者處理有關(guān)通信媒介的細(xì)節(jié)（以太網(wǎng)，令牌環(huán)網(wǎng)等），而后者處理某個(gè)特定的用戶應(yīng)用程序（FTP，Telnet等）。但是，從表面上看，網(wǎng)絡(luò)層和運(yùn)輸層之間的區(qū)別不那么明顯。為什么要把它們劃分成兩個(gè)不同的層次呢？為了理解這一點(diǎn)，我們必須把視野從單個(gè)網(wǎng)絡(luò)擴(kuò)展到一組網(wǎng)絡(luò)。 在80年代，網(wǎng)絡(luò)不斷增長的原因之一是大家都意識到只有一臺孤立的計(jì)算機(jī)構(gòu)成的“孤島”沒有太大意義，于是就把這些孤立的系統(tǒng)組在一起形成網(wǎng)絡(luò)。隨著這樣的發(fā)展，到了90年代，我們又逐漸認(rèn)識到這種由單個(gè)網(wǎng)絡(luò)構(gòu)成的新的更大的“島嶼”同樣沒有太大的意義。于是，人們又把多個(gè)網(wǎng)絡(luò)連在一起形成一個(gè)網(wǎng)絡(luò)的網(wǎng)絡(luò)，或稱作互連網(wǎng)(internet)。一個(gè)互連網(wǎng)就是一組通過相同協(xié)議族互連在一起的網(wǎng)絡(luò)。 構(gòu)造互連網(wǎng)最簡單的方法是把兩個(gè)或多個(gè)網(wǎng)絡(luò)通過路由器進(jìn)行連接。它是一種特殊的用于網(wǎng)絡(luò)互連的硬件盒。路由器的好處是為不同類型的物理網(wǎng)絡(luò)提供連接：以太網(wǎng)，令牌環(huán)網(wǎng)，點(diǎn)對點(diǎn)的鏈接，F(xiàn)DDI（光纖分布式數(shù)據(jù)接口）等等。 （下面是原書p.4①的譯文） 這些盒子也稱作IP路由器（IP Routers），但我們這里使用路由器(Router)這個(gè)術(shù)語。 從歷史上說，這些盒子稱作網(wǎng)關(guān)（gateways），在很多TCP/IP文獻(xiàn)中都使用這個(gè)術(shù)語?，F(xiàn)在網(wǎng)關(guān)這個(gè)術(shù)語只用來表示應(yīng)用層網(wǎng)關(guān)：一個(gè)連接兩種不同協(xié)議組件的進(jìn)程（例如，TCP/IP和IBM的SNA），它為某個(gè)特定的應(yīng)用程序服務(wù)（常常是電子郵件或文件傳輸）。 圖1.3是一個(gè)包含兩個(gè)網(wǎng)絡(luò)的互連網(wǎng)：一個(gè)以太網(wǎng)和一個(gè)令牌環(huán)網(wǎng)，通過一個(gè)路由器互相連接。盡管這里是兩臺主機(jī)通過路由器進(jìn)行通信，實(shí)際上以太網(wǎng)中的任何主機(jī)都可以與令牌環(huán)網(wǎng)中的任何主機(jī)進(jìn)行通信。 在圖1.3中，我們可以劃分出端系統(tǒng)（end system）（兩邊的兩臺主機(jī)）和中間系統(tǒng)（intermediate system）（中間的路由器）。應(yīng)用層和運(yùn)輸層使用端到端（end-to-end）協(xié)議。在我們的圖中，只有端系統(tǒng)需要這兩層協(xié)議。但是，網(wǎng)絡(luò)層提供的卻是逐跳（hop-by-hop）協(xié)議，兩個(gè)端系統(tǒng)和每個(gè)中間系統(tǒng)都要使用它。 圖1.3 通過路由器連接的兩個(gè)網(wǎng)絡(luò) 在TCP/IP協(xié)議組件中，網(wǎng)絡(luò)層IP提供的是一種不可靠的服務(wù)。也就是說，它只是盡可能快地把分組從源結(jié)點(diǎn)送到目的結(jié)點(diǎn)，但是并不提供任何可靠性保證。而另一方面，TCP在不可靠的IP層上提供了一個(gè)可靠的運(yùn)輸層。為了提供這種可靠的服務(wù)，TCP采用了超時(shí)重傳，發(fā)送和接收端到端的確認(rèn)分組等機(jī)制。由此可見，運(yùn)輸層和網(wǎng)絡(luò)層分別負(fù)責(zé)不同的功能。 從定義上看，一個(gè)路由器具有兩個(gè)或多個(gè)網(wǎng)絡(luò)接口層（因?yàn)樗B接了兩個(gè)或多個(gè)網(wǎng)絡(luò)）。任何具有多個(gè)接口的系統(tǒng)英文都稱作是多接口的multihomed。一個(gè)主機(jī)也可以有多個(gè)接口，但一般不稱作路由器, 除非它的功能只是單純地把分組從一個(gè)接口傳送到另一個(gè)接口。同樣，路由器并不一定指那種在互連網(wǎng)中用來轉(zhuǎn)發(fā)分組的特殊硬件盒。大多數(shù)的TCP/IP實(shí)現(xiàn)也允許一個(gè)多接口主機(jī)來擔(dān)當(dāng)路由器的功能，但是主機(jī)為此必須進(jìn)行特殊的配置。在這種情況下，我們既可以稱該系統(tǒng)為主機(jī)（當(dāng)它運(yùn)行某一應(yīng)用程序時(shí)，如FTP或Telnet），也可以稱之為路由器（當(dāng)它把分組從一個(gè)網(wǎng)絡(luò)轉(zhuǎn)發(fā)到另一個(gè)網(wǎng)絡(luò)時(shí)）。我們在不同的場合下使用不同的術(shù)語。 互連網(wǎng)的目標(biāo)之一是在應(yīng)用程序中隱藏所有的物理細(xì)節(jié)。雖然這一點(diǎn)在圖1.3由兩個(gè)網(wǎng)絡(luò)組成的互連網(wǎng)中并不很明顯，但是應(yīng)用層不能關(guān)心（也不關(guān)心）一臺主機(jī)是在以太網(wǎng)上，而另一臺主機(jī)是在令牌環(huán)網(wǎng)上，它們通過路由器進(jìn)行互連。隨著增加不同類型的物理網(wǎng)絡(luò)，可能會有20個(gè)路由器，但應(yīng)用層仍然是一樣的。物理細(xì)節(jié)的隱藏使得互連網(wǎng)功能非常強(qiáng)大，也非常有用。 連接網(wǎng)絡(luò)的另一個(gè)途徑是使用網(wǎng)橋。網(wǎng)橋是在鏈路層上對網(wǎng)絡(luò)進(jìn)行互連，而路由器則是在網(wǎng)絡(luò)層上對網(wǎng)絡(luò)進(jìn)行互連。網(wǎng)橋使得多個(gè)局域網(wǎng)（LAN）組合在一起，這樣對上層來說就好像是一個(gè)局域網(wǎng)。 TCP /IP傾向于使用路由器而不是網(wǎng)橋來連接網(wǎng)絡(luò)，因此我們將著重介紹路由器。文獻(xiàn)[Perlman 1992]的第12章對路由器和網(wǎng)橋進(jìn)行了比較。 1.3 TCP/IP的分層 在TCP/IP協(xié)議組件中，有很多種協(xié)議。圖1.4給出了本書將要討論的其他協(xié)議。 圖1.4 TCP/IP協(xié)議組件中不同層次的協(xié)議 TCP和UDP是兩種最為著名的運(yùn)輸層協(xié)議，二者都使用IP作為網(wǎng)絡(luò)層協(xié)議。 雖然TCP使用不可靠的IP服務(wù)，但它卻提供一種可靠的運(yùn)輸層服務(wù)。本書第17章到第22章將詳細(xì)討論TCP的內(nèi)部操作細(xì)節(jié)。然后，我們將介紹一些TCP的應(yīng)用，如第26章中的Telnet和Rlogin，第27章中的FTP，以及第28章中的SMTP等。這些應(yīng)用通常都是用戶進(jìn)程。 UDP為應(yīng)用程序發(fā)送和接收數(shù)據(jù)報(bào)。一個(gè)數(shù)據(jù)報(bào)是指從發(fā)送方傳輸?shù)浇邮辗降囊粋€(gè)信息單元（例如，發(fā)送方指定的一定字節(jié)數(shù)的信息）。但是與TCP不同的是，UDP是不可靠的，它不能保證數(shù)據(jù)報(bào)能安全無誤地到達(dá)最終目的。本書第11章將討論UDP，然后在第14章（域名系統(tǒng)：Domain Name System），第15章（簡單文件傳輸協(xié)議Trivial File Transfer Protocol），以及第16章（引導(dǎo)程序協(xié)議Bootstrap Protocol）介紹使用UDP的應(yīng)用程序。SNMP（簡單網(wǎng)絡(luò)管理協(xié)議）也使用了UDP協(xié)議，但是由于它還要處理許多其他的協(xié)議，因此本書把它留到第25章再進(jìn)行討論。 IP是網(wǎng)絡(luò)層上的主要協(xié)議，同時(shí)被TCP和UDP使用。TCP和UDP的每組數(shù)據(jù)都通過端系統(tǒng)和每個(gè)中間路由器中的IP層在互連網(wǎng)中進(jìn)行傳輸。在圖1.4中，我們給出了一個(gè)直接訪問IP的應(yīng)用程序。這是很少見的，但也是可能的。（一些較老的路由選擇協(xié)議就是以這種方式來實(shí)現(xiàn)的。當(dāng)然新的運(yùn)輸層協(xié)議也有可能試用這種方式。）第3章主要討論IP協(xié)議，但是為了使內(nèi)容更加有針對性，一些細(xì)節(jié)將留在后面的章節(jié)中進(jìn)行討論。第9章和第10章討論IP如何進(jìn)行路由選擇。 ICMP是IP協(xié)議的附屬協(xié)議。IP層用它來與其他主機(jī)或路由器交換錯(cuò)誤報(bào)文和其他重要信息。第6章對ICMP的有關(guān)細(xì)節(jié)進(jìn)行討論。盡管ICMP主要被IP使用，但應(yīng)用程序也有可能訪問它。我們將分析兩個(gè)流行的診斷工具，Ping和Traceroute（第7章和第8章），它們都使用了ICMP。 IGMP是Internet組管理協(xié)議。它用來把一個(gè)UDP數(shù)據(jù)報(bào)多播到多個(gè)主機(jī)。我們在第12章中描述廣播（把一個(gè)UDP數(shù)據(jù)報(bào)發(fā)送到某個(gè)指定網(wǎng)絡(luò)上的所有主機(jī)）和多點(diǎn)傳送的一般特性，然后在第13章中對IGMP協(xié)議本身進(jìn)行描述。 ARP（地址解析協(xié)議）和RARP（逆地址解析協(xié)議）是某些網(wǎng)絡(luò)接口（如以太網(wǎng)和令牌環(huán)網(wǎng)）使用的特殊協(xié)議，用來轉(zhuǎn)換IP層和網(wǎng)絡(luò)接口層使用的地址。我們分別在第4章和第5章對這兩種協(xié)議進(jìn)行分析和介紹。 1.4 互連網(wǎng)的地址 互連網(wǎng)上的每個(gè)接口必須有一個(gè)唯一的Internet地址（也稱作IP地址）。IP地址長32 bit。Internet地址并不采用平面形式的地址空間，如1，2，3等。IP地址具有一定的結(jié)構(gòu)，五類不同的互連網(wǎng)地址格式如圖1.5所示。 這些32位的地址通常寫成四個(gè)十進(jìn)制的數(shù)，其中每個(gè)整數(shù)對應(yīng)一個(gè)字節(jié)。這種表示方法稱作“點(diǎn)分十進(jìn)制表示法”（dotted decimal notation）。例如，作者的系統(tǒng)就是一個(gè)B類地址，它表示為：140.252.13.33。 區(qū)分各類地址的最簡單方法是看它的第一個(gè)十進(jìn)制整數(shù)。圖1.6列出了各類地址的起止范圍，其中第一個(gè)十進(jìn)制整數(shù)用加黑字體表示。 圖1.5五類互連網(wǎng)地址 圖1.6 各類IP地址的范圍 需要再次指出的是，多接口主機(jī)具有多個(gè)IP地址，其中每個(gè)接口都對應(yīng)一個(gè)IP地址。 由于互連網(wǎng)上的每個(gè)接口必須有一個(gè)唯一的IP地址，因此必須要有一個(gè)管理機(jī)構(gòu)為接入互連網(wǎng)的網(wǎng)絡(luò)分配IP地址。這個(gè)管理機(jī)構(gòu)就是互連網(wǎng)絡(luò)信息中心（Internet Network Information Centre）稱作InterNIC。InterNIC只分配網(wǎng)絡(luò)號。主機(jī)號的分配由系統(tǒng)管理員來負(fù)責(zé)。 （下面是原書p.8①的譯文） Internet注冊服務(wù)(IP地址和DNS域名)過去由NIC來負(fù)責(zé)，其網(wǎng)絡(luò)地址是nic.ddn.mil。1993年4月1日，InterNIC成立?，F(xiàn)在，NIC只負(fù)責(zé)處理國防數(shù)據(jù)網(wǎng)的注冊請求，所有其他的Internet用戶注冊請求均由InterNIC負(fù)責(zé)處理，其網(wǎng)址是：rs.internic.net。 事實(shí)上InterNIC有三部分組成：注冊服務(wù)（rs.internic.net），目錄和數(shù)據(jù)庫服務(wù)（ds.internic.net），以及信息服務(wù)（is.internic.net）。有關(guān)InterNIC的其他信息參見習(xí)題1.8。 有三類IP地址：單目傳送地址（目標(biāo)為單個(gè)主機(jī)），廣播傳送地址（目的端為給定網(wǎng)絡(luò)上的所有主機(jī)），以及多目傳送地址（目的端為同一組內(nèi)的所有主機(jī)）。第12章和第13章將分別討論廣播傳送和多目傳送的更多細(xì)節(jié)。 在3.4節(jié)中，我們在介紹IP路由選擇以后將進(jìn)一步介紹子網(wǎng)的概念。圖3.9給出了幾個(gè)特殊的IP地址：主機(jī)號和網(wǎng)絡(luò)號為全0或全1。 1.5 域名系統(tǒng) 盡管通過IP地址可以識別主機(jī)上的網(wǎng)絡(luò)接口，進(jìn)而訪問主機(jī)，但是人們最喜歡使用的還是主機(jī)名。在TCP/IP領(lǐng)域中，域名系統(tǒng)（DNS）是一個(gè)分布的數(shù)據(jù)庫，由它來提供IP地址和主機(jī)名之間的映射信息。我們在第14章將詳細(xì)討論DNS。 現(xiàn)在，我們必須理解，任何應(yīng)用程序都可以調(diào)用一個(gè)標(biāo)準(zhǔn)的庫函數(shù)來查看給定名字的主機(jī)的IP地址。類似地，系統(tǒng)還提供一個(gè)逆函數(shù)──給定主機(jī)的IP地址，查看它所對應(yīng)的主機(jī)名。 大多數(shù)使用主機(jī)名作為參數(shù)的應(yīng)用程序也可以把IP地址作為參數(shù)。例如，在第4章中當(dāng)我們用Telnet進(jìn)行遠(yuǎn)程登錄時(shí)，我們既可以指定一個(gè)主機(jī)名，也可以指定一個(gè)IP地址。 1.6 封裝 當(dāng)應(yīng)用程序用TCP傳送數(shù)據(jù)時(shí)，數(shù)據(jù)被送入?yún)f(xié)議棧中，然后逐個(gè)通過每一層直到被當(dāng)作一串比特流送入網(wǎng)絡(luò)。其中每一層對收到的數(shù)據(jù)都要增加一些首部信息（有時(shí)還要增加尾部信息），該過程如圖1.7所示。TCP傳給IP的數(shù)據(jù)單元稱作TCP報(bào)文段或簡稱為TCP段（TCP segment）。IP傳給網(wǎng)絡(luò)接口層的數(shù)據(jù)單元稱作IP數(shù)據(jù)報(bào)(IP datagram)。通過以太網(wǎng)傳輸?shù)谋忍亓鞣Q作幀(frame)。 圖1.7中幀頭和幀尾下面所標(biāo)注的數(shù)字是典型以太網(wǎng)幀首部的字節(jié)長度。在后面的章節(jié)中我們將詳細(xì)討論這些幀頭的具體含義。 以太網(wǎng)數(shù)據(jù)幀的物理特性是其長度必須在46－1500字節(jié)之間。我們將在4.5節(jié)遇到最小長度的數(shù)據(jù)幀，在2.8節(jié)中遇到最大長度的數(shù)據(jù)幀。 （下面是原書p.9①的譯文） 所有的Internet標(biāo)準(zhǔn)和大多數(shù)有關(guān)TCP/IP的書都使用octet這個(gè)術(shù)語來表示字節(jié)。使用這個(gè)過分雕琢的術(shù)語是有歷史原因的，因?yàn)門CP/IP的很多工作都是在DEC-10系統(tǒng)上進(jìn)行的，但是它并不使用8 bit的字節(jié)。由于現(xiàn)在幾乎所有的計(jì)算機(jī)系統(tǒng)都采用8 bit的字節(jié)，因此我們在本書中使用字節(jié)（byte）這個(gè)術(shù)語。 更準(zhǔn)確地說，圖1.7中IP和網(wǎng)絡(luò)接口層之間傳送的數(shù)據(jù)單元應(yīng)該是分組（packet）。分組既可以是一個(gè)IP數(shù)據(jù)報(bào)，也可以是IP數(shù)據(jù)報(bào)的一個(gè)片（fragment）。我們將在11.5節(jié)討論IP數(shù)據(jù)報(bào)分片的詳細(xì)情況。 UDP數(shù)據(jù)與TCP數(shù)據(jù)基本一致。唯一的不同是UDP傳給IP的信息單元稱作UDP數(shù)據(jù)報(bào)（UDP datagram），而且UDP的首部長為8字節(jié)。 圖1.7 數(shù)據(jù)進(jìn)入?yún)f(xié)議棧時(shí)的封裝過程 回想第6頁中的圖1.4，由于TCP，UDP，ICMP和IGMP都要向IP傳送數(shù)據(jù)，因此IP必須在生成的IP首部中加入某種標(biāo)識，以表明數(shù)據(jù)屬于哪一層。為此，IP在首部中存入一個(gè)長度為8比特的數(shù)值，稱作協(xié)議域。1表示為ICMP協(xié)議，2表示為IGMP協(xié)議，6表示為TCP協(xié)議，17表示為UDP協(xié)議。 類似地，許多應(yīng)用程序都可以使用TCP或UDP來傳送數(shù)據(jù)。運(yùn)輸層協(xié)議在生成報(bào)文首部時(shí)要存入一個(gè)應(yīng)用程序的標(biāo)識符。TCP和UDP都用一個(gè)16 bit的端口號來表示不同的應(yīng)用程序。TCP和UDP把源端口號和目的端口號分別存入報(bào)文首部中。 網(wǎng)絡(luò)接口分別要發(fā)送和接收IP，ARP和RARP數(shù)據(jù)，因此也必須在以太網(wǎng)的幀首部中加入某種形式的標(biāo)識，以指明生成數(shù)據(jù)的網(wǎng)絡(luò)層協(xié)議。為此，以太網(wǎng)的幀首部也有一個(gè)16 bit的幀類型域。 1.7 分用（Demultiplexing） 當(dāng)目的主機(jī)收到一個(gè)以太網(wǎng)數(shù)據(jù)幀時(shí)，數(shù)據(jù)就開始從協(xié)議棧中由底向上升，同時(shí)去掉各層協(xié)議加上的報(bào)文首部。每層協(xié)議盒都要去檢查報(bào)文首部中的協(xié)議標(biāo)識，以確定接收數(shù)據(jù)的上層協(xié)議。這個(gè)過程稱作分用，圖1.8顯示了該過程是如何發(fā)生的。 圖1.8 以太網(wǎng)數(shù)據(jù)幀的分用過程 （下面是原書p.11①的譯文） 為協(xié)議ICMP和IGMP定位一直是一件很棘手的事情。在圖1.4中，我們把它們與IP放在同一層上，那是因?yàn)槭聦?shí)上它們是IP的附屬協(xié)議。但是在這里，我們又把它們放在IP層的上面，這是因?yàn)镮CMP和IGMP報(bào)文都被封裝在IP數(shù)據(jù)報(bào)中。 對于ARP和RARP我們也遇到類似的難題。在這里我們把它們放在以太網(wǎng)設(shè)備驅(qū)動程序的上方，這是因?yàn)樗鼈兒虸P數(shù)據(jù)報(bào)一樣，都有各自的以太網(wǎng)數(shù)據(jù)幀類型。但在圖2.4中，我們又把ARP作為以太網(wǎng)設(shè)備驅(qū)動程序的一部分，放在IP層的下面，其原因在邏輯上是合理的。 當(dāng)進(jìn)一步描述TCP的細(xì)節(jié)時(shí)，我們將看到協(xié)議確實(shí)是通過目的端口號，源IP地址和源端口號進(jìn)行解包的。 1.8 客戶服務(wù)器模型 大部分網(wǎng)絡(luò)應(yīng)用程序在編寫時(shí)都假設(shè)一端是客戶，另一端是服務(wù)器，其目的是為了讓服務(wù)器為客戶提供一些特定的服務(wù)。 我們可以將這種服務(wù)分為兩種類型：重復(fù)型或并發(fā)型。重復(fù)型服務(wù)器通過以下步驟進(jìn)行交互： I1. 等待一個(gè)客戶請求的到來。 I2. 處理客戶請求。 I3. 發(fā)送響應(yīng)給發(fā)送請求的客戶。 I4. 返回I1步驟。 重復(fù)型服務(wù)器主要的問題發(fā)生在I2狀態(tài)。在這個(gè)時(shí)候，它不能為其他客戶機(jī)提供服務(wù)。 相應(yīng)地，并發(fā)型服務(wù)器采用以下步驟： C1. 等待一個(gè)客戶請求的到來 C2. 啟動一個(gè)新的服務(wù)器來處理這個(gè)客戶的請求。在這期間可能生成一個(gè)新的進(jìn)程、任務(wù)或線程，并依賴底層操作系統(tǒng)的支持。這個(gè)步驟如何進(jìn)行取決于操作系統(tǒng)。生成的新服務(wù)器對客戶的全部請求進(jìn)行處理。處理結(jié)束后，終止這個(gè)新服務(wù)器。 C3.返回C1步驟。 并發(fā)服務(wù)器的優(yōu)點(diǎn)在于它是利用生成其他服務(wù)器的方法來處理客戶的請求。也就是說，每個(gè)客戶都有它自己對應(yīng)的服務(wù)器。如果操作系統(tǒng)允許多任務(wù)，那么就可以同時(shí)為多個(gè)客戶同時(shí)服務(wù)。 我們對服務(wù)器，而不是對客戶進(jìn)行分類的原因是因?yàn)閷τ谝粋€(gè)客戶來說，它通常并不能夠辨別自己是與一個(gè)重復(fù)型服務(wù)器或并發(fā)型服務(wù)器進(jìn)行對話。 一般來說，TCP服務(wù)器是并發(fā)的，而UDP服務(wù)器是重復(fù)的，但也存在一些例外。我們將在11.12節(jié)對UDP對其服務(wù)器產(chǎn)生的影響進(jìn)行詳細(xì)討論，并在18.11節(jié)對TCP對其服務(wù)器的影響進(jìn)行討論。 1.9 端口號 我們前面已經(jīng)指出過，TCP和UDP采用16比特的端口號來識別應(yīng)用程序。那么這些端口號是如何選擇的呢？ 服務(wù)器一般都是通過人們所熟知的端口號來識別的。例如，對于每個(gè)TCP/IP實(shí)現(xiàn)來說，F(xiàn)TP服務(wù)器的TCP端口號都是21，每個(gè)Telnet服務(wù)器的TCP端口號都是23，每個(gè)TFTP(簡單文件傳輸協(xié)議)服務(wù)器的UDP端口號都是69。任何TCP/IP實(shí)現(xiàn)所提供的服務(wù)都用眾所周知的1－1023之間的端口號。這些人們所熟知的端口號由Internet端口號分配機(jī)構(gòu)（Internet Assigned Numbers Authority, IANA）來管理。 （下面是原書p.13①的譯文） 到1992年為止，人們所熟知的端口號介于1－255之間。256－1023之間的端口號通常都是由Unix系統(tǒng)占用，以提供一些特定的Unix服務(wù)──也就是說，提供一些只有Unix系統(tǒng)才有的，而其他操作系統(tǒng)可能不提供的服務(wù)?，F(xiàn)在IANA管理1－1023之間所有的端口號。 Internet擴(kuò)展服務(wù)與Unix特定服務(wù)之間的一個(gè)差別就是Telnet和Rlogin。它們二者都允許我們通過計(jì)算機(jī)網(wǎng)絡(luò)登錄到其他主機(jī)上。Telnet是采用端口號為23的TCP/IP標(biāo)準(zhǔn)且?guī)缀蹩梢栽谒胁僮飨到y(tǒng)上進(jìn)行實(shí)現(xiàn)。相反，Rlogin最開始時(shí)只是為Unix系統(tǒng)設(shè)計(jì)的（盡管許多非Unix系統(tǒng)現(xiàn)在也提供該服務(wù)），因此在80年代初，它的有名端口號為513。 客戶端通常對它所使用的端口號并不關(guān)心，只需保證該端口號在本機(jī)上是唯一的就可以了?？蛻舳丝谔栍址Q作臨時(shí)端口號（即存在時(shí)間很短暫）。這是因?yàn)樗ǔＶ皇窃谟脩暨\(yùn)行該客戶程序時(shí)才存在，而服務(wù)器則只要主機(jī)開著的，其服務(wù)就運(yùn)行。 大多數(shù)TCP/IP實(shí)現(xiàn)給臨時(shí)端口分配1024－5000之間的端口號。大于5000的端口號是為其他服務(wù)器預(yù)留的（Internet上并不常用的服務(wù))。我們可以在后面看見許多這樣的給臨時(shí)端口分配端口號的例子。 （下面是原書p.13②的譯文） Solaris 2.2是一個(gè)很有名的例外。通常TCP和UDP的缺省臨時(shí)端口號從32768開始。在E.4節(jié)中，我們將詳細(xì)描述系統(tǒng)管理員如何對配置選項(xiàng)進(jìn)行修改以改變這些缺省項(xiàng)。 大多數(shù)Unix系統(tǒng)的file/etc/services都包含了人們熟知的端口號。為了找到Telnet服務(wù)器和域名系統(tǒng)的端口號，我們可以運(yùn)行以下語句： （見原書p.13的③） 保留端口號 Unix系統(tǒng)有保留端口號的概念。只有具有超級用戶特權(quán)的進(jìn)程才允許給它自己分配一個(gè)保留端口號。 這些端口號介于1到1023之間，一些應(yīng)用程序（如有名的Rlogin，26.2節(jié)）將它作為客戶與服務(wù)器之間身份認(rèn)證的一部分。 1.10 標(biāo)準(zhǔn)化過程 究竟是誰控制著TCP/IP協(xié)議組件，又是誰在定義新的標(biāo)準(zhǔn)以及其他類似的事情？事實(shí)上，有四個(gè)小組在負(fù)責(zé)Internet技術(shù)。 1. Internet協(xié)會（ISOC: Internet Society）是一個(gè)推動、支持和促進(jìn)Internet不斷增長和發(fā)展的專業(yè)組織，它把Internet作為全球研究通信的基礎(chǔ)設(shè)施。 2. Internet體系結(jié)構(gòu)委員會（IAB：Internet Architecture Board）是一個(gè)技術(shù)監(jiān)督和協(xié)調(diào)的機(jī)構(gòu)。它由國際上來自不同專業(yè)的15個(gè)志愿者組成，其職能是負(fù)責(zé)Internet標(biāo)準(zhǔn)的最后編輯和技術(shù)審核。IAB隸屬于ISOC。 3. Internet工程專門小組（IETF：Internet Engineering Task Force）是一個(gè)面向近期標(biāo)準(zhǔn)的組織，它分為9個(gè)領(lǐng)域（應(yīng)用，尋徑和尋址，安全等等）。IETF開發(fā)成為Internet標(biāo)準(zhǔn)的規(guī)約。為幫助IETF主席，又成立了Internet工程指導(dǎo)小組（IESG：Internet Engineering Steering Group）。 4. Internet研究專門小組主要對長遠(yuǎn)的項(xiàng)目進(jìn)行研究。 IRTF和IETF都隸屬于IAB。文獻(xiàn)[Crocker 1993]提供了關(guān)于Internet內(nèi)部標(biāo)準(zhǔn)化進(jìn)程更為詳細(xì)的信息，同時(shí)還介紹了它的早期歷史。 1.11 RFC 所有關(guān)于Internet的正式標(biāo)準(zhǔn)都以RFC（Request for Comment）文檔出版。另外，大量的RFC并不是正式的標(biāo)準(zhǔn)，出版的目的只是為了提供信息。RFC的篇幅從1頁到200頁不等。每一項(xiàng)都用一個(gè)數(shù)字來標(biāo)識，如RFC 1122，數(shù)字越大說是RFC的內(nèi)容越新。 所有的RFC都可以通過電子郵件或用FTP從Internet上免費(fèi)獲取。如果發(fā)送下面這份電子郵件，你就會收到一份獲取RFC的方法清單： To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs 最新的RFC索引總是搜索信息的起點(diǎn)。這個(gè)索引列出了RFC被替換或局部更新的時(shí)間。 下面是一些重要的RFC文檔： 1. 賦值RFC（Assigned Numbers RFC）列出了所有Internet協(xié)議中使用的數(shù)字和常數(shù)。至本書出版時(shí)為止，最新RFC的編號是1340 [Reynolds and Postel 1992]。所有著名的Internet端口號都列在這里。 當(dāng)這個(gè)RFC被更新時(shí)（通常每年至少更新一次），索引清單會列出RFC 1340被替換的時(shí)間?！ ? 2. Internet正式協(xié)議標(biāo)準(zhǔn)，目前是RFC 1600[Postel 1994]。這個(gè)RFC描述了各種Internet協(xié)議的標(biāo)準(zhǔn)化現(xiàn)狀。每種協(xié)議都處于下面幾種標(biāo)準(zhǔn)化狀態(tài)之一：標(biāo)準(zhǔn)，草案標(biāo)準(zhǔn)，提議標(biāo)準(zhǔn)，實(shí)驗(yàn)標(biāo)準(zhǔn)，信息標(biāo)準(zhǔn)，和歷史標(biāo)準(zhǔn)。另外，對每種協(xié)議都有一個(gè)要求的層次：必需的，建議的，可選擇的，限制使用的，或者不推薦的。 與賦值RFC一樣，這個(gè)RFC也定期更新。請一定隨時(shí)查看最新版本。 3. 主機(jī)需求RFC，1122和1123[Braden 1989a, 1989b]。RFC 1122針對鏈路層，網(wǎng)絡(luò)層和運(yùn)輸層，RFC 1123針對應(yīng)用層。這兩個(gè)RFC對早期重要的RFC文檔作了大量的糾正和解釋。如果要查看有關(guān)協(xié)議更詳細(xì)的細(xì)節(jié)內(nèi)容，它們通常是一個(gè)入口點(diǎn)。它們列出了協(xié)議中關(guān)于“必須”，“應(yīng)該”，“可以”，“不應(yīng)該”或者“不能”等特性及其實(shí)現(xiàn)細(xì)節(jié)。 文獻(xiàn)[Borman 1993b]提供了有關(guān)這兩個(gè)RFC的實(shí)用內(nèi)容。RFC 1127[Braden 1989c]對工作小組開發(fā)主機(jī)需求RFC過程中的討論內(nèi)容和結(jié)論進(jìn)行了非正式的總結(jié)。 4．路由器需求RFC，目前正式版是RFC 1009[Braden and Postel 1987]，但一個(gè)新版已接近完成[Aknqyust 1993]。它與主機(jī)需求RFC類似，但是只單獨(dú)描述了路由器的需求。 1.12 標(biāo)準(zhǔn)的簡單服務(wù) 有一些標(biāo)準(zhǔn)的簡單服務(wù)幾乎每種實(shí)現(xiàn)都要提供。在本書中我們將使用其中的一些服務(wù)程序，而客戶程序通常選擇Telnet。圖1.9描述了這些服務(wù)。從該圖我們可以看出，當(dāng)使用TCP和UDP提供相同的服務(wù)時(shí)，一般選擇相同的端口號. （下面是原書p.15①的譯文） 如果仔細(xì)檢查這些標(biāo)準(zhǔn)的簡單服務(wù)以及其他標(biāo)準(zhǔn)的TCP/IP服務(wù)（如Telnet, FTP, SMTP等）的端口號時(shí)，我們發(fā)現(xiàn)它們都是奇數(shù)。這是有歷史原因的，因?yàn)檫@些端口號都是從NCP端口號派生出來的。（NCP，即網(wǎng)絡(luò)控制協(xié)議，是ARPANET的運(yùn)輸層協(xié)議，是TCP的前身。NCP是單工的，不是全雙工的，因此每個(gè)應(yīng)用程序需要兩個(gè)連接，需預(yù)留一對奇數(shù)和偶數(shù)端口號。當(dāng)TCP和UDP成為標(biāo)準(zhǔn)的運(yùn)輸層協(xié)議時(shí)，每個(gè)應(yīng)用程序只需要一個(gè)端口號，因此就使用了NCP中的奇數(shù)。 （以下是原書p.16圖1.9的譯文） 名字 TCP端口號 UDP端口號 RFC 描述 echo 7 7 862 服務(wù)器返回客戶發(fā)送的所有內(nèi)容。 discard 9 9 863 服務(wù)器丟棄客戶發(fā)送的所有內(nèi)容。 daytime 13 13 867 服務(wù)器以可讀形式返回時(shí)間和日期。 chargen 19 19 864 當(dāng)客戶發(fā)送一個(gè)數(shù)據(jù)報(bào)時(shí)，TCP服務(wù)器發(fā)送一串連續(xù)的字符流，直到客戶中斷連接。UDP服務(wù)器發(fā)送一個(gè)隨機(jī)長度的數(shù)據(jù)報(bào)。 time 37 37 868 服務(wù)器返回一個(gè)二進(jìn)制形式的32 bit數(shù)，表示從UTC時(shí)間1900年1月1日午夜至今的秒數(shù)。 圖1.9 大多數(shù)實(shí)現(xiàn)都提供的標(biāo)準(zhǔn)的簡單服務(wù) 1.13 互連網(wǎng) 在圖1.3中，我們列舉了一個(gè)由兩個(gè)網(wǎng)絡(luò)組成的互連網(wǎng)－一個(gè)以太網(wǎng)和一個(gè)令牌環(huán)網(wǎng)。在1.4節(jié)和1.9節(jié)中，我們討論了世界范圍內(nèi)的互連網(wǎng)－Internet，以及集中分配IP地址的需要（InterNIC），還討論了著名的端口號（IANA）。internet這個(gè)詞第一個(gè)字母是否大寫決定了它具有不同的含義。 internet意思是用一個(gè)共同的協(xié)議族把多個(gè)網(wǎng)絡(luò)連接在一起。而Internet指的是世界范圍內(nèi)通過TCP/IP互相通信的所有主機(jī)集合（超過100萬臺）。Internet是一個(gè)internet（互連網(wǎng)），但internet不等于Internet。 1.14 實(shí)現(xiàn) 既成事實(shí)標(biāo)準(zhǔn)的TCP/IP軟件實(shí)現(xiàn)來自于位于伯克利的加利福尼亞大學(xué)的計(jì)算機(jī)系統(tǒng)研究小組。從歷史上看，軟件是隨同4.x BSD系統(tǒng)（Berkeley Software Distribution）的網(wǎng)絡(luò)版一起發(fā)布的。它的源代碼是許多其他實(shí)現(xiàn)的基礎(chǔ)。 圖1.10列舉了各種BSD版本發(fā)布的時(shí)間，并標(biāo)注了重要的TCP/IP特性。列在左邊的BSD網(wǎng)絡(luò)版，其所有的網(wǎng)絡(luò)源代碼可以公開得到：包括協(xié)議本身以及許多應(yīng)用程序和工具（如Telnet和FTP）。 在本書中，我們將使用“伯克利派生系統(tǒng)”來指SunOS 4.x, SVR4, 以及AIX 3.2等那些基于伯克利源代碼開發(fā)的系統(tǒng)。這些系統(tǒng)有很多共同之處，經(jīng)常包含相同的錯(cuò)誤。 （以下是原書p.17圖1.10的譯文） 4.2BSD (1983) 第一個(gè)廣泛可用的TCP/IP發(fā)布 4.3BSD (1986) TCP性能得到改善 4.3BSD Tahoe (1988) 啟動慢，擁塞避免措施 BSD網(wǎng)絡(luò)軟件1.0版(1989)：Net/1 4.3BSD Reno(1990) TCP首部預(yù)測，SLIP首部壓縮 路由表修改 BSD網(wǎng)絡(luò)軟件2.0版(1991)：Net/2 4.4BSD(1993) 多播，長胖管道修改 4.4BSD-Lite (1994) 又稱為Net/3 圖1.10 不同的BSD版及其重要的TCP/IP特性 起初關(guān)于Internet的很多研究現(xiàn)在仍然在伯克利系統(tǒng)中應(yīng)用－新的擁塞控制算法（21.7節(jié)），多目傳送（12.4節(jié)），“又長又胖的管道”修改（24.3節(jié)），以及其他類似的研究。 1.15 應(yīng)用編程接口 使用TCP/IP協(xié)議的應(yīng)用程序通常采用兩種應(yīng)用編程接口（API）：socket和TLI（運(yùn)輸層接口：Transport Layer Interface）。前者有時(shí)稱作“Berkeley socket”，表明它是從伯克利版發(fā)展而來的。后者起初是由AT&T開發(fā)的，有時(shí)稱作XTI（X/Open傳輸接口），以承認(rèn)X/Open這個(gè)自己定義標(biāo)準(zhǔn)的國際計(jì)算機(jī)生產(chǎn)產(chǎn)商所做的工作。XTI實(shí)際上是TLI的一個(gè)超集。 本書不是一本編程方面的書，但是偶爾會引用一些內(nèi)容來說明TCP/IP的特性，不管大多數(shù)的API（socket）是否提供它們。所有關(guān)于socket和TLI的編程細(xì)節(jié)請參閱文獻(xiàn)[Stevens 1990]。 1.16 測試網(wǎng)絡(luò) 圖1.11是本書中所有的例子運(yùn)行的測試網(wǎng)絡(luò)。為閱讀時(shí)參考方便，該圖還復(fù)制在本書的封面內(nèi)側(cè)。 圖1.11 本書例子運(yùn)行的測試網(wǎng)絡(luò)，所有的IP地址均從140.252開始編址。 在這個(gè)圖中（作者的子網(wǎng)），大多數(shù)的例子都運(yùn)行在下面四個(gè)系統(tǒng)中。圖中所有的IP地址屬于B類地址，網(wǎng)絡(luò)號為140.252。所有的主機(jī)名屬于.tuc.noao.edu這個(gè)域。（noao代表National Optical Astronomy Observatories，tuc代表Tucson）。例如，右下方的系統(tǒng)有一個(gè)完整的名字: svr4.tuc.noao.edu，其IP地址是：140.252.13.34。每個(gè)方框上方的名稱是該主機(jī)運(yùn)行的操作系統(tǒng)。這一組系統(tǒng)和網(wǎng)絡(luò)上的主機(jī)及路由器運(yùn)行于不同的TCP/IP實(shí)現(xiàn)。 需要指出的是，noao.edu這個(gè)域中的網(wǎng)絡(luò)和主機(jī)要比圖1.11中的多得多。這里列出來的只是本書中將要用到的系統(tǒng)。 在3.4節(jié)中，我們將描述這個(gè)網(wǎng)絡(luò)所用到的子網(wǎng)形式，在4.6中我們將更介紹sun與netb之間的拔號SLIP的有關(guān)細(xì)節(jié)。2.4節(jié)將詳細(xì)討論SLIP。 1.17 小結(jié) 本章快速地瀏覽了TCP/IP協(xié)議族，介紹了我們在后面的章節(jié)中將要詳細(xì)討論的許多術(shù)語和協(xié)議。 TCP/IP協(xié)議族分為四層：鏈路層，網(wǎng)絡(luò)層，運(yùn)輸層和應(yīng)用層，每一層各有不同的責(zé)任。在TCP/IP中，網(wǎng)絡(luò)層和運(yùn)輸層之間的區(qū)別是最為關(guān)鍵的：網(wǎng)絡(luò)層（IP）提供點(diǎn)到點(diǎn)的服務(wù)，而運(yùn)輸層（TCP和UDP）提供端到端的服務(wù)。 一個(gè)互連網(wǎng)是網(wǎng)絡(luò)的網(wǎng)絡(luò)。構(gòu)造互連網(wǎng)的共同基石是路由器，它們在IP層把網(wǎng)絡(luò)連在一起。第一個(gè)字母大寫的Internet是指分布在世界各地的大型互連網(wǎng)，其中包括1萬多個(gè)網(wǎng)絡(luò)和超過100萬臺主機(jī)。 在一個(gè)互連網(wǎng)上，每個(gè)接口都用IP地址來標(biāo)識，盡管用戶習(xí)慣使用主機(jī)名而不是IP地址。域名系統(tǒng)為主機(jī)名和IP地址之間提供動態(tài)的映射。端口號用來標(biāo)識互相通信的應(yīng)用程序。服務(wù)器使用眾所周知的端口號，而客戶使用臨時(shí)設(shè)定的端口號。 習(xí)題 1.1 請計(jì)算最多有多少個(gè)A類、B類和C類網(wǎng)絡(luò)號。 1.2 用匿名FTP（見27.3節(jié)）從主機(jī)nic.merit.edu 上獲取文件nsfnet/statistics/history.netcount。該文件包含在NSFNET網(wǎng)絡(luò)上登記的國內(nèi)和國外的網(wǎng)絡(luò)數(shù)。畫一坐標(biāo)系，橫坐標(biāo)代表年，縱坐標(biāo)代表網(wǎng)絡(luò)總數(shù)的對數(shù)值。縱坐標(biāo)的最大值是習(xí)題1.1的結(jié)果。如果數(shù)據(jù)顯示一個(gè)明顯的趨勢，請估計(jì)按照當(dāng)前的編址體制推算，何時(shí)會用完所有的網(wǎng)絡(luò)地址。（3.10節(jié)討論解決該難題的建議。） 1.3 獲取一份主機(jī)需求RFC拷貝[Braden 1989a]，閱讀有關(guān)應(yīng)用于TCP/IP協(xié)議族每一層的穩(wěn)健性原則。這個(gè)原則的參考對象是什么？ 1.4 獲取一份最新的賦值RFC拷貝?！皅uote of the day"協(xié)議的有名端口號是什么？哪個(gè)RFC對該協(xié)議進(jìn)行了定義？ 1.5 如果你有一個(gè)接入TCP/IP互連網(wǎng)的主機(jī)帳號，它的主IP地址是多少？這臺主機(jī)是否接入了Internet？它是多接口主機(jī)嗎？ 1.6 獲取一份RFC 1000的拷貝，了解RFC這個(gè)術(shù)語從何而來。 1.7 與Internet協(xié)會聯(lián)系， isoc@isoc.org 或者+1 703 648 9888，了解有關(guān)加入的情況。 1.8 用匿名FTP從主機(jī)is.internic.net處獲取文件about-internic/information-about-the-internic。 1－1 2 鏈路層 2.1 引言 從圖1.4我們可以看出，在TCP/IP協(xié)議族中，鏈路層主要有三個(gè)目的：（1）為IP模塊發(fā)送和接收IP數(shù)據(jù)報(bào)；（2）為ARP模塊發(fā)送ARP請求和接收ARP應(yīng)答；（3）為RARP發(fā)送RARP請求和接收RARP應(yīng)答。TCP/IP支持多種不同的鏈路層協(xié)議，這取決于網(wǎng)絡(luò)所使用的硬件，如以太網(wǎng)，令牌環(huán)網(wǎng)，F(xiàn)DDI（光纖分布式數(shù)據(jù)接口），RS－232串行線路等。 在本章中，我們將詳細(xì)討論以太網(wǎng)鏈路層協(xié)議，兩個(gè)串行接口鏈路層協(xié)議（SLIP和PPP），以及大多數(shù)實(shí)現(xiàn)都包含的環(huán)回（loopback）驅(qū)動程序。以太網(wǎng)和SLIP是本書中大多數(shù)例子使用的鏈路層。我們對MTU（最大傳輸單元）進(jìn)行了介紹，這個(gè)概念在本書的后面章節(jié)中將多次遇到。我們還討論了如何為串行線路選擇MTU。 2.2 以太網(wǎng)和IEEE 802封裝 以太網(wǎng)這個(gè)術(shù)語一般是指數(shù)字設(shè)備公司（Digital Equipment Corp.）、 英特爾公司（Intel Corp.）、和Xerox公司聯(lián)合在1982年公布的一個(gè)標(biāo)準(zhǔn)。它是當(dāng)今TCP/IP采用的主要的局域網(wǎng)技術(shù)。它采用一種稱作CSMA/CD的媒體接入方法，其意思是載波偵聽多路接入/沖突檢測（Carrier Sense, Multiple Access with Collision Detection）。它的速率為10 Mb/s，地址為48 bit。 幾年后，IEEE（電子電氣工程師協(xié)會）802委員會公布了一個(gè)稍有不同的標(biāo)準(zhǔn)集，其中802.3針對了整個(gè)CSMA/CD網(wǎng)絡(luò)，802.4針對令牌總線網(wǎng)絡(luò)，802.5針對令牌環(huán)網(wǎng)絡(luò)。這三者的共同特性由802.2標(biāo)準(zhǔn)來定義，那就是802網(wǎng)絡(luò)共有的邏輯鏈路控制（LLC）。不幸的是，802.2和802.3定義了一個(gè)與以太網(wǎng)不同的幀格式。文獻(xiàn)[Stallings 1987]對所有的IEEE 802標(biāo)準(zhǔn)進(jìn)行了詳細(xì)的介紹。 在TCP/IP世界中，以太網(wǎng)IP數(shù)據(jù)報(bào)的封裝是在RFC 894[Hornig 1984]中定義的，IEEE 802網(wǎng)絡(luò)的IP數(shù)據(jù)報(bào)封裝是在RFC 1042[Postel and Reynolds 1988]中定義的。主機(jī)需求RFC要求每臺Internet主機(jī)都與一個(gè)10Mbit/s的以太網(wǎng)電纜相連接： 1. 必須能發(fā)送和接收采用RFC 894（以太網(wǎng)）封裝格式的分組。 2. 應(yīng)該能接收與RFC 894混合的RFC 1042（IEEE 802）封裝格式的分組。 3. 也許能夠發(fā)送采用RFC 1042格式封裝的分組。如果主機(jī)能同時(shí)發(fā)送兩種類型的分組數(shù)據(jù)，那么發(fā)送的分組必須是可以設(shè)置的，而且默認(rèn)條件下必須是RFC 894分組。 最常使用的封裝格式是RFC 894定義的格式。圖2.1顯示了兩種不同形式的封裝格式。圖中每個(gè)方框下面的數(shù)字是它們的字節(jié)長度。 兩種幀格式都采用48 bit（6字節(jié)）的目標(biāo)地址和源地址。（802.3允許使用16 bit的地址，但一般是48 bit地址。）這就是我們在本書中所稱的硬件地址。ARP和RARP協(xié)議（第4章和第5章）對32 bit的IP地址和48 bit的硬件地址進(jìn)行映射。 接下來的2個(gè)字節(jié)在兩種幀格式中互不相同。在802標(biāo)準(zhǔn)定義的幀格式中，長度字段是指它后續(xù)數(shù)據(jù)的字節(jié)長度，但不包括CRC檢驗(yàn)碼。以太網(wǎng)的類型字段定義了后續(xù)數(shù)據(jù)的類型。在802標(biāo)準(zhǔn)定義的幀格式中，類型字段則由后續(xù)的子網(wǎng)接入?yún)f(xié)議（Sub-network Access Protocol，SNAP）的首部給出。幸運(yùn)的是，802定義的有效長度值與以太網(wǎng)的有效類型值無一相同，這樣，就可以對兩種幀格式進(jìn)行區(qū)分。 在以太網(wǎng)幀格式中，類型字段之后就是數(shù)據(jù)，而在802幀格式中，跟隨在后面的是3字節(jié)的802.2 LLC和5字節(jié)的802.2 SNAP。目的服務(wù)訪問點(diǎn)（Destination Service Access Point, DSAP）和源服務(wù)訪問點(diǎn)（Source Service Access Point, SSAP）的值都設(shè)為0xaa。ctrl字段的值設(shè)為3。隨后的3個(gè)字節(jié)org code都置為0。再接下來的2個(gè)字節(jié)類型字段和以太網(wǎng)幀格式一樣。（其他類型字段值可以參見RFC 1340 [Reynolds and Postel 1992]）。 CRC字段用于幀內(nèi)后續(xù)字節(jié)差錯(cuò)的循環(huán)冗余碼檢驗(yàn)（檢驗(yàn)和）。（它也被稱為FCS或幀檢驗(yàn)序列） 802.3標(biāo)準(zhǔn)定義的幀和以太網(wǎng)的幀都有最小長度要求。802.3規(guī)定數(shù)據(jù)部分必須至少為38字節(jié)，而對于以太網(wǎng)，則要求最少要有46字節(jié)。為了保證這一點(diǎn)，必須在不足的空間插入填充（pad）字節(jié)。我們在開始觀察線路上的分組時(shí)將遇到這種最小長度的情況。 在本書中，我們在需要的時(shí)候?qū)⒔o出以太網(wǎng)的封裝格式，因?yàn)檫@是最為常見的封裝格式。 圖2.1 IEEE 802.2/802.3（RFC 1042）和以太網(wǎng)的封裝格式（RFC 894） 2.3 尾部封裝 RFC 893[Leffler and Karels 1984]描述了另一種用于以太網(wǎng)的封裝格式，稱作尾部封裝（trailer encapsulation）。這是一個(gè)早期BSD系統(tǒng)在DEC VAX機(jī)上運(yùn)行時(shí)的試驗(yàn)格式，它通過調(diào)整IP數(shù)據(jù)報(bào)中字段的次序來提高性能。在以太網(wǎng)數(shù)據(jù)幀中，開始的那部分是變長的字段（IP首部和TCP首部）。把它們移到尾部（在CRC之前），這樣當(dāng)把數(shù)據(jù)復(fù)制到內(nèi)核時(shí)，就可以把數(shù)據(jù)幀中的數(shù)據(jù)部分映射到一個(gè)硬件頁面，節(jié)省內(nèi)存到內(nèi)存的復(fù)制過程。TCP數(shù)據(jù)報(bào)的長度是512字節(jié)的整數(shù)倍，正好可以用內(nèi)核中的頁表來處理。兩臺主機(jī)通過協(xié)商使用ARP擴(kuò)展協(xié)議對數(shù)據(jù)幀進(jìn)行尾部封裝。這些數(shù)據(jù)幀需定義不同的以太網(wǎng)幀類型值。 現(xiàn)在，尾部封裝已遭到反對，因此我們不對它舉任何例子。有興趣的讀者請參閱RFC 893以及文獻(xiàn)[Leffler et al. 1989]的11.8節(jié)。 2.4 SLIP：串行線路IP SLIP的全稱是Serial Line IP。它是一種在串行線路上對IP數(shù)據(jù)報(bào)進(jìn)行封裝的簡單形式，在RFC 1055[Romkey 1988]中有詳細(xì)描述。SLIP適用于家庭中每臺計(jì)算機(jī)幾乎都有的RS-232串行端口和高速調(diào)制解調(diào)器接入Internet。 下面的規(guī)則描述了SLIP協(xié)議定義的幀格式： 1．IP數(shù)據(jù)報(bào)以一個(gè)稱作END（0xc0）的特殊字符結(jié)束。同時(shí)，為了防止數(shù)據(jù)報(bào)到來之前的線路噪聲被當(dāng)成數(shù)據(jù)報(bào)內(nèi)容，大多數(shù)實(shí)現(xiàn)在數(shù)據(jù)報(bào)的開始處也傳一個(gè)END字符。（如果有線路噪聲，那么END字符將結(jié)束這份錯(cuò)誤的報(bào)文。這樣當(dāng)前的報(bào)文得以正確的傳輸，而前一個(gè)錯(cuò)誤報(bào)文交給上層后，會被發(fā)現(xiàn)其內(nèi)容毫無意義而被丟棄。） 2．如果IP報(bào)文中某個(gè)字符為END，那么就要連續(xù)傳輸兩個(gè)字節(jié)0xdb, 0xdc來取代它。0xdb這個(gè)特殊字符被稱作SLIP的ESC字符，但是它的值與ASCII碼的ESC字符（0x1b）不同。 3． 如果IP報(bào)文中某個(gè)字符為SLIP的ESC字符，那么就要連續(xù)傳輸兩個(gè)字節(jié)0xdb,0xdd來取代它。 圖2.2中的例子就是含有一個(gè)END字符和一個(gè)ESC字符的IP報(bào)文。在這個(gè)例子中，在串行線路上傳輸?shù)目傋止?jié)數(shù)是原IP報(bào)文長度再加4個(gè)字節(jié)。 SLIP是一種簡單的幀封裝方法，還有一些值得一提的缺陷： 1. 每一端必須知道對方的IP地址。沒有辦法把本端的IP地址通知給另一端。 2. 數(shù)據(jù)幀中沒有類型字段（類似于以太網(wǎng)中的類型字段）。如果一條串行線路用于SLIP，那么它不能同時(shí)使用其他協(xié)議。 3. SLIP沒有在數(shù)據(jù)幀中加上檢驗(yàn)和（類似于以太網(wǎng)中的CRC字段）。如果SLIP傳輸?shù)膱?bào)文被線路噪聲影響而發(fā)生錯(cuò)誤，只能通過上層協(xié)議來發(fā)現(xiàn)。（另一種方法是，新型的調(diào)制解調(diào)器可以檢測并糾正錯(cuò)誤報(bào)文。）這樣，上層協(xié)議提供某種形式的CRC就顯得很重要。在第3章和第17章中，我們將看到IP首部和TCP首部及其數(shù)據(jù)始終都有檢驗(yàn)和。在第11章中，我們將看到UDP首部及其數(shù)據(jù)的檢驗(yàn)和卻是可選的。 圖2.2 SLIP報(bào)文的封裝 盡管存在這些缺點(diǎn)，SLIP仍然是一種廣泛使用的協(xié)議。 （下面是原書p.25①的譯文） SLIP的歷史要追溯到1984年，Rick Adams第一次在4.2BSD系統(tǒng)中實(shí)現(xiàn)。盡管它本身的描述是一種非標(biāo)準(zhǔn)的協(xié)議，但是隨著調(diào)制解調(diào)器的速率和可靠性的提高，SLIP越來越流行?，F(xiàn)在，它的許多產(chǎn)品可以公開獲得，而且很多產(chǎn)家都支持這種協(xié)議。 2.5 壓縮的SLIP 由于串行線路的速率通常較低（19200 b/s或更低），而且通信經(jīng)常是交互式的（如Telnet和Rlogin，二者都使用TCP），因此在SLIP線路上有許多小的TCP分組進(jìn)行交換。為了傳送1個(gè)字節(jié)的數(shù)據(jù)需要20個(gè)字節(jié)的IP首部和20個(gè)字節(jié)的TCP首部，總數(shù)超過40個(gè)字節(jié)。（19.2節(jié)描述了Rlogin會話過程中，當(dāng)敲入一個(gè)簡單命令時(shí)這些小報(bào)文傳輸?shù)脑敿?xì)情況。） 既然承認(rèn)這些性能上的缺陷，于是人們提出一個(gè)被稱作CSLIP（即壓縮SLIP）的新協(xié)議，它在RFC 1144[Jacobson 1990a]中被詳細(xì)描述。CSLIP一般能把上面的40個(gè)字節(jié)壓縮到3或5個(gè)字節(jié)。它能在CSLIP的每一端維持多達(dá)16個(gè)TCP連接，并且知道其中每個(gè)連接的首部中的某些字段一般不會發(fā)生變化。對于那些發(fā)生變化的字段，大多數(shù)只是一些小的數(shù)字和的改變。這些被壓縮的首部大大地縮短了交互響應(yīng)時(shí)間。 （下面是原書p.25②的譯文） 現(xiàn)在大多數(shù)的SLIP產(chǎn)品都支持CSLIP。作者所在的子網(wǎng)（參見封面內(nèi)頁）中有兩條SLIP鏈路，它們均是CSLIP鏈路。 2.6 PPP：點(diǎn)對點(diǎn)協(xié)議 PPP，點(diǎn)對點(diǎn)協(xié)議修改了SLIP協(xié)議中的所有缺陷。PPP包括以下三個(gè)部分： 1．在串行鏈路上封裝IP數(shù)據(jù)報(bào)的方法。PPP既支持?jǐn)?shù)據(jù)為8位和無奇偶檢驗(yàn)的異步模式（如大多數(shù)計(jì)算機(jī)上都普遍存在的串行接口），還支持面向比特的同步鏈接。 2．建立、配置及測試數(shù)據(jù)鏈路的鏈路控制協(xié)議（LCP：Link Control Protocol）。它允許通信雙方進(jìn)行協(xié)商，以確定不同的選項(xiàng)。 3．針對不同網(wǎng)絡(luò)層協(xié)議的網(wǎng)絡(luò)控制協(xié)議（NCP：Network Control Protocol）體系。當(dāng)前RFC定義的網(wǎng)絡(luò)層有IP，OSI網(wǎng)絡(luò)層，DECnet，以及AppleTalk。例如，IP NCP允許雙方商定是否對報(bào)文首部進(jìn)行壓縮，類似于CSLIP。（縮寫詞NCP也可用在TCP的前面）。 RFC 1548[Simpson 1993]描述了報(bào)文封裝的方法和鏈路控制協(xié)議。RFC 1332[McGregor 1992]描述了針對IP的網(wǎng)絡(luò)控制協(xié)議。 PPP數(shù)據(jù)幀的格式看上去很像ISO的HDLC（高層數(shù)據(jù)鏈路控制）標(biāo)準(zhǔn)。圖2.3是PPP數(shù)據(jù)幀的格式。 圖2.3 PPP數(shù)據(jù)幀的格式 每一幀都以標(biāo)志字符0x7e開始和結(jié)束。緊接著是一個(gè)地址字節(jié)，值始終是0xff，然后是一個(gè)值為0x03的控制字節(jié)。 接下來是協(xié)議字段，類似于以太網(wǎng)中類型字段的功能。當(dāng)它的值為0x0021時(shí)表示信息字段是一個(gè)IP數(shù)據(jù)報(bào)，值為0xc021時(shí)表示信息字段是鏈路控制數(shù)據(jù)，值為0x8021時(shí)表示信息字段是網(wǎng)絡(luò)控制數(shù)據(jù)。 CRC字段（或FCS，幀校驗(yàn)序列）是一個(gè)循環(huán)冗余檢驗(yàn)碼，以檢測數(shù)據(jù)幀中的錯(cuò)誤。 由于標(biāo)志字符的值是0x7e，因此當(dāng)該字符出現(xiàn)在信息字段中時(shí)，PPP需要對它進(jìn)行轉(zhuǎn)義。在同步鏈路中，該過程是通過一種稱作比特填充(bit stuffing)的硬件技術(shù)來完成的[Tanenbaum 1989]。在異步鏈路中，特殊字符0x7d用作轉(zhuǎn)義字符。當(dāng)它出現(xiàn)在PPP數(shù)據(jù)幀中時(shí)，那么緊接著的字符的第六個(gè)比特要取其補(bǔ)碼，具體實(shí)現(xiàn)過程如下： 1. 當(dāng)遇到字符0x7e時(shí)，需連續(xù)傳送兩個(gè)字符：0x7d和0x5e，以實(shí)現(xiàn)標(biāo)志字符的轉(zhuǎn)義。 2. 當(dāng)遇到轉(zhuǎn)義字符0x7d時(shí)，需連續(xù)傳送兩個(gè)字符：0x7d和0x5d，以實(shí)現(xiàn)轉(zhuǎn)義字符的轉(zhuǎn)義。 3. 默認(rèn)情況下，如果字符的值小于0x20（比如，一個(gè)ASCII控制字符），一般都要進(jìn)行轉(zhuǎn)義。例如，遇到字符0x01時(shí)需連續(xù)傳送0x7d和0x21兩個(gè)字符。（這時(shí)，第六個(gè)比特取補(bǔ)碼后變?yōu)?，而前面兩種情況均把它變?yōu)?。） 這樣做的原因是防止它們出現(xiàn)在雙方主機(jī)的串行接口驅(qū)動程序或調(diào)制解調(diào)器中，因?yàn)橛袝r(shí)它們會把這些控制字符解釋成特殊的含義。另一種可能是用鏈路控制協(xié)議來指定是否需要對這32個(gè)字符中的某一些值進(jìn)行轉(zhuǎn)義。默認(rèn)情況下是對所有的32個(gè)字符都進(jìn)行轉(zhuǎn)義。 與SLIP類似，由于PPP經(jīng)常用于低速的串行鏈路，因此減少每一幀的字節(jié)數(shù)可以降低應(yīng)用程序的交互時(shí)延。利用鏈路控制協(xié)議，大多數(shù)的產(chǎn)品通過協(xié)商可以省略標(biāo)志符和地址字段，并且把協(xié)議字段由2個(gè)字節(jié)減少到1個(gè)字節(jié)。如果我們把PPP的幀格式與前面的SLIP的幀格式（圖2.2）進(jìn)行比較會發(fā)現(xiàn)，PPP只增加了3個(gè)額外的字節(jié)：1個(gè)字節(jié)留給協(xié)議字段，另2個(gè)給CRC字段使用。另外，使用IP網(wǎng)絡(luò)控制協(xié)議，大多數(shù)的產(chǎn)品可以通過協(xié)商采用Van Jacobson報(bào)文首部壓縮方法（對應(yīng)于CSLIP壓縮），減小IP和TCP首部長度。 總的來說，PPP比SLIP具有下面這些優(yōu)點(diǎn)：（1）PPP支持在單根串行線路上運(yùn)行多種協(xié)議，不只是IP協(xié)議；（2）每一幀都有循環(huán)冗余檢驗(yàn)；（3）通信雙方可以進(jìn)行IP地址的動態(tài)協(xié)商（使用IP網(wǎng)絡(luò)控制協(xié)議）；（4）與CSLIP類似，對TCP和IP報(bào)文首部進(jìn)行壓縮；（5）鏈路控制協(xié)議可以對多個(gè)數(shù)據(jù)鏈路選項(xiàng)進(jìn)行設(shè)置。為這些優(yōu)點(diǎn)我們付出的代價(jià)是在每一幀的首部增加3個(gè)字節(jié)，當(dāng)建立鏈路時(shí)要發(fā)送幾幀協(xié)商數(shù)據(jù)，以及更為復(fù)雜的實(shí)現(xiàn)。 （下面是原書p.27①的譯文） 盡管PPP比SLIP有更多的優(yōu)點(diǎn)，但是現(xiàn)在的SLIP用戶仍然比PPP用戶多。隨著產(chǎn)品越來越多，產(chǎn)家也開始逐漸支持PPP，因此最終PPP應(yīng)該取代SLIP。 2.7 環(huán)回接口 大多數(shù)的產(chǎn)品都支持環(huán)回接口（Loopback Interface），以允許運(yùn)行在同一臺主機(jī)上的客戶程序和服務(wù)器程序通過TCP/IP進(jìn)行通信。A類網(wǎng)絡(luò)號127就是為環(huán)回接口預(yù)留的。根據(jù)慣例，大多數(shù)系統(tǒng)把IP地址127.0.0.1分配給這個(gè)接口，并命名為localhost。一個(gè)傳給環(huán)回接口的IP數(shù)據(jù)報(bào)不能在任何網(wǎng)絡(luò)上出現(xiàn)。 我們想象，一旦傳輸層檢測到目的端地址是環(huán)回地址時(shí)，應(yīng)該可以省略部分傳輸層和所有網(wǎng)絡(luò)層的邏輯操作。但是大多數(shù)的產(chǎn)品還是照樣完成傳輸層和網(wǎng)絡(luò)層的所有過程，只是當(dāng)IP數(shù)據(jù)報(bào)離開網(wǎng)絡(luò)層時(shí)把它返回給自己。 圖2.4是環(huán)回接口處理IP數(shù)據(jù)報(bào)的簡單過程。 圖2.4 環(huán)回接口處理IP數(shù)據(jù)報(bào)的過程 需要指出圖中的關(guān)鍵點(diǎn)是： 1. 傳給環(huán)回地址（一般是127.0.0.1 ）的任何數(shù)據(jù)均作為IP輸入。 2. 傳給廣播地址或多播地址的數(shù)據(jù)報(bào)復(fù)制一份傳給環(huán)回接口，然后送到以太網(wǎng)上。這是因?yàn)閺V播傳送和多播傳送的定義（第12章）包含主機(jī)本身。 3. 任何傳給該主機(jī)IP地址的數(shù)據(jù)均送到環(huán)回接口。 看上去用傳輸層和IP層的方法來處理環(huán)回?cái)?shù)據(jù)似乎效率不高，但它簡化了設(shè)計(jì)，因?yàn)榄h(huán)回接口可以被看作是網(wǎng)絡(luò)層下面的另一個(gè)鏈路層。網(wǎng)絡(luò)層把一份數(shù)據(jù)報(bào)傳送給環(huán)回接口，就像傳給其他鏈路層一樣，只不過環(huán)回接口把它返回到IP的輸入隊(duì)列中。 在圖2.4中，另一個(gè)隱含的意思是送給主機(jī)本身IP地址的IP數(shù)據(jù)報(bào)一般不出現(xiàn)在相應(yīng)的網(wǎng)絡(luò)上。例如，在一個(gè)以太網(wǎng)上，分組一般不被傳出去然后讀回來。某些BSD以太網(wǎng)的設(shè)備驅(qū)動程序的注釋說明，許多以太網(wǎng)接口卡不能讀回它們自己發(fā)送出去的數(shù)據(jù)。由于一臺主機(jī)必須處理發(fā)送給自己的IP數(shù)據(jù)報(bào)，因此圖2.4所示的過程是最為簡單的處理辦法。 （下面是原書p.29①的譯文） 4.4BSD系統(tǒng)定義了變量useloopback，并初始化為1。但是，如果這個(gè)變量置為0，以太網(wǎng)驅(qū)動程序就會把本地分組送到網(wǎng)絡(luò)，而不是送到環(huán)回接口上。它也許不能工作，這取決于你所使用的以太網(wǎng)接口卡和設(shè)備驅(qū)動程序。 2.8 最大傳輸單元MTU 正如我們在圖2.1看到的那樣，以太網(wǎng)和802.3對數(shù)據(jù)幀的長度都有一個(gè)限制，其最大值分別是1500和1492字節(jié)。鏈路層的這個(gè)特性稱作MTU，最大傳輸單元。不同類型的網(wǎng)絡(luò)大多數(shù)都有一個(gè)上限。 如果IP層有一個(gè)數(shù)據(jù)報(bào)要傳，而且數(shù)據(jù)的長度比鏈路層的MTU還大，那么IP層就需要進(jìn)行分片（fragmentation），把數(shù)據(jù)報(bào)分布若干片，這樣每一片都小于MTU。我們將在11.5節(jié)討論IP分片的過程。 圖2.5列出了一些典型的MTU值，它們摘自RFC 1191[Mogul and Deering 1990]。點(diǎn)到點(diǎn)的鏈路層（如SLIP和PPP）的MTU并非指的是網(wǎng)絡(luò)媒體的物理特性。相反，它是一個(gè)邏輯限制，目的是為交互使用提供足夠快的響應(yīng)時(shí)間。在2.10節(jié)中，我們將看到這個(gè)限制值是如何計(jì)算出來的。 在3.9節(jié)中，我們將用netstat命令打印出網(wǎng)絡(luò)接口的MTU。 圖2.5 幾種常見的最大傳輸單元（MTU） 2.9 路徑MTU 當(dāng)在同一個(gè)網(wǎng)絡(luò)上的兩臺主機(jī)互相進(jìn)行通信時(shí)，該網(wǎng)絡(luò)的MTU是非常重要的。但是如果兩臺主機(jī)之間的通信要通過多個(gè)網(wǎng)絡(luò)，那么每個(gè)網(wǎng)絡(luò)的鏈路層就可能有不同的MTU。重要的不是兩臺主機(jī)所在網(wǎng)絡(luò)的MTU的值，重要的是兩臺通信主機(jī)路徑中的最小MTU。它被稱作路徑MTU。 兩臺主機(jī)之間的路徑MTU不一定是個(gè)常數(shù)。它取決于當(dāng)時(shí)所選擇的路由。而路由選擇不一定是對稱的（從A到B的路由可能與從B到A的路由不同），因此路徑MTU在兩個(gè)方向上不一定是一致的。 RFC 1191[Mogul and Deering 1990]描述了路徑MTU的發(fā)現(xiàn)機(jī)制，即在任何時(shí)候確定路徑MTU的方法。我們在介紹了ICMP和IP分片方法以后再來看它是如何操作的。在11.6節(jié)中，我們將看到ICMP的不可到達(dá)錯(cuò)誤就采用這種發(fā)現(xiàn)方法。在11.7節(jié)中，我們還會看到，traceroute程序也是用這個(gè)方法來確定到達(dá)目標(biāo)節(jié)點(diǎn)的路徑MTU。在 11.8節(jié)和24.2節(jié)，我們將介紹當(dāng)產(chǎn)品支持路徑MTU的發(fā)現(xiàn)方法時(shí)，UDP和TCP是如何進(jìn)行操作的。 2.10 串行線路吞吐量計(jì)算 如果線路速率是9600 b/s，而一個(gè)字節(jié)有8 bit，加上一個(gè)起始比特和一個(gè)停止比特，那么線路的速率就是960 B/s（字節(jié)/秒）。以這個(gè)速率傳輸一個(gè)1024字節(jié)的分組需要1066 ms。如果我們用SLIP鏈接運(yùn)行一個(gè)交互式應(yīng)用程序，同時(shí)還運(yùn)行另一個(gè)應(yīng)用程序如FTP發(fā)送或接收1024字節(jié)的數(shù)據(jù)，那么一般來說我們就必須等待一半的時(shí)間（533 ms）才能把交互式應(yīng)用程序的分組數(shù)據(jù)發(fā)送出去。 假定我們的交互分組數(shù)據(jù)可以在其它“大塊”分組數(shù)據(jù)發(fā)送之前被發(fā)送出去。大多數(shù)的SLIP實(shí)現(xiàn)確實(shí)提供這類服務(wù)排隊(duì)方法，把交互數(shù)據(jù)放在大塊的數(shù)據(jù)前面。交互通信一般有Telnet，Rlogin，以及FTP的控制部分（用戶的命令，而不是數(shù)據(jù)）。 （下面是原書p.31①的譯文） 這種服務(wù)排隊(duì)方法是不完善的。它不能影響已經(jīng)進(jìn)入下游（如串行驅(qū)動程序）隊(duì)列的非交互數(shù)據(jù)。同時(shí)，新型的調(diào)制解調(diào)器具有很大的緩沖區(qū)，因此非交互數(shù)據(jù)可能已經(jīng)進(jìn)入該緩沖區(qū)了。 對于交互應(yīng)用來說，等待533 ms是不能接受的。關(guān)于人的有關(guān)研究表明，交互響應(yīng)時(shí)間超過100-200 ms就被認(rèn)為是不好的[Jacobson 1990a]。這是發(fā)送一份交互報(bào)文出去后，直到接收到響應(yīng)信息（通常是出現(xiàn)一個(gè)回顯字符）為止的往返時(shí)間。 把SLIP的MTU縮短到256就意味著鏈路傳輸一幀最長需要266 ms，它的一半是133 ms（這是我們一般需要等待的時(shí)間）。這樣情況會好一些，但仍然不完美。我們選擇它的原因（與64或128相比）是因?yàn)榇髩K數(shù)據(jù)提供良好的線路利用率（如大文件傳輸）。假設(shè)CSLIP的報(bào)文首部是5個(gè)字節(jié)，數(shù)據(jù)幀總長為261個(gè)字節(jié)，256個(gè)字節(jié)的數(shù)據(jù)使線路的利用率為98.1%，幀頭占了1.9%，這樣的利用率是很不錯(cuò)。如果把MTU降到256以下，那么將降低傳輸大塊數(shù)據(jù)的最大吞吐量。 在圖2.5列出的MTU值中，點(diǎn)對點(diǎn)鏈路的MTU是296個(gè)字節(jié)。假設(shè)數(shù)據(jù)為256字節(jié)，TCP和IP首部占40個(gè)字節(jié)。由于MTU是IP向鏈路層查詢的結(jié)果，因此該值必須包括通常的TCP和IP首部。這樣就會導(dǎo)致IP如何進(jìn)行分片的決策。IP對于CSLIP的壓縮情況一無所知。 我們對平均等待時(shí)間的計(jì)算（傳輸最大數(shù)據(jù)幀所需時(shí)間的一半）只適用于SLIP鏈路（或PPP鏈路）在交互通信和大塊數(shù)據(jù)傳輸這兩種情況下。當(dāng)只有交互通信時(shí)，如果線路速率是9600 b/s，那么任何方向上的1字節(jié)數(shù)據(jù)（假設(shè)有5個(gè)字節(jié)的壓縮幀頭）往返一次都大約需要12.5 ms。它比前面提到的100-200 ms足夠小。需要注意的是，由于幀頭從40個(gè)字節(jié)壓縮到5個(gè)字節(jié)，使得1字節(jié)數(shù)據(jù)往返時(shí)間從85 ms減到12.5 ms。 不幸的是，當(dāng)使用新型的糾錯(cuò)和壓縮調(diào)制解調(diào)器時(shí)，這樣的計(jì)算就更難了。這些調(diào)制解調(diào)器所采用的壓縮方法使得在線路上傳輸?shù)淖止?jié)數(shù)大大減少，但糾錯(cuò)機(jī)制又會增加傳輸?shù)臅r(shí)間。不過，這些計(jì)算是我們進(jìn)行合理決策的入口點(diǎn)。 在后面的章節(jié)中，我們將用這些串行線路吞吐量的計(jì)算來驗(yàn)證數(shù)據(jù)從串行線路止通過的時(shí)間。 2.11 小結(jié) 本章討論了Internet協(xié)議族中的最底層協(xié)議，鏈路層協(xié)議。我們比較了以太網(wǎng)和IEEE 802.2/802.3的封裝格式，以及SLIP和PPP的封裝格式。由于SLIP和PPP經(jīng)常用于低速的鏈路，二者都提供了壓縮不常變化的公共字段的方法。這使交互性能得到提高。 大多數(shù)的實(shí)現(xiàn)都提供環(huán)回接口。訪問這個(gè)接口可以通過特殊的環(huán)回地址，一般為127.0.0.1，也可以通過發(fā)送IP數(shù)據(jù)報(bào)給主機(jī)所擁有的任一IP地址。當(dāng)環(huán)回?cái)?shù)據(jù)回到上層的協(xié)議棧中時(shí)，它已經(jīng)過傳輸層和IP層完整的處理過程。 我們描述了很多鏈路都具有一個(gè)重要特性，MTU，相關(guān)的一個(gè)概念是路徑MTU。根據(jù)典型的串行線路MTU，我們對SLIP和CSLIP鏈路的傳輸時(shí)延進(jìn)行了計(jì)算。 本章內(nèi)容只覆蓋了當(dāng)今TCP/IP所采用部分?jǐn)?shù)據(jù)鏈路公共技術(shù)。TCP/IP成功的原因之一是它幾乎能在任何數(shù)據(jù)鏈路技術(shù)上運(yùn)行。 習(xí)題 2.1 如果你的系統(tǒng)支持netstat(1)命令（參見3.9小節(jié)），那么請用它確定系統(tǒng)上的接口及其MTU。 2－1 3 IP：網(wǎng)際協(xié)議 3.1 引言 IP是TCP/IP協(xié)議族中最為核心的協(xié)議。所有的TCP，UDP，ICMP，及IGMP數(shù)據(jù)都以IP數(shù)據(jù)報(bào)格式傳輸（圖1.4）。許多剛開始接觸TCP/IP的人對IP提供不可靠、無連接的數(shù)據(jù)報(bào)傳送服務(wù)感到很奇怪，特別是那些具有X.25或SNA背景知識的人。 不可靠（unreliable）的意思是它不能保證IP數(shù)據(jù)報(bào)能成功地到達(dá)目的地。IP僅提供最好的傳輸服務(wù)。如果發(fā)生某種錯(cuò)誤時(shí)，如某個(gè)路由器暫時(shí)用完了緩沖區(qū)，IP有一個(gè)簡單的錯(cuò)誤處理算法：丟棄該數(shù)據(jù)報(bào)，然后發(fā)送ICMP消息報(bào)給信源端。任何要求的可靠性必須由上層來提供（如TCP）。 無連接（connectionless）這個(gè)術(shù)語的意思是IP并不維護(hù)任何關(guān)于后續(xù)數(shù)據(jù)報(bào)的狀態(tài)信息。每個(gè)數(shù)據(jù)報(bào)的處理是相互獨(dú)立的。這也說明，IP數(shù)據(jù)報(bào)可以不按發(fā)送順序接收。如果一信源向相同的信宿發(fā)送兩個(gè)連續(xù)的數(shù)據(jù)報(bào)（先是A，然后是B），每個(gè)數(shù)據(jù)報(bào)都是獨(dú)立地進(jìn)行路由選擇，可能選擇不同的路線，因此B可能在A到達(dá)之前先到達(dá)。 在本章，我們將簡要介紹IP首部中的各個(gè)字段，討論IP路由選擇和子網(wǎng)的有關(guān)內(nèi)容。我們還要介紹兩個(gè)有用的命令：ifconfig和netstat。關(guān)于IP首部中一些字段的細(xì)節(jié)，我們將留在以后使用這些字段的時(shí)候再進(jìn)行討論。RFC 791[Postel 1981a]是IP的正式規(guī)約文件。 3.2 IP首部 IP數(shù)據(jù)報(bào)的格式如圖3.1所示。普通的IP首部長為20個(gè)字節(jié)，除非含有選項(xiàng)字段。 圖3.1 IP數(shù)據(jù)報(bào)格式及首部中的各字段 我們來分析圖3.1中的首部。最高位在左邊，記為0 bit，最低位在右邊，記為31 bit。 4個(gè)字節(jié)的32 bit值以下面的次序傳輸：首先是0-7 bit，其次8-15 bit，然后16-23 bit，最后是24-31 bit。這種傳輸次序稱作big endian字節(jié)次序。由于TCP/IP首部中所有的二進(jìn)制整數(shù)在網(wǎng)絡(luò)中傳輸時(shí)都要求以這種次序，因此它又稱作網(wǎng)絡(luò)字節(jié)次序。以其他形式存儲二進(jìn)制整數(shù)的機(jī)器，如little endian格式，則必須在傳輸數(shù)據(jù)之前把首部轉(zhuǎn)換成網(wǎng)絡(luò)字節(jié)次序。 目前的協(xié)議版本號是4，因此IP有時(shí)也稱作IPv4。3.10節(jié)將對一種新版的IP協(xié)議進(jìn)行討論。 首部長度指的是首部占32 bit字的數(shù)目，包括任何先期選項(xiàng)。由于它是一個(gè)4比特字段，因此首部最長為60個(gè)字節(jié)。在第8章中，我們將看到這種限制使某些選項(xiàng)如路由記錄選項(xiàng)在當(dāng)今已沒有什么用處。普通IP數(shù)據(jù)報(bào)（沒有任何選擇項(xiàng)）該字段的值是5。 服務(wù)類型（TOS）字段包括一個(gè)3 bit的優(yōu)先權(quán)子字段（現(xiàn)在已被忽略），4 bit的TOS子字段，和1 bit未用位但必須置0。4 bit的TOS分別代表：最小時(shí)延，最大吞吐量，最高可靠性，最小費(fèi)用。4 bit中只能置其中1 bit。如果所有4 bit均為0，那么就意味著是普遍服務(wù)。RFC 1340 [Reynolds and Postel 1992]描述了所有的標(biāo)準(zhǔn)應(yīng)用如何設(shè)置這些服務(wù)類型。RFC 1349 [Almquist 1992]對該RFC進(jìn)行了修正，更為詳細(xì)地描述了TOS的特性。 圖3.2列出了對不同應(yīng)用建議的TOS值。在最后一列中，我們給出的是十六進(jìn)制值，因?yàn)檫@就是在后面我們將要看到的tcpdump命令輸出。 圖3.2 服務(wù)類型字段推薦值 Telnet和Rlogin這兩個(gè)交互應(yīng)用要求最小的傳輸時(shí)延，因?yàn)槿藗冎饕盟鼈儊韨鬏斏倭康慕换?shù)據(jù)。另一方面，F(xiàn)TP文件傳輸則要求有最大的吞吐量。最高可靠性被指明給網(wǎng)絡(luò)管理（SNMP）和路由選擇協(xié)議。用戶網(wǎng)絡(luò)新聞（Usenet news, NNTP）是唯一要求最小費(fèi)用的應(yīng)用。 現(xiàn)在大多數(shù)的TCP/IP實(shí)現(xiàn)都不支持TOS特性，但是自4.3BSD Reno以后的新版系統(tǒng)都對它進(jìn)行了設(shè)置。另外，新的路由協(xié)議如OSPF和IS-IS都能根據(jù)這些字段的值進(jìn)行路由決策。 （下面是原書p.35①的譯文） 在2.10節(jié)中，我們提到SLIP一般提供基于服務(wù)類型的排隊(duì)方法，允許對交互通信數(shù)據(jù)在處理大塊數(shù)據(jù)之前進(jìn)行處理。由于大多數(shù)的實(shí)現(xiàn)都不使用TOS字段，因此這種排隊(duì)機(jī)制由SLIP自己來判斷和處理，驅(qū)動程序先查看協(xié)議字段（確定是否是一個(gè)TCP段），然后檢查TCP信源和信宿的端口號，以判斷是否是一個(gè)交互服務(wù)。一個(gè)驅(qū)動程序的注釋這樣認(rèn)為，這種“令人厭惡的處理方法”是必需的，因?yàn)榇蠖鄶?shù)實(shí)現(xiàn)都不允許應(yīng)用程序設(shè)置TOS字段。 總長度字段是指整個(gè)IP數(shù)據(jù)報(bào)的長度，以字節(jié)為單位。利用首部長度字段和總長度字段，我們就可以知道IP數(shù)據(jù)報(bào)中數(shù)據(jù)內(nèi)容的起始位置和長度。由于該字段長16比特，所以IP數(shù)據(jù)報(bào)最長可達(dá)65535字節(jié)。（回憶圖2.5，超級通道的MTU為65535。它的意思其實(shí)不是一個(gè)真正的MTU－—它使用了最長的IP數(shù)據(jù)報(bào)。）當(dāng)數(shù)據(jù)報(bào)被分片時(shí)，該字段的值也隨著變化，這一點(diǎn)我們將在11.5節(jié)中進(jìn)一步描述。 盡管可以傳送一個(gè)長達(dá)65535字節(jié)的IP數(shù)據(jù)報(bào)，但是大多數(shù)的鏈路層都會對它進(jìn)行分片。而且，主機(jī)也要求不能接收超過576字節(jié)的數(shù)據(jù)報(bào)。由于TCP把用戶數(shù)據(jù)分成若干片，因此一般來說這個(gè)限制不會影響TCP。我們在后面的章節(jié)中將遇到大量使用UDP的應(yīng)用（RIP，TFTP，BOOTP，DNS，以及SNMP），它們都限制用戶數(shù)據(jù)報(bào)長度為512字節(jié)，小于576字節(jié)。但是，事實(shí)上現(xiàn)在大多數(shù)的實(shí)現(xiàn)（特別是那些支持網(wǎng)絡(luò)文件系統(tǒng)，NFS的實(shí)現(xiàn)）允許超過8192字節(jié)的IP數(shù)據(jù)報(bào)。 總長度字段是IP首部中必要的內(nèi)容，因?yàn)橐恍?shù)據(jù)鏈路（如以太網(wǎng)）需要填充一些數(shù)據(jù)以達(dá)到最小長度。盡管以太網(wǎng)的最小幀長為46字節(jié)（圖2.1），但是IP數(shù)據(jù)可能會更短。如果沒有總長度字段，那么IP層就不知道46字節(jié)中有多少是IP數(shù)據(jù)報(bào)的內(nèi)容。 標(biāo)識字段唯一地標(biāo)識主機(jī)發(fā)送的每一份數(shù)據(jù)報(bào)。通常每發(fā)送一份報(bào)文它的值就會加1。我們在11.5節(jié)介紹分片和重組時(shí)再詳細(xì)討論它。同樣，在討論分片時(shí)我們再來分析標(biāo)志字段和片偏移字段。 （下面是原書p.36①的譯文） RFC 791 [Postel 1981a]認(rèn)為標(biāo)識字段應(yīng)該由讓IP發(fā)送數(shù)據(jù)報(bào)的上層來選擇。假設(shè)有兩個(gè)連續(xù)的IP數(shù)據(jù)報(bào)，其中一個(gè)是
分享到：
發(fā)表評論
ningbo-seo
最近訪客 更多訪客>>最新評論
|
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長非常感激您！手機(jī)微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
評論