1. 程式人生 > 其它 >TCP和IP的三次握手和第四次揮手

TCP和IP的三次握手和第四次揮手

TCP握手協議

TCP/IP協議中,TCP協議提供可靠的連線服務,採用三次握手建立一個連線.
第一次握手:建立連線時,客戶端傳送syn包(syn=j)到伺服器,並進入SYN_SEND狀態,等待伺服器確認;
SYN:同步序列編號(Synchronize Sequence Numbers)
第二次握手:伺服器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也傳送一個SYN包(syn=k),即SYN+ACK包,此時伺服器進入SYN_RECV狀態;
第三次握手:客戶端收到伺服器的SYN+ACK包,向伺服器傳送確認包ACK(ack=k+1),此包傳送完畢,客戶端和伺服器進入ESTABLISHED狀態,完成三次握手.

完成三次握手,客戶端與伺服器開始傳送資料

 

 

A與B建立TCP連線時:首先A向B發SYN(同步請求),然後B回覆SYN+ACK(同步請求應答),最後A回覆ACK確認,這樣TCP的一次連線(三次握手)的過程就建立了!

 

 

 

 

一、TCP報文格式

        TCP/IP協議的詳細資訊參看《TCP/IP協議詳解》三卷本。下面是TCP報文格式圖:


圖1 TCP報文格式

        上圖中有幾個欄位需要重點介紹下:
        (1)序號:Seq序號,佔32位,用來標識從TCP源端向目的端傳送的位元組流,發起方傳送資料時對此進行標記。
        (2)確認序號:Ack序號,佔32位,只有ACK標誌位為1時,確認序號欄位才有效,Ack=Seq+1。
        (3)標誌位:共6個,即URG、ACK、PSH、RST、SYN、FIN等,具體含義如下:
                (A)URG:緊急指標(urgent pointer)有效。
                (B)ACK:確認序號有效。
                (C)PSH:接收方應該儘快將這個報文交給應用層。
                (D)RST:重置連線。
                (E)SYN:發起一個新連線。
                (F)FIN:釋放一個連線。

        需要注意的是:
                (A)不要將確認序號Ack與標誌位中的ACK搞混了。
                (B)確認方Ack=發起方Req+1,兩端配對。 

二、三次握手
        所謂三次握手(Three-Way Handshake)即建立TCP連線,就是指建立一個TCP連線時,需要客戶端和服務端總共傳送3個包以確認連線的建立。在socket程式設計中,這一過程由客戶端執行connect來觸發,整個流程如下圖所示:


圖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之間可以開始傳輸資料了。
        
        SYN攻擊:
                在三次握手過程中,Server傳送SYN-ACK之後,收到Client的ACK之前的TCP連線稱為半連線(half-open connect),此時Server處於SYN_RCVD狀態,當收到ACK後,Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址,並向Server不斷地傳送SYN包,Server回覆確認包,並等待Client的確認,由於源地址是不存在的,因此,Server需要不斷重發直至超時,這些偽造的SYN包將產時間佔用未連線佇列,導致正常的SYN請求因為佇列滿而被丟棄,從而引起網路堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊,檢測SYN攻擊的方式非常簡單,即當Server上有大量半連線狀態且源IP地址是隨機的,則可以斷定遭到SYN攻擊了,使用如下命令可以讓之現行:
                #netstat -nap | grep SYN_RECV

三、四次揮手
         三次握手耳熟能詳,四次揮手估計就,所謂四次揮手(Four-Way Wavehand)即終止TCP連線,就是指斷開一個TCP連線時,需要客戶端和服務端總共傳送4個包以確認連線的斷開。在socket程式設計中,這一過程由客戶端或服務端任一方執行close來觸發,整個流程如下圖所示:


圖3 TCP四次揮手

        由於TCP連線時全雙工的,因此,每個方向都必須要單獨進行關閉,這一原則是當一方完成資料傳送任務後,傳送一個FIN來終止這一方向的連線,收到一個FIN只是意味著這一方向上沒有資料流動了,即不會再收到資料了,但是在這個TCP連線上仍然能夠傳送資料,直到這一方向也傳送了FIN。首先進行關閉的一方將執行主動關閉,而另一方則執行被動關閉,上圖描述的即是如此。
        (1)第一次揮手:Client傳送一個FIN,用來關閉Client到Server的資料傳送,Client進入FIN_WAIT_1狀態。
        (2)第二次揮手:Server收到FIN後,傳送一個ACK給Client,確認序號為收到序號+1(與SYN相同,一個FIN佔用一個序號),Server進入CLOSE_WAIT狀態。
        (3)第三次揮手:Server傳送一個FIN,用來關閉Server到Client的資料傳送,Server進入LAST_ACK狀態。
        (4)第四次揮手:Client收到FIN後,Client進入TIME_WAIT狀態,接著傳送一個ACK給Server,確認序號為收到序號+1,Server進入CLOSED狀態,完成四次揮手。
        上面是一方主動關閉,另一方被動關閉的情況,實際中還會出現同時發起主動關閉的情況,具體流程如下圖:


圖4 同時揮手
        流程和狀態在上圖中已經很明瞭了,在此不再贅述,可以參考前面的四次揮手解析步驟。

四、附註
        關於三次握手與四次揮手通常都會有典型的面試題,在此提出供有需求的XDJM們參考:
        (1)三次握手是什麼或者流程?四次握手呢?答案前面分析就是。
        (2)為什麼建立連線是三次握手,而關閉連線卻是四次揮手呢?
        這是因為服務端在LISTEN狀態下,收到建立連線請求的SYN報文後,把ACK和SYN放在一個報文裡傳送給客戶端。而關閉連線時,當收到對方的FIN報文時,僅僅表示對方不再發送資料了但是還能接收資料,己方也未必全部資料都發送給對方了,所以己方可以立即close,也可以傳送一些資料給對方後,再發送FIN報文給對方來表示同意現在關閉連線,因此,己方ACK和FIN一般都會分開發送    

複雜點說

TCP(Transmission Control Protocol) 傳輸控制協議

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

位碼即tcp標誌位,

有6種標示:

SYN(synchronous建立聯機)

ACK(acknowledgement 確認)

PSH(push傳送)

FIN(finish結束)

RST(reset重置)

URG(urgent緊急)

Sequence number(順序號碼)

Acknowledge number(確認號碼)

第一次握手:主機A傳送位碼為syn=1,隨機產生seq number=1234567的資料包到伺服器,主機B由SYN=1知道,A要求建立聯機;

第二次握手:主機B收到請求後要確認聯機資訊,向A傳送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包

第三次握手:主機A收到後檢查ack number是否正確,即第一次傳送的seq number+1,以及位碼ack是否為1,若正確,主機A會再發送ack number=(主機B的seq+1),ack=1,主機B收到後確認seq值與ack=1則連線建立成功。

完成三次握手,主機A與主機B開始傳送資料。

在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狀態,完成三次握手。 完成三次握手,客戶端與伺服器開始傳送資料.

   

例項:

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連線是全雙工的,因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線。收到一個 FIN只意味著這一方向上沒有資料流動,一個TCP連線在收到一個FIN後仍能傳送資料。首先進行關閉的一方將執行主動關閉,而另一方執行被動關閉。

(1)客戶端A傳送一個FIN,用來關閉客戶A到伺服器B的資料傳送(報文段4)。

(2)伺服器B收到這個FIN,它發回一個ACK,確認序號為收到的序號加1(報文段5)。和SYN一樣,一個FIN將佔用一個序號。

(3)伺服器B關閉與客戶端A的連線,傳送一個FIN給客戶端A(報文段6)。

(4)客戶端A發回ACK報文確認,並將確認序號設定為收到序號加1(報文段7)。

   

1.為什麼建立連線協議是三次握手,而關閉連線卻是四次握手呢?

這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後,它可以把ACK和SYN(ACK起應答作用,而SYN起同步作用)放在一個報文裡來發送。但關閉連線時,當收到對方的FIN報文通知時,它僅僅表示對方沒有資料傳送給你了;但未必你所有的資料都全部發送給對方了,所以你可以未必會馬上會關閉SOCKET,也即你可能還需要傳送一些資料給對方之後,再發送FIN報文給對方來表示你同意現在可以關閉連線了,所以它這裡的ACK報文和FIN報文多數情況下都是分開發送的。

2.為什麼TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態?

這是因為雖然雙方都同意關閉連線了,而且握手的4個報文也都協調和傳送完畢,按理可以直接回到CLOSED狀態(就好比從SYN_SEND狀態到ESTABLISH狀態那樣);但是因為我們必須要假想網路是不可靠的,你無法保證你最後傳送的ACK報文會一定被對方收到,因此對方處於LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文,而重發FIN報文,所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。

簡單點說:

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

第一次握手:建立連線時,客戶端傳送syn包(syn=j)到伺服器,並進入SYN_SEND狀態,等待伺服器確認;

SYN:同步序列編號(Synchronize Sequence Numbers)

第二次握手:伺服器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也傳送一個SYN包(syn=k),即SYN+ACK包,此時伺服器進入SYN_RECV狀態;

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

完成三次握手,客戶端與伺服器開始傳送資料

再簡單點說:

A與B建立TCP連線時:首先A向B發SYN(同步請求),然後B回覆SYN+ACK(同步請求應答),最後A回覆ACK確認,這樣TCP的一次連線(三次握手)的過程就建立了!



作者:Levan_li
連結:https://www.jianshu.com/p/092705233d37
來源:簡書
簡書著作權歸作者所有,任何形式的轉載都請聯絡作者獲得授權並註明出處。
TCP/IP協議中,TCP協議提供可靠的連線服務,採用三次握手建立一個連線.
第一次握手:建立連線時,客戶端傳送syn包(syn=j)到伺服器,並進入SYN_SEND狀態,等待伺服器確認;
SYN:同步序列編號(Synchronize Sequence Numbers)
第二次握手:伺服器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也傳送一個SYN包(syn=k),即SYN+ACK包,此時伺服器進入SYN_RECV狀態;
第三次握手:客戶端收到伺服器的SYN+ACK包,向伺服器傳送確認包ACK(ack=k+1),此包傳送完畢,客戶端和伺服器進入ESTABLISHED狀態,完成三次握手.

完成三次握手,客戶端與伺服器開始傳送資料

 

 

A與B建立TCP連線時:首先A向B發SYN(同步請求),然後B回覆SYN+ACK(同步請求應答),最後A回覆ACK確認,這樣TCP的一次連線(三次握手)的過程就建立了!

 

 

 

 

一、TCP報文格式

        TCP/IP協議的詳細資訊參看《TCP/IP協議詳解》三卷本。下面是TCP報文格式圖:


圖1 TCP報文格式

        上圖中有幾個欄位需要重點介紹下:
        (1)序號:Seq序號,佔32位,用來標識從TCP源端向目的端傳送的位元組流,發起方傳送資料時對此進行標記。
        (2)確認序號:Ack序號,佔32位,只有ACK標誌位為1時,確認序號欄位才有效,Ack=Seq+1。
        (3)標誌位:共6個,即URG、ACK、PSH、RST、SYN、FIN等,具體含義如下:
                (A)URG:緊急指標(urgent pointer)有效。
                (B)ACK:確認序號有效。
                (C)PSH:接收方應該儘快將這個報文交給應用層。
                (D)RST:重置連線。
                (E)SYN:發起一個新連線。
                (F)FIN:釋放一個連線。

        需要注意的是:
                (A)不要將確認序號Ack與標誌位中的ACK搞混了。
                (B)確認方Ack=發起方Req+1,兩端配對。 

二、三次握手
        所謂三次握手(Three-Way Handshake)即建立TCP連線,就是指建立一個TCP連線時,需要客戶端和服務端總共傳送3個包以確認連線的建立。在socket程式設計中,這一過程由客戶端執行connect來觸發,整個流程如下圖所示:


圖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之間可以開始傳輸資料了。
        
        SYN攻擊:
                在三次握手過程中,Server傳送SYN-ACK之後,收到Client的ACK之前的TCP連線稱為半連線(half-open connect),此時Server處於SYN_RCVD狀態,當收到ACK後,Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址,並向Server不斷地傳送SYN包,Server回覆確認包,並等待Client的確認,由於源地址是不存在的,因此,Server需要不斷重發直至超時,這些偽造的SYN包將產時間佔用未連線佇列,導致正常的SYN請求因為佇列滿而被丟棄,從而引起網路堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊,檢測SYN攻擊的方式非常簡單,即當Server上有大量半連線狀態且源IP地址是隨機的,則可以斷定遭到SYN攻擊了,使用如下命令可以讓之現行:
                #netstat -nap | grep SYN_RECV

三、四次揮手
         三次握手耳熟能詳,四次揮手估計就,所謂四次揮手(Four-Way Wavehand)即終止TCP連線,就是指斷開一個TCP連線時,需要客戶端和服務端總共傳送4個包以確認連線的斷開。在socket程式設計中,這一過程由客戶端或服務端任一方執行close來觸發,整個流程如下圖所示:


圖3 TCP四次揮手

        由於TCP連線時全雙工的,因此,每個方向都必須要單獨進行關閉,這一原則是當一方完成資料傳送任務後,傳送一個FIN來終止這一方向的連線,收到一個FIN只是意味著這一方向上沒有資料流動了,即不會再收到資料了,但是在這個TCP連線上仍然能夠傳送資料,直到這一方向也傳送了FIN。首先進行關閉的一方將執行主動關閉,而另一方則執行被動關閉,上圖描述的即是如此。
        (1)第一次揮手:Client傳送一個FIN,用來關閉Client到Server的資料傳送,Client進入FIN_WAIT_1狀態。
        (2)第二次揮手:Server收到FIN後,傳送一個ACK給Client,確認序號為收到序號+1(與SYN相同,一個FIN佔用一個序號),Server進入CLOSE_WAIT狀態。
        (3)第三次揮手:Server傳送一個FIN,用來關閉Server到Client的資料傳送,Server進入LAST_ACK狀態。
        (4)第四次揮手:Client收到FIN後,Client進入TIME_WAIT狀態,接著傳送一個ACK給Server,確認序號為收到序號+1,Server進入CLOSED狀態,完成四次揮手。
        上面是一方主動關閉,另一方被動關閉的情況,實際中還會出現同時發起主動關閉的情況,具體流程如下圖:


圖4 同時揮手
        流程和狀態在上圖中已經很明瞭了,在此不再贅述,可以參考前面的四次揮手解析步驟。

四、附註
        關於三次握手與四次揮手通常都會有典型的面試題,在此提出供有需求的XDJM們參考:
        (1)三次握手是什麼或者流程?四次握手呢?答案前面分析就是。
        (2)為什麼建立連線是三次握手,而關閉連線卻是四次揮手呢?
        這是因為服務端在LISTEN狀態下,收到建立連線請求的SYN報文後,把ACK和SYN放在一個報文裡傳送給客戶端。而關閉連線時,當收到對方的FIN報文時,僅僅表示對方不再發送資料了但是還能接收資料,己方也未必全部資料都發送給對方了,所以己方可以立即close,也可以傳送一些資料給對方後,再發送FIN報文給對方來表示同意現在關閉連線,因此,己方ACK和FIN一般都會分開發送    

複雜點說

TCP(Transmission Control Protocol) 傳輸控制協議

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

位碼即tcp標誌位,

有6種標示:

SYN(synchronous建立聯機)

ACK(acknowledgement 確認)

PSH(push傳送)

FIN(finish結束)

RST(reset重置)

URG(urgent緊急)

Sequence number(順序號碼)

Acknowledge number(確認號碼)

第一次握手:主機A傳送位碼為syn=1,隨機產生seq number=1234567的資料包到伺服器,主機B由SYN=1知道,A要求建立聯機;

第二次握手:主機B收到請求後要確認聯機資訊,向A傳送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包

第三次握手:主機A收到後檢查ack number是否正確,即第一次傳送的seq number+1,以及位碼ack是否為1,若正確,主機A會再發送ack number=(主機B的seq+1),ack=1,主機B收到後確認seq值與ack=1則連線建立成功。

完成三次握手,主機A與主機B開始傳送資料。

在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狀態,完成三次握手。 完成三次握手,客戶端與伺服器開始傳送資料.

   

例項:

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連線是全雙工的,因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線。收到一個 FIN只意味著這一方向上沒有資料流動,一個TCP連線在收到一個FIN後仍能傳送資料。首先進行關閉的一方將執行主動關閉,而另一方執行被動關閉。

(1)客戶端A傳送一個FIN,用來關閉客戶A到伺服器B的資料傳送(報文段4)。

(2)伺服器B收到這個FIN,它發回一個ACK,確認序號為收到的序號加1(報文段5)。和SYN一樣,一個FIN將佔用一個序號。

(3)伺服器B關閉與客戶端A的連線,傳送一個FIN給客戶端A(報文段6)。

(4)客戶端A發回ACK報文確認,並將確認序號設定為收到序號加1(報文段7)。

   

1.為什麼建立連線協議是三次握手,而關閉連線卻是四次握手呢?

這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後,它可以把ACK和SYN(ACK起應答作用,而SYN起同步作用)放在一個報文裡來發送。但關閉連線時,當收到對方的FIN報文通知時,它僅僅表示對方沒有資料傳送給你了;但未必你所有的資料都全部發送給對方了,所以你可以未必會馬上會關閉SOCKET,也即你可能還需要傳送一些資料給對方之後,再發送FIN報文給對方來表示你同意現在可以關閉連線了,所以它這裡的ACK報文和FIN報文多數情況下都是分開發送的。

2.為什麼TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態?

這是因為雖然雙方都同意關閉連線了,而且握手的4個報文也都協調和傳送完畢,按理可以直接回到CLOSED狀態(就好比從SYN_SEND狀態到ESTABLISH狀態那樣);但是因為我們必須要假想網路是不可靠的,你無法保證你最後傳送的ACK報文會一定被對方收到,因此對方處於LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文,而重發FIN報文,所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。

簡單點說:

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

第一次握手:建立連線時,客戶端傳送syn包(syn=j)到伺服器,並進入SYN_SEND狀態,等待伺服器確認;

SYN:同步序列編號(Synchronize Sequence Numbers)

第二次握手:伺服器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也傳送一個SYN包(syn=k),即SYN+ACK包,此時伺服器進入SYN_RECV狀態;

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

完成三次握手,客戶端與伺服器開始傳送資料

再簡單點說:

A與B建立TCP連線時:首先A向B發SYN(同步請求),然後B回覆SYN+ACK(同步請求應答),最後A回覆ACK確認,這樣TCP的一次連線(三次握手)的過程就建立了!



作者:Levan_li
連結:https://www.jianshu.com/p/092705233d37
來源:簡書
簡書著作權歸作者所有,任何形式的轉載都請聯絡作者獲得授權並註明出處。