第五章   傳輸層

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]