1. 程式人生 > >26-tcp可靠傳輸——停止等待協議

26-tcp可靠傳輸——停止等待協議

1. tcp可靠傳輸

  通過前面的學習可知,網路層傳輸資料時是盡最大努力傳輸到目的地,並不保障資料的可靠傳輸,對於網路擁塞,延遲,資料丟失等問題沒有采取有效的措施。因此我們需要一種資料可靠傳輸的通訊方式,即tcp來實現傳送端和接收端之間的可靠通訊。

  那麼為了後面學習tcp可靠傳輸,先從最簡單的可靠傳輸停止等待協議說起吧。

2. 停止等待協議

  什麼是停止等待協議?

  A和B雙方建立好tcp連線後就可以相互發送資料了,A為傳送方,B為接收方。因為這裡討論可靠傳輸原理,所以把傳輸的資料單元稱為分組。“停止等待”就是每傳送完一個分組就停止傳送,等待對方確認後再發送下一個分組。停止等待協議考慮了資料在網路中傳輸出現的幾種情況來提供有效措施保障資料的可靠傳輸,下面我們就一一來介紹這幾種情況。

  對於無差錯情況,不會出現重傳情況,那麼我們直接跳過,沒什麼好說的。

2.1 出現差錯或丟失的情況

這裡寫圖片描述
圖1-出現差錯或丟失

  當A在傳送M1分組的過程中丟失時,又或者B接收到M1分組檢測到差錯並丟棄了M1分組時(注意:這裡B不會發送M1確認分組,而是什麼也不做),可靠傳輸協議是這樣設計的:只要A沒有在規定時間內收到B的確認,就認為剛才傳送的分組丟失了,並對丟失的分組進行重傳,這種方式叫超時重傳。要實現超時重傳,就要每傳送完一個分組就設定一個超時計時器。如果在超時計時器到期之前收到了對方的確認,則撤銷該超時計時器。

這裡注意幾點:
  1. A傳送完一個分組後,必須暫時儲存已傳送的分組的副本(發生超時重傳時使用),當收到該分組的確認時就清除本地儲存的分組的副本。

  2. 分組和確認分組都必須進行編號,這樣才能明確哪一個已傳送的分組被確認,哪一個還沒被確認。

  3. 超時計時器設定的重傳時間比資料分組傳輸的平均往返時間更長一些,在設定重傳時間也是有要求的。因為重傳時間設定的過長會導致重傳花費的時間長,通訊效率慢,但是重傳時間設定的過短會導致出現不必要的重傳,浪費網路資源。

  比如B傳送的確認分組發生在網路中發生擁塞,傳輸的時間過長才到達A,但是A設定的重傳時間又很短,就會出現不必要的重傳。因此設定重傳時間是非常複雜的,因為分組在網路傳輸的過程中經過哪些網路,是否會出現網路擁塞或其他問題,都是不確定的。

2.2確認丟失的情況

這裡寫圖片描述
圖2-確認丟失

  當B收到A的M1分組後,B傳送的M1確認分組在網路中丟失了,且A在設定的超時重傳時間內又沒有收到B的M1確認分組,這時A無法知道是自己傳送的M1分組出錯丟失,還是B傳送的M1確認分組丟失了,那麼A會在超時計時器到期後重傳M1分組。

  如果B又收到了重傳的分組M1,這時B會丟棄重複的M1分組,並向A傳送M1確認分組(很明顯,因為A本來就沒有收到過確認啊)

2.3 確認遲到的情況

這裡寫圖片描述
圖3-確認遲到

  假設這麼一種情況:A在傳送M1分組後,B傳送的確認M1分組卻遲到了,但是A在超時計時器規定的時間內又沒有收到B的確認M1分組,那麼A將會重傳M1分組,根據前面所知的情況來看,B在收到重複的M1分組後會丟棄並重傳確認M1分組。那麼在A收到重傳的確認分組後,又收到了B遲到的確認M1分組,這是A會丟棄遲到的確認M1分組。

  像上面所說的可靠傳輸協議通常稱為自動重傳請求,也就是說,重傳時自動進行的,只要傳送方沒收到確認,就會重傳。如果A不斷重傳分組卻總是也收不到確認,這說明通訊線路太差,不能進行通訊。