TCP的三次握手。
第一次握手：建立連接時，客戶端 發送 syn 包（syn=j）到 服務器，並進入 SYN_SENT 狀態，等待服務器確認；
syn：同步序列號（Synchronize Sequence Numbers）
第二次握手：服務器 收到 客戶端 發送的 syn 包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（seq=k），即 SYN+ACK包，此時服務器進入 SYN_RECV 狀態；
seq: (sequence)
ack: 確認
先說下爲什麼加1？
假設 a 郵了一個快遞給 b，快遞員是 c。
a 想知道 b 是否可以接收快遞，然後 b 就把快遞又郵回去了。
但是 b 沒有做標記的話，a 無法知道 b 是否收到了包裹。
所以 b 加了一個1，表示自己簽收到了。
然後爲什麼又發了一個序列號？(seq)
因爲 b 也需要知道 a 是否可以接收包裹。
第三次握手：客戶端 收到 服務器 的 SYN+ACK 包，向 服務器 發送確認包 ACK(ack=k+1），此包發送完畢，客戶端和服務器進入 ESTABLISHED（TCP連接成功）狀態，完成三次握手。
established: 建立成功了
*******************************************************************************************************************************
ok, 接下來說爲啥需要三次，而不是兩次！
那麼我們必須明白一個事情，握手是爲了解決什麼問題？
握手要解決的問題其實是：希望服務器端只開一個連接給客戶端使用。兩次握手不是一定不成功
假設 a 要把自己的孩子送到 b 家裏待幾天。
a 要通過給 b 送快遞的方式來確定 b 在不在家，c 是快遞員。
a 的快遞送給 b 的時候，c 把包送到了 b ，b 成功簽收，併發包告訴 a 我在家！
假設 b 的快遞送給 a 的時候，c 把包丟了。
那麼問題就在這裏，假設只有兩次握手
a 的快遞送給 b, b 收到後，要傳給 a。
但是，b 的快遞給 a 的時候呢， 快遞員 c 把包弄丟了。
此時，a 沒有收到包的情況下，會以爲包沒有發給 b。(因爲是兩次握手，此時的 b 只是假設了 a 收到了包)
但是 b 呢？ b 已經準備好 a 送孩子過來，就會打開一個門等 a 發送孩子過來。
此時的 a 會以爲 b 沒在家，重新發一個包查看 b 是否現在在家。（a如果收到包，那麼兩次握手也可以成功建立連接）
那麼 b 收到之後是不是又會開一個門？是否就造成了這種資源浪費！！！
如果這次 a 還是沒收到呢？ b 就會一直開很多門！
握手 3 次 就是爲了解決以上問題的。
OK， 那麼接下來說3次握手之後會有其他問題嗎？
如果握手成功，接下來把孩子送過去就Ok了。
是不是有人還想問 孩子送到半路出了問題怎麼辦！
假設孩子半路又被 快遞員 弄丟了..
那麼，又有什麼問題呢？a 知道 b 在家, 就算是失敗了，a 至少不用發快遞問 b 在不在家了。<== 握手主要是解決這個問題
所以它只需要再發一個孩子過去，直到孩子發過去爲止。
總結：3次握手是爲了減少因網絡或其他原因造成不必要的資源浪費（a沒有收到b的包的情況下）
好，還有一個問題， 大家問我 一次 握手不就不會有問題嗎？
我擦， b 不存在呢？ 你一直髮孩子，客戶端是不是就資源浪費了？
自己捋一捋吧！