連 接 概 述

順著第一篇的思路下來，到最后我們已經可以依靠分層達到兩臺主機之間的自由通信，那么問題來了，假設現在有主機A（客戶端）及主機B（服務端），其中主機A需要訪問主機B的資源，需要哪幾個必要條件呢？經過上篇文章可知至少需要四個條件：

• 主機A需要具有一個ip地址
• 主機B需要具有一個ip地址
• 主機A需要具有一個客戶端端口號
• 主機B需要具有一個服務端端口號

具備上述四個條件后A獲取B的信息是有要求的，根本上的要求是數據信道可靠，就是平時所說的可靠連接，那么如何保證連接的可靠性呢，TCP協議就是靠確認應答機制、超時重傳機制等保證連接可靠性的，接下來就通過TCP協議的三次握手及四次（三次）揮手來分析一下A與B建立連接、關閉連接的技術細節是如何落地實現的。

三 次 握 手

第一次： 首先客戶端A會向服務端B發送一個數據同步請求，可以稱為建立連接請求syn，同時客戶端A 的cpu內核會為這個syn請求生成一個隨機的序列號seq發送給服務端。此處整體稱為第一次握手，注意此處為隨機序列號。

第二次： 服務端B接到客戶端A發送的syn請求后，會回復一個[syn+ack]的響應，其中syn仍表達數據同步的意思，這個應答seq值由服務端B的cpu隨機生成，ack的值為第一次握手seq的值+1，ack表示兩層含義：

• 服務端B已經收到了客戶端A發過來的數據同步請求
• 希望客戶端接下來的應答消息的seq的值以ack回復的值開始傳輸。

這個稱為第二次握手。

第三次： 客戶端A接收到服務端B的[syn+ack]應答消息會給B回復一個ack應答，ack消息中seq值為第二次握手ack的值，而ack則為第二次握手的請求的seq值+1。

三次握手通信釋義圖如上所示，接下來我們來通過抓包的形式來看一下實際報文，印證三次握手的報文通信。

筆者通過wireshark（抓包工具）抓取數據包，采用打開一個瀏覽器網頁的場景模擬對服務器B的請求。

第一次握手抓包圖如下：

第二次握手抓包釋義圖如下：

第三次握手抓包釋義圖如下：

通過三次握手的抓包可以很清晰的展示三次交互流程，可能有人會有連帶的疑問，為什么一定是三次，而不是別的次數，這里三次其實是最優的次數，而不是一定的次數，比如如果兩次的話A、B兩方將會有一方無法做出信息是否送達的確認，而超過三次則造成了浪費，因為三次交互中A、B都已經對兩方應答一次了。接下來來看一下四次揮手的交互流程。

四 次 揮 手

理解三次握手及流程后，四次揮手其實本質和三次握手的確認流程基本上是一樣的，下面我們簡單梳理一下揮手標準流程。

第一次： 當A確認當前連接數據已經全部發送完成以后，會發起關閉連接請求，此時A不再發送業務報文，發送的請求標志為FIN ,seq為x,此處整體為第一次揮手。

第二次： B收到A發出的關閉連接的請求之后，會給A一個確認響應，告訴A我收到你關閉連接的請求了，但是我有可能還有沒發完的數據需要繼續給你發送，響應的標志為ack,seq為Y，ack為x+1，此處整體為第二次揮手。

第三次： 當B把數據傳輸完之后會發送釋放連接響應，此處標志B釋放連接，不會再發送業務報文，此時請求的標志為FIN+ack，seq的值為y，ack的值為x+1,此處整體為第三次揮手。

第四次： A對B第三次揮手做最后確認，并釋放連接，此時請求標志為ack，seq為x+1,ack為y+1。

四次揮手通信釋義圖如上所示，由于三次握手的每一次都通過抓包工具詳細描述了通信詳情，此處揮手抓一個整體包截圖，由讀者自行解析分析即可。

四次揮手抓包整體釋義圖如下：

可以看到，這里面的揮手包數與咱們分析的標準流程不一樣，這里是因為第二次和第三次揮手都是B向A發起確認響應，區別是第二次只是確認，因為可能還有數據沒有傳完，要繼續傳，全部數據傳完后B才能發出最后指令進行釋放連接，但這時如果發第二次揮手的時候就可以確認沒有數據需要再同步給A了，這時如果按照標準流程，B會給A發送兩個相同的數據包，這樣就造成了資源浪費，故這塊揮手做了優化，可以確認數據的情況下，可以把第二次和第三次揮手合并成一次，所以此處是三次握手。