TCP的三次握手和四次揮手及常見面試題

1、前言

今天上掘金查看熱門文章,發現一篇好文 ★前端 100 問:能搞懂 80% 的請把簡歷給我 ★ ,此文包含100個前端面試問題,仔細閱讀完全部題目後,頓感身中數刀沒法呼吸,留下了沒有技術的淚水,只好回爐重塑 ~前端

文章第16題:談談你對TCP三次握手和四次揮手的理解? 這是前端面試頻率特別高的一個題目,接下來咱們學習一下TCP的三次握手和四次揮手面試

2、爲何會有TCP/IP協議

計算機使用者意識到,計算機只是單兵做戰並不會發揮太大的做用。只有把它們聯合起來,電腦纔會發揮出它最大的潛力。因而人們就千方百計的用電線把電腦鏈接到了一塊兒。可是簡單的連到一塊兒是遠遠不夠的,須要定義一些共通的東西來進行交流,TCP/IP就是爲此而生。電腦有了這些,就好像學會了外語同樣,就能夠和其餘的計算機終端作自由的交流了。服務器

3、TCP簡介

傳輸層控制協議(TCP Transport Control Protocol),是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議,是爲了在不可靠的互聯網絡上提供可靠的端到端字節流而專門設計的一個傳輸協議。網絡

記住關鍵詞「面向鏈接」、「可靠」、「字節流」,這是學習掌握TCP的關鍵:post

  • 面向鏈接:客戶端、服務端交換數據前,須要創建鏈接
  • 可靠:經過特定機制,在不可靠的網絡之上,確保報文準確送達
  • 字節流:數據的最小單位爲字節。至於字節中存儲內容的含義,因爲應用層的程序決定


4、TCP報文格式

下面分別對其中的字段進行介紹:學習

⒈ 源端口(Source Port): 16位,表示數據從哪一個進程來,設計

⒉ 目的端口(Destination Port):16位,表示數據到哪一個進程去.指針

⒊ 序號(Sequence Number): 32位,TCP報文段中的數據部分,每個字節都有它的序號(遞增)。根據控制標誌中的SYN是否爲1,Sequence Number 表達不一樣的含義:cdn

  • SYN = 1:當前爲鏈接創建階段,此時的序號爲初始序號(ISN)。當數據傳輸正式開始時,數據的第一個字節的序號爲 ISN + 1
  • SYN = 0:當前報文段中,數據部分的第一個字節的序號。

⒋ 確認序號(Acknowledgment Number): 32位,當控制標誌的ACK爲1時,表示發送方但願收到的下一個報文段的序號(Sequence Number)。一旦鏈接創建成功,ACK值一直爲1。blog

⒌ 數據偏移(Data Offset): 4位,TCP報文段的首部長度,單位是word(4字節)。字面含義是:TCP報文段的數據的起始處,距離TCP報文段的起始處 的偏移量。4個字節最大能表示的數字是15,因此首部最大60字節。

⒍ 保留(Reserved): 6位,預留做爲後續用途,必須是0。

⒎ 控制標誌(Control Bits): 一共有6個控制標誌,其中SYN/ACK、FIN/ACK主要用於鏈接的創建、斷開階段。

  • URG: 當置爲1時,表示緊急指針(Urgent Pointer)字段有效;
  • ACK:確認序號字段(Acknowledgment Number)有效;
  • PSH:接收方應當即把這個報文段交給應用層;
  • RST: 重建鏈接;
  • SYN:同步序號,用於創建鏈接;
  • FIN: 發送端再也不發送數據;

⒏ 窗口大小(Window Size):16位,容許對方發送的數據量。告訴對方本身緩衝區還能容納多少字節,用來控制對方發送數據的速度。

⒐ 檢驗和(Checksum):16位,發送端對TCP首部、數據進行CRC運算得出的結果。接收端收到數據後,對接收到的TCP報文段的首部、數據進行CRC運算,並跟TCP首部中的校驗和進行對比,確保數據在傳輸過程當中沒有損壞。

⒑ 緊急指針(Urgent Pointer):16位,僅在URG=1時才生效,它的值是一個偏移量,和序號字段中的值相加獲得緊急數據最後一個字節的序號。


5、創建鏈接 vs 斷開鏈接

TCP是一種面向鏈接的單播協議,在發送數據前,通訊雙方必須在彼此間創建一條鏈接。所謂的「鏈接」,實際上是客戶端和服務器的內存裏保存的一份關於對方的信息,如ip地址、端口號等。

TCP提供了一種可靠、面向鏈接、字節流、傳輸層的服務,採用三次握手創建一個鏈接。採用四次揮手來關閉一個鏈接。

6、創建鏈接 - 三次握手

最開始的時候客戶端和服務器都是處於CLOSED狀態。主動打開鏈接的爲客戶端,被動打開鏈接的是服務器。

❶ TCP服務器進程先建立傳輸控制塊TCB,時刻準備接受客戶進程的鏈接請求,此時服務器就進入了LISTEN(監聽)狀態;

❷ TCP客戶進程也是先建立傳輸控制塊TCB,而後向服務器發出鏈接請求報文,這是報文首部中的同步序號SYN=1,同時選擇一個初始序列號 seq=x ,此時,TCP客戶端進程進入了 SYN-SENT(同步已發送狀態)狀態。TCP規定,SYN報文段(SYN=1的報文段)不能攜帶數據,但須要消耗掉一個序號。

❸ TCP服務器收到請求報文後,若是贊成鏈接,則發出確認報文。確認報文中應該 ACK=1,SYN=1,確認號是ack=x+1,同時也要爲本身初始化一個序列號 seq=y,此時,TCP服務器進程進入了SYN-RCVD(同步收到)狀態。這個報文也不能攜帶數據,可是一樣要消耗一個序號。

❹ TCP客戶進程收到確認後,還要向服務器給出確認。確認報文的ACK=1,ack=y+1,本身的序列號seq=x+1,此時,TCP鏈接創建,客戶端進入ESTABLISHED(已創建鏈接)狀態。TCP規定,ACK報文段能夠攜帶數據,可是若是不攜帶數據則不消耗序號。

❺ 當服務器收到客戶端的確認後也進入ESTABLISHED(已確認)狀態,此後雙方就能夠開始通訊了。

7、斷開鏈接 - 四次揮手

數據傳輸完畢後,雙方均可釋放鏈接。最開始的時候,客戶端和服務器都是處於ESTABLISHED狀態,而後客戶端主動關閉,服務器被動關閉。

❶ 客戶端進程發出鏈接釋放報文,而且中止發送數據。釋放數據報文首部,FIN=1,其序列號爲seq=u(等於前面已經傳送過來的數據的最後一個字節的序號加1),此時,客戶端進入FIN-WAIT-1(終止等待1)狀態。 TCP規定,FIN報文段即便不攜帶數據,也要消耗一個序號。

❷ 服務器收到鏈接釋放報文,發出確認報文,ACK=1,ack=u+1,而且帶上本身的序列號seq=v,此時,服務端就進入了CLOSE-WAIT(關閉等待)狀態。TCP服務器通知高層的應用進程,客戶端向服務器的方向就釋放了,這時候處於半關閉狀態,即客戶端已經沒有數據要發送了,可是服務器若發送數據,客戶端依然要接受。這個狀態還要持續一段時間,也就是整個CLOSE-WAIT狀態持續的時間。

❸ 客戶端收到服務器的確認請求後,此時,客戶端就進入FIN-WAIT-2(終止等待2)狀態,等待服務器發送鏈接釋放報文(在這以前還須要接受服務器發送的最後的數據)。

❹ 服務器將最後的數據發送完畢後,就向客戶端發送鏈接釋放報文,FIN=1,ack=u+1,因爲在半關閉狀態,服務器極可能又發送了一些數據,假定此時的序列號爲seq=w,此時,服務器就進入了LAST-ACK(最後確認)狀態,等待客戶端的確認。

❺ 客戶端收到服務器的鏈接釋放報文後,必須發出確認,ACK=1,ack=w+1,而本身的序列號是seq=u+1,此時,客戶端就進入了TIME-WAIT(時間等待)狀態。注意此時TCP鏈接尚未釋放,必須通過2∗ *∗MSL(最長報文段壽命)的時間後,當客戶端撤銷相應的TCB後,才進入CLOSED狀態。

❻ 服務器只要收到了客戶端發出的確認,當即進入CLOSED狀態。一樣,撤銷TCB後,就結束了此次的TCP鏈接。能夠看到,服務器結束TCP鏈接的時間要比客戶端早一些。

8、抓包解析TCP生命週期

下面爲wireshark抓包截圖,分爲3個部分:1創建鏈接,2數據傳輸,3斷開鏈接

【1】創建鏈接

客戶端 —> 服務端:[SYN] Seq=0; 客戶端、服務端的初始Seq值其實不是0,截圖中展現的0是個相對值,是wireshark爲了方便開發者進行抓包分析轉化過來的。

服務端 —> 客戶端:[SYN, ACK] Seq=0, Ack=1;

客戶端 —> 服務端:[ACK] Seq=1, Ack=1

【2】發送數據

數據交換是雙向的,這裏以服務端的HTTP響應爲例子。響應內容較大,被拆成了多個TCP包。整個數據發送的過程,就是服務端向客戶端發送數據,客戶端向服務端發送確認的過程。

服務端 —> 客戶端:Seq=1,TCP數據長度273。也就是說,服務端發送的報文段中,第一個數據字節的序號是1;下一個TCP報文段,第一個數據字節的序號應該是274(1 + 273)。

服務端 —> 客戶端:Seq=274,TCP數據長度1400。也就是說,服務端發送的報文段中,第一個數據字節的序號是274;下一個TCP報文段,第一個數據字節的序號應該是1674(274 + 1400)。

客戶端 —> 服務端:Ack=274。表示客戶端已經收到序號274以前的全部字節;也就是說,服務端若是繼續給客戶端發送TCP報文,應該發送序號274及之後的數據。

後面的分析過程同上

【3】斷開鏈接

​當服務端收到客戶端的斷開請求時(FIN=1),服務端在同一個響應包裏發送了FIN、ACK,達到了減小一個數據包的效果。

9、常見面試題

【1】建立鏈接,爲何TCP客戶端最後還要發送一次確認呢?

一句話,主要防止已經失效的鏈接請求報文忽然又傳送到了服務器,從而產生錯誤。

若是使用的是兩次握手創建鏈接,假設有這樣一種場景,客戶端發送了第一個請求鏈接而且沒有丟失,只是由於在網絡結點中滯留的時間太長了,因爲TCP的客戶端遲遲沒有收到確認報文,覺得服務器沒有收到,此時從新向服務器發送這條報文,此後客戶端和服務器通過兩次握手完成鏈接,傳輸數據,而後關閉鏈接。此時此前滯留的那一次請求鏈接,網絡通暢了到達了服務器,這個報文本該是失效的,可是,兩次握手的機制將會讓客戶端和服務器再次創建鏈接,這將致使沒必要要的錯誤和資源的浪費。

若是採用的是三次握手,就算是那一次失效的報文傳送過來了,服務端接受到了那條失效報文而且回覆了確認報文,可是客戶端不會再次發出確認。因爲服務器收不到確認,就知道客戶端並無請求鏈接。

【2】三次握手過程當中能夠攜帶數據嗎?

第一次、第二次握手不能夠攜帶數據,其中一個簡單的緣由就是會讓服務器更加容易受到攻擊了。而對於第三次的話,此時客戶端已經處於 ESTABLISHED 狀態。對於客戶端來講,他已經創建起鏈接了,而且也已經知道服務器的接收、發送能力是正常的了,因此能攜帶數據也沒啥毛病。

【3】SYN攻擊是什麼?

SYN攻擊就是Client在短期內僞造大量不存在的IP地址,並向Server不斷地發送SYN包,Server則回覆確認包,並等待Client確認,因爲源地址不存在,所以Server須要不斷重發直至超時,這些僞造的SYN包將長時間佔用未鏈接隊列,致使正常的SYN請求由於隊列滿而被丟棄,從而引發網絡擁塞甚至系統癱瘓。SYN 攻擊是一種典型的 DoS/DDoS 攻擊。

【4】爲何客戶端最後還要等待2MSL?

MSL(Maximum Segment Lifetime)可譯爲「最長報文段壽命」,它是任何報文在網絡上存在的最長時間,超過這個時間報文將被丟棄。TCP容許不一樣的實現能夠設置不一樣的MSL值。

第一,保證客戶端發送的最後一個ACK報文可以到達服務器,由於這個ACK報文可能丟失,站在服務器的角度看來,我已經發送了FIN+ACK報文請求斷開了,客戶端尚未給我回應,應該是我發送的請求斷開報文它沒有收到,因而服務器又會從新發送一次,而客戶端就能在這個2MSL時間段內收到這個重傳的報文,接着給出迴應報文,而且會重啓2MSL計時器。

第二,防止相似與「三次握手」中提到了的「已經失效的鏈接請求報文段」出如今本鏈接中。客戶端發送完最後一個確認報文後,在這個2MSL時間中,就可使本鏈接持續的時間內所產生的全部報文段都從網絡中消失。這樣新的鏈接中不會出現舊鏈接的請求報文。

【5】爲何創建鏈接是三次握手,關閉鏈接確是四次揮手呢?

創建鏈接的時候, 服務器在LISTEN狀態下,收到創建鏈接請求的SYN報文後,把ACK和SYN放在一個報文裏發送給客戶端。
而關閉鏈接時,服務器收到對方的FIN報文時,僅僅表示對方再也不發送數據了可是還能接收數據,而本身也未必所有數據都發送給對方了,因此己方能夠當即關閉,也能夠發送一些數據給對方後,再發送FIN報文給對方來表示贊成如今關閉鏈接,所以,己方ACK和FIN通常都會分開發送,從而致使多了一次。

【6】若是已經創建了鏈接,可是客戶端忽然出現故障了怎麼辦?

TCP還設有一個保活計時器,顯然,客戶端若是出現故障,服務器不能一直等下去,白白浪費資源。服務器每收到一次客戶端的請求後都會從新復位這個計時器,時間一般是設置爲2小時,若兩小時尚未收到客戶端的任何數據,服務器就會發送一個探測報文段,之後每隔75秒發送一次。若一連發送10個探測報文仍然沒反應,服務器就認爲客戶端出了故障,接着就關閉鏈接。

相關文章
相關標籤/搜索