TCP的揮手協議和握手協議
三次握手協議:三次握手協議的主要過程是交互彼此之間的初始序列號,如果沒有確認的ACK幀可以麽?肯定是可以的
client A -------> server B
client A 發送了自己的初始序列號;然後B看見了之後B發送了一個初始序列號,這樣兩次“握手”都可以啊。但是兩次握手的問題是:此時A開始發送信息,B肯定是收到了A的序列號了;B告訴A說我的序列號;二次握手基於的假設是:我發送結束後默認你已經知道了我的初始序列號是多少,但是現在的問題是B肯定是知道A的序列號了,所以B可以很自如地向A發送數據包,但是如果A一直沒有發送數據包,那麽是因為B的sync序列號的包沒有達到,A不知道B的初始序列號所以沒發呢?還是說A就是沒有發送數據包,還是說A的數據包丟失了呢?B端充滿了疑惑。好像是可以工作的,B端此時會超時重傳,不斷地去發送SYNC包告訴A說自己的初始序列號;那麽這裏就是整個問題的核心了:此時我如果A就是沒有數據要發呢
那四次揮手又是解決啥問題呢?
A調用close是為了說啥呢?是說我這裏不在對你B發送數據,還是告訴B我不再接受數據呢?是前者,告訴B我不再向你發送數據了(但是我這邊仍然有段時間會接受到你的數據)或者說是申請關閉鏈接,你看著辦吧。
ACK報文在TCP協議中超級重要,它可以很大程度防止丟包引起的重傳。握手階段的ACK上面已經分析過了;在真正的數據傳輸階段呢,當A發送了1,2,3,4,5包,然後又發送了6,我怎麽確定包是否是收到了呢?要不然我一個勁兒地發也沒用呀,ACK幀的主要作用就是讓A和B的信息透明。
ACK在整個TCP協議中的作用是信息透明,防止重傳;
在結束的時候也是這樣,如果A發送了FIN,如果好久沒有相應,那麽A怎麽知道到底是因為數據包在A->B的路上丟了,還是B已經收到了,所以必須要讓A心知肚明,此時B先發送一個ACK幀過來,通知A:我B收到了你的斷開請求。【還是沒有找到問題的根源。三次握手的第三個ACK包是為了降低B的疑惑,即當A遲遲沒有發數據,不是因為A沒有收到B的序列號,而是Abenlai
TCP的揮手協議和握手協議