計算機網絡(謝希仁 第七版)運輸層 課后習題解析


第五層 運輸層課后習題答案

1. 試說明傳輸層在協議棧中的地位和作用,傳輸層的通信和網絡層的通信有什么重要區別?為什么說傳輸層是必不可少的?

答:

地位:傳輸層處於面向通信部分的最高層,同時也用戶功能中的最底層

作用:向它上面的應用層提供服務,向下兼容網絡層,起到承上啟下的中間作用

重要區別:傳輸層為應用層的應用程序提供端到端的邏輯通信,該邏輯鏈路是虛擬的

,而網絡層是為主機之間提供邏輯通信的(面向主機,承擔路由功能)

必不可少的原因:各種應用進程之間通信需要“可靠交付”和“盡最大努力交付”的

類服務,必須要又傳輸層以復用和分用的形式加載到網絡層才能實現這兩種類型的通信

2. 網絡層提供數據報或虛電路服務隊上面的傳輸層有何影響?

答:不管是網絡層提供數據報還是虛電路服務,隊上面運輸層的運行機制都不會有任何影響,但是會給運輸層提供不同質量的服務

3. 當應用程序使用面向連接的TCP和無連接的IP時,這種傳輸的面向連接的還是面向無連接的?(無連接的IP:IP協議,面向無連接,跟UPD一樣)

答:都有,這要在不同層次來看,在運輸層是面向連接的,在網絡層則是面向無連接的

4. 試用畫圖解釋運輸層的復用,畫圖說明許多個運輸用戶復用到一條運輸連接上,而這條運輸連接又復用到IP數據報上

答:許多個運輸用戶復用到一條運輸連接上:通過不同的端口號(不同應用程序不同端口號)

這條運輸連接又復用到不同的IP數據報上:不同的協議號,UDP-17,TCP-6,UPD在IP報文的協議號是17

wps72D5.tmp

5. 舉例說明有的應用程序寧願采用不可靠的UDP,而不采用可靠的TCP

答:視頻播放程序,可以忍受不可靠的UDP丟失掉一兩幀的圖,不會影響視頻服務的質量,但是不能忍受可靠的TCP的,因為TCP雖然可靠但是傳輸速率慢

原理:有差錯的數據報UDP直接丟棄,而TCP則要求重傳,TCP會帶來較大的時延

6. 接收方收到有差錯的UDP用戶數據報應如何處理?

答:直接丟棄

7. 如果應用程序寧願使用UDP來完成可靠的傳輸,這可能嗎?請說明理由

答:可能,但應用程序中必須額外提供於TCP相同的功能

8. 為什么說UDP是面向報文的,而TCP是面向字節的?

答:UDP是面向報文的:發送方的UDP對應用程序交下來的報文,在添加了首部之后就向下交付,UDP對應用層交付下來的報文即不合並也不拆分,而是保留這些報文的邊界,應用層交給UDP多長的報文,UDP就照樣發送,即一次發送一個報文,接收方UDP對下方交上來的UDP用戶數據報,在去除首部之后就原封不動的交付給上層的應用程序,一次交付一個完整報文,所以是UDP是面向報文的

TCP是面向字節的:發送方TCP對應用程序交下來的報文數據塊,視為無結構的字節流(無邊界約束,可拆分/合並),但維持各字節流順序(相對順序沒有變),TCP發送方有一個發送緩沖區,當應用程序傳輸的數據塊太長,TCP就可以把它划分端一些再傳輸,如果應用程序一次只傳輸一個字節,那么TCP可以等待積累足夠多的字節后再構成報文端發送出去,所以TCP的面向字節的

9. 端口的作用是什么?為什么端口要划分三種?

答:端口的作用是對TCP/IP體系的應用進程進行統一的標志,使運行不同操作系統的計算機能夠相互通信

熟知端口號:數值一般為0~1023,標記常規的服務進程如FTP是21,DNS是53,HTTP是80等

登記端口號:數值為1024~49151,標記沒有熟知端口號的非常規的服務進程

短暫端口號:數值為49152~65535,客戶進程運行時動態選擇

10. 試說明運輸層中偽首部的作用

答:僅用於計算運輸層數據報的校驗和

11. 某個應用進程使用運輸層的UDP用戶數據報,然而繼續向下交付給IP層之后,又封裝成IP數據報,既然都是數據報,可否跳過UDP而直接交給IP層?哪些功能UDP提供了但IP沒有提供?

答:不可以跳過UDP而直接交給IP層,IP數據報的IP報頭承擔主機尋址,報頭檢錯,直接交付給IP層只能找到目的主機而無法找到目的進程

UDP提供對應用進程的復用和分佣功能,以及提供對數據的差錯檢驗

12. 一個應用程序用UDP,到了IP層把數據報划分偽4個數據報片發送出去,結果前兩個數據報丟失,后兩個到達目的站,過了一段時間應用程序重傳UDP,而IP層仍然划分為4個數據報片來發送,結果這次前兩個到達后兩個丟失,試問,在目的站能否將這兩次傳輸的4個數據報片組合成一個完整的數據報?假定目的站第一次收到后的兩個數據報片仍然1保存在目的站的緩存中。

答:不行,數據報片丟失重傳時,IP數據報的標識字段會又另一個標識符,僅當標識符相同的IP數據報片才能組成一個IP數據報,前兩個IP數據報片的標識符和后兩個IP數據報片的IP標識符不同,使用不能組成一個IP數據報

補充:因為IP協議是無連接的服務,所以數據報不存在按序接收到達的問題,當數據報由於長度超過網絡的最大傳輸單元MTU而必須分片時,該數據報的標識字段就被復制到該數據報的所有數據報分片中,相同的標識字段的值可以使得分片后的數據報片能正確的重裝成原理的數據報

13. 一個UDP用戶數據報的數據字段為8192個字節,在數據鏈路層要使用以太網來傳送,試問應該划分為幾個IP數據報片?說明每一個IP數據報字段長度和片偏移字段的值。

答:6個,8192字節加上UDP首部8字節共8200字節

數據字段的長度:前面5個是1480字節,最后一個是800字節

片偏移字段的值分別是:0,1480,2960,4440,5920,7400

補充:

UDP數據報首部長度為8個字節

UDP數據報數據部分+UDP數據報首部=IP數據報的數據部分

所以IP數據報的數據部分長度=8192字節+8字節=8200字節

IP數據報的數據部分+IP數據報的首部=一個完整的IP數據報

IP數據報的首部是20個字節

一個完整的IP數據報的最大長度是1500字節

所以IP數據報的數據部分最大長度是1500-20=1480字節

1480*5+800=8200字節

所以至少需要6個IP數據報片

偏移值分別是:1480*0,1480*1,1480*2,1480*3,1480*4,1480*5

14. 一UDP用戶數據報的首部十六進制表示是:06 32 00 45 00 1C E2 17 ,試求源端口,目的端口,用戶數據報的總長度,數據部分長度,這個用戶數據報是從客戶發送給服務器還是服務器發送給用戶?使用這個UDP的這個服務器程序是什么?

答:源端口:1586,目的端口:69,UDP用戶數據報總長度:28字節,數據部分長度:20字節,此UDP用戶數據報是從客戶發送給服務器(因為目的端口<1023,是熟知端口1),服務器程序是TFTP

補充:UDP首部結構(8字節):源端口(2字節)+目的端口(2字節)+UDP數據報總長度(2字節)+校驗和(2字節)

十六進制0632  ---> 十進制1586

十六進制0045  ---> 十進制 69

十六進制1C    ---> 十進制 28

所以該用戶數據報UDP的數據部分長度是28-8=20字節

69端口是TFTP的端口

15. 使用TCP對實時話音數據的傳輸有沒有什么問題?使用UDP在傳送數據文件時會有什么問題?

答:如果話音數據不是實時播放(邊接收邊播放)就可以使用TCP,因為TCP傳輸可靠,接收端用TCP接收數據完畢之后,可以在任何時間進行播放,但階段是實時播放,則必須使用UDP,UDP不保證可靠交付,但UDP比TCP的開銷小很多,一次只要應用程序接受這樣的服務質量就可以選擇使用UDP

16. 在停止等待協議中如果不使用編號是否可行?為什么?

答:不行,分組和確認分組都必須進行編號,才能明確哪個分組得到了確認

補:停止等待協議是TCP可靠傳輸的保證之一

17. 在停止等待協議中,如果收到重復的報文段時不予理睬(即悄悄丟棄什么也不做)是否可行?舉例說明

答:不可以,收到重復報文不確認相當於丟失,會讓發送方以為你沒有收到而一直發送該重復報文

18.假定在運輸層使用停止等待協議,發送方在發送報文段M0后在設定時間未收到確認,於是重傳M0,但是M0又遲遲不能到達接收方,不久發送方收到了遲到的對M0的確認,於是發送下一個報文M1,不僅就收到了對M1的確認,接着發送方發送新的報文段M0(和前面的M0不同)但這個新的M0的傳送過程中丟失了,正巧,一開始就滯留在網絡中的M0現在到達接收方,接收方無法分辨M0是舊的,於是收下了M0,並發送確認,顯然,接收方后來收到的M0是重復,協議失敗了,請畫圖描述上述過程

答:

wps72D6.tmp

19.試證明:當用n比特進行分組的編號時,若接收窗口等於1(即只能按序接收分組),當僅在發送窗口不超過2的n次方然后減去1時,連續滑動窗口協議才能正確運行,窗口單位是分組

答:

wps72D7.tmp

20. 在連續ARQ協議中,若發送窗口等於7,則發送端在開始時可連續發送7個分組,因此,在每一組發送之后,都要設置一個超時計時器,現在計算機里之一一個硬時鍾,設這7個分組發出的時間為t0~t6,且超時時間Tout一樣大,試問如何實現這7個超時計時器(軟件時鍾法)?

答:

wps72D8.tmp

補充:方法2:可以定義一個含有7個數據的數組,數組中的數據表示時間,當該組數據發送出去時,在對應序號的數組中填入時間值,該時間值是該組發送出去的時間+超時時間得到,如何不停的對該數組的值進行掃描,當接收到接收端的確認分組時,即將對應數組序號的時間值設置為空,准備記錄下一個數據發發送時間,當系統時間大於數組中某一個時間值時,說明該分組以及超時了,需要進行重傳

21. 假設使用連續ARQ協議中,發送窗口大小是3,序列范圍是[0,15],而傳送媒體保證在接收方能接收到分組,在某時刻,在接收方,下一個期望收到的序號是5

試問:

1)在發送方的發送窗口中你可能出現的序號組合有哪幾種?

答:如果發送方沒有收到[2,4]的確認,那么發送窗口的范圍是:[2,4],[3,5],[4,6],[5,7]中如何一個

如果發送方收到了[2,4]的確認,那么發送窗口的范圍是:[5,7]

2) 接收方已經發送出去的,但在網絡中(未到達發送方)的確認分組可能有那些?說明這些確認分組是用來確認那些序號的分組

答:[2,4]分組的確認可能還在網絡中

22. 主機A向主機B發送一個很長的文件,其長度為L字節,假定TCP使用的MSS有1460字節

1)在TCP的序號不重復使用的條件下,L的最大值是多少?

答:FAT單個文件不能超過4G,2^32=4G,1G=2^30字節,所以L_max=2^62字節

3) 假定使用上面計算出的文件長度,而運輸層,網絡層和數據鏈路層所使用的首部開銷共66字節,鏈路的數據率為10Mb/s,試求這個文件所需要的最短發送時間

答:滿載分片數Q={L_max/MSS}取整=2941758次

總字節數N=Q*(MSS+66)+{(L_max-Q*MSS)+66}=4489122708+682=4489123390字節

最小時間T=N*8/(10*10^6)=3591.3秒=59.85分 約等於1小時

補充:MSS:TCP最大報文段長度

最后剩余要發送的字節不足MSS所以要取整

1個字節是8個比特

1Mb=10^6 b

23. 主機A向主機B連續發送了兩個TCP報文段,其序號是70和100,問:

1) 第一個報文段攜帶了多少個字節?

答:

TCP報文段的序號:發送數據段的首字節編號

70~99有30個字節,所以第一個報文段攜帶了30個字節

2)主機B收到第一個報文段后發回的確認中確認序號應當是多少?

答:

TCP報文段的確認號:期望下一次收到的字節的序號

所以該確認序號是100

3)如果主機B收到第二個報文段后發揮確認中的確認序號是180,試問A發送的第二個報文段中的數據有多少字節?

答:

確認序號是180,說明它期望下次收到180編號的字節,那么180以前的就已經收到了,即100~179,80個字節

4) 如果A發送的第一個報文段丟失了,單第二個報文段到達了B,B在第二個報文段到達后向A發送確認,試問這個確認號應該是多少?

答:70,因為第一個報文段的丟失,需要重傳

24. 一個TCP連接下面使用256kb/s的鏈路,其端到端時延為128ms,經測試,發現吞吐量只有120kb/s,試問發送窗口w是多少?(提示:可以有兩種答案,取決於接收等發出確認的時機)

答:來回路程的時延等於128*2=256ms

設窗口值為x(以字節為單位),假定一次最大發送量等於窗口值,且發送時間等於255ms,那么每發送一次都得停下來期待再次得到下一窗口的確認,以得到新的發送許可,這樣發送時間等於停止等待應答的時間,結果,測到的平均吞吐率就等於發送速率的一半,即:

8*x/(256*1000)=256*0.001

X=8192

補充:一個字節8個比特

256ms=256*0.001s

速率=256*1000 b/s

25. 為什么在TCP首部中要把TCP端口號放入最開始的4個字節?

答:在ICMP的差錯報文中要包含IP首部后面8個字節的內容,而這里面有TCP首部中的源端口和目的端口,當TCP收到ICMP差錯報文時需要用這兩個端口來確定是哪條連接出了差錯

26. 為什么在TCP首部中有一個首部長度字段,而UDP的首部中就沒有首部長度字段?

答:TCP首部除固定長度部分外,還有選項,TCP首部長度是可變的,所以需要首部長度字段,而UDP的首部長度是固定的,不需要

27. 一個TCP報文段的數據部分最多為多少個字節?為什么?如果用戶要傳送的數據的字節長度超過TCP報文字段中的序號字段可能編出的最大序號,問還能否用TCP來傳送?

答:65535-20-20=65495字節,此數據部分加上TCP首部的20字節,然后加上IP首部的20字節,正好是IP數據報的最大長度:65535字節(當然若IP首部包含了選填字段,則IP首部的長度超過20字節,這時TCP報文端的數據部分的長度將小於65495字節),數據的字節長度超過TCP報文字段中序號字段可能編出的最大序號,通過循環使用序號,仍然可以使用TCP來傳送

28. 主機A向主機B發送TCP報文段,首部中的源端口是m而且目的端口是n,當B向A發送回信時,其TCP報文段的首部中源端口和目的端口分別是什么?

答:n和m

29. 在使用TCP傳送數據時,如果有一個確認報文段丟失了,也不一定會引起與該確認報文對應的數據的重傳,試說明理由

答:還沒有重傳就收到了對更高序號的確認

30. 設TCP使用的最大窗口為65535字節,而傳輸信道不產生差錯,帶寬也不受限制,若報文段的平均往返時延為20ms,問所能得到的最大吞吐率是多少?

答:在發送時延可忽略的情況下:最大數據率=最大窗口*8/平均往返時間=26.2Mb/s

31. 通信信道的帶寬為1GB/s,端到端的時延為10ms,TCP的發送窗口為65535字節,試問:可能達到的最大吞吐率是多少?信道的利用率是多少?

答:傳輸的比特L=65536*8+40*8=52408b 帶寬c=10^9 b/s

發送時延 L/c=0.000524608 s

傳輸時延 Td=10*10^-3 s

最大吞吐率=傳輸的比特數/(發送時延+2倍的傳輸時延)=25.6Mb/s

信道利用率=發送時延/(發送時延+2倍的傳輸時延)=2.55%

補充:0-65535,所以是65536,乘以8是因為一個字節8個比特,40是因為TCP首部20個字節+IP首部20個字節,發送時延+2倍的傳輸時延是因為先發出去,然后傳輸到接收方,然后接收方發送一個確認信號才算完成了此次傳輸

32. 什么是karm算法?在TCP的重傳機制中,若不采用karm算法,而是在收到確認時都認為是對重傳報文端的確認,那么由此得出的往返時延樣本和重傳時間都會減小,試問:重傳時間最后會減小到什么程度?

答:karm算法:在計算平均往返時延RTT時,只要該報文段重傳了,就不采用其往返延時樣本

超時重傳時間RTO=RTTs+4*RTTd 其中RTTd是RTTs的偏差加權均值

wps72E9.tmp

33. 假定TCP在開始建立連接時,發送方設定的超時重傳時間是RTO=6s

1)當發送方接收到對方的連接確認報文時,測量出RTT(平均往返時延)樣本值為1.5s,試計算限制的超時重傳時間RTO

2)當發送方發送數據報文段並接收到確認時,測量出RTT樣本值為2.5s,試計算限制的RTO值

答:

wps72EA.tmp

34. 已知第一次測得TCP的往返時延的當前值是30ms,現在收到了三給連接的確認報文段,他們相比的數據報文段的發送時間分別滯后26ms,32ms,和24ms,設a=0.9,試計算每一層新的加權平均往返時間值RTTs,討論所得結果

答:a=0.1,RTTO=20

wps72EB.tmp

RTT1=RTTO*(1-a)+26*a=29.6

RTT2=RTT1*a_32(1-a)=29.84

RTT3=RTT2*a+24(1-a)=29.256

可以看出,RTT的樣本值變化多達20%,加權平均往返時間RTTs的變化卻很小

35. 試計算一個包括5段鏈路的運輸連接的單程段到端的延時,5端鏈路程中有2端是衛星鏈路,有3段是廣域網鏈路,每條衛星鏈路又由上行鏈路和下行鏈路兩部分組成,可以去這兩部分的傳播時延之和為250ms,每一個廣域網的范圍為1500km,其傳播時延可按150000km/s來計算,各數據鏈路速率為48kb/s,幀長為960位

答:總的傳播時延=信道長度/傳播速率=250*2+(1500/150000)*3*1000=530 ms

總的發送時延=960/(48*1000/1000)*5=100ms

單程端到端時延=100ms+530ms=630ms

36. 重復35題,假定其中一個陸地上的廣域網的發送時延為150ms

答:

總的傳播時延沒有變化,還是530ms

總的發送時延=960/(48*1000/1000)*4+150=230ms

端到端的時延=530+230=760ms

37. 在TCP的擁塞控制中,什么是慢開始,擁塞避免,快重傳和快恢復算法?這里每一種算法各起什么作用?乘法減小和加法增大各用在什么情況下?

答:

慢開始:在主機剛剛開始發送報文段時先將擁塞窗口cwnd設置為一個最大報文段的MSS數值,在每收到一個對新的報文端的確認后,將擁塞窗口增加至多一個MSS數值,用這樣的方法逐步增大發送端的擁塞窗口cwnd,即逐步增加發送窗口的大小,可以分組注入到網絡中的速率更加合理

擁塞避免:當擁塞窗口值(現在是等於發送窗口大小)大於慢開始門限時,停止使用慢開始算法,而改用擁塞避免算法:使發送的擁塞窗口每經過一個往返時延RTT就增加一個MSS的大小

快重傳算法:發送端只要連續收到三個重復的ACK,就斷定有分組丟失了,就理解重傳丟失的報文段而不是等待該報文段的超時計時器超時

快恢復算法:當發送端連續收到三個重復的ACK時,就重新設置慢開始門限ssthresh(當前擁塞窗口的一半)與慢開始不同之處在於擁塞窗口cwnd不是設置為1,而是設置為新的慢開始啟動門限(當前擁塞窗口的一半)

乘法減小:是指無論在慢開始階段還是在擁塞避免階段,只要出現超時(即很有可能出現了網絡擁塞),就是把慢開始門限值ssthresh設置為當前擁塞窗口值的一半,當網絡頻繁出現擁塞時,ssthresh值就下降得很快,以大大減少注入到網絡中的分組數

加法增大:是值指向擁塞避免算法之后,在收到度所有報段的確認后(即經過一個往返時間)就把擁塞控制窗口cwnd增加一個MSS大小,使得擁塞窗口緩慢增大,以防止網絡過早的出現擁塞

38. 設TCP的ssthresh的初始值為8,當擁塞窗口上升到12時網絡發送了超時,TCP使用慢開始和擁塞避免,試求出第一次到第15此的擁塞窗口大小

答:1 2 4 8 9 10 11 12 1 2 4 6 7 8 9

                    *        *

Ssthresh在12之后變成了6,然后又是從1開始,快到6就采用擁塞控制

39. TCP在進行流量控制時是以分組的丟失作為產生擁塞的標志的,有沒有不是因為擁塞而引起的丟失分組的情況?如果有,請舉3個例子

答:1.當IP數據報的傳輸過程中需要分片,但其中的一個數據報未能及時到達終點,而終點組裝IP數據報已超時,因而只能丟失該數據報

2. IP數據報已經到達終點,但終點的緩存沒有足夠的空間來存放此數據報

3. 數據報在轉發的過程中經過一個局域網的網橋,但網橋在轉發該數據報的幀沒有足夠的差錯空間而只好丟棄

41.用TCP傳送512字節的數據,設窗口為100字節,而TCP報文段每次也是傳送100字節的數據,再設發送端和接收端的起始序號分別為100和200,試畫出連接建立到連接釋放的工作示意圖

答:

44試舉例說明為什么一個運輸連接可以有多種方式釋放,可以設兩個互相通信的用戶分別連接在網絡的兩個結點上

答:假設A,B建立了運輸連接,協議應該考慮實際的可能性

比如:

A或者B故障,應該設置超時機制,使對方推出,不至於死鎖

A主動退出,B被動退出

A被動退出,B主動退出

45. 試接收為什么突然釋放運輸連接就有可能丟失用戶數據,而使用TCP的連接釋放方法就可以保證數據不丟失?

答:當主機1和主機2之間建立連接后,主機1發送了一個TCP數據段並且正確抵達主機2,接着主機1發送另外一個TCP數據段,這次很不幸,主機2在收到第二個TCP數據段之前發出了釋放連接的請求,如果就這樣突然釋放連接,顯然主機1發送的第二個TCP報文段會丟失,而使用TCP的連接釋放方法,主機2發出了釋放連接的請求,那么即使收到主機1的確認后,之間釋放主機2到主機1的連接,即主機2不再向主機1發送數據,而仍然可以接受主機1發送來的數據,所以可以保證數據不丟失

46. 試用例子說明為什么在運輸連接建立時要使用三次握手。說明不這樣做可能會出現什么情況

答:3次握手完成兩個重要功能,既要雙方做好發送數據的准備工作(雙方都知道彼此已經准備好),也要運行雙方就初始序列號進行協商,這個序列號在握手過程中被發送和確認。

假定B決定給A發送一個連接請求分組,A收到了分組,並發送了確認分組,按照兩次握手的協定,A認為連接已經成功建立了,可以開始發送數據分組,可是B在A的應答分組在傳輸中被丟失的情況下,將不知道A是否已經准備號,不知道A建議什么樣的序列號,B甚至懷疑A是否收到了自己的請求連接分組,在這種情況下還未建立成功,將忽略A發送過來的任何數據,只等待連接確認分組

而A發送的分組超過之后,重復發送同樣的分組,這樣就形成了死鎖


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM