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

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

1. 三次握手的具體過(guò)程

(1) 第一次握手

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

(2) 第二次握手

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

(3) 第三次握手

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

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

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

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

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

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

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

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

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

假設(shè)以下場(chǎng)景：

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

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

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

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

三次握手如何避免這個(gè)問(wèn)題？在三次握手中：

• 當(dāng)服務(wù)器收到SYN包后，會(huì)回復(fù)SYN+ACK包（第二次握手），但不會(huì)立即進(jìn)入連接狀態(tài)。
• 只有當(dāng)客戶端收到SYN+ACK包并回復(fù)ACK包（第三次握手）后，服務(wù)器才會(huì)確認(rèn)這是一個(gè)有效的連接。
• 如果舊的SYN包延遲到達(dá)服務(wù)器，服務(wù)器會(huì)回復(fù)SYN+ACK包，但客戶端不會(huì)發(fā)送最終的ACK包，因?yàn)榭蛻舳瞬](méi)有發(fā)起這個(gè)舊的連接請(qǐng)求。因此，服務(wù)器會(huì)丟棄這個(gè)無(wú)效的連接，避免資源浪費(fèi) 。

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

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

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

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

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

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

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

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

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

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

2. 客戶端的行為

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

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

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

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

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

?；顧C(jī)制（Keepalive）：

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

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

?；顧C(jī)制缺陷：

檢測(cè)延遲：默認(rèn)11分鐘的檢測(cè)周期較長(zhǎng)，可能無(wú)法滿足實(shí)時(shí)性要求。

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

資源競(jìng)爭(zhēng)風(fēng)險(xiǎn)：

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

優(yōu)化建議：

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

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

TCP斷開(kāi)連接需要通過(guò)四次揮手的方式。雙方都有能力主動(dòng)斷開(kāi)連接，一旦斷開(kāi)連接，主機(jī)中的各種「資源」將被釋放。

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

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

1. 四次揮手詳細(xì)步驟

i

(1) 第一次揮手：主動(dòng)關(guān)閉方發(fā)送FIN報(bào)文

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

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

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

(3) 第三次揮手：被動(dòng)關(guān)閉方發(fā)送FIN報(bào)文

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

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

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

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

為了更好地理解為什么揮手需要四次，讓我們?cè)賮?lái)回顧一下雙方發(fā)出FIN包的過(guò)程。這樣我們就能理解為什么需要四次揮手了。

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

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

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

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

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

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

1. 確?？煽拷K止連接

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 核心特性對(duì)比

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

(1) 可靠性 vs 高效性

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

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

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

(3) 性能開(kāi)銷對(duì)比

• TCP：頭部包含序列號(hào)、確認(rèn)號(hào)、窗口大小等字段，共20字節(jié)基礎(chǔ)開(kāi)銷，復(fù)雜場(chǎng)景可能擴(kuò)展至60字節(jié)。
• UDP：頭部?jī)H包含源端口、目的端口、長(zhǎng)度、校驗(yàn)和等8字節(jié)字段，開(kāi)銷極低。

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

(1) TCP適用場(chǎng)景

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

(2) UDP適用場(chǎng)景

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

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

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