第6章傳輸層和高層協(xié)議

第6章

傳輸層和高層協(xié)議

韶關(guān)學(xué)院信息工程學(xué)院駱耀祖1內(nèi)容提要本章描述傳輸層和TCP協(xié)議規(guī)范實(shí)現(xiàn)的一些方法，討論了TCP/IP中最為常見的應(yīng)用層協(xié)議：Telnet、FTP、小文件傳輸協(xié)議TFTP、簡單郵件傳輸協(xié)議SMTP和HTTP協(xié)議，討論這些協(xié)議與TCP和IP的關(guān)系、控制代碼及特點(diǎn)以及典型應(yīng)用實(shí)例。讀者在讀完本章后，應(yīng)充分理解為何要使用這些協(xié)議以及這些協(xié)議是如何適應(yīng)TCP/IP的。

6.1傳輸層和TCP協(xié)議規(guī)范

傳輸控制協(xié)議TCP(TransferControlProtocol)是一種面向連接的協(xié)議，該協(xié)議可以保證客戶端和服務(wù)端的連接是可靠的、安全的，所以大多數(shù)程序采用TCP協(xié)議。用戶數(shù)據(jù)報(bào)協(xié)議UDP(UserDatagramProtocol)是一種非面向連接的協(xié)議，它不能保證網(wǎng)絡(luò)程序的連接是可靠的，但由于它速度快，在要求速度和效率的場合可能會(huì)使用UDP協(xié)議。6.1.1TCP協(xié)議規(guī)范TCP協(xié)議是面向連接的端到端的可靠協(xié)議。它支持多種網(wǎng)絡(luò)應(yīng)用程序。TCP假定下層只能提供不可靠的數(shù)據(jù)報(bào)服務(wù)，對(duì)下層服務(wù)沒有多少要求，它可以在多種硬件構(gòu)成的網(wǎng)絡(luò)上運(yùn)行。在層次式結(jié)構(gòu)中，TCP的下層是IP協(xié)議，TCP可以根據(jù)IP協(xié)議提供的服務(wù)傳送大小不定的數(shù)據(jù)，IP協(xié)議負(fù)責(zé)對(duì)數(shù)據(jù)進(jìn)行分段和重組，在多種網(wǎng)絡(luò)中傳送。TCP的上層接口包括一系列類似于操作系統(tǒng)中斷的調(diào)用。對(duì)于上層應(yīng)用程序來說，TCP應(yīng)該能夠異步傳送數(shù)據(jù)。為了在并不可靠的網(wǎng)絡(luò)上實(shí)現(xiàn)面向連接的可靠的傳送數(shù)據(jù)，TCP必須解決可靠性和流量控制的問題，必須能夠?yàn)樯蠈討?yīng)用程序提供多個(gè)接口，同時(shí)為多個(gè)應(yīng)用程序提供數(shù)據(jù)。同時(shí)，TCP是面向連接的，必須解決連接問題。最后，TCP也必須能夠解決通信安全性的問題。主機(jī)上不同的協(xié)議有不同的端口號(hào)，一對(duì)進(jìn)程通過這個(gè)端口號(hào)進(jìn)行通信。網(wǎng)絡(luò)上的計(jì)算機(jī)被看作包傳送的源和目的節(jié)點(diǎn)。進(jìn)程為了傳送數(shù)據(jù)，將數(shù)據(jù)和相應(yīng)的參數(shù)傳送給TCP，通過將TCP包打包在IP包內(nèi)在網(wǎng)絡(luò)上傳送到目的TCP。TCP會(huì)保證接收數(shù)據(jù)順序的正確性。網(wǎng)關(guān)在接收到這個(gè)包后，會(huì)將包解開，看看是不是已經(jīng)到目的地了，如果沒有到，網(wǎng)關(guān)會(huì)根據(jù)下一個(gè)網(wǎng)絡(luò)內(nèi)的協(xié)議情況再次將TCP包打包傳送。有時(shí)還需要把這個(gè)包分成幾段再傳送。這個(gè)落地檢查的過程是一個(gè)耗時(shí)的過程。接收方TCP在接收到數(shù)據(jù)后與上層應(yīng)用程序通信。具體過程可能還要復(fù)雜得多。在實(shí)現(xiàn)TCP的主機(jī)上，TCP可以被看成是一個(gè)模塊，和文件系統(tǒng)區(qū)別不大，TCP也可以調(diào)用一些操作系統(tǒng)的功能。TCP不直接和網(wǎng)絡(luò)打交道，TCP只是調(diào)用IP接口，IP向TCP提供所有TCP需要的服務(wù)。控制網(wǎng)絡(luò)的任務(wù)由專門的設(shè)備驅(qū)動(dòng)模塊完成。TCP連接是可靠的，而且保證了所傳送數(shù)據(jù)包的順序，保證順序是用一個(gè)序號(hào)來保證的。響應(yīng)包內(nèi)也包括一個(gè)序列號(hào)，表示接收方準(zhǔn)備好這個(gè)序號(hào)的包。在TCP傳送一個(gè)數(shù)據(jù)包時(shí)，它同時(shí)把這個(gè)數(shù)據(jù)包放入重發(fā)隊(duì)列中，同時(shí)啟動(dòng)記數(shù)器，如果收到了關(guān)于這個(gè)包的確認(rèn)信息，將此包從隊(duì)列中刪除，如果計(jì)時(shí)超時(shí)則需要重新發(fā)送此包。從TCP返回的確認(rèn)信息并不保證最終接收者接收到數(shù)據(jù)，這個(gè)責(zé)任由接收方負(fù)責(zé)。1.TCP協(xié)議數(shù)據(jù)單元

urg如果設(shè)置緊急數(shù)據(jù)指針，則該位為1；

ack如果確認(rèn)號(hào)正確，那么為1；

psh如果設(shè)置為1，那么接收方收到數(shù)據(jù)后，立即交給上一層程序；

rst為1的時(shí)候，表示請(qǐng)求重新連接；

syn為1的時(shí)候，表示請(qǐng)求建立連接；fin為1的時(shí)候，表示請(qǐng)求關(guān)閉連接；2.TCP接口

網(wǎng)絡(luò)協(xié)議的分層結(jié)構(gòu)決定了TCP有兩個(gè)接口，向上的用戶接口和與下層的接口。對(duì)下層協(xié)議接口依賴于下層協(xié)議，由下層協(xié)議來描述，但也會(huì)討論到一些TCP要使用的參數(shù)。（1）用戶/TCP接口(TCP用戶命令)TCP的實(shí)現(xiàn)與具體的操作系統(tǒng)相關(guān)，因系統(tǒng)不同具體實(shí)現(xiàn)可能不同。不同的TCP實(shí)現(xiàn)可能有不同的用戶接口，但是有一些功能是最基本的，本節(jié)討論的都是調(diào)用的源語形式，其參數(shù)都支持TCP最低限度的子集。為了實(shí)現(xiàn)通信功能，TCP不能只會(huì)接收命令，而且能夠返回消息給它服務(wù)的進(jìn)程，這些消息包括：關(guān)于連接的通常消息，如中斷，遠(yuǎn)程關(guān)閉等等；對(duì)用戶命令做出應(yīng)答，是成功還是失敗。（2）TCP與下層接口

在互聯(lián)網(wǎng)上，通常認(rèn)為TCP的下層是IP協(xié)議。對(duì)TCP與下層(通常是IP，但不一定是)對(duì)話的模型卻沒有規(guī)定。TCP要求其下面的層定義通信的方式。TCP要調(diào)用下層服務(wù)才能在網(wǎng)絡(luò)上傳輸數(shù)據(jù)。IP層提供一些例如服務(wù)類型和生存時(shí)間等的參數(shù)。通常假定TCP與網(wǎng)絡(luò)層采用異步方式進(jìn)行通信。如果下層是IP而且使用源地址路由，接口必須允許路由信息的通信。這對(duì)建立連接和進(jìn)行路由是十分重要的。當(dāng)然也可以不使用IP協(xié)議作為TCP的底層協(xié)議，但無論下層協(xié)議是什么，都必須提供源地址，目的地址和協(xié)議域，以及一些決定TCP長度的字段?？傊?，要能夠提供類似于IP的功能。因?yàn)門CP是一種面向連接的協(xié)議，負(fù)責(zé)保證從源主機(jī)到目標(biāo)主機(jī)的數(shù)據(jù)報(bào)端到端的傳輸，所以TCP必須接收從目標(biāo)主機(jī)發(fā)送來的，確認(rèn)數(shù)據(jù)報(bào)已經(jīng)接收的通信信息。術(shù)語“虛電路”（virtualcircuit

）通常用來表示兩邊終端的通信，這些通信通常是簡單的確認(rèn)信息(接收的確認(rèn)或傳輸失敗的代碼)以及數(shù)據(jù)報(bào)的序列號(hào)。

圖6.2TCP提供了端到端的通信

（3）TCP與上層的通信

TCP必須與位于上層的應(yīng)用程序和在下層的網(wǎng)絡(luò)系統(tǒng)進(jìn)行通信。TCP與上層的接口包括一系列類似于操作系統(tǒng)中斷的調(diào)用。TCP與上層協(xié)議ULP(upper-layerprotocol)通信的方法由一組服務(wù)請(qǐng)求原語定義，

在ULP與TCP的通信中包含的原語如表6.1所示。

表6.1ULP與TCP通信中包含的原語6.1.2端口和套接字TCP/IP采用了協(xié)議端口號(hào)來區(qū)分使用TCP或UDP的各個(gè)應(yīng)用程序。端口機(jī)制是指在一個(gè)給定主機(jī)上使用TCP或UDP的每一個(gè)應(yīng)用程序都被指定一個(gè)邏輯地址，這些16比特的值用來標(biāo)識(shí)不同的應(yīng)用程序，在傳輸時(shí)保存在TCP或UDP報(bào)頭中。因此，在主機(jī)上的三級(jí)尋址方式包括：端口號(hào)(PortNumber)──標(biāo)識(shí)應(yīng)用程序；協(xié)議號(hào)(ProtocolNumber)──所使用的傳輸層協(xié)議；IP地址(IPAddress)──進(jìn)出主機(jī)的路徑。1.套接字套接字（Socket）是分配給某運(yùn)行在主機(jī)上特定進(jìn)程的邏輯地址。它形成主機(jī)和客戶機(jī)之間的虛擬連接。套接字使用IP地址、協(xié)議號(hào)和端口號(hào)的組合唯一標(biāo)識(shí)，也稱為三級(jí)尋址。一個(gè)連接由連接兩端的套接字標(biāo)識(shí)，本地的套接字可能和不同的外部套接字通信，這種通信是全雙工的。2.端口號(hào)套接字的地址集成了主機(jī)的IP地址和與某進(jìn)程有關(guān)的端口號(hào)(PortNumber)。TCP和UDP采用16位的端口號(hào)來識(shí)別應(yīng)用程序。例如，對(duì)于每個(gè)TCP/IP實(shí)現(xiàn)來說，F(xiàn)TP服務(wù)器的TCP端口號(hào)都是21，每個(gè)Telnet服務(wù)器的TCP端口號(hào)都是23。又如，IP地址為7的Web服務(wù)器的Telnet服務(wù)的套接字地址為7：23，其中23是Telnet服務(wù)的標(biāo)準(zhǔn)端口號(hào)。換句話說，在安裝之后，如果沒有特別配置軟件的話，Web服務(wù)器軟件會(huì)假設(shè)任何進(jìn)入端口號(hào)23的請(qǐng)求都是Telnet請(qǐng)求。注意，端口號(hào)被表示為IP地址后冒號(hào)后面的十進(jìn)制數(shù)字。23并不被認(rèn)為是套接字號(hào)中額外的十進(jìn)制數(shù)，它只是該端口的一個(gè)指針。圖6.3給出了使用TCP的端口號(hào)建立虛電路時(shí)的情況。圖6.3使用TCP的端口號(hào)建立虛電路通過向本地端口發(fā)送OPEN命令及外部套接字參數(shù)建立連接，這個(gè)連接的信息保存在一個(gè)稱為傳輸控制塊TCB（TransmissionControlBlock）的數(shù)據(jù)結(jié)構(gòu)中。TCP返回一個(gè)標(biāo)記這個(gè)連接的名稱，以后如果用戶需要這個(gè)連接就可使用這個(gè)名稱標(biāo)記。OPEN命令還指定這個(gè)連接的建立是主動(dòng)請(qǐng)求還是被動(dòng)等待請(qǐng)求。任何TCP/IP實(shí)現(xiàn)所提供的服務(wù)都用眾所周知的1－1023之間的端口號(hào)。這些端口號(hào)由Internet端口號(hào)分配機(jī)構(gòu)IANA（InternetAssignedNumbersAuthority）管理。到1992年為止，人們所熟知的端口號(hào)介于1－255之間。256－1023之間的端口號(hào)通常都是由Unix系統(tǒng)占用，以提供一些只有Unix系統(tǒng)才有的，而其他操作系統(tǒng)可能不提供的服務(wù)。大多數(shù)的TCP/IP實(shí)現(xiàn)給臨時(shí)端口分配的端口號(hào)在1024－5000之間。大于5000的端口號(hào)是為其他Internet上并不常用的服務(wù)預(yù)留的。表6.2給出了常用的TCP端口號(hào)。3.保留端口

Unix系統(tǒng)有保留端口號(hào)的概念。只有具有超級(jí)用戶特權(quán)的進(jìn)程才允許給它自己分配一個(gè)保留端口號(hào)。這些端口號(hào)介于1到1023之間，一些應(yīng)用程序（如有名的Rlogin）將它作為客戶與服務(wù)器之間身份認(rèn)證的一部分。端口號(hào)可以是任何一個(gè)值。一些使用TCP/IP的軟件（如Novell的GroupWise，以及HP的性能數(shù)據(jù)警報(bào)管理器）都可選擇自己的默認(rèn)端口號(hào)。常見TCP/IP服務(wù)的默認(rèn)端口號(hào)一般小于255

。盡管不必記住每個(gè)端口號(hào)，但應(yīng)該記住常見服務(wù)如Telnet、FIP、SNMP和HTTP等相關(guān)的端口號(hào)。了解這些端口號(hào)將有助于配置和調(diào)試TCP/IP網(wǎng)絡(luò)服務(wù)。端口號(hào)的引入簡化了TCP／IP通信。比如，當(dāng)某客戶機(jī)請(qǐng)求與某服務(wù)器通信，并指定端口23時(shí)，服務(wù)器會(huì)立即知道客戶機(jī)希望進(jìn)行Telnet會(huì)話。不再需要其他數(shù)據(jù)交換來定義會(huì)話類型，并且服務(wù)器可以立即初始化Telnet服務(wù)。服務(wù)器會(huì)連接到客戶機(jī)的Telnet端口，默認(rèn)值為23，并且建立虛擬線路。有一些標(biāo)準(zhǔn)的簡單服務(wù)幾乎每種實(shí)現(xiàn)都要提供。當(dāng)使用TCP和UDP提供相同的服務(wù)時(shí)，一般選擇相同的端口號(hào)。如果仔細(xì)檢查這些標(biāo)準(zhǔn)的簡單服務(wù)以及其他標(biāo)準(zhǔn)的TCP/IP服務(wù)（如Telnet，F(xiàn)TP，SMTP等）的端口號(hào)時(shí)，發(fā)現(xiàn)它們都是奇數(shù)。這是有歷史原因的，因?yàn)檫@些端口號(hào)都是從NCP端口號(hào)派生出來的。（NCP，即網(wǎng)絡(luò)控制協(xié)議，是ARPANET的傳輸層協(xié)議，是TCP的前身。NCP是單工的，不是全雙工的，因此每個(gè)應(yīng)用程序需要兩個(gè)連接，需預(yù)留一對(duì)奇數(shù)和偶數(shù)端口號(hào)。當(dāng)TCP和UDP成為標(biāo)準(zhǔn)的傳輸層協(xié)議時(shí)，每個(gè)應(yīng)用程序只需要一個(gè)端口號(hào)，因此就使用了NCP中的奇數(shù)。大多數(shù)服務(wù)器維護(hù)一個(gè)可編輯的、基于文本的端口號(hào)和相關(guān)服務(wù)的文件。如有必要，可以通過軟件來配置端口號(hào)。在通常的情況下，不應(yīng)更改默認(rèn)端口號(hào)，原因是違反了標(biāo)準(zhǔn)。當(dāng)然，一些網(wǎng)絡(luò)管理員為了安全原因也許會(huì)更改服務(wù)器端口號(hào)，以迷惑黑客。6.1.3TCP的連接

TCP通信建立在面向連接的基礎(chǔ)上，實(shí)現(xiàn)了一種“虛電路”的概念。在進(jìn)行實(shí)際數(shù)據(jù)傳輸前必須在信源端與信宿端建立一條連接，然后雙方就可以在其上發(fā)送數(shù)據(jù)流。假如連接建立不成功，則信源端不會(huì)像UDP一樣貿(mào)然向信宿端發(fā)送數(shù)據(jù)。此外，面向連接傳輸?shù)拿總€(gè)報(bào)文都需要收端確認(rèn)，未確認(rèn)報(bào)文被認(rèn)為是出錯(cuò)報(bào)文，以保證面向連接的可靠性。這種數(shù)據(jù)交換方式能提高效率，但事先建立連接和事后拆除連接需要開銷。1.連接進(jìn)程

TCP連接進(jìn)程是通過一系列狀態(tài)表示的，各個(gè)狀態(tài)的意義如下：LISTEN-偵聽來自遠(yuǎn)方TCP端口的連接請(qǐng)求；SYN-SENT-在發(fā)送連接請(qǐng)求后等待匹配的連接請(qǐng)求；

SYN-RECEIVED-在收到和發(fā)送一個(gè)連接請(qǐng)求后等待對(duì)連接請(qǐng)求的確認(rèn)；

ESTABLISHED-代表一個(gè)打開的連接，數(shù)據(jù)可以傳送給用戶；FIN-WAIT-1-等待遠(yuǎn)程TCP的連接中斷請(qǐng)求，或先前的連接中斷請(qǐng)求的確認(rèn)；FIN-WAIT-2-從遠(yuǎn)程TCP等待連接中斷請(qǐng)求；CLOSE-WAIT-等待從本地用戶發(fā)來的連接中斷請(qǐng)求；CLOSING-等待遠(yuǎn)程TCP對(duì)連接中斷的確認(rèn)；LAST-ACK-等待原來發(fā)向遠(yuǎn)程TCP的連接中斷請(qǐng)求的確認(rèn)；TIME-WAIT-等待足夠的時(shí)間以確保遠(yuǎn)程TCP接收到連接中斷請(qǐng)求的確認(rèn)；

CLOSED-沒有任何連接狀態(tài)；圖6.4表示了TCP連接可能發(fā)生的狀態(tài)及各種可能發(fā)生的變遷的有限狀態(tài)機(jī)，但該圖中沒有包括錯(cuò)誤的情況和錯(cuò)誤處理。2.建立一個(gè)連接TCP的連接要分為幾個(gè)步驟。通常把這個(gè)連接過程稱為“三次握手”。目的是使數(shù)據(jù)段的發(fā)送和接收同步；告訴其

它主機(jī)其一次可接收的數(shù)據(jù)量，并建立虛連接。

三次握手的簡單過程如圖6.5所示，步驟如下：

(1)初始化主機(jī)通過一個(gè)同步標(biāo)志置位的數(shù)據(jù)段發(fā)出會(huì)話請(qǐng)求。(2)接收主機(jī)發(fā)回具有以下項(xiàng)目的數(shù)據(jù)段表示回復(fù)：同步標(biāo)志置位、即將發(fā)送的數(shù)據(jù)段的起始字節(jié)的順序號(hào)、應(yīng)答并帶有將收到的下一個(gè)數(shù)據(jù)段的字節(jié)順序號(hào)。

(3)請(qǐng)求主機(jī)再回送一個(gè)數(shù)據(jù)段，并帶有確認(rèn)順序號(hào)和確認(rèn)號(hào)。

建立連接時(shí)，如果雙方同時(shí)都發(fā)送SYN，雙方會(huì)發(fā)現(xiàn)這個(gè)SYN中沒有確認(rèn)，通常應(yīng)該發(fā)送一個(gè)"reset"段來解決這種情況，減少了連接失敗的可能性。圖6.5三次握手使用三次握手的主要原因是為了防止使用過期的數(shù)據(jù)段。因此，必須引入新的控制消息RESET。如果接收TCP處理非同步狀態(tài)，在接收到RESET后返回到LISTEN狀態(tài)。如果TCP處理以下幾種狀態(tài)：ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK和TIME-WAIT時(shí)，放棄連接并通知用戶。3.關(guān)閉連接由于是TCP的傳輸是全雙工的，在CLOSE操作時(shí)的連接處理有些問題。TCP以一種簡單的方式處理CLOSE，發(fā)送CLOSE的一方在接收到對(duì)方的CLOSED之前，還要繼續(xù)接收數(shù)據(jù)。因此程序可以在一個(gè)CLOSE之后初始化幾個(gè)SEND，然后開始RECEIVE，直到接收到對(duì)方的CLOSED而RECEIVE失敗為止。假設(shè)TCP可以通知用戶連接關(guān)閉，即使仍在RECEIVE也可以，這樣用戶就可以正常關(guān)閉了。這樣，TCP就可以在連接關(guān)閉前可靠地發(fā)送數(shù)據(jù)。4.優(yōu)先和安全TCP的操作必須在兩個(gè)優(yōu)先級(jí)相同的端口間進(jìn)行。TCP使用的優(yōu)先和安全參數(shù)在IP協(xié)議中定義。這里所說的安全/間隔就是指的IP中定義的優(yōu)先、用戶組和處理規(guī)定。如果不符合則發(fā)送RST。TCP在操作過程中也會(huì)檢查接收數(shù)據(jù)段的優(yōu)先級(jí)，還可以在操作中提高優(yōu)先級(jí)。雖然運(yùn)行在無安全環(huán)境中，主機(jī)也必須能夠處理安全參數(shù)。6.2傳輸控制塊和流控制由于TCP建立在不可靠的IP協(xié)議之上，所以TCP的可靠性完全由自己實(shí)現(xiàn)。TCP采用的最基本的可靠性技術(shù)是：確認(rèn)與超時(shí)重傳。流量控制也是保證可靠性的一個(gè)重要措施，假如沒有流控，可能因接收緩沖區(qū)溢出而丟失大量數(shù)據(jù)，導(dǎo)致許多重傳。TCP采用可變窗口進(jìn)行流控。此外，TCP還要進(jìn)行擁塞控制。6.2.1傳輸控制塊TCB

TCP通過傳輸控制塊TCB（TransmissionControlBlock）監(jiān)視有關(guān)每個(gè)連接的有關(guān)信息。TCB包含的信息包括：本地和遠(yuǎn)程端口號(hào)（套接字）、發(fā)送和接收緩沖器指針等變量、安全性和優(yōu)先權(quán)值以及隊(duì)列中的當(dāng)前段，此外，TCB還管理和發(fā)送接收序列號(hào)。TCB使用若干變量跟蹤發(fā)送和接收狀態(tài)，并控制信息流。這些變量如表6.3所示。

TCP使用這些變量控制兩個(gè)套接字之間的信息流。圖6.6給出了發(fā)送序列變量間的關(guān)系。圖6.6發(fā)送序列變量間的關(guān)系這些變量的使用方式可用一個(gè)例子來說明。如果主機(jī)A希望將五個(gè)數(shù)據(jù)塊發(fā)送到主機(jī)B，如果窗口的極限是七個(gè)塊，主機(jī)A上的SND.UNA變量將指示有多少個(gè)塊已經(jīng)發(fā)送但未經(jīng)確認(rèn)(5)，而SND.NXT變量的值為序列的下一個(gè)塊(6)。SND.WND變量的值

是2(可用7塊，減去已經(jīng)發(fā)送的5塊)，因此只可以發(fā)送兩個(gè)塊而不會(huì)使窗口過載。主機(jī)B返回接收?qǐng)?bào)文的數(shù)目后，窗口的（可用）極限將作出相應(yīng)的調(diào)整。

6.2.2TCP定時(shí)器TCP使用幾個(gè)定時(shí)器以確保在通信過程中不會(huì)發(fā)生過度延遲。這些計(jì)時(shí)器起到確保數(shù)據(jù)從一個(gè)連接正確發(fā)送到另一方的作用。1.重傳計(jì)時(shí)器2.靜態(tài)計(jì)時(shí)器3.持續(xù)計(jì)時(shí)器4.?；钣?jì)時(shí)器和空閑計(jì)時(shí)器6.2.3確認(rèn)與超時(shí)重傳

在TCP連接中發(fā)送的字節(jié)都有一個(gè)序列號(hào)?？筛鶕?jù)序列號(hào)對(duì)接收到的包進(jìn)行確認(rèn)。對(duì)序列號(hào)的確認(rèn)是累積性的，也就是說，如果用戶收到對(duì)X的確認(rèn)信息，這表示在X以前的數(shù)據(jù)（不包括X）都收到了。在每個(gè)段中字節(jié)是這樣安排的：第一個(gè)字節(jié)在包頭后面，按這個(gè)順序排列。實(shí)際的序列空間的范圍是0到2的32次方減1。圖6.7給出了TCP序列號(hào)及確認(rèn)號(hào)的關(guān)系。

圖

6.7TCP序列號(hào)及確認(rèn)號(hào)1.序列號(hào)

（1）序列的比較和操作序列的比較和操作包括如下幾種：①

決定一些發(fā)送了的但未確認(rèn)的序列號(hào)；

②

決定所有的序列號(hào)都已經(jīng)收到了；③

決定下一個(gè)段中應(yīng)該包括的序列號(hào)。對(duì)于發(fā)送的數(shù)據(jù)TCP要接收確認(rèn)，處理確認(rèn)時(shí)必須進(jìn)行下面的比較操作：SND.UNA=最老的確認(rèn)了的序列號(hào)；SND.NXT=下一個(gè)要發(fā)送的序列號(hào)；SEG.ACK=接收TCP的確認(rèn)，接收TCP期待的下一個(gè)序列號(hào)；

SEG.SEQ=一個(gè)數(shù)據(jù)段的第一個(gè)序列號(hào)；SEG.LEN=數(shù)據(jù)段中包括的字節(jié)數(shù)；SEG.SEQ+SEG.LEN-1=數(shù)據(jù)段的最后一個(gè)序列號(hào)。注意下面的關(guān)系：SND.UNA<SEG.ACK=<SND.NXT（2）接收數(shù)據(jù)時(shí)的比較操作如果一個(gè)數(shù)據(jù)段的序列號(hào)小于等于確認(rèn)號(hào)的值，那么整個(gè)數(shù)據(jù)段就被確認(rèn)了。而在接收數(shù)據(jù)時(shí)下面的比較操作是必須的：RCV.NXT=期待的序列號(hào)和接收窗口的最低沿；RCV.NXT+RCV.WND-1=最后一個(gè)序列號(hào)和接收窗口的最高沿；

SEG.SEQ=接收到的第一個(gè)序列號(hào)；SEG.SEQ+SEG.LEN-1=接收到的最后一個(gè)序列號(hào)；上面幾個(gè)量有如下關(guān)系：RCV.NXT=<SEG.SEQ<RCV.NXT+RCV.WND或

RCV.NXT=<SEG.SEQ+SEG.LEN-1<RCV.NXT+RCV.WND圖6.8TCP簡單確認(rèn)機(jī)制測試的第一部分是檢查數(shù)據(jù)段的開始部分是否在接收窗口中，第二部分是檢查數(shù)據(jù)段的結(jié)束部分是否也在接收窗口內(nèi)；上面兩個(gè)檢查通過任何一個(gè)就說明它包括窗口要求的數(shù)據(jù)。實(shí)際中的情況會(huì)更復(fù)雜一些，因?yàn)橛辛愦翱诤土銛?shù)據(jù)段長，所以有下面四種情況：

接收窗口的大小可以為零，在窗口為零時(shí)它只用來接收ACK信息，因此對(duì)于一個(gè)TCP來說，它可以使用零大小窗口在發(fā)送數(shù)據(jù)的同時(shí)接收數(shù)據(jù)。即使接收窗口的大小為零，TCP必須處理所有接收到信息的RST和URG域。也可應(yīng)用計(jì)數(shù)的方式保護(hù)一些特定的控制信息，這是通過隱式地使用一些控制標(biāo)記，使數(shù)據(jù)段能夠可靠地重新發(fā)送（或確認(rèn)）來達(dá)到的?？刂菩畔⒉⒉辉诙螖?shù)據(jù)空間中傳送，因此，必須采用隱式指定序列號(hào)進(jìn)行控制。SYN和FIN是需要保護(hù)的控制量，這兩個(gè)控制量也只在連接打開和關(guān)閉時(shí)使用。SYN被認(rèn)為是在第一個(gè)實(shí)際數(shù)據(jù)之間的數(shù)據(jù)，而FIN是最后一個(gè)實(shí)際數(shù)據(jù)之后的數(shù)據(jù)。段長度（SEG.LEN）包括數(shù)據(jù)和序列號(hào)空間，如果出現(xiàn)了SYN，那么SEG.SEQ是SYN的序列號(hào)。（3）初始序列號(hào)選擇協(xié)議對(duì)于特定連接被重復(fù)使用沒有什么限制。連接是由一對(duì)套接字定義的。新的連接實(shí)例被定義為連接的另一次恢復(fù)，這就帶來了問題：TCP如何確定多個(gè)數(shù)據(jù)段是從以前連接的另一次恢復(fù)中取得的呢？這個(gè)問題在連接迅速打開和關(guān)閉，或因?yàn)閮?nèi)存原因被關(guān)閉然后又迅速建立后顯得特別突出。為了避免混亂，用戶必須避免因此恢復(fù)使用某一連接，而使序列號(hào)發(fā)生混亂。必須保證序列號(hào)的正確性，即使TCP失敗，根本不知道以前的序列號(hào)是什么的情況下。也要保證序列號(hào)的正確性。當(dāng)新的連接被創(chuàng)建時(shí)，產(chǎn)生一個(gè)新的初始序列號(hào)（ISN）產(chǎn)生子，它用來選擇一個(gè)新的32位ISN。產(chǎn)生子和32位時(shí)鐘的低位字節(jié)相關(guān)，低位字節(jié)的刷新頻率大概是4微秒，因此ISN的循環(huán)時(shí)間大概是4.55小時(shí)。因此把網(wǎng)絡(luò)包的最長生存時(shí)間（MSL）小于4.55小時(shí)，因此可以認(rèn)為ISN是唯一的。每個(gè)連接都有發(fā)送序列號(hào)和接收序列號(hào)，初始發(fā)送序列號(hào)（ISS）由發(fā)送TCP選擇，而初始接收序列號(hào)是在連接建立過程中產(chǎn)生的。對(duì)于將要連接或初始化的連接，兩個(gè)TCP必須和對(duì)方的初始序列號(hào)同步。這通過交換一個(gè)控制位SYN和初始序列號(hào)完成。把帶有SYN的數(shù)據(jù)段稱為"SYNs"。同步的獲得過程這里就不重復(fù)了，每方必須發(fā)送自己的序列號(hào)并返回對(duì)于對(duì)方序列號(hào)的確認(rèn)。TCP的基本傳輸單元――段(Segment)是不定長的?？勺冮LTCP段所采用的確認(rèn)與超時(shí)重傳機(jī)制是所謂的“累計(jì)確認(rèn)”：TCP確認(rèn)針對(duì)流中的字節(jié)，而不是段。一段情況下，接收方確認(rèn)已正確收到的最長的連續(xù)的流前部(prefixofthestream)，每個(gè)確認(rèn)指出下一個(gè)希望收到的字節(jié)。累計(jì)確認(rèn)的優(yōu)點(diǎn)之一是在變長段傳輸方式下不會(huì)產(chǎn)生二義性，累計(jì)確認(rèn)另一個(gè)優(yōu)點(diǎn)是確認(rèn)丟失后不一定導(dǎo)致重傳。假設(shè)收方當(dāng)時(shí)正確收到第10號(hào)字節(jié)以前的流前部，將發(fā)送一報(bào)文確認(rèn)第11號(hào)字節(jié)，緊跟著又收到第11、12號(hào)字節(jié)，又發(fā)送一個(gè)確認(rèn)第13號(hào)字節(jié)的報(bào)文。確認(rèn)第11號(hào)字節(jié)的報(bào)文丟失并不一定導(dǎo)致重傳。因?yàn)榧偃绱_認(rèn)第13號(hào)字節(jié)的報(bào)文在一定時(shí)間之內(nèi)傳到發(fā)送方，發(fā)送方將不進(jìn)行重傳。累計(jì)確認(rèn)的缺點(diǎn)是發(fā)送方不能獲得關(guān)于所有成功的段傳輸信息，假如前面尚有數(shù)據(jù)未收到，則后面所有成功傳輸?shù)亩味嫉貌坏酱_認(rèn)，必須重傳。2.超時(shí)重傳

TCP采用“帶重傳的肯定確認(rèn)”技術(shù)來實(shí)現(xiàn)傳輸?shù)目煽啃?。簡單的“帶重傳的肯定確認(rèn)”是指與發(fā)送方通信的接收者，每接收一次數(shù)據(jù)，就送回一個(gè)確認(rèn)報(bào)文，發(fā)送者對(duì)每個(gè)發(fā)出去的報(bào)文都留一份記錄，等到收到確認(rèn)之后再發(fā)出下一報(bào)文數(shù)據(jù)報(bào)。發(fā)送者發(fā)出一個(gè)報(bào)文數(shù)據(jù)報(bào)時(shí)，啟動(dòng)一個(gè)計(jì)時(shí)器，若計(jì)時(shí)器計(jì)數(shù)完畢，確認(rèn)還未到達(dá)，則發(fā)送者重新送該報(bào)文數(shù)據(jù)報(bào)。TCP通過重新傳送保證每個(gè)數(shù)據(jù)段到達(dá)對(duì)方，因?yàn)橛辛酥匦聜魉?，所以?duì)方可能接收到兩個(gè)相同的包，那就必須根據(jù)內(nèi)部的序列號(hào)來判斷哪個(gè)數(shù)據(jù)段是可以接收的。發(fā)送方通過使用SND.NXT跟蹤下一個(gè)要發(fā)送的數(shù)據(jù)段，而接收方則跟蹤RCV.NXT來知道下一個(gè)要接收的數(shù)據(jù)段。發(fā)送方要還未確認(rèn)的最老的序列號(hào)保存于SND.UNA。當(dāng)發(fā)送方形成數(shù)據(jù)段并發(fā)送后SND.NXT增大；當(dāng)接收方接收到數(shù)據(jù)段后RCV.NXT增大并發(fā)送確認(rèn)；當(dāng)發(fā)送方接收到確認(rèn)后SND.UNA增大。它們?nèi)咴诓煌臅r(shí)間增大是因?yàn)閭魉蜁r(shí)延造成的。而增大多少則由數(shù)據(jù)段中數(shù)據(jù)的大小決定。連接進(jìn)入ESTABLISHED狀態(tài)后，所有的段必須包括當(dāng)前的確認(rèn)信息。而CLOSE用戶操作的性質(zhì)類似于推操作，這和在接收到的數(shù)據(jù)段中的FIN標(biāo)記一樣。因?yàn)榫W(wǎng)絡(luò)中有不同類型的網(wǎng)絡(luò)，而使用TCP的范圍又很廣，所以，重傳超時(shí)必須動(dòng)態(tài)決定。下面給出一個(gè)確定重傳超時(shí)過程的例子，用兩個(gè)變量說明時(shí)延的問題。一個(gè)是環(huán)路時(shí)間（RTT），它是由一個(gè)序列碼得到的，這個(gè)序列碼在發(fā)送時(shí)給出，在接收到確認(rèn)時(shí)被覆蓋；另一個(gè)平滑環(huán)路時(shí)間（SRTT）：SRTT=(ALPHA*SRTT)+((1-ALPHA)*RTT)通過上面的式子，可以得到重傳超時(shí)RTO：RTO=min[UBOUND，max[LBOUND，(BETA*SRTT)]]其中UBOUND是超時(shí)的上界（如1分鐘），LBOUND是超時(shí)的下界（如1秒鐘），ALPHA是平滑因子（如0.8到0.9），BETA是延時(shí)變量（如1.3到2.0）。3.傳送緊急消息

TCP的緊急機(jī)制允許發(fā)送者使接收者接收一些緊急消息，并讓接收方在接收到這一消息后立刻通知用戶。這種機(jī)制是在數(shù)據(jù)流是加入一個(gè)點(diǎn)，指出這是緊急數(shù)據(jù)的結(jié)束點(diǎn)，當(dāng)接收方要接收到這個(gè)點(diǎn)之前，它會(huì)通知用戶進(jìn)入緊急狀態(tài)，在接收到這個(gè)點(diǎn)的數(shù)據(jù)后，它會(huì)通知用戶進(jìn)入通常狀態(tài)。如果這個(gè)緊急點(diǎn)在用戶進(jìn)入緊急狀態(tài)時(shí)更新，這個(gè)更新必須對(duì)用戶透明。應(yīng)用一個(gè)緊急域的方法可以達(dá)到上述目的，而URG控制標(biāo)記則指明緊急域是否被使用，而且在數(shù)據(jù)段中必須加入指示緊急點(diǎn)的序列號(hào)，如果沒有這個(gè)標(biāo)記則說明沒有緊急點(diǎn)。如果需要發(fā)送緊急數(shù)據(jù)，發(fā)送方必須起碼發(fā)送一個(gè)字節(jié)。6.2.4TCP的擁塞控制

在互聯(lián)網(wǎng)中，擁塞是由于網(wǎng)關(guān)數(shù)據(jù)報(bào)超載而引起的嚴(yán)重延遲現(xiàn)象，一旦發(fā)生擁塞，網(wǎng)關(guān)將拋棄數(shù)據(jù)報(bào)，導(dǎo)致重傳，而大量的重傳會(huì)進(jìn)一步加劇擁塞。因此，TCP必須進(jìn)行擁塞控制?？偟膩碚f，TCP的擁塞控制是基于滑動(dòng)窗口協(xié)議的。通過限制發(fā)送端向互聯(lián)網(wǎng)注入報(bào)文的速率而達(dá)到控制擁塞的目的。滑動(dòng)窗口的范圍決定了發(fā)送方發(fā)送的但未被接收方確認(rèn)的數(shù)據(jù)報(bào)的數(shù)量。各報(bào)文按序發(fā)送出去，但確認(rèn)不一定按序返回，一旦窗口前面部分報(bào)文得到確認(rèn)，則窗口向后滑動(dòng)相應(yīng)位置，落入窗口的后續(xù)報(bào)文又可連續(xù)發(fā)送。這種機(jī)制不需要對(duì)每個(gè)數(shù)據(jù)報(bào)都進(jìn)行確認(rèn)，提高了網(wǎng)絡(luò)的吞吐量。TCP滑動(dòng)窗口用于暫存兩臺(tái)主機(jī)間要傳送的數(shù)據(jù)。

每個(gè)TCP/IP主機(jī)有兩個(gè)滑動(dòng)窗口：一個(gè)用于接收數(shù)據(jù)，另一個(gè)用于發(fā)送數(shù)據(jù)。

圖6.9中發(fā)送滑動(dòng)窗口的窗口大小為3，接收窗口的窗口大小為2。其中報(bào)文1、2、3已發(fā)送且1、2、3被確認(rèn)后，發(fā)送報(bào)文4、5并正在確認(rèn)。在接收端，窗口內(nèi)的序號(hào)對(duì)應(yīng)于允許接收的幀，窗口前的幀是已收到且已發(fā)出確認(rèn)的幀，是不允許接收的，窗口后的幀要等待窗口滑動(dòng)后才能接收。在TCP中，接收端會(huì)向發(fā)送端指示它可以發(fā)送的字節(jié)數(shù)，即它的接收窗口大小，發(fā)送方根據(jù)接收方所通告的窗口大小和發(fā)送端的擁塞窗口來決定發(fā)送窗口。發(fā)送窗口=

min（接收方通告窗口，擁塞窗口）在非擁塞狀態(tài)下，擁塞窗口和接收方通告窗口大小相等，一旦發(fā)現(xiàn)擁塞，TCP將減小擁塞窗口。TCP發(fā)現(xiàn)擁塞的途徑有兩條，一是來自ICMP源抑制報(bào)文

，二是報(bào)文丟失的現(xiàn)象。TCP假定多數(shù)報(bào)文丟失都源于擁塞，為迅速抑制擁塞，TCP采取成倍遞減擁塞窗口的策略：一旦發(fā)現(xiàn)報(bào)文丟失嚴(yán)重，立即將擁塞窗口大小減半。對(duì)于保留在發(fā)送窗口中的報(bào)文，根據(jù)Karn算法，按指數(shù)級(jí)延長重傳定時(shí)器的定時(shí)。這樣的結(jié)果是：擁塞窗口呈幾何級(jí)數(shù)減小，而發(fā)送方發(fā)送報(bào)文的速度和重傳率也呈幾何級(jí)數(shù)減少，最終可能出現(xiàn)發(fā)送窗口為1。若此時(shí)繼續(xù)出現(xiàn)重傳，根據(jù)Karn算法，TCP將成倍增加重傳超時(shí)。擁塞結(jié)束后，TCP又采取一種算術(shù)級(jí)窗口恢復(fù)策略，以避免迅速增加窗口大小造成的振蕩，過程是，當(dāng)在一條新連接或經(jīng)過一定時(shí)間擁塞后開始恢復(fù)的連接上傳輸數(shù)據(jù)時(shí)，都要從大小為1的擁塞窗口開始，之后每收到一個(gè)確認(rèn)，擁塞窗口大小增加1，直到恢復(fù)到正常窗口大小。另外，TCP還附加一條限制，當(dāng)擁塞窗口增加到原來大小的一半時(shí)，進(jìn)入“擁塞避免”狀態(tài)，減緩增大窗口的速率。在擁塞避免狀態(tài)，TCP在收到窗口中所有報(bào)文的確認(rèn)后才將擁塞窗口增1。TCP中每個(gè)數(shù)據(jù)段都包括下一個(gè)希望接收到的序列號(hào)。窗口比較大會(huì)提高傳送速度，如果傳送過來的數(shù)據(jù)超過窗口大小，數(shù)據(jù)會(huì)被拋棄。這樣會(huì)加重網(wǎng)絡(luò)負(fù)擔(dān)。對(duì)于健壯的TCP來說，最好不要自己縮小窗口，但要做要準(zhǔn)備對(duì)方的TCP縮小窗口。6.3用戶數(shù)據(jù)報(bào)協(xié)議UDP用戶數(shù)據(jù)報(bào)協(xié)議UDP是定義用來在互連網(wǎng)絡(luò)環(huán)境中提供包交換的計(jì)算機(jī)通信的協(xié)議。作為在傳輸層中的UDP協(xié)議是建立在IP協(xié)議基礎(chǔ)之上的，默認(rèn)認(rèn)為IP協(xié)議是其下層協(xié)議。UDP協(xié)議提供了向另一用戶程序發(fā)送信息的最簡便的協(xié)議機(jī)制，它是面向操作的，未提供提交和復(fù)制保護(hù)。因此，UDP和IP協(xié)議一樣是不可靠的數(shù)據(jù)報(bào)服務(wù)。如果應(yīng)用程序要求可靠的數(shù)據(jù)傳送應(yīng)該使用傳輸控制協(xié)議（TCP）。6.3.1UDP概述UDP是一個(gè)簡單的的傳輸層協(xié)議。所謂面向數(shù)據(jù)報(bào)，是指進(jìn)程的每個(gè)輸出操作都正好產(chǎn)生一個(gè)UDP數(shù)據(jù)報(bào)，并組裝成一份待發(fā)送的IP數(shù)據(jù)報(bào)。這與如TCP等面向流字符的協(xié)議不同，應(yīng)用程序產(chǎn)生的全體數(shù)據(jù)與真正發(fā)送的單個(gè)IP數(shù)據(jù)報(bào)可能沒有什么聯(lián)系。UDP的數(shù)據(jù)報(bào)格式如圖6.10所示：1.UDP數(shù)據(jù)報(bào)中的域信源端口(Sourceport)：是可選域，當(dāng)其有意義時(shí)，它指的是發(fā)送進(jìn)程的端口，說明在沒有其它信息的情況下，返回信息應(yīng)該向什么地方發(fā)送。如果不使用它，則在此域中填0。

信宿端口(Destinationport)：在有特定的目的網(wǎng)絡(luò)地址時(shí)有意義。

長度(Length)：此用戶數(shù)據(jù)報(bào)長度的八進(jìn)制表示（最小的數(shù)據(jù)報(bào)長度是8）。

校驗(yàn)和(Checksum)：16位，是對(duì)IP頭，UDP頭和數(shù)據(jù)中信息包頭的數(shù)位取反之和再取反得到的。這個(gè)校驗(yàn)過程與TCP中使用的過程一致。包頭從概念上說是在UDP頭信息之前的，它包括有源地址，目的地地址，所使用的協(xié)議和UDP長度。這些信息使信息不能被錯(cuò)誤地接收。

UDP的校驗(yàn)域是可選的，如果校驗(yàn)碼為零，意味著發(fā)送者未產(chǎn)生校驗(yàn)碼。這表示對(duì)于數(shù)據(jù)段不使用校驗(yàn)，因?yàn)镮P只是對(duì)IP頭進(jìn)行校驗(yàn)。2.UDP協(xié)議的接口（1）用戶接口用戶接口應(yīng)該允許創(chuàng)建新的接收端口，在接收端口的接收操作有：應(yīng)該返回一個(gè)八進(jìn)制數(shù)說明源端口和源地址，允許數(shù)據(jù)報(bào)傳送，指定數(shù)據(jù)，源和目標(biāo)端口和目的地地址。（2）IP層接口UDP模塊必須能夠決定源和目標(biāo)的網(wǎng)絡(luò)地址，而且必須能夠從包頭中得知所使用的協(xié)議。一個(gè)可能的接口方式是返回整個(gè)數(shù)據(jù)報(bào)，包括接收操作返回的包頭。這樣的接口還應(yīng)該允許UDP向IP傳送完整的帶包頭的數(shù)據(jù)報(bào)用于傳送。由IP來確定一致性并計(jì)算校驗(yàn)碼。3.協(xié)議應(yīng)用

UDP協(xié)議的最主要的用途是DNS服務(wù)器和小文件傳輸協(xié)議TFTP(TrivialFileTransferProtocol)。在IP中使用它時(shí)，它的協(xié)議號(hào)是17（八進(jìn)制中是21）。UDP不提供可靠性：它把應(yīng)用程序傳給IP層的數(shù)據(jù)發(fā)送出去，但是并不保證它們能到達(dá)目的地。由于缺乏可靠性，似乎覺得要避免使用UDP而使用一種可靠協(xié)議如TCP。下面討論什么樣的應(yīng)用程序可以使用UDP。在TFTP及Internet名字服務(wù)器上都使用UDP協(xié)議。在伯克利的UNIX上，一些檢查網(wǎng)絡(luò)用戶的命令（如rwho等）使用的也是UDP協(xié)議。SunMicrosystem公司開發(fā)的NFS也是在UDP上實(shí)現(xiàn)的。UDP由于協(xié)議簡單，系統(tǒng)對(duì)網(wǎng)絡(luò)的負(fù)載很輕，故有利于大量數(shù)據(jù)的傳送。應(yīng)用程序必須關(guān)心IP數(shù)據(jù)報(bào)的長度。如果它超過網(wǎng)絡(luò)的MTU（最大傳輸單元），那么就要對(duì)IP數(shù)據(jù)報(bào)進(jìn)行分片。如果需要，源端到目的端之間的每個(gè)網(wǎng)絡(luò)都要進(jìn)行分片，并不只是發(fā)送端主機(jī)連接第一個(gè)網(wǎng)絡(luò)才這樣做。6.3.2UDP端口號(hào)

一個(gè)UDP端口是一個(gè)可讀可寫的軟件結(jié)構(gòu)，內(nèi)部有一個(gè)接收?qǐng)?bào)文緩沖區(qū)。發(fā)送數(shù)據(jù)時(shí)，UDP軟件構(gòu)造一個(gè)數(shù)據(jù)報(bào)，然后把它交給IP軟件，便完成所有的工作。接收數(shù)據(jù)時(shí)，UDP軟件首先要判斷接收數(shù)據(jù)報(bào)的信宿端口是否與當(dāng)前正在使用的某端口匹配，假如是，則將數(shù)據(jù)報(bào)放入相應(yīng)接收隊(duì)列，否則，拋棄該數(shù)據(jù)報(bào)，并向信源端發(fā)送“端口不可到達(dá)”ICMP報(bào)文，雖然端口匹配成功，但如果相應(yīng)端口隊(duì)列已滿，UDP也要拋棄該數(shù)據(jù)報(bào)。端口號(hào)表示發(fā)送進(jìn)程和接收進(jìn)程。TCP和UDP用目的端口號(hào)來分用來自IP層的數(shù)據(jù)。由于根據(jù)IP首部中協(xié)議字段值，IP層已經(jīng)把IP數(shù)據(jù)報(bào)分配給TCP或UDP，因此TCP端口號(hào)由TCP來查看，而UDP端口號(hào)由UDP來查看。TCP端口號(hào)與UDP端口號(hào)是相互獨(dú)立的。但是，如果TCP和UDP同時(shí)提供某種知名服務(wù)，盡管相互獨(dú)立，兩個(gè)協(xié)議通常選擇相同的端口號(hào)。這純粹是為了使用方便，而不是協(xié)議本身的要求。UDP長度字段指的是UDP首部和UDP數(shù)據(jù)的字節(jié)長度。該字段的最小值為8字節(jié)。這個(gè)UDP長度是有冗余的。IP數(shù)據(jù)報(bào)長度指的是數(shù)據(jù)報(bào)全長，因此UDP數(shù)據(jù)報(bào)長度是全長減去IP首部的長度（該值在首部長度字段中指定，）。6.3.3UDP校驗(yàn)和

UDP校驗(yàn)和覆蓋UDP首部和UDP數(shù)據(jù)?；叵隝P首部的校驗(yàn)和，它只覆蓋IP的首部，并不覆蓋IP數(shù)據(jù)報(bào)中的任何數(shù)據(jù)。UDP和TCP在首部中都有覆蓋它們首部和數(shù)據(jù)的校驗(yàn)和。UDP的校驗(yàn)和是可選的，而TCP的校驗(yàn)和是必需的。盡管UDP校驗(yàn)和的基本計(jì)算方法與IP首部校驗(yàn)和計(jì)算方法相類似（16bit字的二進(jìn)制反碼和），但是它們之間存在不同的地方。首先，UDP數(shù)據(jù)報(bào)的長度可以為奇數(shù)字節(jié)，但是校驗(yàn)和算法是把若干個(gè)16bit字相加。解決方法是必要時(shí)在最后增加填充字節(jié)0，這只是為了校驗(yàn)和的計(jì)算。（也就是說，可能增加的填充字節(jié)不被傳送。）其次，UDP數(shù)據(jù)報(bào)和TCP段都包含一個(gè)12字節(jié)長的偽首部，它是為了計(jì)算校驗(yàn)和而設(shè)置的。偽首部中包含IP首部一些字段。其目的是讓UDP兩次檢查數(shù)據(jù)是否已經(jīng)正確到達(dá)目的地（例如，IP沒有接受地址不是本主機(jī)的數(shù)據(jù)報(bào)，以及IP沒有把應(yīng)傳給另一高層的數(shù)據(jù)報(bào)傳給UDP）。如果校驗(yàn)和的計(jì)算結(jié)果為0，它存入的值為全1（65535），相當(dāng)于它的算術(shù)二進(jìn)制反碼。如果傳送的校驗(yàn)和為0，說明發(fā)送端沒有計(jì)算校驗(yàn)和。如果發(fā)送端沒有計(jì)算校驗(yàn)和，而接收端檢測到校驗(yàn)和有差錯(cuò)，那么UDP數(shù)據(jù)報(bào)就要被悄悄地丟棄。不產(chǎn)生任何差錯(cuò)報(bào)文。（當(dāng)IP層檢測到IP首部校驗(yàn)和有差錯(cuò)時(shí)也這樣做。）UDP校驗(yàn)和是一個(gè)端到端的校驗(yàn)和。它由發(fā)送端計(jì)算，然后由接收端驗(yàn)證。其目的是為了發(fā)現(xiàn)UDP首部和數(shù)據(jù)在發(fā)送端到接收端之間發(fā)生的任何改動(dòng)。盡管UDP校驗(yàn)和是可選的，但應(yīng)該始終使用它。在數(shù)據(jù)報(bào)通過路由器時(shí)，通過對(duì)鏈路層數(shù)據(jù)幀進(jìn)行循環(huán)冗余檢驗(yàn)（如以太網(wǎng)或令牌環(huán)數(shù)據(jù)幀）可以檢測到大多數(shù)的差錯(cuò)，導(dǎo)致傳輸失敗。在實(shí)際的網(wǎng)絡(luò)上，路由器中也會(huì)存在軟件和硬件差錯(cuò)，以致于修改數(shù)據(jù)報(bào)中的數(shù)據(jù)。如果關(guān)閉端到端的UDP校驗(yàn)和功能，那么這些差錯(cuò)在UDP數(shù)據(jù)報(bào)中就不能被檢測出來。另外，一些數(shù)據(jù)鏈路層協(xié)議（如SLIP）沒有任何形式的數(shù)據(jù)鏈路校驗(yàn)和。注意，TCP發(fā)生校驗(yàn)和差錯(cuò)的比例與UDP相比要高得多。這很可能是因?yàn)樵谠撓到y(tǒng)中的TCP連接經(jīng)常是“遠(yuǎn)程”連接（經(jīng)過許多路由器，網(wǎng)橋等中間設(shè)備），而UDP一般為本地通信。不要完全相信數(shù)據(jù)鏈路（如以太網(wǎng)，令牌環(huán)等）的CRC校驗(yàn)。應(yīng)該始終打開端到端的校驗(yàn)和功能。如果數(shù)據(jù)很有價(jià)值，更不要完全相信UDP或TCP的校驗(yàn)和，因?yàn)檫@些都只是簡單的校驗(yàn)和，不能檢測出所有可能發(fā)生的差錯(cuò)。6.3.4最大UDP數(shù)據(jù)報(bào)長度

IP數(shù)據(jù)報(bào)理論上的最大長度是65535字節(jié)，這是由IP首部16位總長度字段所限制的。去除20字節(jié)的IP首部和8個(gè)字節(jié)的UDP首部，UDP數(shù)據(jù)報(bào)中用戶數(shù)據(jù)的最大長度為65507字節(jié)。1.兩個(gè)限制因素但是，大多數(shù)實(shí)現(xiàn)所提供的長度比上述的最大值小。因?yàn)橛袃蓚€(gè)限制因素：(1)應(yīng)用程序可能會(huì)受到其程序接口的限制。socketAPI提供了一個(gè)可供應(yīng)用程序調(diào)用的函數(shù)，以設(shè)置接收和發(fā)送緩存的長度。對(duì)于UDPsocket，這個(gè)長度與應(yīng)用程序可以讀寫的最大UDP數(shù)據(jù)報(bào)的長度直接相關(guān)的。現(xiàn)在的大部分系統(tǒng)都默認(rèn)提供了可讀寫大于8192字節(jié)的UDP數(shù)據(jù)報(bào)。（使用這個(gè)默認(rèn)值是因?yàn)?192是NFS讀寫用戶數(shù)據(jù)數(shù)的默認(rèn)值。）(2)TCP/IP的內(nèi)核實(shí)現(xiàn)可能存在一些實(shí)現(xiàn)特性（或差錯(cuò)），使IP數(shù)據(jù)報(bào)長度小于65535字節(jié)。這個(gè)限制與源端和目的端的實(shí)現(xiàn)有關(guān)。在許多UDP應(yīng)用程序的設(shè)計(jì)中，其應(yīng)用程序數(shù)據(jù)被限制成512字節(jié)或更小。例如，路徑信息協(xié)議總是發(fā)送每份數(shù)據(jù)報(bào)小于512字節(jié)的數(shù)據(jù)。在其它UDP應(yīng)用程序如DNS，TFTP，BOOTP以及SNMP遇到這個(gè)限制。2.數(shù)據(jù)報(bào)截?cái)?/p>

由于IP能夠發(fā)送或接收特定長度的數(shù)據(jù)報(bào)并不意味著接收應(yīng)用程序可以讀取該長度的數(shù)據(jù)。因此，UDP編程接口允許應(yīng)用程序指定每次返回的最大字節(jié)數(shù)。如果接收到的數(shù)據(jù)報(bào)長度大于應(yīng)用程序所能處理的長度，該問題的答案取決于編程接口和實(shí)現(xiàn)。在討論TCP時(shí)，發(fā)現(xiàn)它為應(yīng)用程序提供連續(xù)的字節(jié)流，而沒有任何信息邊界。TCP以應(yīng)用程序讀操作時(shí)所要求的長度來傳送數(shù)據(jù)，因此，在這個(gè)接口下，不會(huì)發(fā)生數(shù)據(jù)丟失。6.4

應(yīng)用層協(xié)議

本節(jié)介紹TCP/IP中最為常見的應(yīng)用層協(xié)議：Telnet、FTP、小文件傳輸協(xié)議TFTP、簡單郵件傳輸協(xié)議SMTP和HTTP協(xié)議。本章只討論這些協(xié)議與TCP和IP的關(guān)系、控制代碼及特點(diǎn)以及典型應(yīng)用實(shí)例。讀者在讀完本節(jié)后，應(yīng)能充分理解為何要使用這些協(xié)議以及這些協(xié)議是如何適應(yīng)TCP/IP的。6.4.1域名服務(wù)

在TCP/IP網(wǎng)絡(luò)中，每一個(gè)節(jié)點(diǎn)都有一個(gè)唯一的IP地址，作為節(jié)點(diǎn)唯一的標(biāo)志。當(dāng)TCP/IP正式成為網(wǎng)絡(luò)的新標(biāo)準(zhǔn)后，人們提出了使用容易記憶的主機(jī)名(HostName)代替IP方式的設(shè)想。它運(yùn)行在TCP協(xié)議之上，負(fù)責(zé)實(shí)現(xiàn)IP與主機(jī)名的轉(zhuǎn)換。這個(gè)過程就是域名解析，負(fù)責(zé)域名解析的機(jī)器稱為域名服務(wù)器。1.主機(jī)名解析

最簡單的主機(jī)名解析方法是，使用HostName對(duì)照表將容易記憶的主機(jī)名代替不容易記憶的IP地址。在一個(gè)文件中記錄所有主機(jī)名及與其對(duì)應(yīng)的IP地址，并保證該文件中主機(jī)名的唯一性，通過檢索文件就可以完成主機(jī)名的解析。主機(jī)名字最主要的工作就是IP到主機(jī)名字的轉(zhuǎn)換（例如將03轉(zhuǎn)換成），這樣所形成的數(shù)據(jù)表就成為主機(jī)名表（HostTable），可直接使用人工方式維護(hù)。要測試HostTable的運(yùn)作，可直接使用ping命令。2.域名系統(tǒng)

隨著網(wǎng)絡(luò)的不斷發(fā)展，網(wǎng)絡(luò)中的主機(jī)數(shù)量爆炸性地增加，使用主機(jī)文件作為域名解析的方法已經(jīng)無法適應(yīng)新的解析需要。在Internet上，采用域名系統(tǒng)DNS作為名字主機(jī)的另一種解決方案。DNS主要的功能也是處理IP與名字方面的轉(zhuǎn)換，但DNS與主機(jī)名表最大的區(qū)別是DNS服務(wù)器采用動(dòng)態(tài)的、分布式樹狀結(jié)構(gòu)。在分布式的域名服務(wù)器體系中，每一臺(tái)域名服務(wù)器負(fù)責(zé)解析屬于自己的一部分主機(jī)的域名。一般說來，如果所處在公司或組織所擁有的主機(jī)并不多，通?？蓪⒂蛎慕馕龉ぷ鹘唤o自己的ISP的域名服務(wù)器來完成。而如果所在組織擁有的主機(jī)比較多，就可以組建自己的域名服務(wù)器，負(fù)責(zé)解析所在組織的主機(jī)。（1）域名的層次樹狀結(jié)構(gòu)DNS結(jié)構(gòu)是一個(gè)樹狀結(jié)構(gòu)，由最高的根域名往下擴(kuò)展，每一個(gè)層都有其相應(yīng)的屬性。如第二層即屬于分類、第三層即屬于組織、第四層即屬于主機(jī)名等。這樣所組成的結(jié)構(gòu)，稱為域名的空間(NameSpace)，如圖6.11所示。

（2）域名系統(tǒng)六大分類NIC機(jī)構(gòu)定出域名系統(tǒng)最早的六大分類，如表6.4所示。由于DNS系統(tǒng)起初沒有考慮跨國家的范圍，隨著Internet的崛起，美國NIC組織保留了六大分類并且將所有非美國的國家分布于第一層，例如中國為.cn，并將該國家的DNS系統(tǒng)交由該國家負(fù)責(zé)。

3.DNS的組成

DNS的主要目標(biāo)是使資源有一個(gè)一致的名字空間。為了避免不同編碼帶來的問題，需要將網(wǎng)絡(luò)標(biāo)記、地址、路由或其它信息作為名字的一部分，要對(duì)名字所代表的資源類型有一個(gè)標(biāo)記，要支持多協(xié)議訪問。名字服務(wù)器的操作應(yīng)獨(dú)立于通信系統(tǒng)，能夠使不同的機(jī)器、不同的方法都能夠使用這一系統(tǒng)。為了要在獲取數(shù)據(jù)的代價(jià)和數(shù)據(jù)準(zhǔn)確性之間有一個(gè)平衡，DNS使用分布式的存儲(chǔ)方式。DNS由下面三個(gè)部分組成：（1）域名空間和資源記錄。域名空間是一個(gè)樹狀結(jié)構(gòu)，資源記錄是與名字相關(guān)的一些數(shù)據(jù)。每個(gè)節(jié)點(diǎn)和域名空間樹的葉子節(jié)點(diǎn)都有一定的信息，而查詢是要查詢出一些與之相關(guān)的特定信息。（2）名字服務(wù)器。又稱為DNS服務(wù)器，主要用來存放IP與主機(jī)名轉(zhuǎn)換的數(shù)據(jù)庫，并負(fù)責(zé)管理有關(guān)域名的事宜。（3）名字解釋器是向名字服務(wù)器提出查詢請(qǐng)求并將結(jié)果返回給客戶的程序，它必須可以訪問至少一個(gè)名字服務(wù)器，并將結(jié)果直接返回給用戶或向別的名字服務(wù)器查詢。它通常是用戶可以訪問的系統(tǒng)方法，在名字解釋器和用戶程序之間不需要協(xié)議。4.DNS三個(gè)部分組成之間的相互關(guān)系

下面通過三個(gè)不同的角度來看看它們的相互關(guān)系：（1）從用戶的角度，域名系統(tǒng)可以通過簡單的過程或操作系統(tǒng)調(diào)用來調(diào)用本地名字解釋器進(jìn)行查詢。域名空間包括一個(gè)單獨(dú)的樹，用戶可以從樹中的任何一個(gè)部分查詢信息。（2）從名字解釋器的角度，域名系統(tǒng)由一些名字服務(wù)器組成，每個(gè)服務(wù)器有域樹的整個(gè)或部分?jǐn)?shù)據(jù)，名字解釋器將這些數(shù)據(jù)庫視為基本是靜態(tài)的。（3）從名字服務(wù)器的角度，域名系統(tǒng)由稱為區(qū)（zone）的本地?cái)?shù)據(jù)集組成，名字服務(wù)器必須定期從主備份上更新自己區(qū)內(nèi)的數(shù)據(jù)，它還必須處理從名字解釋器傳送來的查詢請(qǐng)求。5.名字解釋過程概述

名字解釋是實(shí)現(xiàn)名字到地址的映射，將名字解釋為IP地址的過程。DNS名字服務(wù)器可實(shí)現(xiàn)對(duì)向前的解釋查詢和逆向解釋的查詢。所謂向前的解釋查詢是將名字解釋為IP地址的要求，而逆向解釋查詢則要求將IP地址解釋成名字。名字服務(wù)器只能對(duì)它可進(jìn)行認(rèn)證(authority)的一個(gè)區(qū)域(Zone)進(jìn)行查詢。如果某個(gè)名字服務(wù)器不能得到某個(gè)查詢結(jié)果，就將該查詢傳送的其它能夠得到結(jié)果的名字服務(wù)器。名字服務(wù)器將查詢結(jié)果存入高速緩沖區(qū)以減少網(wǎng)絡(luò)上的DNS傳送。（1）標(biāo)準(zhǔn)查詢(向前查詢)DNS服務(wù)使用client/server模型進(jìn)行名字解釋。在進(jìn)行向前查詢時(shí)，客戶機(jī)將一個(gè)查詢傳送到本地名字服務(wù)器。本地名字服務(wù)器或者給出查詢的解釋或?qū)⒉樵冋?qǐng)求傳送到另一臺(tái)名字服務(wù)器以得出結(jié)果。圖6.12說明了某客戶機(jī)向名字服務(wù)器查詢的IP地址的過程。

圖中的數(shù)字表示了如下的查詢步驟：圖6.12標(biāo)準(zhǔn)查詢示例

①

客戶機(jī)傳送有關(guān)的一個(gè)向前查詢到本地名字服務(wù)器。

②

本地名字服務(wù)器檢查該向前查詢的區(qū)域(zone)數(shù)據(jù)庫文件以確定是否存在客戶端所查詢的名字到IP地址的映射。由于本地名字服務(wù)器沒有關(guān)于

域的認(rèn)證權(quán)限，就將該查詢傳送到DNS的一個(gè)根服務(wù)器，要求對(duì)主機(jī)名進(jìn)行解釋。③

根名字服務(wù)器返回一個(gè)對(duì)于com名字服務(wù)器的參照。

④

本地名字服務(wù)器向com名字服務(wù)器發(fā)出查詢請(qǐng)求。⑤com名字服務(wù)器回應(yīng)有關(guān)Microsoft名字服務(wù)器的信息。

⑥

本地名字服務(wù)器向Microsoft名字服務(wù)器發(fā)出查詢請(qǐng)求，Microsoft名字服務(wù)器接收該請(qǐng)求。⑦

由于Microsoft名字服務(wù)器對(duì)于域名空間的該部分具有認(rèn)證權(quán)限，它返回

的IP地址給本地名字服務(wù)器。

⑧

本地名字服務(wù)器將

的IP地址發(fā)送給客戶機(jī)。

至此，名字解釋完成，客戶機(jī)可使用

的IP地址進(jìn)行訪問。

（2）名字服務(wù)器高速緩沖區(qū)為了加快查詢速度，將常用域名暫時(shí)存放在高速緩沖區(qū)中。當(dāng)客戶端主機(jī)向DNS查詢有關(guān)域名時(shí)，則DNS服務(wù)器會(huì)先到高速緩沖區(qū)尋找，如果有有關(guān)域名則傳回給客戶端，沒有則到最近的DNS主機(jī)尋找。當(dāng)一個(gè)名字服務(wù)器接收到一個(gè)查詢結(jié)果，將執(zhí)行下列動(dòng)作：①

名字服務(wù)器在某存活時(shí)間段TTL中將查詢結(jié)果存入高速緩沖區(qū)。TTL由提供查詢的區(qū)域指定?？墒褂肈NSsnap-in對(duì)TTL進(jìn)行配置。默認(rèn)值為60min。

②

每次將查詢結(jié)果存入高速緩沖區(qū)，TTL即開始由原始值開始倒計(jì)數(shù)。

③TTL超時(shí)，名字服務(wù)器從高速緩沖中刪除該查詢結(jié)果。

（3）逆向查詢請(qǐng)求逆向查詢將IP地址映射到名字。實(shí)際的應(yīng)用程序的安全實(shí)現(xiàn)，通常是基于連接到主機(jī)名而不是連接到IP地址。例如故障查找工具（如nslookup命令）可使用逆向查詢返回有關(guān)主機(jī)名的報(bào)告。由于DNS分布式數(shù)據(jù)庫是以名字為索引而不是以IP地址為索引的，逆向查詢需要對(duì)每個(gè)域名的窮舉搜索。要解決這個(gè)問題，建立了一種特殊的稱為的第二層域。與域名空間一樣，域遵守分層命名規(guī)則；但是它是基于IP地址的而不是基于域名的。域的構(gòu)成遵守下面的規(guī)則：·子域以域名方式表示，位于點(diǎn)分十進(jìn)制表示的IP地址之后。

·IP地址的octets順序是逆向的。

·

域的公司管理的子域基于它們被指定的IP地址和子網(wǎng)掩碼。

例如，某公司的IP地址范圍是

到55子網(wǎng)掩碼為

，具有對(duì)于16.254.169.域的認(rèn)證權(quán)限。6.IN-ADDR-ARPA域名服務(wù)DNS通過使用名字?jǐn)?shù)據(jù)庫中的資源記錄進(jìn)行名字解釋。

地址資源記錄類型中的地址字段，使用一種稱為IN-ADDR-ARPA的專用格式。這種格式允許地址和主機(jī)名之間的雙向轉(zhuǎn)換。為了更好地理解IN-ADDR-ARPA，有必要首先介紹標(biāo)準(zhǔn)格式的資源記錄。如前所述，資源記錄采用ASCII格式進(jìn)行維護(hù)。資源記錄的一種最簡單類型用于地址（類型A）。下面是一個(gè)地址文件的摘錄：

TPCI_HPWS1INA0TPCI_HPWS2INA1TPCI_HPWS3INA2TPCI_GATEWAYINA00INAMERLININASMALLWOODINA5文件的每一行表示一個(gè)資源記錄。在上述情況下，每個(gè)資源記錄都是簡單的輸入項(xiàng)。這些輸入項(xiàng)包括主機(jī)的符號(hào)名（別名）、主機(jī)的類別（IN代表Internet），A表示是地址資源記錄，后面緊跟著主機(jī)的IP地址。因?yàn)門PCI_GATEWAY主機(jī)是兩個(gè)網(wǎng)絡(luò)之間的網(wǎng)關(guān)，所以它的輸入項(xiàng)有兩個(gè)對(duì)應(yīng)地址。網(wǎng)關(guān)在每個(gè)網(wǎng)絡(luò)上有不同的地址，因此在同一個(gè)文件中有兩個(gè)資源記錄。采用上述文件類型可使主機(jī)到地址的轉(zhuǎn)換十分簡單。名字服務(wù)器只需查找應(yīng)用程序所請(qǐng)求的符號(hào)名所在行，并在行的末返回IP地址。由于數(shù)據(jù)庫索引按名稱排列，所以查找過程非常迅速。

從地址查找對(duì)應(yīng)的主機(jī)符號(hào)名比較復(fù)雜一些。如果資源記錄文件比較小，手動(dòng)查找的時(shí)間延遲并不明顯。但是，對(duì)于大型區(qū)域，輸入項(xiàng)可能有成千上萬，使用符號(hào)名索引來查找地址是相當(dāng)緩慢的。為了解決逆向變換問題，人們開發(fā)了IN-ADDR-ARPA，它采用主機(jī)地址作為主機(jī)資源記錄信息索引。IN-ADDR-ARPA使用PTR資源記錄類型(參看表6.2)，由地址指向名字。在每個(gè)名字服務(wù)器上都維護(hù)這種指針?biāo)饕?。下面是一個(gè)地址到名的轉(zhuǎn)換文件：

43.IN-ADDR-ARPA.PTRTPCI_HPWS_4.TPCI.COM47.IN-ADDR-ARPA.PTRTPCI_SERVER.MERLIN.COM23.IN-ADDR-ARPA.PTRBEAST.BEAST.COM23.143.IN-ADDR-ARPAPTRMERLINGATEWAY.MERLIN.COM為了便于使用，Internet地址在IN-ADDR-ARPA文件中是倒寫的。如上述樣本文件所示，不必為網(wǎng)關(guān)指定完整的地址，因?yàn)橛蛎梢蕴峁┳銐虻穆酚尚畔ⅰ?/p>

6.4.2WWW的核心——HTTP協(xié)議WWW服務(wù)器使用的主要協(xié)議是HTTP協(xié)議，即超文體傳輸協(xié)議。由于HTTP協(xié)議支持的服務(wù)不限于WWW，還可以是其它服務(wù)，因而HTTP協(xié)議允許用戶在統(tǒng)一的界面下，采用不同的協(xié)議訪問不同的服務(wù)，如FTP、Archie、SMTP、NNTP等。另外，HTTP協(xié)議還可用于名字服務(wù)器和分布式對(duì)象管理。

1.HTTP協(xié)議概述

超文本傳輸協(xié)議HTTP(HypertextTransferProtocol)是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它定義了瀏覽器與WWW服務(wù)器之間的通信交換機(jī)制、請(qǐng)求及響應(yīng)消息的格式等，一個(gè)WWW客戶機(jī)使用HTTP協(xié)議可以訪問遠(yuǎn)程的WWW服務(wù)器上的資源。HTTP的服務(wù)被稱為超文本傳輸協(xié)議守護(hù)進(jìn)程httpd(HyperTextTransferProtocolDaemon)。HTTP使用了統(tǒng)一資源定位器URL(UniformResourceLocator)的概念，以標(biāo)識(shí)Ineternet或者與Internet相連的主機(jī)上任何可用的數(shù)據(jù)對(duì)象。簡單地說，URL就是文件在環(huán)球信息網(wǎng)上的“地址”。當(dāng)在瀏覽器的地址框中輸入一個(gè)URL或是單擊一個(gè)超級(jí)鏈接時(shí)，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協(xié)議HTTP，將Web服務(wù)器上站點(diǎn)的網(wǎng)頁代碼提取出來，并翻譯成漂亮的網(wǎng)頁。（1）URL的組成在URL概念背后有一個(gè)基本思想，那就是在提供一定的信息條件下，應(yīng)能在Internet上的任何一臺(tái)機(jī)器上訪問任何可用的公共數(shù)據(jù)。這些信息包括：所使用的訪問協(xié)議、數(shù)據(jù)所在的機(jī)器、請(qǐng)求數(shù)據(jù)的數(shù)據(jù)源端口、通向數(shù)據(jù)的路徑和包含了所需數(shù)據(jù)的文件的名稱。這些信息組成了URL。

URL的標(biāo)準(zhǔn)格式如下：Protocol://machineaddress：port/path/filename例如：/china/index.htm。（2）HTTP協(xié)議的特點(diǎn)HTTP協(xié)議的主要特點(diǎn)可概括如下：①

支持客戶/服務(wù)器模式。②

簡單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。③

靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。④

無連接：無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。⑤

無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。但是，在服務(wù)器不需要先前的信息時(shí)它的應(yīng)答就較快。

（3）公共網(wǎng)關(guān)接口公共網(wǎng)關(guān)接口CGI（CommonGatewayInterface）是用于提供Web服務(wù)器一個(gè)外部程序的通道。它使服務(wù)器能夠建立動(dòng)態(tài)網(wǎng)頁，與其它非HTTP服務(wù)器如數(shù)據(jù)庫服務(wù)器連通。使用CGI技術(shù)建立的服務(wù)端應(yīng)用程序，稱為CGI程序。CGI程序就是一個(gè)標(biāo)準(zhǔn)的執(zhí)行文件，可使用各種程序語言開發(fā)，如Java、VBScript等。2.多用途Internet郵件擴(kuò)展MIME

多用途Internet郵件擴(kuò)展MIME（MultipurposeInternetMailExtensions）技術(shù)規(guī)范提供了一種可以在郵件中附加多種不同編碼文件的方法?，F(xiàn)在MIME已經(jīng)成為了HTTP協(xié)議標(biāo)準(zhǔn)的一個(gè)部分，可以在用來傳送可以供瀏覽器識(shí)別的信息。在MIME出現(xiàn)以前，信件內(nèi)容如果要包括聲音和動(dòng)畫，就必須把它變?yōu)锳SCII碼或把二進(jìn)制的信息變成可以傳送的編碼標(biāo)準(zhǔn)，而接收方必須經(jīng)過解碼才可以獲得聲音和圖畫信息。MIME提供了一種可以在郵件中附加多種不同編碼文件的方法。MIME是服務(wù)器通知客戶機(jī)傳送文件是什么類型的主要方法，客戶機(jī)瀏覽器也通過MIME告訴服務(wù)器它的參數(shù)。在網(wǎng)上，如果接收到的文件沒有MIME首部，就默認(rèn)它為HTML格式。但這樣顯示出來的內(nèi)容就會(huì)很單調(diào)。用在電子郵件中或用在瀏覽器上的MIME首部的內(nèi)容有所不同。在HTTP中傳送MIME時(shí)，MIME首部要簡單一些。在訪問一個(gè)網(wǎng)頁時(shí)，瀏覽器和服務(wù)器之間產(chǎn)生一個(gè)會(huì)話，作為請(qǐng)求內(nèi)容的一部分，瀏覽器發(fā)送它能夠理解的MIME類型的描述，即告訴服務(wù)器，瀏覽器除了網(wǎng)頁外還可以支持什么，服務(wù)器對(duì)這個(gè)信息一般不作什么修改?？纯聪旅孢@個(gè)首部：Content-type:text/html

在實(shí)現(xiàn)的時(shí)候，注意一定要在MIME首部后跟一個(gè)空行，否則該首部將被瀏覽器忽略，并將該首部當(dāng)作文本顯示出來。下面介紹一下標(biāo)準(zhǔn)MIME類型。

Text.文本，包括普通文本，PostScript和HTML；Multipart.多類型，指出此信息包括多種信息，不止一種類型；

Message.用于標(biāo)記不同類型的消息；

Application.應(yīng)用類型；

Image.圖象，用于標(biāo)明圖形文件；

Audio.聲音，用于標(biāo)明聲音文件；

Video.影象，用于標(biāo)明動(dòng)畫文件。

每個(gè)MIME類型有不同的子類型。IANA規(guī)定了對(duì)45種類型/子類型的支持，也允許用戶自定義自己的類型，用戶自定義類型要以“X-”開始以示區(qū)別。HTTP協(xié)議是基于請(qǐng)求／響應(yīng)模式的。一個(gè)客戶機(jī)與服務(wù)器建立連接后，發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求的格式為：統(tǒng)一資源標(biāo)識(shí)符、協(xié)議版本號(hào)，后邊是MIME信息，包括請(qǐng)求修飾符、客戶機(jī)信息和可能的內(nèi)容。服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤的代碼，后邊是MIME信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容。許多HTTP通訊是由一個(gè)用戶代理初始化的并且包括一個(gè)申請(qǐng)?jiān)谠捶?wù)器上資源的請(qǐng)求。最簡單的情況可能是在用戶代理和服務(wù)器之間通過一個(gè)單獨(dú)的連接來完成。在Internet上，HTTP通訊通常發(fā)生在TCP/IP連接之上。默認(rèn)端口是TCP80。

HTTP通訊最簡單的情況可能是在用戶代理(UA)和源服務(wù)器(O)之間通過一個(gè)單獨(dú)的連接來完成。當(dāng)一個(gè)或多個(gè)中介出現(xiàn)在請(qǐng)求／響應(yīng)鏈中時(shí)，情況就變得復(fù)雜一些。中介有三種：代理(Proxy)、網(wǎng)關(guān)(Gateway)和通道(Tunnel)。一個(gè)代理根據(jù)URL的絕對(duì)格式來接受請(qǐng)求，重寫全部或部分消息，通過URL的標(biāo)識(shí)把已格式化過的請(qǐng)求發(fā)送到服務(wù)器。網(wǎng)關(guān)是一個(gè)接收代理，作為一些其它服務(wù)器的上層，并且如果必須的話，可以把請(qǐng)求翻譯給下層的服務(wù)器協(xié)議。一個(gè)通道作為不改變消息的兩個(gè)連接之間的中繼點(diǎn)。當(dāng)通訊需要通過一個(gè)中介(例如：防火墻等)或者是中介不能識(shí)別消息的內(nèi)容時(shí)，經(jīng)常使用通道。

圖6.14表明了在用戶代理(UA)和源服務(wù)器(O)之間有三個(gè)中介(A、B和C)。盡管圖6.14是線性的，每個(gè)參與者都可能從事多重的、并發(fā)的通訊。例如，B可能從許多客戶機(jī)接收請(qǐng)求而不通過A，并且／或者不通過C把請(qǐng)求送到A，在同時(shí)它還可能處理A的請(qǐng)求。

圖6.14用戶代理和源服務(wù)器之間有三個(gè)中介

任何針對(duì)不作為通道的匯聚可能為處理請(qǐng)求啟用一個(gè)內(nèi)部緩存。緩存的效果是請(qǐng)求／響應(yīng)鏈被縮短，條件是沿鏈的參與者之一具有一個(gè)緩存的響應(yīng)作用于那個(gè)請(qǐng)求。圖6.15說明結(jié)果鏈，其條件是針對(duì)一個(gè)未被UA或A加緩存的請(qǐng)求，B有一個(gè)經(jīng)過C來自O(shè)的一個(gè)前期響應(yīng)的緩存拷貝。3.HTTP協(xié)議的內(nèi)部操作過程

基于HTTP協(xié)議的客戶/服務(wù)器模式的信息交換過程包括：建立連接、發(fā)送請(qǐng)求信息、發(fā)送響應(yīng)信息、關(guān)閉連接。當(dāng)服務(wù)器上的HTTP守護(hù)進(jìn)程接收到請(qǐng)求，在進(jìn)行必要的操作后回送所要求的文件。(1)建立連接

連接的建立是通過申請(qǐng)?zhí)捉幼?Socket)實(shí)現(xiàn)的。服務(wù)器上有一個(gè)HTTP守護(hù)進(jìn)程，用于響應(yīng)用戶請(qǐng)求。WWW服務(wù)器運(yùn)行時(shí)，一直在TCP80端口(WWW的默認(rèn)端口)監(jiān)聽，等待連接的出現(xiàn)。當(dāng)客戶瀏覽器中輸入了一個(gè)URL或點(diǎn)擊了一個(gè)超級(jí)鏈接時(shí)，瀏覽器就向服務(wù)器發(fā)送了HTTP連接請(qǐng)求，打開一個(gè)套接字并把它約束在一個(gè)端口上，如果成功，就相當(dāng)于建立了一個(gè)虛擬文件。以后就可以在該虛擬文件上寫數(shù)據(jù)并通過網(wǎng)絡(luò)向外傳送。(2)發(fā)送請(qǐng)求信息打開一個(gè)連接后，客戶機(jī)把請(qǐng)求消息送到服務(wù)器的特定端口上，完成提出請(qǐng)求動(dòng)作。HTTP/1.0請(qǐng)求消息的格式為：請(qǐng)求消息=請(qǐng)求行(通用信息|請(qǐng)求首部|實(shí)體首部)CRLF[實(shí)體內(nèi)容]請(qǐng)求行=方法請(qǐng)求URL

HTTP版本號(hào)CRLF方法=GET|HEAD|POST|擴(kuò)展方法URL=協(xié)議名稱+宿主名+目錄與文件名請(qǐng)求行中的方法描述指定資源中應(yīng)該執(zhí)行的動(dòng)作，常用的方法有GET、HEAD和POST。不同的請(qǐng)求對(duì)象對(duì)應(yīng)GET的結(jié)果是不同的，對(duì)應(yīng)關(guān)系如下：對(duì)象GET的結(jié)果：文件文件的內(nèi)容程序該程序的執(zhí)行結(jié)果數(shù)據(jù)庫查詢查詢結(jié)果HEAD——要求服務(wù)器查找某對(duì)象的元信息，而不是對(duì)象本身。POST——從客戶機(jī)向服務(wù)器傳送數(shù)據(jù)，在要求服務(wù)器和CGI做進(jìn)一步處理時(shí)會(huì)用到POST方法。POST主要用于發(fā)送HTML文本中FORM的內(nèi)容，讓CGI程序處理。一個(gè)請(qǐng)求的例子為：GEThttp://WWW./home.htmlHTTP/1.0（3）發(fā)送響應(yīng)消息服務(wù)器在處理完客戶的請(qǐng)求之后，要向客戶機(jī)發(fā)送響應(yīng)消息。HTTP/1.0的響應(yīng)消息格式如下：響應(yīng)消息=狀態(tài)行(通用信息首部|響應(yīng)首部|實(shí)體首部)

CRLF〔實(shí)體內(nèi)容〕狀

態(tài)

行=HTTP版本號(hào)狀態(tài)碼原因敘述狀態(tài)碼表示響應(yīng)類型響應(yīng)首部的信息包括：服務(wù)程序名，通知客戶請(qǐng)求的URL需要認(rèn)證，請(qǐng)求的資源何時(shí)能使用。（4）關(guān)閉連接客戶和服務(wù)器雙方都可以通過關(guān)閉套接字來結(jié)束TCP/IP對(duì)話。4.HTTP連接觀察實(shí)例

在HTTP協(xié)議中，服務(wù)端是指提供HTTP服務(wù)的部分，客戶端是指使用的瀏覽器或者下載工具等等。在通訊時(shí)，由客戶端發(fā)出請(qǐng)求連接，服務(wù)端建立連接；然后，客戶端發(fā)出HTTP請(qǐng)求（Request），服務(wù)端返回響應(yīng)信息（Respond），由此完成一個(gè)HTTP操作。與FTP（文件傳輸協(xié)議）不同，由于主要用于超文本傳輸，因此HTTP協(xié)議顯得更簡單一點(diǎn)。下面用Net

Vampire監(jiān)測的一次HTTP連接，使用Net

Vampire

Pro

4.0來取得與HTTP服務(wù)器的通信Log，以顯示和介紹HTTP協(xié)議的連接過程和HTTP/1.1的基本格式。

6.4.3其他常見的應(yīng)用層協(xié)議

1.郵件服務(wù)協(xié)議SMTP/POP3

2.SMTP協(xié)議原理

3.POP3郵局協(xié)議

4.遠(yuǎn)程登錄Telnet

5.文件傳送協(xié)議FTP

1.郵件服務(wù)協(xié)議SMTP/POP3

簡單郵件傳輸協(xié)議SMTP（SimpleMailTransferProtocol）的目標(biāo)是可靠高效地傳送郵件，它獨(dú)立于傳送子系統(tǒng)而且僅要求一條可以保證傳送數(shù)據(jù)單元順序的通道。SMTP的一個(gè)重要特點(diǎn)是它能夠在傳送中接力傳送郵件，傳送服務(wù)提供了進(jìn)程間通信環(huán)境，此環(huán)境可以包括一個(gè)網(wǎng)絡(luò)，幾個(gè)網(wǎng)絡(luò)或一個(gè)網(wǎng)絡(luò)的子網(wǎng)。理解到傳送系統(tǒng)（或進(jìn)程間通信環(huán)境）不是一對(duì)一的是很重要的。進(jìn)程可能直接和其它進(jìn)程通過已知的IPCE通信。郵件是一個(gè)應(yīng)用程序或進(jìn)程間通信。郵件可以通過連接在不同IPCE上的進(jìn)程跨網(wǎng)絡(luò)進(jìn)行郵件傳送。更特別的是，郵件可以通過不同網(wǎng)絡(luò)上的主機(jī)接力式傳送。SMTP設(shè)計(jì)基于以下通信模型：針對(duì)用戶的郵件請(qǐng)求，發(fā)送SMTP建立與接收SMTP之間建立一個(gè)雙向傳送通道。接收SMTP可以是最終接收者也可以是中間傳送者。SMTP命令由發(fā)送SMTP發(fā)出，由接收SMTP接收，而應(yīng)答則反方面?zhèn)魉汀Ｒ坏﹤魉屯ǖ澜?，SMTP發(fā)送者發(fā)送MAIL命令指明郵件發(fā)送者。如果SMTP接收者可以接收郵件則返回OK應(yīng)答。SMTP發(fā)送者再發(fā)出RCPT命令確認(rèn)郵件是否接收到。如果SMTP接收者接收，則返回OK應(yīng)答；如果不能接收到，則發(fā)出拒絕接收應(yīng)答（但不中止整個(gè)郵件操作），雙方將如此重復(fù)多次。當(dāng)接收者收到全部郵件后會(huì)接收到特別的序列，如果接收者成功處理了郵件，則返回OK應(yīng)答。圖6.16示出了SMTP的通信模型。圖6.16SMTP通信模型

SMTP提供傳送郵件的機(jī)制，如果接收方與發(fā)送方連接在同一個(gè)傳送服務(wù)下時(shí)，郵件可以直接由發(fā)送方主機(jī)傳送到接收方主機(jī)；當(dāng)兩者不在同一個(gè)傳送服務(wù)下時(shí)，通過中繼SMTP服務(wù)器傳送。為了對(duì)SMTP服務(wù)器提供中繼能力，它必須擁有最終目的主機(jī)地址和郵箱名稱。MAIL命令參數(shù)是回復(fù)路徑，它指定郵件從何處來；而RCPT命令的參數(shù)是轉(zhuǎn)發(fā)路徑的，它指定郵件向何處去。向前路徑是源路徑，而回復(fù)路徑是返回路徑（它用于發(fā)生錯(cuò)誤時(shí)返回郵件）。當(dāng)同一個(gè)消息要發(fā)往不同的接收者時(shí)，SMTP遇到了向不同接收者發(fā)送同一份數(shù)據(jù)的復(fù)制品的問題，郵件命令和應(yīng)答有一個(gè)比較奇怪的語法，應(yīng)答也有一個(gè)數(shù)字代碼。命令與應(yīng)答對(duì)大小寫不敏感，也就是說，命令和應(yīng)答可以是大寫，小寫或兩者的混合，而SMTP實(shí)現(xiàn)中將用戶郵箱名稱保留成初始時(shí)的樣子，主機(jī)名稱對(duì)大小寫不敏感。2.SMTP協(xié)議原理

簡單郵件傳輸協(xié)議SMTP是定義郵件傳輸?shù)膮f(xié)議，它是基于TCP服務(wù)的應(yīng)用層協(xié)議，由RFC0821所定義。SMPT協(xié)議規(guī)定的命令是以明文方式進(jìn)行的。為了說明SMTP的工作原理，以向www.L發(fā)送郵件為實(shí)例進(jìn)行說明。（1）接收和發(fā)送郵件的全過程在Linux環(huán)境下，使用telnet命令連接www.L的25號(hào)端口(SMTP的標(biāo)準(zhǔn)服務(wù)端口)；在windows下使用telnet程序，遠(yuǎn)程主機(jī)指定為www.L，而端口號(hào)指定為25，然后連接www.L：交互過程如下：其中頂格部分是輸入的命令，其他內(nèi)容是對(duì)方郵件服務(wù)器輸出的狀態(tài)信息。這里，HELO是客戶向?qū)Ψ洁]件服務(wù)器發(fā)出的標(biāo)識(shí)自己的身份的命令，這里假設(shè)發(fā)送者為ideal；MAILFROM命令用來表示發(fā)送者的郵件地址；RCPTTO：標(biāo)識(shí)接收者的郵件地址，這里表示希望發(fā)送郵件給ideal@L，如果郵件接收者不是本地用戶，例如RCPTTO：ideal@，則說明希望對(duì)方郵件服務(wù)器為自己轉(zhuǎn)發(fā)(Relay)郵件，若該機(jī)器允許轉(zhuǎn)發(fā)這樣的郵