背景

和女朋友異地戀一年多，為了保持感情我提議每天晚上影片聊天一次。

從好上開始，到現在，一年多也算堅持下來了。

問題

有時候聊天的過程中，我的網路或者她的網路可能會不好，影片就會卡住，聽不到對方的聲音，過一會兒之後才會恢復。

中間雙方可能就要不斷的確認網路是否恢復，但是有時候會：

她：“你可以聽到了嗎？”

我：“可以了，你呢？”、

她：“喂喂，你可以聽到了嗎？”

我：“可以了，我可以聽到了，你呢？”

她：“你可以聽到了嗎？”

…..

這種情況很蛋疼，那麼怎樣才能找一個簡單的辦法，讓兩個人都確認自己可以聽到對方的聲音，對方也可以聽到自己的聲音呢？

註：以下情節純屬虛構

方案

TCP建立連線為什麼是三次握手，而不是兩次或四次？

TCP，名為傳輸控制協議，是一種可靠的傳輸層協議，IP協議號為6。

順便說一句，原則上任何資料傳輸都無法確保絕對可靠，三次握手只是確保可靠的基本需要。

舉個日常例子，打電話時我們對話如下：

對應為客戶端與伺服器之間的通訊：

於是有瞭如下對話：

我：1+1等於幾？

她：2,2+2等於幾？

我：4

首先兩個人約定協議

1.感覺網路情況不對的時候，任何一方都可以發起詢問

2.任何情況下，若發起詢問後5秒還沒收到回覆，則認為網路不通

3.網路不通的情況下等1min路由器之後再發起詢問

對於我而言，發起 “1+1等於幾”的詢問後

1. 若5s內沒有收到回覆，則認為網路不通

2. 若收到回覆，則我確認①我能聽到她的訊息 ②她能聽到我的訊息，然後回覆她的問題的答案

對於她而言，當感覺網路情況不對的時候

1. 若沒有收到我的詢問，則她發起詢問

2. 若收到“1+1等於幾”，則她確認 ①她可以聽到我的訊息，然後回覆我的問題的答案和她的問題“2，2+2等於幾”

3. 若5s內沒有收到我的回覆“4”，則她確認 ②我聽不見她的訊息

4. 若5s內收到了我的回覆“4”，則她確認 ②我可以聽見她的訊息

這樣，如果上面的對話得以完成，就證明雙方都可以確認自己可以聽到對方的聲音，對方也可以聽到自己的聲音！

這個故事可以解釋TCP為什麼要三次握手嗎 … 囧

關於四次揮手

先由客戶端向伺服器端傳送一個FIN，請求關閉資料傳輸。

當伺服器接收到客戶端的FIN時，向客戶端傳送一個ACK，其中ack的值等於FIN+SEQ

然後伺服器向客戶端傳送一個FIN，告訴客戶端應用程式關閉。

當客戶端收到伺服器端的FIN是，回覆一個ACK給伺服器端。其中ack的值等於FIN+SEQ

為什麼要4次揮手？

確保資料能夠完整傳輸。

當被動方收到主動方的FIN報文通知時，它僅僅表示主動方沒有資料再傳送給被動方了。

但未必被動方所有的資料都完整的傳送給了主動方，所以被動方不會馬上關閉SOCKET,它可能還需要傳送一些資料給主動方後，

再傳送FIN報文給主動方，告訴主動方同意關閉連線，所以這裡的ACK報文和FIN報文多數情況下都是分開傳送的。

一、TCP報文格式

  TCP報文格式圖：

上圖中有幾個欄位需要重點介紹下：

（1）序號：Seq序號，佔32位，用來標識從TCP源端向目的端傳送的位元組流，發起方傳送資料時對此進行標記。

（2）確認序號：Ack序號，佔32位，只有ACK標誌位為1時，確認序號欄位才有效，Ack=Seq+1。

（3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義如下：

（A）URG：緊急指標（urgent pointer）有效。

（B）ACK：確認序號有效。

（C）PSH：接收方應該儘快將這個報文交給應用層。

（D）RST：重置連線。

（E）SYN：發起一個新連線。

（F）FIN：釋放一個連線。

需要註意的是：

（A）不要將確認序號Ack與標誌位中的ACK搞混了。

（B）確認方Ack=發起方Req+1，兩端配對。 

二、三次握手

TCP(Transmission Control Protocol)　傳輸控制協議

TCP是主機對主機層的傳輸控制協議，提供可靠的連線服務，採用三次握手確認建立一個連線

位碼即tcp標誌位,有6種標示:

• SYN(synchronous建立聯機)

• ACK(acknowledgement 確認)

• PSH(push傳送)

• FIN(finish結束)

• RST(reset重置)

• URG(urgent緊急)

• Sequence number(順序號碼)

• Acknowledge number(確認號碼) 

• establish  建立，建立

所謂三次握手（Three-Way Handshake）即建立TCP連線，是指建立一個TCP連線時，需要客戶端和服務端總共傳送3個包以確認連線的建立。在socket程式設計中，這一過程由客戶端執行connect來觸發，整個流程如下圖所示：

（1）第一次握手：Client將標誌位SYN置為1，隨機產生一個值seq=J，並將該資料包傳送給Server，Client進入SYN_SENT狀態，等待Server確認。

（2）第二次握手：Server收到資料包後由標誌位SYN=1知道Client請求建立連線，Server將標誌位SYN和ACK都置為1，ack (number )=J+1，隨機產生一個值seq=K，並將該資料包傳送給Client以確認連線請求，Server進入SYN_RCVD狀態。

（3）第三次握手：Client收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該資料包傳送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連線建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸資料了。

SYN攻擊：

在三次握手過程中，Server傳送SYN-ACK之後，收到Client的ACK之前的TCP連線稱為半連線（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址，並向Server不斷地傳送SYN包，Server回覆確認包，並等待Client的確認，由於源地址是不存在的，因此，Server需要不斷重發直至超時，這些偽造的SYN包將長時間佔用未連線佇列，導致正常的SYN請求因為佇列滿而被丟棄，從而引起網路堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連線狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：

#netstat -nap | grep SYN_RECV

三、四次揮手

三次握手耳熟能詳，四次揮手估計就..所謂四次揮手（Four-Way Wavehand）即終止TCP連線，就是指斷開一個TCP連線時，需要客戶端和服務端總共傳送4個包以確認連線的斷開。在socket程式設計中，這一過程由客戶端或服務端任一方執行close來觸發，整個流程如下圖所示：

由於TCP連線時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成資料傳送任務後，傳送一個FIN來終止這一方向的連線，收到一個FIN只是意味著這一方向上沒有資料流動了，即不會再收到資料了，但是在這個TCP連線上仍然能夠傳送資料，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉，上圖描述的即是如此。

（1）第一次揮手：Client傳送一個FIN，用來關閉Client到Server的資料傳送，Client進入FIN_WAIT_1狀態。

（2）第二次揮手：Server收到FIN後，傳送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。

（3）第三次揮手：Server傳送一個FIN，用來關閉Server到Client的資料傳送，Server進入LAST_ACK狀態。

（4）第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接著傳送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。

上面是一方主動關閉，另一方被動關閉的情況，實際中還會出現同時發起主動關閉的情況，具體流程如下圖：

流程和狀態在上圖中已經很明瞭了，在此不再贅述，可以參考前面的四次揮手解析步驟。

四、附註

關於三次握手與四次揮手通常都會有典型的面試題，在此提出供有需求的同學們參考：

（1）三次握手是什麼或者流程？四次握手呢？答案前面分析就是。

（2）為什麼建立連線是三次握手，而關閉連線卻是四次揮手呢？

這是因為服務端在LISTEN狀態下，收到建立連線請求的SYN報文後，把ACK和SYN放在一個報文裡傳送給客戶端。而關閉連線時，當收到對方的FIN報文時，僅僅表示對方不再傳送資料了但是還能接收資料，己方也未必全部資料都傳送給對方了，所以己方可以立即close，也可以傳送一些資料給對方後，再傳送FIN報文給對方來表示同意現在關閉連線，因此，己方ACK和FIN一般都會分開傳送。

作者：Champin

來源：https://my.oschina.net/u/3708120/blog/1581023

《Linux雲端計算及運維架構師高薪實戰班》2018年05月14日即將開課中，120天衝擊Linux運維年薪30萬，改變速約~~~~

*宣告：推送內容及圖片來源於網路，部分內容會有所改動，版權歸原作者所有，如來源資訊有誤或侵犯權益，請聯絡我們刪除或授權事宜。

– END –

更多Linux好文請點選【閱讀原文】哦

↓↓↓