TCP三次握手和四次揮手

TCP三次握手的過程圖

這是TCP三次握手的過程圖，我們首先來說下SYN,ACK,seq,ack分別代表什麼含義:
(1)確認ACK:僅當ACK=1時確認號字段纔有效。當ACK=0時，確認號無效。
   TCP規定:當連接建立後所有傳送的報文段必須把ACK置1。


(2)同步SYN:在連接建立時用來同步信號。
   SYN置爲1表示這是一個連接請求或連接接受的報文。
   SYN=1,ACK=0          連接請求報文段
   SYN=1,ACK=1          連接接受報文段

(3)初始序號:seq

(4)確認號:ack

TCP三次握手的過程

(1)客戶端向B發送連接請求報文段，此時首部的同步位SYN=1，同時選擇一個初始序號seq=x。TCP客戶端進程進入SYN_SENT狀態。

(2)B收到連接請求報文段後，如果同意建立連接，則向A發送確認。確認報文段中置SYN=1,ACK=1，確認號ack=x+1,同時自己選擇一個初始序號:
seq=y,此時TCP服務器進程進入SYN_RCVD(同步收到)狀態。

(3)TCP客戶端在收到B的確認後，還要向B給出確認。確認報文段置ACK=1,確認號ack=y+1,而自己的序號:seq=x+1。此時TCP連接已建立。
A進入ESTABLISHED(已建立連接)狀態。
當B收到A的確認後，也進入ESTABLISHED狀態。

兩次連接可不可以?

考慮這樣一種情況:
    A發送連接請求，但由於網絡原因，造成長時間滯留。於是A重傳了一次連接請求，建立連接，數據傳輸完成後，連接斷開。
    這個時候，滯留的連接請求到達B，這本來是一個失效的報文段，但是如果採取兩次連接的話，在B向A發出確認之後，新的連接就建立了。
    由於現在A沒有發連接請求，因此不會理睬B的確認，也不會向A發送數據。而B卻以爲連接已建立，並一直等待A發送數據，造成了B的
    資源的浪費。
    而採用三次握手的話，A不會向B的確認發送確認，B收不到確認，就知道A並沒有要求建立連接。

TCP四次揮手的過程圖

TCP四次揮手的過程

(1)A的應用進程先向其TCP發送連接釋放報文段，並停止再發送數據，主動關閉TCP連接。A將連接釋放報文段首部的FIN置1，其序號seq=u,
它等於前面已傳送過的數據的最後一個字節的序號加1。這時候A進入FIN-WAIT-1(終止等待1)狀態，等待B的確認。
(2)B收到連接釋放報文段後即發出確認，確認號是ack=u+1,而這個報文段自己的序號是v,等於B前面已傳送過的數據的最後一個字節的序號加1。
然後B進入CLOSE-WAIT(關閉等待)狀態。
此時TCP服務器的進程應通知高層應用進程，因爲A到B這個方向的連接已經釋放了，這時TCP處於半關閉狀態。從B到A這個方向的連接
並沒有關閉，所以B若發送數據，A仍要接收。

A收到B的確認後，就進入FIN-WAIT-2(終止等待2)狀態，等待B發出連接釋放報文段。
(3)若B已經沒有要向A發送的數據，其應用程序就通知TCP釋放連接。這時候B發出的連接釋放的報文段必須使FIN=1,
假定B的序號爲w,B還需要重複確認上次發送的確認號ack=u+1。這時候B就進入LAST-ACK(最後確認)狀態，等待A的確認。
(4)A在收到B的連接釋放報文段後，必須對此發送確認。在確認報文段把ACK置1,確認號ack=w+1,而自己的序號是seq=u+1,然後
進入TIME-WAIT(時間等待)狀態。這時候TCP連接還沒有釋放掉，必須經過時間等待計時器設置的時間後，A才進入到CLOSED狀態。