TCP連接三次握手四次揮手
TCP報文：
幾個字段：
（1）序號：Seq序號，佔32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。
（2）確認序號：Ack序號，佔32位，只有ACK標誌位爲1時，確認序號字段纔有效，Ack=Seq+1。
（3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義如下：
ACK：確認序號有效。 SYN：發起一個新連接。 FIN：釋放一個連接。
TCP三次握手
建立一個TCP連接時，需要客戶端和服務端總共發送3個包以確認連接的建立。整個流程如下圖所示：
-
客戶端發起建立鏈接請求，發送一個TCP報文，隨機生成一個seq，SYN置1
-
服務器應答，將確認序號ACK設置爲客戶的seq加1以對客戶的SYN報文段進行確認，同時，隨機生成一個seq號，SYN、ACK置1
-
客戶端發送第三個包，ACK爲服務端的seq加1，seq爲步驟1中seq加1，ACK置1
爲什麼是3次，而不是兩次？
考慮計算機S和C之間的通信，假定C給S發送一個連接請求分組，S收到了這個分組，併發送了確認應答分組。按照兩次握手的協定，S認爲連接已經成功地建立了，可以開始發送數據分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已準備好，不知道S建立什麼樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認爲連接還未建立成功，將忽略S發來的任何數據分 組，只等待連接確認應答分組。而S在發出的分組超時後，重複發送同樣的分組。這樣就形成了死鎖。
SYN攻擊
在三次握手過程中，服務器發送SYN-ACK之後，收到客戶端的ACK之前的TCP連接稱爲半連接(half-open connect).此時服務器處於SYN_RECV狀態.當收到ACK後，服務器轉入ESTABLISHED狀態. Syn攻擊就是 攻擊客戶端 在短時間內僞造大量不存在的IP地址，向服務器不斷地發送syn包，服務器回覆確認包，並等待客戶的確認，由於源地址是不存在的，服務器需要不斷的重發直 至超時，這些僞造的SYN包將長時間佔用未連接隊列，正常的SYN請求被丟棄，目標系統運行緩慢，嚴重者引起網絡堵塞甚至系統癱瘓。 Syn攻擊是一個典型的DDOS攻擊。檢測SYN攻擊非常的方便，當你在服務器上看到大量的半連接狀態時，特別是源IP地址是隨機的，基本上可以斷定這是一次SYN攻擊.在Linux下可以如下命令檢測是否被Syn攻擊 netstat -n -p TCP | grep SYN_RECV 一般較新的TCP/IP協議棧都對這一過程進行修正來防範Syn攻擊，修改tcp協議實現。主要方法有SynAttackProtect保護機制、SYN cookies技術、增加最大半連接和縮短超時時間等. 但是不能完全防範syn攻擊。
TCP四次揮手
TCP的連接的拆除需要發送四個包，因此稱爲四次揮手(four-way handshake)。客戶端或服務器均可主動發起揮手動作
-
Client （可以使客戶端，也可以是服務器端），設置Seq和Ack，向 Server發送一個FIN報文段；此時，Client 進入FIN_WAIT_1狀態；這表示 Client 沒有數據要發送給 Server了；
-
Server 收到了 Client 發送的FIN報文段，向 Client 回一個ACK報文段，Ack爲步驟1中 Seq加 1；Client 進入 FIN_WAIT_2 狀態；Server 告訴 Client ，我“同意”你的關閉請求；
-
Server 向 Client 發送 FIN 報文段，Ack爲步驟1中 Seq加 1，請求關閉連接，同時 Server 進入 CLOSE_WAIT 狀態；
-
Client 收到 Server 發送的 FIN 報文段，向 Server 發送 ACK 報文，ACK爲步驟3中Seq加1，然後 Client 進入 TIME_WAIT 狀態；Server 收到 Client 的 ACK 報文段以後，就關閉連接；此時，Client等待2MSL後依然沒有收到回覆，則證明 Server 端已正常關閉，那好，Client 也可以關閉連接了。
爲什麼是4次？
因爲client請求關閉時，server可能還有數據沒有發送，因此2，3步分開進行，等server數據發送完成，才進行第3步。否則，2，3步合起來，就和3次握手一樣了。
爲什麼TIME_WAIT狀態需要經過2MSL？
因爲有可以第四步中報文丟失，如果直接關閉，那麼server端可能沒收到報文，那麼server端會重新發送FIN（第三步），所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。
所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網絡中最大的存活時間，2MSL就是一個發送和一個回覆所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP連接。
TIME_WAIT狀態所帶來的影響
當某個連接的一端處於TIME_WAIT狀態時，該連接將不能再被使用。事實上，對於我們比較有現實意義的是，這個端口將不能再被使用。某個端口處於TIME_WAIT狀態(其實應該是這個連接)時，這意味着這個TCP連接並沒有斷開(完全斷開)，那麼，如果你bind這個端口，就會失敗。對於服務器而言，如果服務器突然crash掉了，那麼它將無法再2MSL內重新啓動，因爲bind會失敗。因此，一般是客戶端發起關閉鏈接請求。
TCP狀態變遷圖
參考：