當前位置:首頁 » 網路連接 » 計算機網路滑動窗口的計算
擴展閱讀
電腦被黑屏了怎麼處理 2025-06-21 03:57:38

計算機網路滑動窗口的計算

發布時間: 2022-06-22 10:17:13

計算機網路 滑動窗口

我們計算窗口的大小的時候用位元組表示,比如50位元組等,發送窗口和擁塞床窗口不是一個概念,擁塞窗口隨著傳輸的次數的增加會變化,具體的變化策略和網路所採用的策略相關,擁塞是用來實現實現網路的擁塞控制的!具體的你在網路中隨手搜擁塞控制,就能明白!發送窗口,也是變化!但是擁塞窗口的大小是發送窗口的上限!發送窗口的大小由擁塞窗口大小和接受端的所給定的能接受的大小共同決定!時間有些長,不能說的太具體,怕錯誤太多了!如果有事么不懂,將我回答的關鍵字在網路中查找就能明白說的意思!

㈡ 滑動窗口協議的效率計算

LU = (W*T)/(T+rtt) ,這是滑動窗口的信道利用率,W代表窗口的大小,T代表每幀的發送時延,rtt代表往返的傳播時延。其中需要理解的是分母為啥是T+rtt,在滑動窗口傳輸過程中,發送第一個幀和接收第一個確認的時間幀之間發送了所有其他幀。示意圖如下:

文章出處:數據鏈路詳解--滑動窗口信道利用率

㈢ 請教關於計算機網路滑動窗口一題

發送窗口:每發送一幀數據,窗口後沿移動一格;每接收一幀應答,窗口前沿移動一格;接收窗口:每接收一幀數據,窗口後沿移動一格;每發送一幀應答,窗口前沿移動一格;所以 此時發送窗口將要發送的幀序號為( D、4),接收窗口的上邊界對應的幀序號為( B、2 )

㈣ 計算機網路 設計一個類似於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。
我也是在網上找的,不知道准確不準確。

㈤ 關於計算機通信網路的一道滑動窗口題目

窗口大小為7就是表示發送和接收之間可以相差6個幀,如果B回復A他收到的幀的編號為m,那麼A最多發送的數據幀編號只要不大於m+7就可以繼續發。協議都是認為正確的,如果大於m+7那麼協議就認為傳輸有錯誤。如:B回復A他已經收到的最後一幀的編號為1,那麼A發送的數據幀的編號只要不大於8,那麼他就可以繼續順序發下去,如果大於8那麼就認為傳輸出錯了,那麼就要重發。A是順序發的,所以A發送的幀編號為4。

㈥ 請教一道計算機網路關於滑動窗口的題目

你的想法不能說錯,但是在這個方向上無法得到最優解。
現實情況是為了防止窗口發生重疊,發送窗口維持最大容量的一半就已經非常充分了。序號總共n位,那麼整個發送空間撐死只有2^n幀,所以發送窗口有2^(n-1)就足以應付最惡劣情況下的重傳。無論是選擇重傳、還是回退N幀都是如此。
換個角度而言,真的像你所述,發送方要維持2^n-1幀的窗口——我的天,按照這個思路,是不是鐵路必須設計成能夠同時容納運輸14億人的容量呢?顯然這是不合理、不經濟的……
就像解三角函數一樣,如果你僅僅根據sin、cos函數在[-1,1]這個范圍內,或許能夠得到一個解集,然而這個解集遠非最優;還需要根據其他條件進一步縮小范圍。

㈦ TCP滑動窗口的功能是什麼

滑動窗口本質上是描述接受方(本地)的TCP數據報緩沖區大小的數據,發送方根據這個數據來計算自己最多能發送多長的數據。如果發送方收到接受方的窗口大小為0的TCP數據報,那麼發送方將停止發送數據,等到接受方發送窗口大小不為0的數據報的到來

㈧ 在計算機網路考試中,問:TCP流量控制中,滑動窗口的特點。有誰能總結一下

只有在接收窗口向前滑動時(與此同時也發送了確認),發送窗口才有可能向前滑動。
收發兩端的窗口按照以上規律不斷地向前滑動,因此這種協議又稱為滑動窗口協議。
當發送窗口和接收窗口的大小都等於 1時,就是停止等待協議。
當發送窗口大於1,接收窗口等於1時,就是回退N步協議。
當發送窗口和接收窗口的大小均大於1時,就是選擇重發協議。
協議中規定,對於窗口內未經確認的分組需要重傳。這種分組的數量最多可以等於發送窗口的大小,即滑動窗口的大小n減去1(因為發送窗口不可能大於(n-1),起碼接收窗口要大於等於1)。