TCP(Transmission Control Protocol)協(xié)議是一種面向連接的、相對可靠的傳輸控制協(xié)議（雖說是面向連接，其實也就是通信雙方保持一個‘連接’狀態(tài)）

三次握手和四次揮手是TCP協(xié)議中比較重要的部分，它們都是為數(shù)據(jù)傳輸而服務(wù)的，一個是在數(shù)據(jù)傳輸開始之前建立連接，一個是在數(shù)據(jù)傳輸結(jié)束之后關(guān)閉連接，接下來就簡單說一下這個過程：

TCP傳輸

關(guān)于各種狀態(tài)以及發(fā)送的報文信息，上圖已經(jīng)表現(xiàn)的很清楚，就不詳述了

三次握手

必須是client先發(fā)起請求

1. Client向Server發(fā)起建立請求信息，“我想給你發(fā)數(shù)據(jù)，可以嗎？”
   （此步是為了讓Server端知道Client能夠發(fā)送數(shù)據(jù)）
2. Server端確認Client發(fā)來的請求信息，同時向Client返回確認信息，“可以，你什么時候發(fā)？”
   （此步是為了讓Client知道Server既能接收到數(shù)據(jù)也能發(fā)送數(shù)據(jù)）
3. Client收到Server的確認信息，并向Server發(fā)送確認信息，“我現(xiàn)在就發(fā)，你接著吧！”
   （此步是為了讓Server知道Client能夠接收數(shù)據(jù)）

經(jīng)過上面的三次握手，會讓Client和Server確認彼此雙方既能接收數(shù)據(jù)又能發(fā)送數(shù)據(jù)，然后便可以進入數(shù)據(jù)傳輸進程了，一般來說，握手次數(shù)達到3就可以保證通信信息被正確傳達。

網(wǎng)上發(fā)現(xiàn)一個形象化的圖例

四次揮手

誰先發(fā)起請求都可以

因為Client和Server都能發(fā)起請求，所以我們此處用A和B替代通訊雙方

1. A發(fā)起請求結(jié)束信號（A表示自己不會再傳輸數(shù)據(jù)了，請求斷開）
2. B向A發(fā)送確認收到A發(fā)起的結(jié)束請求的確認信號（B知道了A的請求，但是還有數(shù)據(jù)要處理，暫時還不能斷開）
3. B向A發(fā)送請求結(jié)束信號（數(shù)據(jù)發(fā)送完成，B同意斷開）
4. A向B發(fā)送確認結(jié)束信號（A同意斷開，很愉快的中斷這次TCP連接）

由于TCP是全雙工的協(xié)議，也就是說兩端可以同時進行數(shù)據(jù)傳輸，所以，TCP連接的關(guān)閉在兩端都關(guān)閉之后才正式關(guān)閉。

網(wǎng)上發(fā)現(xiàn)一個形象化的圖例

相關(guān)疑問點：

• 建立連接的第二次握手為什么要傳回SYN？
  接收端傳回發(fā)送端所發(fā)送的SYN是為了告訴發(fā)送端，我接收到的信息確實就是你所發(fā)送的信號了。
• 傳了SYN，為啥還要傳ACK？
  雙方通信無誤必須是兩者互相發(fā)送信息都無誤。傳了SYN，證明發(fā)送方到接收方的通道沒有問題，但是接收方到發(fā)送方的通道還需要ACK信號來進行驗證。
• 為什么要三次握手？
  為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端，導(dǎo)致服務(wù)器端的一直等待而浪費資源。
  引用書中一個例子：

“已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求。于是就向client發(fā)出確認報文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認，也不會向server發(fā)送數(shù)據(jù)。但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會向server的確認發(fā)出確認。server由于收不到確認，就知道client并沒有要求建立連接?！?/p>