TCP三向交握和四次揮手全過程及為什麼要三次握手解答

TCP三向交握和四次揮手的全過程

     TCP是主機對主機層的傳輸控制協定，提供可靠的連接配接服務，采用三次握手确認建立一個連接配接:

位碼即tcp标志位,有6種表示:

SYN(synchronous建立連接配接)

ACK(acknowledgement 表示響應、确認)

PSH(push表示有DATA資料傳輸)

FIN(finish關閉連接配接)

RST(reset表示連接配接重置)

URG(urgent緊急指針字段值有效)

三次握手：

第一次握手：用戶端發送syn包(syn=x)到伺服器，并進入SYN_SEND狀态，等待伺服器确認；

第二次握手：伺服器收到syn包，必須确認客戶的SYN（ack=x+1），同時自己也發送一個SYN包（syn=y），即SYN+ACK包，此時伺服器進入SYN_RECV狀态；

第三次握手：用戶端收到伺服器的SYN＋ACK包，向伺服器發送确認包ACK(ack=y+1)，此包發送完畢，用戶端和伺服器進入ESTABLISHED狀态，完成三次握手。

      握手過程中傳送的包裡不包含資料，三次握手完畢後，用戶端與伺服器才正式開始傳送資料。理想狀态下，TCP連接配接一旦建立，在通信雙方中的任何一方主動關閉連接配接之前，TCP 連接配接都将被一直保持下去。

      确認号：其數值等于發送方的發送序号+1(即接收方期望接收的下一個序列号)。

四次揮手：

與建立連接配接的“三次握手”類似，斷開一個TCP連接配接則需要“四次揮手”。

第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的資料傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發資料了(當然，在fin包之前發送出去的資料，如果沒有收到對應的ack确認封包，主動關閉方依然會重發這些資料)，但是，此時主動關閉方還可以接受資料。

第二次揮手：被動關閉方收到FIN包後，發送一個ACK給對方，确認序号為收到序号+1（與SYN相同，一個FIN占用一個序号）。

第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的資料傳送，也就是告訴主動關閉方，我的資料也發送完了，不會再給你發資料了。

第四次揮手：主動關閉方收到FIN後，發送一個ACK給被動關閉方，确認序号為收到序号+1，至此，完成四次揮手。

TCP的四次揮手過程（簡言之）：主動關閉方向被動關閉方發送不會再給你發資料了的資訊；被動關閉方對收到的主動關閉方的封包段進行确認；被動關閉方向主動關閉方發送我也不會再給你發資料了的資訊；主動關閉方再次對被動關閉方的确認進行确認。

 TCP三向交握和四次揮手的全過程如下圖：

TCP的三次握手過程？為什麼會采用三次握手，若采用二次握手可以嗎？

答：建立連接配接的過程是利用客戶伺服器模式，假設主機A為用戶端，主機B為伺服器端。

（1）TCP的三次握手過程：主機A向B發送連接配接請求；主機B對收到的主機A的封包段進行确認；主機A再次對主機B的确認進行确認。

（2）采用三次握手是為了防止失效的連接配接請求封包段突然又傳送到主機B，因而産生錯誤。失效的連接配接請求封包段是指：主機A發出的連接配接請求沒有收到主機B的确認，于是經過一段時間後，主機A又重新向主機B發送連接配接請求，且建立成功，順序完成資料傳輸。考慮這樣一種特殊情況，主機A第一次發送的連接配接請求并沒有丢失，而是因為網絡節點導緻延遲達到主機B，主機B以為是主機A又發起的新連接配接，于是主機B同意連接配接，并向主機A發回确認，但是此時主機A根本不會理會，主機B就一直在等待主機A發送資料，導緻主機B的資源浪費。

（3）采用兩次握手不行，原因就是上面說的失效的連接配接請求的特殊情況，是以采用三次握手剛剛好，兩次可能出現失效，四次甚至更多次則沒必要，反而複雜了。

本文轉自 Tenderrain 51CTO部落格，原文連結:http://blog.51cto.com/tenderrain/1980570