面試計算機網(wǎng)絡(luò)框架八股文十問十答第七期
作者：程序員小白條，個人博客
相信看了本文后，對你的面試是有一定幫助的！關(guān)注專欄后就能收到持續(xù)更新！
?點贊?收藏?不迷路！?文章來源地址http://www.zghlxwxcb.cn/news/detail-826002.html
1）UDP協(xié)議為什么不可靠？
UDP（用戶數(shù)據(jù)報協(xié)議）是一種無連接的、不可靠的傳輸協(xié)議。它的不可靠性主要體現(xiàn)在以下幾個方面：
- 無連接性： UDP 不需要在發(fā)送數(shù)據(jù)之前建立連接，也不維護連接狀態(tài)，因此不會進行握手和維持連接的開銷。這使得 UDP 更加輕量級，但也使得它無法保證數(shù)據(jù)的可靠傳輸。
- 不保證數(shù)據(jù)的到達順序： 由于 UDP 不會對數(shù)據(jù)包進行排序和重組，因此發(fā)送的數(shù)據(jù)包的到達順序不一定與發(fā)送順序一致。在網(wǎng)絡(luò)中，數(shù)據(jù)包可能會因為不同的路由和網(wǎng)絡(luò)擁塞情況而以不同的順序到達目的地。
- 不提供重傳機制： UDP 協(xié)議本身不提供重傳機制。如果一個數(shù)據(jù)包在傳輸過程中丟失，UDP 協(xié)議不會負責重新發(fā)送該數(shù)據(jù)包，而是由應(yīng)用層自行處理丟失的情況。
因此，盡管 UDP 在一些對實時性要求高、數(shù)據(jù)丟失對應(yīng)用影響不大的場景下表現(xiàn)出色，但在對數(shù)據(jù)完整性和可靠性要求較高的場景下，通常會選擇使用 TCP 協(xié)議。
2）TCP的重傳機制
TCP（傳輸控制協(xié)議）是一種面向連接的、可靠的傳輸協(xié)議。TCP 通過以下機制來保證數(shù)據(jù)的可靠傳輸：
- 序列號和確認應(yīng)答： TCP 在發(fā)送的數(shù)據(jù)包中會包含序列號，接收方收到數(shù)據(jù)后會發(fā)送確認應(yīng)答，告知發(fā)送方已經(jīng)收到了哪些數(shù)據(jù)。如果發(fā)送方在合理的超時時間內(nèi)沒有收到確認應(yīng)答，就會認為數(shù)據(jù)丟失，進行重傳。
- 超時重傳： 如果發(fā)送方在一定時間內(nèi)沒有收到確認應(yīng)答，就會重新發(fā)送相同的數(shù)據(jù)包。TCP 會動態(tài)調(diào)整重傳的超時時間，以適應(yīng)網(wǎng)絡(luò)的變化。
- 快速重傳： 如果發(fā)送方收到了對同一數(shù)據(jù)包的三個重復的確認應(yīng)答，就會認為接收方已經(jīng)丟失了后續(xù)的數(shù)據(jù)，立即進行快速重傳，而不必等待超時時間到期。
3）TCP的擁塞控制機制
TCP 的擁塞控制是為了避免過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，導致網(wǎng)絡(luò)擁塞，從而影響網(wǎng)絡(luò)性能。TCP 的擁塞控制主要包括以下幾個機制：
- 慢啟動： 發(fā)送方在連接剛建立時，會以指數(shù)增長的速率增加發(fā)送窗口大小，以快速填滿網(wǎng)絡(luò)的帶寬。
- 擁塞避免： 一旦發(fā)送方開始遇到丟包，就會進入擁塞避免階段，發(fā)送窗口大小會線性增長，而不是指數(shù)增長，以降低發(fā)送速率。
- 快速重傳和快速恢復： 當發(fā)送方收到對同一數(shù)據(jù)包的三個重復的確認應(yīng)答時，會觸發(fā)快速重傳和快速恢復機制，以快速調(diào)整發(fā)送窗口大小，避免繼續(xù)注入更多的數(shù)據(jù)到網(wǎng)絡(luò)中。
通過這些擁塞控制機制，TCP 能夠在一定程度上適應(yīng)網(wǎng)絡(luò)的擁塞情況，保證網(wǎng)絡(luò)的穩(wěn)定性和公平性。
4）TCP的流量控制機制
TCP 的流量控制是為了防止發(fā)送方發(fā)送過多的數(shù)據(jù)，導致接收方無法處理。流量控制主要通過滑動窗口（Sliding Window）機制來實現(xiàn)：
- 接收窗口（rwnd）： 接收方在通信的過程中會通知發(fā)送方自己當前的接收窗口大小，即能夠接收的數(shù)據(jù)量。發(fā)送方根據(jù)這個信息來控制發(fā)送的數(shù)據(jù)量，保證不會超過接收方的處理能力。
- 滑動窗口： 發(fā)送方維護一個發(fā)送窗口，表示可以發(fā)送但還未收到確認的數(shù)據(jù)段的范圍?；瑒哟翱诘拇笮∈艿浇邮辗酵ㄖ慕邮沾翱诖笮『途W(wǎng)絡(luò)的實際情況的影響。
通過動態(tài)調(diào)整滑動窗口的大小，TCP 實現(xiàn)了流量控制，確保在通信過程中不會因為發(fā)送方速度過快而導致接收方無法處理。
5）TCP的可靠傳輸機制
TCP 的可靠傳輸機制主要包括以下幾個方面：
- 序列號和確認應(yīng)答： 發(fā)送方會為每個數(shù)據(jù)包分配一個序列號，接收方通過確認應(yīng)答來告知發(fā)送方已經(jīng)正確接收到數(shù)據(jù)。如果發(fā)送方在一定時間內(nèi)未收到確認應(yīng)答，會進行重傳。
- 超時重傳： 如果發(fā)送方在合理的超時時間內(nèi)未收到確認應(yīng)答，會認為數(shù)據(jù)包丟失，進行超時重傳。
- 快速重傳和快速恢復： 當發(fā)送方收到對同一數(shù)據(jù)包的三個重復的確認應(yīng)答時，會觸發(fā)快速重傳和快速恢復機制，以快速調(diào)整發(fā)送窗口大小。
- 選擇性重傳： 發(fā)送方能夠選擇性地重傳丟失的數(shù)據(jù)包，而不是重新傳輸所有的數(shù)據(jù)。
這些機制使得 TCP 在不可靠的網(wǎng)絡(luò)環(huán)境中能夠保證數(shù)據(jù)的可靠傳輸。
6）TCP的三次握手和四次揮手
TCP 的連接建立和斷開分別通過三次握手和四次揮手來完成：
三次握手（Connection Establishment）：
- 客戶端發(fā)送 SYN： 客戶端發(fā)送一個帶有 SYN（同步）標志的數(shù)據(jù)包，表示請求建立連接。
- 服務(wù)端發(fā)送 SYN + ACK： 服務(wù)端收到客戶端的請求后，回復一個帶有 SYN 和 ACK（確認）標志的數(shù)據(jù)包，表示同意建立連接。
- 客戶端發(fā)送 ACK： 客戶端收到服務(wù)端的確認后，發(fā)送一個帶有 ACK 標志的數(shù)據(jù)包，表示連接建立完成。
四次揮手（Connection Termination）：
- 客戶端發(fā)送 FIN： 客戶端發(fā)送一個帶有 FIN（結(jié)束）標志的數(shù)據(jù)包，表示要關(guān)閉連接。
- 服務(wù)端發(fā)送 ACK： 服務(wù)端收到客戶端的關(guān)閉請求后，發(fā)送一個帶有 ACK 標志的數(shù)據(jù)包，表示接收到關(guān)閉請求。
- 服務(wù)端發(fā)送 FIN： 服務(wù)端發(fā)送一個帶有 FIN 標志的數(shù)據(jù)包，表示服務(wù)端也準備關(guān)閉連接。
- 客戶端發(fā)送 ACK： 客戶端收到服務(wù)端的關(guān)閉請求后，發(fā)送一個帶有 ACK 標志的數(shù)據(jù)包，表示確認關(guān)閉。此時連接徹底關(guān)閉。
這樣的握手和揮手機制確保了雙方在建立和關(guān)閉連接時的可靠性和同步性。
7）TCP粘包是怎么回事，如何處理?
TCP粘包是指發(fā)送方發(fā)送的若干小數(shù)據(jù)包到達接收方時，接收方可能會將它們合并成一個大的數(shù)據(jù)包，從而導致接收方處理時難以區(qū)分原始的數(shù)據(jù)邊界。這可能會引發(fā)一些問題，比如數(shù)據(jù)解析錯誤或應(yīng)用層處理混亂。
原因：
- 緩沖機制： 操作系統(tǒng)或中間網(wǎng)絡(luò)設(shè)備的緩沖機制可能會導致多個小數(shù)據(jù)包在傳輸過程中被合并成一個大的數(shù)據(jù)包。
- 發(fā)送速率： 發(fā)送方連續(xù)發(fā)送數(shù)據(jù)包的速率比接收方處理的速率快，導致多個數(shù)據(jù)包在傳輸過程中組成一個大的數(shù)據(jù)包。
處理方法：
- 消息長度標識： 在傳輸?shù)臄?shù)據(jù)中增加消息長度的信息，接收方通過解析長度信息來拆分數(shù)據(jù)。
- 特殊字符標識： 在消息之間增加特殊字符標識，接收方根據(jù)特殊字符來切分數(shù)據(jù)。
- 定長消息： 固定長度的消息，不足長度時用空格或其他填充。
- 使用消息邊界標記： 在數(shù)據(jù)包的開頭或結(jié)尾添加標記表示消息的開始或結(jié)束。
- 應(yīng)用層協(xié)議設(shè)計： 在應(yīng)用層設(shè)計協(xié)議時，可以采用更復雜的協(xié)議規(guī)定來避免粘包問題。
8）為什么udp不會粘包？
UDP是無連接的、不可靠的協(xié)議，它對數(shù)據(jù)包的傳輸不做任何拆分或合并的處理，因此不存在TCP粘包的問題。每個UDP數(shù)據(jù)包都是獨立的，不會受到底層協(xié)議的影響而被合并，接收方能夠按照發(fā)送方發(fā)送的數(shù)據(jù)包一一接收。
UDP的簡單性和無連接性使得它不會進行復雜的緩沖和組包操作，也就不會出現(xiàn)TCP粘包的情況。然而，正因為UDP不保證可靠傳輸，應(yīng)用層需要自行處理丟包、重復和順序等問題。
9）對 WebSocket 的理解
WebSocket是一種在單個TCP連接上進行全雙工通信的協(xié)議，它允許客戶端和服務(wù)器之間進行實時、雙向的數(shù)據(jù)傳輸。相比于傳統(tǒng)的HTTP協(xié)議，WebSocket的優(yōu)勢在于降低了通信的延遲，提高了效率。
特點和優(yōu)勢：
- 全雙工通信： 可以同時在同一個連接上進行雙向通信，服務(wù)器可以向客戶端推送數(shù)據(jù)，而不需要等待客戶端的請求。
- 低延遲： 由于建立一次連接后可以持久存在，避免了HTTP協(xié)議中頻繁的連接建立和斷開，降低了通信的延遲。
- 輕量級： WebSocket協(xié)議的頭部較小，通信時的數(shù)據(jù)幀相對較小，減少了網(wǎng)絡(luò)傳輸?shù)拈_銷。
- 跨域通信： 支持跨域通信，通過一定的握手過程建立連接，使得客戶端和服務(wù)器可以跨域進行實時通信。
10）即時通訊的實現(xiàn)：短輪詢、長輪詢、SSE 和 WebSocket 間的區(qū)別？
即時通訊的實現(xiàn)方式有多種，其中常見的包括短輪詢（Short Polling）、長輪詢（Long Polling）、SSE（Server-Sent Events）和WebSocket。
-
短輪詢（Short Polling）：
- 客戶端定期發(fā)送HTTP請求詢問是否有新消息。
- 服務(wù)器響應(yīng)時，返回當前可用的消息。
- 缺點：頻繁的HTTP請求可能造成不必要的開銷，延遲高。
-
長輪詢（Long Polling）：
- 客戶端發(fā)送HTTP請求到服務(wù)器，服務(wù)器保持連接打開，直到有新消息才響應(yīng)給客戶端。
- 客戶端收到響應(yīng)后立即再次發(fā)起請求。
- 缺點：仍然存在較高的延遲，但相較于短輪詢減少了請求的頻率。
-
SSE（Server-Sent Events）：
- 使用單個HTTP連接，服務(wù)器可以主動推送數(shù)據(jù)給客戶端。
- 基于事件流的機制，通過EventSource對象在客戶端接收服務(wù)器的推送。
- 缺點：僅支持單向通信，不適合需要雙向通信的場景。
-
WebSocket：
- 建立在單個TCP連接上，支持全雙工通信。
- 通過握手過程建立連接，之后可以雙向發(fā)送消息。
- 優(yōu)點：低延遲，支持雙向通信，適用于實時性要求高的場景。
總的來說，短輪詢和長輪詢通過HTTP請求，存在較高的延遲和開銷；SSE是基于HTTP的單向通信，適用于服務(wù)器向客戶端推送數(shù)據(jù)；WebSocket是全雙工通信，延遲低，適用于實時性要求高的即時通訊場景。選擇哪種方式取決于具體的需求和場景。
開源項目地址：https://gitee.com/falle22222n-leaves/vue_-book-manage-system
已 300 + Star！文章來源：http://www.zghlxwxcb.cn/news/detail-826002.html
?點贊?收藏?不迷路！?
到了這里，關(guān)于面試計算機網(wǎng)絡(luò)框架八股文十問十答第七期的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
