TCP協議的三次握手和四次揮手

一、OSI七層模型與TCP/IP協議簡介

OSI七層模型與TCP/IP四層(參考)模型

OSI模型(Open System Interconnection Reference Model,縮寫為OSI),全名“開放式系統互聯通信參考模型”,是一個試圖使各種計算機在全世界范圍內互聯為網絡的標準框架。
TCP/IP協議族(TCP/IP Protocol Suite,或TCP/IP Protocols),簡稱TCP/IP協議。有關TCP/IP協議的詳細理論介紹參見《TCP/IP詳解》。

二、TCP報文格式說明

  • TCP協議屬于OSI模型的傳輸層,傳輸層的功能是使源端主機和目標端主機上的對等實體可以進行會話。

  • TCP協議是一個面向連接的、可靠的協議。它將一臺主機發出的字節流無差錯地發往互聯網上的其他主機。

  • 在發送端,它負責把上層傳送下來的字節流分成報文段并傳遞給下層。

  • 在接收端,它負責把收到的報文進行重組后遞交給上層。

  • TCP協議還要處理端到端的流量控制,以避免緩慢接收的接收方沒有足夠的緩沖區接收發送方發送的大量數據。


    TCP報文格式圖

    圖中重點字段介紹:
    (1)序號:Seq序號,占32位,用來標識從TCP源端向目的端發送的字節流,發起方發送數據時對此進行標記。
    (2)確認序號:Ack序號,占32位,只有ACK標志位為1時,確認序號字段才有效,Ack=Seq+1。
    (3)標志位:共6個,即URG、ACK、PSH、RST、SYN、FIN等,具體含義如下:

SYN(synchronous)建立聯機,發起一個新連接。
ACK(acknowledgement )確認序號有效。
PSH(push)傳送,接收方應該盡快將這個報文交給應用層。
FIN(finish)結束,釋放一個連接。
RST(reset)重置連接。
URG(urgent)緊急指針有效。
需要注意的是:
(A)不要將確認序號Ack與標志位中的ACK搞混了。
(B)確認方Ack=發起方Req+1,兩端配對。

三、TCP完整連接過程與狀態示意

TCP連接狀態轉移圖
  • LISTEN:偵聽來自客戶端的TCP端口的連接請求
  • SYN-SENT:再發送連接請求后等待匹配的連接請求(如果有大量這樣的狀態包,檢查是否中招了)
  • SYN-RCVD:再收到和發送一個連接請求后等待對方對連接請求的確認(如有大量此狀態,估計被flood攻擊了)
  • ESTABLISHED:代表一個打開的連接
  • FIN-WAIT-1:等待遠程TCP連接中斷請求,或先前的連接中斷請求的確認
  • FIN-WAIT-2:從遠程TCP等待連接中斷請求
  • CLOSE-WAIT:等待從本地用戶發來的連接中斷請求
  • LAST-ACK:等待原來的發向遠程TCP的連接中斷請求的確認(不是什么好東西,此項出現,檢查是否被攻擊)
  • TIME-WAIT:等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
  • CLOSED:沒有任何連接狀態,連接結束

四、TCP的3次握手過程

所謂三次握手(Three-Way Handshake)即建立TCP連接,就是指建立一個TCP連接時,需要客戶端和服務端總共發送3個包以確認連接的建立。在socket編程中,這一過程服務器accept(被動等待),由客戶端執行connect來觸發(主動打開)。

三次握手示例過程

為什么需要“三次握手”?

目的是“為了防止已失效的連接請求報文段突然又傳送到了服務端,因而產生錯誤”。
例子:client發出的第一個連接請求報文段并沒有丟失,而是在某個網絡結點長時間的滯留了,以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后,就誤認為是client再次發出的一個新的連接請求。于是就向client發出確認報文段,同意建立連接。假設不采用“三次握手”,那么只要server發出確認,新的連接就建立了。由于現在client并沒有發出建立連接的請求,因此不會理睬server的確認,也不會向server發送數據。但server卻以為新的運輸連接已經建立,并一直等待client發來數據。這樣,server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況,client不會向server的確認發出確認。server由于收不到確認,就知道client并沒有要求建立連接。”。主要目的防止server端一直等待,浪費資源。

整個流程如下圖所示:
seq:(Sequence number順序號碼) ack:(Acknowledge number確認號碼)

三次握手流程圖

(1)第一次握手:

  • 發送端首先發送一個帶SYN標志的數據包給接收端。
  • Client將標志位SYN置為1,隨機產生一個值seq=J,并將該數據包發送給Server,Client進入SYN_SENT狀態,等待Server確認。

(2)第二次握手:

  • 接收端收到后,回傳一個帶有SYN/ACK標志的數據包以示傳達確認信息。
  • Server收到數據包后由標志位SYN=1知道Client請求建立連接,Server將標志位SYN和ACK都置為1,ack=J+1,隨機產生一個值seq=K,并將該數據包發送給Client以確認連接請求,Server進入SYN_RCVD狀態。

(3)第三次握手:

  • 發送端再回傳一個帶ACK標志的數據包
  • Client收到確認后,檢查ack是否為J+1,ACK是否為1,如果正確則將標志位ACK置為1,ack=K+1,并將該數據包發送給Server,Server檢查ack是否為K+1,ACK是否為1,如果正確則連接建立成功,Client和Server進入ESTABLISHED狀態,完成三次握手,隨后Client與Server之間可以開始傳輸數據了。

實例:
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則連接建立成功。

SYN攻擊: 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攻擊( 沒有根治方法, 除非不用TCP/IP鏈接),檢測SYN攻擊的方式非常簡單,即當Server上有大量半連接狀態且源IP地址是隨機的,則可以斷定遭到SYN攻擊了,使用系統自帶的netstat 工具來檢測SYN攻擊命令可以讓之現行:#netstat -nap | grep SYN_RECV

五、TCP的4次揮手過程

所謂四次揮手(Four-Way Wavehand)即終止TCP連接,就是指斷開一個TCP連接時,需要客戶端和服務端總共發送4個包以確認連接的斷開。在socket編程中,這一過程由客戶端或服務端任一方執行close來觸發。
為什么要四次揮手?

由于TCP連接是全雙工(通訊傳輸的一個術語:即允許數據在兩個方向上可以同時(瞬時)進行信號的雙向傳輸,指A→B的同時B→A。)的,因此,每個方向都必須要單獨進行關閉,這一原則是當一方完成數據發送任務后,發送一個FIN來終止這一方向的連接,收到一個FIN只是意味著這一方向上沒有數據流動了,即不會再收到數據了,但是在這個TCP連接上仍然能夠發送數據,直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉,而另一方則執行被動關閉。

整個流程如下圖所示:

一方主動關閉的四次揮手流程圖

(1)第一次揮手:Client:我已經不會再給你發數據了。

  • Client(主動關閉方)發送一個FIN,用來關閉Client到Server(被動關閉方)的數據傳送,Client進入FIN_WAIT_1狀態。
  • (當然,在FIN包之前發送出去的數據,如果沒有收到對應的ack確認報文,主動關閉方依然會重發這些數據),但是,此時主動關閉方還可 以接受數據。

(2)第二次揮手:Server:好,我知道了。

  • Server收到FIN后,發送一個ACK給Client,確認序號為收到序號+1(與SYN相同,一個FIN占用一個序號),Server進入CLOSE_WAIT狀態。

(3)第三次揮手:Server:我的數據也發送完了,我也不會再給你發數據了。

  • Server發送一個FIN,用來關閉Server到Client的數據傳送,Server進入LAST_ACK狀態。

(4)第四次揮手:Client:OK,我也知道了,再見。

  • Client收到FIN后,Client進入TIME_WAIT狀態,接著發送一個ACK給Server,確認序號為收到序號+1,Server進入CLOSED狀態,完成四次揮手。

上面是一方主動關閉,另一方被動關閉的情況,實際中還會出現同時發起主動關閉的情況,具體流程如下圖:


雙方同時主動關閉的四次揮手流程圖

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

六、常見問題

TCP與UDP的區別是什么?

  • TCP(Transmission Control Protocol,傳輸控制協議)是基于連接的協議,也就是說,在正式收發數據前,必須和對方建立可靠的連接。一個TCP連接(一對一)必須要經過三次“對話”才能建立起來。保證兩端通信主機之間的通信可達;全雙工通信;面向字節流;首部最低20個字節
  • UDP(User Data Protocol,用戶數據報協議)是與TCP相對應的協議。它是面向無連接的傳輸層協議。它不與對方建立連接,而是直接就把數據包發送過去!支持一對一、一對多、多對一、多對多的交互通信。 不保證可靠交付,也不使用擁塞控制;面向報文的,沒有擁塞控制,適合多媒體通信的要求;首部開銷小8字節。

三次握手有什么缺點?
慢,效率低,占用系統資源高,易被攻擊 TCP在傳遞數據之前,要先建連接,這會消耗時間,而且在數據傳遞時,確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間,而且要在每臺設備上維護所有的傳輸連接,事實上,每個連接都會占用系統的CPU、內存等硬件資源。 而且,因為TCP有確認機制、三次握手機制,這些也導致TCP容易被人利用,實現DOS、DDOS、CC等攻擊。

為什么建立連接是三次握手,而關閉連接卻是四次揮手呢?
這是因為服務端在LISTEN狀態下,收到建立連接請求的SYN報文后,把ACK和SYN放在一個報文里發送給客戶端。而關閉連接時,當收到對方的FIN報文時,僅僅表示對方不再發送數據了但是還能接收數據,己方也未必全部數據都發送給對方了,所以己方可以立即close,也可以發送一些數據給對方后,再發送FIN報文給對方來表示同意現在關閉連接,因此,己方ACK和FIN一般都會分開發送。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,197評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,415評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,104評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,884評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,647評論 6 408
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,130評論 1 323
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,208評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,366評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,887評論 1 334
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,737評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,939評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,478評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,174評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,586評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,827評論 1 283
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,608評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,914評論 2 372

推薦閱讀更多精彩內容