TCP協議非常重要，這裏把它的連接和釋放整理一下。
首先是三次握手：
1、 客戶端發起，像服務器發送的報文SYN=1，ACK=0，然後選擇了一個初始序號：seq=x。
SYN是幹什麼用的？
在鏈接的時候創建一個同步序號，當SYN=1同時ACK=0的時候，表明這是一個連接請求的報文段。如果對方有意鏈接，返回的報文裏面SYN=1，ACK=1,。從這個意義上來說，SYN=1的時候，就表明這是一個‘請求’或者‘接受請求’的報文。
SYN=1的報文段不能攜帶數據。但是要消耗掉一個序號，
ACK是幹什麼用的？
僅當ACK=1的時候，確認字號（期望收到對方下一個報文段的第一個數據字節的編號）纔有效。因此，TCP規定，當鏈接建立之後，所有往來的報文裏面的ACK都應該是1（事實上，也只有客戶端發起的鏈接請求報文的ACK沒有置1）。
現在的狀態：客戶端進入SYN-SEND狀態；
2、 服務器接收到了SYN=1，ACK=0的請求報文之後，返回一個SYN=1，ACK=1的確認報文。
同時，確認號ack=x+1，同時也爲自己選擇一個初始序號seq=y
現在的狀態：服務器進入SYN-REVD狀態；
3、 客戶端接收到了服務器的返回信息之後，還要給服務器返回最後一條確認，ACK=1，確認號ack=y+1；
現在的狀態：客戶端進入ESTABLISHED狀態。
下面說一下爲什麼兩次握手不行，非得三次：
首先說明一種正常的情況，就是客戶端發送了一條請求鏈接的報文，但是由於網絡原因丟失了，所以，不可能接收到服務器端的確認。這個時候，客戶端就就只有再一次發送原來的請求報文，這次服務器收到之後返回確認，客戶端再確認一次，鏈接確立。
然後考慮一種不正常的情況，客戶端發了兩次請求鏈接的報文，第二條被服務器捕捉到，返回數據，完成了兩次握手。數據傳送完成之後，鏈接關閉。但是這時候，第一條擁塞的請求報文現在到達了服務器端，服務器還以爲客戶端要又一次建立連接，於是發送確認，然後把自己敞開，等着客戶端發送過來數據。於是，很多的網絡資源就是這樣浪費掉了。
要是實行三次握手，服務器收到了一條過期的請求報文，返回確認信息，客戶端接收到了服務器的信息之後感到莫名其妙，心想：我他媽又沒要鏈接，你返回這個是不是瘋了。於是不置一詞。服務器過一段時間還沒有收到第三次握手的數據，知道客戶端並沒有要求建立鏈接的請求，含淚離開。
然後是四次分手：
現在雙方的狀態都是ESTABLISHED狀態。
1、 客戶端發起請求，請求斷開鏈接。FIN=1，seq=u。u是之前傳送過來的最後一個字節的序號+1。
FIN：用來釋放一個鏈接，當FIN=1的時候，表明此報文的發送方已經完成了數據的發送，沒有新的數據要傳送，並要求釋放鏈接。
客戶端進入FIN-WAIT-1狀態，等着服務器返回確認；
2、 服務器收到客戶端的請求斷開鏈接的報文之後，返回確認信息。ACK=1，seq=v，ack=u+1。
服務器進入CLOSE-WAIT狀態。
這個時候，客戶端不能給服務器發送信息報文，只能接收。但是服務器要是還有信息要傳給服務器，仍然能傳送。
3、 當服務器也沒有了可以傳的信息之後，給客戶端發送請求結束的報文。FIN=1，ACK=1，
ack=u+1，seq=w。
這個時候的狀態：服務器進入LAST-ACK狀態。
4、 客戶端接收到FIN=1的報文之後，返回確認報文，ACK=1，seq=u+1，ack=w+1。
發送完畢之後，客戶端進入等待狀態，等待兩個時間週期。關閉。
爲什麼最後還要等待兩個時間週期呢？
1、 客戶端的最後一個ACK報文在傳輸的時候丟失，服務器並沒有接收到這個報文。這個候。
服務器就會超時重傳這個FIN消息，然後客戶端就會重新返回最後一個ACK報文，等待兩個時間週期，完成關閉。如果不等待這兩個時間週期，服務器重傳的那條消息就不會收到。服務器就因爲接收不到客戶端的信息而無法正常關閉。
2、 預防上一次在三次握手中提到的失效的報文干擾。兩個時間週期過去之後，所有的報文都會在網絡中消失，保證下一次重新連接的時候有亂七八糟的報文影響。