客戶端與伺服器之間資料的傳送和返回的過程當中需要建立乙個叫tcp connection的東西；
由於tcp不存在連線的概念，只存在請求和響應，請求和響應都是資料報，它們之間都是經過由tcp建立的乙個從客戶端發起，伺服器接收的類似連線的通道，這個連線可以一直保持，http請求是在這個連線的基礎上傳送的；
在乙個tcp連線上是可以傳送多個http請求的，不同的版本這個模式不一樣。
在http/1.0中這個tcp連線是在http請求建立的時候同步建立的，http請求傳送到伺服器端，伺服器端響應了之後，這個tcp連線就關閉了；
http/1.1中可以以某種方式宣告這個連線一直保持，乙個請求傳輸完之後，另乙個請求可以接著傳輸。這樣的好處是：在建立乙個tcp連線的過程中需要「三次握手」的消耗，「三次握手」代表有三次網路傳輸。
如果tcp連線保持，第二個請求傳送就沒有這「三次握手」的消耗。http/2中同乙個tcp連線裡還可以併發地傳輸http請求。
其中比較重要的字段有：
（1）序號（sequence number）：seq序號，佔32位，用來標識從tcp源端向目的端傳送的位元組流，發起方傳送資料時對此進行標記。
（2）確認號（acknowledgement number）：ack序號，佔32位，只有ack標誌位為1時，確認序號欄位才有效，ack=seq+1。
（3）標誌位（flags）：共6個，即urg、ack、psh、rst、syn、fin等，具體含義如下：
需要注意的是：
所謂的三次握手即tcp連線的建立。這個連線必須是一方主動開啟，另一方被動開啟的。
以下為客戶端主動發起連線的**：
握手之前主動開啟連線的客戶端結束closed階段，被動開啟的伺服器端也結束closed階段，並進入listen階段。隨後開始「三次握手」：
（1）首先客戶端向伺服器端傳送一段tcp報文，其中：
標記位為syn，表示「請求建立新連線」;
序號為seq=x（x一般為1）；
隨後客戶端進入syn-sent階段。
（2）伺服器端接收到來自客戶端的tcp報文之後，結束listen階段。並返回一段tcp報文，其中：
標誌位為syn和ack，表示「確認客戶端的報文seq序號有效，伺服器能正常接收客戶端傳送的資料，並同意建立新連線」（即告訴客戶端，伺服器收到了你的資料）；
序號為seq=y；
確認號為ack=x+1，表示收到客戶端的序號seq並將其值加1作為自己確認號ack的值；隨後伺服器端進入syn-rcvd階段。
（3）客戶端接收到來自伺服器端的確認收到資料的tcp報文之後，明確了從客戶端到伺服器的資料傳輸是正常的，結束syn-sent階段。並返回最後一段tcp報文。其中：
標誌位為ack，表示「確認收到伺服器端同意連線的訊號」（即告訴伺服器，我知道你收到我發的資料了）；
序號為seq=x+1，表示收到伺服器端的確認號ack，並將其值作為自己的序號值；
確認號為ack=y+1，表示收到伺服器端序號seq，並將其值加1作為自己的確認號ack的值；
隨後客戶端進入established階段。
伺服器收到來自客戶端的「確認收到伺服器資料」的tcp報文之後，明確了從伺服器到客戶端的資料傳輸是正常的。結束syn-sent階段，進入established階段。
在客戶端與伺服器端傳輸的tcp報文中，雙方的確認號ack和序號seq的值，都是在彼此ack和seq值的基礎上進行計算的，這樣做保證了tcp報文傳輸的連貫性。一旦出現某一方發出的tcp報文丟失，便無法繼續"握手"，以此確保了"三次握手"的順利完成。
此後客戶端和伺服器端進行正常的資料傳輸。這就是「三次握手」的過程。
舉個栗子：把客戶端比作男孩，伺服器比作女孩。用他們的交往來說明「三次握手」過程：
女孩收到男孩的回信之後，也很開心，因為發出的情書男孩收到了。由此男孩女孩雙方都知道了彼此的心意，之後就快樂地交流起來了~~
這就是通俗版的「三次握手」，期間一共往來了三封信也就是「三次握手」，以此確認兩個方向上的資料傳輸通道是否正常。為了防止伺服器端開啟一些無用的連線增加伺服器開銷以及防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤。
由於網路傳輸是有延時的(要通過網路光纖和各種中間**伺服器)，在傳輸的過程中，比如客戶端發起了syn=1建立連線的請求(第一次握手)。
如果伺服器端就直接建立了這個連線並返回包含syn、ack和seq等內容的資料報給客戶端，這個資料報因為網路傳輸的原因丟失了，丟失之後客戶端就一直沒有接收到伺服器返回的資料報。
客戶端可能設定了乙個超時時間，時間到了就關閉了連線建立的請求。再重新發出建立連線的請求，而伺服器端是不知道的，如果沒有第三次握手告訴伺服器端客戶端收的到伺服器端傳輸的資料的話，
伺服器端是不知道客戶端有沒有接收到伺服器端返回的資訊的。
這個過程可理解為：這樣沒有給伺服器端乙個建立還是關閉連線埠的請求，伺服器端的埠就一直開著，等到客戶端因超時重新發出請求時，伺服器就會重新開啟乙個埠連線。那麼伺服器端上沒有接收到請求資料的上乙個埠就一直開著，長此以往，這樣的埠多了，就會造成伺服器端開銷的嚴重浪費。
還有一種情況是已經失效的客戶端發出的請求資訊，由於某種原因傳輸到了伺服器端，伺服器端以為是客戶端發出的有效請求，接收後產生錯誤。
所以我們需要「第三次握手」來確認這個過程，讓客戶端和伺服器端能夠及時地察覺到因為網路等一些問題導致的連線建立失敗，這樣伺服器端的埠就可以關閉了不用一直等待。
也可以這樣理解：「第三次握手」是客戶端向伺服器端傳送資料，這個資料就是要告訴伺服器，客戶端有沒有收到伺服器「第二次握手」時傳過去的資料。若傳送的這個資料是「收到了」的資訊，接收後伺服器就正常建立tcp連線，否則建立tcp連線失敗，伺服器關閉連線埠。由此減少伺服器開銷和接收到失效請求發生的錯誤。
下面是用抓包工具抓到的一些資料報，可用來分析tcp的三次握手：
圖中顯示的就是完整的tcp連線的」三次握手」過程。在52528 -> 80中，52528是本地(客戶端)埠，80是伺服器的埠。80埠和52528埠之間的三次來回就是"三次握手"過程。
詳解tcp連線的「三次握手」與「四次揮手」(下)
參考資料：深入淺出**【計算機網路】 之 【tcp可靠傳輸的實現: 三次握手+滑動視窗】
使用 wireshark 分析 tcp/ip 三次握手 和 四次揮手
TCP三次握手與四次握手
當我們從瀏覽器輸入乙個url，http的工作流程如下圖所示 dns解析流程請看dns網域名稱解析過程這篇文章 現在來講tcp三次握手 tcp是主機對主機層的傳輸控制協議，提供可靠的連線服務，採用三次握手確認建立乙個連線。1 序號 seq序號，佔32位，用來標識從tcp源端向目的端傳送的位元組流，發起...
tcp 三次握手連線，四次握手斷開
tcp握手協議 在tcp ip協議中,tcp協議提供可靠的連線服務,採用三次握手建立乙個連線.第一次握手 建立連線時,客戶端傳送syn包 syn j 到伺服器,並進入syn send狀態,等待伺服器確認 syn 同步序列編號 synchronize sequence numbers 第二次握手 伺服...
TCP 三次握手 四次握手
http常見狀態碼 200 ok 伺服器成功處理了請求 301 302 moved permanently 重定向 response中應該包含乙個location url,說明資源現在所處的位置 304 not modified 未修改 客戶的快取資源是最新的，要客戶端使用快取 404 not fo...