TCP協議總結--停止等待協議,連續ARQ協議,滑動窗口協議


前言:在學習tcp三次握手的過程之中,由於一直無法解釋tcpdump命令抓的包中seq和ack的含義,就將tcp協議往深入的了解了一下,了解到了幾個協議,做一個小結.

先來看看我的問題:
這是用tcpdump命令抓的三次握手的包,可以看到seq和ack都比較大,我自己也無法解釋原因.
這里寫圖片描述
這里寫圖片描述
第二張是在同一過程中用Wireshark抓的包,其中seq和ack還比較正常,難道原因就是我不懂tcpdump命令中的數據?我的解釋是Wireshark和tcpdump中抓的包,數據的顯示方式可能不同,最后學長說可以用 -S 將tcp的序列號以絕對值形式輸出,而不是相對值。轉化了一下,第三次的ack就正常了.主要還是得知道seq和ack一樣,都是字節序列號,一共4個字節,范圍都是從[0,2^32 - 1].

$ tcpdump -S port 80

這里寫圖片描述

一:停止等待協議
停止等待協議是tcp保證傳輸可靠的重要途徑,”停止等待”就是指發送完一個分組就停止發送,等待對方的確認,只有對方確認過,才發送下一個分組.

1:無差錯情況:發送方發送分組,接收方在規定時間內收到,並且回復確認.發送方再次發送……
這里寫圖片描述
2:超時重傳有以下三種情況:
(1)分組丟失:發送方發送分組,接收方沒有收到分組,那么接收方不會發出確認,只要發送方過一段時間沒有收到確認,就認為剛才的分組丟了,那么發送方就會再次發送.
(2):確認丟失:發送方發送成功,接收方接收成功,確認分組也被發送,但是分組丟失,那么到了等待時間,發送方沒有收到確認,又會發送分組過去,此時接收方前面已經收到了分組,那么此時接收方要做的事就是:丟棄分組,重新發送確認.
(3):傳送延遲:發送方發送成功,接收方接收成功,確認分組也被發送,沒有丟失,但是由於傳輸太慢,等到了發送方設置的時間,發送方又會重新發送分組,此時接收方要做的事情:丟棄分組,重新發送確認. 發送方如果收到兩個或者多個確認,就停止發送,丟棄其他確認.
這里寫圖片描述

停止等待協議的優點是簡單,但是缺點是信道的利用率太低,一次發送一條消息,使得信道的大部分時間內都是空閑的,為了提高效率,我們采用流水線傳輸,這就與下面兩個協議有關系了.

二:連續ARQ協議和滑動窗口協議
這兩個協議主要解決的問題信道效率低和增大了吞吐量,以及控制流量的作用.

  • 連續ARQ協議:它是指發送方維護着一個窗口,這個窗口中不止一個分組,有好幾個分組,窗口的大小是由接收方返回的win值決定的,所以窗口的大小是動態變化的,只要在窗口中的分組都可以被發送,這就使得TCP一次不是只發送一個分組了,從而大大提高了信道的利用率.並且它采用累積確認的方式,對於按序到達的最后一個分組發送確認.
  • 滑動窗口協議:之所以叫滑動窗口協議,是因為窗口是不斷向前走的,該協議允許發送方在停止並等待確認前發送多個數據分組。由於發送方不必每發一個分組就停下來等待確認,因此該協議可以加速數據的傳輸,還可以控制流量的問題.
  • 累積確認:如果發送方發送了5個分組,接收方只收到了1,2,4,5,沒有收到3分組,那么我的確認信息只會說我期望下一個收到的分組是第三個,此時發送方會將3,4,5,全部重發一次,當通信質量不是很好的時候,連續ARQ還是會帶來負面影響.

版權聲明:本文為博主原創文章,未經博主允許不得轉載。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM