最近在惡補計算機網路方面的知識，之前對於TCP的三次握手和四次分手也是模模糊糊，對於其中的細節更是渾然不知，最近看了很多這方面的知識，也在系統的學習計算機網路，加深自己的CS功底，就把看過的一些比較好的東西和自己的一些理解二次加工組織一下然後交流分享，一起學習進步，對了這個面試好像經常問到。

原文收錄在我的 GitHub部落格 (https://github.com/jawil/blog) ，喜歡的可以關注最新動態，大家一起多交流學習，共同進步，以學習者的身份寫部落格，記錄點滴。

通俗理解:

但是為什麼一定要進行三次握手來保證連線是雙工的呢，一次不行麼？兩次不行麼？我們舉一個現實生活中兩個人進行語言溝通的例子來模擬三次握手。

引用網上的一些通俗易懂的例子，雖然不太正確，後面會指出，但是不妨礙我們理解，大體就是這麼個理解法。

第一次對話：

老婆讓甲出去打醬油，半路碰到一個朋友乙，甲問了一句：哥們你吃飯了麼？

結果乙帶著耳機聽歌呢，根本沒聽到，沒反應。甲心裡想：跟你說話也沒個音，不跟你說了，溝通失敗。說明乙接受不到甲傳過來的資訊的情況下溝通肯定是失敗的。

如果乙聽到了甲說的話，那麼第一次對話成功，接下來進行第二次對話。

第二次對話：

乙聽到了甲說的話，但是他是老外，中文不好，不知道甲說的啥意思也不知道怎樣回答，於是隨便回答了一句學過的中文 ：我去廁所了。甲一聽立刻笑噴了，“去廁所吃飯”?道不同不相為謀，離你遠點吧，溝通失敗。說明乙無法做出正確應答的情況下溝通失敗。

如果乙聽到了甲的話，做出了正確的應答，並且還進行了反問：我吃飯了，你呢？那麼第二次握手成功。

通過前兩次對話證明了乙能夠聽懂甲說的話，並且能做出正確的應答。 接下來進行第三次對話。

第三次對話：

甲剛和乙打了個招呼，突然老婆喊他，“你個死鬼，打個醬油咋這麼半天，看我回家咋收拾你”，甲是個妻管嚴，聽完嚇得二話不說就跑回家了，把乙自己晾那了。乙心想：這什麼人啊，得，我也回家吧，溝通失敗。說明甲無法做出應答的情況下溝通失敗。

如果甲也做出了正確的應答：我也吃了。那麼第三次對話成功，兩人已經建立起了順暢的溝通渠道，接下來開始持續的聊天。

通過第二次和第三次的對話證明了甲能夠聽懂乙說的話，並且能做出正確的應答。

可見，兩個人進行有效的語言溝通，這三次對話的過程是必須的。

為了保證服務端能收接受到客戶端的資訊並能做出正確的應答而進行前兩次(第一次和第二次)握手，為了保證客戶端能夠接收到服務端的資訊並能做出正確的應答而進行後兩次(第二次和第三次)握手。

這個例子舉得挺好的。不過個人感覺為什麼是三次而不是二次，不是因為為了證明甲能聽懂乙並回應（第二次乙能正確的響應甲說明倆人之間溝通已無障礙了），而是怕出現以下情況而浪費感情。這個情景是這樣的（例子有點不實際意會就好）：甲在路上跟乙打招呼，由於颳風什麼的這句活被吹跑了，然後甲又跟打了個招呼，乙聽到了並作出了迴應。此時不管是三次握手還是兩次握手兩個人都能愉快的溝通。0.1秒後倆人四次揮手告別了。此時被風颳跑的那句話又傳到了乙的耳朵裡，乙認為甲又要跟他溝通，所以做出了響應的迴應。（問題出現了）假如採用2次握手，乙就認定了甲要跟他溝通，於是就不停的等，浪費感情。可如果是採用3次握手，乙等了一會後發現甲沒有迴應他就認為甲走了然後自己也就走了！

這就很明白了，其實第三步是防止了乙的一直等待而浪費自己的時間，而不是為了保證甲能夠正確迴應乙的資訊。。。後面的也會講到。

引用知乎上的別人引用的一個回答，從另外一個角度闡釋：

在Google Groups的TopLanguage中看到一帖討論TCP“三次握手”覺得很有意思。貼主提出“TCP建立連線為什麼是三次握手？”的問題，在眾多回復中，有一條回覆寫道：“這個問題的本質是, 通道不可靠, 但是通訊雙發需要就某個問題達成一致. 而要解決這個問題, 無論你在訊息中包含什麼資訊, 三次通訊是理論上的最小值. 所以三次握手不是TCP本身的要求, 而是為了滿足"在不可靠通道上可靠地傳輸資訊"這一需求所導致的. 請注意這裡的本質需求,通道不可靠, 資料傳輸要可靠. 三次達到了, 那後面你想接著握手也好, 發資料也好, 跟進行可靠資訊傳輸的需求就沒關係了. 因此,如果通道是可靠的, 即無論什麼時候發出訊息, 對方一定能收到, 或者你不關心是否要保證對方收到你的訊息, 那就能像UDP那樣直接傳送訊息就可以了.”。這可視為對“三次握手”目的的另一種解答思路。

上面的純屬大白話娛樂講解，可能還有偏差，例子可能有點不得體。在我們真正瞭解TCP的三次握手和四次分手之前，必須瞭解一些基本的概念，最後和這大白話例子對比結合一下理解，說不定就會頓時融會貫通。

HTTP連線

HTTP協議即超文字傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。
HTTP連線最顯著的特點是客戶端傳送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連線。從建立連線到關閉連線的過程稱為“一次連線”。
1）在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨的連線，在處理完本次請求後，就自動釋放連線。

2）在HTTP 1.1中則可以在一次連線中處理多個請求，並且多個請求可以重疊進行，不需要等待一個請求結束後再發送下一個請求。

由於HTTP在每次請求結束後都會主動釋放連線，因此HTTP連線是一種“短連線”，要保持客戶端程式的線上狀態，需要不斷地向伺服器發起連線請求。通常 的做法是即時不需要獲得任何資料，客戶端也保持每隔一段固定的時間向伺服器傳送一次“保持連線”的請求，伺服器在收到該請求後對客戶端進行回覆，表明知道 客戶端“線上”。若伺服器長時間無法收到客戶端的請求，則認為客戶端“下線”，若客戶端長時間無法收到伺服器的回覆，則認為網路已經斷開。

SOCKET原理

套接字（socket）概念

套接字（socket）是通訊的基石，是支援TCP/IP協議的網路通訊的基本操作單元。它是網路通訊過程中端點的抽象表示，包含進行網路通訊必須的五種資訊：連線使用的協議，本地主機的IP地址，本地程序的協議埠，遠地主機的IP地址，遠地程序的協議埠。
應用層通過傳輸層進行資料通訊時，TCP會遇到同時為多個應用程式程序提供併發服務的問題。多個TCP連線或多個應用程式程序可能需要通過同一個 TCP協議埠傳輸資料。為了區別不同的應用程式程序和連線，許多計算機作業系統為應用程式與TCP／IP協議互動提供了套接字(Socket)介面。應 用層可以和傳輸層通過Socket介面，區分來自不同應用程式程序或網路連線的通訊，實現資料傳輸的併發服務。

建立socket連線

建立Socket連線至少需要一對套接字，其中一個運行於客戶端，稱為ClientSocket ，另一個運行於伺服器端，稱為ServerSocket 。
套接字之間的連線過程分為三個步驟：伺服器監聽，客戶端請求，連線確認。
伺服器監聽：伺服器端套接字並不定位具體的客戶端套接字，而是處於等待連線的狀態，實時監控網路狀態，等待客戶端的連線請求。
客戶端請求：指客戶端的套接字提出連線請求，要連線的目標是伺服器端的套接字。為此，客戶端的套接字必須首先描述它要連線的伺服器的套接字，指出伺服器端套接字的地址和埠號，然後就向伺服器端套接字提出連線請求。
連線確認：當伺服器端套接字監聽到或者說接收到客戶端套接字的連線請求時，就響應客戶端套接字的請求，建立一個新的執行緒，把伺服器端套接字的描述發 給客戶端，一旦客戶端確認了此描述，雙方就正式建立連線。而伺服器端套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連線請求。

SOCKET連線與TCP連線

建立Socket連線時，可以指定使用的傳輸層協議，Socket可以支援不同的傳輸層協議（TCP或UDP），當使用TCP協議進行連線時，該Socket連線就是一個TCP連線。

Socket連線與HTTP連線

由於通常情況下Socket連線就是TCP連線，因此Socket連線一旦建立，通訊雙方即可開始相互發送資料內容，直到雙方連線斷開。但在實際網 絡應用中，客戶端到伺服器之間的通訊往往需要穿越多箇中間節點，例如路由器、閘道器、防火牆等，大部分防火牆預設會關閉長時間處於非活躍狀態的連線而導致 Socket 連線斷連，因此需要通過輪詢告訴網路，該連線處於活躍狀態。
而HTTP連線使用的是“請求—響應”的方式，不僅在請求時需要先建立連線，而且需要客戶端向伺服器發出請求後，伺服器端才能回覆資料。
很多情況下，需要伺服器端主動向客戶端推送資料，保持客戶端與伺服器資料的實時與同步。此時若雙方建立的是Socket連線，伺服器就可以直接將數 據傳送給客戶端；若雙方建立的是HTTP連線，則伺服器需要等到客戶端傳送一次請求後才能將資料傳回給客戶端，因此，客戶端定時向伺服器端傳送連線請求， 不僅可以保持線上，同時也是在“詢問”伺服器是否有新的資料，如果有就將資料傳給客戶端。TCP(Transmission Control Protocol)　傳輸控制協議

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

位碼即tcp標誌位,有6種標示:SYN(synchronous建立聯機) ACK(acknowledgement 確認) PSH(push傳送) FIN(finish結束) RST(reset重置) URG(urgent緊急)
Sequence number(順序號碼) Acknowledge number(確認號碼)

TCP是什麼？

TCP（Transmission Control Protocol 傳輸控制協議）是一種面向連線的、可靠的、基於位元組流的傳輸層通訊協議。

具體的關於TCP是什麼，我不打算詳細的說了；當你看到這篇文章時，我想你也知道TCP的概念了，想要更深入的瞭解TCP的工作，我們就繼續。它只是一個超級麻煩的協議，而它又是網際網路的基礎，也是每個程式設計師必備的基本功。首先來看看OSI的七層模型：

我們需要知道TCP工作在網路OSI的七層模型中的第四層——Transport層，IP在第三層——Network層，ARP在第二層——Data Link層；在第二層上的資料，我們把它叫Frame，在第三層上的資料叫Packet，第四層的資料叫Segment。 同時，我們需要簡單的知道，資料從應用層發下來，會在每一層都會加上頭部資訊，進行封裝，然後再發送到資料接收端。這個基本的流程你需要知道，就是每個資料都會經過資料的封裝和解封裝的過程。 在OSI七層模型中，每一層的作用和對應的協議如下：

TCP是一個協議，那這個協議是如何定義的，它的資料格式是什麼樣子的呢？要進行更深層次的剖析，就需要了解，甚至是熟記TCP協議中每個欄位的含義。哦，來吧。



TCP頭部

其中 ACK SYN 序號 這三個部分在以下會用到，它們的介紹也在下面。

上面就是TCP協議頭部的格式，由於它太重要了，是理解其它內容的基礎，下面就將每個欄位的資訊都詳細的說明一下。

• Source Port和Destination Port:分別佔用16位，表示源埠號和目的埠號；用於區別主機中的不同程序，而IP地址是用來區分不同的主機的，源埠號和目的埠號配合上IP首部中的源IP地址和目的IP地址就能唯一的確定一個TCP連線；

• Sequence Number:用來標識從TCP發端向TCP收端傳送的資料位元組流，它表示在這個報文段中的的第一個資料位元組在資料流中的序號；主要用來解決網路報亂序的問題；

• Acknowledgment Number:32位確認序列號包含傳送確認的一端所期望收到的下一個序號，因此，確認序號應當是上次已成功收到資料位元組序號加1。不過，只有當標誌位中的ACK標誌（下面介紹）為1時該確認序列號的欄位才有效。主要用來解決不丟包的問題；

• Offset:給出首部中32 bit字的數目，需要這個值是因為任選欄位的長度是可變的。這個欄位佔4bit（最多能表示15個32bit的的字，即4*15=60個位元組的首部長度），因此TCP最多有60位元組的首部。然而，沒有任選欄位，正常的長度是20位元組；

• TCP Flags:TCP首部中有6個標誌位元，它們中的多個可同時被設定為1，主要是用於操控TCP的狀態機的，依次為URG，ACK，PSH，RST，SYN，FIN。每個標誌位的意思如下：

URG：此標誌表示TCP包的緊急指標域（後面馬上就要說到）有效，用來保證TCP連線不被中斷，並且督促中間層裝置要儘快處理這些資料；

ACK：此標誌表示應答域有效，就是說前面所說的TCP應答號將會包含在TCP資料包中；有兩個取值：0和1，為1的時候表示應答域有效，反之為0；

PSH：這個標誌位表示Push操作。所謂Push操作就是指在資料包到達接收端以後，立即傳送給應用程式，而不是在緩衝區中排隊；

RST：這個標誌表示連線復位請求。用來複位那些產生錯誤的連線，也被用來拒絕錯誤和非法的資料包；

SYN：表示同步序號，用來建立連線。SYN標誌位和ACK標誌位搭配使用，當連線請求的時候，SYN=1，ACK=0；連線被響應的時候，SYN=1，ACK=1；這個標誌的資料包經常被用來進行埠掃描。掃描者傳送一個只有SYN的資料包，如果對方主機響應了一個數據包回來 ，就表明這臺主機存在這個埠；但是由於這種掃描方式只是進行TCP三次握手的第一次握手，因此這種掃描的成功表示被掃描的機器不很安全，一臺安全的主機將會強制要求一個連線嚴格的進行TCP的三次握手；

FIN： 表示傳送端已經達到資料末尾，也就是說雙方的資料傳送完成，沒有資料可以傳送了，傳送FIN標誌位的TCP資料包後，連線將被斷開。這個標誌的資料包也經常被用於進行埠掃描。

• Window:視窗大小，也就是有名的滑動視窗，用來進行流量控制；這是一個複雜的問題，這篇博文中並不會進行總結的；

暫時需要的資訊有：

ACK ： TCP協議規定，只有ACK=1時有效，也規定連線建立後所有傳送的報文的ACK必須為1

SYN(SYNchronization) ： 在連線建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連線請求報文。對方若同意建立連線，則應在響應報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連線請求或連線接受報文。

FIN （finis）即完，終結的意思， 用來釋放一個連線。當 FIN = 1 時，表明此報文段的傳送方的資料已經發送完畢，並要求釋放連線。

三次握手的過程：

多麼清晰的一張圖，當然了，也不是我畫的，我也只是引用過來說明問題了。

1. 第一次握手：建立連線。客戶端傳送連線請求報文段，將SYN位置為1，Sequence Number為x；然後，客戶端進入SYN_SEND狀態，等待伺服器的確認；
2. 第二次握手：伺服器收到SYN報文段。伺服器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設定Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要傳送SYN請求資訊，將SYN位置為1，Sequence Number為y；伺服器端將上述所有資訊放到一個報文段（即SYN+ACK報文段）中，一併傳送給客戶端，此時伺服器進入SYN_RECV狀態；
3. 第三次握手：客戶端收到伺服器的SYN+ACK報文段。然後將Acknowledgment Number設定為y+1，向伺服器傳送ACK報文段，這個報文段傳送完畢以後，客戶端和伺服器端都進入ESTABLISHED狀態，完成TCP三次握手。
   完成了三次握手，客戶端和伺服器端就可以開始傳送資料。以上就是TCP三次握手的總體介紹。

那四次分手呢？

當客戶端和伺服器通過三次握手建立了TCP連線以後，當資料傳送完畢，肯定是要斷開TCP連線的啊。那對於TCP的斷開連線，這裡就有了神祕的“四次分手”。

1. 第一次分手：主機1（可以使客戶端，也可以是伺服器端），設定Sequence Number和Acknowledgment Number，向主機2傳送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有資料要傳送給主機2了；
2. 第二次分手：主機2收到了主機1傳送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我“同意”你的關閉請求；
3. 第三次分手：主機2向主機1傳送FIN報文段，請求關閉連線，同時主機2進入LAST_ACK狀態；
4. 第四次分手：主機1收到主機2傳送的FIN報文段，向主機2傳送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連線；此時，主機1等待2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，主機1也可以關閉連線了。

至此，TCP的四次分手就這麼愉快的完成了。當你看到這裡，你的腦子裡會有很多的疑問，很多的不懂，感覺很凌亂；沒事，我們繼續總結。

為什麼要三次握手

在謝希仁著《計算機網路》第四版中講“三次握手”的目的是“為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤”。在另一部經典的《計算機網路》一書中講“三次握手”的目的是為了解決“網路中存在延遲的重複分組”的問題。

在謝希仁著《計算機網路》書中同時舉了一個例子，如下：

“已失效的連線請求報文段”的產生在這樣一種情況下：client發出的第一個連線請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連線釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連線請求報文段後，就誤認為是client再次發出的一個新的連線請求。於是就向client發出確認報文段，同意建立連線。假設不採用“三次握手”，那麼只要server發出確認，新的連線就建立了。由於現在client並沒有發出建立連線的請求，因此不會理睬server的確認，也不會向server傳送資料。但server卻以為新的運輸連線已經建立，並一直等待client發來資料。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連線。”

這就很明白了，防止了伺服器端的一直等待而浪費資源。

為什麼要四次分手

那四次分手又是為何呢？TCP協議是一種面向連線的、可靠的、基於位元組流的運輸層通訊協議。TCP是全雙工模式，這就意味著，當主機1發出FIN報文段時，只是表示主機1已經沒有資料要傳送了，主機1告訴主機2，它的資料已經全部發送完畢了；但是，這個時候主機1還是可以接受來自主機2的資料；當主機2返回ACK報文段時，表示它已經知道主機1沒有資料傳送了，但是主機2還是可以傳送資料到主機1的；當主機2也傳送了FIN報文段時，這個時候就表示主機2也沒有資料要傳送了，就會告訴主機1，我也沒有資料要傳送了，之後彼此就會愉快的中斷這次TCP連線。如果要正確的理解四次分手的原理，就需要了解四次分手過程中的狀態變化。

• FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連線，向對方傳送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。（主動方）
• FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連線，也即有一方要求close連線，但另外還告訴對方，我暫時還有點資料需要傳送給你(ACK資訊)，稍後再關閉連線。（主動方）
• CLOSE_WAIT：這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後傳送FIN報文給自己，你係統毫無疑問地會迴應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料傳送給對方，如果沒有的話，那麼你也就可以 close這個SOCKET，傳送FIN報文給對方，也即關閉連線。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連線。（被動方）
• LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在傳送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。（被動方）
• TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FINWAIT1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。（主動方）
• CLOSED: 表示連線中斷。

例項:

TCP的作用是流量控制，主要是控制資料流的傳輸。下面以瀏覽網頁為例，根據自身理解來解釋一下這個過程。（注：第二個ack屬於程式碼段ack位）

握手過程中傳送的包裡不包含資料，三次握手完畢後，客戶端與伺服器才正式開始傳送資料。

第一次握手：客戶端傳送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=k+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包裡不包含資料，三次握手完畢後，客戶端與伺服器才正式開始傳送資料。理想狀態下，TCP連線一旦建立，在通訊雙方中的任何一方主 動關閉連線之前，TCP 連線都將被一直保持下去。斷開連線時伺服器和客戶端均可以主動發起斷開TCP連線的請求，斷開過程需要經過“四次握手”（過程就不細寫了，就是伺服器和客 戶端互動，最終確定斷開）

對應的例項

IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1

第一次握手：192.168.1.116傳送位碼syn＝1,隨機產生seq number=3626544836的資料包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立聯機;

第二次握手：192.168.1.123收到請求後要確認聯機資訊，向192.168.1.116傳送ack number=3626544837,syn=1,ack=1,隨機產生seq=1739326486的包;

第三次握手：192.168.1.116收到後檢查ack number是否正確，即第一次傳送的seq number+1,以及位碼ack是否為1，若正確，192.168.1.116會再發送ack number=1739326487,ack=1，192.168.1.123收到後確認seq=seq+1,ack=1則連線建立成功。

我想你應該懂了

總結到這裡，也該結束了，但是對於TCP的學習遠還沒有結束。TCP是一個非常複雜的協議，這裡稍微總結了一下TCP的連線與斷開連線是發生的事情，其中還有很多的“坑”，讓我們後續有時間再繼續填吧。好了，完畢！