每日一句英語學習,每天進步一點點: 前言 不管面試 Java 、C/C++、Python 等開發崗位, TCP 的知識點可以說是的必問的了。 任 TCP 虐我千百遍,我仍待 TCP 如初戀。 遙想小林當年校招時常因 TCP 面試題被刷,真是又愛又狠…. 過去不會沒關係,今天就讓我們來消除這份恐懼,微 ...
每日一句英語學習,每天進步一點點:
前言
不管面試 Java 、C/C++、Python 等開發崗位, TCP
的知識點可以說是的必問的了。
任 TCP 虐我千百遍,我仍待 TCP 如初戀。
遙想小林當年校招時常因 TCP
面試題被刷,真是又愛又狠….
過去不會沒關係,今天就讓我們來消除這份恐懼,微笑著勇敢的面對它吧!
所以小林整理了關於 TCP 三次握手和四次揮手的面試題型,跟大家一起探討探討。
- TCP 基本認識
- TCP 連接建立
- TCP 連接斷開
- Socket 編程
PS:本次文章不涉及 TCP 流量控制、擁塞控制、可靠性傳輸等方面知識,這些留在下篇哈!
正文
01 TCP 基本認識
瞧瞧 TCP 頭格式
我們先來看看 TCP 頭的格式,標註顏色的表示與本文關聯比較大的欄位,其他欄位不做詳細闡述。
TCP 頭格式序列號:在建立連接時由電腦生成的隨機數作為其初始值,通過 SYN 包傳給接收端主機,每發送一次數據,就「累加」一次該「數據位元組數」的大小。用來解決網路包亂序問題。
確認應答號:指下一次「期望」收到的數據的序列號,發送端收到這個確認應答以後可以認為在這個序號以前的數據都已經被正常接收。用來解決不丟包的問題。
控制位:
- ACK:該位為
1
時,「確認應答」的欄位變為有效,TCP 規定除了最初建立連接時的SYN
包之外該位必須設置為1
。 - RST:該位為
1
時,表示 TCP 連接中出現異常必須強制斷開連接。 - SYC:該位為
1
時,表示希望建立連,併在其「序列號」的欄位進行序列號初始值的設定。 - FIN:該位為
1
時,表示今後不會再有數據發送,希望斷開連接。當通信結束希望斷開連接時,通信雙方的主機之間就可以相互交換FIN
位置為 1 的 TCP 段。
為什麼需要 TCP 協議? TCP 工作在哪一層?
IP
層是「不可靠」的,它不保證網路包的交付、不保證網路包的按序交付、也不保證網路包中的數據的完整性。
如果需要保障網路數據包的可靠性,那麼就需要由上層(傳輸層)的 TCP
協議來負責。
因為 TCP 是一個工作在傳輸層的可靠數據傳輸的服務,它能確保接收端接收的網路包是無損壞、無間隔、非冗餘和按序的。
什麼是 TCP ?
TCP 是面向連接的、可靠的、基於位元組流的傳輸層通信協議。
-
面向連接:一定是「一對一」才能連接,不能像 UDP 協議 可以一個主機同時向多個主機發送消息,也就是一對多是無法做到的;
-
可靠的:無論的網路鏈路中出現了怎樣的鏈路變化,TCP 都可以保證一個報文一定能夠到達接收端;
-
位元組流:消息是「沒有邊界」的,所以無論我們消息有多大都可以進行傳輸。並且消息是「有序的」,當「前一個」消息沒有收到的時候,即使它先收到了後面的位元組已經收到,那麼也不能扔給應用層去處理,同時對「重覆」的報文會自動丟棄。
什麼是 TCP 連接?
我們來看看 RFC 793 是如何定義「連接」的:
Connections: The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection.
簡單來說就是,用於保證可靠性和流量控制維護的某些狀態信息,這些信息的組合,包括Socket、序列號和視窗大小稱為連接。
所以我們可以知道,建立一個 TCP 連接是需要客戶端與伺服器端達成上述三個信息的共識。
- Socket:由 IP 地址和埠號組成
- 序列號:用來解決亂序問題等
- 視窗大小:用來做流量控制
如何唯一確定一個 TCP 連接呢?
TCP 四元組可以唯一的確定一個連接,四元組包括如下:
- 源地址
- 源埠
- 目的地址
- 目的埠
源地址和目的地址的欄位(32位)是在 IP 頭部中,作用是通過 IP 協議發送報文給對方主機。
源埠和目的埠的欄位(16位)是在 TCP 頭部中,作用是告訴 TCP 協議應該把報文發給哪個進程。
有一個 IP 的伺服器監聽了一個埠,它的 TCP 的最大連接數是多少?
伺服器通常固定在某個本地埠上監聽,等待客戶端的連接請求。
因此,客戶端 IP 和 埠是可變的,其理論值計算公式如下:
對 IPv4,客戶端的 IP 數最多為 2
的 32
次方,客戶端的埠數最多為 2
的 16
次方,也就是服務端單機最大 TCP 連接數,約為 2
的 48
次方。
當然,服務端最大併發 TCP 連接數遠不能達到理論上限。
- 首先主要是文件描述符限制,Socket 都是文件,所以首先要通過
ulimit
配置文件描述符的數目; - 另一個是記憶體限制,每個 TCP 連接都要占用一定記憶體,操作系統是有限的。
UDP 和 TCP 有什麼區別呢?分別的應用場景是?
UDP 不提供複雜的控制機制,利用 IP 提供面向「無連接」的通信服務。
UDP 協議真的非常簡,頭部只有 8
個位元組( 64 位),UDP 的頭部格式如下:
- 目標和源埠:主要是告訴 UDP 協議應該把報文發給哪個進程。
- 包長度:該欄位保存了 UDP 首部的長度跟數據的長度之和。
- 校驗和:校驗和是為了提供可靠的 UDP 首部和數據而設計。
TCP 和 UDP 區別:
1. 連接
- TCP 是面向連接的傳輸層協議,傳輸數據前先要建立連接。
- UDP 是不需要連接,即刻傳輸數據。
2. 服務對象
- TCP 是一對一的兩點服務,即一條連接只有兩個端點。
- UDP 支持一對一、一對多、多對多的交互通信
3. 可靠性
- TCP 是可靠交付數據的,數據可以無差錯、不丟失、不重覆、按需到達。
- UDP 是盡最大努力交付,不保證可靠交付數據。
4. 擁塞控制、流量控制
- TCP 有擁塞控制和流量控制機制,保證數據傳輸的安全性。
- UDP 則沒有,即使網路非常擁堵了,也不會影響 UDP 的發送速率。
5. 首部開銷
- TCP 首部長度較長,會有一定的開銷,首部在沒有使用「選項」欄位時是
20
個位元組,如果使用了「選項」欄位則會變長的。 - UDP 首部只有 8 個位元組,並且是固定不變的,開銷較小。
TCP 和 UDP 應用場景:
由於 TCP 是面向連接,能保證數據的可靠性交付,因此經常用於:
FTP
文件傳輸HTTP
/HTTPS
由於 UDP 面向無連接,它可以隨時發送數據,再加上UDP本身的處理既簡單又高效,因此經常用於:
- 包總量較少的通信,如
DNS
、SNMP
等 - 視頻、音頻等多媒體通信
- 廣播通信
為什麼 UDP 頭部沒有「首部長度」欄位,而 TCP 頭部有「首部長度」欄位呢?
原因是 TCP 有可變長的「選項」欄位,而 UDP 頭部長度則是不會變化的,無需多一個欄位去記錄 UDP 的首部長度。
為什麼 UDP 頭部有「包長度」欄位,而 TCP 頭部則沒有「包長度」欄位呢?
先說說 TCP 是如何計算負載數據長度:
其中 IP 總長度 和 IP 首部長度,在 IP 首部格式是已知的。TCP 首部長度,則是在 TCP 首部格式已知的,所以就可以求得 TCP 數據的長度。
大家這時就奇怪了問:“ UDP 也是基於 IP 層的呀,那 UDP 的數據長度也可以通過這個公式計算呀? 為何還要有「包長度」呢?”
這麼一問,確實感覺 UDP 「包長度」是冗餘的。
因為為了網路設備硬體設計和處理方便,首部長度需要是 4
位元組的整數倍。
如果去掉 UDP 「包長度」欄位,那 UDP 首部長度就不是 4
位元組的整數倍了,所以小林覺得這可能是為了補全 UDP 首部長度是 4
位元組的整數倍,才補充了「包長度」欄位。
02 TCP 連接建立
TCP 三次握手過程和狀態變遷
TCP 是面向連接的協議,所以使用 TCP 前必須先建立連接,而建立連接是通過三次握手而進行的。
TCP 三次握手- 一開始,客戶端和服務端都處於
CLOSED
狀態。先是服務端主動監聽某個埠,處於LISTEN
狀態
- 客戶端會隨機初始化序號(
client_isn
),將此序號置於 TCP 首部的「序號」欄位中,同時把SYN
標誌位置為1
,表示SYN
報文。接著把第一個 SYN 報文發送給服務端,表示向服務端發起連接,該報文不包含應用層數據,之後客戶端處於SYN-SENT
狀態。
- 服務端收到客戶端的
SYN
報文後,首先服務端也隨機初始化自己的序號(server_isn
),將此序號填入 TCP 首部的「序號」欄位中,其次把 TCP 首部的「確認應答號」欄位填入client_isn + 1
, 接著把SYN
和ACK
標誌位置為1
。最後把該報文發給客戶端,該報文也不包含應用層數據,之後服務端處於SYN-RCVD
狀態。
-
客戶端收到服務端報文後,還要向服務端回應最後一個應答報文,首先該應答報文 TCP 首部
ACK
標誌位置為1
,其次「確認應答號」欄位填入server_isn + 1
,最後把報文發送給服務端,這次報文可以攜帶客戶到伺服器的數據,之後客戶端處於ESTABLISHED
狀態。 -
伺服器收到客戶端的應答報文後,也進入
ESTABLISHED
狀態。
從上面的過程可以發現第三次握手是可以攜帶數據的,前兩次握手是不可以攜帶數據的,這也是面試常問的題。
一旦完成三次握手,雙方都處於 ESTABLISHED
狀態,此致連接就已建立完成,客戶端和服務端就可以相互發送數據了。
如何在 Linux 系統中查看 TCP 狀態?
TCP 的連接狀態查看,在 Linux 可以通過 netstat -napt
命令查看。
為什麼是三次握手?不是兩次、四次?
相信大家比較常回答的是:“因為三次握手才能保證雙方具有接收和發送的能力。”
這回答是沒問題,但這回答是片面的,並沒有說出主要的原因。
在前面我們知道了什麼是 TCP 連接:
- 用於保證可靠性和流量控制維護的某些狀態信息,這些信息的組合,包括Socket、序列號和視窗大小稱為連接。
所以,重要的是為什麼三次握手才可以初始化Socket、序列號和視窗大小並建立 TCP 連接。
接下來以三個方面分析三次握手的原因:
- 三次握手才可以阻止重覆歷史連接的初始化(主要原因)
- 三次握手才可以同步雙方的初始序列號
- 三次握手才可以避免資源浪費
原因一:避免歷史連接
我們來看看 RFC 793 指出的 TCP 連接使用三次握手的首要原因:
The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.
簡單來說,三次握手的首要原因是為了防止舊的重覆連接初始化造成混亂。
網路環境是錯綜複雜的,往往並不是如我們期望的一樣,先發送的數據包,就先到達目標主機,反而它很騷,可能會由於網路擁堵等亂七八糟的原因,會使得舊的數據包,先到達目標主機,那麼這種情況下 TCP 三次握手是如何避免的呢?
三次握手避免歷史連接客戶端連續發送多次 SYN 建立連接的報文,在網路擁堵等情況下:
- 一個「舊 SVN 報文」比「最新的 SYN 」 報文早到達了服務端;
- 那麼此時服務端就會回一個
SYN + ACK
報文給客戶端; - 客戶端收到後可以根據自身的上下文,判斷這是一個歷史連接(序列號過期或超時),那麼客戶端就會發送
RST
報文給服務端,表示中止這一次連接。
如果是兩次握手連接,就不能判斷當前連接是否是歷史連接,三次握手則可以在客戶端(發送方)準備發送第三次報文時,客戶端因有足夠的上下文來判斷當前連接是否是歷史連接:
- 如果是歷史連接(序列號過期或超時),則第三次握手發送的報文是
RST
報文,以此中止歷史連接; - 如果不是歷史連接,則第三次發送的報文是
ACK
報文,通信雙方就會成功建立連接;
所以, TCP 使用三次握手建立連接的最主要原因是防止歷史連接初始化了連接。
原因二:同步雙方初始序列號
TCP 協議的通信雙方, 都必須維護一個「序列號」, 序列號是可靠傳輸的一個關鍵因素,它的作用: