TCP 建連三次握手
首先解釋一下每個步驟的作用：
1、a 時刻，A 準備就緒，發送 SYN 包給 B，嘗試建立連接
2、b 時刻，B 收到 A 發來的 SYN 包，知道 A 要請求建連，回 SYN ACK 包，告訴 A 自己收到了建連請求，可以建連了
3、c 時刻，A 收到了 B 的回覆，知道 B 準備好了，鏈路通暢，可以發送數據了。回 ACK 告知 B 收到了 B 的回覆，下面要開始發送該數據了
4、d 時刻，B 收到了 A 的回覆，知道 A 接下來要發數據了。至此，AB 雙方都確認整個鏈路已經可靠了，接下來可以發送數據了。
爲什麼要多次確認呢？爲什麼不可以 A 上來就直接發送數據給 B 呢？
這裏首先要明確一點，TCP 是傳輸層的協議，是建立在物理層、數據鏈路層、網絡層之上的協議，而底層的網絡是不可靠的，可能路由出問題，可能網關出問題，可能網線出問題，A 沒法保證自己發出來的消息 B 一定能收到，所以一定要反饋機制，即 ACK，這樣才能在不可靠的網絡層智商構建可靠的傳輸層。
那爲什麼一定是三次呢，爲什麼不是兩次或者四次呢？
先來說一下爲什麼不能少。
一次可以嗎？不可以。設想一下，A 對 B 說：我要給你發數據。然後不等 B 的回覆，接下來就開始發數據了。這時候根本不能保證 B 已經準備好了，那 A 發出來的數據就沒法保證 B 一定能收到。聯想生活中的場景，你隔着很遠的距離向對方喊話：我要把蘋果扔給你。然後不關心對方有沒有聽到，就直接扔了，那最終的結果通常就是對方接不到蘋果，因爲對方可能根本沒有收到消息。
兩次可以嗎？不可以。設想一下，A 對 B 說：我要給你發數據，然後 B 收到消息後給 A 回覆：收到，A 在收到 B 的回覆後開始發送數據。這時候 A 端是可以準備就緒的，但是 B 端不知道 A 端當前的狀態。因爲 B 在收到 A 的消息的時候，可能已經過去了很長時間，B 在回消息的時候，A 可能已經不在線了，此時 B 是不能直接發數據的。如果 A 再給 B 回一個 ACK，B 就可以確認當前鏈路狀態了，這就變成了三次握手。
接下來說一下爲什麼不是四次。既然三次已經可以保證建立可靠通信，就不需要額外的一次交互了。
TCP 斷鏈四次揮手
1、a 時刻，A 向 B 發出 FIN 包，表示自己沒有數據要發送了
2、b 時刻，B 收到 FIN 包，回覆 ACK，表示收到了 A 的 FIN 包，不會再接收 A 的數據了
3、B 在發完 FIN ACK 後，可能還有數據要發給 A，這個數據是不能停止發送的，有數據還是需要繼續發送
4、d 時刻，B 發完了數據，也發出 FIN ACK包，告訴 A 自己的數據發完了，不再發送數據了
5、e 時刻，A 收到了 B 的 FIN 包，知道 B 也沒有數據要發送了，回覆 ACK。此時，連接可以斷開了
建連只需要交互三次，斷連卻需要四次，這是爲什麼呢？其實斷開連接和建立連接還是不一樣的。建連的時候，只要雙方都告知對方自己準備好了就可以，但是斷連的時候，一方提出要斷開連接，不再發數據，另一方不能立即斷開，因爲這一方可能還有數據要發送，直到數據全部發送完成後才能確認斷開。