計算機網絡 第五章-運輸層習題答案

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

2、能提供的多得多。這是因為TCP使用了諸如確認、窗口通知、計時器等機制，因而可以檢測出有差錯的報文、重復的報文和失序的報文。F問題5-2：從通信的起點和終點來比較，TCP和IP的不同點是什么？答：用下面的圖就可說明。進程A和進程B的通信是使用面向連接的TCP提供的可靠的傳輸。主機X和主機Y的通信是使用無連接的IP提供的不可靠的傳輸。請注意：對TCP來說，通信的起點和終點是運輸層上面的兩個套接字(socket)，而應用層的應用進程正是通過應用層和運輸層之間的套接字來使用TCP提供的服務。TCP協議根據報文段首部中的端口號找到目的端口，將報文段交付給目的進程。請注意：套接字是由IP地址和端口號決定的

3、，套接字也可稱為“插口”。對IP來說，通信的起點和終點是連接在網絡上的兩個主機。IP協議根據數據報首部中的目的IP地址找到目的主機，將數據報交付給目的主機。請注意可靠傳輸的范圍和不可靠傳輸的范圍是不同的。我們還應當注意的是：雖然在兩個套接字之間的通信是面向連接的，但IP數據報在下面的網絡中傳輸時是獨立地選擇路由，而不是沿著某一條固定的路徑傳輸。然而在上面的端口看來，TCP報文段好像都是從一個虛擬的、可靠的通信管道中傳輸到對方的端口。F問題5-3：端口(port)和套接字(socket)的區(qū)別是什么？答：從本書經常使用的套接字定義來看，套接字包含了端口，因為套接字 = (IP地址，端口號)。套接

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

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

6、LC則是以幀為確認的單位。需要注意的是，現在使用得最多的PPP鏈路層協議并不使用確認機制和窗口機制。因此像PPP協議這樣的鏈路層協議就和運輸層協議有相當大的區(qū)別。F問題5-6：TCP協議能夠實現可靠的端到端傳輸。在數據鏈路層和網絡層的傳輸還有沒有必要來保證可靠傳輸呢？答：在舊的OSI體系中，在數據鏈路層使用HDLC協議而在網絡層使用X.25協議，這些協議都有確認機制和窗口機制，因而能夠保證可靠傳輸。但是技術的進步使得鏈路的傳輸已經相當可靠了，因此在數據鏈路層和網絡層重復地保證可靠傳輸就顯得多余了?，F在因特網在鏈路層使用的PPP協議和在網絡層使用的IP協議都沒有確認機制和窗口機制。如果出現差錯就

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

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

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

10、置為重傳時間的數值。但是，若沒有收到從接收端來的響應，則需發(fā)送另一個探測報文段，并將持續(xù)計時器的值加倍和復位。發(fā)送端繼續(xù)發(fā)送探測報文段，將持續(xù)計時器設定的值加倍和復位，直到這個值增大到門限值（通常是60秒）為止。在這以后，發(fā)送端每隔60秒就發(fā)送一個探測報文段，直到窗口重新打開。Ø?；钣嫊r器保活計時器使用在某些實現中，用來防止在兩個TCP之間的連接出現長時期的空閑。假定客戶打開了到服務器的連接，傳送了一些數據，然后就保持靜默了。也許這個客戶出故障了。在這種情況下，這個連接將永遠地處理打開狀態(tài)。要解決這種問題，在大多數的實現中都是使服務器設置?；钣嫊r器。每當服務器收到客戶的信息，就將計時

11、器復位。超時通常設置為2小時。若服務器過了2小時還沒有收到客戶的信息，它就發(fā)送探測報文段。若發(fā)送了10個探測報文段（每一個相隔75秒）還沒有響應，就假定客戶出了故障，因而就終止該連接。Ø時間等待計時器 時間等待計時器是在連接終止期間使用的。當TCP關閉一個連接時，它并不認為這個連接馬上就真正地關閉了。在時間等待期間中，連接還處于一種中間過渡狀態(tài)。這就可以使重復的FIN報文段（如果有的話）可以到達目的站因而可將其丟棄。這個計時器的值通常設置為一個報文段的壽命期待值的兩倍。F問題5-10：是否TCP和UDP都需要計算往返時間RTT？答：往返時間RTT只是對運輸層的TCP協議才很重要，因為

12、TCP要根據平均往返時間RTT的值來設置超時計時器的超時時間。UDP沒有確認和重傳機制，因此RTT對UDP沒有什么意義。因此，不要籠統(tǒng)地說“往返時間RTT對運輸層來說很重要”，因為只有TCP才需要計算RTT，而UDP不需要計算RTT。F問題5-11：假定TCP開始進行連接建立。當TCP發(fā)送第一個SYN報文段時，顯然無法利用教材中節(jié)所介紹的方法計算往返時間RTT。那么這時TCP又怎樣設置重傳計時器呢？答：這時TCP顯然無法利用已有的公式算出往返時間RTT。實際上TCP是選擇（也就是猜測）一個比較長的時間作為初始的往返時間RTT。等到收到至少一個確認報文段時才能利用公式計算出比較合理的往返時間RT

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

14、發(fā)送端為產生數據很慢的應用程序服務，例如，一次產生一個字節(jié)。這個應用程序一次將一個字節(jié)的數據寫入發(fā)送端的TCP的緩存。如果發(fā)送端的TCP沒有特定的指令，它就產生只包括一個字節(jié)數據的報文段。結果有很多41字節(jié)的IP數據報就在互連網中傳來傳去。解決的方法是防止發(fā)送端的TCP逐個字節(jié)地發(fā)送數據。必須強迫發(fā)送端的TCP收集數據，然后用一個更大的數據塊來發(fā)送。發(fā)送端的TCP要等待多長時間呢？如果它等待過長，它就會使整個的過程產生較長的時延。如果它的等待時間不夠長，它就可能發(fā)送較小的報文段。Nagle找到了一個很好的解決方法。ØNagle算法Nagle算法非常簡單，但它能解決問題。這個算法是為發(fā)

15、送端的TCP用的： 1. 發(fā)送端的TCP將它從發(fā)送應用程序收到的第一塊數據發(fā)送出去，哪怕只有一個字節(jié)。 2. 在發(fā)送第一個報文段（即報文段1）以后，發(fā)送端的TCP就在輸出緩存中積累數據，并等待：或者接收端的TCP發(fā)送出一個確認，或者數據已積累到可以裝成一個最大的報文段。在這個時候，發(fā)送端的TCP就可以發(fā)送這個報文段。 3. 對剩下的傳輸，重復步驟2。這就是：如果收到了對報文段x的確認，或者數據已積累到可以裝成一個最大的報文段，那么就發(fā)送下一個報文段(x + 1)。Nagle算法的優(yōu)點就是簡單，并且它考慮到應用程序產生數據的速率，以及網絡運輸數據的速率。若應用程序比網絡更快，則報文段就更大（最大

16、報文段）。若應用程序比網絡慢，則報文段就較小（小于最大報文段）。接收端產生的癥狀接收端的TCP可能產生糊涂窗口綜合癥，如果它為消耗數據很慢的應用程序服務，例如，一次消耗一個字節(jié)。假定發(fā)送應用程序產生了1000字節(jié)的數據塊，但接收應用程序每次只吸收1字節(jié)的數據。再假定接收端的TCP的輸入緩存為4000字節(jié)。發(fā)送端先發(fā)送第一個4000字節(jié)的數據。接收端將它存儲在其緩存中?，F在緩存滿了。它通知窗口大小為零，這表示發(fā)送端必須停止發(fā)送數據。接收應用程序從接收端的TCP的輸入緩存中讀取第一個字節(jié)的數據。在入緩存中現在有了1字節(jié)的空間。接收端的TCP宣布其窗口大小為1字節(jié)，這表示正渴望等待發(fā)送數據的發(fā)送端的

17、TCP會把這個宣布當作一個好消息，并發(fā)送只包括一個字節(jié)數據的報文段。這樣的過程一直繼續(xù)下去。一個字節(jié)的數據被消耗掉，然后發(fā)送只包含一個字節(jié)數據的報文段。這又是一個效率問題和糊涂窗口綜合癥（見下圖）。對于這種糊涂窗口綜合癥，即應用程序消耗數據比到達的慢，有兩種建議的解決方法。ØClark解決方法 Clark解決方法是只要有數據到達就發(fā)送確認，但宣布的窗口大小為零，直到或者緩存空間已能放入具有最大長度的報文段，或者緩存空間的一半已經空了。Ø延遲的確認 第二個解決方法是延遲一段時間后再發(fā)送確認。這表示當一個報文段到達時并不立即發(fā)送確認。接收端在確認收到的報文段之前一直等待，直到入

18、緩存有足夠的空間為止。延遲的確認防止了發(fā)送端的TCP滑動其窗口。當發(fā)送端的TCP發(fā)送完其數據后，它就停下來了。這樣就防止了這種癥狀。遲延的確認還有另一個優(yōu)點：它減少了通信量。接收端不需要確認每一個報文段。但它也有一個缺點，就是遲延的確認有可能迫使發(fā)送端重傳其未被確認的報文段?？梢杂脜f議來平衡這個優(yōu)點和缺點，例如現在定義了確認的延遲不能超過500毫秒。F問題5-14：為什么TCP在建立連接時不能每次都選擇相同的、固定的初始序號？答：如果TCP在建立連接時每次都選擇相同的、固定的初始序號，那么設想以下的情況：(1) 假定主機A和B頻繁地建立連接，傳送一些TCP報文段后，再釋放連接，然后又不斷地建立

19、新的連接、傳送報文段和釋放連接。(2) 假定每一次建立連接時，主機A都選擇相同的、固定的初始序號，例如，選擇1。(3) 假定主機A發(fā)送出的某些TCP報文段在網絡中會滯留較長的時間，以致造成主機A超時重傳這些TCP報文段。(4) 假定有一些在網絡中滯留時間較長的TCP報文段最后終于到達了主機B，但這時傳送該報文段的那個連接早已釋放了，而在到達主機B時的TCP連接是一條新的TCP連接。這樣，工作在新的TCP連接下的主機B就有可能會接受在舊的連接傳送的、已經沒有意義的、過時的TCP報文段（因為這個TCP報文段的序號有可能正好處在現在新的連接所使用的序號范圍之中）。結果產生錯誤。因此，必須使得遲到的T

20、CP報文段的序號不處在新的連接中所使用的序號范圍之中。這樣，TCP在建立新的連接時所選擇的初始序號一定要和前面的一些連接所使用過的序號不一樣。因此，不同的TCP連接不能使用相同的初始序號。F問題5-15：能否利用TCP發(fā)送端和接收端交換報文段的圖來說明慢開始的特點？答：慢開始的特點可以用下圖來說明。擁塞窗口cwnd的初始值是1（為方便起見，這里將擁塞窗口的單位設為報文段）。以后每收到一個對新的報文段的確認，就將發(fā)送端的擁塞窗口cwnd加1?？梢钥闯?，擁塞窗口cwnd按照指數規(guī)律增長。所謂“新的報文段”就是指“未被確認過的報文段”。由于報文段在因特網中傳輸時，有可能在某個路由器處滯留一段時間，但

21、以后又被交付到接收端（重復交付）。接收端對每一個收到的無差錯的報文段都可能給出確認。因此，對同一個報文段，發(fā)送端有可能收到幾個重復的確認。但除了第一個確認可以使發(fā)送端擁塞窗口cwnd加1以外，對其余重復的報文段的確認都不能再使發(fā)送端擁塞窗口加1。F問題5-16：對于擁塞避免是否也能夠用發(fā)送端和接收端交換的報文段來說明其工作原理？答：可以，但這只能是示意圖。因為在擁塞避免的開始，發(fā)送端的擁塞窗口swnd = ssthresh，這時可以發(fā)送好幾個報文段。按照RFC 2581文檔，每經過一個往返時間RTT，擁塞窗口就增加一個MSS的大?。ㄒ宰止?jié)為單位）。在我們討論原理時，以報文段個數作為窗口單位較為

22、方便，因此在圖中每經過一個RTT，發(fā)送端擁塞窗口swnd就在ssthresh的基礎上加1。在圖中將發(fā)送端發(fā)送報文段用一個粗箭頭表示（因為這里面包含有許多個報文段，很難一個個畫出），確認報文段也用一個粗箭頭表示（這也可能有許多個確認報文段），因此RTT也是概念性的往返時間。 正因為RTT無法很嚴格地畫出，因此在圖中左邊增加一個注釋，即“收到對所有報文段的確認”。這里假定收到對所有報文段的確認所需的時間就是RTT。F問題5-17：TCP連接很像一條連接發(fā)送端和接收端的雙向管道。當TCP在連續(xù)發(fā)送報文段時，若要管道得到充分的利用，則發(fā)送窗口的大小應怎樣選擇？答：我們可以用下面的圖來說明這一問題。圖中

23、在發(fā)送端和接收端之間的兩個白色長條表示TCP全雙工通信的發(fā)送管道和接收管道。管道是對信道的一種抽象，便于討論問題（可以不涉及下層互連網絡的細節(jié)）。假定在t = 0時發(fā)送端使用慢開始算法來發(fā)送報文段，因此在t = 0時只能發(fā)送一個報文段（圖中標有1的綠色長方條就代表報文段1）。圖中的時間都是按離散的時間單位表示。為簡化分析，我們還假定，發(fā)送窗口僅由發(fā)送端的擁塞窗口來確定，接收端不對發(fā)送窗口加以限制。假定在t = 1時，報文段1的第一個比特正好走完四分之一的管道，同時該報文段的最后一個比特正好發(fā)送完畢。t = 4，報文段1的前沿到達接收端。t = 5時，接收端將報文段1接收完畢。假定接收端立即發(fā)送

24、確認報文段。我們所用的標記是：對報文段n的確認報文段我們用具有標記n的紅色小長方條表示。t = 9，對報文段1的確認的前沿到達發(fā)送端。t = 10，發(fā)送端將發(fā)送窗口加1變?yōu)?（可以發(fā)送報文段2和3），并開始發(fā)送報文段2（這一步圖中省略了，沒有畫出）。t = 11，報文段2走完發(fā)送管道的四分之一，發(fā)送端開始發(fā)送報文段3。t = 12，報文段2和3填滿發(fā)送管道的一半。t = 14，報文段2的前沿到達接收端。t = 15，接收端收完報文段2，并發(fā)送對報文段2的確認。t = 16，接收端收完報文段3，并發(fā)送對報文段3的確認。t = 19，對報文段2的確認前沿傳播到發(fā)送端。t = 20，發(fā)送端收到對報文

25、段2的確認，將發(fā)送窗口加1變?yōu)?（可以發(fā)送報文段4, 5和6），并開始發(fā)送報文段4（這一步圖中省略了，沒有畫出）。對報文段3的確認的前沿也在這個時間傳播到發(fā)送端。再以后的過程我們用下面的另一張圖來說明。t = 21，發(fā)送端收到對報文段3的確認，將發(fā)送窗口再加1變?yōu)?（可以發(fā)送報文段4, 5, 6和7），并開始發(fā)送報文段5。此時，報文段4已完全進入發(fā)送管道，前沿到了管道的四分之一處。以后的過程讀者自己都可以看懂。這里只再提幾點。發(fā)送端每收到一個對沒有確認過的報文段的確認，就將發(fā)送窗口加1。因此在陸續(xù)收到確認4 7后，將發(fā)送窗口加4，即增大到8，可以連續(xù)發(fā)送報文段8 15。管道空間是有限的。從圖中

26、表示的例子可以看出，這樣的管道至多可容納4個報文段。當發(fā)送窗口很小時，管道在大部分時間內是比較空的（見前面的第一張圖）。這說明在TCP連接中傳輸數據的效率比較低。當發(fā)送窗口增大時，管道逐漸被填滿?？梢钥闯觯趖 = 34 38時，發(fā)送管道一直是被填滿的，這說明發(fā)送管道被利用得很充分。因為報文段的傳輸需要時間，因此對報文段的確認總是會滯后一段時間。上面的例子表明，在單方向發(fā)送報文段（另一個方向發(fā)送確認）的情況下，發(fā)送管道和接收管道往往不能同時被充分利用（除非發(fā)送窗口的數值較大）。但如果雙向都能發(fā)送數據報文段，那么發(fā)送管道和接收管道就都能夠被利用得較充分。我們還可看出，接收管道（即接收端發(fā)送確認報文段的管道）在任何情況下都沒有填滿。這是因為確認報文段很短，只需很短的時間就可發(fā)送出去。但接收一個數據報文段需要較多的時間，這就造成確認報文段不可能連續(xù)地從接收端發(fā)送出去。F問題5-18：假定在一個互聯網中，所有的鏈路的傳輸都不出現差錯，所有的結點也都不會發(fā)生故障。試問在這種情況下，TCP的“可靠交付”的功能是否就是多余的？答：不是多余的。TCP的“可靠交付”功能在互聯網中起著至關重要的作用。至少在以下所列舉的情況下，TCP的“可靠交付”功能是必不可少的。(1) 每個IP數據報獨立地選擇路由，因此在到達目的主機時有可能出現失序。(2) 由于路由選擇的計算出現