1、三次握手

（1）三次握手的詳述

首先Client端發送連接請求報文，Server段接受連接后回復ACK報文，并為這次連接分配資源。Client端接收到ACK報文后也向Server段發生ACK報文，并分配資源，這樣TCP連接就建立了。

最初兩端的TCP進程都處于CLOSED關閉狀態，A主動打開連接，而B被動打開連接。（A、B關閉狀態CLOSED——B收聽狀態LISTEN——A同步已發送狀態SYN-SENT——B同步收到狀態SYN-RCVD——A、B連接已建立狀態ESTABLISHED）

B的TCP服務器進程先創建傳輸控制塊TCB，準備接受客戶進程的連接請求。然后服務器進程就處于LISTEN（收聽）狀態，等待客戶的連接請求。若有，則作出響應。

1）第一次握手：A的TCP客戶進程也是首先創建傳輸控制塊TCB，然后向B發出連接請求報文段，（首部的同步位SYN=1，初始序號seq=x），（SYN=1的報文段不能攜帶數據）但要消耗掉一個序號，此時TCP客戶進程進入SYN-SENT（同步已發送）狀態。

2）第二次握手：B收到連接請求報文段后，如同意建立連接，則向A發送確認，在確認報文段中（SYN=1，ACK=1，確認號ack=x+1，初始序號seq=y），測試TCP服務器進程進入SYN-RCVD（同步收到）狀態；

3）第三次握手：TCP客戶進程收到B的確認后，要向B給出確認報文段（ACK=1，確認號ack=y+1，序號seq=x+1）（初始為seq=x，第二個報文段所以要+1），ACK報文段可以攜帶數據，不攜帶數據則不消耗序號。TCP連接已經建立，A進入ESTABLISHED（已建立連接）。

當B收到A的確認后，也進入ESTABLISHED狀態。

（2）總結三次握手過程：

第一次握手：起初兩端都處于CLOSED關閉狀態，Client將標志位SYN置為1，隨機產生一個值seq=x，并將該數據包發送給Server，Client進入SYN-SENT狀態，等待Server確認；

第二次握手：Server收到數據包后由標志位SYN=1得知Client請求建立連接，Server將標志位SYN和ACK都置為1，ack=x+1，隨機產生一個值seq=y，并將該數據包發送給Client以確認連接請求，Server進入SYN-RCVD狀態，此時操作系統為該TCP連接分配TCP緩存和變量；

第三次握手：Client收到確認后，檢查ack是否為x+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=y+1，并且此時操作系統為該TCP連接分配TCP緩存和變量，并將該數據包發送給Server，Server檢查ack是否為y+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨后Client和Server就可以開始傳輸數據。

起初A和B都處于CLOSED狀態——B創建TCB，處于LISTEN狀態，等待A請求——A創建TCB，發送連接請求（SYN=1，seq=x），進入SYN-SENT狀態——B收到連接請求，向A發送確認（SYN=ACK=1，確認號ack=x+1，初始序號seq=y），進入SYN-RCVD狀態——A收到B的確認后，給B發出確認（ACK=1，ack=y+1，seq=x+1），A進入ESTABLISHED狀態——B收到A的確認后，進入ESTABLISHED狀態。

TCB傳輸控制塊Transmission Control Block，存儲每一個連接中的重要信息，如TCP連接表，到發送和接收緩存的指針，到重傳隊列的指針，當前的發送和接收序號。

（3）為什么A還要發送一次確認呢？可以二次握手嗎？

答：主要為了防止已失效的連接請求報文段突然又傳送到了B，因而產生錯誤。如A發出連接請求，但因連接請求報文丟失而未收到確認，于是A再重傳一次連接請求。后來收到了確認，建立了連接。數據傳輸完畢后，就釋放了連接，A工發出了兩個連接請求報文段，其中第一個丟失，第二個到達了B，但是第一個丟失的報文段只是在某些網絡結點長時間滯留了，延誤到連接釋放以后的某個時間才到達B，此時B誤認為A又發出一次新的連接請求，于是就向A發出確認報文段，同意建立連接，不采用三次握手，只要B發出確認，就建立新的連接了，此時A不理睬B的確認且不發送數據，則B一致等待A發送數據，浪費資源。

（4）Server端易受到SYN攻擊？

服務器端的資源分配是在二次握手時分配的，而客戶端的資源是在完成三次握手時分配的，所以服務器容易受到SYN洪泛攻擊，SYN攻擊就是Client在短時間內偽造大量不存在的IP地址，并向Server不斷地發送SYN包，Server則回復確認包，并等待Client確認，由于源地址不存在，因此Server需要不斷重發直至超時，這些偽造的SYN包將長時間占用未連接隊列，導致正常的SYN請求因為隊列滿而被丟棄，從而引起網絡擁塞甚至系統癱瘓。

防范SYN攻擊措施：降低主機的等待時間使主機盡快的釋放半連接的占用，短時間受到某IP的重復SYN則丟棄后續請求。

2、四次揮手

（1）四次揮手的詳述

　　假設Client端發起中斷連接請求，也就是發送FIN報文。Server端接到FIN報文后，意思是說"我Client端沒有數據要發給你了"，但是如果你還有數據沒有發送完成，則不必急著關閉Socket，可以繼續發送數據。所以你先發送ACK，"告訴Client端，你的請求我收到了，但是我還沒準備好，請繼續你等我的消息"。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端確定數據已發送完成，則向Client端發送FIN報文，"告訴Client端，好了，我這邊數據發完了，準備好關閉連接了"。Client端收到FIN報文后，"就知道可以關閉連接了，但是他還是不相信網絡，怕Server端不知道要關閉，所以發送ACK后進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳?！埃琒erver端收到ACK后，"就知道可以斷開連接了"。Client端等待了2MSL后依然沒有收到回復，則證明Server端已正常關閉，那好，我Client端也可以關閉連接了。Ok，TCP連接就這樣關閉了！

數據傳輸結束后，通信的雙方都可釋放連接，A和B都處于ESTABLISHED狀態。（A、B連接建立狀態ESTABLISHED——A終止等待1狀態FIN-WAIT-1——B關閉等待狀態CLOSE-WAIT——A終止等待2狀態FIN-WAIT-2——B最后確認狀態LAST-ACK——A時間等待狀態TIME-WAIT——B、A關閉狀態CLOSED）

1）A的應用進程先向其TCP發出連接釋放報文段（FIN=1，序號seq=u），并停止再發送數據，主動關閉TCP連接，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。

2）B收到連接釋放報文段后即發出確認報文段，（ACK=1，確認號ack=u+1，序號seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處于半關閉狀態，A到B的連接釋放。

3）A收到B的確認后，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連接釋放報文段。

4）B沒有要向A發出的數據，B發出連接釋放報文段（FIN=1，ACK=1，序號seq=w，確認號ack=u+1），B進入LAST-ACK（最后確認）狀態，等待A的確認。

5）A收到B的連接釋放報文段后，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態。此時TCP未釋放掉，需要經過時間等待計時器設置的時間2MSL后，A才進入CLOSED狀態。

（2）總結四次揮手過程：

起初A和B處于ESTABLISHED狀態——A發出連接釋放報文段并處于FIN-WAIT-1狀態——B發出確認報文段且進入CLOSE-WAIT狀態——A收到確認后，進入FIN-WAIT-2狀態，等待B的連接釋放報文段——B沒有要向A發出的數據，B發出連接釋放報文段且進入LAST-ACK狀態——A發出確認報文段且進入TIME-WAIT狀態——B收到確認報文段后進入CLOSED狀態——A經過等待計時器時間2MSL后，進入CLOSED狀態。

（3）為什么A在TIME-WAIT狀態必須等待2MSL的時間？

MSL最長報文段壽命Maximum Segment Lifetime，MSL=2

答：　　兩個理由：1）保證A發送的最后一個ACK報文段能夠到達B。2）防止“已失效的連接請求報文段”出現在本連接中。

1）這個ACK報文段有可能丟失，使得處于LAST-ACK狀態的B收不到對已發送的FIN+ACK報文段的確認，B超時重傳FIN+ACK報文段，而A能在2MSL時間內收到這個重傳的FIN+ACK報文段，接著A重傳一次確認，重新啟動2MSL計時器，最后A和B都進入到CLOSED狀態，若A在TIME-WAIT狀態不等待一段時間，而是發送完ACK報文段后立即釋放連接，則無法收到B重傳的FIN+ACK報文段，所以不會再發送一次確認報文段，則B無法正常進入到CLOSED狀態。

2）A在發送完最后一個ACK報文段后，再經過2MSL，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失，使下一個新的連接中不會出現這種舊的連接請求報文段。

（4）為什么連接的時候是三次握手，關閉的時候卻是四次握手？

答：因為當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能并不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。

（5）為什么TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

原文：https://blog.csdn.net/qzcsu/article/details/72861891

https://www.cnblogs.com/Andya/p/7272462.html