一、面試官：什么是TCP的三次握手？三次握手的過程是怎么樣的？為什么需要三次握手而不是兩次或者四次？

TCP（傳輸控制協(xié)議）是一種面向連接的、可靠的傳輸層協(xié)議。在建立連接時，TCP使用三次握手（Three-way Handshake）機制來確保通信雙方能夠同步彼此的序列號，并確認雙方都具備發(fā)送和接收數(shù)據(jù)的能力 。

1. 三次握手的具體過程

(1) 第一次握手

客戶端向服務(wù)器發(fā)送一個SYN（同步）包，表示希望建立連接。這個SYN包中包含一個隨機生成的初始序列號（ISN, Initial Sequence Number），用于后續(xù)數(shù)據(jù)傳輸?shù)木幪?。發(fā)送完成后，客戶端進入SYN_SENT狀態(tài)，等待服務(wù)器的響應(yīng) 。

(2) 第二次握手

服務(wù)器收到客戶端的SYN包后，會向客戶端回復(fù)一個SYN+ACK包。其中，SYN表示服務(wù)器同意建立連接，ACK是對客戶端SYN包的確認，確認號為客戶端的初始序列號加1。同時，服務(wù)器也會生成自己的初始序列號，并將其包含在SYN包中。此時，服務(wù)器進入SYN_RCVD狀態(tài) 。

(3) 第三次握手

客戶端收到服務(wù)器的SYN+ACK包后，會再向服務(wù)器發(fā)送一個ACK包，作為對服務(wù)器SYN包的確認。這個ACK包的確認號是服務(wù)器的初始序列號加1。發(fā)送完成后，客戶端和服務(wù)器都進入ESTABLISHED狀態(tài)，連接正式建立，雙方可以開始傳輸數(shù)據(jù) 。

2. 為什么需要三次握手而非兩次或者四次？

(1) 同步雙方的初始序列號

TCP協(xié)議的通信雙方都必須維護一個序列號，這是確?？煽總鬏?shù)年P(guān)鍵因素。序列號在TCP連接中扮演了重要角色，它具有以下作用：

• 接收方可以消除重復(fù)的數(shù)據(jù)，確保數(shù)據(jù)的準確性。
• 接收方可以按照序列號的順序接收數(shù)據(jù)包，保證數(shù)據(jù)的完整性。
• 序列號可以標識已經(jīng)被對方接收的數(shù)據(jù)包，實現(xiàn)可靠的數(shù)據(jù)傳輸。

因此，在建立TCP連接時，客戶端發(fā)送帶有初始序列號的SYN報文，并需要服務(wù)器回復(fù)一個ACK報文，表示成功接收了客戶端的SYN報文。然后，服務(wù)器發(fā)送帶有初始序列號的SYN報文給客戶端，并等待客戶端的應(yīng)答，這樣一來一回，才能確保雙方的初始序列號能夠可靠地同步。

雖然四次握手也可以實現(xiàn)可靠地同步雙方的初始序列號，但由于第二步和第三步可以合并為一步，所以最終演變成了三次握手。而兩次握手只能保證一方的初始序列號被對方成功接收，無法保證雙方的初始序列號都能被確認接收。因此，三次握手是為了確保TCP連接的穩(wěn)定性和可靠性而采取的最佳選擇。

(2) 防止舊的重復(fù)連接初始化造成混亂

在網(wǎng)絡(luò)通信中，數(shù)據(jù)包可能會因為網(wǎng)絡(luò)擁塞、路由問題或其他原因而延遲到達。這些延遲的數(shù)據(jù)包被稱為“歷史數(shù)據(jù)包”或“舊數(shù)據(jù)包”。如果TCP只使用兩次握手，服務(wù)器無法區(qū)分當前收到的SYN包是新的連接請求，還是一個延遲到達的舊連接請求 。

假設(shè)以下場景：

客戶端發(fā)送了一個SYN包（連接請求），但由于網(wǎng)絡(luò)延遲，這個SYN包沒有及時到達服務(wù)器。

客戶端由于超時未收到服務(wù)器的響應(yīng)，重新發(fā)送了一個新的SYN包（新的連接請求）。

如果采用兩次握手，服務(wù)器收到新的SYN包后，回復(fù)SYN+ACK包，并認為連接已建立。

隨后，舊的SYN包延遲到達服務(wù)器。由于服務(wù)器只進行兩次握手，它會將這個舊的SYN包誤認為是一個新的連接請求，并回復(fù)SYN+ACK包，進而為這個不存在的連接分配資源 。

三次握手如何避免這個問題？在三次握手中：

• 當服務(wù)器收到SYN包后，會回復(fù)SYN+ACK包（第二次握手），但不會立即進入連接狀態(tài)。
• 只有當客戶端收到SYN+ACK包并回復(fù)ACK包（第三次握手）后，服務(wù)器才會確認這是一個有效的連接。
• 如果舊的SYN包延遲到達服務(wù)器，服務(wù)器會回復(fù)SYN+ACK包，但客戶端不會發(fā)送最終的ACK包，因為客戶端并沒有發(fā)起這個舊的連接請求。因此，服務(wù)器會丟棄這個無效的連接，避免資源浪費 。

(3) 確認雙方的收發(fā)能力

三次握手確保了雙方都能正常發(fā)送和接收數(shù)據(jù)。例如，客戶端通過第二次握手確認服務(wù)器能接收到自己的包；服務(wù)器通過第三次握手確認客戶端能接收到自己的包 。

二、面試官追問：第三次握手過程中，如果客戶端的ACK未送達服務(wù)器，會發(fā)生什么？如果已經(jīng)建立了連接，但客戶端出現(xiàn)了故障怎么辦？

在TCP三次握手過程中，如果第三次握手的ACK包未送達服務(wù)器，會發(fā)生以下情況：

1. 服務(wù)器的行為

服務(wù)器在發(fā)送SYN+ACK包后，會進入SYN_RCVD狀態(tài)，并等待客戶端的ACK確認。

如果服務(wù)器沒有收到客戶端的ACK包，它會認為自己的SYN+ACK包可能丟失，因此會根據(jù)TCP的超時重傳機制，重新發(fā)送SYN+ACK包。

通常情況下，服務(wù)器會嘗試重傳SYN+ACK包最多5次（具體次數(shù)取決于實現(xiàn)），每次重傳的時間間隔會逐漸增加（例如3秒、6秒、12秒等）。

如果經(jīng)過多次重傳后仍然沒有收到客戶端的ACK確認，服務(wù)器會放棄建立連接，并進入CLOSED狀態(tài)，釋放相關(guān)資源。

在服務(wù)端進入CLOSED狀態(tài)之后，如果客戶端向服務(wù)器發(fā)送數(shù)據(jù)，服務(wù)器會以RST包應(yīng)答。

2. 客戶端的行為

客戶端在發(fā)送ACK包后，會進入ESTABLISHED狀態(tài)，認為連接已經(jīng)建立。

如果客戶端隨后開始向服務(wù)器發(fā)送數(shù)據(jù)，而服務(wù)器尚未收到ACK確認，服務(wù)器在收到數(shù)據(jù)包時會檢查其中的ACK標志位。如果數(shù)據(jù)包中包含有效的ACK信息，服務(wù)器會將其視為對SYN+ACK的確認，并完成連接的建立。

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

在TCP協(xié)議中，若已建立連接但客戶端出現(xiàn)故障，服務(wù)器端會通過?；顧C制（Keepalive）檢測連接狀態(tài)，并采取相應(yīng)措施釋放資源。以下是詳細分析：

(1) TCP連接故障處理機制

?；顧C制（Keepalive）：

• 觸發(fā)條件：當連接長時間無數(shù)據(jù)交互時（默認2小時），服務(wù)器會啟動?；钐綔y。
• 探測過程：服務(wù)器每隔75秒發(fā)送一次探測報文（空數(shù)據(jù)包），若連續(xù)10次（約11分鐘）未收到客戶端響應(yīng)，則判定連接失效。
• 結(jié)果處理：服務(wù)器主動關(guān)閉連接，釋放占用的端口和內(nèi)存資源，避免資源泄漏。

(2) 潛在問題與解決方案

?；顧C制缺陷：

檢測延遲：默認11分鐘的檢測周期較長，可能無法滿足實時性要求。

優(yōu)化建議：在應(yīng)用層實現(xiàn)心跳機制（如HTTP長輪詢、WebSocket），通過自定義協(xié)議定期發(fā)送心跳包，縮短故障檢測時間。

資源競爭風(fēng)險：

場景：若客戶端崩潰前未釋放連接，服務(wù)器可能因資源耗盡（如TIME_WAIT狀態(tài)堆積）無法建立新連接。

優(yōu)化建議：

• 調(diào)整內(nèi)核參數(shù)（如`net.ipv4.tcp_keepalive_time`）縮短?；铋g隔。  
• 使用連接池技術(shù)復(fù)用連接，減少頻繁建立/釋放的開銷。

三、面試官追問：TCP四次揮手的過程是怎么樣的？為什么不能把服務(wù)器發(fā)送的ACK和FIN合并起來，變成三次揮手？

TCP斷開連接需要通過四次揮手的方式。雙方都有能力主動斷開連接，一旦斷開連接，主機中的各種「資源」將被釋放。

TCP連接是全雙工的，因此每個方向都必須單獨進行關(guān)閉。首先進行關(guān)閉的一方將執(zhí)行主動關(guān)閉，而另一方則執(zhí)行被動關(guān)閉。

整個過程通常涉及四個步驟，每個步驟都通過交換TCP報文段來完成。而且每次揮手客戶端和服務(wù)端都會進入到相應(yīng)的狀態(tài) (FIN_WAIT_1、FIN_WAIT_2、CLOSED_WAIT、LAST_ACK 和 TIME_WAIT)。

1. 四次揮手詳細步驟

i

(1) 第一次揮手：主動關(guān)閉方發(fā)送FIN報文

• 過程：主動關(guān)閉方（通常是客戶端）發(fā)送一個FIN（Finish）報文段，表示它已經(jīng)沒有數(shù)據(jù)要發(fā)送了，希望關(guān)閉連接，但此時主動關(guān)閉方還能接受數(shù)據(jù)。此時，主動關(guān)閉方進入FIN_WAIT_1狀態(tài)，等待被動關(guān)閉方的確認。
• 報文段內(nèi)容：FIN報文段中，F(xiàn)IN標志位被設(shè)置為1，同時可能包含一個序列號（seq），用于標識該報文段在數(shù)據(jù)流中的位置。

(2) 第二次揮手：被動關(guān)閉方回應(yīng)ACK報文

• 過程：被動關(guān)閉方（通常是服務(wù)器）收到FIN報文段后，發(fā)送一個ACK（Acknowledgment）報文段作為回應(yīng)，表示已經(jīng)收到了關(guān)閉請求。此時，被動關(guān)閉方進入CLOSE_WAIT狀態(tài)，表示它已經(jīng)準備好關(guān)閉連接，但還可能需要處理剩余的數(shù)據(jù)。主動關(guān)閉方收到ACK報文段后，進入FIN_WAIT_2狀態(tài)。在這個階段，如果服務(wù)端處理好了數(shù)據(jù)（如果有的話）會將數(shù)據(jù)發(fā)送給客戶端。
• 報文段內(nèi)容：ACK報文段中，ACK標志位被設(shè)置為1，確認序號（ack）為收到的FIN報文段的序列號加1，表示對FIN報文段的確認。

(3) 第三次揮手：被動關(guān)閉方發(fā)送FIN報文

• 過程：被動關(guān)閉方在處理完剩余數(shù)據(jù)后，發(fā)送一個FIN報文段，表示它也沒有數(shù)據(jù)要發(fā)送了，請求關(guān)閉連接。此時，被動關(guān)閉方進入LAST_ACK狀態(tài)，等待主動關(guān)閉方的確認。
• 報文段內(nèi)容：FIN報文段中，F(xiàn)IN標志位被設(shè)置為1，同時可能包含一個序列號（seq），用于標識該報文段在數(shù)據(jù)流中的位置。

(4) 第四次揮手：主動關(guān)閉方回應(yīng)ACK報文并進入TIME_WAIT狀態(tài)

• 過程：主動關(guān)閉方收到被動關(guān)閉方的FIN報文段后，發(fā)送一個ACK報文段作為回應(yīng)，表示已經(jīng)收到了關(guān)閉請求。此時，主動關(guān)閉方進入TIME_WAIT狀態(tài)，等待一段時間（通常為2MSL，即最大段生存期的兩倍），以確保被動關(guān)閉方收到了最終的ACK報文段。如果被動關(guān)閉方?jīng)]有收到ACK報文段，它會重新發(fā)送FIN報文段，主動關(guān)閉方則可以再次發(fā)送ACK報文段。等待時間結(jié)束后，主動關(guān)閉方進入CLOSED狀態(tài)，連接正式關(guān)閉。被動關(guān)閉方收到ACK報文段后，也立即進入CLOSED狀態(tài)。
• 報文段內(nèi)容：ACK報文段中，ACK標志位被設(shè)置為1，確認序號（ack）為收到的FIN報文段的序列號加1，表示對FIN報文段的確認。

2. 為什么不能將ACK和FIN合并為三次揮手？

為了更好地理解為什么揮手需要四次，讓我們再來回顧一下雙方發(fā)出FIN包的過程。這樣我們就能理解為什么需要四次揮手了。

在關(guān)閉連接時，當客戶端向服務(wù)端發(fā)送FIN時，這僅僅表示客戶端不再發(fā)送數(shù)據(jù)了，但是它仍然可以接收數(shù)據(jù)。

當服務(wù)端收到客戶端的FIN報文時，它首先會回復(fù)一個ACK應(yīng)答報文。然而，服務(wù)端可能還有數(shù)據(jù)需要處理和發(fā)送，所以它會等待直到它不再發(fā)送數(shù)據(jù)時，才會發(fā)送FIN報文給客戶端，表示同意現(xiàn)在關(guān)閉連接。

通過上述過程，我們可以看出，服務(wù)端通常需要等待完成數(shù)據(jù)的發(fā)送和處理，所以服務(wù)端的ACK和FIN通常會分開發(fā)送，這就導(dǎo)致了比三次握手多了一次揮手的過程。

四、面試官追問：為什么主動關(guān)閉方最后一次揮手后會進入TIME_WAIT狀態(tài)而不是直接釋放資源？為什 TIME_WAIT 狀態(tài)持續(xù)的時間是2MSL？

TIME_WAIT 狀態(tài)的存在是為了確保網(wǎng)絡(luò)連接的可靠關(guān)閉。只有主動發(fā)起關(guān)閉連接的一方（即主動關(guān)閉方）才會有 TIME_WAIT 狀態(tài)。

客戶端進入 TIME_WAIT 狀態(tài)是 TCP 協(xié)議可靠性和健壯性設(shè)計的重要體現(xiàn)，其核心意義體現(xiàn)在以下關(guān)鍵方面：

1. 確?？煽拷K止連接

避免數(shù)據(jù)丟失：在 TCP 四次揮手過程中，客戶端發(fā)送最后一個 ACK 確認報文后進入 TIME_WAIT 狀態(tài)，等待 2 倍最大報文段生存時間（2MSL）。若該 ACK 丟失，服務(wù)端會重傳 FIN 報文，客戶端可在 TIME_WAIT 期間重新發(fā)送 ACK，確保服務(wù)端正確關(guān)閉連接。

處理延遲或重傳報文：網(wǎng)絡(luò)中可能存在延遲或重傳的報文，TIME_WAIT 狀態(tài)確保這些報文在連接完全終止前被丟棄，避免干擾后續(xù)新連接。

2. 防止連接復(fù)用沖突

避免端口和地址混淆：TCP 連接由四元組（源 IP、源端口、目的 IP、目的端口）唯一標識。TIME_WAIT 狀態(tài)確保在舊連接完全終止前，相同的四元組不會被新連接復(fù)用。若新連接復(fù)用舊連接的地址和端口，舊連接的延遲報文可能被誤認為新連接的數(shù)據(jù)，導(dǎo)致數(shù)據(jù)混亂。

維持連接唯一性：通過等待 2MSL，TIME_WAIT 狀態(tài)確保舊連接的報文在網(wǎng)絡(luò)中自然消失，從而保證新連接的獨立性和正確性。

為什 TIME_WAIT 狀態(tài)持續(xù)的時間是2MSL？

MSL是報文在網(wǎng)絡(luò)中存活的最長時間，超過該時間后，報文將被丟棄。不同操作系統(tǒng)或網(wǎng)絡(luò)設(shè)備對MSL的定義可能存在差異（如RFC 793建議MSL為2分鐘，但實際可能更短）。

如上所述，TCP報文在網(wǎng)絡(luò)中可能因延遲、路由重傳等原因滯留，最長可達MSL時間。若主動關(guān)閉方在TIME_WAIT階段未等待足夠時間，新建立的連接可能復(fù)用相同的四元組（源IP、源端口、目的IP、目的端口），導(dǎo)致滯留的舊連接報文被誤認為新連接數(shù)據(jù)，引發(fā)數(shù)據(jù)混亂或協(xié)議錯誤。

等待2MSL可確保所有舊連接報文因超時而被丟棄，避免對新連接造成干擾。例如，若MSL為30秒，則2MSL為60秒，足以覆蓋網(wǎng)絡(luò)中可能的最長滯留時間。

雖然TIME_WAIT狀態(tài)會占用端口和系統(tǒng)資源，但2MSL的等待時間是協(xié)議可靠性的必要代價。在高并發(fā)場景下，可通過調(diào)整系統(tǒng)參數(shù)（如縮短TIME_WAIT時間或復(fù)用TIME_WAIT連接）優(yōu)化資源利用率，但需謹慎權(quán)衡可靠性與性能。

五、面試官追問：TCP和UDP協(xié)議的區(qū)別是什么？它們的適用場景分別有哪些？

TCP是一種面向連接、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

面向連接：面向連接意味著TCP通信是一對一的，即點對點端到端的通信，不像UDP可以同時向多個主機發(fā)送消息，因此無法實現(xiàn)一對多的通信。

可靠的：TCP的可靠性保證了無論網(wǎng)絡(luò)鏈路中發(fā)生何種變化，TCP都能確保報文的可靠傳輸?shù)竭_接收端，這也使得TCP的協(xié)議報文格式相比UDP更為復(fù)雜。

基于字節(jié)流：基于字節(jié)流的特性使得TCP可以傳輸任意大小的消息，而且保證了消息的有序性，前一個消息未被完全接收，即使后面的字節(jié)已經(jīng)接收，TCP也不會將其交付給應(yīng)用層處理。同時對于重復(fù)的報文會自動丟棄。

UDP（User Datagram Protocol）是一種面向無連接的通信協(xié)議，相比于TCP，UDP不提供復(fù)雜的控制機制。UDP協(xié)議允許應(yīng)用程序在不建立連接的情況下直接發(fā)送封裝的IP數(shù)據(jù)包。開發(fā)人員選擇使用UDP而不是TCP時，應(yīng)用程序與IP直接進行通信。

1. 核心特性對比

2. 關(guān)鍵差異解析

(1) 可靠性 vs 高效性

• TCP：通過確認機制（ACK）、重傳（Retransmission）、序列號（Sequence Number）等技術(shù)確保數(shù)據(jù)可靠傳輸，但會增加延遲和開銷。
• UDP：僅提供“盡力而為”的傳輸，不保證數(shù)據(jù)完整性，但因無需等待確認，可實現(xiàn)更低延遲的實時通信。

(2) 連接建立 vs 即發(fā)即走

• TCP：需通過三次握手建立連接（SYN→SYN+ACK→ACK），類似打電話前先撥號確認；關(guān)閉時需四次揮手（FIN→ACK→FIN→ACK），類似掛電話前的禮貌道別。
• UDP：直接發(fā)送數(shù)據(jù)包，無需任何連接建立過程，類似寫信無需確認收件人是否在線。

(3) 性能開銷對比

• TCP：頭部包含序列號、確認號、窗口大小等字段，共20字節(jié)基礎(chǔ)開銷，復(fù)雜場景可能擴展至60字節(jié)。
• UDP：頭部僅包含源端口、目的端口、長度、校驗和等8字節(jié)字段，開銷極低。

3. 典型應(yīng)用場景

(1) TCP適用場景

• 需要高可靠性的應(yīng)用：如HTTP/HTTPS（網(wǎng)頁）、FTP（文件傳輸）、SMTP（郵件）、SSH（遠程登錄）。
• 數(shù)據(jù)完整性敏感的場景：如銀行交易、數(shù)據(jù)庫同步。

(2) UDP適用場景

• 實時性要求高的應(yīng)用：如視頻直播（允許少量丟包）、在線游戲（低延遲比丟包更重要）。
• 廣播/組播通信：如視頻會議、物聯(lián)網(wǎng)設(shè)備群控。
• 簡單請求-響應(yīng)模式：如DNS查詢（通常單包即可完成）。
• 自定義協(xié)議設(shè)計：如QUIC協(xié)議（Google基于UDP開發(fā)，融合TCP可靠性）。

4. 優(yōu)缺點總結(jié)

總結(jié)：TCP與UDP的選擇本質(zhì)是“可靠性”與“效率”的權(quán)衡。TCP適用于對數(shù)據(jù)完整性要求嚴苛的場景，而UDP更適合實時性優(yōu)先或簡單通信需求的場景。實際開發(fā)中，可根據(jù)業(yè)務(wù)特性選擇協(xié)議，或通過混合方案兼顧兩者優(yōu)勢。