停止-等待協議

停止-等待協議
從名稱上可以看出，停止-等待協議是基於停止-等待流量控制技術的。從滑動窗口的角度來看就是其發送窗口大小等於 1，接收窗口大小也是 1.
基本思想：發送方傳輸一個幀之后，必須等待對方的確認才能發送下一幀。如果在規定的實踐之內沒有收到確認，則發送方超時，並重傳原始幀。
有人會問，停止-等待流量控從v行程序制技術（這里是停止-等待流量控制技術而不是停止-等待協議）為什么要一直在等待？為什么不設置一個規定時間？我們來看協議的指定。首先協議需要建立在一定的技術（停止-等待流量控制技術）之上，然后在此技術上需要考慮一切可能突發的不利狀況（可以理解：協議 = 技術 + 考慮不利因素，即 停止-等待協議 = 停止-等待流量控制技術 + 不利因素），設定規定時重傳就是為了解決這些不利因素。如果不設定時間就會造成死鎖，這樣就無法推進，在這里可以聯想操作系統的死鎖，如果沒有外力參與打破死鎖，就會一直等待下去，而這個外力就是重傳計時器。
停止-等待協議會出現的差錯主要有以下兩大類：
幀一般被分為數據幀和確認幀。
第一類錯誤就是數據幀被損壞或者丟失，那么接收方在進行差錯校驗時，會被檢測出來。處理數據幀被損壞的情況時，使用計時器可以解決。這樣發送方再發送一個幀之后，如果數據能夠被正確的接收到，那么就接收方就發送一個確認幀，沒有問題；如果接收方接收到的是一個被損壞的數據幀，則直接丟棄，此時發送方處於等待狀態，直到計時器超市，發送方就會重新發送這個數據幀，如此重復，直到這一個數據幀無錯誤地到達接收方為止。
第二類錯誤就是確認幀被破壞或者丟失。一旦確認幀被破壞或者丟失，造成的后果就是發送方會不斷地重新發送該幀，從而導致接收方不斷地重復接受該幀。如何解決？顯然，對於接收方而言，需要有能力區分某一幀是新幀還是重復幀。解決方法很簡單，讓發送方再每一個待發地幀地頭部加一個編號，而接收方對每一個到達的幀地編號進行識別，判斷是新幀還是需要拋棄的重復幀。