第5章-運輸層

1、精選優(yōu)質文檔-傾情為你奉上第5章5-1 試說明運輸層在協(xié)議棧中的地位和作用。運輸層的通信和網(wǎng)絡層的通信有什么重要區(qū)別？解答：從通信和信息處理的角度看，運輸層向它上面的應用層提供端到端通信服務，它屬于面向通信部分的最高層，同時也是用戶功能中的最低層。當位于網(wǎng)絡邊緣部分的兩臺主機使用網(wǎng)絡核心部分的功能進行端到端的通信時，只有主機的協(xié)議棧才有運輸層，而網(wǎng)絡核心部分中的路由器在轉發(fā)分組時都只用到下三層的功能。雖然網(wǎng)絡層實現(xiàn)了主機到主機的邏輯通信，但嚴格地講，通信的真正端點并不是主機而是主機中的進程。因此，運輸層在網(wǎng)絡層之上提供應用進程間的邏輯通信。5-2 當應用程序使用面向連接的TCP和無連接的IP時

2、，這種傳輸是面向連接的還是無連接的？解答：從網(wǎng)絡層看是無連接的，但從運輸層看是面向連接的。5-3 接收方收到有差錯的UDP用戶數(shù)據(jù)報時應如何處理？解答：丟棄且不通知發(fā)送方。5-4 在“滑動窗口”概念中，“發(fā)送窗口”和“接收窗口”的作用是什么？如果接收方的接收能力不斷地發(fā)生變化，則采取何種措施可以提高協(xié)議的效率。解答：“發(fā)送窗口”作用是限制發(fā)送方連續(xù)發(fā)送數(shù)據(jù)的數(shù)量，即控制發(fā)送方發(fā)送數(shù)據(jù)的平均速率。“接收窗口”反映了接收方當前接收緩存的大小，即接收方接收能力的大小。當接收方的接收能力不斷地發(fā)生變化時，可以將接收窗口的大小發(fā)送給發(fā)送方，調節(jié)發(fā)送方的發(fā)送速率，避免因發(fā)送方發(fā)送速率太大或太小而導致接收緩

3、存的溢出或帶寬的浪費，從而提高協(xié)議的效率。5-5 簡述TCP和UDP的主要區(qū)別。解答：TCP提供的是面向連接、可靠字的字節(jié)流服務，并且有流量控制和擁塞控制功能。UDP提供的是無連接、不可靠的數(shù)據(jù)報服務，無流量控制和擁塞控制。5-6 如果因特網(wǎng)中的所有鏈路都提供可靠的傳輸服務，TCP可靠傳輸服務將會是完全多余的嗎？為什么？解答：TCP可靠傳輸服務不是多余的。因為在端到端的數(shù)據(jù)傳輸過程中并不是所有的差錯都來自分組在鏈路上傳輸時的比特級差錯，例如由于網(wǎng)絡擁塞導致路由器的分組丟棄，路由器在轉發(fā)分組時的故障等都會導致端到端的數(shù)據(jù)傳輸?shù)牟铄e，這些都不可能通過鏈路層的可靠數(shù)據(jù)傳輸?shù)靡越鉀Q，必須由端到端的運輸

4、層可靠數(shù)據(jù)傳輸服務來解決。5-7 解釋為什么突然釋放運輸連接就可能會丟失用戶數(shù)據(jù)，而使用TCP的連接釋放方法就可保證不丟失數(shù)據(jù)。解答：假定A和B之間建立了TCP連接。如果A發(fā)送完數(shù)據(jù)在還沒有接收到對方確認時就突然釋放連接，則不能保證這些沒有被確認的數(shù)據(jù)在傳輸中不會丟失。如果A在收到B對所有發(fā)送數(shù)據(jù)的確認后釋放連接，A發(fā)送的數(shù)據(jù)不會丟失，可能B還在數(shù)據(jù)發(fā)送，這些數(shù)據(jù)A都無法正確收到。TCP的連接釋放在兩個方向都要發(fā)送連接釋放請求和確認，保證數(shù)據(jù)不丟失。5-8 試用具體例子說明為什么在運輸連接建立時要使用三次聯(lián)絡。說明如不這樣做可能會出現(xiàn)什么情況。解答：這主要是為了防止已失效的連接請求報文段突然又

5、傳送到了TCP服務器，導致建立錯誤的連接而浪費資源，如圖所示。5-9 主機A和B使用TCP通信。在B發(fā)送過的報文段中，有這樣連續(xù)的兩個：ack = 120和ack = 100。這可能嗎（前一個報文段確認的序號還大于后一個的）？試說明理由。解答：一般不會，因為TCP的接收方采用的是累積確認，確認號不會倒退。但當出現(xiàn)失序時會有這種情況出現(xiàn)。設想A連續(xù)發(fā)送兩個報文段：（seq = 92，DATA共8字節(jié)）和（seq =100，DATA共20字節(jié)），均正確到達B。B連續(xù)發(fā)送兩個確認：(ack = 100) 和 (ack = 120)。但前者在網(wǎng)絡中傳送時經(jīng)歷了很

6、大的時延，使得A先收到B后發(fā)送的確認。圖A-1說明了這一情況。見圖A-1。圖A-1 習題5-11的圖5-10 請簡要比較TCP的可靠傳輸實現(xiàn)與GBN算法的主要異同。解答：TCP接收窗口大小不為1，發(fā)送窗口和接收窗口大小動態(tài)變化，而GBN接收窗口為1。TCP標準沒有規(guī)定對不按序到達的數(shù)據(jù)應如何處理。通常是先臨時存放在接收窗口中，等到字節(jié)流中所缺少的字節(jié)收到后，再按序交付上層的應用進程。TCP和GBN都是采用累積確認方式，但在發(fā)生超時，TCP發(fā)送方僅對超時的分組重傳，而GBN是重傳窗口內(nèi)所有已發(fā)送的分組。TCP的編號以字節(jié)為單位，而GBN以分組為單位。因此TCP的算法介于GBN和SR之間。5-11

7、 用TCP傳送512字節(jié)的數(shù)據(jù)。設窗口為100字節(jié)，而TCP報文段每次也是傳送100字節(jié)的數(shù)據(jù)。再設發(fā)送方和接收方的起始序號分別選為100和200，試畫出類似于圖5-15的工作示意圖。從連接建立階段到連接釋放都要畫上。解答5-12 在上圖所示的連接釋放過程中，主機A在發(fā)送完對B的連接釋放請求報文段的確認后，為什么還要等待一段超時時間再徹底關閉連接？因為主機A的確認有可能丟失，這時B會重傳FIN報文段。在這段超時時間內(nèi)，若A又收到B重傳的FIN報文段，A需要再次進行確認。收到A的最后確認，B才能最終將整個連接釋放。主機A的TCP再向其應用進程報告，整個連接已經(jīng)全部釋放。5-13 使用TCP對實時

8、話音數(shù)據(jù)的傳輸有沒有什么問題？使用UDP在傳送數(shù)據(jù)文件時會有什么問題？解答：TCP的流量控制和擁塞控制和可靠數(shù)據(jù)傳輸機制會導致比較大的分組時延抖動，而大的時延抖動會嚴重影響實時話音數(shù)據(jù)傳輸?shù)馁|量。由于數(shù)據(jù)文件的傳輸需要可靠數(shù)據(jù)傳輸，因此在使用UDP在傳送數(shù)據(jù)文件時需要應用程序自己實現(xiàn)可靠數(shù)據(jù)傳輸功能。5-14 TCP在進行擁塞控制時是以分組的丟失作為產(chǎn)生擁塞的標志。有沒有不是因擁塞而引起的分組丟失的情況？如有，請舉出三種情況。解答：有。一是信道誤碼導致中間結點將分組丟棄；二是路由錯誤導致分組在網(wǎng)絡中兜圈子最后被路由器丟棄；三是中間路由器在接收了分組還沒有轉發(fā)出去時故障，導致分組丟失。這些情況發(fā)生的概率都比較小。5-15 簡述TCP流量控制和擁塞控制的不同。解答：流量控制解決因發(fā)送方發(fā)送數(shù)據(jù)太快而導致接收方來不及接收使接收方緩存溢出的問題。流量控制的基本方法就接收方根據(jù)自己的接收能力控制發(fā)送方的發(fā)送速率。TCP采用接收方控制發(fā)送方發(fā)送窗口大小的方法來實現(xiàn)在TCP連接上的流量控制。擁塞控制就是防止過多的數(shù)據(jù)