在理解GBN協議之前，先了解滑動窗口是怎么回事？
在任意時刻，發送方都維持了一個連續的允許發送的幀的序號，稱為發送窗口；同時，接收方也維持了一個連續的允許接收的幀的序號，稱為接收窗口。發送窗口和接收窗口的序號的上下界不一定要一樣，甚至大小也可以不同。不同的滑動窗口協議窗口大小一般不同。發送方窗口內的序列號代表了那些已經被發送，但是還沒有被確認的幀，或者是那些可以被發送的幀。
若從滑動窗口的觀點來統一看待停等、后退n及選擇重傳三種協議，它們的差別僅在於各自窗口尺寸的大小不同而已。停等：發送窗口= 1，接收窗口=1； 后退n協議：發送窗口>1，接收窗口=1；選擇重傳協議：發送窗口>1,接受窗口>1;
停等協議很好理解，這里主要解釋后退n協議和選擇重傳協議。
GBN協議中，發送方在發完一個數據幀后，連續發送若干個數據幀，即使在連續發送過程中收到了接收方發來的應答幀，也可以繼續發送。且發送方在每發送完一個數據幀時都要設置超時定時器。只要在所設置的超時時間內仍未收到確認幀，就要重發相應的數據幀。如：當發送方發送了N個幀后，若發現該N幀的前一個幀在計時器超時后仍未返回其確認信息，則該幀被判為出錯或丟失，此時發送方就不得不重新發送出錯幀及其后的N幀。
接受幀只允許按順序接受幀。為了減少開銷，累計確認允許接收端在連續收到好幾個正確的確認幀后，只對最后一個數據幀發確認信息，或者可以在自己有數據要發送時才將對以前正確收到的幀加以捎帶確認。這就是說，對某一數據幀的確認就表明該數據幀和這以前所有的數據幀均已正確無誤地收到了。
后退N幀協議的接受窗口為1，可以保證按序接受數據幀。若采用n個比特對幀編號，則其發送窗口的尺寸應滿足：1~2^(n-1)。若發送窗口的尺寸大於2^(n-1)，則會造成接受方無法分辨新幀和舊幀。(具體例子見書)
SR協議是當接收方發現某幀出錯后，其后繼續送來的正確的幀雖然不能立即遞交給接收方的高層，但接收方可收下來，存放在一個緩沖區中，同時要求發送方重新傳送出錯的那一幀。一旦收到重新傳來的幀后，就可以原已存於緩沖區中的其余幀一並按正確的順序遞交高層。顯然，SR減少了浪費，但要求接收方有足夠大的緩沖區空間。
若采用n比特對幀編號，為了保證接收方向向前移動窗口后，新窗口序號與舊窗口序號沒有重疊部分，需要滿足條件：接受窗口+發送窗口<=2^n。假定仍然采用累計確認的方法，並且接受窗口顯然不應超過發送窗口，那么接受窗口尺寸不應超過序號范圍的一半<=2^(n-1)。
假設n取3,序號空間即0~7 （S:sender R:receiver）
1、S 發送了0,1,2,3,4,5,6 號幀
2、R 接受上述幀並且捎帶發送 ACK6,但是丟失了
3、S的0號幀首先超時，S 重發發送0號幀
4、R收到0號幀，但是因為之前它已經接受0~6,發送了ACK6，它會認為0號幀是一個新的幀，而在0號幀之前的一個7號幀丟失（注意這里是一個環的結構）。因為是選擇重傳協議，R會接受0號幀( the old)作為新幀(暫時放在緩存區)，並通知S重發7號幀。
5、S 發送7號幀
6、R接受了7和0號幀，並且發送ACK0
這就出現了問題
1、R接受錯誤的0號幀作為新的幀
2、S在發送完7號幀之后收到了ACK0，而不是ACK7，此時對於S而言，它的0號幀早已在ACK6中確認。
出現這個問題的主要原因是我們不能區別新舊幀，現在我們將序號空間一分為二，首先發送0~3，繼續上面的步驟。走到步驟4的時候R不會接受0作為新幀，因為R知道新的幀是4而不是0。這樣就避免了上面的問題。
先提個問題：回退N步協議中，如果接收方發送的ACK1丟失，ACK2到達發送方，這時還沒有超時發生，發送方是否因為收到了 ACK2 就不會重新發送 幀 1了？
我的答案是不會重發幀 1 。在累計確認中，即使ACK1丟失，但是在超時時間內接收到ACK2，那么發送方立即就知道1號幀已經被成功接收，只是對應的ACK1丟失而已，因此無需重傳幀1。
類似的這道題，發送發沒有收到幀1的確認，但是卻收到幀2、3的確認消息，說明此時還沒有超時，在這超時時間內是依然可以收到后序幀的確認，一個原因可能是接收方發送幀1的確認，但丟在路上，另一個原因是“累計確認”即捎帶確認，接受方根本沒有發送幀1的確認，而是通過2、3幀的確認告訴我們幀1已經接收成功。
所以，幀0、1、2、3均已正確接收到，需要重發的是4、5、6、7幀，答案選C。