計算機網絡謝希仁第七版 第五章 答案

計算機網絡謝希仁第七版 第五章 傳輸層

5—01 試說明運輸層在協議棧中的地位和做用，運輸層的通訊和網絡層的通訊有什麼重要區別？爲何運輸層是必不可少的？

答：運輸層處於面向通訊部分的最高層，同時也是用戶功能中的最低層，向它上面的應用層提供服務     運輸層爲應用進程之間提供端到端的邏輯通訊，但網絡層是爲主機之間提供邏輯通訊（面向主機，承擔路由功能，即主機尋址及有效的分組交換）。    各類應用進程之間通訊須要「可靠或盡力而爲」的兩類服務質量，必須由運輸層以複用和分用的形式加載到網絡層。      

5—02 網絡層提供數據報或虛電路服務對上面的運輸層有何影響？

答案：網絡層提供數據報或虛電路服務不影響上面的運輸層的運行機制。      但提供不一樣的服務質量。

謝希仁

5—03 當應用程序使用面向鏈接的TCP和無鏈接的IP時，這種傳輸是面向鏈接的仍是面向無鏈接的？

答案：都是。這要在不一樣層次來看，在運輸層是面向鏈接的，在網絡層則是無鏈接的。

謝希仁

5—04 試用畫圖解釋運輸層的複用。畫圖說明許多個運輸用戶複用到一條運輸鏈接上，而這條運輸鏈接有複用到IP數據報上。        

5—05 試舉例說明有些應用程序願意採用不可靠的UDP，而不用採用可靠的TCP。答案：VOIP：因爲語音信息具備必定的冗餘度，人耳對VOIP數據報損失由必定的承受度，但對傳輸時延的變化較敏感。    有差錯的UDP數據報在接收端被直接拋棄，TCP數據報出錯則會引發重傳，可能

帶來較大的時延擾動。

所以VOIP寧肯採用不可靠的UDP，而不肯意採用可靠的TCP。

5—06 接收方收到有差錯的UDP用戶數據報時應如何處理？答案：丟棄

5—07 若是應用程序願意使用UDP來完成可靠的傳輸，這可能嗎？請說明理由答案：可能，但應用程序中必須額外提供與TCP相同的功能。

5—08 爲何說UDP是面向報文的，而TCP是面向字節流的？

答案：發送方 UDP 對應用程序交下來的報文，在添加首部後就向下交付 IP 層。UDP 對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。接收方 UDP 對 IP 層交上來的 UDP 用戶數據報，在去除首部後就原封不動地交付上層的應用進程，一次交付一個完整的報文。

發送方TCP對應用程序交下來的報文數據塊，視爲無結構的字節流（無邊界約束，課分拆/合併），但維持各字節

5—09 端口的做用是什麼？爲何端口要劃分爲三種？

答案：端口的做用是對TCP/IP體系的應用進程進行統一的標誌，使運行不一樣操做系統的計算機的應用進程可以互相通訊。熟知端口，數值通常爲0~1023.標記常規的服務進程；登記端口號，數值爲1024~49151，標記沒有熟知端口號的很是規的服務進程； 5—10 試說明運輸層中僞首部的做用。  答案：用於計算運輸層數據報校驗和。

5—11 某個應用進程使用運輸層的用戶數據報UDP，然而繼續向下交給IP層後，又封裝成IP數據報。既然都是數據報，能否跳過UDP而直接交給IP層？哪些功能UDP提供了但IP沒提提供？

答案：不可跳過UDP而直接交給IP層IP數據報IP報承擔主機尋址，提供報頭檢錯；只能找到目的主機而沒法找到目的進程。UDP提供對應用進程的複用和分用功能，以及提供對數據差分的差錯檢驗。

5—12 一個應用程序用UDP，到IP層把數據報在劃分爲4個數據報片發送出去，結果前兩個數據報片丟失，後兩個到達目的站。過了一段時間應用程序重傳UDP，而IP層仍然劃分爲4個數據報片來傳送。結果此次前兩個到達目的站然後兩個丟失。試問：在目的站可否將這兩次傳輸的4個數據報片組裝成完整的數據報？假定目的站第一次收到的後兩個數據報片仍然保存在目的站的緩存中。答案：不行  重傳時，IP數據報的標識字段會有另外一個標識符。  僅當標識符相同的IP數據報片才能組裝成一個IP數據報。前兩個IP數據報片的標識符與後兩個IP數據報片的標識符不一樣，所以不能組裝成一個IP數據報。

5—13 一個UDP用戶數據的數據字段爲8192季節。在數據鏈路層要使用以太網來傳送。試問應當劃分爲幾個IP數據報片？說明每個IP數據報字段長度和片偏移字段的值。答案：6個  數據字段的長度：前5個是1480字節，最後一個是800字節。片偏移字段的值分別是：0，1480，2960，4440，5920和7400.

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

解：源端口1586，目的端口69，UDP用戶數據報總長度28字節，數據部分長度20字節。    此UDP用戶數據報是從客戶發給服務器（由於目的端口號<1023，是熟知端口）、服務器程序是TFFTP。

5—15 使用TCP對實時話音數據的傳輸有沒有什麼問題？使用UDP在傳送數據文件時會有什麼問題？

答案：若是語音數據不是實時播放（邊接受邊播放）就可使用TCP，由於TCP傳輸可靠。接收端用TCP講話音數據接受完畢後，能夠在之後的任什麼時候間進行播放。但假定是實時傳輸，則必須使用UDP。  UDP不保證可靠交付，但UCP比TCP的開銷要小不少。所以只要應用程序接受這樣

的服務質量就可使用UDP。

5—16 在中止等待協議中若是不使用編號是否可行？爲何？

答案:分組和確認分組都必須進行編號，才能明確哪一個分則獲得了確認。

5—17 在中止等待協議中，若是收到重複的報文段時不予理睬（即悄悄地丟棄它而其餘什麼也沒作）是否可行？試舉出具體的例子說明理由。

答案： 收到重複幀不確認至關於確認丟失

5—18 假定在運輸層使用中止等待協議。發送發在發送報文段M0後再設定的時間內未收到確認，因而重傳M0，但M0又遲遲不能到達接收方。不久，發送方收到了遲到的對M0的確認，因而發送下一個報文段M1，不久就收到了對M1的確認。接着發送方發送新的報文段M0，但這個新的M0在傳送過程當中丟失了。正巧，一開始就滯留在網絡中的M0如今到

達接收方。接收方沒法分辨M0是舊的。因而收下M0，併發送確認。顯然，接收方後來收到的M0是重複的，協議失敗了。試畫出相似於圖5-9所示的雙方交換報文段的過程。答案：  舊的M0被當成新的M0。        

5—19 試證實：當用n比特進行分組的編號時，若接收到窗口等於1（即只能按序接收分組），當僅在發送窗口不超過2n-1時，鏈接ARQ協議才能正確運行。窗口單位是分組。解：見課後答案案。

5—20 在連續ARQ協議中，若發送窗口等於7，則發送端在開始時可連續發送7個分組。所以，在每一分組發送後，都要置一個超時計時器。如今計算機裏只有一個硬時鐘。設這7個分組發出的時間分別爲t0,t1…t6,且tout都同樣大。試問如何實現這7個超時計時器（這叫軟件時鐘法）？

解：見課後答案案。

5—21 假定使用連續ARQ協議中，發送窗口大小事3，而序列範圍[0,15],而傳輸媒體保證在接收方可以按序收到分組。在某時刻，接收方，下一個指望收到序號是5.試問：

（1） 在發送方的發送窗口中可能有出現的序號組合有哪幾種？

（2） 接收方已經發送出去的、但在網絡中（即還未到達發送方）的確認分組可能有哪些？說明這些確認分組是用來確認哪些序號的分組。

5—22 主機A向主機B發送一個很長的文件，其長度爲L字節。假定TCP使用的MSS有1460字節。

（1） 在TCP的序號不重複使用的條件下，L的最大值是多少？

（2） 假定使用上面計算出文件長度，而運輸層、網絡層和數據鏈路層所使用的首部開銷共66字節，鏈路的數據率爲10Mb/s，試求這個文件所需的最短髮送時間。

 解：（1）L_max的最大值是2^32=4GB,G=2^30.

(2) 滿載分片數Q={L_max/MSS}取整=2941758發送的總報文數

N=Q*(MSS+66)+{（L_max-Q*MSS）+66}=4489122708+682=4489123390

總字節數是N=4489123390字節，發送4489123390字節需時間爲：N*8/（10*10^6）

=3591.3秒，即59.85分，約1小時。

5—23 主機A向主機B連續發送了兩個TCP報文段，其序號分別爲70和100。試問：     

（1） 第一個報文段攜帶了多少個字節的數據？

（2） 主機B收到第一個報文段後發回的確認中的確認號應當是多少？

（3） 若是主機B收到第二個報文段後發回的確認中的確認號是180，試問A發送的第二個報文段中的數據有多少字節？

（4） 若是A發送的第一個報文段丟失了，但第二個報文段到達了B。B在第二個報文段到達後向A發送確認。試問這個確認號應爲多少？

       解：（1）第一個報文段的數據序號是70到99，共30字節的數據。

（2）確認號應爲100.（3）80字節。      （4）70

5—24 一個TCP鏈接下面使用256kb/s的鏈路，其端到端時延爲128ms。經測試，發現吞吐量只有120kb/s。試問發送窗口W是多少？（提示：能夠有兩種答案案，取決於接收等發出確認的時機）。

解：來回路程的時延等於256ms(=128ms×2).設窗口值爲X(注意:以字節爲單位),假定一次最大發送量等於窗口值,且發射時間等於256ms,那麼,每發送一次都得停下來期待再次獲得下一窗口的確認,以獲得新的發送許可.這樣,發射時間等於中止等待應答案的時間結果,測到的平均吞吐率就等於發送速率的一半,即8X÷(256×1000)=256×0.001X=8192因此,窗口值爲8192.

    5—25 爲何在TCP首部中要把TCP端口號放入最開始的4個字節？ 答案：在ICMP的差錯報文中要包含IP首部後面的8個字節的內容，而這裏面有TCP首部中的源端口和目的端口。當TCP收到ICMP差錯報文時須要用這兩個端口來肯定是哪條鏈接出了差錯。

5—26 爲何在TCP首部中有一個首部長度字段，而UDP的首部中就沒有這個這個字段？       答案：TCP首部除固定長度部分外，還有選項，所以TCP首部長度是可變的。UDP首部長度是固定的。

5—27 一個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報文段的首部中源端口和目的端口分別是什麼？答案：分別是n和m。

5—29 在使用TCP傳送數據時，若是有一個確認報文段丟失了，也不必定會引發與該確認報文段對應的數據的重傳。試說明理由。

答案：還未重傳就收到了對更高序號的確認。

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

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

5—31 通訊信道帶寬爲1Gb／s，端到端時延爲10ms。TCP的發送窗口爲65535字節。試問:可能達到的最大吞吐量是多少?信道的利用率是多少?

答案：  L=65536×8+40×8=524600

       C=109b/s

       L/C=0.0005246s

 Td=10×10-3s

       0.02104864

       Throughput=L/(L/C+2×Td)=524600/0.0205246=25.5Mb/s

       Efficiency=(L/C)//(L/C+2×D)=0.0255

最大吞吐量爲25.5Mb/s。信道利用率爲25.5/1000=2.55%

 5—32 什麼是Karn算法?在TCP的重傳機制中，若不採用Karn算法，而是在收到確認時都認爲是對重傳報文段的確認，那麼由此得出的往返時延樣本和重傳時間都會偏小。試

問：重傳時間最後會減少到什麼程度?

答案：Karn算法：在計算平均往返時延RTT時，只要報文段重傳了，就不採用其往返時延樣本。  設新往返時延樣本Ti

RTT（1）=a*RTT（i-1）+（1-a）*T（i）；

RTT^（i）=a* RTT（i-1）+（1-a）*T（i）/2；

RTT（1）=a*0+(1-a)*T(1)= (1-a)*T(1);

RTT^（1）=a*0+(1-a)*T(1)/2= RTT（1）/2

RTT（2）= a*RTT（1）+（1-a）*T（2);

RTT^（2）= a*RTT（1）+（1-a）*T（2)/2;

= a*RTT（1）/2+（1-a）*T（2)/2= RTT（2）/2

RTO=beta*RTT,在統計意義上，重傳時間最後會減少到使用karn算法的1/2.

5—33  假定TCP在開始創建鏈接時，發送方設定超時重傳時間是RTO=6s。

（1）當發送方接到對方的鏈接確認報文段時，測量出RTT樣本值爲1.5s。試計算如今的RTO值。

（2）當發送方發送數據報文段並接收到確認時，測量出RTT樣本值爲2.5s。試計算如今的RTO值。答案：

（1）據RFC2988建議，RTO=RTTs+4*RTTd。其中RTTd是RTTs的誤差加權均值。   初次測量時，RTTd（1）= RTT（1）/2；       後續測量中，RTTd（i）=（1-Beta）* RTTd（i-1）+Beta*{ RTTs- RTT（i）}；

       Beta=1/4

       依題意，RTT（1）樣本值爲1.5秒，則

       RTTs（1）=RTT（1）=1.5s   RTTd(1)=RTT(1)/2=0.75s

       RTO(1)=RTTs(1)+4RTTd(1)=1.5+4*0.75=4.5(s)

（2）RTT（2）=2.5   RTTs（1）=1.5s   RTTd（1）=0.75s

       RTTd（2）=（1-Beta）* RTTd（1）+Beta*{ RTTs（1）- RT

（2）}=0.75*3/4+{1.5-2.5}/4=13/16

      RTO(2)=RTTs（1）+4RTTd（2）=1.5+4*13/16=4.75s

5—34 已知第一次測得TCP的往返時延的當前值是30 ms。如今收到了三個接連的確認報文段，它們比相應的數據報文段的發送時間分別滯後的時間是：26ms，32ms和24ms。設α=0．9。試計算每一次的新的加權平均往返時間值RTTs。討論所得出的結果。

答案：a=0.1， RTTO=30

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

RTT2=RTT1*a+32(1-a)=29.84

RTT3=RTT2*a+24（1-a）=29.256

三次算出加權平均往返時間分別爲29.6，29.84和29.256ms。

能夠看出，RTT的樣本值變化多達20%時，加權平均往返

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

答案：5段鏈路的傳播時延=250*2+（1500/150000）*3*1000=530ms

       5段鏈路的發送時延=960/（48*1000）*5*1000=100ms

       因此5段鏈路單程端到端時延=530+100=630ms

5—36 重複5-35題，但假定其中的一個陸地上的廣域網的傳輸時延爲150ms。答案：760ms

5—37 在TCP的擁塞控制中，什麼是慢開始、擁塞避免、快重傳和快恢復算法?這裏每一種算法各起什麼做用?  「乘法減少」和「加法增大」各用在什麼狀況下?答案：慢開始：  在主機剛剛開始發送報文段時可先將擁塞窗口cwnd設置爲一個最大報文段

MSS的數值。在每收到一個對新的報文段的確認後，將擁塞窗口增長至多一個MSS的數值。用這樣的方法逐步增大發送端的擁塞窗口cwnd，能夠分組注入到網絡的速率更加合理。  擁塞避免：  當擁塞窗口值大於慢開始門限時，中止使用慢開始算法而改用擁塞避免算法。擁塞避免算法使發送的擁塞窗口每通過一個往返時延RTT就增長一個MSS的大小。快重傳算法規定：發送端只要一連收到三個重複的ACK便可判定有分組丟失了，就應該當即重傳丟手的報文段而沒必要繼續等待爲該報文段設置的重傳計時器的超時。快恢復算法：當發送端收到連續三個重複的ACK時，就從新設置慢開始門限 ssthresh與慢開始不一樣之處是擁塞窗口 cwnd 不是設置爲 1，而是設置爲ssthresh若收到的重複的AVK爲n個（n>3），則將cwnd設置爲ssthresh若發送窗口值還允許發送報文段，就按擁塞避免算法繼續發送報文段。若收到了確認新的報文段的ACK，就將cwnd縮小到ssthresh

乘法減少：是指不論在慢開始階段仍是擁塞避免階段，只要出現一次超時（即出現一次網絡擁塞），就把慢開始門限值 ssthresh 設置爲當前的擁塞窗口值乘以 0.5。當網絡頻繁出現擁塞時，ssthresh 值就降低得很快，以大大減小注入到網絡中的分組數。加法增大：是指執行擁塞避免算法後，在收到對全部報文段的確認後（即通過一個往返時間），就把擁塞窗口 cwnd增長一個 MSS 大小，使擁塞窗口緩慢增大，以防止網絡過早出現擁塞

 

。

5—38 設TCP的ssthresh的初始值爲8(單位爲報文段)。當擁塞窗口上升到12時網絡發生了超時，TCP使用慢開始和擁塞避免。試分別求出第1次到第15次傳輸的各擁塞窗口大小。你能說明擁塞控制窗口每一次變化的緣由嗎？ 答案：擁塞窗口大小分別爲：1，2，4，8，9，10，11，12，1，2，4，6，7，8，9.

5—39 TCP的擁塞窗口cwnd大小與傳輸輪次n的關係以下所示：

cwnd

 n 1

1 2

2 4

3 8

4 16

5 32

6 33

7 34

8 35

9 36

10 37

11 38

12 39

13

cwnd

 n 40

14 41

15 42

16 21

17 22

18 23

19 24

20 25

21 26

22 1

23 2

24 4

25 8

26

（1）試畫出如圖5-25所示的擁塞窗口與傳輸輪次的關係曲線。

（2）指明TCP工做在慢開始階段的時間間隔。

（3）指明TCP工做在擁塞避免階段的時間間隔。

（4）在第16輪次和第22輪次以後發送方是經過收到三個重複的確認仍是經過超市檢測到丟失了報文段？

（5）在第1輪次，第18輪次和第24輪次發送時，門限ssthresh分別被設置爲多大？

（6）在第幾輪次發送出第70個報文段？

（7）假定在第26輪次以後收到了三個重複的確認，於是檢測出了報文段的丟失，那麼擁塞窗口cwnd和門限ssthresh應設置爲多大？

答案：（1）擁塞窗口與傳輸輪次的關係曲線如圖所示（課本後答案案）：

（2） 慢開始時間間隔：【1，6】和【23，26】

（3） 擁塞避免時間間隔：【6，16】和【17，22】

（4） 在第16輪次以後發送方經過收到三個重複的確認檢測到丟失的報文段。在第22輪次以後發送方是經過超時檢測到丟失的報文段。

（5） 在第1輪次發送時，門限ssthresh被設置爲32  在第18輪次發送時，門限ssthresh被設置爲發生擁塞時的一半，即21. 在第24輪次發送時，門限ssthresh是第18輪次發送時設置的21（6） 第70報文段在第7輪次發送出。（7） 擁塞窗口cwnd和門限ssthresh應設置爲8的一半，即4.

5—40 TCP在進行流量控制時是以分組的丟失做爲產生擁塞的標誌。有沒有不是因擁塞而引發的分組丟失的狀況?若有，請舉出三種狀況。

答案：當Ip數據報在傳輸過程當中須要分片，但其中的一個數據報未能及時到達終點，而終點組裝IP數據報已超時，於是只能丟失該數據報；IP數據報已經到達終點，但終點的緩存沒有足夠的空間存放此數據報；數據報在轉發過程當中通過一個局域網的網橋，但網橋在轉發該數據報的幀沒有足夠的差錯空間而只好丟棄。

5—41 用TCP傳送512字節的數據。設窗口爲100字節，而TCP報文段每次也是傳送100字節的數據。再設發送端和接收端的起始序號分別選爲100和200，試畫出相似於圖5-31的工做示意圖。從鏈接創建階段到鏈接釋放都要畫上。

5—42 在圖5-32中所示的鏈接釋放過程當中，主機B可否先不發送ACK=x+1的確認?  (由於後面要發送的鏈接釋放報文段中仍有ACK=x+1這一信息)

答案：若是B再也不發送數據了，是能夠把兩個報文段合併成爲一個，即只發送FIN+ACK報文段。但若是B還有數據報要發送，並且要發送一段時間，那就不行，由於A遲遲收不到確認，就會覺得剛纔發送的FIN報文段丟失了，就超時重傳這個FIN報文段，浪費網絡資源。

5—43 在圖(5-33)中，在什麼狀況下會發生從狀態LISTEN到狀態SYN_SENT，以及從狀

態SYN_ENT到狀態SYN_RCVD的變遷?

答案：當A和B都做爲客戶，即同時主動打開TCP鏈接。這時的每一方的狀態變遷都是： CLOSED----àSYN-SENT---àSYN-RCVD--àESTABLISHED

5—44 試以具體例子說明爲何一個運輸鏈接能夠有多種方式釋放。能夠設兩個互相通訊的用戶分別鏈接在網絡的兩結點上。

答案：設A,B創建了運輸鏈接。協議應考慮一下實際可能性：

           A或B故障，應設計超時機制，使對方退出，不至於死鎖；

           A主動退出，B被動退出

           B主動退出，A被動退出

5—45 解釋爲何忽然釋放運輸鏈接就可能會丟失用戶數據，而使用TCP的鏈接釋放方法就可保證不丟失數據。答案：當主機1和主機2之間鏈接創建後，主機1發送了一個TCP數據段並正確抵達主機2，接着

主機1發送另外一個TCP數據段，此次很不幸，主機2在收到第二個TCP數據段以前發出了釋放鏈接請求，若是就這樣忽然釋放鏈接，顯然主機1發送的第二個TCP報文段會丟失。而使用TCP的鏈接釋放方法，主機2發出了釋放鏈接的請求，那麼即便收到主機1的確認後，只會釋放主機2到主機1方向的鏈接，即主機2再也不向主機1發送數據，而仍然可接受主機1發來的數據，因此可保證不丟失數據。

5—46 試用具體例子說明爲何在運輸鏈接創建時要使用三次握手。說明如不這樣作可能會出現什麼狀況。答案： 3次握手完成兩個重要的功能，既要雙方作好發送數據的準備工做（雙方都知道彼此已

準備好），也要容許雙方就初始序列號進行協商，這個序列號在握手過程當中被髮送和確認。

假定B給A發送一個鏈接請求分組，A收到了這個分組，併發送了確認應答案分組。按照兩

 

次握手的協定，A認爲鏈接已經成功地創建了，能夠開始發送數據分組。但是，B在A的應答案分組在傳輸中被丟失的狀況下，將不知道A是否已準備好，不知道A建議什麼樣的序列號，B甚至懷疑A是否收到本身的鏈接請求分組，在這種狀況下，B認爲鏈接還未創建成功，將忽略A發來的任何數據分組，只等待鏈接確認應答案分組。   而A發出的分組超時後，重複發送一樣的分組。這樣就造成了死鎖。

5—47 一個客戶向服務器請求創建TCP鏈接。客戶在TCP鏈接創建的三次握手中的最後一個報文段中捎帶上一些數據，請求服務器發送一個長度爲L字節的文件。假定：（1）客戶和服務器之間的數據傳輸速率是R字節/秒，客戶與服務器之間的往返時間是RTT（固定值）。

（2）服務器發送的TCP報文段的長度都是M字節，而發送窗口大小是nM字節。（3）全部傳送的報文段都不會出錯（無重傳），客戶收到服務器發來的報文段後就及時發送確認。（4）全部的協議首部開銷均可忽略，全部確認報文段和鏈接創建階段的報文段的長度均可忽略（即忽略這些報文段的發送時間）。試證實，從客戶開始發起鏈接創建到接收服務器發送的整個文件多需的時間T是： T=2RTT+L/R   當nM>R(RTT)+M

或  T=2RTT+L/R+(K-1)[M/R+RTT-nM/R]   當nM<R(RTT)+M

其中，K=[L/nM]，符號[x]表示若x不是整數，則把x的整數部分加1。

解：發送窗口較小的狀況，發送一組nM個字節後必須停頓下來，等收到確認後繼續發送。共需K=[L/nM]個週期：其中        前K-1個週期每週期耗時M/R+RTT,共耗時（K-1）（M/R+RTT）       第K週期剩餘字節數Q=L-（K-1）*nM，需耗時Q/R 總耗時=2*RTT+(K-1)M/(R+RTT)+Q/R=2*RTT+L/R+(K-1)[( M/R+RTT)-nM/R]

 

計算機網絡第七版第四章答案

計算機網絡第七版第六章答案