一說起TCP歉闰，很多人立馬就能想起三次握手和四次分手昙沦。
更有記憶力強者琢唾，能把整個狀態(tài)變遷圖記下來。
但是說起為什么要有這些機制盾饮，就不太好答上來采桃。
下面以一個例子分析三次握手和四次分手的過程懒熙。
打個比方，你和同事在早上相約中午去xx餐廳吃飯普办。
由于工作比較忙工扎，雙方有可能看不到對方發(fā)的消息。
所以你們約定：
- 在看到對方發(fā)的消息時衔蹲，就回復一條收到肢娘。
- 如果對方?jīng)]有回復收到，自己就重新發(fā)一次舆驶。
12：00橱健，你給同事發(fā)了一條消息：我準備去吃飯了
如果你的同事剛好活已經(jīng)干完，那么會回復：收到沙廉。我也準備去吃飯了拘荡。
然后你再回復一次：收到。
看起來就像是TCP的3次握手撬陵。
但是假如你的同事在收到你的第一條消息時珊皿，工作還差一點未完成。
那時他就只能回復：收到巨税。
而此時你看到回復之后亮隙，你只能確認對方確實收到了你的消息，而不能確認對方已經(jīng)準備好了和你一起吃飯垢夹。
假設過了10分鐘溢吻，你的同事把工作做完，給你發(fā)送了一條消息：我也準備去吃飯了
你回復：收到果元。
如此你和同事就達成了共同吃飯的協(xié)調工作促王，經(jīng)歷了4次消息傳遞。
所以反過來再回想一下TCP的建鏈過程而晒。
client: SYN
server: SYN+ACK
client: ACK
其實真正的過程是
client: SYN
server: ACK
server: SYN
client: ACK
只不過服務端在收到SYN時蝇狼，已經(jīng)確定自己也要向客戶端建鏈，而不是稍后再進行建鏈倡怎，所以服務端的SYN和ACK可以合并在一起發(fā)送迅耘，看起來就成了三次握手。
分析完建鏈過程之后监署，再看拆鏈過程颤专，就非常好理解。
為什么需要4次交互钠乏？
因為發(fā)起的一方栖秕，表達的是：我要停止數(shù)據(jù)發(fā)送了。
然后響應的一方晓避，往往還有數(shù)據(jù)要發(fā)（類比上面的工作差一點沒有完成的同事）簇捍，需要再把數(shù)據(jù)發(fā)完之后只壳，才能發(fā)出：我也要停止數(shù)據(jù)發(fā)送了。
就好比暑塑，你和同事去吃飯吼句，你吃完了，說一句：我吃完了事格。
如果同事這時也吃完了惕艳，就會說：收到，我也吃完了分蓖。
然后你回復：收到尔艇。
這樣就能一起回去了。
但是大概率你的同事不會和你同時吃完么鹤。
所以聽到你說吃完時终娃，他只會回復：收到。
等他吃完后蒸甜，他會說：我也吃完了棠耕，在你回復收到之后，整個同步才算完成柠新。
總結
所以我們可以得出窍荧，通過一個不可靠的信道傳輸數(shù)據(jù)來同步雙方，在不發(fā)生重試的情況下恨憎，最少需要3步蕊退，最多需要4步。
原因在于：
- 每次傳輸?shù)臄?shù)據(jù)都需要確認接收
- 另一方可能沒有準備好這次的同步動作憔恳。
如果是可靠信道瓤荔，只需要兩步就ok了。
