TCP鏈接的4次握手講解

　　眾所周知TCP連接需要3次握手，斷開需要4次握手。一直不是很清楚怎麼回事，最近有仔細的研究了一番，下面把我的理解和網上大蝦們的博文總結如下：

　　直奔主題，3次握手確認建立連接

　　第一次握手：主機A發送位碼為syn＝1,隨機產生seq number=1234567的數據包到服務器，主機B由SYN=1知道，A要求建立聯機；

　　第二次握手：主機B收到請求後要確認聯機信息，向A發送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包

　　第三次握手：主機A收到後檢查ack number是否正確，即第一次發送的seq number+1,以及位碼ack是否為1，若正確，主機A會再發送ack number=(主機B的seq+1),ack=1，主機B收到後確認seq值與ack=1則連接建立成功。

　　4次握手斷開連接

　　第一次： 客戶端A發送一個FIN，用來告訴服務器B，客戶A關閉數據傳送。

　　第二次： 服務端B收到這個FIN後，回發一個ACK，序號為收到的序號加1。和SYN一樣，一個FIN將占用一個序號。

　　第三次： 服務器B發送一個FIN給客戶端A。表示服務器B關閉與客戶端A的數據傳送。

　　第四次： 客戶端A發回ACK報文確認，並將確認序號設置為收到序號加1。

　　由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的連 接。收到一個 FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

　　為什麼建立連接協議是三次握手，而關閉連接卻是四次握手呢？

　　這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它可以把ACK和SYN（ACK起應答作用，而SYN起同步 作用）放在一個報文裡來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了， 所以你未必會馬上會關閉SOCKET,你可能還需要發送一些數據給對方之後再關閉，所以發送ACK報文給對方來表示你已經知道對方現在關閉連接了，然後發 送FIN告訴對方服務端也要關閉連接了，它這裡的ACK報文和FIN報文多數情況下都是分開發送的。

　　下面集中連接狀態的解釋會更好的幫助你理解這幾次握手

　　LISTEN： 這個也是非常容易理解的一個狀態，表示服務器端的某個SOCKET處於監聽狀態，可以接受連接了。

　　SYN_RCVD： 這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態，很短暫，基本 上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程序，故意將三次TCP握手過程中最後一個ACK報文不予發送。因此這種狀態 時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。

　　SYN_SENT： 這個狀態與SYN_RCVD遙想呼應，當客戶端SOCKET執行CONNECT連接時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀 態，並等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。

　　ESTABLISHED：這個容易理解了，表示連接已經建立了。

　　FIN_WAIT_1： 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別 是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連接，向對方發送了FIN報文，此時該SOCKET即 進入到FIN_WAIT_1狀態。而當對方回應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬 上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到，以為對方不一定立 馬給你發送FIN報文。