5-38.設(shè) TCP 的 ssthresh 的初始值為 8 (單位為報文段)。當(dāng)擁塞窗口上升到 12 時網(wǎng)絡(luò)發(fā)生了超時，TCP 使用慢開始和擁塞避免。試分別求出第 1 次到第 15 次傳輸?shù)母鲹砣翱诖笮?。你能說明擁塞控制窗口每一次變化的原因嗎？?

擁塞窗口大小及變化原因見下表：

輪次?? ?擁塞窗口?? ?擁塞窗口變化的原因
1?? ?????????1?? ?????????網(wǎng)絡(luò)發(fā)生了超時，TCP 使用慢開始算法
2?? ?????????2?? ?????????擁塞窗口值加倍
3?? ?????????4?? ?????????擁塞窗口值加倍
4?? ?????????8?? ?????????擁塞窗口值加倍，這是 ssthresh 的初始值
5?? ?????????9?? ?????????TCP 使用擁塞避免算法，擁塞窗口值加 1
6?? ?????????10? ? ? ? ? TCP 使用擁塞避免算法，擁塞窗口值加 1
7?? ?????????11? ? ? ? ? TCP 使用擁塞避免算法，擁塞窗口值加 1
8?? ?????????12? ? ? ? ??TCP 使用擁塞避免算法，擁塞窗口值加 1
9?? ?????????1? ? ????????網(wǎng)絡(luò)發(fā)生了超時，TCP 使用慢開始算法
10?? ???????2?? ?????????擁塞窗口值加倍
11?? ???????4?? ?????????擁塞窗口值加倍
12?? ???????6?? ?????????擁塞窗口值加倍，但到達(dá) 12 的一半時，改為擁塞避免算法
13? ? ? ? ? 7?? ?????????TCP 使用擁塞避免算法，擁塞窗口值加 1
14?? ???????8?? ?????????TCP 使用擁塞避免算法，擁塞窗口值加 1
15?? ???????9?? ?????????TCP 使用擁塞避免算法，擁塞窗口值加 1

注：依照原理，首先執(zhí)行 TCP 連接初始化，將擁塞窗口 cwnd 值置為 1；其次執(zhí)行慢開始算法，cwnd 按指數(shù)規(guī)律增長，因此隨后窗口大小分別為 2，4，8。當(dāng)擁塞窗口 cwnd = ssthresh 時，進(jìn)入擁塞避免階段，其窗口大小依次是 9，10，11，12，直到上升到 12 為止發(fā)生擁塞；然后把門限值 ssthresh 設(shè)置為當(dāng)前的擁塞窗口值乘以 0.5，門限值 ssthresh 變?yōu)?,；然后進(jìn)入慢開始，cwnd 值置為1，cwnd 按指數(shù)規(guī)律增長，隨后窗口大小分別為 1，2，4，6。當(dāng)擁塞窗口 cwnd = ssthresh 時，進(jìn)入擁塞避免階段，其窗口大小依次是 7，8，9。
?

5-39.TCP 的擁塞窗口 cwnd 大小與傳輸輪次 n 的關(guān)系如表所示：
?1）試畫出如教材中圖 5-25 所示的擁塞窗口與傳輸輪次的關(guān)系曲線。
（2）指明 TCP 工作在慢開始階段的時間間隔。
（3）指明 TCP 工作在擁塞避免階段的時間間隔。
（4）在第 16 輪次和第 22 輪次之后發(fā)送方是通過收到三個重復(fù)的確認(rèn)還是通過超時檢測到丟失了報文段？
（5）在第 1 輪次，第 18 輪次和第 24 輪次發(fā)送時，門限 ssthresh 分別被設(shè)置為多大？
（6）在第幾輪次發(fā)送出第 70 個報文段？
（7）假定在第 26 輪次之后收到了三個重復(fù)的確認(rèn)，因而檢測出了報文段的丟失，那么擁塞窗口 cwnd 和門限 ssthresh 應(yīng)設(shè)置為多大？
答：(1)

（2）慢開始時間間隔：[1, 6] 和 [23, 26]
（3）擁塞避免時間間隔：[6, 16] 和 [17, 22]
（4）在第 16 輪次之后發(fā)送方通過收到三個重復(fù)的確認(rèn)，檢測到丟失了報文段，因為題目給出，下一個輪次的擁塞窗口減半了。在第 22 輪次之后發(fā)送方通過超時，檢測到丟失了報文段，因為題目給出，下一個輪次的擁塞窗口下降到 1了。
（5）在第 1 輪次發(fā)送時，門限 ssthresh 被設(shè)置為 32，因為從第 6 輪次起就進(jìn)入了擁塞避免狀態(tài)，擁塞窗口每個輪次加 1。
在第 18 輪次發(fā)送時，門限 ssthresh 被設(shè)置為發(fā)生擁塞時擁塞窗口 42 的一半，即 21。
在第 24 輪次發(fā)送時，門限 ssthresh 被設(shè)置為發(fā)生擁塞時擁塞窗口 26 的一半，即 13。
（6）第 1 輪次發(fā)送報文段 1。（cwnd = 1）
第 2 輪次發(fā)送報文段 2， 3。（cwnd = 2）
第 3 輪次發(fā)送報文段 4 ~ 7。（cwnd = 4）
第 4 輪次發(fā)送報文段 8 ~ 15。（cwnd = 8）
第 5 輪次發(fā)送報文段 16 ~ 31。（cwnd = 16）
第 6 輪次發(fā)送報文段 32 ~ 63。（cwnd = 32）
第 7 輪次發(fā)送報文段 64 ~ 96。（cwnd = 33）
因此第 70 報文段在第 7 輪次發(fā)送出。
（7）檢測出了報文段的丟失時擁塞窗口 cwnd 是 8，因此擁塞窗口 cwnd 的數(shù)值應(yīng)當(dāng)減半，等于 4，而門限 ssthresh 應(yīng)設(shè)置為檢測出報文段丟失時的擁塞窗口 8 的一半，即 4。
40.TCP 在進(jìn)行流量控制時是以分組的丟失作為產(chǎn)生擁塞的標(biāo)志。有沒有不是因擁塞而引起的分組丟失的情況?如有，請舉出三種情況。
答：不是因為擁塞而引起分組丟失的情況是有的，舉例如下：
① 當(dāng) IP 數(shù)據(jù)報在傳輸過程中需要分片，但其中一個數(shù)據(jù)報片未能及時到達(dá)終點(diǎn)，而終點(diǎn)組裝 IP 數(shù)據(jù)報已超時，因而只能丟棄該數(shù)據(jù)報。
② IP 數(shù)據(jù)報已經(jīng)到達(dá)終點(diǎn)，但終點(diǎn)的緩存沒有足夠的空間存放此數(shù)據(jù)報。
③ 數(shù)據(jù)報在轉(zhuǎn)發(fā)過程中經(jīng)過一個局域網(wǎng)的網(wǎng)橋，但網(wǎng)橋在轉(zhuǎn)發(fā)該數(shù)據(jù)報的幀時沒有足夠的儲存空間而只好丟棄。

5-49.下面是以十六進(jìn)制格式存儲的一個 UDP 首部：
CB84000D001C001C
試問:
(1) 源端口號是什么？
(2) 目的端口號是什么？
(3) 這個用戶數(shù)據(jù)報的總長度是什么？
(4) 數(shù)據(jù)長度是多少？
(5)這個分組是從客戶到服務(wù)器還是從服務(wù)器到客戶？
(6) 客戶進(jìn)程是什么？
答：(1)源端口號是最前面的四位十六進(jìn)制數(shù)(CB84)16=(52100)10
(2)目的端口號是五到八位的十六進(jìn)制數(shù)(000D)16=(13)10
(3)用戶數(shù)據(jù)報的長度由九到十二位十六進(jìn)制數(shù)決定(001C)16=(28)10字節(jié)。
(4)數(shù)據(jù)長度=數(shù)據(jù)報長度-首部長度=28字節(jié)-8字節(jié)=20字節(jié)。
(5)因為目的端口是 13 （熟知端口），所以這個分組是從客戶到目的端口。
(6)從 RFC 867 可以得知，這個客戶進(jìn)程是 Daytime。當(dāng) Daytime 服務(wù)器收到客戶發(fā)送的 UDP 用戶數(shù)據(jù)報后，就把現(xiàn)在的日期和時間以 ASCII 碼字符串的形式返回給客戶。
?

5-52.UDP 和 IP 的不可靠程度是否相同? 請加以解釋。
答：① UDP 和 IP 都是無連接的協(xié)議和不可靠傳輸?shù)膮f(xié)議。UDP 用戶數(shù)據(jù)報和 IP 數(shù)據(jù)報的首部都有檢驗和字段。當(dāng)檢驗出現(xiàn)差錯時，就把收到的 UDP 用戶數(shù)據(jù)報或 IP 數(shù)據(jù)報丟棄。這是它們的相同之處。
② 但 UDP 和 IP 的可靠性是有些區(qū)別的。UDP 用戶數(shù)據(jù)報的檢驗和是既檢驗 UDP 用戶數(shù)據(jù)報的首部又檢驗整個的 UDP 用戶數(shù)據(jù)報的數(shù)據(jù)部分，而 IP 數(shù)據(jù)報的檢驗和僅僅檢驗 IP 數(shù)據(jù)報的首部。UDP 用戶數(shù)據(jù)報的檢驗和還增加了偽首部，即還檢驗了下面的 IP 數(shù)據(jù)報的源 IP 地址和目的 IP 地址。
?

5-62.TCP 連接處于 ESTABLISHED 狀態(tài)。以下的事件相繼發(fā)生：
（1）收到一個 FIN 報文段。
（2）應(yīng)用程序發(fā)送 “關(guān)閉” 報文。
在每一個事件之后，連接的狀態(tài)是什么？在每一個事件之后發(fā)生的動作是什么？
答：（1）處于 ESTABLISHED 狀態(tài)又能夠收到一個 FIN 報文段，只有 TCP 的服務(wù)器端而不會是客戶端。當(dāng)這個服務(wù)器端收到 FIN 時，服務(wù)器就向客戶端發(fā)送 ACK 報文段，并進(jìn)入到 CLOSE-WAIT 狀態(tài)。這是被動關(guān)閉。請注意，這時客戶端不會再發(fā)送數(shù)據(jù)了，但服務(wù)器端如還有數(shù)據(jù)要發(fā)送給客戶端，那么還是可以繼續(xù)發(fā)送的。
（2）應(yīng)用程序發(fā)送 “關(guān)閉” 報文給服務(wù)器，表明沒有數(shù)據(jù)要發(fā)送了。這時服務(wù)器就應(yīng)當(dāng)發(fā)送 FIN 報文段給客戶，然后轉(zhuǎn)換到 LAST-ACK 狀態(tài)，并等待來自客戶端的最后的確認(rèn)。

5-66.主機(jī) A 通過 TCP 連接向 B 發(fā)送一個很長的文件，因此這需要分成很多個報文段來發(fā)送。假定某一個 TCP 報文段的序號是 x，那么下一個報文段的序號是否就是 x + 1 呢？
答：假定某一個 TCP 報文段的序號是 x，那么下一個報文段的序號應(yīng)當(dāng)是 x+n，這里的 n 是這個報文段中的數(shù)據(jù)長度的字節(jié)數(shù)。如 n = 4000，那么下一個報文段的序號應(yīng)當(dāng)是 x + 4000。若此報文段中僅有一個字節(jié)的數(shù)據(jù)，則下一個報文段的序號才是 x + 1。
?文章來源地址http://www.zghlxwxcb.cn/news/detail-502727.html

到了這里，關(guān)于計算機(jī)網(wǎng)絡(luò)復(fù)習(xí)（五）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！