计算机网络第七版(谢希仁)第五章——传输层课后习题答案（上）
文章目錄
- 5-01
- 解答
- 5-02
- 解答
- 5-03
- 解答
- 5-04
- 解答
- 5-05
- 解答
- 5-06
- 解答
- 5-07
- 解答
- 5-08
- 解答
- 5-09
- 解答
- 5-10
- 解答
- 5-11
- 解答
- 5-12
- 解答
- 5-13
- 解答
- 5-14
- 解答
- 5-15
- 解答
- 5-16
- 解答
- 5-17
- 解答
- 5-18
- 解答
- 5-19
- 解答
- 5-20
- 解答
- 5-21
- 解答
- 5-22
- 解答
- 5-23
- 解答
- 5-24
- 解答
- 5-25
- 解答
- 5-26
- 解答
- 5-27
- 解答
- 5-28
- 解答
- 5-29
- 解答
- 5-30
- 解答
- 5-31
- 解答
- 5-32
- 解答
5-01
試說明運輸層在協議棧中的地位和作用。運輸層的通信和網絡層的通信有什么重要的區別?為什么運輸層是必不可少的?
解答
5-02
網絡層提供數據報或虛電路服務對上面的運輸層有何影響?
解答
5-03
當應用程序使用面向連接的TCP和無連接的IP時，這種傳輸是面向連接的還是無連接的?
解答
5-04
試畫圖解釋運輸層的復用。畫圖說明許多個運輸用戶復用到一條運輸連接上，而這條運輸連接又復用到IP數據報上。
解答
5-05
試舉例說明有些應用程序愿意采用不可靠的UDP，而不愿意采用可靠的TCP。
解答
5-06
接收方收到有差錯的UDP用戶數據報時應如何處理?
解答
簡單地丟棄
5-07
如果應用程序愿意使用UDP完成可靠傳輸，這可能嗎?請說明理由。
解答
解答:這是可能的，但這要由應用層自己來完成可靠傳輸。例如，應用層自己使用可靠傳輸協議。當然，這還是需要相當大的工作量的。
5-08
為什么說UDP是面向報文的，而TCP是面向字節流的?
解答
解答:發送方的UDP對應用程序交下來的報文，在添加首部后就向下交付IP層。UDP對應用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。這就是說，應用層交給UDP多長的報文，UDP就照樣發送，即一次發送一個報文，如教材的圖5-4所示。在接收方的UDP，對IP層交上來的UDP用戶數據報，在去除首部后就原封不動地交付上層的應用進程。也就是說，UDP一次交付一個完整的報文。因此，應用程序必須選擇合適大小的報文。若報文太長，UDP把它交給IP層后，IP層在傳送時可能要進行分片，這會降低IP層的效率。反之，若報文太短，UDP把它交給IP層后，會使IP數據報的首部的相對長度太大，這也降低了IP層的效率。
5-09
端口的作用是什么?為什么端口號要劃分為三種?
解答
解答:端口是用來標志進程的。端口也就是協議端口號。但這種在協議棧層間的抽象的協議端口是軟件端口，和路由器或交換機上的硬件端口是完全不同的概念。硬件端口是不同硬件設備進行交互的接口，而軟件端口是應用層的各種協議進程與運輸實體進行層間交互的一種地址。不同的系統，具體實現端口的方法可以是不同的（取決于系統使用的操作系統)。TCP/IP的運輸層用一個16位端口號來標志一個端口。但端口號只具有本地意義，它只是為了標志本計算機應用層中的各個進程在和運輸層交互時的層間接口。在互聯網中不同的計算機中，相同的端口號是沒有關聯的。
兩個計算機中的進程要互相通信,不僅必須知道對方的IP地址(為了找到對方的計算機)，而且還要知道對方的端口號（為了找到對方計算機中的應用進程)。
端口號有三種。不同的端口類別有其特殊的用途。例如，客戶端是通信的發起方，而服務器是服務的提供方。它們對端口的使用要求是不同的。這三種端口號是:
(1)熟知端口號或系統端口號，數值為0~1023。這些數值可在網址 www.iana.org查到。IANA把這些端口號指派給了TCP/IP最重要的一些應用程序，讓所有的用戶都知道。
(2）登記端口號，數值為1024~49151。這類端口號是為沒有熟知端口號的應用程序使用的。使用這類端口號必須按照IANA規定的手續登記，以防止重復。
上面兩種端口號是服務器端使用的端口號。下面的一種是客戶端使用的端口號。
(3）短暫端口號，數值為49152~65535。這類端口號僅在客戶進程運行時才動態選擇，是留給客戶進程選擇暫時使用。
5-10
試說明運輸層中偽首部的作用。
解答
解答:所謂“偽首部”是因為這種偽首部并不是UDP用戶數據報或TCP報文段真正的首部。只是在計算檢驗和時，臨時添加在UDP用戶數據報或TCP報文段的前面，得到一個臨時的UDP用戶數據報或TCP報文段。檢驗和就是按照這個臨時的UDP用戶數據報或TCP報文段來計算的。偽首部既不向下傳送也不向上遞交，而僅僅是為了計算運輸層的檢驗和。
5-11
某個應用進程使用運輸層的用戶數據報UDP，然后繼續向下交給P層后，又封裝成IP數據報。既然都是數據報，是否可以跳過UDP而直接交給IP層﹖哪些功能UDP提供了但IP沒有提供?
解答
解答:IP數據報只能找到目的主機而無法找到目的進程。如果應用進程直接把數據交給下面的IP層，那么在傳送到對方IP層后，就只能交付目的主機，但不知道應當交付哪一個應用進程。UDP提供對應用進程的復用和分用功能，以及提供對數據部分的差錯檢驗。這些功能IP層沒有提供。
5-12
一個應用程序用UDP，到了IP層把數據報再劃分為4個數據報片發送出去。結果前兩個數據報片丟失，后兩個到達目的站。過了一段時間應用程序重傳UDP，而IP層仍然劃分為4個數據報片來傳送。結果這次前兩個到達目的站而后兩個丟失。試問:在目的站能否將這兩次傳輸的4個數據報片組裝成為完整的數據報?假定目的站第一次收到的后兩個數據報片仍然保存在目的站的緩存中。
解答
解答:不行。重傳時，IP 數據報的標識字段會有另一個標識符。僅當標識符相同的IP數據報片才能組裝成一個IP數據報。前兩個IP數據報片的標識符與后兩個IP數據報片的標識符不同，因此不能組裝成一個IP數據報。
5-13
一個UDP用戶數據報的數據字段為8192字節。在鏈路層要使用以太網來傳送。試問應當劃分為幾個IP數據報片﹖說明每一個IP數據報片的數據字段長度和片偏移字段的值。
解答
解答:UDP用戶數據報的長度=8192+8= 8200 B
以太網數據字段最大長度是1500 B。若IP首部為20 B，則IP數據報的數據部分最多只能有1480 B。8200= 1480×5+800，因此劃分的數據報片共6個。
數據字段的長度:前5個是1480字節，最后一個是800字節。第1個數據報片的片偏移字節是0。
第⒉個數據報片的片偏移字節是1480 B。
第3個數據報片的片偏移字節是1480 × 2 = 2960 B。第4個數據報片的片偏移字節是1480× 3=4440 B。第5個數據報片的片偏移字節是1480x4 = 5920 B。第6個數據報片的片偏移字節是1480 x5= 7400 B。
圖T-5-13給出了以上結果。
把以上得出的片偏移字節數除以8，就得出片偏移字段中應當寫入的的數值。因此最后的答案，片偏移字段的值分別是:0,185,370,555,740和925(字節數除以8)。
5-14
一個UDP用戶數據報的首部的十六進制表示是:06 32 00 45 00 1C E2 17。試求源端口、目的端口、用戶數據報的總長度、數據部分長度。這個用戶數據報是從客戶發送給服務器還是從服務器發送給客戶?使用UDP的這個服務器程序是什么?
解答
5-15
使用TCP對實時話音數據的傳輸會有什么問題?使用UDP 在傳送數據文件時會有什么問題?
解答
解答:對實時話音數據的傳輸是不能使用TCP的。這是因為用TCP傳輸話音數據時，只要一出現差錯或丟失，TCP就要重傳。這就產生了額外的時延，有時這種時延會達到很高的數值，使接收方無法容忍。在實時話音通信中，我們寧可丟掉幾個分組（這在重放時，還原的話音質量會差一些，但仍然可以聽懂)，也不愿意收到太遲來到的分組，因為這樣會使重放的話音質量嚴重惡化。雖然UDP不保證可靠交付，但UDP比TCP的開銷要小很多。因此只要應用程序接受這樣的服務質量就可以使用UDP。
如果話音數據不是實時播放（邊接收邊播放）就可以使用TCP，因為TCP傳輸可靠。接收端用TCP將話音數據接收完畢后，可以在以后的任何時間進行播放。但本題目假定是實時話音數據傳輸，因此必須使用UDP。
使用UDP傳送數據文件時，如果出現了差錯，UDP僅僅是少收了這個出錯的報文段，并不通知發送方重傳。這樣就不能保證正確地傳送數據。因此在傳送數據文件時，我們都是采用TCP來傳送的,
5-16
在停止等待協議中如果不使用編號是否可行?為什么?
解答
5-17
在停止等待協議中，如果收到重復的報文段時不予理睬（即悄悄地丟棄它而其他什么也不做）是否可行?試舉出具體例子說明理由。
解答
5-18
假定在運輸層使用停止等待協議。發送方發送報文段M后在設定的時間內未收到確認，于是重傳 M，但Mo又遲遲不能到達接收方。不久，發送方收到了遲到的對 M的確認，于是發送下一個報文段 M，不久就收到了對M的確認。接著發送方發送新的報文段 M，但這個新的 M在傳送過程中丟失了。正巧，一開始就滯留在網絡中的M現在到達接收方。接收方無法分辨M是舊的。于是收下Mo，并發送確認。顯然，接收方后來收到的M是重復的，協議失敗了。試畫出類似于圖5-9所示的雙方交換報文段的過程。
解答
5-19
試證明:當用n比特進行分組的編號時，若接收窗口等于1(即只能按序接收分組)，則僅在發送窗口不超過2”-1時，連續ARQ 協議才能正確運行。窗口單位是分組。
解答
解答:如圖T-5-19所示，設發送窗口記為W，接收窗口記為WR。假定用3比特進行編號。設接收窗口正好在7號分組處（有陰影的分組)。
發送窗口Wr的位置不可能比②的位置更靠前。因為接收窗口的位置表明接收方正等待接收7號分組，而這時的發送方不可能已經收到了對7號分組的確認。因此發送窗口必須包括7號分組，也就是不可能比②的位置更靠前（前方就是圖的右方)。
發送窗口Wr的位置也不可能比③的位置更靠后。因為接收窗口的位置表明接收方已經對6號分組(以及以前的分組)發送了確認。但如果發送窗口Wr的位置再靠后一個分組，即在6 號分組的左邊，那就表明還沒有發送6號分組。但接收窗口的位置表明接收方已經發送了對6號分組的確認。這顯然是不可能的。
5-20
在連續ARQ協議中，若發送窗口等于7，則發送端在開始時可連續發送7個分組。因此，在每一分組發出后，都要置一個超時計時器。現在計算機里只有一個硬時鐘。設這7個分組發出的時間分別為to, t,…, t6，且 tou都一樣大。試問如何實現這7個超時計時器（這叫軟時鐘法）?
解答
5-21
假定使用連續ARQ協議，發送窗口大小是 3，而序號范圍是[0，15]，而傳輸媒體保證在接收方能夠按序收到分組。在某一時刻，在接收方，下一個期望收到的序號是5。試問:
(1)在發送方的發送窗口中可能出現的序號組合有哪些?
(2)接收方已經發送出的、但在網絡中（即還未到達發送方）的確認分組可能有哪些?說明這些確認分組是用來確認哪些序號的分組。
解答
解答:分別回答如下:
(1)在接收方，下一個期望收到的序號是5。這表明序號到4為止的分組都已收到。若這些確認都已到達發送方，則發送窗口最靠前，其范圍是[5,7]。
假定所有的確認都丟失了，發送方都沒有收到這些確認。這時，發送窗口最靠后，應為[2,4]。因此，發送窗口可以是[2,4],[3，5],[4,6],[5,7]中的任何一個。
(2）接收方期望收到序號5的分組，說明序號為2,3,4的分組都已收到，并且發送了確認。對序號為1的分組的確認肯定被發送方收到了，否則發送方不可能發送4號分組。可見，對序號為2,3,4的分組的確認有可能仍滯留在網絡中。這些確認是用來確認序號為2,3,4的分組的。
5-22
主機A向主機B發送一個很長的文件，其長度為L字節。假定TCP使用的MSS為1460字節。
(1)在 TCP的序號不重復使用的條件下，L的最大值是多少?
(2)假定使用上面計算出的文件長度，而運輸層、網絡層和數據鏈路層所用的首部開
銷共66字節，鏈路的數據率為10 Mbit/s，試求這個文件所需的最短發送時間。
解答
5-23
主機A向主機B連續發送了兩個TCP報文段，其序號分別是70和100。試問:
(1)第一個報文段攜帶了多少字節的數據?
(2)主機收到第一個報文段后發回的確認中的確認號應當是多少?
(3)如果B收到第二個報文段后發回的確認中的確認號是180，試問A發送的第二個報文段中的數據有多少字節?
(4)如果A發送的第一個報文段丟失了，但第二個報文段到達了B。B在第二個報文段到達后向A發送確認。試問這個確認號應為多少?
解答
解答:分別求解如下:
(1)第一個報文段的數據序號是70到99，共30字節的數據。
(2)B期望收到下一個報文段的第一個數據字節的序號是100，因此確認號應為100。
(3)A發送的第二個報文段中的數據中的字節數是180- 100= 80字節。
(4)B在第二個報文段到達后向A發送確認，其確認號應為70。
5-24
一個TCP連接下面使用256 kbit/s的鏈路，其端到端時延為128 ms。經測試，發現吞吐量只有120 kbit/s。試問發送窗口W是多少?(提示:可以有兩種答案，取決于接收端發出確認的時機。)
解答
解答:設發送窗口=W(bit)，再設發送端連續發送完窗口內的數據所需的時間=T。有兩種情況:
(a)接收端在收完一批數據的最后才發出確認，因此發送端經過(256 ms + T)后才能發送下一個窗口的數據。
(b)接收端每收到–個很小的報文段后就發回確認，因此發送端經過比256 ms略多一些的時間即可再發送數據。因此每經過256 ms就能發送一個窗口的數據。
5-25
為什么在TCP首部中的要把TCP的端口號放入最開始的4個字節?
解答
解答:在ICMP的差錯報文中(見教材的圖4-28)要包含IP首部后面的8個字節的內容，而這里面有TCP首部中的源端口和目的端口。當TCP收到ICMP差錯報文時，需要用這兩個端口來確定是哪條連接出了差錯。
5-26
為什么在TCP首部中有一個首部長度字段，而UDP的首部中就沒有這個字段?
解答
解答:TCP首部除固定長度部分外，還有選項，因此TCP首部長度是可變的。UDP首部長度是固定的，不需要這個字段。
5-27
一個TCP報文段的數據部分最多為多少個字節?為什么?如果用戶要傳送的數據的字節長度超過TCP報文段中的序號字段可能編出的最大序號，問還能否用TCP來傳送?
解答
解答:一個TCP報文段的數據部分最多為65495字節。數據部分加上TCP首部的20字節，再加上IP首部的20字節，正好是IP數據報的最大長度65535字節。當然，若IP首部包含了選項，則IP首部長度超過20字節，這時TCP報文段的數據部分的長度將小于65495字節。
如果用戶要傳送的數據的字節長度超過TCP報文段中的序號字段可能編出的最大序號，仍可用TCP來傳送。編號用完后再重復使用。但應設法保證不出現編號的混亂。
5-28
主機A向主機B發送TCP報文段，首部中的源端口是m而目的端口是n。當B向A發送回信時，其TCP報文段的首部中的源端口和目的端口分別是什么?
解答
解答:當B向A發送回信時，其TCP報文段首部中的源端口就是A發送的TCP報文段首部中的目的端口n，而B發送的TCP報文段首部中的目的端口就是A發送的TCP報文段首部中的源端口m。
5-29
在使用TCP傳送數據時，如果有一個確認報文段丟失了，也不一定會引起與該確認報文段對應的數據的重傳。試說明理由。
解答
還未重傳就收到了對更高序號的確認。
5-30
設TCP使用的最大窗口為65535字節，而傳輸信道不產生差錯，帶寬也不受限制。若報文段的平均往返時間為20 ms，問所能得到的最大吞吐量是多少?
解答
解答:在發送時延可忽略的情況下，每 20 ms可發送65535×8= 524280 bit最大數據率 =(524280 bit)/ (20 ms) 約等于26.2 Mbit/s。
5-31
通信信道帶寬為1 Gbit/s，端到端傳播時延為10 ms。TCP的發送窗口為65535字節。試問:可能達到的最大吞吐量是多少?信道的利用率是多少?
解答
5-32
什么是Karn算法？在TCP的重傳機制中，若不采用Karn 算法，而是在收到確認時都認為是對重傳報文段的確認，那么由此得出的往返時間樣本和重傳時間都會偏小。試問:重傳時間最后會減小到什么程度?
解答
解答:Karn算法允許 TCP 能夠區分開有效的和無效的往返時間樣本，從而改進了往返時間的估算。
若不采用Karn 算法，而是在收到確認時都認為是對重傳報文段的確認，那么由此得出的往返時間樣本和重傳時間都會偏小。如圖T-5-32所示，TCP發送了報文段后，沒有收到確認，于是超時重傳報文段。但剛剛重傳了報文段后，馬上就收到了確認。顯然，這個確認是對原來發送的報文段的確認。
但是，根據題意，我們就認為這個確認是對重傳的報文段的確認。這樣得出的往返時間就會很小。這樣的往返時間最后甚至可以減小到很接近于零。
因此，上述的這種做法是不可取的。
對于計算機網絡的課后習題我都做了一遍，這里就不再放我的解答過程了，直接給大家展示標準答案，如有不懂，可評論私信，我一定解答，后續還會堅持更新完…
總結
以上是生活随笔為你收集整理的计算机网络第七版(谢希仁)第五章——传输层课后习题答案（上）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 韩家炜
- 下一篇： Visual Studio 2008 S