轉自：https://blog.csdn.net/zDavid_2018/article/details/89357949
【三次握手】在TCP/IP協議中，TCP協議提供可靠通信服務，採用三次握手建立一個連接。
第一次握手：建立連接時，客戶端首先發送數據報，報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，表明傳送數據使得第一個數據字節的序號爲x。此時，客戶端進程進入了 SYN-SENT（同步已發送狀態）狀態。
第二次握手：服務器收到請求報文後，如果同意連接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲自己初始化一個序列號 seq=y，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。
第三次握手：客戶進程收到確認後，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，自己的序列號seq=x+1，此時，TCP連接建立，客戶端進入ESTABLISHED（已建立連接）狀態。
簡單來說
1. Client: SYN=1,seq=x
2.Server: ACK=1,SYN=1,ack=x+1,seq=y
3.Client: ACK=1,ack=y+1,seq=x+1
【四次揮手】
第一次揮手：客戶端發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
第二次揮手：服務器收到客戶端的釋放連接包，服務器發出確認，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP 服務器進程通知高層應用進程。從 客戶端 到 服務器 這個方向的連接就釋放了，TCP 連接處於半關閉狀態。服務器若發送數據，客戶端 仍要接收。
第三次揮手：客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最後的數據）。服務器 如果沒有數據要發送，其應用進程就通知tcp釋放連接。
服務器向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
第四次揮手：客戶端收到服務器的連接釋放報文後，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
簡單來說：
1.Client: FIN=1,seq=u
2.Server: ack=u+1,seq=v
3.Server: FIN=1,ack=u+1,seq=w
4.Client: ACK=1,ack=w+1,seq=u+1
1.三次握手中爲什麼TCP客戶端最後還要發送一次確認呢？
一句話，主要防止已經失效的連接請求報文突然又傳送到了服務器，從而產生錯誤。
如果使用的是兩次握手建立連接，假設有這樣一種場景，客戶端發送了第一個請求連接並且沒有丟失，只是因爲在網絡結點中滯留的時間太長了，由於TCP的客戶端遲遲沒有收到確認報文，以爲服務器沒有收到，此時重新向服務器發送這條報文，此後客戶端和服務器經過兩次握手完成連接，傳輸數據，然後關閉連接。此時此前滯留的那一次請求連接，網絡通暢了到達了服務器，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端和服務器再次建立連接，這將導致不必要的錯誤和資源的浪費。
如果採用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文並且回覆了確認報文，但是客戶端不會再次發出確認。由於服務器收不到確認，就知道客戶端並沒有請求連接。
（1） 浪費網絡資源；（2）引起安全問題。
目的：防止”已延遲TCP連接請求”發送給對方。
A發送了兩個連接請求報文,其中有一個有效.(暫且假設爲第二個) 2) 第一個TCP連接請求在網絡傳輸延遲時間長;
三次握手：A與B通信時，接收到延遲的第一個連接請求解決方法：序號不在接收窗口內，重複段丟棄！
三次握手是原子操作，A沒有發送應答給B，原子操作失敗， 連接無法建立。
2.四次揮手爲什麼客戶端最後還要等待2MSL（TIME_WAIT狀態）？
第一，爲了保證 客戶端發送的最後一個 ACK 報文段能夠到達服務器。
第二，防止 “已失效的連接請求報文段”出現在本連接中。客戶端在發送完最後一個 ACK 報文段後，再經過時間 2MSL，就可以使本連接持續的時間內所產生的所有報文段，都從網絡中消失。這樣就可以使下一個新的連接中不會出現這種舊的連接請求報文段。
3.如果已經建立了連接，但是客戶端突然出現故障了怎麼辦？
TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設置爲2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以後每隔75秒發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉連接。
4.爲什麼建立連接是三次握手，關閉連接確是四次揮手呢？
建立連接的時候， 服務器在LISTEN狀態下，收到建立連接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。
而關閉連接時，服務器收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，而自己也未必全部數據都發送給對方了，所以己方可以立即關閉，也可以發送一些數據給對方後，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送，從而導致多了一次。
傳輸層爲應用進程之間提供端到端的邏輯通信（但網絡層是爲主機之間提供邏輯通信）。