停止等待協議和滑動視窗協議的區別
停止等待協議是一種流量控制機制協議。在這個協議中,傳送方一次傳送一個幀,並等待接收方的確認。一旦確認,傳送方就會向接收方傳送另一個幀。
停止等待協議也是一種流量控制機制協議。在這個協議中,傳送方一次傳送多個幀,並重傳發現損壞或受損的幀。(這段描述與上一段矛盾,需要修改或刪除其中一段)
閱讀本文,瞭解更多關於這兩種協議的資訊以及它們之間的區別。
什麼是停止等待協議?
這是最基本的流量控制策略。傳送方將一次傳送一個幀給接收方。傳送方將停止並等待接收方的響應。傳送訊息和接收確認之間的時間間隔稱為傳送方的等待時間,在此期間傳送方處於空閒狀態。接收確認 (ACK) 後,傳送方將向接收方傳送下一個資料包,依此類推,直到傳送方沒有更多資料要傳送。
以下是使用停止等待協議的優點:
它很容易實現。
該技術的精確性是其主要優點。只有在第一個幀被確認後,才會傳送第二個幀。因此,沒有丟失任何幀的風險。
以下是停止等待協議的缺點:
在任何給定時間,只能傳送一個數據包。
如果傳送方和接收方之間的距離很遠,則傳播延遲將大於傳輸延遲。結果,效率會下降。
每次通訊後,傳送方必須等待確認,這會增加總傳輸時間。這會減慢傳輸過程。
什麼是滑動視窗協議?
在使用資料鏈路層(OSI 模型)或傳輸控制協議 (TCP) 時,滑動視窗會控制兩個網路計算機之間傳送的資料包,這些計算機需要可靠且按順序交付資料包。
在滑動視窗方法中,每個資料包(對於大多數資料連線層)和位元組(在 TCP 中)都包含一個唯一的順序序列號,接收計算機使用該序列號將資料按正確的順序排列。滑動視窗技術旨在透過使用序列號來消除重複資料並請求丟失的資料。
滑動視窗技術限制了在等待接收機的響應之前可以傳送的資料包數量。視窗大小就是資料包的數量。視窗大小受接收計算機處理資料包的速度及其記憶體緩衝區容量的限制。
停止等待協議和滑動視窗協議的區別
下表重點介紹了停止等待協議和滑動視窗協議的主要區別:
關鍵 | 停止等待協議 | 滑動視窗協議 |
---|---|---|
機制 | 在停止等待協議中,傳送方傳送單個幀並等待接收方的確認。 | 在滑動視窗協議中,傳送方一次傳送多個幀並重傳損壞的幀。 |
效率 | 停止等待協議效率較低。 | 滑動視窗協議比停止等待協議效率更高。 |
視窗大小 | 停止等待協議中傳送方的視窗大小為 1。 | 滑動視窗協議中傳送方的視窗大小從“1 到 n”不等。 |
排序 | 不需要對幀進行排序。 | 對幀進行排序有助於提高協議的效率。 |
效率 | 停止等待協議的效率計算公式為 1/(1+2a),其中“a”是傳播延遲與傳輸延遲的比率。 | 滑動視窗協議的效率計算公式為 N/(1+2a),其中 N 是視窗幀數,a 是傳播延遲與傳輸延遲的比率。 |
雙工 | 停止等待協議是半雙工的。 | 滑動視窗協議是全雙工的。 |
結論
這兩種協議都提供了一種流量控制機制,但是滑動視窗協議比停止等待協議效率更高。滑動視窗的傳播延遲更小,因為傳送方可以自發地傳輸多個幀,而停止等待協議中,傳送方一次只能傳輸一個幀,然後等待確認後再傳輸第二個幀。