停等協議的弊端：
停等協議大多數時間都在等待(空閑)，發送的時間占比比較低
浪費資源、太閑了
改善：
1.現在要連續發送多個幀，每個幀編號不同，便於出錯我們定位是哪一個幀，因此幀的編號必須擴充。
- 停等協議的緩沖區只有一個，因為它一次只能發送一個幀，出錯的話，直接取緩沖區中唯一的一個幀；但是采用連續發送多個幀，自然緩沖區就得擴容，擴充之后的緩沖區放入每個幀對應的拷貝，當發送出現問題需要再次發送的時候，就可以在大號緩沖區中找到對應的拷貝，供再次發送。
引入GBN、SR協議
GBN協議(后退N幀協議)
接收窗口接收到0#幀之后，就會返回一個0#確認幀，緊接着接收窗口的窗口就會向后移動一個，接收窗口變成1；然后，發送窗口收到0#確認幀之后，發送窗口也會向后移動一個窗口
發送窗口有6個並不表示這6個都會連續發送，而是可能會2個、3個連續發送。發送窗口可能不一定會被填滿，6個窗口的發送窗口，可能目前只有2、3個幀，剩下位置是空的。
GBN發送方必須做的三件事：
-
發送方必須先檢查發送窗口是否已滿，要是滿的話，發送方會告訴上層 發送窗口已滿，等一會再發送（實際情況是上層還是會發給發送方的緩沖區）；要是沒有滿，上層就會把數據發送給發送窗口
-
累計確認：累計確認就是指 對n號幀累計確認，不僅暗示已經收到了n號幀，而且收到了n號幀之前的所有幀。 正是由於累計確認的方式，GBN方式下不用對每一個幀都返回確認幀，可以每隔幾個幀返回確認幀。這樣比較高效
-
超時事件(后退N幀) 沒收到的幀以及沒收到的幀之后的幀，隨后會再次被發送
比如說，發送方發送出去n號幀，但是n號幀在路上丟失了，但是n+1,n+2這兩個幀仍然順利發送出去；但是接收方接收窗口只能容納一個幀，此時的接收方（根據前面的n-1號幀）還是期望收到一個n號幀，所以面對發來的n+1,n+2號幀還是丟棄。一直到n號幀因為超時重傳被再次發送過來，n+1,n+2號幀會隨n號幀之后被再次發送過來。
GBN接收方要做的三件事：
-
如果正確收到n號幀，並且n號幀之前的幀也都按序，那么只發送一個ack n 幀給發送方
-
如果有幀丟失以及其他出錯情況，比如發送出去 1 2 4 5這樣4個幀，3號幀丟失，接收方會陸續收到1 2 幀，之后，期待的是3號幀，但是發現傳來的是4號幀和5號幀，就會把4 5號幀丟棄，並返回一個ack 2給發送方，發送方收到ack 2之后，就會把3 4 5幀又全部的發送出去。
發送幀一般是連續連續的發送，遇到編號不連續（丟幀）的幀，把連續部分發送出去，不連續部分二次連續的發送出去
幀編號（比特位數）和發送窗口長度的關系： 發送窗口長度小於幀編號
幀編號(由比特位數決定，比如max{0 1 2 3 4 5 6 7}) \(>\) 發送窗口長度
- 累計確認(偶爾捎帶確認)
- 接收方只按序接收幀，無序則 丟掉
- 遇到差錯的 確認序列號會是前面有序幀序號最大值的ack值，比如ack 2返回給發送方，3號幀以及以后的幀則會重發
- 發送窗口最大值是 \(2^n-1\) ，接收窗口1
GBN協議的性能：
缺點：丟失的幀出錯，不僅要把丟失的幀重傳，還要把丟失的幀之后的幀也得重傳
因為連續發送提高了信道利用率
重傳時必須把原來正確的數據幀重傳，傳送效率降低