（面試）TCP、UDP協議

TCP（傳輸控制協議）和UDP（用戶數據報協議）是互聯網核心的傳輸層協議，負責應用程序之間的數據傳輸。它們在設計目標、特性和適用場景上有顯著差異：

TCP：面向連接，可靠的，速度慢、效率低，適用于需要傳輸可靠的數據時使用。
UDP：無連接，不可靠，速度快、效率高，適用于高效傳輸忽略可靠性時使用

1. TCP（Transmission Control Protocol）

特點：
- 面向連接：通信前需通過“三次握手”建立連接，結束后通過“四次揮手”斷開連接。
- 可靠傳輸：通過確認應答（ACK）、超時重傳、數據排序等機制確保數據不丟失、不重復、按序到達。
- 流量控制：通過滑動窗口機制動態調整發送速率，避免接收方緩沖區溢出。
- 擁塞控制：通過慢啟動、擁塞避免等算法減少網絡擁塞。
- 全雙工通信：支持雙向數據流。
頭部開銷：較大（通常20字節，可擴展至60字節），包含序列號、確認號、控制標志等字段。
適用場景：需要高可靠性的應用，如網頁瀏覽（HTTP/HTTPS）、文件傳輸（FTP）、電子郵件（SMTP）等。

2. UDP（User Datagram Protocol）

特點：
- 無連接：無需建立連接，直接發送數據包。
- 不可靠傳輸：不保證數據到達、不保證順序，無重傳機制。
- 輕量高效：頭部僅8字節（含源/目標端口、長度、校驗和），無復雜控制機制。
- 支持廣播/多播：可向多個目標同時發送數據。
- 低延遲：無需等待確認或重傳，適合實時應用。
適用場景：對實時性要求高、可容忍少量丟失的應用，如視頻會議（Zoom）、在線游戲、DNS查詢、VoIP（如Skype）、物聯網傳感器數據等。

TCP三次握手與四次揮手全指南?

三次握手確保客戶端與服務器收發能力正常，四次揮手處理雙向連接釋放。

圖中字符詳解：
SYN：代表連接請求或接收的報文段。
seq：指發送的第一個字節的序號。
ACK：確認報文段，用于回應SYN。
ack：確認號，表示希望收到的下一個數據的第一個字節的序號。

在TCP協議中，主動發起連接請求的一方被稱為客戶端，而被動等待連接的一方則被稱為服務端。無論是客戶端還是服務端，一旦TCP連接成功建立，雙方均可進行數據的發送與接收。

連接建立之初，服務器和客戶端都處于CLOSED狀態。在通信正式開始前，雙方需要分別創建自己的傳輸控制塊（TCB）。服務器完成TCB創建后，會進入LISTEN狀態，隨時準備接收客戶端發來的連接請求。
1、第一次握手：
客戶端向服務端發送一個SYN報文（SYN=1），并指明客戶端的初始化序列號ISN(x)，即圖中的seq=x，它表示本報文段所發送的數據的第一個字節的序號。在發送SYN報文后，客戶端進入SYN_SENT狀態，意味著它正在等待服務端的連接確認。

SYN_SENT狀態解釋：當客戶端發送連接請求后，它進入SYN_SENT狀態，等待服務端的響應。在這個狀態下，客戶端準備好了接受服務端的連接確認。

TCP協議規定：SYN=1的報文段是用于建立連接的請求，它不攜帶任何數據，但會消耗一個序號。這是TCP協議確保連接建立過程中的有序性和可靠性的一種方式。
2、第二次握手：
服務器在接收到客戶端的SYN報文后，會以SYN報文作為回應（SYN=1），并賦予自己獨特的初始化序列號ISN(y)，即圖中的seq=y。同時，服務器將客戶端的ISN+1設置為確認號ack的值，以此確認已收到客戶端的SYN報文，并期待接收到的下一個數據報的起始序號為x+1。在此之后，服務器會進入SYN-RCVD狀態，等待對連接請求的進一步確認。

SYN-RCVD狀態解析：當服務器在收到并發送連接請求后，會進入SYN-RCVD狀態，此時它正在等待對初始連接請求的確認。在這個狀態下，服務器已經準備好接受來自客戶端的進一步通信。

TCP協議規定：SYN=1且ACK=1的報文段是用于確認連接的應答，它同樣不攜帶任何數據，但通過確認號的使用，確保了連接建立過程中的有序性和可靠性。
3、第三次握手：
在收到服務器發送的SYN報文后，客戶端會回應一個ACK報文。這個ACK報文將服務器的ISN+1作為ack的值，表明客戶端已經收到了服務器的SYN報文，并期待接收到的下一個數據報的起始序號為y+1。同時，客戶端將自己的序列號seq設置為x+1，即初始序列號seq=x增加1。完成這些操作后，客戶端進入ESTABLISHED狀態，表示連接已成功建立。服務器在收到這個ACK報文后，也會轉入ESTABLISHED狀態，此時雙方連接的建立工作全部完成。

ESTABLISHED狀態解釋：當一個TCP連接進入ESTABLISHED狀態時，它意味著連接已經打開，數據可以開始在雙方之間傳送。

四次揮手連接釋放：
TCP連接的終止需要經過四次包的交換，因此被稱為四次揮手。在這四次交換中，客戶端或服務器都可以主動發起連接的釋放動作。值得注意的是，TCP連接是雙向的，因此四次揮手中，前兩次主要用于斷開一個方向的連接，后兩次則用于斷開另一方向的連接。
?

1、第一次揮手
客戶端首先發送一個FIN報文，其中包含一個序列號seq=u，表示請求連接終止。在發送完畢后，客戶端停止數據發送，并主動關閉TCP連接。此時，客戶端進入FIN_WAIT_1狀態，等待服務器的確認。

FIN_WAIT_1狀態解析：該狀態表示客戶端正在等待遠程TCP的連接中斷請求，或者等待先前連接中斷請求的確認。FIN=1標志著該報文段是一個連接釋放請求。而seq=u則代表客戶端向服務器發送的最后一個字節的序號。
2、第二次揮手
服務端在收到客戶端的FIN報文后，會發送一個ACK報文作為回應。這個ACK報文中，序列號值設為客戶端序號值加1，意在確認已收到客戶端的報文。隨后，服務端進入CLOSE_WAIT狀態，等待本地用戶的連接中斷請求。

CLOSE_WAIT狀態解析：在此狀態下，服務端等待來自本地用戶的連接釋放請求。ACK報文中的ACK=1表示應答，而seq=v則指明了服務端釋放應答報文段的首字節序號。同時，ack=u+1表明服務端希望從第u+1個字節開始接收報文段，并已成功接收了前u個字節。

完成第二次揮手后，客戶端到服務端的連接已釋放，服務端不再接收客戶端數據，而客戶端也已無數據待發送。然而，服務端到客戶端的連接仍保持開啟，若服務端在此期間發送數據，客戶端仍需正常接收。此狀態將持續一段時間，直至整個CLOSE-WAIT狀態結束。
3、第三次揮手
服務端在完成數據的發送后，會向客戶端發送一個連接釋放報文。這個報文頭包含FIN標志位為1，以及ack序號值為u+1。由于在CLOSE_WAIT狀態期間，服務端可能又發送了一些數據，假設此時的序列號為seq=w。發送完畢后，服務端進入LAST_ACK狀態，等待來自客戶端的連接中斷確認。
4、第四次揮手
客戶端在收到服務端的FIN報文后，會響應一個ACK報文，其中ack序號值為w+1，同時將自己的序列值加1作為ACK報文的seq序號值，即seq=u+1。此后，客戶端進入TIME_WAIT狀態。
TIME_WAIT：確保遠程TCP收到連接中斷請求的確認
該狀態會持續2MSL（最長報文段壽命）的時間。在此期間，TCP連接并未完全釋放。若在這段時間內未收到服務端的重發請求，客戶端將進入CLOSED狀態，并撤銷TCB。
服務端在收到客戶端的確認ACK報文后，會立即進入CLOSED狀態，并撤銷TCB，從而結束此次TCP連接。值得注意的是，服務端結束TCP連接的時間點通常早于客戶端。
1、為何TCP建立連接時采用三次握手而非兩次或四次？
采用兩次握手會導致已失效的連接請求報文段被重新發送至服務端，從而造成服務端資源的無效消耗。而三次握手已足夠確保握手過程中的通信正常，無需增加至四次，否則將顯得冗余。
2、為何TCP關閉連接時需要四次揮手？
TCP協議的半關閉特性允許其連接的一端在完成發送后，仍能繼續接收來自另一端的數據。因此，任何一方都可以在數據傳輸結束后主動發起連接釋放的通知，并在對方確認后進入半關閉狀態。當另一方也確認無數據再發送時，才會發出最終的連接釋放通知，對方確認后，TCP連接即完全關閉。
3、為何TIME_WAIT狀態需持續2MSL后才能轉為CLOSE狀態？

當TCP連接的一方完成連接釋放后，會進入TIME_WAIT狀態。這個狀態需要持續2倍的最大段壽命（Maximum Segment Lifetime，MSL）的時間，這是為了確保在傳輸過程中可能存在的延遲數據包能夠被對方完全接收。只有當2MSL時間過去后，確認對方已收到所有數據，該TCP連接才能完全關閉，進入CLOSE狀態。

確保服務端能夠接收到客戶端的確認應答。

如果客戶端在發送完確認應答后立即進入CLOSED狀態，而該應答不幸丟失，服務端在等待超時后將嘗試重新發送連接釋放請求。但此時，由于客戶端已經關閉，無法再作出響應，這會導致服務端無法正常關閉TCP連接。因此，TIME_WAIT狀態的持續存在，是為了保證服務端能夠接收到并處理客戶端的確認應答，從而確保連接的平滑關閉。
2. 防止“三次握手”中提及的“已失效的連接請求報文段”干擾當前連接。

當客戶端發送完最后一個確認報文后，經過2MSL的時間間隔，可以確保在本連接持續時間內產生的所有報文段都已從網絡中清除。這樣，新建立的連接就不會受到舊連接請求報文的影響。