兩張動圖--帶你搞懂TCP的三次握手與四次揮手

更新時間：2021年06月22日 14:35:54 作者：小書go

TCP是一種傳輸控制協(xié)議，是面向連接的、可靠的、基于字節(jié)流之間的傳輸層通信協(xié)議，由IETF的RFC 793定義。在簡化的計算機網(wǎng)絡OSI模型中，TCP完成第四層傳輸層所指定的功能

背景描述

通過上一篇中網(wǎng)絡模型中的IP層的介紹，我們知道網(wǎng)絡層，可以實現(xiàn)兩個主機之間的通信。但是這并不具體，因為，真正進行通信的實體是在主機中的進程，是一個主機中的一個進程與另外一個主機中的一個進程在交換數(shù)據(jù)。IP協(xié)議雖然能把數(shù)據(jù)報文送到目的主機，但是并沒有交付給主機的具體應用進程。而端到端的通信才應該是應用進程之間的通信。

UDP，在傳送數(shù)據(jù)前不需要先建立連接，遠地的主機在收到UDP報文后也不需要給出任何確認。雖然UDP不提供可靠交付，但是正是因為這樣，省去和很多的開銷，使得它的速度比較快，比如一些對實時性要求較高的服務，就常常使用的是UDP。對應的應用層的協(xié)議主要有 DNS,TFTP,DHCP,SNMP,NFS 等。

TCP，提供面向連接的服務，在傳送數(shù)據(jù)之前必須先建立連接，數(shù)據(jù)傳送完成后要釋放連接。因此TCP是一種可靠的的運輸服務，但是正因為這樣，不可避免的增加了許多的開銷，比如確認，流量控制等。對應的應用層的協(xié)議主要有 SMTP,TELNET,HTTP,FTP 等。

應用程序	FTP	TFTP	TELNET	SMTP	DNS	HTTP	SSH	MYSQL
熟知端口	21,20	69	23	25	53	80	22	3306
傳輸層協(xié)議	TCP	UDP	TCP	TCP	UDP	TCP	TCP	TCP

TCP的概述

TCP把連接作為最基本的對象，每一條TCP連接都有兩個端點，這種斷點我們叫作套接字（socket），它的定義為端口號拼接到IP地址即構成了套接字，例如，若IP地址為192.3.4.16 而端口號為80，那么得到的套接字為192.3.4.16:80。

TCP報文首部

1.源端口和目的端口，各占2個字節(jié)，分別寫入源端口和目的端口；

2.序號，占4個字節(jié)，TCP連接中傳送的字節(jié)流中的每個字節(jié)都按順序編號。例如，一段報文的序號字段值是 301 ，而攜帶的數(shù)據(jù)共有100字段，顯然下一個報文段（如果還有的話）的數(shù)據(jù)序號應該從401開始；

3.確認號，占4個字節(jié)，是期望收到對方下一個報文的第一個數(shù)據(jù)字節(jié)的序號。例如，B收到了A發(fā)送過來的報文，其序列號字段是501，而數(shù)據(jù)長度是200字節(jié)，這表明B正確的收到了A發(fā)送的到序號700為止的數(shù)據(jù)。因此，B期望收到A的下一個數(shù)據(jù)序號是701，于是B在發(fā)送給A的確認報文段中把確認號置為701；

4.數(shù)據(jù)偏移，占4位，它指出TCP報文的數(shù)據(jù)距離TCP報文段的起始處有多遠；

5.保留，占6位，保留今后使用，但目前應都位0；

6.緊急URG，當URG=1，表明緊急指針字段有效。告訴系統(tǒng)此報文段中有緊急數(shù)據(jù)；

7.確認ACK，僅當ACK=1時，確認號字段才有效。TCP規(guī)定，在連接建立后所有報文的傳輸都必須把ACK置1；

8.推送PSH，當兩個應用進程進行交互式通信時，有時在一端的應用進程希望在鍵入一個命令后立即就能收到對方的響應，這時候就將PSH=1；

9.復位RST，當RST=1，表明TCP連接中出現(xiàn)嚴重差錯，必須釋放連接，然后再重新建立連接；

10.同步SYN，在連接建立時用來同步序號。當SYN=1，ACK=0，表明是連接請求報文，若同意連接，則響應報文中應該使SYN=1，ACK=1；

11.終止FIN，用來釋放連接。當FIN=1，表明此報文的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并且要求釋放；

12.窗口，占2字節(jié)，指的是通知接收方，發(fā)送本報文你需要有多大的空間來接受；

13.檢驗和，占2字節(jié)，校驗首部和數(shù)據(jù)這兩部分；

14.緊急指針，占2字節(jié)，指出本報文段中的緊急數(shù)據(jù)的字節(jié)數(shù)；

15.選項，長度可變，定義一些其他的可選的參數(shù)。

TCP連接的建立（三次握手）

這里寫圖片描述

最開始的時候客戶端和服務器都是處于CLOSED狀態(tài)。主動打開連接的為客戶端，被動打開連接的是服務器。

1.TCP服務器進程先創(chuàng)建傳輸控制塊TCB，時刻準備接受客戶進程的連接請求，此時服務器就進入了LISTEN（監(jiān)聽）狀態(tài)；

2.TCP客戶進程也是先創(chuàng)建傳輸控制塊TCB，然后向服務器發(fā)出連接請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端進程進入了 SYN-SENT（同步已發(fā)送狀態(tài)）狀態(tài)。TCP規(guī)定，SYN報文段（SYN=1的報文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個序號。

3.TCP服務器收到請求報文后，如果同意連接，則發(fā)出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要為自己初始化一個序列號 seq=y，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態(tài)。這個報文也不能攜帶數(shù)據(jù)，但是同樣要消耗一個序號。

4.TCP客戶進程收到確認后，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，自己的序列號seq=x+1，此時，TCP連接建立，客戶端進入ESTABLISHED（已建立連接）狀態(tài)。TCP規(guī)定，ACK報文段可以攜帶數(shù)據(jù)，但是如果不攜帶數(shù)據(jù)則不消耗序號。

5.當服務器收到客戶端的確認后也進入ESTABLISHED狀態(tài)，此后雙方就可以開始通信了。

三次握手為

什么TCP客戶端最后還要發(fā)送一次確認呢？

一句話，主要防止已經(jīng)失效的連接請求報文突然又傳送到了服務器，從而產(chǎn)生錯誤。

如果使用的是兩次握手建立連接，假設有這樣一種場景，客戶端發(fā)送了第一個請求連接并且沒有丟失，只是因為在網(wǎng)絡結點中滯留的時間太長了，由于TCP的客戶端遲遲沒有收到確認報文，以為服務器沒有收到，此時重新向服務器發(fā)送這條報文，此后客戶端和服務器經(jīng)過兩次握手完成連接，傳輸數(shù)據(jù)，然后關閉連接。此時此前滯留的那一次請求連接，網(wǎng)絡通暢了到達了服務器，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端和服務器再次建立連接，這將導致不必要的錯誤和資源的浪費。

如果采用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文并且回復了確認報文，但是客戶端不會再次發(fā)出確認。由于服務器收不到確認，就知道客戶端并沒有請求連接。

TCP連接的釋放（四次揮手）

這里寫圖片描述

數(shù)據(jù)傳輸完畢后，雙方都可釋放連接。最開始的時候，客戶端和服務器都是處于ESTABLISHED狀態(tài)，然后客戶端主動關閉，服務器被動關閉。

客戶端進程發(fā)出連接釋放報文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報文首部，F(xiàn)IN=1，其序列號為seq=u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態(tài)。 TCP規(guī)定，F(xiàn)IN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。

服務器收到連接釋放報文，發(fā)出確認報文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態(tài)。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處于半關閉狀態(tài)，即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。

客戶端收到服務器的確認請求后，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務器發(fā)送連接釋放報文（在這之前還需要接受服務器發(fā)送的最后的數(shù)據(jù)）。

服務器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報文，F(xiàn)IN=1，ack=u+1，由于在半關閉狀態(tài)，服務器很可能又發(fā)送了一些數(shù)據(jù)，假定此時的序列號為seq=w，此時，服務器就進入了LAST-ACK（最后確認）狀態(tài)，等待客戶端的確認。

客戶端收到服務器的連接釋放報文后，必須發(fā)出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態(tài)。注意此時TCP連接還沒有釋放，必須經(jīng)過2 ∗ * ∗MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態(tài)。

服務器只要收到了客戶端發(fā)出的確認，立即進入CLOSED狀態(tài)。同樣，撤銷TCB后，就結束了這次的TCP連接?？?span style="color: #ff0000">以看到，服務器結束TCP連接的時間要比客戶端早一些。

四次揮手

為什么客戶端最后還要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允許不同的實現(xiàn)可以設置不同的MSL值。

第一，保證客戶端發(fā)送的最后一個ACK報文能夠到達服務器，因為這個ACK報文可能丟失，站在服務器的角度看來，我已經(jīng)發(fā)送了FIN+ACK報文請求斷開了，客戶端還沒有給我回應，應該是我發(fā)送的請求斷開報文它沒有收到，于是服務器又會重新發(fā)送一次，而客戶端就能在這個2MSL時間段內(nèi)收到這個重傳的報文，接著給出回應報文，并且會重啟2MSL計時器。

第二，防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請求報文段”出現(xiàn)在本連接中?？蛻舳税l(fā)送完最后一個確認報文后，在這個2MSL時間中，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡中消失。這樣新的連接中不會出現(xiàn)舊連接的請求報文。

為什么建立連接是三次握手，關閉連接確是四次揮手呢？

建立連接的時候，服務器在LISTEN狀態(tài)下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發(fā)送給客戶端。而關閉連接時，服務器收到對方的FIN報文時，僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，而自己也未必全部數(shù)據(jù)都發(fā)送給對方了，所以己方可以立即關閉，也可以發(fā)送一些數(shù)據(jù)給對方后，再發(fā)送FIN報文給對方來表示同意現(xiàn)在關閉連接，因此，己方ACK和FIN一般都會分開發(fā)送，從而導致多了一次。

如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？

TCP還設有一個?；钣嫊r器，顯然，客戶端如果出現(xiàn)故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數(shù)據(jù)，服務器就會發(fā)送一個探測報文段，以后每隔75秒發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。