GBN&&SR窗口大小討論
本文旨在分析GBN&&SR窗口大小與分組序號數量之間的關系.
引用博客：計算機網絡——滑動窗口協議的窗口大小
總體結論
- 對於GBN而言，只需要滿足: 發送端滑動窗口的序號數目 <= 分組編號數目 - 1，便不會造成接受端識別錯誤的問題。
- 對於SR而言，只需要滿足: 發送端滑動窗口的序號數目 + 接受端滑動窗口的序號數目 <= 分組編號數目，便不會造成接受端識別錯誤的問題。
- 雖然，GBN沒有接受窗口，但是，我們可以假定其接受窗口為1，那么，可以綜合以上問題，得到：對於GBN && SR而言，只需要滿足: 發送端滑動窗口的序號數目 + 接受端滑動窗口的序號數目 <= 分組編號數目，便不會造成接受端識別錯誤的問題。
GBN分析
PS：這一部分引用，做了些許修改
- 分組編號數目 = 8
- 發送端滑動窗口的序號數目 = 8
發送方給接收方發送了幀編號0A，1A，2A，3A，4A，5A，6A，7A，共計8個幀，接收方均收到，並處理后提交給網絡層，並向發送方回饋ACK 0A~7A,並期待幀0B
然而回饋電路被雷劈了，所以ACK全部丟失，接收方等了好久，沒等到確認，認定自己工作失誤，發出去的東西沒有到達地點，於是重發了之前的0A~7A號幀
但是接收方不知道自己的信道被劈了啊！他還以為自己的ACK（A系列）被對方接收到了，還在喜滋滋等着第二波新幀，沒想到來的居然還是老人物。但是接收方臉盲啊，不把熟人當兄弟，一看來的還是0號大爺(它可分不清0B還是0A)，打頭的正好編號和自己需要的一樣，也看不出是不是新來的，就還是接收
這不就出錯了嗎！
所以我們得想辦法防止這種事出現：
窗口如果等於7，就不會有這種狗東行為出現：
發送方發出0A,1A,2A,3A,4A,5A,6A共計7個幀，接收方還是接收並發送A系列的ACK，且依舊全部丟失，發送方超時重傳0A~6A
但是這次情況不同了！
接收方發現來的人雖然數量沒變，但是編號對不上了啊！自己等的是7爺，怎么來的是0爺？來的人不對，混日子的不是我的兄弟，不收！
於是數據傳輸斷裂，但至少不會出錯了……最后黑鍋由閃電完美背起，鼓掌
SR分析
參看如下圖示，很容易想到只要滿足：發送端滑動窗口的序號數目 + 接受端滑動窗口的序號數目 <= 分組編號數目，就不會造成接受端識別錯誤問題。
