滑動視窗機制

視窗機制

分析：①初始態，傳送方沒有幀發出，傳送視窗前後沿相重合。接收方0號視窗打開，等待接收0號幀；②傳送方打開0號視窗，表示已發出0幀但尚確認返回信息。此時接收視窗狀態不變；③傳送方打開0、1號視窗，表示0、1號幀均在等待確認之列。至此，傳送方打開的視窗數已達規定限度，在未收到新的確認返回幀之前，傳送方將暫停傳送新的數據幀。接收視窗此時狀態仍未變；④接收方已收到0號幀，0號視窗關閉，1號視窗打開，表示準備接收1號幀。此時傳送視窗狀態不變；⑤傳送方收到接收方發來的0號幀確認返回信息，關閉0號視窗，表示從重發表中刪除0號幀。此時接收視窗狀態仍不變；⑥傳送方繼續傳送2號幀，2號視窗打開，表示2號幀也納入待確認之列。至此，傳送方打開的視窗又已達規定限度，在未收到新的確認返回幀之前，傳送方將暫停傳送新的數據幀，此時接收視窗狀態仍不變；⑦接收方已收到1號幀，1號視窗關閉，2號視窗打開，表示準備接收2號幀。此時傳送視窗狀態不變；⑧傳送方收到接收方發來的1號幀收畢的確認信息，關閉1號視窗，表示從重發表中刪除1號幀。此時接收視窗狀態仍不變。

若從滑動視窗的觀點來統一看待1比特滑動視窗、後退n及選擇重傳三種協定，它們的差別僅在於各自視窗尺寸的大小不同而已。1比特滑動視窗協定：傳送視窗= 1，接收視窗=1；後退n協定：發視窗>1，接收視窗=1；選擇重傳協定：傳送視窗>1,接收視窗>1。

比特滑動視窗協定

當傳送視窗和接收視窗的大小固定為1時，滑動視窗協定退化為停等協定（stop－and－wait）。該協定規定傳送方每傳送一幀後就要停下來，等待接收方已正確接收的確認（acknowledgement）返回後才能繼續傳送下一幀。由於接收方需要判斷接收到的幀是新發的幀還是重新傳送的幀，因此傳送方要為每一個幀加一個序號。由於停等協定規定只有一幀完全傳送成功後才能傳送新的幀，因而只用一比特來編號就夠了。其傳送方和接收方運行的流程圖如圖所示。

後退協定

由於停等協定要為每一個幀進行確認後才繼續傳送下一幀，大大降低了信道利用率，因此又提出了後退n協定。後退n協定中，傳送方在發完一個數據幀後，不停下來等待應答幀，而是連續傳送若干個數據幀，即使在連續傳送過程中收到了接收方發來的應答幀，也可以繼續傳送。且傳送方在每傳送完一個數據幀時都要設定逾時定時器。只要在所設定的逾時時間內仍沒有收到確認幀，就要重發相應的數據幀。如：當傳送方傳送了N個幀後，若發現該N幀的前一個幀在計時器逾時後仍未返回其確認信息，則該幀被判為出錯或丟失，此時傳送方就不得不重新傳送出錯幀及其後的N幀。

從這裡不難看出，後退n協定一方面因連續傳送數據幀而提高了效率，但另一方面，在重傳時又必須把原來已正確傳送過的數據幀進行重傳（僅因這些數據幀之前有一個數據幀出了錯），這種做法又使傳送效率降低。由此可見，若傳輸信道的傳輸質量很差因而誤碼率較大時，連續測協定不一定優於停止等待協定。此協定中的傳送視窗的大小為k，接收視窗仍是1。

選擇重傳協定

在後退n協定中，接收方若發現錯誤幀就不再接收後續的幀，即使是正確到達的幀，這顯然是一種浪費。另一種效率更高的策略是當接收方發現某幀出錯後，其後繼續送來的正確的幀雖然不能立即遞交給接收方的高層，但接收方仍可收下來，存放在一個緩衝區中，同時要求傳送方重新傳送出錯的那一幀。一旦收到重新傳來的幀後，就可以原已存於緩衝區中的其餘幀一併按正確的順序遞交高層。這種方法稱為選擇重發(SELECTICE REPEAT)，顯然，選擇重發減少了浪費，但要求接收方有足夠大的緩衝區空間。