通俗解釋

（A和B打電話）

A:“喂，你聽得到嗎？”A->SYN_SEND

B:“我聽得到呀，你聽得到我嗎？”應答與請求同時發出 B->SYN_RCVD | A->ESTABLISHED

A:“我能聽到你，今天balabala……”B->ESTABLISHED

建立連線，開始聊天！

三次握手及建立TCP連線，建立一個TCP連線時，需要客戶端和服務端總共傳送3個包以確認連線的建立，這一過程有客戶端執行connect來觸發，流程如下：

圖 1 三次握手原理圖

握手之前主動開啟連線的客戶端結束Closed階段，被動開啟的伺服器端也結束Closed階段，並進入Listen階段，隨後開始三次握手。

1） 第一次握手，客戶端傳送syn包（SYN=1，seq=n）到伺服器端，此時客戶端進入SYN_SENT狀態，等待伺服器端確認。第一個syn包：SYN=1，seq=n，n為隨機數。

2） 第二次握手，伺服器端接收到syn包，結束Listen階段，並返回一個syn包（SYN=1，ACK=1，seq=k，ack=n+1），此時伺服器端進入SYN_RCVD階段，等待客戶端確認。第二個syn包：SYN=1，ACK=1，seq=k，ack=n+1，k為隨機數。

3） 第三次握手，客戶端接收到來自伺服器端的syn包，明確了資料傳輸是正常的，結束SYN_SENT階段，並向伺服器端返回一個syn包，客戶端進入Established階段。第三個syn包：ACK=1，seq=n+1，ack=k+1。

伺服器端接收到來自客戶端的確認之後，明確了資料傳輸是正常的，結束SYN_RCVD階段，進入Established階段。

在客戶端與伺服器端傳輸的syn包中，雙方的確認號ack和序號seq的值，都是在彼此ack和seq值的基礎上進行計算的，這樣做保證了TCP報文傳輸的連貫性。一旦出現某一方發出的syn包丟失，便無法繼續"握手"，以此確保了"三次握手"的順利完成。

此後客戶端和伺服器端進行正常的資料傳輸。這就是"三次握手"的過程。

TCP（傳輸控制協議）位於網路層（IPv4或者IPv6）之上，用來給上層應用提供一種面向連線的、可靠的位元組流服務。主要是這三個特性：面向連線、可靠、位元組流。透過這三個特性，可以很好的理解TCP以及三次握手原理。

面向連線：是指交換資料前，通訊雙方必須透過相互聯絡來建立一個TCP連線，然後才可以傳輸資料。所以使用TCP的應用在資料可交換前，透過三次握手建立連線。同時連線的狀態也需要維護，部分資訊也在三次握手中完成協商，比如MSS欄位。TCP連線是雙向的，雙方維護自己的TCP連線。

位元組流：這是一種與上層應用互動的方式，對於應用程式來說，只需要將資料按照位元組流送個TCP即可，TCP負責把這些位元組按照寫入順序送到對端。應用程式可以寫入10位元組，然後寫入20位元組，然後寫入30位元組。TCP只負責把這些資料傳遞給對方，可能透過一個報文，也可能透過兩個報文，或者三個報文，這個對上面是不透明的，但最終結果是這些資料按照寫入的順序流，到達對方。

可靠的：TCP透過確認ACK和序列號來保證資料傳輸的可靠性。本端向對端傳送的資訊（序列號為N），對端收到後，會返回一個帶ACK標誌，序列號為N+1的報文，期望本端傳送後面的位元組流。在實際中，為了效率，本端並不會收到每個報文的ACK報文後，才傳送下一個報文，而是傳送一組報文，對端只返回最後一個報文的ACK，表明該報文以及前面的報文都已收到。但是對於SYN報文，是立刻返回ACK的。

由這三個性質，就可以理解三次握手原理。因為是面向連線的，所以需要SYN標誌建立連線，獲取相關資訊，主要是首包序列號（如果沒有獲取首包序列號，則不知道資料從哪裡開始傳輸，否則開頭即使丟包也無法知道）；因為是可靠的，需要ACK和序列號來確保可靠；同時連線是雙向的，所以本端對端都需要SYN+ACK互動。可以理解為兩次互動，對於本端來說，傳送SYN報文，接受ACK；對於對端來說，傳送SYN報文，接受ACK，其實就是三次握手所做的工作。

根據我所知道的回答一下這個問題。

TCP的三次握手，有兩個作用：

建立通訊雙方的端到端的連線

完成通訊雙方的認證

TCP建立連線的過程是客戶端和伺服器之間的通訊過程。

TCP建立連線三次握手的過程如下圖所示：

第一次握手：客戶端傳送SYN=1，seq=x報文到伺服器端

第二次握手：服務端收到客戶端報文之後，傳送SYN=1，seq=y(服務端的序列號),ack=x+1(確認客戶端的序列號)

第三次握手：客戶端收到服務端的報文之後，傳送ACK=1（標識確認報文) seq=x+1,ack=y+1(確認服務端的序列號為y報文)

要深入瞭解TCP建立連線的三次握手，需要了解一下TCP報文的首部資訊。

如下圖所示，顯示了TCP報文的首部，與TCP三次握手相關的欄位是：

控制位（5位)：SYN、ACK。用於傳輸TCP建立連線的控制資料，SYN標識同步報文、ACK標識確認報文。

序號(32位)：Seq。用於標識傳輸報文的序號，同時用於雙方的認證，用（源ip地址、目的ip地址、源埠、目的埠)標識端對端的通訊，用（序列號、確認號）標識報文。

確認號(32位)：Ack。用於標識傳輸報文的確認號，確認對方的報文。

TCP的三次握手是TCP連線的第一步，完成客戶端和服務端的建立連線。

TCP三次握手的過程，同時完成了客戶端和服務端透過序列號和確認號完成雙方的認證。

關於TCP協議三次握手的問題，在面試中是最為常見的知識點之一，得到了很多面試官的青睞，如果這個知識點沒有掌握好，面試官要是問得深入一點，求職者往往會不知所措。

為什麼建立連線需要三次握手？

首先非常明確的是兩次握手是最基本的。第一次握手，客戶端發了個連線請求訊息到服務端，服務端收到資訊後知道自己與客戶端是可以連線成功的，但此時客戶端並不知道服務端是否已經接收到了它的請求，所以服務端接收到訊息後得應答，客戶端得到服務端的反饋後，才確定自己與服務端是可以連線上的，這就是第二次握手。

客戶端只有確定了自己能與服務端連線上才能開始發資料。所以兩次握手肯定是最基本的。

看到這裡，你或許會問，那麼為什麼需要第三次握手呢？我們來看一下，假設一下如果沒有第三次握手，而是兩次握手後我們就認為連線成功了，那麼會發生什麼？第三次握手是為了防止已經失效的連線請求報文段突然又傳到服務端，因而產生錯誤。

譬如發起請求遇到類似這樣的情況：客戶端發出去的第一個連線請求由於某些原因在網路節點中滯留了導致延遲，直到連線釋放的某個時間點才到達服務端，這是一個早已失效的報文，但是此時服務端仍然認為這是客戶端的建立連線請求第一次握手，於是服務端迴應了客戶端，第二次握手。

如果只有兩次握手，那麼到這裡，連線就建立了，但是此時客戶端並沒有任何資料要傳送，而服務端還在傻傻的等候佳音，造成很大的資源浪費。所以需要第三次握手，只有客戶端再次迴應一下，就可以避免這種情況。

如果你覺得上面的闡述過於專業化，還是有點萌萌的，不要緊，下面我們來個生活案例來闡述。

TCP 三次握手好比在一個夜高風黑的夜晚，你一個人在小區裡散步，不遠處看見小區裡的一位漂亮妹子迎面而來，但是因為路燈有點暗等原因不能100%確認，所以要透過招手的方式來確定對方是否認識自己。

你首先向妹子招手(syn)，妹子看到你向自己招手後，向你點了點頭擠出了一個微笑(ack)。你看到妹子微笑後確認了妹子成功辨認出了自己(進入estalished狀態)。

但是妹子有點不好意思，向四周看了一看，有沒有可能你是在看別人呢，她也需要確認一下。妹子也向你招了招手(syn)，你看到妹子向自己招手後知道對方是在尋求自己的確認，於是也點了點頭擠出了微笑(ack)，妹子看到對方的微笑後確認了你就是在向自己打招呼(進入established狀態)。

於是兩人加快步伐，走到了一起，彼此之間相互擁抱。

我們來回顧一下，這個過程中總共有四個動作，

你招手

妹子點頭微笑

妹子招手

你點頭微笑

其中妹子連續進行了兩個動作，先是點頭微笑(回覆對方)，然後再次招手(尋求確認)，實際上我們可以將這兩個動作合成一個動作，招手的同時點頭和微笑(syn+ack)。於是這四個動作就簡化成了三個動作。

你招手

妹子點頭微笑並招手

你點頭微笑

這就是三次握手的本質，中間的一次動作是兩個動作的合併。透過這個案例，不知你對TCP三次握手，有沒有進一步的理解。

握手完成後，開始TCP 資料傳輸

TCP 資料傳輸就是兩個人隔空交流，有一定的距離，需要對方反覆確認聽見了自己的話。

你喊了一句話(data)，妹子聽見了之後要向你回覆自己聽見了(ack)。如果你喊了一句，半天沒聽到妹子回覆，你會很低落，好比談戀愛的時候，你滿腔熱情，而妹子忽冷忽熱，所以你鍥而不捨，一次不行，就兩次，兩次不行就三次，這就是tcp重傳。

也有可能是妹子知道你的本意了，但是妹子有點害羞，遲遲沒有回覆亦或是妹子回覆了你沒收到，以至於你沒收到妹子的回覆。你不能判斷究竟到底妹子喜不喜歡你，對你有沒有好感，沒關係，男人嘛？要主動點，重傳一下就好。

既然會重傳，妹子就有可能同一句話聽見了兩次，這就是去重。對於重傳和去重這兩項工作作業系統的網路核心模組都已經幫我們處理好了，我們不用理會。

【END】

如何理解TCP的三次握手原理？根據題意的題意，三次握手就是為了客戶端與伺服器之間建立連線。TCP協議中文名傳輸控制協議，是一系列規則的集合，使用時需要跟網際協議（IP）共同使用，是以網際網路在計算機之間由資訊單元形式傳送資料。而IP協議是控制實際資料傳輸，TCP協議負責追蹤在網際網路上傳送的資訊所劃分的各個資料單元，也就是所謂的"包"。TCP協議是面向連線協議，也就是說兩端在傳輸資訊時連線是一直處於建立和保持的狀態。其負責把資訊劃分為IP協議能夠處理的，也要把接受到的包拼成一個完整的資訊。

TCP的三次握手原理

TCP會話初期所謂的三次握手，也就是對每次傳送的資料量是如何跟蹤進行協商，使資料端的傳送和接受同步，而根據接收到的資料量來確定資料及確定資料傳送，接受完畢後何時撤銷聯絡並建立虛擬連線。TCP握手協議在TCP/IP協議中，TCP協議可提供可靠的連線服務，採用三次握手原理來建立一個可靠的連線。

第一次握手：建立連線時，客戶端傳送"包"至伺服器，並進入SYN-SEND狀態，來等伺服器確認。

第二次握手：伺服器接受到客服端發來的"包"，此時確認客戶的SYN包，同時也會為自己傳送一個SYN包，即SYN+ACK包，這時候伺服器就會進入SYN-RECV狀態，準備給客戶端傳送SYN+ACK包。

第三次握手：客戶端接受到伺服器傳送過來的SYN+ACK包後，就會向伺服器傳送確認包ACK，這個包傳送完成，此時客戶端和伺服器都會進入ES-TABLISHED狀態，表示三次握手已經完成。因此，三次握手完成，客戶端和伺服器就可以進行資料傳輸了。

現在不想連線了，TCP也要相互確認後才可斷開連線，此過程採用的是四次揮手原理。

四次揮手

第一次揮手：斷開連線時，客戶端傳送一個FIN＝1的請求給伺服器，要求斷開，等待伺服器確認。

第二次揮手：伺服器接受到客戶端發來的請求，傳送ACK＝1進行確認，確認資訊後傳送。

第三次揮手：伺服器傳送一個FIN＝1的包至客戶端，與源主機斷開，等待源主機返回一個ACK＝1的資訊。

第四次揮手：客戶端接受到伺服器傳送的FIN＝1的包，確認後傳送ACK＝1的資訊至伺服器，這樣四次揮手完成，完成客戶端與伺服器之間的連線。

TCP為什麼需要三次握手而不是四次揮手呢？從三次揮手原理看，四次握手原理是在三次握手原理的第三次握手基礎上，伺服器把確認的ACK包再次傳送至客戶端。實際上這樣的過程可以無限迴圈下去，其實三次握手就已經能夠讓雙方都知道對方裝置是好用的且次數是最少的。如此看來不採用四次握手而採用三次握手，是為了減少資源浪費，因此第四次握手相當多餘的。

這種問題，我習慣用通俗的方式來解釋一個專業名詞，那什麼是TCP的三次握手呢，我談談自己的理解：

一個很熟悉的場景：

路人甲：你瞅啥？

路人乙：瞅你咋地？

路人甲：來，過來嘮嘮。

然後路人甲和路人乙，透過三次握手建立了連線，開始“愉快”的交談（通訊）。

一句話概括：就是為了通訊兩方在通訊前，要互相確認對方是可以接受到訊息的（通訊的可靠性）。

路人甲：你瞅啥？說明甲能傳送訊息，但是乙不一定能收到訊息。

路人乙：瞅你咋地？說明甲能傳送訊息，乙能接受訊息，也能傳送訊息，但是不確定甲能不能收到訊息。

路人甲：來，過來嘮嘮。說明甲能傳送訊息，乙能接受訊息，也能傳送訊息，甲最後也能收到訊息。

兩方都確認完畢，開始通訊。

我們經常會聽到TCP和UDP，它倆經常是成對兒出現的，那麼UDP和TCP有什麼不同呢？

從上面的解釋可以看出，TCP對安全性、可靠性要求高，真正通訊之前要三次握手；並且TCP的訊息都是有序的。

而UDP則應是用在資料量大、速度要求快的場景，至於可靠性，則不太關心；UDP的訊息也是沒有順序的。

個人覺得現有的回答都是在回答「什麼是TCP三次握手？」而不是在回答「如何理解TCP的三次握手原理？」！

要回答這個問題，要先看另外一個問題：「兩軍問題」！

兩軍問題的描述是這樣的：兩隻軍隊分別佔領了兩個山頭，準備同時攻打敵軍。兩軍透過通訊兵來確認何時一起攻擊，因為單獨進攻都會全軍覆滅。但是通訊兵需要越過一個山頭，這個山頭被敵軍佔領。也就是說，通訊兵不一定能越過這個山頭，這就可能有幾種情況：

通訊兵越過山頭了，友軍收到了真實訊息

通訊兵沒有越過山頭，被俘虜了

敵軍偽裝通訊兵，友軍收到了偽造的資訊

也就是說：「在一個不可靠的通訊鏈路上試圖透過通訊以達成一致是存在缺陷和困難的」！

TCP三次握手就是一個存在缺陷的方案！甚至都不能算是個解決方案，是一種妥協！

還以上面的例子：

A通訊兵攜帶秘鑰a，通知B軍：「凌晨3點發動攻擊」

B軍收到了，讓B通訊兵攜帶另外一個秘鑰b，以及a+1，回覆A軍：「我收到了」

A軍又讓A通訊兵攜帶a+1和b+1，告訴B軍：「我知道你收到了」

可以看到，這個方案並沒有解決兩軍問題。只是通過了攜帶秘鑰來增加了敵軍截獲資訊的難度。

那為什麼是三次握手？而不是2次，4次，5次呢？

成本問題。三次握手是最經濟的，就這麼簡單！

作為985院校計算機專業的本碩畢業生來為大家介紹下這個來自《計算機網路》課程的知識。

首先要明確，TCP通訊的建立過程需要三次握手，斷開過程需要四次揮手。

請求發起者（比如瀏覽器）傳送syn包（其中seq欄位為x）給後端伺服器，並進入syn_send狀態，等待伺服器確認。

伺服器受到syn包，回覆確認收到了這次請求，於是傳送了一個ack=x+1表示是收到剛剛的syn包，包裡還有一個seq=y的欄位，此時伺服器就進入了syn_recv的狀態

請求發起者收到了伺服器的響應，向伺服器再次傳送確認一個ack=y+1的包，當這個包傳送完畢後，雙方就都進入了established的狀態，完成了三次握手。

在這三次握手僅僅是為了建立連線，期間是不會傳輸使用者的實際資料的，只有在連線建立之後，才會真正開始傳送使用者的資料。在不考慮網路抖動的影響下，TCP一旦建立，只要雙方不發起關閉請求，這個TCP連線會一直保持。

也許你會好奇，為什麼要花費這麼大力氣來進行三次握手呢，兩次握手不可以嗎？

當然不可以。

假設A傳送了訊息給B，但是由於網路抖動，這個訊息阻塞直到A認為超時，然後重新發送了訊息。而當A和B通訊結束後，這個超時的訊息才姍姍來遲到達了B，對於B而言，這是一個全新的建立連線的請求，就會像A發起上述的第二次握手，但是對於A來說，它不認可這個握手，於是如果是兩次握手，那此時B就會認為連線已經建立，照我們上面所說，會一直保持這個連線，導致了資源的浪費。

通訊中，為了確保，對端接收到資訊，就需要發端發request，並收到接收端的response。所以，A，B兩端各需要2次。A，B如果併發握手，那就總共需要4次。而如果串序，B端把它的request，嵌入了A端收到的response中，如此，節約了一次握手，是為3次

TCP通訊前需要建立連線，英文為“Three-Way Handshake”，直譯為“三向的握手”，意譯為“三次訊息互動的握手”。這裡的“三”不是“三次握手”，而是“三次訊息”。但是不知道是誰發明創造了“TCP三次握手”，在中文網際網路上叫“TCP三次握手”越來越多，眾口鑠金，“三次訊息互動的握手”反而沒有多少人知曉。

Three-Way Handshake

TCP建立連線，需要三次訊息互動。只有成功完成了三次訊息互動，雙方才能在TCP連線上運輸位元組資料（Byte Stream）。

既然在建立連線期間，不能運輸資料，那麼運輸的什麼呢？

控制訊號

與建立連線有關的只有兩種控制訊號。

Synchronization (縮寫為SYN)

Acknowledge (縮寫為ACK)

每一個控制訊號只佔據一個二進位制位，要麼為“0”、要麼為“1”。

Synchronization是幹嘛的？

同步訊號，或者建立連線的意思。

Acknowledge是幹嘛的？

用於確認收到對方的SYN同步（建立連線的意圖）訊號。一旦收到對方的“SYN”訊號，如果同意建立連線，必須要“ACK”對方。

第一次訊息互動

Alice主動與Bob建立連線，“SYN”訊號 = 1。

第二次訊息互動

Bob同意建立連線，發“ACK”訊號 = 1，用於確認Alice的建立連線請求。

問題來了，如果Bob只發“ACK”訊號 = 1而沒有其它，其實只是同意Alice可以單向發資料給Bob，而Bob卻不可以發資料給Alice！

如果Bob也要發資料給Alice，Bob需要像Alice那樣發“SYN”訊號 = 1，就有了第三次訊息互動。

第三次訊息互動

Bob被動與Alice建立連線，“SYN”訊號 = 1。

第四次訊息互動

Alice發“ACK”訊號 = 1，用於確認Bob的建立連線請求。

咦，怎麼變成了四次訊息互動，不是說好的三次嗎？

大家仔細瞅瞅，第二個訊息與第三個訊息都是由Bob一前一後發出的，為什麼不能把這兩個訊號放在一個訊息報文裡發出去呢？它們都有自己獨立的訊號位，又不衝突，何樂而不為呢？

最終的TCP協議標準將這兩個報文合二為一，就有了三次訊息互動。

第一次訊息互動

Alice發“SYN”= 1。

第二次訊息互動

Bob發“SYN”= 1, “ACK”= 1。

第三次訊息互動

Alice發“ACK”= 1。