第8章 傳輸層

傳輸協(xié)議(transport protocol)是整個(gè)網(wǎng)絡(luò)體系結(jié)構(gòu)中的關(guān)鍵之一。本章討論TCP/IP體系中的運(yùn)輸協(xié)議UDP和TCP。TCP比UDP復(fù)雜得多。最重要的是應(yīng)弄清端口的概念及TCP的各種機(jī)制(如面向連接的可靠服務(wù)、序號(hào)、確認(rèn)、窗口、擁塞控制等)以及TCP有關(guān)連接管理和狀態(tài)圖的概念。

8.1 傳輸協(xié)議概述

從通信和信息處理的角度．運(yùn)輸層向它上面應(yīng)用層提供通信服務(wù)，它屬于面向通信部分的最高層，同時(shí)也是用功能中的最低層、運(yùn)輸層只存在于通信子網(wǎng)以外的主機(jī)中，在

通信子網(wǎng)中沒有運(yùn)輸層，如圖8-所示。

下面通過圖8-1的示意圖來說明運(yùn)輸層的作用。設(shè)局域網(wǎng)1上的主機(jī)A和局域網(wǎng)2上的主機(jī)B通過互連的廣域網(wǎng)進(jìn)行通信。既然IP協(xié)議能夠?qū)⒃粗鳈C(jī)發(fā)送出的分組按照首部中的目的地址送交到目的主機(jī)，那么，為什么還需要再設(shè)置一個(gè)運(yùn)輸層呢

圖8-1 傳輸層為相互通信的應(yīng)用進(jìn)程提供了邏輯通信

嚴(yán)格地講，兩個(gè)主機(jī)進(jìn)行通信實(shí)際上就是兩個(gè)主機(jī)中的應(yīng)用進(jìn)程互相通信。IP協(xié)議雖然能把分組送到目的主機(jī)，但是這個(gè)分組還停留在主饑的網(wǎng)絡(luò)層而沒有交付給主機(jī)中的應(yīng)用進(jìn)程(請(qǐng)注意：IP地址是標(biāo)識(shí)在因特網(wǎng)中的—個(gè)主機(jī)，而不是標(biāo)識(shí)主機(jī)中的應(yīng)用進(jìn)程)。然而一個(gè)主機(jī)中經(jīng)常有多個(gè)應(yīng)用進(jìn)程同時(shí)分別和另一個(gè)主機(jī)中的多個(gè)應(yīng)用進(jìn)程通信。例如，某用戶在使用瀏覽器查找某網(wǎng)站的信息時(shí)，其主機(jī)的應(yīng)用層運(yùn)行瀏覽器客戶進(jìn)程。如果在瀏覽網(wǎng)頁的同時(shí)，還要用電子郵件給網(wǎng)站發(fā)送反饋意見，那么主機(jī)的應(yīng)用層就還要運(yùn)行電子郵件的客戶進(jìn)程：在圖8-1中，主機(jī)A的應(yīng)用進(jìn)程l和主機(jī)B的應(yīng)用進(jìn)程3通信，而與此同時(shí)，應(yīng)用進(jìn)程2也和對(duì)方的應(yīng)用進(jìn)程4通信。運(yùn)輸層的—個(gè)很重要的功能就是復(fù)用和分用。應(yīng)用層不同進(jìn)程的報(bào)文通過不同的端口(在8.2.2節(jié)還要詳細(xì)討論端口的概念)向下交到運(yùn)輸層，再往下就共用網(wǎng)絡(luò)層提供的服務(wù)。當(dāng)這些報(bào)文沿著圖中的虛線到達(dá)目的主機(jī)后，目的主機(jī)的運(yùn)輸層就使用其分用功能，通過不同的端口將報(bào)文分別交付到相應(yīng)的應(yīng)用進(jìn)程。圖8-2中兩個(gè)運(yùn)輸層之間有一個(gè)粗的雙向箭頭，寫明“運(yùn)輸層提供應(yīng)用進(jìn)程間的邏輯通信”。“邏輯通信”的意思是：應(yīng)用進(jìn)程的報(bào)文到達(dá)運(yùn)輸層后，從效果上看，就好像是直接沿水平方向傳送到遠(yuǎn)地的運(yùn)輸層。當(dāng)然事實(shí)上這兩個(gè)應(yīng)用進(jìn)程之間并沒有一條水平方向的物理連接。要傳送的數(shù)據(jù)是沿著圖中的虛線方向傳送的。

從這里可以看出網(wǎng)絡(luò)層和運(yùn)輸層有很大的區(qū)別。運(yùn)輸層為應(yīng)用進(jìn)程之間提供邏輯通信，但網(wǎng)絡(luò)層是為主機(jī)之間提供邏輯通信，如圖8-2所示。如果運(yùn)輸層只有這—點(diǎn)復(fù)用和分用功能，那么取消運(yùn)輸層而讓網(wǎng)絡(luò)層增加這一點(diǎn)功能也未嘗不可。然而，運(yùn)輸層還具有網(wǎng)絡(luò)層無法代替的許多其他重要功能。

圖8-2 運(yùn)輸層協(xié)議和網(wǎng)絡(luò)層協(xié)議的主要區(qū)別

其次，運(yùn)輸層還要對(duì)收到的報(bào)文進(jìn)行差錯(cuò)檢測(cè)。大家應(yīng)當(dāng)還記得，在網(wǎng)絡(luò)層，IP數(shù)據(jù)報(bào)首部中的檢驗(yàn)和字段，只檢驗(yàn)首部是否出現(xiàn)差錯(cuò)而不檢查數(shù)據(jù)部分。

圖8-3 運(yùn)輸層與其上下層之間的關(guān)系的OSI表示法

再次，根據(jù)應(yīng)用的不同，運(yùn)輸層需要有兩種不同的運(yùn)輸協(xié)議，即面向連接的TCP和無連接的UDP，而網(wǎng)絡(luò)層無法同時(shí)實(shí)現(xiàn)這兩種協(xié)議。

OSI使用了簡(jiǎn)潔的抽象方法將運(yùn)輸層與其上下層之間的關(guān)系歸納如圖8-3所示。

根據(jù)OSI的觀點(diǎn)，運(yùn)輸層中向應(yīng)用層提供運(yùn)輸服務(wù)的是運(yùn)輸實(shí)體。使用運(yùn)輸服務(wù)的是運(yùn)輸服務(wù)用戶(也就是應(yīng)用層中的各種應(yīng)用進(jìn)程，或應(yīng)用層實(shí)體，但不是使用計(jì)算機(jī)的最終用戶)。運(yùn)輸層中的兩個(gè)對(duì)等運(yùn)輸實(shí)體之間的通信遵循著運(yùn)輸協(xié)議。運(yùn)輸協(xié)議保證了運(yùn)輸層能夠向應(yīng)用層提供運(yùn)輸服務(wù)。運(yùn)輸層提供的運(yùn)輸服務(wù)也使用了下面網(wǎng)絡(luò)層向上提供的網(wǎng)絡(luò)服務(wù)。TSAP和NSAP分別是運(yùn)輸層和網(wǎng)絡(luò)層的服務(wù)訪問點(diǎn)，它們都是層與層之間交換信息的抽象

接口。

我們要再次強(qiáng)調(diào)指出，運(yùn)輸層向高層用戶屏蔽了下面通信子網(wǎng)的細(xì)節(jié)(如網(wǎng)絡(luò)拓?fù)?、所采用的協(xié)議等)，它使應(yīng)用進(jìn)程看見的就是好像在兩個(gè)運(yùn)輸層實(shí)體之間有一條端到端的邏輯通信信道，但這條邏輯通信信道對(duì)上層的表現(xiàn)卻因運(yùn)輸層使用的不同協(xié)議而有很大的差別。當(dāng)運(yùn)輸層采用面向連接的TCP協(xié)議時(shí)，盡管下面的網(wǎng)絡(luò)是不可靠的(即只提供盡最大努力服務(wù))，但這種邏輯通信信道就相當(dāng)于一條全雙工的可靠信道。但當(dāng)運(yùn)輸層采用無連接的UDP協(xié)議時(shí)，這種邏輯通信信道則是一條不可靠信道。在圖8-4中我們將可靠信道畫成一個(gè)管道，這意味著報(bào)文在這樣的“管道”中運(yùn)輸時(shí)，可以做到無差錯(cuò)、按序(接收的順序和發(fā)送的順序一樣)、無丟失和無重復(fù)。對(duì)不可靠信道就用一個(gè)云狀網(wǎng)絡(luò)來表示，它不具備可靠倍道的按序、無丟失和無重復(fù)的特性，但仍具有無差錯(cuò)的特性。只要檢查出報(bào)文有差錯(cuò)就將其丟棄。最后再強(qiáng)調(diào)一下，我們說運(yùn)輸層提供可靠的交付，是指運(yùn)輸層將數(shù)據(jù)可靠地交付給接收端的應(yīng)用層，但應(yīng)用層是否再可靠地交付給最終用戶，現(xiàn)在還不知道。

圖8-4運(yùn)輸層向上提供可靠的和不可靠的邏輯通信信道

8.2 TCP/IP體系中的運(yùn)輸層

8.2.1 運(yùn)輸層中的兩個(gè)協(xié)議

TCP/IP的運(yùn)輸層有兩個(gè)不同的協(xié)議，如圖8-5所示，它們都是因特網(wǎng)的正式標(biāo)準(zhǔn)。即：(1)用戶數(shù)據(jù)報(bào)協(xié)議UDP(User Datagram Protocol)：見[RFC 793]。

(2)傳輸控制協(xié)議TCP(Transmission Control Protocol)：見[RFC 768]。

按照OSI的術(shù)語，兩個(gè)對(duì)等運(yùn)輸實(shí)體在通信時(shí)傳送的數(shù)據(jù)單位叫做運(yùn)輸協(xié)議數(shù)據(jù)單元TPDU(Transport Protocol Data Unit)。但在TCP/IP體系中，則根據(jù)所使用的協(xié)議是TCP或UDP，分別稱之為TCP報(bào)文段(segment)或UDP報(bào)文或用戶數(shù)據(jù)報(bào)。

UDP在傳送數(shù)據(jù)之前不需要先建立連接。遠(yuǎn)地主機(jī)的運(yùn)輸層在收到UDP報(bào)文后，不需要給出任何確認(rèn)。雖然UDP不提供可靠交付，但在某些情況下UDP是—種最有效的工作方式。TCP/IP體系中的應(yīng)用服務(wù)，如DNS和NFS就使用UDP這種運(yùn)輸方式。

圖8-5 TCP/IP 體系中的運(yùn)輸層協(xié)議

TCP則提供面向連接的服務(wù)。在傳送數(shù)據(jù)之前必須先建立連接，數(shù)據(jù)傳送結(jié)束后要釋放連接。即不提供廣播或多播服務(wù)。由于TCP要提供可靠的、面向連接的運(yùn)輸服務(wù)，因此不可避免地增加了許多的開銷，如確認(rèn)、流量控制、計(jì)時(shí)器以及連接管理等。這不僅使協(xié)議數(shù)據(jù)單元的首部增大很多，還要占用許多的處理機(jī)資源。

這里還要強(qiáng)調(diào)兩點(diǎn)：

(1)運(yùn)輸層的UDP用戶數(shù)據(jù)報(bào)與網(wǎng)際層的IP數(shù)據(jù)報(bào)有很大的區(qū)別。IP數(shù)據(jù)報(bào)要經(jīng)過互連網(wǎng)中許多路由器的存儲(chǔ)轉(zhuǎn)發(fā)，但UDP用戶數(shù)據(jù)報(bào)是在運(yùn)輸層的端到端抽象的邏輯信道中傳送的。這個(gè)邏輯信道雖然也是盡最大努力交付(因而不可靠)，但運(yùn)輸層的這個(gè)邏輯信道并不經(jīng)過路由器(運(yùn)輸層看不見路由器)，因?yàn)槁酚善髦挥邢氯龑訁f(xié)議而沒有運(yùn)輸層。IP數(shù)據(jù)報(bào)雖然經(jīng)過路由器進(jìn)行轉(zhuǎn)發(fā)，但用戶數(shù)據(jù)報(bào)只是IP數(shù)據(jù)報(bào)中的數(shù)據(jù)，因此路由器看不見有用戶數(shù)據(jù)報(bào)經(jīng)過它。這兩種數(shù)據(jù)報(bào)不能弄混。

(2)TCP連接也和網(wǎng)絡(luò)層中的虛電路(X.25所使用的)完全不同。TCP報(bào)文段是在運(yùn)輸層的端到端抽象的邏輯信道中傳送，但TCP連接是可靠的全雙工信道，不涉及到互連網(wǎng)中的路由器。這些路由器根本不知道上面的運(yùn)輸層建立了多少個(gè)TCP連接。然而在X.25建立的虛電路所經(jīng)過的交換結(jié)點(diǎn)中，都要保存X.25虛電路的狀態(tài)信息。

8.2.2 端口的概念

UDP和TCP都使用了與應(yīng)用層接口處的端口(port)與上層的應(yīng)用進(jìn)程進(jìn)行通信。端口是個(gè)非常重要的概念，因?yàn)閼?yīng)用層的各種進(jìn)程是通過相應(yīng)的端口與運(yùn)輸實(shí)體進(jìn)行交互。當(dāng)運(yùn)輸層收到IP層交上來的數(shù)據(jù)(即TCP報(bào)文段或UDP用戶數(shù)據(jù)報(bào))時(shí)，就要根據(jù)其中首部的端口號(hào)來決定應(yīng)當(dāng)通過哪—個(gè)端口上交給應(yīng)當(dāng)接收此數(shù)據(jù)的應(yīng)用進(jìn)程。圖8-6說明了端口在進(jìn)程之間的通信中所起的作用。

用OSI的術(shù)語，圖中的端口就是運(yùn)輸層服務(wù)訪問點(diǎn)TSAPC可以看出，若沒有端口，運(yùn)輸層就無法知道數(shù)據(jù)應(yīng)當(dāng)交付給應(yīng)用層的哪一個(gè)進(jìn)程。從這個(gè)意義上講，端口是用來標(biāo)識(shí)應(yīng)用層的進(jìn)程。由于使用了復(fù)用和分用技術(shù)，在運(yùn)輸層與網(wǎng)絡(luò)層的交互中已看不見各種應(yīng)用進(jìn)程，而只有TCP報(bào)文段或用戶數(shù)據(jù)報(bào)。IP層也使用類似的復(fù)用和分用技術(shù)，因而在網(wǎng)絡(luò)層和鏈路層的交互中也只有IP數(shù)據(jù)報(bào)。上述概念在網(wǎng)絡(luò)中是十分重要的。

圖8-6端口在進(jìn)程之間的通信中所起的作用

在運(yùn)輸層與應(yīng)用層的接口上所設(shè)置端口是一個(gè)16 bit的地址，并用端口號(hào)進(jìn)行標(biāo)識(shí)。端口就是一個(gè)抽象的定位符，有時(shí)也可稱為郵箱(mailbox)。端口的基本概念就是：應(yīng)用層的源進(jìn)程將報(bào)文發(fā)送給運(yùn)輸層的某個(gè)端口，而應(yīng)用層的目的進(jìn)程從端口接收?qǐng)?bào)文。端口號(hào)只具有本地意義。即端口號(hào)只是為了標(biāo)識(shí)本計(jì)算機(jī)應(yīng)用層中的各進(jìn)程。不同計(jì)算機(jī)中的相同端口號(hào)是沒有聯(lián)系的。16比的端口號(hào)可允許有64K個(gè)端口號(hào)，這個(gè)數(shù)目對(duì)一個(gè)計(jì)算機(jī)來說是足夠用的。

端口號(hào)分為兩類。一類是由因特網(wǎng)指派名字和號(hào)碼公司I。ANN負(fù)責(zé)分配給—些常用的應(yīng)用層程序固定使用的熟知端口(well-known port)，其數(shù)值一股為0～l023，見[RFC1700]。例如，F(xiàn)TP用21，TELNET用23，SMTP用25，DNS用53，HTTP用80，SNMP用161，等等。“熟知”就表示這些端口號(hào)是TCP/IP體系確定并公布的，因而是所有用戶進(jìn)程都知道的。當(dāng)一種新的應(yīng)用程序出現(xiàn)時(shí)，必須為它指派一個(gè)熟知端口，否則其他的應(yīng)用進(jìn)程就無法和它進(jìn)行交互。在應(yīng)用層中的各種不同的服務(wù)器進(jìn)程不斷地檢測(cè)分配給它們的熟知端口，以便發(fā)現(xiàn)是否某個(gè)客戶進(jìn)程要和和它通信。另一類則是一般端口，用來隨時(shí)分配給請(qǐng)求通信的客戶進(jìn)程。

圖8-8舉例說明了端口的作用。設(shè)主機(jī)A使用簡(jiǎn)單郵件傳送協(xié)議SMTP與主機(jī)。通信。SMTP使用而向連接的TCPC為了找到目的主機(jī)中的SMTP，主機(jī)A與主機(jī)。建立的連接要使用目的主機(jī)中的熟知端口，其端口號(hào)為25。主機(jī)A也要給自己的進(jìn)程分配一個(gè)端口號(hào)，設(shè)分配的源端口號(hào)為1500。這就是主機(jī)A和主機(jī)。建立的第一連接。圖中的連接畫成虛線，表示這種連接不是物理連接而只是個(gè)虛連接(即邏輯連接)。

現(xiàn)在主機(jī)A中的另一個(gè)進(jìn)程也要和主機(jī)。中的SMTP建立連接。目的端口號(hào)仍為25，但其源端口號(hào)不能與上一個(gè)連接的重復(fù)。設(shè)主機(jī)A分配的這個(gè)源端口號(hào)為1501。這是主機(jī)A和主機(jī)。建立的第二個(gè)連接。

設(shè)主機(jī)B現(xiàn)在也要和主機(jī)C的SMTP建立連接，端口號(hào)當(dāng)然還是25。主機(jī)B選擇源端口號(hào)為1500。這是和主機(jī)C建立的第三個(gè)連接。這里的源端口號(hào)與第一個(gè)連接的源端口號(hào)相同，但純屬巧合。各主機(jī)都獨(dú)立地分配自已的端口號(hào)。

為了在通信時(shí)不致發(fā)生混亂，就必須把端口號(hào)和主機(jī)的IP地址結(jié)合在—起使用，在圖8-8中，主機(jī)A和B雖然都使用了相同的源端口號(hào)1500．但只要查一下IP地址就可知道是哪一個(gè)主機(jī)的數(shù)據(jù)。

因此，TCP使用“連接”(而不僅僅是“端口”)作為最基本的抽象。一個(gè)連接由它的兩個(gè)端點(diǎn)來標(biāo)識(shí)。這樣的端點(diǎn)就叫做插口(socket)或套接字。插口的概念并不復(fù)雜，但非常重要。插口包括IP地址(32 bit)和端口號(hào)(16 bit)，共48 bit。插口和端口、IP地址的關(guān)系如圖8-9所示。

在整個(gè)因特網(wǎng)中，在運(yùn)輸層通信的一對(duì)插口必須是惟一的。例如：對(duì)圖8-8中的連接1的一對(duì)插口是：

(131.6.23.13,1500)和(130.42.85.15,25)

意思是：IP地址為131.6.23.13的主機(jī)用端口1500和IP地址為130.42.85.15的主機(jī)端口25建立了連接1，而連接2的一對(duì)插口是：

(131.6.23.13,1501和(230.42.85.15,25)

意思是：IP地址為131.6.23.13的土機(jī)用端口1501和IP地址為130.42.85.15的主機(jī)的端口25建立了連接2。

上面的例子是使用面向連接的TCP。若使用無連接的DDP，雖然在相互通信的兩個(gè)進(jìn)程之間沒有一條虛連接，但發(fā)送端UDP一定有一個(gè)發(fā)送端口而在接收端UDP一定有—個(gè)接收端口，因而也同樣可使用插口的概念。這樣才能區(qū)分多個(gè)主機(jī)中同時(shí)通信的多個(gè)進(jìn)程。

值得注意的是，插口這個(gè)名詞很容易讓人將一些概念弄混淆，因?yàn)橥粋€(gè)名詞socket有多種不同的意思。例如：

(1)允許應(yīng)用程序訪問連網(wǎng)協(xié)議的應(yīng)用編程接口API(Application Programming Interface)，也就是在運(yùn)輸層和應(yīng)用層之間的—種接口，稱為socket API，并簡(jiǎn)稱為socket。

(2)在socket API中使用的—個(gè)函數(shù)名也叫做socket。

(3)調(diào)用socket函數(shù)的端點(diǎn)稱為socket，如“創(chuàng)建—個(gè)數(shù)據(jù)報(bào)socket”。

(4)socket函數(shù)的返回值稱為socket描述符，可簡(jiǎn)稱為socket。

(5)在操作系統(tǒng)內(nèi)核中連網(wǎng)協(xié)議的Berkeley實(shí)現(xiàn)稱為socket實(shí)現(xiàn)。

上面的這些socket的意思都和本章中的socket(指IP地址和端口號(hào)的組合)不同。

8.3 用戶數(shù)據(jù)報(bào)協(xié)議UDP

本節(jié)將分別介紹UDP和TCP的要點(diǎn)。由于UDP很簡(jiǎn)單，因而本節(jié)以討論TCP為重點(diǎn)。

8.3.1 用戶數(shù)據(jù)報(bào)的用途

用戶數(shù)據(jù)報(bào)協(xié)議UDP只在IP的數(shù)據(jù)報(bào)服務(wù)之上增加了很少—點(diǎn)的功能，這就是端口的功能(有了端口，運(yùn)輸層就能進(jìn)行復(fù)用和分用)和無差錯(cuò)檢測(cè)的功能。雖然UDP用戶數(shù)據(jù)報(bào)只能提供不可靠的交付，但UDP在某些方面有其特殊的優(yōu)點(diǎn)，例如：

(1)發(fā)送數(shù)據(jù)之前不需要建立連接(當(dāng)然發(fā)送數(shù)據(jù)結(jié)束時(shí)也沒有連接需要釋放)，因而減少了開銷和發(fā)送數(shù)據(jù)之前的時(shí)延。

(2)UDP沒有擁塞控制，也不保證可靠交付，因此主機(jī)不需要維持具有許多參數(shù)的、復(fù)雜的連接狀態(tài)表。

(3)UDP用戶數(shù)據(jù)報(bào)只有8個(gè)字節(jié)的首都開銷，比TCP的20個(gè)字節(jié)的首部要短。

(4)由于UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)的擁塞不會(huì)使源主機(jī)的發(fā)送速率降低。這對(duì)某些實(shí)時(shí)應(yīng)用是很重要的。很多的實(shí)時(shí)應(yīng)用(如IP電話、實(shí)時(shí)視頻會(huì)議等)要求源主機(jī)以恒定的速率發(fā)送數(shù)據(jù)，并且允許在網(wǎng)絡(luò)發(fā)生擁塞時(shí)丟失一些數(shù)據(jù)，但不允許數(shù)據(jù)有太大的時(shí)延。UDP正好適合這種要求。

雖然某些實(shí)時(shí)應(yīng)用需要使用沒有擁塞控制的UDP，但當(dāng)很多的源主機(jī)同時(shí)都向網(wǎng)絡(luò)發(fā)送高速率的實(shí)時(shí)視頻流時(shí)，網(wǎng)絡(luò)就有可能發(fā)生擁塞，結(jié)果大家都無法正常接收。因此“UDP不具有擁塞控制功能”，可能會(huì)引起網(wǎng)絡(luò)產(chǎn)生嚴(yán)重的擁塞問題。

還有些使用UDP的實(shí)時(shí)應(yīng)用需要對(duì)UDP的不可靠的傳輸進(jìn)行適當(dāng)?shù)母倪M(jìn)以減少數(shù)據(jù)的丟失。在這種情況下，應(yīng)用進(jìn)程本身可在不影響應(yīng)用的實(shí)時(shí)性的前提下增加一些提高可靠性的措施，如采用前向糾錯(cuò)或重傳已丟失的報(bào)文。

8.3.2 用戶數(shù)據(jù)報(bào)的格式

用戶數(shù)據(jù)報(bào)UDP有兩個(gè)字段：數(shù)據(jù)字段和首都字段。首部字段很簡(jiǎn)單，只有8個(gè)字節(jié)如圖8-11所示，由4個(gè)字段組成，每個(gè)字段都是兩個(gè)字節(jié)。各字段意義如下所述。

(1)源端口字段：源端口號(hào)。

(2)目的端口字段：目的端口號(hào)。

(3)長度字段：UDP用戶數(shù)據(jù)報(bào)的長度。

(4)檢驗(yàn)和字段：防止UDP用戶數(shù)據(jù)報(bào)在傳輸中出錯(cuò)。

圖8-7 UDP用戶數(shù)據(jù)報(bào)的首部和偽首部

UDP用戶數(shù)據(jù)報(bào)首都中檢驗(yàn)和的計(jì)算方法有些特殊。在計(jì)算檢驗(yàn)利時(shí)在UDP用戶數(shù)據(jù)報(bào)之前要增加12個(gè)字節(jié)的偽首部。所謂“偽首部”是因?yàn)檫@種偽首部并不是UDP用戶數(shù)據(jù)報(bào)真正的首部。只是在計(jì)算檢驗(yàn)和時(shí)，臨時(shí)和UDP用戶數(shù)據(jù)報(bào)連接在一起，得到一個(gè)過渡的UDP用戶數(shù)據(jù)報(bào)。檢驗(yàn)和就是按照這個(gè)過渡的UDP用戶數(shù)據(jù)報(bào)來計(jì)算的，偽首部既不向下傳送，也不向上遞交。圖8-7的最上面給出了偽首部各字段的內(nèi)容。

UDP計(jì)算檢驗(yàn)和的方法和計(jì)算IP數(shù)據(jù)報(bào)首都檢驗(yàn)和的方法相似。在發(fā)送端，首先是先將全零放入檢驗(yàn)和字段。再將偽首部以及UDP用戶數(shù)據(jù)報(bào)(現(xiàn)在要包括數(shù)據(jù)字段]看成是由許多16 bit的字串接起來。若UDP用戶數(shù)據(jù)報(bào)的數(shù)據(jù)部分不是偶數(shù)個(gè)字節(jié)則要填入一個(gè)全零字節(jié)(但此字節(jié)不發(fā)送)。然后按二進(jìn)制反碼計(jì)算出這些16 bit字的和。將此和的二進(jìn)制反碼寫入檢驗(yàn)和字段后，發(fā)送此UDP用戶數(shù)據(jù)報(bào)。在接收端，將收到的UDP用戶數(shù)據(jù)報(bào)連同偽首部(以及可能的填充全零字節(jié))一起，按二進(jìn)制反碼求這些16 bit字的和。當(dāng)無差錯(cuò)時(shí)其結(jié)果應(yīng)為全1。否則就表明有差錯(cuò)出現(xiàn)，接收端就應(yīng)將此UDP用戶數(shù)據(jù)報(bào)丟棄(也可以上交給應(yīng)用層，但附上出現(xiàn)了差錯(cuò)的警告)。圖8-12給出了一個(gè)計(jì)算UDP檢驗(yàn)和的例子。這里假定用戶數(shù)據(jù)報(bào)的長度是15字節(jié)，因此要添加一個(gè)全0的字節(jié)，讀者可以自己檢驗(yàn)一下在接收端是怎樣對(duì)檢驗(yàn)和進(jìn)行檢驗(yàn)的。不難看出，這種簡(jiǎn)單的差錯(cuò)檢驗(yàn)方法的檢錯(cuò)能力并不強(qiáng)，但它的好處是簡(jiǎn)單，處理起來較快。

偽首都的第3字段是全0，第4個(gè)字段是IP首部中的協(xié)議字段的值。以前已講過，對(duì)于UDP，此協(xié)議字段值為17，第5字段是UDP用戶數(shù)據(jù)報(bào)的長度。因此我們可以看出，這樣的檢驗(yàn)和，既檢查了UDP用戶數(shù)據(jù)報(bào)的源端口號(hào)、日的端門號(hào)以及UDP用戶數(shù)據(jù)報(bào)的數(shù)據(jù)部分，又檢查了IP數(shù)據(jù)報(bào)的源IP地址和目的址址。

8.4 傳輸控制協(xié)議TCP

TCP/IP體系中面向連接的運(yùn)輸層協(xié)議，它提供全雙工的可靠交付的服務(wù)。一定要記?。篢CP與UDP最大的區(qū)別就是TCP是面向連接的，而UDP是無連接的。下面先介紹TCP的報(bào)文段首部的格式，然后再討論保證數(shù)據(jù)傳送可靠、按序、無丟失和元重復(fù)的一些機(jī)制。

傳輸?shù)目煽渴怯捎谑褂昧诵蛱?hào)和確認(rèn)。當(dāng)TCP發(fā)送一報(bào)文段時(shí)，它同時(shí)也在重傳隊(duì)列中放入一個(gè)副本。若收到確認(rèn)，則刪除此副本。若在計(jì)時(shí)器時(shí)間到之前沒有收到確隊(duì)，則重傳此報(bào)文段。TCP的確認(rèn)并不保證數(shù)據(jù)已交付給端用戶，這是接收TCP的責(zé)任。

圖8-11 TCP報(bào)文段的首部

8.4.1 TCP報(bào)文段的首部

一個(gè)TCP報(bào)文段分為首部和數(shù)據(jù)兩部分，如圖8-11所示。應(yīng)當(dāng)指出，TCP的全部功能都體現(xiàn)在它的首都的各字段。本節(jié)先大致介紹各字段的作用，然后在后續(xù)的幾節(jié)還要結(jié)合相關(guān)的字段詳細(xì)討淪TCP的主要機(jī)制。

TCP報(bào)文段首都的前20個(gè)字節(jié)是固定的，后面有4 N字節(jié)是根據(jù)需要而增加的選項(xiàng)(N必須是整數(shù))。因此TCP首部的最小長度是20字節(jié)。首部固定部分各字段的意義如下所述。

(1)源端口和目的端口

各占兩個(gè)字節(jié)，前面已經(jīng)講過，端口是運(yùn)輸層與應(yīng)用層的服務(wù)接口。16 bit的端口號(hào)加上32 bit的IP地址，構(gòu)成了插口(socket)，它相當(dāng)于運(yùn)輸層服務(wù)訪問點(diǎn)TSAP的地址(總共是48bit)。這些端口用來將若干高層協(xié)議向下復(fù)用，也用來將運(yùn)輸層協(xié)議向上分用。

(2)序號(hào)

占4字節(jié)。TCP是面向數(shù)據(jù)流的，TCP傳送的報(bào)文可看成為連續(xù)的數(shù)據(jù)流，其中每一個(gè)字節(jié)都對(duì)應(yīng)于一個(gè)序號(hào)。首部中的“序號(hào)”則指的是本報(bào)文段所發(fā)送的數(shù)據(jù)中第一個(gè)字節(jié)的序號(hào)，例如，某報(bào)文段的序號(hào)字段的值是30l，而攜帶的數(shù)據(jù)共100字節(jié)，則本報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)是301，而最后一個(gè)字節(jié)的序號(hào)是400。這樣，下一個(gè)報(bào)文段的數(shù)據(jù)序號(hào)應(yīng)當(dāng)從401開始，因而下一個(gè)報(bào)文段的序號(hào)字段的值應(yīng)為401。

(3)確認(rèn)序號(hào)

占4字節(jié)，是期望收到對(duì)方的下—個(gè)報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)，也就是期望收到的下—個(gè)報(bào)文段首部的字號(hào)字段的值。例如，正確收到了一個(gè)報(bào)文段，其序號(hào)字段的值是501，而數(shù)據(jù)長度是200字節(jié)，這就表明序號(hào)在501～700之間的數(shù)據(jù)均已正確收到。因此在響應(yīng)的報(bào)文段中應(yīng)將確認(rèn)序號(hào)置為701。請(qǐng)注意：確認(rèn)序號(hào)既不是501也不是700。

由于序號(hào)字段有32 bit長，可對(duì)4 GB(即4千兆字節(jié))的數(shù)據(jù)進(jìn)行編號(hào)，這樣就可保證當(dāng)序號(hào)重復(fù)使用時(shí)，舊序號(hào)的數(shù)據(jù)早已在網(wǎng)絡(luò)中消失了。

(4)數(shù)據(jù)偏移

占4bit，它指出數(shù)據(jù)開始的地方離TCP報(bào)文段的起始處有多遠(yuǎn)。這實(shí)際上就是TCP報(bào)文段首都的長度。由于首部長度不固定(因首部中還有長度不確定的選項(xiàng)字段)，因此致?lián)谱侄问潜匾摹５珣?yīng)注息，“數(shù)據(jù)偏移”的單位不是字節(jié)，而是32 bit字(即4字節(jié)字)。由于4 bit能表示的最大十進(jìn)制數(shù)是15,因此數(shù)據(jù)偏移的最大值是60字節(jié)，這也是TCP首部的最大長度。

(5)保留

占6 bit，保留為今后使用，但目前應(yīng)置為0。

下面有6個(gè)比特是說明本報(bào)文段性質(zhì)的控制比特，它們的意義如下。

(6)緊急比特URG(URGent)

當(dāng)URG＝1時(shí)，表明緊急指針字段有效。它告訴系統(tǒng)此報(bào)文段中有緊急數(shù)據(jù)，應(yīng)盡快傳送(相當(dāng)于高優(yōu)先級(jí)的數(shù)據(jù))，而不要按原來的排隊(duì)順序來傳送。例如，已經(jīng)發(fā)送了很長的一個(gè)程序要在遠(yuǎn)地的主機(jī)上運(yùn)行。但后來發(fā)現(xiàn)了一些問題，需要取消該程序的運(yùn)行。因此用戶從鍵盤發(fā)出中斷命令(Control＋C)。如果不使用緊急數(shù)據(jù)，那么這兩個(gè)字符將存儲(chǔ)在接收TCP緩存的末尾。只有在所有的數(shù)據(jù)被處理完畢后這兩個(gè)字符才被交付到接收應(yīng)用進(jìn)程。這樣做就浪費(fèi)了許多時(shí)間。

當(dāng)使用緊急比特并將URG置1時(shí)，發(fā)送應(yīng)用進(jìn)程就告訴發(fā)送TCP這兩個(gè)字符是緊急數(shù)據(jù)。于是發(fā)送TCP就將這兩個(gè)字符插入到報(bào)文段的數(shù)據(jù)的最前面，其余的數(shù)據(jù)都是普通數(shù)據(jù)。這時(shí)要與首部中第五個(gè)32 bit字中的一半“緊急指針”(Urgent Pointer)字段配合使用。緊急指針指出在本報(bào)文段中的緊急數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)。緊急指針使接收方知道緊急數(shù)據(jù)共有多少個(gè)字節(jié)。緊急數(shù)據(jù)到達(dá)接收端后，當(dāng)所有緊急數(shù)據(jù)都被處理完時(shí)，TCP就告訴應(yīng)用程序恢復(fù)到正常操作。值得注意的是，即使窗口為零時(shí)也可發(fā)送緊急數(shù)據(jù)。

(7)確認(rèn)比特ACK

只有當(dāng)ACK＝1時(shí)確認(rèn)序號(hào)字段才有效。當(dāng)ACK＝0時(shí)，確認(rèn)序號(hào)無效。

(8)推送比特PSH(PuSH)

當(dāng)兩個(gè)應(yīng)用進(jìn)程進(jìn)行文互式的通信時(shí)，有時(shí)在一端的應(yīng)用進(jìn)程希望在鍵入一個(gè)命令后立即就能夠收到對(duì)方的響應(yīng)。在這種情況下，TCP就可以使用推送(push)操作。這時(shí)，發(fā)送端TCP將推送比特PSH置1，并立即創(chuàng)建一個(gè)報(bào)文段發(fā)送出上。接收TCP收到推送比特置1的報(bào)文段，就盡快(即“推送”向前)交付給接收應(yīng)用進(jìn)程，而不再等到整個(gè)緩存都填滿了后再向上交付。PSH比特也可叫做急迫比特。

雖然應(yīng)用程序可以選擇推推送操作，但抵達(dá)操作還是往往不被人們使用。TCP可以選擇或不選擇這個(gè)操作。

(9)復(fù)位比特RST(ReSeT)

當(dāng)RST＝1時(shí)，表明TCP連接中出現(xiàn)嚴(yán)重差錯(cuò)(如由于主機(jī)崩潰或其他原因)，必須釋放連接，然后再重新建立運(yùn)輸連接。復(fù)位比特還用來拒絕一個(gè)非法的報(bào)文段或拒絕打開一個(gè)連接。復(fù)位比特也可稱為重建比特或重置比特。

(10)同步比特SYN

在連接建立時(shí)用來同步序號(hào)。當(dāng)SYN＝1而ACK＝0時(shí),表明這是一個(gè)連接請(qǐng)求報(bào)文段。對(duì)方若同意建立連接，則應(yīng)在響應(yīng)的報(bào)文段中使SYN＝1和ACK＝1。因此，同步比特SYN置為1，就表示這是一個(gè)連接請(qǐng)求或連接接受報(bào)文。關(guān)于連接的建立和釋放，后面還要進(jìn)行討論。

(11)終止比特FIN(FINal)

用來釋放一個(gè)迎接，當(dāng)FIN＝1時(shí)，表明此報(bào)文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運(yùn)輸連接。

(12)窗口

占2字節(jié)。窗口字段用來控制對(duì)方發(fā)送的數(shù)據(jù)量，單位為字節(jié)。大家知道，計(jì)算機(jī)網(wǎng)絡(luò)經(jīng)常是用接收端的接收能力的大小來控制發(fā)送端的數(shù)據(jù)發(fā)送量。TCP也是這樣。TCP連接的一端根據(jù)自己緩存的空間大小確定自己的接收窗口大小，然后通知對(duì)方來確定對(duì)方的發(fā)送窗口。假定TCP連接的兩端是A和B。若A確定自己的接收窗口為WIN，則將窗口WIN的數(shù)值寫在A發(fā)送給B的TCP報(bào)文段的窗口字段中，這就是告訴B的TCP，“你(B)在未收到我(A)的確認(rèn)時(shí)所能夠發(fā)送的數(shù)據(jù)量就是從本首部中的確認(rèn)序號(hào)開始的WIN個(gè)字節(jié)。”所以A所確定的WINA是A的接收窗口，同時(shí)也就是B的發(fā)送窗口。例如，A發(fā)送的報(bào)文段首部中的窗口WIN＝500，確認(rèn)序號(hào)為201，則表明B可以在未收到確認(rèn)的情況下，向A發(fā)送序號(hào)從201～700的數(shù)據(jù)。B在收到此報(bào)文段后，就以這個(gè)窗口數(shù)值WIN作為B的發(fā)送窗口。但應(yīng)注意，B所發(fā)送的報(bào)文段中的窗口字段則是根據(jù)B的接收能力來確定A的發(fā)送窗口，不要弄混。

(13)檢驗(yàn)和

占2字節(jié)。檢驗(yàn)和字段檢驗(yàn)的范圍包括首部和數(shù)據(jù)這兩部分。和UDP用戶數(shù)據(jù)報(bào)一樣，在計(jì)算檢驗(yàn)和時(shí)，要在TCP報(bào)文段的前面加上12字節(jié)的偽首都。偽首部的格式與圖8-10中UDP用戶數(shù)據(jù)報(bào)的偽首部一樣。但應(yīng)將偽首部第四個(gè)字段中的17放為6(TCP的協(xié)議號(hào)是6)，將第五字段中的UDP長度改為TCP長度。接收端收到此報(bào)文段后，仍要加上這個(gè)偽首都來計(jì)算檢驗(yàn)和。若使用IPV6，則相應(yīng)的偽首部也要改變。

(14)選項(xiàng)

長度可變。TCP只規(guī)定了一種選項(xiàng)，即最大報(bào)文段長度MSS(Maximum Segment Size)。MSS告訴對(duì)方TCP：“我的緩存所能接收的報(bào)文段的數(shù)據(jù)字段的最大長度是MSS。”與沒有選項(xiàng)時(shí)，TCP的首部長度是20字節(jié)。

MSS的選擇并不簡(jiǎn)單。若選擇較小的MSS長度，網(wǎng)絡(luò)的利用率就降低。設(shè)想在極端的情況下，當(dāng)TCP報(bào)文段只含有1字節(jié)的數(shù)據(jù)時(shí)，在IP層傳輸?shù)臄?shù)據(jù)報(bào)的開銷至少有40字節(jié)(包括TCP報(bào)文段的首部和IP數(shù)據(jù)報(bào)的首都)。這樣，對(duì)網(wǎng)絡(luò)的利用率就不會(huì)超過1/41，到了數(shù)據(jù)鏈路層還要加上一些開銷。但反過來，若TCP報(bào)文段非常長，那么在IP層傳輸時(shí)就有可能要分解成多個(gè)短數(shù)據(jù)報(bào)片。在目的站要將收到的各個(gè)短數(shù)據(jù)報(bào)片裝配成原來的TCP報(bào)文段。當(dāng)傳輸出錯(cuò)時(shí)還要進(jìn)行重傳。這些也都會(huì)使開銷增大。一般認(rèn)為，MSS應(yīng)盡可能大些，只要在IP層傳輸時(shí)不需要再分片就行。在連接建立的過程中，雙方都將自己能夠支持的MSS寫入這一字段。在以后的數(shù)據(jù)傳送階段，MSS取雙方提出的較小的那個(gè)數(shù)值：若主機(jī)未填寫這項(xiàng)，則MSS的默認(rèn)值是536字節(jié)長。因此，所有要因特網(wǎng)上的主機(jī)都能接受的報(bào)文段長度是536+20＝556字節(jié)。

8.4.2 TCP的數(shù)據(jù)編號(hào)與確認(rèn)

TCP協(xié)議是面向字節(jié)的。TCP將所要傳送的整個(gè)報(bào)文(這可能包括許多個(gè)報(bào)文段)看成是一個(gè)個(gè)字節(jié)組成的數(shù)據(jù)流，并使每一個(gè)字節(jié)對(duì)應(yīng)于一個(gè)序號(hào)。在連接建立時(shí)，雙方要商定初始序號(hào)。TCP誨隊(duì)所發(fā)送的報(bào)文段的首部中的序號(hào)字段數(shù)值表示該報(bào)文段中的數(shù)據(jù)部分的第一個(gè)字節(jié)的序號(hào)。

TCP的確認(rèn)是對(duì)接收到的數(shù)據(jù)的最高序號(hào)(即收到的數(shù)據(jù)流中的最后一個(gè)序號(hào))表示確認(rèn)。但接收端返回的確認(rèn)序號(hào)是已收到的數(shù)據(jù)的最高序號(hào)加1。也就是說，確認(rèn)序號(hào)表示接收端期望下次收到的數(shù)據(jù)中的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)。

由于TCP連接能提供全雙工通信，因此通信中的每一方都不必專門發(fā)送確認(rèn)報(bào)文段，而可以在傳送數(shù)據(jù)時(shí)順便把確認(rèn)信息捎帶傳送，這樣做可以提高傳輸效率。

在發(fā)送端，TCP是怎樣決定發(fā)送個(gè)報(bào)文段的時(shí)機(jī)呢

TCP有三種基本機(jī)制來控制報(bào)文段的發(fā)送。第一種機(jī)制是TCP維持一個(gè)變量，它等于最大報(bào)文段長度MSS，只要發(fā)送緩存從發(fā)送進(jìn)程得到的數(shù)據(jù)達(dá)到MSS字節(jié)時(shí)，就組裝成—個(gè)TCP報(bào)文段，然后發(fā)送出去。第二種機(jī)制是發(fā)送端的應(yīng)用進(jìn)程指明要求發(fā)送報(bào)文段，即TCP支持的推送(push)操作。第三種機(jī)制是發(fā)送端的一個(gè)計(jì)時(shí)器時(shí)間到了，這時(shí)就把當(dāng)前已有的緩存數(shù)據(jù)裝入報(bào)文段發(fā)送出去。

但是，如何控制TCP發(fā)送報(bào)文段的時(shí)機(jī)仍然是一個(gè)較為復(fù)雜的問題。

例如，一個(gè)交互式用戶使用一條TELNET連接(運(yùn)輸層為TCP協(xié)議)。設(shè)用戶只發(fā)—個(gè)字符。加上20字節(jié)的首部后，得到21字節(jié)長的TCP報(bào)文段。再加上20字節(jié)的IP首都，形成41字節(jié)長的IP數(shù)據(jù)報(bào)。在接收端TCP立即發(fā)出確認(rèn)，構(gòu)成的數(shù)據(jù)報(bào)是40字節(jié)長(假定沒有救據(jù)發(fā)送)。若用戶要求遠(yuǎn)地主機(jī)回送這一字符，則又要發(fā)回41字節(jié)長的IP數(shù)據(jù)報(bào)和40字節(jié)長的確認(rèn)IP數(shù)據(jù)報(bào)。這樣，用戶僅發(fā)一字符時(shí)線路是就需傳送總長度為162字節(jié)共4個(gè)報(bào)文段。當(dāng)線路帶寬并不富裕時(shí)，這種傳送方法的效率的確不高。因此應(yīng)適當(dāng)推遲發(fā)回確認(rèn)報(bào)文，并盡量使用捎帶確認(rèn)的方法。

在TCP的實(shí)現(xiàn)中廣泛使用Nagle算法［NAGL84]：算法是：若發(fā)送端應(yīng)用進(jìn)程將欲發(fā)送的數(shù)據(jù)逐個(gè)字節(jié)地達(dá)到發(fā)送端的TCP緩存，則發(fā)送端就將第一個(gè)字符(—個(gè)字符的長度是一個(gè)字節(jié))發(fā)送出去，將后面到達(dá)的字符將都緩存起來。當(dāng)接收端收到對(duì)第一個(gè)字符的確認(rèn)后，再將緩存中的所有字符裝成一個(gè)報(bào)文段發(fā)送出去，同時(shí)繼續(xù)對(duì)隨后到達(dá)的字符進(jìn)行緩存。只有在收到對(duì)前一個(gè)報(bào)文段的確認(rèn)時(shí)才繼續(xù)發(fā)送下一個(gè)報(bào)文段。當(dāng)字符到達(dá)較快而網(wǎng)絡(luò)速率較慢時(shí)，用這樣的方法可明顯的減少所用的網(wǎng)絡(luò)帶寬，算法還規(guī)定，當(dāng)?shù)竭_(dá)的字符已達(dá)到窗口大小的一半或己達(dá)到報(bào)文段的最大長度時(shí)，就立即發(fā)送一個(gè)報(bào)文段。

但有時(shí)不宜采用Nagle算法。例如在因特網(wǎng)上使用X Windows，并將鼠標(biāo)移動(dòng)的信息傳到遠(yuǎn)地主機(jī)。若采用Nagle算法會(huì)使用戶感到無法忍受。這時(shí)最好關(guān)閉這個(gè)算法。

另一個(gè)問題叫做糊涂窗口綜合癥(silly window syndrome)［RFC 813］，有時(shí)也會(huì)使TCP的性能變壞。設(shè)想這種情況：接收端的緩存已滿，而交互的應(yīng)用進(jìn)程一次只從緩存中讀取一個(gè)字符(這樣就在緩存產(chǎn)生1個(gè)字節(jié)的空位，然后向發(fā)送端發(fā)送確認(rèn)，并將窗口設(shè)置為1個(gè)字節(jié)(但發(fā)送的數(shù)據(jù)報(bào)是40字節(jié)長)。接著，發(fā)送端又傳來1個(gè)字符(但發(fā)來的IP數(shù)據(jù)報(bào)是41字節(jié)長。接收端發(fā)回確認(rèn)，仍然將窗口設(shè)置為一個(gè)字節(jié)。這樣進(jìn)行下去，網(wǎng)絡(luò)的效率將會(huì)很低。

要解決這個(gè)問題，可讓接收端等待一段時(shí)間，使得或者緩存已能有足夠的空間容納—個(gè)最長的報(bào)文段，或者緩存已有一半的中間處于空的狀態(tài)。只要出現(xiàn)這兩種情況之一，就發(fā)出確認(rèn)報(bào)文，并向發(fā)送端通知當(dāng)前的窗口大小。此外，發(fā)送端也不要發(fā)送太小的報(bào)文段，而是將數(shù)掘積累成足夠大的報(bào)文段，或達(dá)到接收端緩存的空間的—半大小。

上述兩種方法可配合使用。使得在發(fā)送端不發(fā)送很小的報(bào)文段的同時(shí)，接收端也不要在緩存剛剛有了一點(diǎn)小的空位置就急忙將一個(gè)很小的窗口大小通知給發(fā)送端。

若發(fā)送方在規(guī)定的設(shè)置時(shí)間內(nèi)沒有收到確認(rèn)，就要將未被確認(rèn)的報(bào)文段重新發(fā)送。接收方若收到有差錯(cuò)的報(bào)文段，則丟棄此報(bào)文段(不發(fā)達(dá)否認(rèn)信息)。若收到重復(fù)的報(bào)文段，也要將其丟棄，但要發(fā)回(或捎帶發(fā)回)確認(rèn)信息。這與數(shù)據(jù)鏈路層的情況相似。

若收到的報(bào)文段無差錯(cuò)，只是未按序號(hào)，那么該如何處理？TCP對(duì)此未作明確規(guī)定，而是讓TCP的實(shí)現(xiàn)者自行確定?；蛘邔⒉话葱虻膱?bào)文段丟棄，或者先將其暫存于接收緩存內(nèi)，待所缺序號(hào)的報(bào)文段收齊后再一起上交應(yīng)用層。如有可能，采用后—種策略對(duì)網(wǎng)絡(luò)的性能會(huì)更好些。例如，發(fā)送端每個(gè)報(bào)文中含有100字節(jié)的數(shù)據(jù)，且一連發(fā)送了8個(gè)報(bào)文段，其序號(hào)分別為1，l01，201,…，701。設(shè)接收端正確收到了其中的7個(gè)，而未收到序號(hào)為201的報(bào)文段。接收端可以將序號(hào)為30l～701的5個(gè)報(bào)文段先進(jìn)行暫存，而發(fā)回確認(rèn)序號(hào)為201的報(bào)文段(即序號(hào)為200及這以前的都已正確收到了)。當(dāng)發(fā)送端重傳的序號(hào)為201的報(bào)文段正確到達(dá)接收端后，接收端就發(fā)回確認(rèn)序號(hào)為801的確認(rèn)，因而提高了傳輸效率。

8.4.3 TCP的流量控制與擁塞控制

為了提高報(bào)文段的傳輸效率，TCP采用大小可變的滑動(dòng)窗口進(jìn)行流量控制。窗口大小的單位是字節(jié)。在TCP報(bào)文段首部的窗口字段寫入的數(shù)值就是當(dāng)前給對(duì)方設(shè)置的窗口數(shù)值。發(fā)送窗口在連接建立時(shí)由雙方商定。但在通信的過程中，接收端可根據(jù)自己的資源情況，隨時(shí)動(dòng)態(tài)地調(diào)整對(duì)方為發(fā)送窗口(可增大或減小)。這種由接收端控制發(fā)送端的做法，在計(jì)算機(jī)網(wǎng)絡(luò)中經(jīng)常使用。圖8-12表示的是在TCP中使用的窗口概念。在TCP中接收端的接收窗口總是等于發(fā)送端的發(fā)送窗口(因?yàn)楹笳呤怯汕罢叽_定的)，因此—般就只使用發(fā)送窗口這個(gè)詞匯。這一點(diǎn)和數(shù)據(jù)鏈路居HDLC中的滑動(dòng)窗口很不一樣。在不使用選擇重傳ARQ時(shí)，通接收雙方的接收窗口都 是1,而發(fā)送窗口是由幀編號(hào)的位數(shù)確定的。

圖7-12 TCP中的窗口概念

圖8-13 利用可變窗口進(jìn)行流量控制舉例

圖8-12(a)表示發(fā)送端要發(fā)送900字節(jié)長的數(shù)據(jù)，劃分為9個(gè)100個(gè)節(jié)長的報(bào)文段，對(duì)方確定的發(fā)送窗口為500字節(jié)。發(fā)送端只要收到了對(duì)方的確認(rèn)，發(fā)送窗口就可前移。發(fā)送端的TCP要維護(hù)一個(gè)指針。每發(fā)送一個(gè)報(bào)文段，指針就向前移動(dòng)—個(gè)報(bào)文段的距離。當(dāng)指針移動(dòng)到發(fā)送窗口的最右端(即窗口前沿)時(shí)就不能再發(fā)送報(bào)文段了。

圖8-12(b)表示發(fā)送端已發(fā)送了400字節(jié)的數(shù)據(jù)，但只收到對(duì)前200字節(jié)數(shù)據(jù)的確認(rèn)，同時(shí)窗口大小不變，我們注意到，現(xiàn)在發(fā)送端還可發(fā)送300字節(jié)。

圖8-12(C)表示發(fā)送端收到了對(duì)方對(duì)前400字節(jié)數(shù)據(jù)的確認(rèn)，但窗口減小到400字節(jié)，于是，發(fā)送端還可發(fā)送400字節(jié)的數(shù)據(jù)。

下面通過圖8-13的例子說明利用可變窗口大小進(jìn)行流量控制。

設(shè)主機(jī)A 向主機(jī)B發(fā)送數(shù)據(jù)。雙方確定的窗口值是400。再設(shè)每一個(gè)報(bào)文段為100字節(jié)長，序號(hào)的初始值為1(見8-16圖中第一個(gè)箭頭上的SEQ＝1)。圖8-16中右邊的注釋可幫助理解整個(gè)的過程。我們應(yīng)注意到，主機(jī)B進(jìn)行了3次流量控制。第一次將窗口減小為300字節(jié)，第二次又減為200字節(jié)，最后減至0，即不允許對(duì)方再發(fā)送數(shù)據(jù)了。這種暫停狀態(tài)將持續(xù)到主機(jī)B重新發(fā)出一個(gè)新的窗口值為止。

實(shí)現(xiàn)流量控制并非僅僅為了使接收端來得及接收。如果發(fā)送端發(fā)出的報(bào)文過多會(huì)使網(wǎng)絡(luò)負(fù)荷過重。由此會(huì)引起報(bào)文段的時(shí)延增大。但報(bào)文段時(shí)廷的增大，將使主機(jī)不能及時(shí)地收到確認(rèn)。因此會(huì)重傳更多的報(bào)文段，而這又會(huì)進(jìn)一步加劇網(wǎng)絡(luò)的擁塞。為了避免發(fā)生擁塞，主機(jī)應(yīng)當(dāng)降低發(fā)送速率。

可見發(fā)送端的主機(jī)在發(fā)送數(shù)據(jù)時(shí)，既要考慮到接收端的接收能力，又要使網(wǎng)絡(luò)不要發(fā)生擁塞。因而發(fā)送端的發(fā)送窗口應(yīng)接以下方式確定：

發(fā)送窗口＝Min[通知窗口，擁塞窗口] (8-1)

這里

通知窗口(advertised window)是接收端根據(jù)其接收能力許諾的窗口值，是來自接收端的流量控制。接收端將通知窗口的值放在TCP報(bào)文的首部中，傳送給發(fā)送端。

擁塞窗口(congestion window)是發(fā)送端根據(jù)網(wǎng)絡(luò)擁塞情況得出的窗口值，是來自發(fā)送端的流量控制。

(8-1)式表明，發(fā)送端的發(fā)送窗口取“通知窗口”和“擁塞窗口”中的較小的一個(gè)。在未發(fā)生擁塞的穩(wěn)定工作狀態(tài)下，接收端通知的窗口和擁塞窗口是一致的。

為了更好地進(jìn)行擁塞控制，因特網(wǎng)標(biāo)準(zhǔn)推薦使用以下三種技術(shù)，即慢啟動(dòng)(slow-start)、加速遞減(multiplicative decrease)和擁塞避免(congestion avoidance)。使用這些技術(shù)的前提是：由于通信線路帶來的誤碼而使得分組丟失的概率很小(遠(yuǎn)小于1％)。因此只要出現(xiàn)分組丟失或遲延過長而引起超時(shí)重傳，就意味著在網(wǎng)絡(luò)的某處出現(xiàn)了擁塞。實(shí)現(xiàn)步驟如下所述。

(1)當(dāng)一個(gè)連接初始化時(shí)，將擁塞窗口置為1(即窗口允許發(fā)送1個(gè)報(bào)文段)、并設(shè)置慢啟動(dòng)的門限窗口值。

(2)發(fā)送端的發(fā)送窗口不能超過擁塞窗口和通知窗口的最小值?，F(xiàn)在假定接收端不進(jìn)行流量控制。

(3)發(fā)送端若收到了對(duì)所有發(fā)出的報(bào)文段的確認(rèn)，就在下一次發(fā)送時(shí)將擁塞窗口加倍，可見擁塞窗口從1開始，把指數(shù)規(guī)律增長。若出現(xiàn)了超時(shí)，則將當(dāng)時(shí)的擁塞窗口減半，作為新的門限窗口值，同時(shí)擁塞窗口再次變?yōu)?。

(4)擁塞窗口重新從1開始按指數(shù)規(guī)律增長。但當(dāng)增長到新的門限窗口值時(shí)，就每次只將擁塞窗口加1，使擁塞窗口按線性規(guī)律增長。當(dāng)網(wǎng)絡(luò)又出現(xiàn)超時(shí)，仍重復(fù)上述過程。

(5)從以上討論可看出，“慢啟動(dòng)”是指每出現(xiàn)一次超時(shí)，擁塞窗口都降低到1，使報(bào)文段慢慢注入到網(wǎng)絡(luò)中。不過這個(gè)名詞不太準(zhǔn)確，因?yàn)閾砣翱谠鲩L的比率并不很慢。“加速遞減”是指每出現(xiàn)一次超時(shí)，就將門限窗口值減半。若超時(shí)頻繁出現(xiàn)，則門限窗口減小的速率是很快的。“擁塞避免”是指當(dāng)擁塞窗口增大到門限窗口值時(shí)，就將擁塞窗口指數(shù)增長速率降低為線性增長速率，避免網(wǎng)絡(luò)再次出現(xiàn)擁塞。

8.4.4 TCP的重傳機(jī)制

重傳機(jī)制是TCP中最重要和最復(fù)雜的問題之一。TCP每發(fā)送一個(gè)報(bào)文段，就設(shè)置一次計(jì)時(shí)器。只要計(jì)時(shí)器設(shè)置的重傳時(shí)間已經(jīng)到了但還沒有收到確認(rèn)，就要重傳這一報(bào)文段。

出于TCP的下層是一個(gè)互連網(wǎng)環(huán)境，發(fā)送的報(bào)文段可能只經(jīng)過一個(gè)高速率的局域網(wǎng)，但也可能是經(jīng)過多個(gè)低速率的局域網(wǎng)，并且數(shù)據(jù)報(bào)所選擇的路由還可能會(huì)發(fā)生變化。圖8-17畫出了數(shù)據(jù)鏈路層和運(yùn)輸層的往返時(shí)延概率分布的對(duì)比。往返時(shí)延就是從數(shù)據(jù)發(fā)出到收到對(duì)方的確認(rèn)所經(jīng)歷的時(shí)間。對(duì)于數(shù)據(jù)鏈路層，其往返時(shí)延的方差很小，因此將超時(shí)時(shí)間設(shè)置為如8-17圖中的T₁即可。但對(duì)于運(yùn)輸層來說，其往返時(shí)延的方差很大。若將超時(shí)時(shí)間設(shè)計(jì)為圖8-17中的T₂，則很多報(bào)文段的重傳時(shí)間太早，因而給網(wǎng)絡(luò)增加了許多不應(yīng)有的負(fù)荷。但若將超時(shí)時(shí)間選為圖中的T₃，則顯然全使網(wǎng)絡(luò)的傳輸效率降低很多。

那么，運(yùn)輸層的超時(shí)器的重傳時(shí)間究竟應(yīng)設(shè)置為多大呢

TCP采用了一種自適應(yīng)算法。這種算法記錄每一個(gè)報(bào)文段發(fā)出的時(shí)間、以及收到相應(yīng)的確認(rèn)報(bào)文段的時(shí)間。這兩個(gè)時(shí)間之差就是報(bào)文段的往返時(shí)延。將各個(gè)報(bào)文段的往返時(shí)延樣本加權(quán)平均，就得出報(bào)文段的平均往返時(shí)延T，每測(cè)量到一個(gè)新的往返時(shí)間樣本，就接下式重新計(jì)算一次平均往返時(shí)延：

平均往返時(shí)延T＝a(舊的往返時(shí)延T))＋(1-a)(新的往返時(shí)延樣本) (8-2)

在上式中，0<a<1。若a很接近于1,表示新算出的往返時(shí)延T和原來的值相比變化不大，而新的往返時(shí)延樣本的影響不大(T值更新較慢)。若選擇a接近于0,則表示加權(quán)計(jì)算的往返時(shí)延T受新的往返時(shí)延樣本的影響較大(T值的更新較快)。典型的a值為7/8。

顯然，計(jì)時(shí)器設(shè)置的重傳時(shí)間應(yīng)略大于上面得出的平均往返時(shí)延，即

重傳時(shí)間＝B(平均往返時(shí)延) (8-3)

這里B是個(gè)大于1的系數(shù)，實(shí)際上，系數(shù)B是很難確定的，若取B很接近于1，發(fā)送端可以很及時(shí)地重傳丟失的報(bào)文段，因此效率得到提高。但若報(bào)文段并未丟失而僅僅是增加了一點(diǎn)時(shí)延，那么過早地重傳未收到確認(rèn)的報(bào)文段，反而會(huì)加重網(wǎng)絡(luò)的負(fù)擔(dān)。因此TCP原先的標(biāo)準(zhǔn)推薦將B值取為2。但現(xiàn)在已有了更好的辦法。

上面所說的往返時(shí)間的測(cè)量，實(shí)現(xiàn)起來相當(dāng)復(fù)雜，試看下面的例子。

如圖8-17所示，發(fā)送出一個(gè)TCP報(bào)文段1、設(shè)定的重傳到了，但還沒有收到確認(rèn)。于是重傳此報(bào)文段，即圖中的報(bào)文段2，后來收到了確認(rèn)報(bào)文段ACK?，F(xiàn)在的問題是：如何判出此確認(rèn)報(bào)文段是對(duì)原來的報(bào)文段1的確認(rèn)，還是對(duì)重傳的報(bào)文段2的確認(rèn)？由于重傳的報(bào)文段2和原來的報(bào)文段1完全一樣，因此源站在收到確認(rèn)后，就無法做出正確的判斷了。

圖8-17 收到的確認(rèn)報(bào)文段ACK是對(duì)哪一個(gè)報(bào)文段的確認(rèn)

若收到的確認(rèn)是對(duì)重傳報(bào)文段2的確認(rèn)，但被源站當(dāng)成是對(duì)原來的報(bào)文段1的確認(rèn)，那么這樣計(jì)算出的往返時(shí)延樣本和重傳時(shí)間就會(huì)偏大。如果后面再發(fā)送的報(bào)文段又是經(jīng)過重傳后才收到確認(rèn)報(bào)文段，那么按此方法得出的重傳時(shí)間就越來越長。

同樣，若收到的確認(rèn)是對(duì)原來的報(bào)文段1的確認(rèn)，但被當(dāng)成是對(duì)重傳報(bào)文段2的確認(rèn)，則由此計(jì)算出的往返時(shí)廷樣本和重傳時(shí)間都會(huì)偏小。這就必然更加頻繁地導(dǎo)致報(bào)文段的重傳這樣就有可能使重傳時(shí)間越來越短。

根據(jù)以上所述，Karn提出了一個(gè)算法：在計(jì)算平均往返時(shí)延時(shí)，只要報(bào)文段重傳了，就不采用其往返時(shí)延樣本。這樣得出的平均往返時(shí)延和重傳時(shí)間當(dāng)然就較準(zhǔn)確。

但是，這又引起新的問題。設(shè)想出現(xiàn)這樣的情況：報(bào)文段的時(shí)延突然增大了很多。因此在原來得出的重傳時(shí)間內(nèi)，不會(huì)收到確認(rèn)報(bào)文段，于是就重傳報(bào)文段。但根據(jù)Karn算法，不考慮重傳的報(bào)文段的往返時(shí)延樣本。這樣，重傳時(shí)間就無法更新。

因此，對(duì)Karn算法進(jìn)行修正的方法是：報(bào)文段重傳一次，就將重傳時(shí)間增大一些，

新的重傳時(shí)間＝Y(jié)(舊的重傳時(shí)間) (8-4)

系數(shù)Y的典型值是2，當(dāng)不再發(fā)生報(bào)文段的重傳時(shí)，才根據(jù)報(bào)文段的往返時(shí)延更新平均往返時(shí)延和重傳時(shí)間的數(shù)值。實(shí)踐證明，這種策略較為合理。

8.4.5 TCP的運(yùn)輸連接管理

TCP是面向連接的協(xié)議。運(yùn)輸連接的建立和釋放是每一次面向連接的通信中必不可少的過程。運(yùn)輸連接的管理就是使運(yùn)輸連接的建立和釋放都能正常地進(jìn)行。

在連接建立過程中要解決以下三個(gè)問題。

(1)要使每一方能夠確知對(duì)方的存在。

(2)要允許雙方協(xié)商一些參數(shù)(如最大報(bào)文段長度，最大窗口大小，服務(wù)質(zhì)量等)。

(3)能夠運(yùn)輸實(shí)體資源(如緩存大小，連接表中的項(xiàng)目等)進(jìn)行分配。

TCP的連接和建立都是采用客戶服務(wù)端方式。主動(dòng)發(fā)起連接建立的進(jìn)程叫做客戶(client)。而被動(dòng)等待正接建立的進(jìn)程叫服務(wù)器(server)。

圖8-18用三次握手建立 TCP 連接

設(shè)主機(jī)B中運(yùn)行一個(gè)服務(wù)器過程，如圖8-18所示，它先發(fā)出一個(gè)被動(dòng)打開(passive open)命令，告訴它的TCP要準(zhǔn)備接受客戶進(jìn)程的連接請(qǐng)求。然后服務(wù)器進(jìn)程就處于“聽”(listen)的狀態(tài)，不斷檢測(cè)是否有客戶進(jìn)程要發(fā)起連接請(qǐng)求，如有，即做出響應(yīng)。

設(shè)客戶進(jìn)程運(yùn)行在主機(jī)A中。它先向其TCP發(fā)出主動(dòng)打開(active open)命令，表明要向某個(gè)IP地址的某個(gè)端口建立運(yùn)輸連接。

主機(jī)A的TCP向主機(jī)B的TCP發(fā)出連接請(qǐng)求報(bào)文段，其首部的同步比特SYN應(yīng)置為1，同時(shí)選樣—個(gè)序號(hào)x．表明在后面?zhèn)魉蛿?shù)據(jù)時(shí)的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)是x。在圖8-19中，一個(gè)從A到B的箭頭上標(biāo)有“SYN，SEQ＝x”就是這個(gè)意思。

主機(jī)B的TCP收到連接請(qǐng)求報(bào)文段后，如同意，則發(fā)回確認(rèn)。在確認(rèn)報(bào)文段中應(yīng)將SYN

置為1，確認(rèn)序號(hào)應(yīng)為x+1，同時(shí)也為自己選擇一個(gè)序號(hào)y。

主機(jī)A的TCP收到此報(bào)文段后，還要向B給出確認(rèn)，其確認(rèn)序號(hào)為y+1。

運(yùn)行客戶進(jìn)程的主機(jī)A的TCP通知上層應(yīng)用進(jìn)程，連接已經(jīng)建立(或打開)。

當(dāng)運(yùn)行服務(wù)器進(jìn)程的主機(jī)B的TCP收到主機(jī)A的確認(rèn)后，也通知其上層應(yīng)用進(jìn)程，連接已經(jīng)建立。

連接建立采用的這種過程叫做三次握手(there-way handshake)，或三次聯(lián)絡(luò)。

為什么要發(fā)送這第三個(gè)報(bào)文段呢 這主要是為了防止己失效連接請(qǐng)求報(bào)文段突然又傳送到了主機(jī)B，因而產(chǎn)生錯(cuò)誤。

所謂“已失效的連接請(qǐng)求報(bào)文段”是這樣產(chǎn)生的?？紤]這樣一種情況。主機(jī)A發(fā)出連接請(qǐng)求，但因連接請(qǐng)求報(bào)文丟失而未收到確認(rèn)。主機(jī)A于是再重傳—次。后來收到了確認(rèn)，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接。主機(jī)A共發(fā)送了兩個(gè)連接請(qǐng)求報(bào)文段，其中的第二個(gè)到達(dá)了主機(jī) B 。

圖8-19 TCP 連接釋放的過程

現(xiàn)假定出現(xiàn)另一種情況，即主機(jī) A發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失，而是在某些網(wǎng)絡(luò)結(jié)點(diǎn)滯留的時(shí)間太長，以致延誤到在這次的連接釋放以后才傳送到主機(jī)B。本來這是一個(gè)已經(jīng)失效的報(bào)文段。但主機(jī)B收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是主機(jī)A又發(fā)出—次新的連接請(qǐng)求，于是就向主機(jī)A發(fā)出確認(rèn)報(bào)文段，同意建立連接。

主機(jī)A由于并沒有要求建立連接，因此不會(huì)理睬主機(jī)B的確認(rèn)，也不會(huì)向主機(jī)B發(fā)送數(shù)據(jù)，但主機(jī)B卻以為運(yùn)輸連接就這樣建立了，并一直等待主機(jī)A發(fā)來數(shù)據(jù)。主機(jī)B的許多資源就這樣白白浪費(fèi)了。

采用三次握手的辦法可以防止上述現(xiàn)象的發(fā)生。例如在剛才的情況下，主機(jī)A不會(huì)向主機(jī)B的確認(rèn)發(fā)出確認(rèn)。主機(jī)B收不到確認(rèn)，連接就建立不起來。

在數(shù)據(jù)傳輸結(jié)束后，通信的雙方都可以發(fā)出釋放連接的請(qǐng)求。

設(shè)圖8-19 中的豐機(jī)A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放請(qǐng)求，并且不再發(fā)送數(shù)據(jù)。TCP通知對(duì)方要釋放從A到B這個(gè)方向的連接，將發(fā)往主機(jī)B的TCP報(bào)文段首部的終止比特FIN置1，其序號(hào)x等于前面已傳送過的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加l。

主機(jī)B的TCP收到釋放連接通知后即發(fā)出確認(rèn)，其序號(hào)為x+1，同時(shí)通知高層應(yīng)用進(jìn)程，如圖8-19中的箭頭①所示。這樣，從A到B的連接就釋放了，連接處于半關(guān)閉(half-close)狀態(tài)，相當(dāng)于主機(jī)A向主機(jī)B說：“我已經(jīng)沒有數(shù)據(jù)要發(fā)送了。但你如果還發(fā)送數(shù)據(jù)，我仍接收。”

此后，主機(jī)B不再接收主機(jī)A發(fā)來的數(shù)據(jù)。但若主機(jī)B還有一些數(shù)據(jù)要發(fā)往主機(jī)A，則可以繼續(xù)發(fā)送。主機(jī)A只要收到數(shù)據(jù)，仍應(yīng)向主機(jī)B發(fā)送確認(rèn)。

在主機(jī)B向主機(jī)A的數(shù)據(jù)發(fā)送結(jié)束后，其應(yīng)用進(jìn)程就通知TCP釋放連接，如圖8-20中的箭頭②所示。主機(jī)B發(fā)出的連接釋放報(bào)文段必須將終止比特FIN置1，并使其序號(hào)y等于前面已傳送過的數(shù)據(jù)的最后—個(gè)字節(jié)的序號(hào)加1，還必須重復(fù)上次已發(fā)送過的ACK＝x+1。主機(jī)A必須對(duì)此發(fā)出確認(rèn)，給出ACK＝y(tǒng)+1,這樣才將從B到A的反方向連接釋放掉。主機(jī)A的TCP再向其應(yīng)用進(jìn)程報(bào)告，整個(gè)連接已經(jīng)全部釋放。

由此可見，上述連接釋放過程和連接建立時(shí)的三次握手在本質(zhì)上是一致的。

習(xí) 題

1．試說明運(yùn)輸層的作用。網(wǎng)絡(luò)層提供數(shù)據(jù)報(bào)或虛電路服務(wù)對(duì)面的運(yùn)輸層有何影響

2．試用示意圖來解釋運(yùn)輸層的復(fù)用。一個(gè)給定的運(yùn)輸連接能否分裂成許多條虛電路？請(qǐng)解釋之。畫圖說明許多個(gè)運(yùn)輸用戶復(fù)用到一條運(yùn)輸連接上，而這條運(yùn)輸連接又復(fù)用到若干條網(wǎng)絡(luò)連接(虛電路)上。

3．解釋為什么突然釋放運(yùn)輸連接就可能會(huì)丟失用戶數(shù)據(jù)而使用TCP的連接釋放方法就可保證不丟失數(shù)據(jù)。

4．試用具體例子說明為什么在運(yùn)輸連接建立時(shí)要使用三次握手。說明如不這樣做可能會(huì)出現(xiàn)什么情況。

5．—個(gè)TCP報(bào)文段中的救據(jù)部分最多為多少個(gè)字節(jié) 為什么

6．主機(jī)A和B使用TCP通信。在B發(fā)送過的報(bào)文段中，有這樣連續(xù)的兩個(gè)：ACK＝120和ACK＝100。這可能嗎(前一個(gè)報(bào)文段確認(rèn)的序號(hào)還大于后一個(gè)的)？試說明理由。

7．在使用TCP傳送數(shù)據(jù)時(shí)，如果有一個(gè)確認(rèn)報(bào)文段丟失了，也不一定會(huì)引起對(duì)方數(shù)據(jù)的重傳。試說明理由(可結(jié)合上一題討論)。

8．在8.4.1節(jié)曾講過，若收到的報(bào)文段無差錯(cuò)，只是未按序號(hào)，則TCP對(duì)此未作明確規(guī)定。何是讓TCP的實(shí)現(xiàn)者自行確定。試討論兩種可能的方法的優(yōu)劣：(1)將不按序的所文段丟棄；(2)允將不按序的報(bào)文段暫存于接收緩存內(nèi)，待所缺序號(hào)的報(bào)文段收齊后再一塊上交應(yīng)用層。

9．設(shè)TCP使用的最大窗口為64KB，即64x]024字節(jié)，而傳輸信道的帶寬可認(rèn)為是不受限制的?？倛?bào)文段的平均往返時(shí)延為20 ms，問所能得到的最大吞量是多少？

10．試計(jì)算一個(gè)包括5段鏈路的運(yùn)輸連接的單程端到端時(shí)延。5段鏈路程中有2段是衛(wèi)星鏈路。每條衛(wèi)星鏈路又由上行鏈路和下行鏈路兩部分組成。可以取這兩部分的傳播時(shí)延之和為250ms。每一個(gè)局域網(wǎng)的范圍為1500 km，其傳播時(shí)延可按150000km/s來計(jì)算。各數(shù)據(jù)鏈路速率為48 Kbit/s，幀長為960 bit。

11．重復(fù)上題，但假定其中的一個(gè)陸地上的廣域網(wǎng)的傳輸時(shí)延為150 ms。

12．什么是Karn算法 在TCP的重傳機(jī)制中，若不采用Karn算法，而是在收列確認(rèn)時(shí)都認(rèn)為是對(duì)重傳報(bào)文段的確認(rèn)，那么由此得中的往返時(shí)延樣本和重作時(shí)間都會(huì)偏小，試問：重傳時(shí)間最后會(huì)減小到什么程度

l3．若一個(gè)應(yīng)用進(jìn)程使用運(yùn)輸層的用戶數(shù)據(jù)報(bào)UDPC但繼續(xù)向下文給IP層后，又封裝成IP數(shù)據(jù)報(bào)。既然都是據(jù)報(bào)，是否可以跳過UDP而直接交給IP層？UDP有沒有提供IP沒有提供的功能

14．使用TCP對(duì)實(shí)時(shí)話音業(yè)務(wù)的傳輸有沒有什么問題 使用UDP在傳送文件時(shí)會(huì)有什么問題？

l5．TCP在進(jìn)行流量控制時(shí)是以分組的丟失作為產(chǎn)生擁塞的標(biāo)志。有沒有不是因擁塞而引起的分組丟失的情況 如有，請(qǐng)舉出三種情況。

16．一個(gè)應(yīng)用程序用UDP，到了IP層將數(shù)據(jù)報(bào)再劃分為4個(gè)數(shù)據(jù)報(bào)片發(fā)送出去。結(jié)果前兩個(gè)數(shù)據(jù)報(bào)片丟失，后兩個(gè)到達(dá)目的站。過了一段時(shí)間應(yīng)用進(jìn)程重傳UDP，而IP層仍然劃分為4個(gè)數(shù)據(jù)報(bào)片來傳送，結(jié)果這次前兩個(gè)到達(dá)目的站而后兩個(gè)丟失。試問：在目的站能否將這兩次傳輸?shù)?個(gè)數(shù)據(jù)報(bào)片組裝成為完整的數(shù)據(jù)報(bào)？假定目的站第—次收到的后兩個(gè)數(shù)據(jù)報(bào)片仍然保存在目的站的緩存中。

17．為什么在TCP首都中有一個(gè)首部長度字段，而UDP的首都中就沒有這個(gè)字段

l8．一個(gè)UDP用戶數(shù)據(jù)報(bào)的數(shù)據(jù)字段為8192字節(jié)，要使用以太網(wǎng)來傳送、試問應(yīng)當(dāng)劃分為幾個(gè)數(shù)據(jù)報(bào)片 說明每一個(gè)數(shù)據(jù)報(bào)片的數(shù)據(jù)字段長度和片偏移字段的值。

19．網(wǎng)絡(luò)允許的最大報(bào)文段長度為128字節(jié)，序號(hào)用8 bit表示，報(bào)文段在網(wǎng)絡(luò)中的生存時(shí)間為30秒。試求每一條TCP連接所能達(dá)到的最高數(shù)據(jù)率。

20．一個(gè)TCP連接下面使用256 Kbit/s的鏈路，其端到端時(shí)延為128 ms。經(jīng)測(cè)試，發(fā)現(xiàn)吞吐量只有120kbit/s。試問發(fā)送窗口是多少