每日一句英語學習，每天進步一點點：

前言

不管面試 Java 、C/C++、Python 等開發崗位， TCP 的知識點可以說是的必問的了。

任 TCP 虐我千百遍，我仍待 TCP 如初戀。

遙想小林當年校招時常因 TCP 面試題被刷，真是又愛又狠….

過去不會沒關係，今天就讓我們來消除這份恐懼，微笑著勇敢的面對它吧！

所以小林整理了關於 TCP 三次握手和四次揮手的面試題型，跟大家一起探討探討。

1. TCP 基本認識

2. TCP 連線建立

3. TCP 連線斷開

4. Socket 程式設計

PS：本次文章不涉及 TCP 流量控制、擁塞控制、可靠性傳輸等方面知識，這些留在下篇哈！

正文

01 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 前必須先建立連線，而建立連線是通過三次握手而進行的。

• 一開始，客戶端和服務端都處於 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 協議的通訊雙方， 都必須維護一個「序列號」， 序列號是可靠傳輸的一個關鍵因素，它的作用：

• 接收方可以去除重複的資料；
• 接收方可以根據資料包的序列號按序接收；
• 可以標識傳送出去的資料包中， 哪些是已經被對方收到的；

可見，序列號在 TCP 連線中佔據著非常重要的作用，所以當客戶端傳送攜帶「初始序列號」的 SYN 報文的時候，需要服務端回一個 ACK 應答報文，表示客戶端的 SVN 報文已被服務端成功接收，那當服務端傳送「初始序列號」給客戶端的時候，依然也要得到客戶端的應答迴應，這樣一來一回，才能確保雙方的初始序列號能被可靠的同步。

四次握手其實也能夠可靠的同步雙方的初始化序號，但由於第二步和第三步可以優化成一步，所以就成了「三次握手」。

而兩次握手只保證了一方的初始序列號能被對方成功接收，沒辦法保證雙方的初始序列號都能被確認接收。

原因三：避免資源浪費

如果只有「兩次握手」，當客戶端的 SYN 請求連線在網路中阻塞，客戶端沒有接收到 ACK 報文，就會重新發送 SYN ，由於沒有第三次握手，伺服器不清楚客戶端是否收到了自己傳送的建立連線的 ACK 確認訊號，所以每收到一個 SYN 就只能先主動建立一個連線，這會造成什麼情況呢？

如果客戶端的 SYN 阻塞了，重複傳送多次 SYN 報文，那麼伺服器在收到請求後就會建立多個冗餘的無效連結，造成不必要的資源浪費。

即兩次握手會造成訊息滯留情況下，伺服器重複接受無用的連線請求 SYN 報文，而造成重複分配資源。

小結

TCP 建立連線時，通過三次握手能防止歷史連線的建立，能減少雙方不必要的資源開銷，能幫助雙方同步初始化序列號。序列號能夠保證資料包不重複、不丟棄和按序傳輸。

不使用「兩次握手」和「四次握手」的原因：

• 「兩次握手」：無法防止歷史連線的建立，會造成雙方資源的浪費，也無法可靠的同步雙方序列號；
• 「四次握手」：三次握手就已經理論上最少可靠連線建立，所以不需要使用更多的通訊次數。

為什麼客戶端和服務端的初始序列號 ISN 是不相同的？

因為網路中的報文會延遲、會複製重發、也有可能丟失，這樣會造成的不同連線之間產生互相影響，所以為了避免互相影響，客戶端和服務端的初始序列號是隨機且不同的。

初始序列號 ISN 是如何隨機產生的？

起始 ISN 是基於時鐘的，每 4 毫秒 + 1，轉一圈要 4.55 個小時。

RFC1948 中提出了一個較好的初始化序列號 ISN 隨機生成演算法。

ISN = M + F (localhost, localport, remotehost, remoteport)

• M 是一個計時器，這個計時器每隔 4 毫秒加 1。
• F 是一個 Hash 演算法，根據源 IP、目的 IP、源埠、目的埠生成一個隨機數值。要保證 Hash 演算法不能被外部輕易推算得出，用 MD5 演算法是一個比較好的選擇。

既然 IP 層會分片，為什麼 TCP 層還需要 MSS 呢？

我們先來認識下 MTU 和 MSS