最新計(jì)算機(jī)網(wǎng)絡(luò)-第三章-運(yùn)輸層(練習(xí)題)

1、精品文檔第 3 章運(yùn)輸層練習(xí)題1. 當(dāng)一個(gè)TCP 報(bào)文段到達(dá)目的主機(jī)時(shí)，通過什么來定向套接 字？ A. 封裝報(bào)文段的數(shù)據(jù)報(bào)中的源 IP 地址B. 目的端口號(hào)C.源端口號(hào)D. 以上所有答案： D提示：TC喳接字是通過一個(gè)四元組：（IP地址，源端口號(hào)，目的IP 地址，目的端口號(hào)）來標(biāo)識(shí)的。當(dāng)一個(gè)TCP 報(bào)文段從網(wǎng)絡(luò)到達(dá)一臺(tái)主機(jī)時(shí)，主機(jī)使用全部四個(gè)值來將報(bào)文段定向（多路分解）到相應(yīng)的套接字。2. UDP 具有以下哪些特征？A. 在服務(wù)器上維護(hù)連接狀態(tài)信息B. 通過三次握手建立連接C.調(diào)節(jié)發(fā)送速率D. 以上都不是答案： D3. 當(dāng)一個(gè)UDP報(bào)文段到達(dá)某個(gè)主機(jī)時(shí)，為了將報(bào)文段提交給合適的套接字，操作系統(tǒng)

2、使用：A. 源IP 地址B. 源端口號(hào)C. 目的端口號(hào)D. 以上全部答案： C提示：UD唯接字是由一個(gè)包含目的IP 地址和目的端口號(hào)組成的二元組來全面標(biāo)識(shí)的。 在多路分解時(shí)，目標(biāo)主機(jī)通過檢查報(bào)文段中的目的端口號(hào)，將報(bào)文段定向到相應(yīng)套接字。4. 在什么樣的情況下，停止等待協(xié)議的效率會(huì)變得很低：疑難：重點(diǎn)：一般：了解：自學(xué)：X精品文檔精品文檔第3 章運(yùn)輸層A. 當(dāng)源主機(jī)和目的主機(jī)之間的距離很近而且傳輸速率很 高時(shí) B. 當(dāng)源主機(jī)和目的主機(jī)之間的距離很遠(yuǎn)而且傳輸速率很 高時(shí) C. 當(dāng)源主機(jī)和目的主機(jī)之間的距離很近而且傳輸速率很 低時(shí) D. 當(dāng)源主機(jī)和目的主機(jī)之間的距離很遠(yuǎn)而且傳輸速率很 低時(shí) 答案：

3、 B 提示：使用停止等待協(xié)議，發(fā)送方在確認(rèn)接收方已經(jīng) 正確地接收了當(dāng)前傳送的分組之前不會(huì)發(fā) 送新的數(shù)據(jù)。所以在傳輸效率很高的前提下，主機(jī)之 間距離越遠(yuǎn)，不必要的等待時(shí)間就越長。精品文檔精品文檔5.流水線操作具有以下哪些特點(diǎn)：A.發(fā)送方必須能緩存它已發(fā)送了但還沒有收到確認(rèn)的分組B.每一個(gè)正在傳輸?shù)姆纸M具有獨(dú)一無二的順序號(hào)C.發(fā)送方在收到確認(rèn)信號(hào)之前可傳輸多個(gè)分組D.以上都是答案： D6.TCP什么時(shí)候?qū)?bào)文段采用快速重傳？A.報(bào)文段的定時(shí)器過期B.估計(jì)往返時(shí)延過長C.收到之前發(fā)出的一個(gè)報(bào)文段的三個(gè)重復(fù)ACKD.以上都不是答案： C提示：當(dāng)接收方檢測到數(shù)據(jù)流中出現(xiàn)了缺失，它會(huì)簡單的對(duì)收到的最后一個(gè)

4、有序字節(jié)給出重復(fù)確認(rèn)，即產(chǎn)生一個(gè)該數(shù)據(jù)的重復(fù)的ACK如果TCP發(fā)送方收到了同一數(shù)據(jù)的三個(gè)重復(fù)確認(rèn)，就表示該被確認(rèn)了三次的數(shù)據(jù)段后面的數(shù)據(jù)已經(jīng)丟失了。此時(shí)TC或行快速重傳RFC2581。7.在TC睢接中，假設(shè)一旦窗口大小到達(dá)W寸就會(huì)出現(xiàn)分組丟失，并假設(shè)RTT是不變的。那么近似平均傳輸速度是：A.W*MSS/RTTB.MSS/RTTC.0.75 W*MSS/RTTD.W*MSS/2 RTT疑難：重點(diǎn)：一般：了解：自學(xué)：X精品文檔精品文檔第3 章運(yùn)輸層答案： C8.(不要求掌握)考慮靜態(tài)擁塞窗口延時(shí)模型。如果服務(wù)器在完成第一個(gè)窗口中分組傳送前接收到了第一個(gè)窗口中的第一個(gè)分組的確認(rèn)信號(hào)，那么一個(gè)大小為

5、O的對(duì)象的延時(shí)為：A.Latency = 2 RTT + O/R + (K-1) S/R + RTT - WS/R B.Latency = 2 RTT + O/R - S/R - RTT +WS/RC.Latency = 2 RTT + O/RD.Latency = 2 RTT答案： C精品文檔精品文檔（不要求掌握）考慮動(dòng)態(tài)擁塞窗口延時(shí)模型。下面那些組成部分會(huì)導(dǎo)致延時(shí)：A.對(duì)象傳輸時(shí)間 O/RB.往返時(shí)間 RTTC.所有停滯時(shí)間之和D.以上所有的答案： D9.（不要求掌握）考慮動(dòng)態(tài)擁塞窗口延時(shí)模型。 P 的值等于：A.RTT/OB.服務(wù)器處于停滯的次數(shù)C.涵蓋該對(duì)象的窗口的數(shù)量D.以上都不是答

6、案： B二、判斷題1.考慮一個(gè)使用持久連接的HTTP1艮務(wù)器。假設(shè)服務(wù)器為每個(gè)用戶產(chǎn)生一個(gè)獨(dú)立的進(jìn)程。那么每一個(gè)進(jìn)程將有不同的服務(wù)器端口號(hào)。答案：錯(cuò)疑難：重點(diǎn)：一般：了解：自學(xué)：X精品文檔精品文檔第3 章運(yùn)輸層提示：HTTP勺默認(rèn)端口是80。一個(gè)Web!艮務(wù)器可以為它所處理的每個(gè)請(qǐng)求產(chǎn)生一個(gè)新的HTTP進(jìn)程，每個(gè)進(jìn)程都使用80 端口。2.主機(jī)A經(jīng)過TCP1接向主機(jī)B 發(fā)送一個(gè)大文件。假定主機(jī)B 沒有數(shù)據(jù)發(fā)往主機(jī)A那么由于主機(jī)B 不能隨數(shù)據(jù)捎帶確認(rèn)信息，所以主機(jī)B 將不向主機(jī)A發(fā)送確認(rèn)。精品文檔精品文檔答案：錯(cuò)提示：確認(rèn)并不是捎帶在數(shù)據(jù)上的。3.在整個(gè)連接過程持續(xù)期間，RcvWindow 的大小

7、是不會(huì)改變。答案：錯(cuò)提示：在全雙工連接中，連接雙方的發(fā)送方各自保留一個(gè)接收窗口以提供流量控制。接收窗口是動(dòng)態(tài)的，在連接的整個(gè)生命周期中是不斷變化的。4.假定主機(jī)A通過TC選接向主機(jī)B 發(fā)送一個(gè)大文件。如果對(duì)于當(dāng)前連接的一個(gè)報(bào)文段的順序號(hào)為簿則對(duì)于后續(xù)報(bào)文段的順序號(hào)將必然是 m+1。答案：錯(cuò) 提示：順序號(hào)的設(shè)定是以傳送的字節(jié)流為單位，而不 是以報(bào)文段為單位。一個(gè)報(bào)文段的順序號(hào) 是該報(bào)文段中數(shù)據(jù)段的第一個(gè)字節(jié)在字節(jié)流中的編號(hào)。5.tcps文段在它的首部中有一個(gè)RcvWindow 段。答案：對(duì)6.假定在一個(gè)TCP1接中最后的SampleRTT 于1s ，那么對(duì)于這一連接的TimeoutInterva

8、l 的當(dāng)前值必定n 1s。答案：錯(cuò)提示：超時(shí)時(shí)間是EstimatedRTT 和SampleRTT勺函數(shù)，不能由一個(gè)SampleRTT©決定。7.假定主機(jī)A通過TC選接向主機(jī)8. 發(fā)送一個(gè)順序號(hào)為38 的4 字節(jié)報(bào)文段。該報(bào)文段的確認(rèn)號(hào)必定是42。疑難：重點(diǎn)：一般：了解：自學(xué)：精品文檔精品文檔答案：錯(cuò)提示：某些情況下（比如該報(bào)文段發(fā)送超時(shí)）接收方會(huì)發(fā)送一個(gè)重復(fù)的ACK,即確認(rèn)號(hào)仍然是 38。8.假設(shè)主機(jī) A 希望通過 TCP 向主機(jī) B 發(fā)送數(shù)據(jù)，同時(shí)主機(jī) B 也希望通過TCP 向主機(jī) A 發(fā)送數(shù)據(jù)。那么就需要建立兩個(gè)TCP連接。答案：錯(cuò)提示：TCP1接提供了全雙工數(shù)據(jù)傳輸。9.MS牖

9、指包括頭部的TCP報(bào)文段的最大值。答案：錯(cuò)提示：NSS（最大數(shù)據(jù)段尺寸）對(duì)每次從緩沖區(qū)中攫取并放入數(shù)據(jù)段中的最大數(shù)據(jù)量進(jìn)行了限制。它是數(shù)據(jù)段中應(yīng)用程序級(jí)數(shù)據(jù)的最大量，而不是包括TCP頭部的報(bào)文段最大尺寸。10.在 TCP 中， 主機(jī)放入報(bào)文段中的確認(rèn)信號(hào)是主機(jī)期望從發(fā)送者收到的下一個(gè)字節(jié)的順序號(hào)。答案：對(duì)三、復(fù)習(xí)題3.13.3 節(jié)1 考慮在主機(jī)A和主機(jī)B之間有一條TCP連接。假 定從主機(jī)A傳送到主機(jī)B的TCP報(bào)文段使用的源端口號(hào)是x ，而目的端口號(hào)是y 。那么對(duì)于從主機(jī)B傳送到主機(jī)A的TCP報(bào)文段而言，源端口號(hào)和目的端口號(hào)分別是多少。答案：源端口號(hào)y ，目的端口號(hào)x 。2 請(qǐng)闡述應(yīng)用程序開發(fā)者

10、為什么更傾向于選擇在UDP±運(yùn)行應(yīng)用程序而不是在TCP上運(yùn)行的原因。答案：應(yīng)用程序的開發(fā)者也許不希望應(yīng)用程序使用TC硼塞控制機(jī)制。使用擁塞控制時(shí)會(huì)扼殺疑難：重點(diǎn)：一般：了解：自學(xué)：X精品文檔精品文檔第3 章運(yùn)輸層應(yīng)用程序的發(fā)送速率。一般來說， IP 電話和IP 視頻會(huì)議應(yīng)用程序的設(shè)計(jì)者會(huì)選擇UDP乍為低層協(xié)議，是因?yàn)橄Ｍ荛_TCP的擁塞控制。而且，其中一些應(yīng)用程序本來就不需要TC晦供的可靠數(shù)據(jù)傳輸。3A當(dāng)應(yīng)用程序運(yùn)行在UDP上時(shí)，某應(yīng)用程序是否能夠得到可靠的數(shù)據(jù)傳輸?如果能，如何實(shí)現(xiàn)？答案：可以。應(yīng)用程序的開發(fā)者可以在應(yīng)用層協(xié)議上提供可靠的數(shù)據(jù)傳輸，但這需要大量的工作和調(diào)試。精品文檔

11、精品文檔3.5 節(jié)4是非判斷題a)主機(jī)A經(jīng)過TC選接向主機(jī)B 發(fā)送一個(gè)大文件。假設(shè)主機(jī)B 沒有數(shù)據(jù)發(fā)往主機(jī)A因?yàn)橹鳈C(jī)B 不能隨數(shù)據(jù)捎帶確認(rèn)信息，所以主機(jī)B 將不向主機(jī)A發(fā)送確認(rèn)。b)在該連接的整個(gè)過程中，TCP的 RcvWindoW勺大小不會(huì)變化。c)假定主機(jī)A通過一個(gè)TCP1接向主機(jī)B 發(fā)送一個(gè)大文件。主機(jī)A發(fā)送的未被確認(rèn)的字節(jié)數(shù)不會(huì)超過接受緩存的大小。d)假定主機(jī)A通過TCP連接向主機(jī)B 發(fā)送一個(gè)大文件。如果對(duì)于當(dāng)前連接的一個(gè)報(bào)文段順序號(hào)為簿則對(duì)于后續(xù)報(bào)文段的順序號(hào)將必然是 m+1。e)TCP艮文段在它的首部中有一個(gè)RcvWindow 段。f)假定在一個(gè)TC選接中最后的SampleRTTi

12、F 于1s ，那么對(duì)于這一連接的TimeoutInterval的當(dāng)前值必定n 1s。g)假定主機(jī)A通過TC選接向主機(jī)B 發(fā)送一個(gè)順序號(hào)為38 的4 字節(jié)報(bào)文段。這一報(bào)文段的確認(rèn)號(hào)必定是42。答案： a) 錯(cuò) b) 錯(cuò)c) 對(duì) d) 錯(cuò) e) 對(duì) f) 錯(cuò) g) 錯(cuò)5假定主機(jī)A通過TC選接向主機(jī)B 連續(xù)發(fā)送兩個(gè)TCP艮文段。第一個(gè)報(bào)文段的順序號(hào)為90，第二個(gè)報(bào)文段順序號(hào)是110。a)第一報(bào)文段中有多少數(shù)據(jù)？b)假定第一個(gè)報(bào)文段丟失而第二個(gè)報(bào)文段到達(dá)主機(jī)B。那么在主機(jī)B 發(fā)往主機(jī)A的確認(rèn)報(bào)文中，確認(rèn)號(hào)應(yīng)該是多少？答案： a) 20 bytes b) 確認(rèn)號(hào) = 90疑難：重點(diǎn)：一般：了解：自學(xué)：精

13、品文檔精品文檔6考慮在3.5節(jié)討論中的Telnet的例子。在用戶鍵入字符 C 數(shù)秒之后，用戶又鍵入字符R 。那么在用戶鍵入字符 R 之后， 總共發(fā)送了多少個(gè)報(bào)文段，這些報(bào)文段的順序號(hào)和確認(rèn)號(hào)字段應(yīng)該是填入什么？答案： 3 個(gè)報(bào)文段。第一個(gè)報(bào)文段: ：順序號(hào) = 43, 確認(rèn)號(hào) =80第二個(gè)報(bào)文段：順序號(hào)= 80, 確認(rèn)號(hào) = 44第三個(gè)報(bào)文段; 順序號(hào) = 44, 確認(rèn)號(hào) = 813.7 節(jié)7假定兩個(gè)TCP連接存在于一個(gè)帶寬為R b/s的瓶頸鏈路上。它們都要發(fā)送一個(gè)很大的文件 （ 在瓶頸鏈路以相同的方向上傳輸） ， 并且兩者是同時(shí)開始傳輸文件。那么TCP將為每個(gè)連接分配多大的傳輸速率?答案：

14、R/28是非判斷題?？紤]TCP的擁塞控制，發(fā)送方在定 時(shí)器超時(shí)時(shí)，其閾值將被設(shè)置為原來值的一半。答案： 錯(cuò)誤。 其閥值被設(shè)置為當(dāng)前擁塞窗口值的一半。四、求解題1A假設(shè)客戶機(jī)A面向服務(wù)器S發(fā)起一個(gè)Telnet會(huì)話 與此同時(shí)，客戶機(jī)也向服務(wù)器S 發(fā)起一個(gè) Telnet會(huì)話。請(qǐng)給出下面報(bào)文段的源端口號(hào)和目的端口號(hào)。a)從A發(fā)往S的報(bào)文段。b)從B發(fā)往S的報(bào)文段。c) 從 S 發(fā)往 A 的報(bào)文段。d)從S發(fā)往B的報(bào)文段。e) 如果 A 和 B 是不同的主機(jī)，那么從A 發(fā)往 S 報(bào)文段的源端口號(hào)是否可能與從B 發(fā)往 S 的報(bào)文段的源端口號(hào)相同？f) 如果他們是同一臺(tái)主機(jī)情況會(huì)怎么樣？答案：源端口號(hào)目的端

15、口號(hào) 疑難：重點(diǎn)：一般：了解：自學(xué)：X精品文檔精品文檔第 3 章運(yùn)輸層a) A -S 467 23b) B -S 513 23c) S -A 23 467d) S -B 23 513e) 可能相同f) 不可能相同2A參見圖3-5。從服務(wù)器發(fā)回客戶機(jī)進(jìn)程的報(bào)文段中的源端口號(hào)和目的端口號(hào)是多少？傳送運(yùn)輸層報(bào)文段的網(wǎng)絡(luò)層數(shù)據(jù)報(bào)中的 IP 地址是多少？答案：假設(shè)主機(jī)A， B， C 的 IP 地址分別為 a， b， c 。 (注意a， b， c 各自獨(dú)立)對(duì)主機(jī) A： 源端口 80， 源 IP 為 b， 目的端口為 26145， 目的 IP 為 a精品文檔精品文檔對(duì)主機(jī)C左邊的進(jìn)程：源端口 80,源IP

16、為b,目的 端口為 7532，目的 IP 為 c對(duì)主機(jī)C右邊的進(jìn)程：源端口 80,源IP為b,目的 端口26145，目的IP 為 c3AUD可口 TCP使用1的補(bǔ)碼來計(jì)算校驗(yàn)和.假設(shè)你有下面 3 個(gè) 8 比特字節(jié)： 01010101 ， 01110000，01001100， 請(qǐng)問這些8 比特字節(jié)和的 1 的補(bǔ)碼是多少？（注意到盡管UDP和TCP使用16比特的字來計(jì)算校驗(yàn)和，但對(duì)于這個(gè)問題，你應(yīng)該考慮 8比特被加數(shù)。 ）寫出所有工作過程。 UDP為什么要用該和的 1 的補(bǔ)碼， 即為什么不直接使用該和呢？使用該1 的補(bǔ)碼方案，接收方如何檢測出差錯(cuò)？ 1 比特的差錯(cuò)將可能未被檢測出來嗎？2 比特的差

17、錯(cuò)呢？答案：01010101+01110000110 0 01011 1 0 0 0 1 0 1+0 1 0 0 1 1 0 0_0 0 0 1 0 0 1 0結(jié)果求補(bǔ)為 11101101進(jìn)行差錯(cuò)校驗(yàn)時(shí)，接收方將四個(gè)字一起相加（三個(gè)原有的字和一個(gè)校驗(yàn)和） 。如果校驗(yàn)和包含一個(gè)0，接收方將得知分組出現(xiàn)了差錯(cuò)。所有的一位錯(cuò)誤都將被檢驗(yàn)出來，但不能檢查出兩位出錯(cuò)的情況（比如，如果第一個(gè)字的最后一個(gè)位轉(zhuǎn)換成0，第二個(gè)字的最后一位被轉(zhuǎn)疑難：重點(diǎn)：一般：了解：自學(xué)：X精品文檔精品文檔第 3 章運(yùn)輸層換成 1) 。44考慮我們改正rdt2.1 協(xié)議的動(dòng)機(jī)?？紤]下圖所示的接收方與如果3-11 所示的發(fā)送方的運(yùn)

18、行時(shí)，該接收方可能會(huì)引起發(fā)送方和接收方進(jìn)入死鎖狀態(tài)，即雙方都在等待不可能發(fā)生的事件。請(qǐng)說明這種情況。答案：假定發(fā)送方處于“等待來自上層的調(diào)用 1”狀態(tài)，接收方處于“等待來自下層的1”狀態(tài)。發(fā)送方發(fā)送一個(gè)序號(hào)為 1 的數(shù)據(jù)報(bào)文后， 狀態(tài)轉(zhuǎn)換為“等待ACK/NAK 1"，即等待一個(gè)ACK或者NAKS文。假如現(xiàn)在接收方正確的接收到序號(hào)為1的數(shù)據(jù)報(bào)文，它發(fā)送一個(gè)ACK狀態(tài)轉(zhuǎn)為“等待來自下層的 0 ” ，即等待序號(hào)為0 的數(shù)據(jù)報(bào)文。但現(xiàn)在該ACK報(bào)文受損。當(dāng)發(fā)送者接收到受損的ACK,它重新發(fā)送序號(hào)為1的數(shù)據(jù)包。而這時(shí)的接收者因?yàn)橐恢痹诘却蛱?hào)為 0 的數(shù)據(jù)報(bào)文，將始終以 NAK 報(bào)文來響應(yīng)接收

19、到的序號(hào)為非0 的數(shù)據(jù)報(bào)文。在這種情況下，發(fā)送方始終發(fā)送序號(hào)為1的數(shù)據(jù)報(bào)文，而接收方始終以NAK作為回應(yīng)。雙 方將進(jìn)入死鎖狀態(tài)。5A在rdt3.0協(xié)議中，從接收方向發(fā)送方發(fā)送的 ACK分 組沒有序號(hào)（盡管他們具有 ACK字段，該域包括了他們正在確認(rèn)的分組的序號(hào)） 。 為什么這些 ACK 分組不需要序號(hào)呢？答案：解決這個(gè)問題， 最好首先要考慮我們?yōu)槭裁葱枰蛱?hào)。發(fā)送方使用序號(hào)，從而使接收方確認(rèn)是否接收到冗余的分組。對(duì)于 ACK分組，發(fā)送者并 不需要這樣的信息（AC6組上的序號(hào)）來疑難：重點(diǎn)：一般：了解：自學(xué)：確定是否是冗余的ACK。 在 rdt3.0 協(xié)議中， 一個(gè)冗余的ACK是顯而易見的，因?yàn)?/p>

20、接收到一個(gè)原先的ACK分組它就將轉(zhuǎn)換到下一個(gè)狀態(tài)。冗余的ACK 并非發(fā)送者所需從而將發(fā)送者被忽略。64畫出rtd3.0協(xié)議中接收方的有限狀態(tài)機(jī)（FSM的圖。答案：rdt3.0 協(xié)議和 rdt2.2 協(xié)議的發(fā)送方的不同在于前者有超時(shí)控制機(jī)制。超時(shí)控制的引入增加了發(fā)送方到接收方數(shù)據(jù)流中存在冗余分組的可能性。Rdt2.2 協(xié)議中的接收方已經(jīng)能夠處理冗余分組。（在rdt2.2中，如果接收方發(fā)送的ACK丟失，發(fā)送方將重新發(fā)送原數(shù)據(jù)）從而， rdt3.0中的接收方也像rdt2.2 中的接收方那樣工作。74畫出在數(shù)據(jù)分組和確認(rèn)分組發(fā)生混淆情況下，rdt3.0 協(xié)議的操作的軌跡。你畫的軌跡應(yīng)當(dāng)類似于圖 3-1

21、6 中使用的那個(gè)圖。答案：假定協(xié)議已經(jīng)執(zhí)行一段時(shí)間。發(fā)送者處于“等待來自上層的調(diào)用”狀態(tài)，接收者處于“等待來自下層的 0 ” 。數(shù)據(jù)分組和 ACK 分組發(fā)生損壞的場景如圖所示。疑難：重點(diǎn)：一般：了解：自學(xué)：X精品文檔精品文檔第 3 章運(yùn)輸層Sender sends M0Sender ignores A1Timeout: sender resends M0sender sends M0sender sends M1Ignore ACK Timeout: senderresends M1M0 corruptedA1M0A0精品文檔精品文檔M1A1M0A0M1A1 corruptedM1A1M0Pa

22、cket garbled, receiver resends last ACK (A1)CorrupteddataCorruptedACK圖 1: rdt 3.0 scenarios: corrupted data, corrupted ACK84考慮一個(gè)能夠丟失分組，但是其最大時(shí)延已知的信道。修改 rdt2.1 協(xié)議，以包括發(fā)送方超時(shí)和重傳機(jī)制。簡要論證為什么你的協(xié)議能夠通過該信道正確通信？答案：我們?cè)黾右粋€(gè)計(jì)時(shí)器，它的值大于已知的往返時(shí)延。我們還將一個(gè)超時(shí)事件增加到“等待ACK/NAK0 ” 和“等待ACK/NAK1 ” 狀態(tài)的變化事件中。如果超時(shí)事件發(fā)生，將重新傳輸最近發(fā)送的數(shù)據(jù)包。讓我們來看一下為什么這個(gè)協(xié)議能夠使該信道正確通信假定超時(shí)是由于在發(fā)送者到接受者的數(shù)據(jù)通道上發(fā)生數(shù)據(jù)包的丟失而產(chǎn)生。在這種情況下，接收者永遠(yuǎn)不會(huì)接收到原先的數(shù)據(jù)。以接收者的角度來看，當(dāng)超時(shí)重傳發(fā)生時(shí)，接收者并不知道這是重傳的分組，而把它當(dāng)作原先的數(shù)據(jù)一樣看待。.假定A