5.1 試說明運輸層在協議棧中的地位和作用。運輸層的通信和網絡層的通信有什么重要區別？

解答：從通信和信息處理的角度看，運輸層向它上面的應用層提供端到端通信服務，它屬于面向通信部分的最高層，同時也是用戶功能中的最低層。當位于網絡邊緣部分的兩臺主機使用網絡核心部分的功能進行端到端的通信時，只有主機的協議棧才有運輸層，而網絡核心部分中的路由器在轉發分組時都只用到下三層的功能。

雖然網絡層實現了主機到主機的邏輯通信，但嚴格地講，通信的真正端點并不是主機而是主機中的進程。因此，運輸層在網絡層之上提供應用進程間的邏輯通信。

5.2 當應用程序使用面向連接的TCP和無連接的IP時，這種傳輸是面向連接的還是無連接的？

解答：從網絡層看是無連接的，但從運輸層看是面向連接的。

5.3 接收方收到有差錯的UDP用戶數據報時應如何處理？

解答：丟棄且不通知發送方。

5.4 在“滑動窗口”概念中，“發送窗口”和“接收窗口”的作用是什么？如果接收方的接收能力不斷地發生變化，則采取何種措施可以提高協議的效率。

解答：“發送窗口”作用是限制發送方連續發送數據的數量，即控制發送方發送數據的平均速率。“接收窗口”反映了接收方當前接收緩存的大小，即接收方接收能力的大小。當接收方的接收能力不斷地發生變化時，可以將接收窗口的大小發送給發送方，調節發送方的發送速率，避免因發送方發送速率太大或太小而導致接收緩存的溢出或帶寬的浪費，從而提高協議的效率。

5.5 簡述TCP和UDP的主要區別。

解答：TCP提供的是面向連接、可靠字的字節流服務，并且有流量控制和擁塞控制功能。UDP提供的是無連接、不可靠的數據報服務，無流量控制和擁塞控制。

5.6 為什么在TCP首部中有一個首部長度字段，而UDP的首部中就沒有這個字段？

答：TCP首部除固定長度部分外，還有選項，因此TCP首部長度是可變的。UDP首部長度是固定的。

5.7 如果因特網中的所有鏈路都提供可靠的傳輸服務，TCP可靠傳輸服務將會是完全多余的嗎？為什么？

解答：TCP可靠傳輸服務不是多余的。因為在端到端的數據傳輸過程中并不是所有的差錯都來自分組在鏈路上傳輸時的比特級差錯，例如由于網絡擁塞導致路由器的分組丟棄，路由器在轉發分組時的故障等都會導致端到端的數據傳輸的差錯，這些都不可能通過鏈路層的可靠數據傳輸得以解決，必須由端到端的運輸層可靠數據傳輸服務來解決。

5.8 解釋為什么突然釋放運輸連接就可能會丟失用戶數據，而使用TCP的連接釋放方法就可保證不丟失數據。

解答：假定A和B之間建立了TCP連接。如果A發送完數據在還沒有接收到對方確認時就突然釋放連接，則不能保證這些沒有被確認的數據在傳輸中不會丟失。

如果A在收到B對所有發送數據的確認后釋放連接，A發送的數據不會丟失，可能B還在數據發送，這些數據A都無法正確收到。

TCP的連接釋放在兩個方向都要發送連接釋放請求和確認，保證數據不丟失。

5.9 試用具體例子說明為什么在運輸連接建立時要使用三次聯絡。說明如不這樣做可能會出現什么情況。

解答：這主要是為了防止已失效的連接請求報文段突然又傳送到了TCP服務器，導致建立錯誤的連接而浪費資源，如圖所示。

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

解答：由于IP數據報的最大長度是65535字節，因此除去IP首部的20字節和TCP首部的20字節，一個TCP報文段的數據部分最多為65495字節。

如果用戶要傳送的數據的字節長度超過TCP報文段中的序號字段可能編出的最大序號，則重復循環使用。

5.11 主機A和B使用TCP通信。在B發送過的報文段中，有這樣連續的兩個：ack = 120和ack = 100。這可能嗎（前一個報文段確認的序號還大于后一個的）？試說明理由。

解答：一般不會，因為TCP的接收方采用的是累積確認，確認號不會倒退。但當出現失序時會有這種情況出現。設想A連續發送兩個報文段：（seq = 92，DATA共8字節）和（seq =100，DATA共20字節），均正確到達B。B連續發送兩個確認：(ack?=?100) 和?(ack?=?120)。但前者在網絡中傳送時經歷了很大的時延，使得A先收到B后發送的確認。圖A-1說明了這一情況。見圖A-1。

圖A-1 ?習題5-11的圖

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

解答：發送方還未超時重傳就收到了接收方對更高序號的確認。

5.13 請簡要比較TCP的可靠傳輸實現與GBN算法的主要異同。

解答：TCP接收窗口大小不為1，發送窗口和接收窗口大小動態變化，而GBN接收窗口為1。

TCP標準沒有規定對不按序到達的數據應如何處理。通常是先臨時存放在接收窗口中，等到字節流中所缺少的字節收到后，再按序交付上層的應用進程。

TCP和GBN都是采用累積確認方式，但在發生超時，TCP發送方僅對超時的分組重傳，而GBN是重傳窗口內所有已發送的分組。

TCP的編號以字節為單位，而GBN以分組為單位。

因此TCP的算法介于GBN和SR之間。

5.14 在5.3.3節曾講過，若收到的報文段無差錯，只是未按序號，則TCP對此未作明確規定，而是讓TCP的實現者自行確定。試討論兩種可能的方法的優劣：

(1)?把不按序的報文段丟棄；

(2)?先把不按序的報文段暫存于接收緩存內，待所缺序號的報文段收齊后再一起上交應用層。

解答：對于第一種方法，實現簡單，接收方不需要很大的接收緩存，但由于所有不按序到達的報文段都被丟棄，這些報文段需要發送方進行重傳，會浪費帶寬。特別是在運輸層，報文段不出現丟失也可能因IP報文獨立路由而失序，而且由于端到端時延和時延抖動都比較大，超時時間設置的比較長，因此，失序報文段被接收方丟棄不僅浪費帶寬而且重傳會產生很大的時延。

對于第二種方法，只要在發送方超時前收到失序報文段的確認（接收方已收到所有遲到的報文段，并發回確認），就可以避免失序報文段的重傳。但協議更復雜，且需要比較大的接收緩存。

5.15 設TCP使用的最大窗口為64 KB，即64 ′?1024字節，而傳輸信道的帶寬可認為是不受限制的。若報文段的平均往返時延為20 ms，問所能得到的最大吞量是多少？

解答：

5.16 試計算一個包括5段鏈路的運輸連接的單程端到端時延。5段鏈路程中有兩段是衛星鏈路，有三段是廣域網鏈路。每條衛星鏈路又由上行鏈路和下行鏈路兩部分組成。可以取這兩部分的傳播時延之和為250?ms。每一個廣域網的范圍為1500?km，其傳播時延可按150?000?km/s來計算。各數據鏈路速率為48?kbit/s，幀長為960?bit。

解答：每個廣域網的傳播時延 = (1500 km)/(150000 km/s) = 0.01 s = 10 ms

衛星鏈路傳播時延 = 250?ms

每個結點的傳輸時延或發送時延 = (960 bit)/(48000 bit/s) = 0.02 s = 20 ms

因此，總的端到端單程時延為：10 ms ′?3 + 250 ms ′?2 + 20 ms ′?5 = 630 ms。

5.17 重復上題，但假定其中的一個陸地上的廣域網的傳輸時延為150?ms。

解答：760 ms。

5.18 TCP接收方收到3個重復ACK就執行快速重傳。為什么不在收到對報文段的第一個重復ACK后就快速重傳？

答：當TCP接收方收到失序分組或重復分組時都會發送重復確認，而在運輸層，失序是經常發生的，若對收到第一個冗余ACK后就快速重傳，一旦兩個報文段失序就會導致發送方立即快速重傳，重傳的分組又導致冗余ACK（對重復分組的確認），又導致快速重傳，不斷這樣下去。因此收到3個冗余ACK才認為丟失并進行快速重傳，一是收到3個冗余ACK是因為丟失報文段的可能性比較大，二是即使沒丟失也不會導致一直重傳，很快能恢復正常。

5.19 用TCP傳送512字節的數據。設窗口為100字節，而TCP報文段每次也是傳送100字節的數據。再設發送方和接收方的起始序號分別選為100和200，試畫出類似于圖5-15的工作示意圖。從連接建立階段到連接釋放都要畫上。

解答

5.20 在圖5-17中所示的連接釋放過程中，主機B能否先不發送ack?=?u?+?1的確認？（因為后面要發送的連接釋放報文段中仍有ack?=?u?+?1這一信息）

解答：如果B也正要關閉連接，可以將對A的連接釋放請求的確認和發給A的連接釋放請求合并。但如果B并不馬上關閉連接，則要及時對A的連接釋放請求進行確認。

5.21 在圖5-17所示的連接釋放過程中，主機A在發送完對B的連接釋放請求報文段的確認后，為什么還要等待一段超時時間再徹底關閉連接？

因為主機A的確認有可能丟失，這時B會重傳FIN報文段。在這段超時時間內，若A又收到B重傳的FIN報文段，A需要再次進行確認。收到A的最后確認，B才能最終將整個連接釋放。主機A的TCP再向其應用進程報告，整個連接已經全部釋放。

5.22 在圖5-18中，在什么情況下會發生從狀態LISTEN到狀態SYN_SENT，以及從狀態SYN_SENT到狀態SYN_RCVD的變遷？

解答：當雙方同時主動打開TCP連接，向對方發送連接請求（SYN）時，從狀態LISTEN變為狀態SYN_SENT，然后收到對方的連接請求后，發送連接請求確認（SYN, ACK）從狀態SYN_SENT變為狀態SYN_RCVD。

5.23 是否TCP和UDP都需要計算往返時延RTT？

解答：往返時延RTT只是對運輸層的TCP協議才很重要，因為TCP要根據平均往返時延RTT的值來設置超時計時器的超時時間。

UDP沒有確認和重傳機制，因此RTT對UDP沒有什么意義。

5.24 在TCP的往返時延的估計中，你認為為什么TCP忽略對重傳報文段的往返時延測量值RTT樣本。

解答：因為分組丟失差錯和過早超時都可能導致發送方重傳分組，因此發送方無法確定接收到的確認是對原來發送的分組的確認還是對重傳的分組進行確認。

若認為是對重傳的分組進行確認，而實際上是過早超時，該分組是對原來發送的分組的確認，則可能測量值SampleRTT比實際值要小。

若認為是對原來發送的分組的確認，而實際上是對重傳分組的確認，則測量值SampleRTT可能比實際值要大。

5.25 什么是Karn算法？在TCP的重傳機制中，若不采用Karn算法，而是在收到確認時都認為是對重傳報文段的確認，那么由此得出的往返時延樣本和重傳時間都會偏小。試問：重傳時間最后會減小到什么程度？

解答：若不采用Karn算法，而是在收到確認時都認為是對重傳報文段的確認，那么由此得出的往返時延樣本和重傳時間會小于實際的往返時延，當再次發送報文段時，又會超時，若在超時重傳后立即收到原報文段的確認，則重傳時間會減小到接近于零。

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

解答：不能，IP協議沒有提供端口功能，IP數據報只能找到目的主機而無法找到目的進程。

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

解答：TCP的流量控制和擁塞控制和可靠數據傳輸機制會導致比較大的分組時延抖動，而大的時延抖動會嚴重影響實時話音數據傳輸的質量。由于數據文件的傳輸需要可靠數據傳輸，因此在使用UDP在傳送數據文件時需要應用程序自己實現可靠數據傳輸功能。

5.28 TCP在進行擁塞控制時是以分組的丟失作為產生擁塞的標志。有沒有不是因擁塞而引起的分組丟失的情況？如有，請舉出三種情況。

解答：有。一是信道誤碼導致中間結點將分組丟棄；二是路由錯誤導致分組在網絡中兜圈子最后被路由器丟棄；三是中間路由器在接收了分組還沒有轉發出去時故障，導致分組丟失。這些情況發生的概率都比較小。

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

解答：不行。重傳時，IP數據報的標識字段會有另一個標識符。僅當標識符相同的IP數據報片才能組裝成一個數據報。

5.30 為什么在TCP首部中有一個首部長度字段，而UDP的首部中就沒有這個字段？

解答：TCP首部除固定長度部分外，還有選項，因此TCP首部長度是可變的。如果沒有首部長度字段，接收方就無法知道TCP報文段的數據從什么地方開始。TCP首部中的首部長度字段也可以看成是數據偏移字段。而UDP首部長度是固定的，因此不需要首部長度字段。

5.31 一個UDP用戶數據報的數據字段為8192字節。要使用以太網來傳送。試問應當劃分為幾個數據報片？說明每一個數據報片的數據字段長度和片偏移字段的值。

解答：6個。數據字段的長度：前5個是1480字節，最后一個是800字節。(注意要加上UDP首部的8字節)

片偏移字段的值分別是：0, 185, 370, 555, 740和925。

5.32 簡述TCP流量控制和擁塞控制的不同。

解答：流量控制解決因發送方發送數據太快而導致接收方來不及接收使接收方緩存溢出的問題。流量控制的基本方法就接收方根據自己的接收能力控制發送方的發送速率。TCP采用接收方控制發送方發送窗口大小的方法來實現在TCP連接上的流量控制。

擁塞控制就是防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載。TCP的發送方維持一個叫做擁塞窗口的狀態變量。擁塞窗口的大小取決于網絡的擁塞程度，當網絡擁塞時減小擁塞窗口的大小，控制TCP發送方的發送速率。TCP發送方的發送窗口大小取接收窗口和擁塞窗口的最小值。

5.33 在TCP的擁塞控制中，什么是慢開始、擁塞避免、快速重傳和快速恢復算法？這里每一種算法各起什么作用？“加性增”和“乘性減”各用在什么情況下？

解答：慢開始就是當主機剛開始發送數據時完全不知到網絡的擁塞情況，將擁塞窗口設為很小，當收到確認時，由小到大逐漸增大發送方的擁塞窗口數值。

在慢開始階段發送速率以指數方式迅速增長，若持續以該速度增長發送速率必然導致網絡很快進入擁塞狀態。因此需要設置一個狀態變量，即慢開始門限ssthresh，當擁塞窗口大于該門限時，進入擁塞避免階段，降低發送速率的增長速率（以線性方式增長），避免網絡擁塞。

快速重傳就是當發送方收到3個冗余確認時，就認為現在可能是網絡出現了擁塞造成分組丟失，就立即重傳確認號指示的報文段，而不必繼續等待超時。

快速恢復就是，當發送方收到連續三個重復的ACK時，雖然有可能丟失了一些分組，但這連續的三個重復ACK同時又表明丟失分組以外的另外三個分組已經被接收方接收了。因此，與發生超時事件的情況不同，網絡還有一定的分組交付能力，擁塞情況并不嚴重，直接執行擁塞避免算法。

采用快速恢復算法的情況下，長時間的TCP連接在穩定的時候通常處于下面描述的重復狀態。經過慢啟動發送方迅速進入擁塞避免階段，在該階段，使擁塞窗口呈線性增長，即“加性增”，發送速率緩慢增長，以防止網絡過早出現擁塞。當流量逐漸超過網絡可用帶寬時會出現擁塞，但由于發送速率增長緩慢，通常僅導致少量分組丟失。這種情況下發送方會收到3個重復ACK并將擁塞窗口減半，即“乘性減”，然后再繼續執行“加性增”緩慢增長發送速率，如此重復下去。

5.34 TCP使用慢開始和擁塞避免，設TCP的擁塞窗口閾值的初始值為8（單位為MSS）。從慢開始開始，當擁塞窗口上升到12時網絡發生了超時。試畫出每個往返時間TCP擁塞窗口的演變曲線圖（橫坐標單位為“輪次”，縱坐標為擁塞窗口大小）。說明擁塞窗口每一次變化的原因（畫15個“輪次”）。

解答：擁塞窗口的變化：1, 2, 4, 8, 9, 10, 11, 12, 1, 2, 4, 6, 7, 8, 9。

5.35 通信信道帶寬為1 Gbit/s，端到端時延為10 ms。TCP的發送窗口為65535字節。試問：可能達到的最大吞吐量是多少？信道的利用率是多少？

解答：最大吞吐量：25.5?Mbit/s。信道利用率：25.5%。

5.36 為什么TCP擁塞控制中對發送方收到3個重復ACK和超時事件采用不同的處理方法？

解答：當發送方收到3個冗余ACK說明網絡可能丟失了少量分組，但后續多個分組都被接收方收到了，因此網絡擁塞并不嚴重，TCP執行快速恢復算法，將擁塞窗口減半，直接進入擁塞避免階段。而當超時事件發生時，說明發送的一連串分組都丟失了，網絡擁塞比較嚴重，因此將擁塞窗口減少到最小，開始執行慢啟動。

5.37 考慮圖5-18中的例子，若將主機C到R1的鏈路帶寬提高到1000 Mbit/s，則所能達到的最大吞吐量大約會是多少？

解答：約11 Mbit/s。

5.38考慮圖5-23的網絡，路由器之間的鏈路帶寬為100 Mbit/s，假設主機到路由器的鏈路帶寬無限。主機A到C的連接經過R2，B到D的連接經過R3，C到A的連接經過R4，D到B的連接過R1。若無擁塞控制，各主機逐漸增大發送速率，會出現什么情況？

圖5-23 習題5-38的圖

解答：隨著各主機逐漸增大發送速率，網絡總吞吐量逐漸增大到200 Mbit/s（各主機發送速率為50 Mbit/s），然后網絡總吞吐量逐漸減少，當各主機發送速率增大到無窮大時，網絡總吞吐量趨近于0，即路由器之間的4條鏈路均滿負荷，但各主機之間的分組傳送均失敗。

總結

以上是生活随笔為你收集整理的【计算机网络(微课版)】第5章 传输层 课后习题及答案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。