計(jì)算機(jī)網(wǎng)絡(luò)第五章運(yùn)輸層習(xí)題答案

1、奇問(wèn)題5-1：TCP協(xié)議是面向連接的，但TCP使用的IP協(xié)議卻是無(wú)連接的。這兩種協(xié)議都有哪些主要的區(qū)別？答：這個(gè)問(wèn)題很重要，一定要弄清楚。TCP是面向連接的，但TCP所使用的網(wǎng)絡(luò)則可以是面向連接的（如X.25網(wǎng)絡(luò)），但也可以是無(wú)連接的（如現(xiàn)在大量使用的IP網(wǎng)絡(luò)）。選擇無(wú)連接網(wǎng)絡(luò)就使得整個(gè)的系統(tǒng)非常靈活,當(dāng)然也帶來(lái)了一些問(wèn)題。下面是TCP和IP向上提供的功能和服務(wù)的比較。TCP提供的IP提供的面向連接服務(wù)無(wú)連接服務(wù)字節(jié)流接口數(shù)據(jù)報(bào)接口有流量控制無(wú)流量控制有擁塞控制無(wú)擁塞控制保證可靠性：不保證可靠性無(wú)丟失可能丟失無(wú)重復(fù)可能重復(fù)按序交付可能失序顯然，TCP提供的功能和服務(wù)要比IP所能提供的多得多。這

2、是因?yàn)門CP使用了諸如確認(rèn)、窗口通知、計(jì)時(shí)器等機(jī)制，因而可以檢測(cè)出有差錯(cuò)的報(bào)文、重復(fù)的報(bào)文和失序的報(bào)文。奇問(wèn)題5-2：從通信的起點(diǎn)和終點(diǎn)來(lái)比較，TCP和IP的不同點(diǎn)是什么？答：用下面的圖就可說(shuō)明。進(jìn)程A和進(jìn)程B的通信是使用面向連接的TCP提供的可靠的傳輸。主機(jī)X和主機(jī)Y的通信是使用無(wú)連接的IP提供的不可靠的傳輸。請(qǐng)注意：對(duì)TCP來(lái)說(shuō)，通信的起點(diǎn)和終點(diǎn)是運(yùn)輸層上面的兩個(gè)套接字（socket），而應(yīng)用層的應(yīng)用進(jìn)程正是通過(guò)應(yīng)用層和運(yùn)輸層之間的套接字來(lái)使用TCP提供的服務(wù)。TCP協(xié)議根據(jù)報(bào)文段首部中的端口號(hào)找到目的端口，將報(bào)文段交付給目的進(jìn)程。請(qǐng)注意：套接字是由IP地址和端口號(hào)決定的，套接字也可稱為“

3、插口”。對(duì)IP來(lái)說(shuō)，通信的起點(diǎn)和終點(diǎn)是連接在網(wǎng)絡(luò)上的兩個(gè)主機(jī)。IP協(xié)議根據(jù)數(shù)據(jù)報(bào)首部中的目的IP地址找到目的主機(jī)，將數(shù)據(jù)報(bào)交付給目的主機(jī)。/xlSOfilPW請(qǐng)們還可當(dāng)傳輸?shù)姆秶m不可靠傳套的_字擇路由，而不:飛的丨面向連接的，但I(xiàn)P數(shù)據(jù)報(bào)在下i定的路徑傳輸。然而在上面的端字之間的是沿著某我們還應(yīng)當(dāng)注意的是:t面的網(wǎng)絡(luò)中傳輸時(shí)是獨(dú)立地_口看來(lái)，Tcp報(bào)文段好像都是從一個(gè)虛擬的、可靠的通信管道中傳輸?shù)綄?duì)方的端口。|丁土丄A；I不可軸傳輸肯問(wèn)題5-3：端口（port）和套接字（socket）的區(qū)別是什么？答：從本書經(jīng)常使用的套接字定義來(lái)看，套接字包含了端口，因?yàn)樘捉幼?（IP地址，端口號(hào)）。套接字

4、是TCP連接的端點(diǎn)。套接字又稱為“插口”但我們已經(jīng)講過(guò)，套接字（socket）有多種意思。當(dāng)使用API時(shí)，套接字往往被看成是操作系統(tǒng)的一種抽象，這時(shí)，套接字和一個(gè)文件描述符是很相似的，并且是應(yīng)用編程接口API的一部分。套接字由應(yīng)用程序產(chǎn)生，并指明它將由客戶還是服務(wù)器來(lái)使用。當(dāng)應(yīng)用進(jìn)程創(chuàng)建一個(gè)套接字時(shí)，要指明該套接字使用的端口號(hào)。端口則是應(yīng)用層服務(wù)的的一種代號(hào)，它用來(lái)標(biāo)志應(yīng)用層的進(jìn)程。端口是一個(gè)16bit的整數(shù)。各種服務(wù)器使用的端口號(hào)都是保留端口號(hào)，以便使客戶能夠找到服務(wù)器。例如萬(wàn)維網(wǎng)服務(wù)器使用的端口號(hào)是80。在發(fā)送數(shù)據(jù)時(shí)，應(yīng)用層的數(shù)據(jù)通過(guò)端口向下交付到運(yùn)輸層。在接收數(shù)據(jù)時(shí)，運(yùn)輸層的數(shù)據(jù)通過(guò)適當(dāng)

5、的端口向上交付到應(yīng)用層的某個(gè)應(yīng)用程序。奇問(wèn)題5-4：個(gè)套接字能否同時(shí)與遠(yuǎn)地的兩個(gè)套接字相連？答：不行。一個(gè)套接字只能和另一個(gè)遠(yuǎn)地套接字相連。如果許多個(gè)客戶同時(shí)訪問(wèn)同一個(gè)服務(wù)器，那么對(duì)于這種情況，請(qǐng)參考教材的第6章的圖6-30及相應(yīng)的文字解釋。奇問(wèn)題5-5:數(shù)據(jù)鏈路層的HDLC協(xié)議和運(yùn)輸層的TCP協(xié)議都使用滑動(dòng)窗口技術(shù)。從這方面來(lái)進(jìn)行比較，數(shù)據(jù)鏈路層協(xié)議和運(yùn)輸層協(xié)議的主要區(qū)別是什么？答：運(yùn)輸層的TCP協(xié)議是端到端（進(jìn)程到進(jìn)程）的協(xié)議，而數(shù)據(jù)鏈路層的HDLC協(xié)議則是僅在一段鏈路上的結(jié)點(diǎn)到結(jié)點(diǎn)的協(xié)議。此外，TCP的窗口機(jī)制和HDLC的也有許多區(qū)別。如TCP是按數(shù)據(jù)部分的字節(jié)數(shù)進(jìn)行確認(rèn)，而HDLC則是

6、以幀為確認(rèn)的單位。需要注意的是，現(xiàn)在使用得最多的PPP鏈路層協(xié)議并不使用確認(rèn)機(jī)制和窗口機(jī)制。因此像PPP協(xié)議這樣的鏈路層協(xié)議就和運(yùn)輸層協(xié)議有相當(dāng)大的區(qū)別。奇問(wèn)題5-6：TCP協(xié)議能夠?qū)崿F(xiàn)可靠的端到端傳輸。在數(shù)據(jù)鏈路層和網(wǎng)絡(luò)層的傳輸還有沒(méi)有必要來(lái)保證可靠傳輸呢？答：在舊的OSI體系中，在數(shù)據(jù)鏈路層使用HDLC協(xié)議而在網(wǎng)絡(luò)層使用X.25協(xié)議，這些協(xié)議都有確認(rèn)機(jī)制和窗口機(jī)制，因而能夠保證可靠傳輸。但是技術(shù)的進(jìn)步使得鏈路的傳輸已經(jīng)相當(dāng)可靠了，因此在數(shù)據(jù)鏈路層和網(wǎng)絡(luò)層重復(fù)地保證可靠傳輸就顯得多余了。現(xiàn)在因特網(wǎng)在鏈路層使用的PPP協(xié)議和在網(wǎng)絡(luò)層使用的IP協(xié)議都沒(méi)有確認(rèn)機(jī)制和窗口機(jī)制。如果出現(xiàn)差錯(cuò)就由運(yùn)輸層

7、的TCP來(lái)處理（若使用UDP協(xié)議則運(yùn)輸層也不處理出錯(cuò)的問(wèn)題）。奇問(wèn)題5-7：在TCP報(bào)文段的首部中只有端口號(hào)而沒(méi)有IP地址。當(dāng)TCP將其報(bào)文段交給IP層時(shí)，IP協(xié)議怎樣知道目的IP地址呢？答：顯然，僅從TCP報(bào)文段的首部是無(wú)法得知目的IP地址。因此，TCP必須告訴IP層此報(bào)文段要發(fā)送給哪一個(gè)目的主機(jī)（給出其IP地址）。此目的IP地址填寫在IP數(shù)據(jù)報(bào)的首部中。奇問(wèn)題5-8：在TCP傳送數(shù)據(jù)時(shí)，有沒(méi)有規(guī)定一個(gè)最大重傳次數(shù)？答：我們知道以太網(wǎng)規(guī)定重傳16次就認(rèn)為傳輸失敗，然后報(bào)告上層。但TCP沒(méi)有規(guī)定最大重傳次數(shù)，而是通過(guò)設(shè)置一些計(jì)時(shí)器來(lái)解決有關(guān)傳輸失敗的問(wèn)題。奇問(wèn)題5-9：TCP都使用哪些計(jì)時(shí)器？

8、答：TCP共使用以下四種計(jì)時(shí)器，即重傳計(jì)時(shí)器、持續(xù)計(jì)時(shí)器、?；钣?jì)時(shí)器和時(shí)間等待計(jì)時(shí)器。這幾個(gè)計(jì)時(shí)器的主要特點(diǎn)如下：A重傳計(jì)時(shí)器當(dāng)TCP發(fā)送報(bào)文段時(shí)，就創(chuàng)建該特定報(bào)文段的重傳計(jì)時(shí)器?？赡馨l(fā)生兩種情況：若在計(jì)時(shí)器截止時(shí)間到之前收到了對(duì)此特定報(bào)文段的確認(rèn)，則撤銷此計(jì)時(shí)器。若在收到了對(duì)此特定報(bào)文段的確認(rèn)之前計(jì)時(shí)器截止期到，則重傳此報(bào)文段，并將計(jì)時(shí)器復(fù)位。A持續(xù)計(jì)時(shí)器為了對(duì)付零窗口大小通知，TCP需要另一個(gè)計(jì)時(shí)器。假定接收TCP宣布了窗口大小為零。發(fā)送TCP就停止傳送報(bào)文段，直到接收TCP發(fā)送確認(rèn)并宣布一個(gè)非零的窗口大小。但這個(gè)確認(rèn)可能會(huì)丟失。我們知道在TCP中，對(duì)確認(rèn)是不需要發(fā)送確認(rèn)的。若確認(rèn)丟失了，

9、接收TCP并不知道，而是會(huì)認(rèn)為它已經(jīng)完成任務(wù)了，并等待著發(fā)送TCP接著會(huì)發(fā)送更多的報(bào)文段。但發(fā)送TCP由于沒(méi)有收到確認(rèn)，就等待對(duì)方發(fā)送確認(rèn)來(lái)通知窗口的大小。雙方的TCP都在永遠(yuǎn)地等待著對(duì)方。要打開(kāi)這種死鎖，TCP為每一個(gè)連接使用一個(gè)持續(xù)計(jì)時(shí)器。當(dāng)發(fā)送TCP收到一個(gè)窗口大小為零的確認(rèn)時(shí)，就啟動(dòng)持續(xù)計(jì)時(shí)器。當(dāng)持續(xù)計(jì)時(shí)器期限到時(shí)，發(fā)送TCP就發(fā)送一個(gè)特殊的報(bào)文段，叫做報(bào)文段。這個(gè)報(bào)文段只有一個(gè)字節(jié)的數(shù)據(jù)。它有一個(gè)序號(hào)，但它的序號(hào)永遠(yuǎn)不需要確認(rèn)；甚至在計(jì)算對(duì)其他部分的數(shù)據(jù)的確認(rèn)時(shí)該序號(hào)也被忽略。探測(cè)報(bào)文段提醒接收TCP：確認(rèn)已丟失，必須重傳。持續(xù)計(jì)時(shí)器的值設(shè)置為重傳時(shí)間的數(shù)值。但是，若沒(méi)有收到從接收端

10、來(lái)的響應(yīng)，則需發(fā)送另一個(gè)探測(cè)報(bào)文段，并將持續(xù)計(jì)時(shí)器的值加倍和復(fù)位。發(fā)送端繼續(xù)發(fā)送探測(cè)報(bào)文段，將持續(xù)計(jì)時(shí)器設(shè)定的值加倍和復(fù)位，直到這個(gè)值增大到門限值（通常是60秒）為止。在這以后發(fā)送端每隔60秒就發(fā)送一個(gè)探測(cè)報(bào)文段，直到窗口重新打開(kāi)。A保活計(jì)時(shí)器?；钣?jì)時(shí)器使用在某些實(shí)現(xiàn)中，用來(lái)防止在兩個(gè)TCP之間的連接出現(xiàn)長(zhǎng)時(shí)期的空閑。假定客戶打開(kāi)了到服務(wù)器的連接，傳送了一些數(shù)據(jù)，然后就保持靜默了。也許這個(gè)客戶出故障了。在這種情況下，這個(gè)連接將永遠(yuǎn)地處理打開(kāi)狀態(tài)。要解決這種問(wèn)題，在大多數(shù)的實(shí)現(xiàn)中都是使服務(wù)器設(shè)置?；钣?jì)時(shí)器。每當(dāng)服務(wù)器收到客戶的信息，就將計(jì)時(shí)器復(fù)位。超時(shí)通常設(shè)置為2小時(shí)。若服務(wù)器過(guò)了2小時(shí)還沒(méi)有收

11、到客戶的信息，它就發(fā)送探測(cè)報(bào)文段。若發(fā)送了10個(gè)探測(cè)報(bào)文段（每一個(gè)相隔75秒）還沒(méi)有響應(yīng)，就假定客戶出了故障，因而就終止該連接。A時(shí)間等待計(jì)時(shí)器時(shí)間等待計(jì)時(shí)器是在連接終止期間使用的。當(dāng)TCP關(guān)閉一個(gè)連接時(shí)，它并不認(rèn)為這個(gè)連接馬上就真正地關(guān)閉了。在時(shí)間等待期間中，連接還處于一種中間過(guò)渡狀態(tài)。這就可以使重復(fù)的FIN報(bào)文段（如果有的話）可以到達(dá)目的站因而可將其丟棄。這個(gè)計(jì)時(shí)器的值通常設(shè)置為一個(gè)報(bào)文段的壽命期待值的兩倍。奇問(wèn)題5-10：是否TCP和UDP都需要計(jì)算往返時(shí)間RTT?答：往返時(shí)間RTT只是對(duì)運(yùn)輸層的TCP協(xié)議才很重要，因?yàn)門CP要根據(jù)平均往返時(shí)間RTT的值來(lái)設(shè)置超時(shí)計(jì)時(shí)器的超時(shí)時(shí)間。UDP

12、沒(méi)有確認(rèn)和重傳機(jī)制，因此RTT對(duì)UDP沒(méi)有什么意義。因此，不要籠統(tǒng)地說(shuō)“往返時(shí)間RTT對(duì)運(yùn)輸層來(lái)說(shuō)很重要”，因?yàn)橹挥蠺CP才需要計(jì)算RTT，而UDP不需要計(jì)算RTT。奇問(wèn)題5-11：假定TCP開(kāi)始進(jìn)行連接建立。當(dāng)TCP發(fā)送第一個(gè)SYN報(bào)文段時(shí)，顯然無(wú)法利用教材中5.6.3節(jié)所介紹的方法計(jì)算往返時(shí)間RTT。那么這時(shí)TCP又怎樣設(shè)置重傳計(jì)時(shí)器呢？答:這時(shí)TCP顯然無(wú)法利用已有的公式算出往返時(shí)間RTT。實(shí)際上TCP是選擇（也就是猜測(cè)）一個(gè)比較長(zhǎng)的時(shí)間作為初始的往返時(shí)間RTT。等到收到至少一個(gè)確認(rèn)報(bào)文段時(shí)才能利用公式計(jì)算出比較合理的往返時(shí)間RTT。奇問(wèn)題5-12:糊涂窗口綜合癥產(chǎn)生的條件是什么？是否只

13、有在接收方才產(chǎn)生這種癥狀？答：糊涂窗口綜合癥產(chǎn)生的條件是：當(dāng)發(fā)送應(yīng)用程序產(chǎn)生數(shù)據(jù)很慢，或者接收應(yīng)用程序吸收數(shù)據(jù)很慢，或者兩者都有。因此發(fā)送方和接收方都可能產(chǎn)生這種癥狀。不管是上述情況中的哪一種，都使得發(fā)送數(shù)據(jù)的報(bào)文段很小，這就引起操作效率的降低。例如，若TCP發(fā)送的報(bào)文段只包括一個(gè)字節(jié)的數(shù)據(jù)，則意味著我們發(fā)送41字節(jié)的數(shù)據(jù)報(bào)（20字節(jié)的TCP首部和20字節(jié)的IP首部）才傳送1字節(jié)的數(shù)據(jù)。數(shù)據(jù)的傳送效率是1/41，它表示我們非常低效率地使用網(wǎng)絡(luò)的容量。奇問(wèn)題5-13:能否更詳細(xì)些討論一下糊涂窗口綜合癥及其解決方法？答:發(fā)送端產(chǎn)生的癥狀如果發(fā)送端為產(chǎn)生數(shù)據(jù)很慢的應(yīng)用程序服務(wù)，例如，一次產(chǎn)生一個(gè)字節(jié)

14、。這個(gè)應(yīng)用程序一次將一個(gè)字節(jié)的數(shù)據(jù)寫入發(fā)送端的TCP的緩存。如果發(fā)送端的TCP沒(méi)有特定的指令，它就產(chǎn)生只包括一個(gè)字節(jié)數(shù)據(jù)的報(bào)文段。結(jié)果有很多41字節(jié)的IP數(shù)據(jù)報(bào)就在互連網(wǎng)中傳來(lái)傳去。解決的方法是防止發(fā)送端的TCP逐個(gè)字節(jié)地發(fā)送數(shù)據(jù)。必須強(qiáng)迫發(fā)送端的TCP收集數(shù)據(jù)，然后用一個(gè)更大的數(shù)據(jù)塊來(lái)發(fā)送。發(fā)送端的TCP要等待多長(zhǎng)時(shí)間呢？如果它等待過(guò)長(zhǎng),它就會(huì)使整個(gè)的過(guò)程產(chǎn)生較長(zhǎng)的時(shí)延。如果它的等待時(shí)間不夠長(zhǎng)，它就可能發(fā)送較小的報(bào)文段。Nagle找到了一個(gè)很好的解決方法。算法Nagle算法非常簡(jiǎn)單，但它能解決問(wèn)題。這個(gè)算法是為發(fā)送端的TCP用的：發(fā)送端的TCP將它從發(fā)送應(yīng)用程序收到的第一塊數(shù)據(jù)發(fā)送出去，哪怕

15、只有一個(gè)字節(jié)。在發(fā)送第一個(gè)報(bào)文段（即報(bào)文段1）以后，發(fā)送端的TCP就在輸出緩存中積累數(shù)據(jù)，并等待：或者接收端的TCP發(fā)送出一個(gè)確認(rèn)，或者數(shù)據(jù)已積累到可以裝成一個(gè)最大的報(bào)文段。在這個(gè)時(shí)候，發(fā)送端的TCP就可以發(fā)送這個(gè)報(bào)文段。對(duì)剩下的傳輸，重復(fù)步驟2。這就是：如果收到了對(duì)報(bào)文段x的確認(rèn)，或者數(shù)據(jù)已積累到可以裝成一個(gè)最大的報(bào)文段，那么就發(fā)送下一個(gè)報(bào)文段（x+1）。Nagle算法的優(yōu)點(diǎn)就是簡(jiǎn)單，并且它考慮到應(yīng)用程序產(chǎn)生數(shù)據(jù)的速率，以及網(wǎng)絡(luò)運(yùn)輸數(shù)據(jù)的速率。若應(yīng)用程序比網(wǎng)絡(luò)更快，則報(bào)文段就更大（最大報(bào)文段）。若應(yīng)用程序比網(wǎng)絡(luò)慢則報(bào)文段就較?。ㄐ∮谧畲髨?bào)文段）。接收端產(chǎn)生的癥狀接收端的TCP可能產(chǎn)生糊涂窗口

16、綜合癥，如果它為消耗數(shù)據(jù)很慢的應(yīng)用程序服務(wù)，例如，一次消耗一個(gè)字節(jié)。假定發(fā)送應(yīng)用程序產(chǎn)生了1000字節(jié)的數(shù)據(jù)塊，但接收應(yīng)用程序每次只吸收1字節(jié)的數(shù)據(jù)。再假定接收端的TCP的輸入緩存為4000字節(jié)。發(fā)送端先發(fā)送第一個(gè)4000字節(jié)的數(shù)據(jù)。接收端將它存儲(chǔ)在其緩存中?，F(xiàn)在緩存滿了。它通知窗口大小為零，這表示發(fā)送端必須停止發(fā)送數(shù)據(jù)。接收應(yīng)用程序從接收端的TCP的輸入緩存中讀取第一個(gè)字節(jié)的數(shù)據(jù)。在入緩存中現(xiàn)在有了1字節(jié)的空間。接收端的TCP宣布其窗口大小為1字節(jié),這表示正渴望等待發(fā)送數(shù)據(jù)的發(fā)送端的TCP會(huì)把這個(gè)宣布當(dāng)作一個(gè)好消息，并發(fā)送只包括一個(gè)字節(jié)數(shù)據(jù)的報(bào)文段。這樣的過(guò)程一直繼續(xù)下去。一個(gè)字節(jié)的數(shù)據(jù)被消

17、耗掉，然后發(fā)送只包含一個(gè)字節(jié)數(shù)據(jù)的報(bào)文段。這又是一個(gè)效率問(wèn)題和糊涂窗口綜合癥（見(jiàn)下圖）。對(duì)于這種糊涂窗口綜合癥，即應(yīng)用程序消耗數(shù)據(jù)比到達(dá)的慢，有兩種建議的解決方法。解決方法Clark解決方法是只要有數(shù)據(jù)到達(dá)就發(fā)送確認(rèn)，但宣布的窗口大小為零，直到或者緩存空間已能放入具有最大長(zhǎng)度的報(bào)文段，或者緩存空間的一半已經(jīng)空了。A延遲的確認(rèn)第二個(gè)解決方法是延遲一段時(shí)間后再發(fā)送確認(rèn)。這表示當(dāng)一個(gè)報(bào)文段到達(dá)時(shí)并不立即發(fā)送確認(rèn)。接收端在確認(rèn)收到的報(bào)文段之前一直等待，直到入緩存有足夠的空間為止。延遲的確認(rèn)防止了發(fā)送端的TCP滑動(dòng)其窗口。當(dāng)發(fā)送端的TCP發(fā)送完其數(shù)據(jù)后，它就停下來(lái)了。這樣就防止了這種癥狀。遲延的確認(rèn)還有

18、另一個(gè)優(yōu)點(diǎn)：它減少了通信量。接收端不需要確認(rèn)每一個(gè)報(bào)文段。但它也有一個(gè)缺點(diǎn)，就是遲延的確認(rèn)有可能迫使發(fā)送端重傳其未被確認(rèn)的報(bào)文段。可以用協(xié)議來(lái)平衡這個(gè)優(yōu)點(diǎn)和缺點(diǎn)，例如現(xiàn)在定義了確認(rèn)的延遲不能超過(guò)500毫秒。奇問(wèn)題5-14:為什么TCP在建立連接時(shí)不能每次都選擇相同的、固定的初始序號(hào)？答：如果TCP在建立連接時(shí)每次都選擇相同的、固定的初始序號(hào)，那么設(shè)想以下的情況：假定主機(jī)A和B頻繁地建立連接，傳送一些TCP報(bào)文段后，再釋放連接，然后又不斷地建立新的連接、傳送報(bào)文段和釋放連接。假定每一次建立連接時(shí)，主機(jī)A都選擇相同的、固定的初始序號(hào)，例如，選擇1。假定主機(jī)A發(fā)送出的某些TCP報(bào)文段在網(wǎng)絡(luò)中會(huì)滯留較

19、長(zhǎng)的時(shí)間，以致造成主機(jī)A超時(shí)重傳這些TCP報(bào)文段。假定有一些在網(wǎng)絡(luò)中滯留時(shí)間較長(zhǎng)的TCP報(bào)文段最后終于到達(dá)了主機(jī)B,但這時(shí)傳送該報(bào)文段的那個(gè)連接早已釋放了，而在到達(dá)主機(jī)B時(shí)的TCP連接是一條新的TCP連接。這樣，工作在新的TCP連接下的主機(jī)B就有可能會(huì)接受在舊的連接傳送的、已經(jīng)沒(méi)有意義的、過(guò)時(shí)的TCP報(bào)文段(因?yàn)檫@個(gè)TCP報(bào)文段的序號(hào)有可能正好處在現(xiàn)在新的連接所使用的序號(hào)范圍之中)。結(jié)果產(chǎn)生錯(cuò)誤。因此，必須使得遲到的TCP報(bào)文段的序號(hào)不處在新的連接中所使用的序號(hào)范圍之中。這樣，TCP在建立新的連接時(shí)所選擇的初始序號(hào)一定要和前面的一些連接所使用過(guò)的序號(hào)不一樣。因此，不同的TCP連接不能使用相同的

20、初始序號(hào)。奇問(wèn)題5-15:能否利用TCP發(fā)送端和接收端交換報(bào)文段的圖來(lái)說(shuō)明慢開(kāi)始的特點(diǎn)？答：慢開(kāi)始的特點(diǎn)可以用下圖來(lái)說(shuō)明。擁塞窗口cwnd的初始值是1(為方便起見(jiàn)，這里將擁塞窗口的單位設(shè)為報(bào)文段)。以后每收到一個(gè)對(duì)新的報(bào)文段的確認(rèn)，就將發(fā)送端的擁塞窗口cwnd加1?？梢钥闯?，擁塞窗口cwnd按照指數(shù)規(guī)律增長(zhǎng)。所謂“新的報(bào)文段”就是指“未被確認(rèn)過(guò)的報(bào)文段”。由于報(bào)文段在因特網(wǎng)中傳輸時(shí)，有可能在某個(gè)路由器處滯留一段時(shí)間，但以后又被交付到接收端(重復(fù)交付)。接收端對(duì)每一個(gè)收到的無(wú)差錯(cuò)的報(bào)文段都可能給出確認(rèn)。因此，對(duì)同一個(gè)報(bào)文段，發(fā)送端有可能收到幾個(gè)重復(fù)的確認(rèn)。但除了第一個(gè)確認(rèn)可以使發(fā)送端擁塞窗口cw

21、nd加1以外，對(duì)其余重復(fù)的報(bào)文段的確認(rèn)都不能再使發(fā)送端擁塞窗口加1。發(fā)送端cwnd=1，發(fā)送M。接收端MMt確認(rèn)M0收到對(duì)M1M2的確認(rèn)cwnd=4,發(fā)送MM36確認(rèn)M-M36確認(rèn)M1M2收到對(duì)M0的確認(rèn)cwnd=2,發(fā)送MM2收到對(duì)M3m6的確認(rèn)cwnd=&發(fā)送M7MmRTT收到對(duì)所有報(bào)文段的確認(rèn)cwnd=ssthresh+2RTTRTT接收端發(fā)送確認(rèn)發(fā)送確認(rèn)RTT發(fā)送確認(rèn)發(fā)送確認(rèn)發(fā)送確認(rèn)收到對(duì)所有報(bào)文段的確認(rèn)cwnd=ssthresh+1收到對(duì)所有報(bào)文段的確認(rèn)cwnd=ssthresh+4一發(fā)送N-個(gè)報(bào)文段收到對(duì)所有報(bào)文段的確認(rèn)一cwnd=ssthresh+3問(wèn)題5-16：對(duì)于擁塞避免是否

22、也能夠用發(fā)送端和接收端交換的報(bào)文段來(lái)說(shuō)明其工作原理？答：可以，但這只能是示意圖。因?yàn)樵趽砣苊獾拈_(kāi)始，發(fā)送端的擁塞窗口swnd=ssthresh，這時(shí)可以發(fā)送好幾個(gè)報(bào)文段。按照RFC2581文檔，每經(jīng)過(guò)一個(gè)往返時(shí)間RTT,擁塞窗口就增加一個(gè)MSS的大小（以字節(jié)為單位）。在我們討論原理時(shí)，以報(bào)文段個(gè)數(shù)作為窗口單位較為方便，因此在圖中每經(jīng)過(guò)一個(gè)RTT，發(fā)送端擁塞窗口swnd就在ssthresh的基礎(chǔ)上加1。在圖中將發(fā)送端發(fā)送報(bào)文段用一個(gè)粗箭頭表示（因?yàn)檫@里面包含有許多個(gè)報(bào)文段，很難一個(gè)個(gè)畫出），確認(rèn)報(bào)文段也用一個(gè)粗箭頭表示（這也可能有許多個(gè)確認(rèn)報(bào)文段），因此RTT也是概念性的往返時(shí)間。邈送端當(dāng)cw

23、nd=ssthresh時(shí)開(kāi)始擁塞避免rttt正因?yàn)镽TT無(wú)法很嚴(yán)格地畫出，因此在圖中左邊增加一個(gè)注釋，即“收到對(duì)所有報(bào)文段的確認(rèn)”這里假定收到對(duì)所有報(bào)文段的確認(rèn)所需的時(shí)間就是RTT。問(wèn)題5-17：TCP連接很像一條連接發(fā)送端和接收端的雙向管道。當(dāng)TCP在連續(xù)發(fā)送報(bào)文段時(shí)，若要管道得到充分的利用，則發(fā)送窗口的大小應(yīng)怎樣選擇？答：我們可以用下面的圖來(lái)說(shuō)明這一問(wèn)題。圖中在發(fā)送端和接收端之間的兩個(gè)白色長(zhǎng)條表示TCP全雙工通信的發(fā)送管道和接收管道。管道是對(duì)信道的一種抽象，便于討論問(wèn)題（可以不涉及下層互連網(wǎng)絡(luò)的細(xì)節(jié)）。假定在t=0時(shí)發(fā)送端使用慢開(kāi)始算法來(lái)發(fā)送報(bào)文段，因此在t=0時(shí)只能發(fā)送一個(gè)報(bào)文段（圖中標(biāo)

24、有1的綠色長(zhǎng)方條就代表報(bào)文段1）。圖中的時(shí)間都是按離散的時(shí)間單位表示。為簡(jiǎn)化分析，我們還假定，發(fā)送窗口僅由發(fā)送端的擁塞窗口來(lái)確定，接收端不對(duì)發(fā)送窗口加以限制。假定在t=1時(shí)，報(bào)文段1的第一個(gè)比特正好走完四分之一的管道，同時(shí)該報(bào)文段的最后一個(gè)比特正好發(fā)送完畢。t=4，報(bào)文段1的前沿到達(dá)接收端。t=5時(shí)，接收端將報(bào)文段1接收完畢。假定接收端立即發(fā)送確認(rèn)報(bào)文段。我們所用的標(biāo)記是：對(duì)報(bào)文段n的確認(rèn)報(bào)文段我們用具有標(biāo)記n的紅色小長(zhǎng)方條表示。t=9，對(duì)報(bào)文段1的確認(rèn)的前沿到達(dá)發(fā)送端。t=10，發(fā)送端將發(fā)送窗口加1變?yōu)?（可以發(fā)送報(bào)文段2和3），并開(kāi)始發(fā)送報(bào)文段2（這一步圖中省略了，沒(méi)有畫出）。t=11，報(bào)

25、文段2走完發(fā)送管道的四分之一，發(fā)送端開(kāi)始發(fā)送報(bào)文段3。t=12，報(bào)文段2和3填滿發(fā)送管道的一半。t=14，報(bào)文段2的前沿到達(dá)接收端。t=15，接收端收完報(bào)文段2，并發(fā)送對(duì)報(bào)文段2的確認(rèn)。t=16，接收端收完報(bào)文段3，并發(fā)送對(duì)報(bào)文段3的確認(rèn)。t=19，對(duì)報(bào)文段2的確認(rèn)前沿傳播到發(fā)送端。t=20，發(fā)送端收到對(duì)報(bào)文段2的確認(rèn)，將發(fā)送窗口加1變?yōu)?（可以發(fā)送報(bào)文段4,5和6），并開(kāi)始發(fā)送報(bào)文段4（這一步圖中省略了，沒(méi)有畫出）。對(duì)報(bào)文段3的確認(rèn)的前沿也在這個(gè)時(shí)間傳播到發(fā)送端。再以后的過(guò)程我們用下面的另一張圖來(lái)說(shuō)明。t=21，發(fā)送端收到對(duì)報(bào)文段3的確認(rèn)，將發(fā)送窗口再加1變?yōu)?（可以發(fā)送報(bào)文段4,5,6和7

26、），并開(kāi)始發(fā)送報(bào)文段5。此時(shí)，報(bào)文段4已完全進(jìn)入發(fā)送管道，前沿到了管道的四分之一處。t=35t=36t=3754t=22!654t=23176541t=24t=257654t=2676i4714-5-6-1t=2745-6-7t=28t=31t=32t=33t=3411098111098!121110913121110-8-9-1141312118-910151413128910以后的過(guò)程讀者自己都可以看懂。這里只再提幾點(diǎn)。發(fā)送端每收到一個(gè)對(duì)沒(méi)有確認(rèn)過(guò)的報(bào)文段的確認(rèn)，就將發(fā)送窗口加1。因此在陸續(xù)收到確認(rèn)47后，將發(fā)送窗口加4，即增大到8，可以連續(xù)發(fā)送報(bào)文段815。管道空間是有限的。從圖中表示的

27、例子可以看出，這樣的管道至多可容納4個(gè)報(bào)文段。當(dāng)發(fā)送窗口很小時(shí)，管道在大部分時(shí)間內(nèi)是比較空的（見(jiàn)前面的第一張圖）。這說(shuō)明在TCP連接中傳輸數(shù)據(jù)的效率比較低。當(dāng)發(fā)送窗口增大時(shí)，管道逐漸被填滿?？梢钥闯?，在t=3438時(shí)，發(fā)送管道一直是被填滿的，這說(shuō)明發(fā)送管道被利用得很充分。因?yàn)閳?bào)文段的傳輸需要時(shí)間，因此對(duì)報(bào)文段的確認(rèn)總是會(huì)滯后一段時(shí)間。上面的例子表明，在單方向發(fā)送報(bào)文段（另一個(gè)方向發(fā)送確認(rèn)）的情況下，發(fā)送管道和接收管道往往不能同時(shí)被充分利用（除非發(fā)送窗口的數(shù)值較大）。但如果雙向都能發(fā)送數(shù)據(jù)報(bào)文段，那么發(fā)送管道和接收管道就都能夠被利用得較充分。我們還可看出，接收管道（即接收端發(fā)送確認(rèn)報(bào)文段的管道）在任何情況下都沒(méi)有填滿。這是因?yàn)榇_認(rèn)報(bào)文段很短，只需很短的時(shí)間就可發(fā)送出去。但接收一個(gè)數(shù)據(jù)報(bào)文段需要較多的時(shí)間，這就造成確認(rèn)報(bào)文段不可能連續(xù)地從接收端發(fā)送出去。問(wèn)題5-18：假定在一個(gè)互聯(lián)網(wǎng)中，所有的鏈路的傳輸都不出現(xiàn)差錯(cuò)，所有的結(jié)點(diǎn)也都不會(huì)發(fā)生故障。試問(wèn)在這種情況下，TCP的“可靠交付”的功能是否就是多余的？答：不是多余的。TCP的“可靠交付”