計算機網路三次握手的標志位

⑴ tcp協議的三次握手

三次握手-簡介所謂的「三握手」：對每次發送的數據量是怎樣跟蹤進行協商使數據段的發送和接收同步，根據所接收到的數據 量而確定的數據確認數及數據發送、接收完畢後何時撤消聯系，並建立虛連接。為了提供可靠的傳送，TCP 在發送新的數據之前，以特定的順序將數據包的序號，並需要這些包傳送給目標機之後的確認消息。TCP 總是用來發送大批量的數據。當應用程序在收到數據後要做出確認時也要用到TCP。 TCP握手協議 在TCP/IP協議中，TCP協議提供可靠的連接服務，採用三次握手建立一個連接。 第一次握手：建立連接時，客戶端發送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認； 第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態； 三次握手協議 第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。 完成三次握手，客戶端與伺服器開始傳送數據，在上述過程中，還有一些重要的概念： 未連接隊列：在三次握手協議中，伺服器維護一個未連接隊列，該隊列為每個客戶端的SYN包（syn=j）開設一個條目，該條目表明伺服器已收到SYN包，並向客戶發出確認，正在等待客戶的確認包。這些條目所標識的連接在伺服器處於Syn_RECV狀態，當伺服器收到客戶的確認包時，刪除該條目，伺服器進入ESTABLISHED狀態。 Backlog參數：表示未連接隊列的最大容納數目。 SYN-ACK 重傳次數 伺服器發送完SYN－ACK包，如果未收到客戶確認包，伺服器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數超過系統規定的最大重傳次數，系統將該連接信息從半連接隊列中刪除。注意，每次重傳等待的時間不一定相同。 半連接存活時間：是指半連接隊列的條目存活的最長時間，也即服務從收到SYN包到確認這個報文無效的最長時間，該時間值是所有重傳請求包的最長等待時間總和。有時我們也稱半連接存活時間為Timeout時間、SYN_RECV存活時間。 [1] * SYN：同步標志 同步序列編號(Synchronize Sequence Numbers)欄有效。該標志僅在三次握手建立TCP連接時有效。它提示TCP連接的服務端檢查序列編號，該序列編號為TCP連接初始端(一般是客戶端)的初始序列編號。在這里，可以把TCP序列編號看作是一個范圍從0到4，294，967，295的32位計數器。通過TCP連接交換的數據中每一個位元組都經過序列編號。在TCP報頭中的序列編號欄包括了TCP分段中第一個位元組的序列編號。 *ACK：確認標志 確認編號(Acknowledgement Number)欄有效。大多數情況下該標志位是置位的。TCP報頭內的確認編號欄內包含的確認編號(w+1，Figure-1)為下一個預期的序列編號，同時提示遠端系統已經成功接收所有數據。 *RST：復位標志 復位標志有效。用於復位相應的TCP連接。 *URG：緊急標志 緊急(The urgent pointer) 標志有效。緊急標志置位， *PSH：推標志 該標志置位時，接收端不將該數據進行隊列處理，而是盡可能快將數據轉由應用處理。在處理 telnet 或 rlogin 等交互模式的連接時，該標志總是置位的。 *FIN：結束標志 帶有該標志置位的數據包用來結束一個TCP回話，但對應埠仍處於開放狀態，准備接收後續數據。 [編輯本段]三次握手協議-工作原理 由於TCP 需要時刻跟蹤，這需要額外開銷，使得TCP 的格式有些顯得復雜。下面就讓我們看一個TCP 的 三次握手協議 經典案例，這是後來被稱為MITNICK 攻擊中KEVIN 開創了兩種攻擊技術： TCP 會話劫持和SYN FLOOD（同步洪流） 在這里我們討論的是TCP 會話劫持的問題。 先讓我們明白TCP 建立連接的基本簡單的過程。為了建設一個小型的模仿環境我們假設有3 台接入互聯網的機器。A 為攻擊者操縱的攻擊機。B 為中介跳板機器（受信任的伺服器）。C 為受害者使用的機器（多是伺服器），這里把C 機器鎖定為目標機器。A 機器向B機器發送SYN 包，請求建立連接，這時已經響應請求的B 機器會向A 機器回應SYN/ACK表明同意建立連接，當A 機器接受到B 機器發送的SYN/ACK 回應時，發送應答ACK 建立 A 機器與B 機器的網路連接。這樣一個兩台機器之間的TCP 通話信道就建立成功了。B 終端受信任的伺服器向C 機器發起TCP 連接，A 機器對伺服器發起SYN 信息，使C 機器不能響應B 機器。在同時A 機器也向B 機器發送虛假的C 機器回應的SYN 數據包，接收到SYN 數據包的B 機器（被C 機器信任）開始發送應答連接建立的SYN/ACK 數據包，這時C 機器正在忙於響應以前發送的SYN 數據而無暇回應B 機器，而A 機器的攻擊者預測出B 機器包的序列號（現在的TCP 序列號預測難度有所加大）假冒C 機器向B 機器發送應答ACK 這時攻擊者騙取B 機器的信任，假冒C 機器與B 機器建立起TCP 協議的對話連接。這個時候的C 機器還是在響應攻擊者A 機器發送的SYN 數據。 TCP 協議棧的弱點：TCP 連接的資源消耗，其中包括：數據包信息、條件狀態、序列號等。通過故意不完成建立連接所需要的三次握手過程，造成連接一方的資源耗盡。通過攻擊者有意的不完成建立連接所需要的三次握手的全過程，從而造成了C 機器的資源耗盡。序列號的可預測性，目標主機應答連接請求時返回的SYN/ACK 的序列號是可預測的。

⑵ 計算機網路——TCP三次握手四次揮手

用戶進程和伺服器進程需要完成一次通信都需要完成 三個階段 ： 連接建立、數據傳送、連接釋放

參考：三次握手和四次揮手

首先先明確幾個概念：

序列號seq（4B） ：用來標記數據段的順序，TCP把連接中發送的所有數據位元組都編上一個序號，第一個位元組的編號由本地隨機產生，給位元組編上序號後，就給每一個報文段指派一個序號， 序列號seq就是這個報文段中的第一個位元組的數據編號 。

確認號ack（4B） ： 期待收到對方下一個報文段的第一個數據位元組的序號 ，序列號表示報文段攜帶數據的第一個位元組的編號，而確認號指的是期望接受到下一個位元組的編號，因此擋牆報文段最後一個位元組的編號+1即是確認號。

確認ACK（1bit） ：僅當ACK=1，確認號欄位才有效。ACK=0，確認號無效。

同步SYN ： 連接建立時 用於同步序號。SYN=1表示這是一個連接請求，或連接接收報文，SYN這個標志位只有在TCP建立連接才會被置為1，握手完成後SYN標志位被置為0.當SYN=1，ACK=0表示：這是一個連接請求報文段。若同意連接，則在響應報文段中使用SYN=1，ACK=1

終止FIN ：用來釋放一個連接。

B的TCP伺服器進程先創建傳輸控制塊TCB，准備接受客戶進程的連接請求。然後伺服器進程就處於LISTEN（收聽）狀態，等待客戶的連接請求。若有，則作出響應。

1）第一次握手：A首先向B發一個SYN (Synchronize) 標記的包，告訴B請求建立連接，一個 SYN包就是僅SYN標記設為1的TCP包(參見TCP包頭Resources)， SYN=1的報文段不能攜帶數據 ，但要 消耗掉一個序號， 此時TCP客戶進程進入SYN-SENT（同步已發送）狀態。

2）第二次握手：B收到後會發一個對SYN包的確認包(SYN/ACK)回去，表示對第一個SYN包的確認，並繼續握手操作.注意: SYN/ACK包是僅SYN 和 ACK 標記為1的包。在確認報文段中，測試TCP伺服器進程進入SYN-RCVD（同步收到）狀態；

3）第三次握手：TCP客戶進程收到B的確認後，要向B給出確認報文段，ACK報文段可以攜帶數據，不攜帶數據則不消耗序號。TCP連接已經建立，A進入ESTABLISHED（已建立連接）。

當B收到A的確認後，也進入建立連接狀態。

序列號和確認號的關系：

第一次握手序列號seq=x；

第二次握手序列號seq=y，確認號ack=x+1；

第三次握手序列號seq=x+1，確認號ack=y+1；

序列號seq是上一次的確認號，而確認號是上一次的序列號+1;這是因為SYN=1的報文段不能攜帶數據，但要消耗掉一個序號，所以下一個報文段要+1；

為了防止已經失效的連接請求報文段突然又傳到服務端，因而產生錯誤」，這種情況是：一端(client)A發出去的第一個連接請求報文並沒有丟失，而是因為某些未知的原因在某個網路節點上發生滯留，導致延遲到連接釋放以後的某個時間才到達另一端(server)B。本來這是一個早已失效的報文段，但是B收到此失效的報文之後，會誤認為是A再次發出的一個新的連接請求，於是B端就向A又發出確認報文，表示同意建立連接。如果不採用「三次握手」，那麼只要B端發出確認報文就會認為新的連接已經建立了，但是A端並沒有發出建立連接的請求，因此不會去向B端發送數據，B端沒有收到數據就會一直等待，這樣B端就會白白浪費掉很多資源。如果採用「三次握手」的話就不會出現這種情況，B端收到一個過時失效的報文段之後，向A端發出確認，此時A並沒有要求建立連接，所以就不會向B端發送確認，這個時候B端也能夠知道連接沒有建立。（知乎上對上面的解釋的評論：這個解答不是問題的本質，這個課本很多知識比較片面。問題的核心在於保證信道數據傳輸的可靠性，避免資源浪費僅僅是一個小的弱原因，不重要。） 

從客戶端到服務端釋放連接的過程中，需要四次報文傳輸。

TCP四次揮手過程

1）A的應用進程先向其TCP發出連接釋放報文段（FIN=1，序號seq=u），並停止再發送數據，主動關閉TCP連接，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。

2）B收到連接釋放報文段後即發出確認報文段，（ACK=1，確認號ack=u+1，序號seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處於半關閉狀態，A到B的連接釋放。

3）A收到B的確認後，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連接釋放報文段。

4）B沒有要向A發出的數據，B發出連接釋放報文段（FIN=1，ACK=1，序號seq=w，確認號ack=u+1），B進入LAST-ACK（最後確認）狀態，等待A的確認。

5）A收到B的連接釋放報文段後，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態。此時TCP未釋放掉，需要經過時間等待計時器設置的時間2MSL後，A才進入CLOSED狀態。

大概就是A和B：

A：「我不和你說話了」

B：「知道了」

此時A單方面不和B說話，當B也沒有話對A說的時候

B：「我也不和你說話了」

A：「好的」

兩個人互相不說話了

TCP四次揮手總結

客戶端發送FIN後，進入終止等待狀態，伺服器收到客戶端連接釋放報文段後，就立即給客戶端發送確認，伺服器就進入CLOSE_WAIT狀態，此時TCP伺服器進程就通知高層應用進程，因而從客戶端到伺服器的連接就釋放了。此時是「半關閉狀態」，即客戶端不可以發送給伺服器，伺服器可以發送給客戶端。

此時，如果伺服器沒有數據報發送給客戶端，其應用程序就通知TCP釋放連接，然後發送給客戶端連接釋放數據報，並等待確認。客戶端發送確認後，進入TIME_WAIT狀態，但是此時TCP連接還沒有釋放，然後經過等待計時器設置的2MSL後，才進入到CLOSE狀態。

⑶ 計算機網路中的「三次握手」是什麼

TCP握手協議

在TCP/IP協議中，TCP協議提供可靠的連接服務，採用三次握手建立一個連接。

第一次握手：建立連接時，客戶端發送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
SYN：同步序列編號(SynchronizeSequenceNumbers)
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；

第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。

完成三次握手，客戶端與伺服器開始傳送數據，在上述過程中，還有一些重要的概念：

未連接隊列：在三次握手協議中，伺服器維護一個未連接隊列，該隊列為每個客戶端的SYN包（syn=j）開設一個條目，該條目表明伺服器已收到SYN包，並向客戶發出確認，正在等待客戶的確認包。這些條目所標識的連接在伺服器處於Syn_RECV狀態，當伺服器收到客戶的確認包時，刪除該條目，伺服器進入ESTABLISHED狀態。
Backlog參數：表示未連接隊列的最大容納數目。

SYN-ACK重傳次數伺服器發送完SYN－ACK包，如果未收到客戶確認包，伺服器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數超過系統規定的最大重傳次數，系統將該連接信息從半連接隊列中刪除。注意，每次重傳等待的時間不一定相同。

半連接存活時間：是指半連接隊列的條目存活的最長時間，也即服務從收到SYN包到確認這個報文無效的最長時間，該時間值是所有重傳請求包的最長等待時間總和。有時我們也稱半連接存活時間為Timeout時間、SYN_RECV存活時間。

⑷ TCP三次握手與四次揮手

為了更好的理解TCP建立連接與釋放連接的過程，我們不妨先了解TCP報文結構。

TCP報文包含 首部 和 數據部分 ：

重點認識一下 TCP首部 結構：

1、源埠與目的埠：
各占兩個位元組，共4個位元組。用來告知主機該報文的源與目的。

2、序號（seq number）
由於TCP是面向流的有序可靠連接，在一個TCP連接中傳輸的位元組流中的每個位元組都需要按順序編號。

序號欄位指的是本報文段所發送的數據的 第一個位元組 的序號。

3、確認號（ack number）
表示 期望收到對方下一個報文段的序號值 ，同時表示前面的序號值都已經 成功接收 ，體現 累積確認機制 。

4、確認ACK
當ACK=1時，確認號有效。

5、同步SYN
當SYN=1時，表明這是一個請求連接報文段。

6、終止FIN
當FIN=1時，表示此報文段的發送方的數據已發送完畢，要求釋放TCP連接。

7、 窗口大小（window size）
流量控制 中的滑動窗口大小，根據接收方的接收緩沖區剩餘大小設置。

TCP 的整個交流過程可以總結為：建立連接，傳輸數據，釋放連接。

TCP連接的建立採用客戶端-伺服器模式，我們將主動方成為客戶端（Client），被動方成為伺服器（Server）。

1、 第一次握手 ：Client主動打開連接，發送TCP報文（ SYN = 1，seq = i ），進行第一次握手，進入 SYN_SEND 狀態；

2、 第二次握手 ： Server收到了SYN報文，發送返回報文（ ACK = 1，SYN = 1，ack = i+1， seq = j ），進行第二次握手，進入 SYN_RCVD 狀態；

3、 第三次握手 ： Client收到來自Server的報文，返回ACK報文（ ACK = 1， ack = j+1，seq = i+1 ），進行第三次握手，進入 ESTABLISHED 狀態； 另外， 第三次握手一般已經可以攜帶數據了 。

TCP有一個特別的概念叫做 半關閉 ，這個概念是說，TCP連接時全雙工的連接，因此在關閉連接的時候，必須關閉傳送和接收兩個方向上的連接。

1、 第一次揮手 ： Client發送關閉連接報文段（ FIN= 1， seq = n ），進入 FIN_WAIT_1 狀態；

2、 第二次揮手 ： Server收到來自Client的FIN之後，立即返回一個 ACK=1 報文段（ack = n+1），進入 CLOSE_WAIT 狀態；
此時Server還是可以發送數據給Client。

3、 第三次揮手 ： 當Server確定所有數據都發送完畢之後，發送 FIN=1 報文段（seq = m），進入 LAST_ACK 狀態；

4、 第四次揮手 ： Client收到之後，返回 ACK=1 報文段（ack = m+1），進入 TIME_WAIT 狀態；
Client等待2MSL（MSL，最長報文段壽命）之後進入CLOSED狀態，Server收到最後一個ACK之後，也進入CLOSED狀態。

在三次握手過程中，Server發送第二次握手報文之後，收到Client的ACk之前的狀態稱為 半連接 狀態。在半連接狀態的Server會為其認為即將完成連接的Client分配資源。

而SYN Flood攻擊就是，在短時間內偽造大量不存在的IP地址，向Server不斷發送SYN包，Server為這些偽造的Client分配資源，並返回SYN+ACK報文段，由於IP地址無效，所以Server不會收到第三次握手的ACK，需要不斷發送直至超時，這些偽造的Client長時間佔用未連接隊列與Server預分配的資源，造成Server崩潰，無法響應正常的SYN包。

1、SYN cookies技術：先不分配數據區，而根據SYN計算一個cookies值，當收到Client的ACk之後，再進行對比，分配資源。

2、增大最大半連接和縮短超時時間。

1、TIME_WAIT狀態能確保Server正常進入CLOSE狀態：
TIME_WAIT狀態是在Client發完最後一個ACK之後進入的狀態，如果這個ACK丟失，則Server不能確認進入CLOSE狀態，超時後，Server會重新發送FIN報文段，此時處於TIME_WAIT狀態的Client就能收到FIN，重發ACK，確保四次揮手完成。

2、TIME_WAIT狀態有 凈空 的效果：
防止已經失效的連接請求出現在下次連接中。經過TIME_WAIT狀態，可以使本連接內的所有請求都在網路中消失（從而起到凈空的效果，不會贏下下一次連接）。

1、 只有主動close一方才會出現TIME_WAIT狀態，只有TCP連接為 短連接 情況下才有可能出現大齡的TIME_WAIT狀態。

2、 伺服器使用短連接，每次客戶端請求後，伺服器都會主動發送FIN關閉連接。最後進入TIME_WAIT狀態。由此，如果訪問量過大的Web Server，會存在大量的TIME_WAIT狀態。
可以通過修改內核參數，快速回收TIME_WAIT資源。

3、如果一直存在大量TIME_WAIT狀態，回收不及時的話，會佔用大量伺服器資源，可能造成該無法提供服務的問題。

【參考】
[1] 理解TCP 和 UDP
[2] 《計算機網路》

⑸ 簡述TCP協議的三次握手過程，以及序列號和確認號的作用

（1）第一次握手：Client將標志位SYN置為1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
（2）第二次握手：Server收到數據包後由標志位SYN=1知道Client請求建立連接，Server將標志位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認連接請求，Server進入SYN_RCVD狀態。
（3）第三次握手：Client收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸數據了。

TCP會話的每一端都包含一個32位（bit）的序列號，該序列號被用來跟蹤該端發送的數據量。每一個包中都包含序列號，在接收端則通過確認號用來通知發送端數據成功接收

⑹ 計算機三級網路技術關於Tcp三次握手的問題。標志著握手成功的到底是哪一行，如下圖，圖一答案給的是8

個人感覺是7，第三次握手就發送了握手完成的標號

⑺ 正常的TCP連接建立過程是一個所謂「三次握手」過程

在第一步中，客戶端向服務端提出連接請求。這時TCPSYN標志置位。客戶端告訴服務端序列號區域合法，需要檢查。客戶端在TCP報頭的序列號區中插入自己的ISN。服務端收到該TCP分段。

在第二步以自己的ISN回應(SYN標志置位)，同時確認收到客戶端的第一個TCP分段(ACK標志置位)。在第三步中，客戶端確認收到服務端的ISN(ACK標志置位)。到此為止建立完整的TCP連接，開始全雙工模式的數據傳輸過程。

⑻ 動畫圖解TCP三次握手

TCP 三次握手過程不管是對於本科計算機網路學習還是考研考計網的同學來說都是必考的一個，所以要掌握 TCP 整個握手的過程顯得尤為重要。

一、TCP 是什麼？

TCP是Transmission Control Protocol(傳輸控制協議) 的簡稱，它提供一種面向連接的、可靠的、基於位元組流的傳輸層通信協議。

在學習 TCP 握手過程之前，我們首先要了解 TCP 報文頭部的一些標志信息，因為在 TCP 握手的過程中，要用到TCP報文頭部的一些信息。

TCP頭部

1.1 源埠和目的埠

對於埠，我們可以這么理解：我們可以想像發送方很多的窗戶，接收方也有很多的窗戶，這些窗口都標有不同的埠號，源埠號和目的埠號就分別代表從哪個規定的串口發送到對方接收的窗口。不同的應用程序都有著不同的埠，比如HTTP埠80，SMTP埠25等。

1.2 序號

TCP是面向位元組流的，在一個TCP連接中傳送的位元組流中的每一個位元組都按順序編號。接收端根據這個編號進行確認，保證分割的數據段在原始數據包的位置。

通俗一點的講，每個欄位在傳送中用序列號來標記自己位置的，而這個欄位就是用來完成雙方傳輸中確保欄位原始位置是按照傳輸順序的。（發送方是數據是怎樣一個順序，到了接受方也要確保是這個順序）

1.3 確認號

確認號是期望收到對方下一個報文段的第一個位元組的序號。確認號 = N,則表示到序號N-1為止的所有數據都已經正確收到。例如：B正確收到了A發送過來的一個報文段，其序號欄位值為500，而數據欄位長度是200位元組(序號501~700)，這表明B正確收到了A發送的到序號700為止的數據，因此B期望收到A的下一個數據序號是701，於是B在發送給A的確認報文段中把確認號置為701。

1.4 標志位

TCP首部中有 6 個標志比特，它們中的多個可同時被設置為 1，主要是用於操控 TCP 的狀態機的，依次為URG，ACK，PSH，RST，SYN，FIN。今天我們只介紹我們用到的三個。

1.4.1 確認ACK

這個標志位可以理解為發送端發送數據到接收端，發送的時候 ACK置 為 0，一旦接收端接收數據之後，就將 ACK 置為 1，發送端接收到之後，就知道了接收端已經接收了數據。需要注意的一點是：當且僅當ACK = 1時，確認號欄位才有效。TCP規定，在連接建立後，所有傳送的報文段 都將ACK置為1。

1.4.2 同步SYN

SYN是同步序列號，在建立TCP連接時用來同步序號。當SYN=1，ACK=0時，表明這是一個連接請求報文段。若對方同意建立連接，則應在響應的報文段中使SYN=1，ACK=1。因此，SYN置為1就表示這是一個連接請求或連接接受報文。

1.4.3 終止FIN

當發送端已經達到數據末尾，也就是說雙方的數據傳送完成，沒有數據可以傳送了，發送方FIN標志位置為1後，表示此報文段的發送方數據發送完畢，請求釋放連接。

二 T CP三次握手過程

TCP 三次握手的過程解決以下三個問題

1.要是每一方都能確知對方的存在

2.要允許雙方協商一些參數(如窗口最大值，是否使用窗口擴大選項以及時間戳選項等)

3.能夠對運輸實體資源(如緩沖大小、連接表中的項目等)進行分配

掌握了這些，TCP 的三次握手就簡單多了。下面我們就以動畫形式進行拆解三次握手過程。

初始狀態 ：客戶端處於closed(關閉)狀態，伺服器處於listen(監聽)狀態

第一次握手 ：客戶端發送請求報文將SYN = 1同步序列號和初始化序列號seq = x發送給服務端，發送完之後客戶端處於SYN_Send狀態。

第二次握手 ：服務端受到SYN請求報文之後，如果同意連接，會以自己的同步序列號SYN(服務端) = 1、初始化序列號seq = y和確認序列號（期望下次收到的數據包）ack = x+ 1以及確認號ACK = 1報文作為應答，伺服器為SYN_Receive狀態。

第三次握手 ： 客戶端接收到服務端的SYN + ACK之後，知道可以下次可以發送了下一序列的數據包了，然後發送同步序列號ack = y + 1和數據包的序列號seq = x + 1以及確認號ACK = 1確認包作為應答，客戶端轉為established狀態。

三、為什麼不能是一次、二次握手，而必須是三次握手？

為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。

所謂「已失效的連接請求報文段」是這樣產生的。考慮一種正常情況：A發出連接請求，但因連接請求報文丟失而未收到確認。於是A在重傳一次連接請求，後來收到了確認，建立了連接。數據傳輸完畢後，就釋放了連接。在此過程中，A一共發送了兩個連接請求報文段，其中一個丟失，第二個到達了B。沒有已經失效的報文段。

但現在出現一種異常情況，即A發出的第一個連接請求報文段並沒有丟失，而是在某些網路結點長時間滯留了，以至延誤到連接釋放以後的某個時間才到達B。本來這是一個早已經失效的報文段，但B收到此失效的連接請求報文段後，就誤認為是A又發出一次新的連接請求。於是就向A發出確認報文段，同意建立連接。假定不採用三次握手，那麼只要B發出確認，新的連接就建立了。

由於現在A並沒有發出建立連接的請求，因此不會理睬B的確認，也不會向B發送數據，但B卻以為新的運輸連接已經建立了，並一直等待A發來數據。B的許多資源就這樣白白浪費了。

採用三次握手的辦法可以防止上述現象的發生，例如在剛才的情況下，A不會向B的確認發出確認。B由於收不到確認，就知道A並沒有要求建立連接。