㈠ 請教關於計算機網路滑動窗口一題
發送窗口：每發送一幀數據，窗口後沿移動一格；每接收一幀應答，窗口前沿移動一格；接收窗口：每接收一幀數據，窗口後沿移動一格；每發送一幀應答，窗口前沿移動一格；所以 此時發送窗口將要發送的幀序號為（ D、4），接收窗口的上邊界對應的幀序號為（ B、2 ）
㈡ 關於計算機通信網路的一道滑動窗口題目
窗口大小為7就是表示發送和接收之間可以相差6個幀，如果B回復A他收到的幀的編號為m,那麼A最多發送的數據幀編號只要不大於m+7就可以繼續發。協議都是認為正確的，如果大於m+7那麼協議就認為傳輸有錯誤。如：B回復A他已經收到的最後一幀的編號為1，那麼A發送的數據幀的編號只要不大於8，那麼他就可以繼續順序發下去，如果大於8那麼就認為傳輸出錯了，那麼就要重發。A是順序發的，所以A發送的幀編號為4。
㈢ 計算機網路中的滑動窗口協議中的窗口是指什麼
窗口 只是個形象的描述而已
在發送數據的時候 收發雙方要做到 收發同步 不能發送方 發得快 而接收方 去接受的慢
所以 就讓 接收方 告訴 發送方 我的接受緩存還有 多少空閑 你這次能發送多少數據給我 多於這個值了 我就接受不下了
其實 窗口 也就是值得 發送方 發送數據的 窗口大小
祝你玩得愉快
不懂了可以hi我
㈣ 請教一道計算機網路關於滑動窗口的題目
你的想法不能說錯，但是在這個方向上無法得到最優解。
現實情況是為了防止窗口發生重疊，發送窗口維持最大容量的一半就已經非常充分了。序號總共n位，那麼整個發送空間撐死只有2^n幀，所以發送窗口有2^(n-1)就足以應付最惡劣情況下的重傳。無論是選擇重傳、還是回退N幀都是如此。
換個角度而言，真的像你所述，發送方要維持2^n-1幀的窗口——我的天，按照這個思路，是不是鐵路必須設計成能夠同時容納運輸14億人的容量呢？顯然這是不合理、不經濟的……
就像解三角函數一樣，如果你僅僅根據sin、cos函數在[-1,1]這個范圍內，或許能夠得到一個解集，然而這個解集遠非最優；還需要根據其他條件進一步縮小范圍。
㈤ 計算機網路-可靠傳輸-滑動窗口協議
TCP的滑動窗口是以位元組為單位的 。為了便於說明滑動窗口的工作原理，我們故意把後面圖5-15至圖5-18中的位元組編號都取得很小。現假定A收到了B發來的確認報文段，其中窗口是20位元組，而 確認號是31 （這表明 B期望收到的下一個序號是31 ，而序號30為止的數據已經收到了)。根據這兩個數據，A就構造出自己的發送窗口。
我們先討論發送方A的發送窗口。發送窗口表示：在沒有收到B的確認的情況下，A可以連續把窗口內的數據都發送出去。凡是已經發送過的數據，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。
發送窗口裡面的序號表示允許發送的序號。顯然，窗口越大，發送方就可以在收到對方確認之前連續發送更多的數據，因而可能獲得更高的傳輸效率。接收方會把自己的接收窗口數值放在窗口欄位中發送給對方。因此，A的發送窗口一定不能超過B的接收窗口數值。發送方的發送窗口大小還要受到當時網路擁塞程度的制約。但在目前，暫不考慮網路擁塞的影響。
發送窗口後沿的後面部分表示己發送且己收到了確認。這些數據顯然不需要再保留了。而發送窗口前沿的前面部分表示不允許發送的，因為接收方都沒有為這部分數據保留臨時存放的緩存空間。
發送窗口的位置由窗口前沿和後沿的位置共同確定。發送窗口後沿的變化情況有兩種可能，即不動（沒有收到新的確認）和前移（收到了新的確認）。發送窗口後沿不可能向後移動，因為不能撤銷掉已收到的確認。發送窗口前沿通常是不斷向前移動，但也有可能不動。這對應於兩種情況：一是沒有收到新的確認，對方通知的窗口大小也不變；二是收到了新的確認但對方通知的窗口縮小了，使得發送窗口前沿正好不動。
發送窗口前沿 也有可能 向後收縮 。這發生在對方通知的窗口縮小了。但 TCP的標准強烈不贊成 這樣做。因為很可能發送方在收到這個通知以前已經發送了窗口中的許多數據，現在又要收縮窗口，不讓發送這些數據，這樣就會產生一些錯誤。
現在假定A發送了序號為31-41的數據。這時， A發送窗口位置並未改變 （圖5-16），但發送窗口內靠後面有11個位元組（31~41）表示己發送但未收到確認。而發送窗口內靠前面的9個位元組(42~50)是允許發送但尚未發送的。
從以上所述可以看出，要描述一個發送窗口的狀態需要三個指針：P1,P2和P3(圖5-16)。指針都指向位元組的序號。這三個指針指向的幾個部分的意義如下：
小於P1的是已發送並已收到確認的部分，而大於P3的是不允許發送的部分。
P3-P1=A的發送窗口
P2-P1=己發送但尚未收到確認的位元組數
P3-P2=允許發送但當前尚未發送的位元組數（又稱為 可用窗口或有效窗口 ）
再看一下B的接收窗口。B的接收窗口大小是20。在接收窗口外面，到30號為止的數據是已經發送過確認，並且己經交付主機了。因此在B可以不再保留這些數據。接收窗口內的序號(31~50)是允許接收的。在圖5-16中，B收到了序號為32和33的數據。這些數據沒有按序到達，因為序號為31的數據沒有收到（也許丟失了，也許滯留在網路中的某處)。請注意，B只能對按序收到的數據中的最高序號給出確認，因此B發送的確認報文段中的確認號仍然是31（即期望收到的序號），而不能是32或33。
現在假定B收到了序號為31的數據，並把序號為31~33的數據交付主機，然後B刪除這些數據。接著把接收窗口向前移動3個序號（圖5-17），同時給A發送確認，其中窗口值仍為20，但確認號是34。這表明B已經收到了到序號33為止的數據。我們注意到，B還收到了序號為37,38和40的數據，但這些都沒有按序到達，只能先暫存在接收窗口中，等待缺少的數據到達。A收到B的確認後，就可以把發送窗口向前滑動3個序號，但指針P2不動。可以看出，現在A的可用窗口增大了，可發送的序號范圍是42~53。
A在繼續發送完序號42~53的數據後，指針P2向前移動和P3重合。發送窗口內的序號都已用完，但還沒有再收到確認（圖5-18）。由於A的發送窗口已滿，可用窗口已減小到零，因此必須停止發送。請注意，存在下面這種可能性，就是發送窗口內所有的數據都已正確到達B,B也早已發出了確認。但不幸的是，所有這些確認都滯留在網路中。在沒有收到B的確認時，A不能猜測：「或許B收到了吧！」為了保證可靠傳輸，A只能認為B還沒有收到這些數據。於是，A在經過一段時間後（由超時計時器控制）就重傳這部分數據，重新設置超時計時器，直到收到B的確認為止。如果A收到確認號落在發送窗口內，那麼A就可以使發送窗口繼續向前滑動，並發送新的數據。
我們在前面的圖5-18中曾給出了這樣的概念：發送方的應用進程把位元組流寫入TCP的發送緩存，接收方的應用進程從TCP的接收緩存中讀取位元組流。
窗口和緩存的關系
第一，緩存空間和序號空間都是有限的，並且都是循環使用的。最好是把它們畫成圓環狀的，但這里為了畫圖的方便，我們還是把它們畫成長條狀的。
第二，由於實際上緩存或窗口中的位元組數是非常之大的，因此圖5-19（a發送緩存和發送窗口，b接收緩存和接收窗口）僅僅是個示意圖，沒有標出具體的數值。但用這樣的圖米說明緩存和發送窗口以及接收窗口的關系是很清楚的。
發送緩存用來暫時存放：
(1)發送應用程序傳送給發送方TCP准備發送的數據；
2)TCP已發送出但尚未收到確認的數據。
發送窗口通常只是發送緩存的一部分，已被確認的數據應當從發送緩存中刪除，因此發送緩存和發送窗口的後沿是重合的。發送應用程序最後寫入發送緩存的位元組減去最後被確認的位元組，就是還保留在發送緩存中的被寫入的位元組數。發送應用程序必須控制寫入緩存的速率，不能太快，否則發送緩存就會沒有存放數據的空間。
接收緩存用來暫時存放：
(1)按序到達的、但尚未被接收應用程序讀取的數據；
(2)末按序到達的數據。
如果收到的分組被檢測出有差錯，則要丟棄。如果接收應用程序來不及讀取收到的數據，接收緩存最終就會被填滿，使接收窗口減小到零。反之，如果接收應用程序能夠及時從接收緩存中讀取收到的數據，接收窗口就可以增大，但最大不能超過接收緩存的大小。圖5-19(b)中還指出了下一個期望收到的位元組號。這個位元組號也就是接收方給發送方的報文段的首部中的確認號。
根據以上所討論的，我們還要再強調以下三點。
第一，雖然A的發送窗口是根據B的接收窗口設置的，但在同一時刻，A的發送窗口並不總是和B的接收窗口一樣大。這是因為通過網路傳送窗口值需要經歷一定的時間滯後(這個時間還是不確定的)。另外，發送方A還可能根據網路當時的擁塞情況適當減小自己的發送窗口數值。
第二，對於不按序到達的數據應如何處理，TCP標准並無明確規定。如果接收方把不按序到達的數據一律丟棄，那麼接妝窗口的管理將會比較簡單，但這樣做對網路資源的利用不利（因為發送方會重復傳送較多的數據）。因此TCP通常對不按序到達的數據是先臨時存放在接收窗口中，等到位元組流中所缺少的位元組收到後，再按序交付上層的應用進程。
第三，TCP要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。接收方可以在合適的時候發送確認，也可以在自己有數據要發送時把確認信息順便梢帶上。但請注意兩點。一是接收方不應過分推遲發送確認，否則會導致發送方不必要的重傳，這反而浪費了網路的資源。TCP標准規定，確認推遲的時間不應超過0.5秒。若收到一連申具有最大長度的報文段，則必須每隔一個報文段就發送一個確認。二是梢帶確認實際上並不經常發生，因為大多數應用程序很少同時在兩個方向上發送數據。
最後再強調一下，TCP的通信是全雙工通信。通信中的每一方都在發送和接收報文段。因此，每一方都有自己的發送窗口和接收窗口。在談到這些窗口時，一定要弄清是哪一方的窗口。
㈥ 計算機網路 設計一個類似於TCP的滑動窗口協議,
這個問題最關鍵是在於窗口大小的計算和每幀長度的確定。至於具體的過程活動窗口協議很多網路一下就有，把下面計算出來的參數套一下就完事~~。
假設每幀傳輸1Kb,
則傳輸一個幀所需時間為： 發送時間 + 信息信道延遲 + 確認信道延遲（確認幀很短，忽略發送時間）= 1kb / 100Mbps + RTT/2+ RTT/2= 100ms+ 0.01ms 信道利用率 = 0.01/ 100.001=0.01%.
要使信道利用率達到更高，可一次發送的幀數量為100/0.01=10000，上面的K=1000，為了計算方便。
也就是說，當幀長度1kb時，發送窗口最大可以達到10000.
協議頭部的窗口欄位和序號欄位最少應該有多少比特？
應該有16bit，因為8bit的最大值才512。
我也是在網上找的，不知道准確不準確。
㈦ 在計算機網路考試中，問：TCP流量控制中，滑動窗口的特點。有誰能總結一下
只有在接收窗口向前滑動時（與此同時也發送了確認），發送窗口才有可能向前滑動。
收發兩端的窗口按照以上規律不斷地向前滑動，因此這種協議又稱為滑動窗口協議。
當發送窗口和接收窗口的大小都等於 1時，就是停止等待協議。
當發送窗口大於1，接收窗口等於1時，就是回退N步協議。
當發送窗口和接收窗口的大小均大於1時，就是選擇重發協議。
協議中規定，對於窗口內未經確認的分組需要重傳。這種分組的數量最多可以等於發送窗口的大小，即滑動窗口的大小n減去1（因為發送窗口不可能大於（n-1），起碼接收窗口要大於等於1）。
㈧ 計算機網路 滑動窗口
我們計算窗口的大小的時候用位元組表示，比如50位元組等，發送窗口和擁塞床窗口不是一個概念，擁塞窗口隨著傳輸的次數的增加會變化，具體的變化策略和網路所採用的策略相關，擁塞是用來實現實現網路的擁塞控制的！具體的你在網路中隨手搜擁塞控制，就能明白！發送窗口，也是變化！但是擁塞窗口的大小是發送窗口的上限！發送窗口的大小由擁塞窗口大小和接受端的所給定的能接受的大小共同決定！時間有些長，不能說的太具體，怕錯誤太多了！如果有事么不懂，將我回答的關鍵字在網路中查找就能明白說的意思！
㈨ TCP滑動窗口的功能是什麼
滑動窗口本質上是描述接受方（本地）的TCP數據報緩沖區大小的數據，發送方根據這個數據來計算自己最多能發送多長的數據。如果發送方收到接受方的窗口大小為0的TCP數據報，那麼發送方將停止發送數據，等到接受方發送窗口大小不為0的數據報的到來