轉載於：http://blog.csdn.net/honeybees/article/details/6755335
TCP報文段首部格式：
序號：本報文段所發送的數據的第一個字節的序號。
確認號ack：期待收到對方下一個報文段的第一個數據字節的序號
確認ACK：佔1位，僅當ACK=1時，確認號字段纔有效。ACK=0時，確認號無效
同步SYN：連接建立時用於同步序號。當SYN=1，ACK=0時表示：這是一個連接請求報文段。
若同意連接，則在響應報文段中使得SYN=1，ACK=1。因此，SYN=1表示這是一個連接請求，或連接接受報文。
終止FIN：用來釋放一個連接。FIN=1表示：此報文段的發送方的數據已經發送完畢，並要求釋放運輸連接
三次握手（三次聯絡）
CLOSED : 進程處於關閉狀態。
SYN-SENT : 客戶進程進入同步已發送狀態。
ESTAB-LISHEND : 進程已經入已建立連接狀態，之後可以傳送數據了。
LISTEN : 服務器進程處於收聽狀態。
SYN-RCVD : 服務器進程進入同步收到狀態。
----------------------------------------------------
需要三次握手（還要再發送一次確認）的原因：
爲了防止已失效的連接請求報文段突然又傳到了服務器B，導致服務器誤認爲客戶端想請求連接而發生連接的錯誤。
產生錯誤的場景：
在兩次握手的前提下，A發出連接請求，但因爲丟失了，故而不能收到B的確認。於是A重新發出請求，然後收到確認，建立連接，數據傳輸完畢後，釋放連接，A發了2個，一個丟掉，一個到達，沒有“已失效的報文段”。
但是，某種情況下，A發出的第一個連接請求在某個節點滯留了，延誤到達B。假設此時B已經釋放連接，那麼B在收到此實現的連接請求後，就誤認爲A又發出一次連接請求，在兩次握手的情況下（A發生請求，B接受請求並確認），B就認爲A又發出一次新連接請求。此時B就又給A發生一個確認，表示同意建立連接。因爲是兩次握手，A收到後，也不再次發出確認連接。此時B會等待A發送的數據，而A本來就沒有要求發送數據，肯定也無動於衷。此時B的資源就被浪費了。
爲什麼三次握手能夠處理這個錯誤場景？
採用三次握手的話，A收到B的確認後，由於A本來就不想發送數據，所以A就不發送確認，而B收不到確認，也就知道A並沒有要求建立連接。
四次握手（兩個二次握手）
----------------------------------------------------------------
ESTAB-LISHEND : 進程已經入已建立連接狀態，可以傳送數據。
FIN-WAIT1 : 客戶端進程進入終止等待1的狀態。
FIN-WAIT2 : 客戶端進程進入終止等待2的狀態。
TIME-WAIT: 客戶端進程進入時間等待（服務器的重傳）的狀態。
CLOSED : 進程處於關閉狀態。
CLOSED-WAIT: 服務器進程進入關閉等待狀態。
LAST-ACK: 服務器進行最後一次關閉確認。
注意兩個狀態：
<1> CLOSED-WAIT: 服務器進程進入關閉等待狀態。
服務器等待關閉狀態：服務器接收到客戶端關閉連接的請求，而自身還未想客戶端發送關閉連接請求的這段時間。
通常情況下，CLOSE_WAIT狀態的持續時間應該很短，但是如果服務器有很多數據需要傳輸或讀寫時，就不能關閉連接，此時就會出現連接長時間處於CLOSE_WAIT狀態的情況。
<2> TIME-WAIT: 客戶端進程進入時間等待（服務器的重傳）的狀態。
<客戶端完全關閉狀態>：客戶端收到服務器斷開連接的請求後，會向服務器確認收到分組，表示自己已經收到，你可以關閉連接了。但是該確認分組可能由於網絡問題收不到，而出現重傳的情況。所以客戶端必須要等待一會。此時客戶端等待完全關閉的時間就爲TIME-WAIT時期。
---------------------------------------------------------------
B收到連接釋放報文段後就立即發送確認，然後就進入close-wait狀態，此時TCP服務器進程就通知高層應用進程，因而從A到B的連接就釋放了。此時是“半關閉”狀態。即A不可以發送給B，但是B可以發送給A。
此時，若B沒有數據報要發送給A了，其應用進程就通知TCP釋放連接，然後發送給A連接釋放報文段，並等待確認。
A發送確認後，進入time-wait，注意，此時TCP連接還沒有釋放掉，然後經過時間等待計時器設置的2MSL後，A才進入到close狀態。
爲什麼要等待呢?
①、爲了保證A發送的最後一個ACK報文段能夠到達B。即最後這個確認報文段很有可能丟失，那麼B會超時重傳，然後A再一次確認，同時啓動2MSL計時器，如此下去。如果沒有等待時間，發送完確認報文段就立即釋放連接的話，B就無法重傳了（連接已被釋放，任何數據都不能出傳了），因而也就收不到確認，就無法按照步驟進入CLOSE狀態，即必須收到確認才能close。
②、防止“已失效的連接請求報文段”出現在連接中。經過2MSL，那些在這個連接持續的時間內，產生的所有報文段就可以都從網絡中消失。即在這個連接釋放的過程中會有一些無效的報文段滯留在樓閣結點，但是呢，經過2MSL這些無效報文段就肯定可以發送到目的地，不會滯留在網絡中。這樣的話，在下一個連接中就不會出現上一個連接遺留下來的請求報文段了。
可以看出：B結束TCP連接的時間比A早一點，因爲B收到確認就斷開連接了，而A還得等待2MSL.