TCP三次握手四次揮手

TCP的三次握手

TCP三次握手過程

假設有一個發送方計算機和一個接收方計算機，縱向爲時間軸

第一次握手

假設首先是發送方主動和接收方創建鏈接，因此，發送方會第一次發送一個報文（此時SYN=1，表示這是一個鏈接請求的報文，seq=x是同步發送方本身的序列號）

第二次握手

接收方在接收到鏈接請求後，也就打開TCP鏈接，同時它也會發送一個報文，這個報文是第二次握手。報文信息中有：

• SYN=1：表示是一個鏈接請求
• ACK=1：表示對序列號的確認
• ack=x+1：小寫的ack表示的是確認號。這裏的ack=x+1，表示接受方指望收到的是x+1這個序列號的值
• seq=y：同時接收方發送的報文中也會攜帶本身的序列號，也就是seq=y

第三次握手

發送方接收到報文以後，會進行迴應，迴應中的報文內容：

• ACK=1：表示這個報文的確認號是有效的
• seq=x+1：發送方所攜帶的序列號，表示的是，當前發送方發送的數據序列號是x+1
• ack=y+1：確認號是y+1，表示發送方指望接收到接收方的序列號是y+1的數據

經過這三次的握手，TCP的鏈接就創建起來了

三次握手中關鍵的信息

• 第一次和第二次握手都有SYN標記，表示這是一個鏈接的請求
• 第二次和第三次握手都有ack標記，對於ack這個標記，它實際上是先對鏈接雙方的序列號進行同步。好比說，經過兩次的ack同步，發送方已經知道了接收方的ack是什麼了，同時，接收方也知道了發送方的ack是什麼了，經過三次握手，它們不只僅將鏈接創建起來，而且也同步了各自的序號

在三次握手的時間軸中，不一樣的時間，接收方和發送方有不一樣的狀態

• 在接收方沒有接收到數據以前，它一直處於監聽狀態（Listen）
• 發送方在第一個報文發送出去，到接收到第一個報文的響應之間，屬於同步已發送狀態（SYNC-SENT），表示已經將SYN發送出去了，而且等待對方的SYN信息
• 從接收方發送第一個報文，到接收到第二個報文之間，屬於同步已接收狀態（SYNC-RCVD），表示發送方發送給個人SYN信息，我已經收到了
• 而後發送方就進入創建鏈接（ESTABLISHED）的狀態了
• 對發送方來講，只要第二次握手成功以後，發送方就創建起鏈接了。可是對接收方來講，只有接收到發送方的第三次握手以後，纔是創建鏈接的狀態（ESTABLISHED）

雙方對於創建鏈接狀態的時間是不同的，發送方只要在第二次握手成功以後，就變成了創建鏈接的狀態。可是對接收方來講，只有接收到發送方的第三次握手以後，纔是創建鏈接的狀態。雙方都進入創建鏈接的狀態以後就能夠進行數據的傳輸了

爲何發送方要發出第三個確認報文呢？爲何兩次不行？

結論：避免已經失效的鏈接請求報文傳送到對方，引發錯誤

假設此時有一個發送方計算機和一個接收方計算機。首先發送方須要發送一個創建鏈接的請求報文（第一次握手），假設第一次握手的報文在網絡中傳輸好久纔到達接收方，由於發送了好久，因此，發送方好久都沒有收到接收方的確認消息。發送方就會認爲第一個報文已經超時了，因此，發送方就會第二次發送一樣的報文

假設第二次發送的報文，很快就到達了對方，接收方在收到第二次的鏈接請求報文以後，就會進行迴應，而且創建起它們之間的鏈接。那麼，對於發送方發送的第一次的請求報文，就應該是一個失效的請求報文，由於它的功能已經被第二次的鏈接請求所完成了。因此，對於第一次發送的請求鏈接報文，在網絡中游蕩了好久，其實就是一個失效的請求報文了，沒有做用了

若是發送方發送的兩次鏈接請求都創建起鏈接了會怎麼樣？

首先考慮第二次請求的報文，這個報文是提早到達接收方的，接收方會對它進行一個迴應，迴應確認以後，就創建起鏈接了（由於咱們是假設兩次握手就創建起鏈接）

如今考慮第一次發送的鏈接請求，若是兩次握手就創建鏈接的話，對於失效的請求，它也會創建起鏈接，由於只要接收方迴應了，就表示鏈接已經創建了

這樣就會致使，一樣的請求發送了兩次，就會創建兩個TCP鏈接的狀況。這種狀況是錯誤的，因此說，兩次握手是不正確的

三次握手是如何解決兩次握手致使的問題？

對於兩次握手，只要接收方迴應了，就表示鏈接創建了。而對於三次握手來講，第一個確認報文會首先到達發送方，而後發送方再發送一個確認報文（第三次握手），此時纔算創建起鏈接

如今來考慮那個比較慢到達接收方的鏈接請求報文，這個報文，接收方也會發送一個確認報文給發送方（第二次握手）。可是發送方已經進行第三次握手了，所以發送方對於第二次的確認消息會忽略掉，並不會進行任何的操做。這樣，第一次比較慢到達的鏈接請求就不會創建起鏈接，這就避免了兩次握手所致使的錯誤

TCP的四次揮手

TCP四次揮手過程

仍是假設這裏有一個發送方結算機和一個接收方計算機，縱向爲時間軸。鏈接正常的時候，雙方是能夠一直進行數據傳輸的。假設數據傳輸完成了，此時就會進行TCP鏈接的釋放。假設發送方主動的進行了鏈接的釋放

第一次揮手

發送方發送第一次揮手的報文，報文內容：

FIN=1：該標記表示須要釋放鏈接

seq=u：同步本身的序列號給接收方

此時發送方就進入了鏈接結束的第一個等待狀態（FIN-WAIT-1）

第二次揮手

接收方在收到發送方的斷開鏈接請求以後，它也會發送一個報文去確認，確認對方給我發送的序列號我已經收到了，確認報文內容是：

ACK=1：表示這個報文已經確認

seq=v：同步自身的序列號

ack=u+1：確認號是u+1，表示接收方指望接收到接發送方的序列號是u+1的數據

發送方接收到確認報文以後，就進入了鏈接結束的第二個等待狀態（FIN-WAIT-2）。而接收方在發送了第一個確認報文以後就進入了關閉等待狀態（CLOSE-WAIT）

這個時候其實接收方仍是能夠進行數據的發送的，由於釋放鏈接的請求是發送方發起的，表示說發送方的數據發送完成了，可是接收方可能尚未發送完成

第三次揮手

接收方發送完第一個確認報文以後，又會發送一個新的報文，這個報文會攜帶FIN=1的標記，表示它也能夠進行鏈接釋放了，而且裏邊會攜帶一個ack，表示重複的對發送方發送的序列號進行確認，該報文中的完整內容：

FIN=1：該標記表示須要釋放鏈接，是一個釋放鏈接的請求

ACK=1：表示確認報文已經收到

seq=w：給發送方同步本身的序列號

ack=u+1：確認號是u+1，表示接收方指望接收到接發送方的序列號是u+1的數據

第四次揮手

發送方接收到接收方的確認報文以後，又會發送一個確認報文，確認接收方發送的報文我已經收到了，此時能夠釋放掉鏈接了

在接收方發送斷開鏈接的請求到發送方的確認報文被接收方收到這之間，接收方處於最後確認狀態（LAST-ACK）。是爲了確認發送方已經接收到了鏈接釋放的報文，此時發送方進入了等待計時器狀態（TIME-WAIT）。發送方會在這個時間等待狀態中等待一段時間，確保這段時間沒有出現任何的問題，此時才進入關閉狀態（CLOSE）

以上即是四次揮手的過程