TCP三向交握、四次揮手，tcp三向交握揮手

TCP三向交握、四次揮手，tcp三向交握揮手

一、三向交握

       TCP是連線導向的，無論哪一方向另一方發送資料之前，都必須先在雙方之間建立可靠串連，串連是通過三向交握進行初始化的。三向交握的目的是同步串連雙方的序號和確認號並交換TCP視窗大

小資訊。

                                 

       第一次握手：建立串連。用戶端發送串連請求報文段，將SYN設定為1，Seq設定為x，然後，用戶端進入SYN_SEND狀態，等待伺服器的確認。

　　第二次握手：伺服器收到SYN報文段。伺服器收到用戶端的SYN報文段，需要對這個報文段進行確認，設定ACK為x+1（Seq+1），同時，伺服器自身還要發送SYN請求資訊，將SYN設定為1，Seq設定為y。伺服器將上述SYN、ACK、Seq放置在一個報文段中，一起發送給用戶端，伺服器端進入SYN_RECV狀態。

　　第三向交握：用戶端收到伺服器端的報文段（SYN、ACK、Seq）。用戶端收到伺服器端的報文段後向將ACK設定為y+1，向伺服器端發送ACK報文段，這個報文段發送完畢後，用戶端和伺服器端都進入ESTABLISHED狀態，三向交握完成。

 

二、四次揮手

　　當用戶端與伺服器在通過三向交握建立TCP串連，傳輸完資料之後，將會斷開TCP串連。斷開TCP串連的過程就是四次揮手。

                                                           

　　第一次揮手：主機1（主動斷開方）主動中斷連線（可以是用戶端，也可以是伺服器端），設定Seq為u，ACK為Z,發送給主機2被動斷開方一個FIN報文段，然後主機1進入FIN_WAIT_1狀態，這表示主機1已經沒有資料要發送給主機2了。

　　第二次分手：主機2收到主機1發送的FIN報文段，將Seq設定為z，ACK為x+1（Seq+1），向主機2回應一個ACK報文段，主機2由CLOSED_WAIT變為CLOSED_OK,主機1收到回應報文後由FIN_WAIT_1變為FIN_WAIT_2；

　　第三次分手：主機2向主機1發送FIN報文段，請求關閉串連，同時主機2由CLOSED_OK進入LAST_ACK狀態。

　　第四次分手：主機1收到主機2的FIN報文段後，向主機2發送ACK報文段，然後主機1由FIN_WAIT_2進入TIME_WAIT狀態。主機2收到主機1的ACK報文段以後，關閉串連，此時主機1等待2MSL後如果還沒有收到回複，那麼就證明伺服器端已經正常關閉，主機1也就可以關閉串連了，用戶端和伺服器端都進入CLOSED狀態。

三、相關問題

　　1、為什麼建立串連要三向交握？

　　防止已經失效的串連請求報文段突然又傳送到了伺服器端。例如：Client發送的第一個串連請求報文段並沒有丟失，但是由於某些原因沒有及時到達Server，以致延誤到Client串連釋放以後的某個時間才到達Server。這個報文段在Client端早已經失效，但是Server端並沒有，於是Server將會向Client端發送出確認報文段，同意建立串連。假設沒有三向交握，那麼只要Server發出確認，新的串連就會建立。但是現在Client並沒有發出建立串連的請求，也就不會搭理Server的確認，更不會像Server發送ACk報文。而Server卻認為串連已經建立，就會一直等待Client發來資料，這樣Server的資源就會白白的浪費。現在我們採用了三向交握，那麼在同樣的情況下，Client不會向Server的確認發出確認，Server由於沒有收到Client的確認，就知道Client沒有請求建立串連。

　　2、為什麼關閉串連要四次揮手？

　　TCP串連是連線導向的、可靠的、基於位元組流的傳輸層協議，TCP是全雙工系統模式。這就意味著當主機1發出FIN報文段時，只是表明主機1已經沒有資料要發送了，但是主機1可以接收來自主機2的資料，但主機2返回ACK報文段時，表明主機2已經知道主機1沒有資料發送了，但是主機2還是可以發送資料到主機1，當主機2也發送FIN報文段時，表明主機2也沒有資料要發送了，串連雙方就中斷本次TCP串連。

　　3、問什麼主動斷開方還要等待2MSL？

　　MSL：報文段最長存留時間，它是任何報文段被丟棄前在網路內的最長時間。

　　①保證TCP協議的全雙工系統串連能夠可靠關閉。如果主機1直接CLOSED，那麼由於IP協議的不可靠性或者其他的網路原因，導致主機2沒有收到主機1最後的ACK確認，那麼主機2就會在逾時後重新發送FIN，但是主機1已經CLOSED，就找不到與重發FIN對應的串連。故主機1不會立刻CLOSED，而保持TIME_WAIT，如此如果再次收到FIN報文段時，能夠保證對方收到ACK，最後確認關閉串連.

　　②保證這次串連的重複資料區段從網路中消失。如果主機1直接CLOSED，然後又向主機2發起一個新的串連，我們無法保證這個新的串連與剛關閉的串連連接埠號碼是不同的，即新舊兩個串連的連接埠號碼可能使相同的。那麼如果上一次串連的某些資料還在網路上，這些延遲資料在新串連建立後才到達主機2，由於新舊串連的連接埠號碼相同，TCP協議就會認為那個資料時新串連的，這樣兩次串連的資料包就混在一起了。所以在等待2MSL後，即使真有資料滯留，也將會在2MSL內全部消失。

　　4、什麼是synflood攻擊？

　　　　synflood發生在建立串連的三向交握過程中。正如問題1中所說，雖然在Client沒有向Server的確認發出確認，但是Server的串連並不是立馬取消，這就是產生synflood攻擊的原因。假設一個Client向Server發送了SYN報文後突然死機或者掉線，那麼Server在發出SYN+ACK應答報文後是無法收到Client的ACK報文的。這種情況下Server一般會重試（再次發送SYN+ACK）並等待一段時間後丟棄這個未完成的串連，這段時間通常稱為SYN Timeout，一般來說這個事件時分鐘層級的（大約30s-2min）。一個Client出現異常導致Server一個線程等待1分鐘並沒有什麼，但是如果惡意攻擊大規模地類比這種情況，Server將會為了維護一個非常大的半串連而消耗非常多的資源，即使簡單的儲存並遍曆也會消耗非常多的CPU時間和記憶體，糟糕的是還需要對這個列表中的IP進行SYN+ACK的重試。最後，如果Server的TCP/IP棧不夠大，往往使堆疊溢位崩潰，即使Server系統足夠強大，也將忙於處理攻擊者偽造的TCP請求而無暇處理正常的請求（佔比小）。此時，從正常Client的角度看，將會認為伺服器失去響應，這種情況即被稱為synflood攻擊（syn洪水攻擊）。