㈠ 滑動窗口協議的效率計算
LU = (W*T)/(T+rtt) ,這是滑動窗口的信道利用率,W代表窗口的大小,T代表每幀的發送時延,rtt代表往返的傳播時延。其中需要理解的是分母為啥是T+rtt,在滑動窗口傳輸過程中,發送第一個幀和接收第一個確認的時間幀之間發送了所有其他幀。示意圖如下:
文章出處:數據鏈路詳解--滑動窗口信道利用率
㈡ 計算機網路筆記——數據鏈路層(停等協議、GBN、SR)
流量控制:防止發送端發送和接收端接收速度不匹配造成傳輸錯誤
傳輸層和數據鏈路層均有流量控制,但是控制手法不一樣
傳輸層:端到端,接收端向發送端發送一個窗口公告。告訴發送端目前我能接收多少
數據鏈路層:點到點,接收端接收不下的就不回復確認(ack),讓發送端自己重傳
涉及協議較多分批寫
優點 :最簡單的控制協議
缺點 :但是性能較弱,信道利用率低
控制方法 :
發送方:發送一個幀
接收方:接收到幀後返回改幀的ack
發送方:接收到ack後發送下一個幀
差錯控制 :
注意 :
滑動窗口協議是基於停止等待協議的優化版本
停止等待協議性能是因為需要等待ack之後才能發送下一個幀,在傳送的很長時間內信道一直在等待狀態
滑動窗口則利用緩沖思想,允許連續發送(未收到ack之前)多個幀,以加強信道利用
窗口 :其實就是緩沖幀的一個容器,將處理好的幀發送到緩沖到窗口,可以發送時就可以直接發送,藉此優化性能。一個幀對應一個窗口。
GBN是滑動窗口中的一種,其中 發送窗口 > 1 , 接收窗口=1 因發送錯誤後需要退回到最後正確連續幀位置開始重發,故而得名。
控制方法 :
發送端:在將發送窗口內的數據連續發送
接收端:收到一個之後向接收端發送累計確認的ack
發送端:收到ack後窗口後移發送後面的數據
累計確認 :累計確認允許接收端一段時間內發送一次ack而不是每一個幀都需要發送ack。該確認方式確認代表其前面的幀都以正確接收到
eg:發送端發送了編號 0,1,2,3,4,5 的幀,等待一段時間後(超過3的超時計時器)累計收到的ack對應 0,2 幀,則證明已經成功 0,1,2 均已經成功接收, 3 傳輸錯誤。並且哪怕 4,5 兩個幀接收成功後也不會返回 4,5 的ack會一直等待從 3 開始重傳
差錯控制 :
發送幀丟失、ack丟失、ack遲到 等處理方法基本和停等協議相同,不同的是採用累計確認恢復的方式,當前面的幀出錯之後後面幀無論是否發送成功都要重傳
優點:信道利用率高(利用窗口有增加發送端佔用,並且減少ack回復次數)
缺點:累計確認使得該方法只接收正確順序的幀,而不接受亂序的幀,錯誤重傳浪費嚴重
發送窗口大小問題
窗口理論上是越多性能越好,但是窗口不能無限大,n比特編碼最大隻能2^(n-1)個窗口,否則會造成幀無法區分(本質就是留了一個比特區分兩組幀)
SR協議可以說是GBN的plus版本,在GBN的基礎上改回每一個幀都要確認的機制,解決了累計確認只接收順序幀的弊端只需要重發錯誤幀。
其中 發送窗口 > 1 , 接收窗口 > 1 , 接收窗口 > 發送窗口 (建議接 收窗口 = 發送窗口 接收窗口少了溢出多了浪費).
控制方法 :
發送端:將窗口內的數據連續發送
接收端:收到一個幀就將該幀緩存到窗口中並回復一個ack
接收端:接收到順序幀後將數據提交給上層並接收窗口後移(若接收到的幀不是連續的順序幀時接收窗口不移動)
發送端:接收到順序幀的ack後發送窗口後移(同理發送窗口接收到的ack不連續也不移動)
差錯控制 :
發送幀丟失、ack丟失、ack遲到 三類處理方式仍然和停等協議相同,不同的是SR向上層提交的是多個連續幀,停等只提交一個幀(不連續的幀要等接收或重傳完成後才會提交)
發送窗口大小問題
同GBN一樣,發送窗口和接收窗口都不能無限多,且不說緩存容量問題,當兩組幀同時發送時會造成無法區分,大小上限仍然是2^(n-1)個窗口(本質就是留了一個比特寫組號)
窗口大小這里留一張截圖,方便理解
假設窗口大小都為3(圖中編號到了3是借4窗口的圖,正常應編號到2,但是不妨礙理解)
左邊是錯誤重發,第一組的0幀ack丟失了
右邊是正常收發
三種協議對比:
停等協議:單線程的傻子,簡單不易出錯,但是效率極其低下
GBN:假的多線程(接收端太坑啦),接收端是情種,只等待自己哪一個幀,丟棄了後來的幀
SR:多線程,接收端有收藏癖,等待集齊一套召喚神龍(提交給上層這只神龍……)
㈢ 計算機網路 滑動窗口
這里採用的是TCP,TCP連接是面向位元組的,也就是以位元組為最小單位。
接下來的組幀和分組也以位元組為具有實際意義最小單位。
發送窗口=min{擁塞窗口,接收端窗口}。沒其他的關系了。
㈣ TCP滑動窗口的功能是什麼
滑動窗口本質上是描述接受方(本地)的TCP數據報緩沖區大小的數據,發送方根據這個數據來計算自己最多能發送多長的數據。如果發送方收到接受方的窗口大小為0的TCP數據報,那麼發送方將停止發送數據,等到接受方發送窗口大小不為0的數據報的到來
㈤ 請教一道計算機網路關於滑動窗口的題目
你的想法不能說錯,但是在這個方向上無法得到最優解。
現實情況是為了防止窗口發生重疊,發送窗口維持最大容量的一半就已經非常充分了。序號總共n位,那麼整個發送空間撐死只有2^n幀,所以發送窗口有2^(n-1)就足以應付最惡劣情況下的重傳。無論是選擇重傳、還是回退N幀都是如此。
換個角度而言,真的像你所述,發送方要維持2^n-1幀的窗口——我的天,按照這個思路,是不是鐵路必須設計成能夠同時容納運輸14億人的容量呢?顯然這是不合理、不經濟的……
就像解三角函數一樣,如果你僅僅根據sin、cos函數在[-1,1]這個范圍內,或許能夠得到一個解集,然而這個解集遠非最優;還需要根據其他條件進一步縮小范圍。
㈥ 滾動預測和滑動窗口有區別嗎
有區別
在計算機網路中,滑動窗口協議是一種在網路上傳輸數據的方法。滑動窗口協議應用於OSI模型的數據鏈路層。在數據鏈路層,數據採用幀的形式。在聯網中,窗口僅表示具有需要傳輸的數據幀的緩沖區。
滾動預測不同於傳統預測,因為滾動預測是連續的,不考慮每年的財政年度結束期間。滾動預測包含的期間基於為滾動預測預定義的窗口滾動。這些期間通常是按月或季度定義的。
㈦ 計算機網路-可靠傳輸-滑動窗口協議
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的通信是全雙工通信。通信中的每一方都在發送和接收報文段。因此,每一方都有自己的發送窗口和接收窗口。在談到這些窗口時,一定要弄清是哪一方的窗口。
㈧ 請教關於計算機網路滑動窗口一題
接收窗口:到底是「每接收一幀數據,窗口後沿移動一格」還是「每應答一幀數據,窗口後沿移動一格」?如果是「接受」的話,題目中接收窗口已經接受了4幀數據了啊!
㈨ 計算機網路中的滑動窗口協議中的窗口是指什麼
窗口 只是個形象的描述而已
在發送數據的時候 收發雙方要做到 收發同步 不能發送方 發得快 而接收方 去接受的慢
所以 就讓 接收方 告訴 發送方 我的接受緩存還有 多少空閑 你這次能發送多少數據給我 多於這個值了 我就接受不下了
其實 窗口 也就是值得 發送方 發送數據的 窗口大小
祝你玩得愉快
不懂了可以hi我
㈩ 在計算機網路考試中,問:TCP流量控制中,滑動窗口的特點。有誰能總結一下
只有在接收窗口向前滑動時(與此同時也發送了確認),發送窗口才有可能向前滑動。
收發兩端的窗口按照以上規律不斷地向前滑動,因此這種協議又稱為滑動窗口協議。
當發送窗口和接收窗口的大小都等於 1時,就是停止等待協議。
當發送窗口大於1,接收窗口等於1時,就是回退N步協議。
當發送窗口和接收窗口的大小均大於1時,就是選擇重發協議。
協議中規定,對於窗口內未經確認的分組需要重傳。這種分組的數量最多可以等於發送窗口的大小,即滑動窗口的大小n減去1(因為發送窗口不可能大於(n-1),起碼接收窗口要大於等於1)。