自己 -s style 分析 建立 丟失 size lai 透明

三次握手協議：三次握手協議的主要過程是交互彼此之間的初始序列號，如果沒有確認的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發送了ＦＩＮ，如果好久沒有相應，那麽Ａ怎麽知道到底是因為數據包在Ａ－>B的路上丟了，還是Ｂ已經收到了，所以必須要讓Ａ心知肚明，此時Ｂ先發送一個ＡＣＫ幀過來，通知Ａ：我Ｂ收到了你的斷開請求。【還是沒有找到問題的根源。三次握手的第三個ACK包是為了降低B的疑惑，即當A遲遲沒有發數據，不是因為A沒有收到B的序列號，而是Abenlai

】

TCP的揮手協議和握手協議