文章目錄
- 昨日內容復習
- 已經建立了 TCP 連接，客戶端突然出現故障怎么辦？
- 什么時候用長連接？短連接？
- TCP 的半連接隊列與全連接隊列？
- 什么是 SYN 攻擊？如何避免？
- TIME_WAIT 的作用？過多如何解決？
- TIME_WAIT 為什么要經過兩個 MSL？
- CLOSE_WAIT 狀態過多如何解決？
- 復習計算機網絡 Day4：TCP 協議的其他相關問題
- TCP 和 UDP 的區別？
- TCP 傳輸時出現粘包問題應該如何解決？
- TCP 的 keepalive 和 HTTP 的 keepalive 的區別？
- IP 層可以對較長的報文進行分片，為什么 TCP 層還需要 MSS？
昨日內容復習
已經建立了 TCP 連接，客戶端突然出現故障怎么辦？
服務端不會一直等待。服務端會為每一條 TCP 連接設置一個保活計時器（時長通常是兩個小時），每當客戶端傳來數據，服務端會重置計時器。如果保活計時器時間到，那么服務端每隔一定時間發送一個探測報文，連續發送十個探測報文仍然收不到客戶端的回復，那么服務端終止與客戶端的連接。
什么時候用長連接？短連接？
- 長連接用于頻繁通信的點對點通訊，并且長連接的個數不能太多。數據庫的連接就是長連接的一種。
- HTTP 服務一般使用短連接，可快速釋放。
TCP 的半連接隊列與全連接隊列？
- 半連接隊列：又稱 SYN 隊列，服務端會保存發送 SYN 請求報文請求連接的客戶端的信息，并向客戶端發送 SYN-ACK 報文。
- 全連接隊列：又稱 ACCEPT 隊列。服務端回發的 SYN-ACK 報文得到 ACK 報文確認后，就會將 SYN 隊列中的客戶端移出隊列，建立 TCP 連接并加入到全連接隊列當中。
什么是 SYN 攻擊？如何避免？
服務端收到大量的惡意 SYN 請求報文，會不停地回發 SYN-ACK 報文，得不到 ACK 確認報文，會觸發超時重傳，此時會導致服務端資源浪費。此外，服務端收到 SYN 報文后，可能會為該連接分配一個 TCB 進程控制塊，大量的惡意 SYN 請求會導致服務端資源枯竭。
避免方法包括但不限于以下幾種：
- TCP 連接建立后再分配 TCB；
- 減少 SYN-ACK 的重傳次數；
- 監視 SYN 隊列和 ACCEPT 隊列中的無效連接，及時清除；
- 擴大 SYN 隊列；
TIME_WAIT 的作用？過多如何解決？
- 確保主動關閉方發送的 ACK 報文到達被動關閉方，從而確保全雙工通道的可靠關閉；
- 等待網絡中因網絡擁塞而還沒有到達的報文在網絡中自然消失，避免對新連接產生干擾；
過多的 TIME_WAIT 會占用網絡與端口資源，導致新的連接無法建立。
解決辦法包括但不限于：
- 復用長連接；
- 調整 MSL 時間；
- 快速回收 TIME_WAIT。
TIME_WAIT 為什么要經過兩個 MSL？
- 第一個 MSL：確保 ACK 報文到達對端；
- 第二個 MSL：確保對端重傳的 FIN 到達本端；
2 MSL 還可確保舊報文在網絡中完全消亡。
CLOSE_WAIT 狀態過多如何解決？
CLOSE_WAIT 過多可能是應用程序層面產生的問題，應該對應用程序進行檢查。
復習計算機網絡 Day4：TCP 協議的其他相關問題
TCP 和 UDP 的區別？
- TCP 是面向連接的，連接建立時需要三次握手，斷開時需要四次揮手。UDP 不需要建立連接。
- TCP 是可靠傳輸服務，可確保傳輸數據無差錯。UDP 非可靠傳輸，盡最大努力交付。
- TCP 是點對點連接，UDP 可以通過多對一、一對多、多對多等方式通訊。
- UDP 對系統資源的要求比較少，通訊效率高，實時性好。TCP 適用于需要可靠連接，比如付費、加密數據等場景。
- TCP 首部長度較長，有一定開銷，在沒有額外選項時 TCP 頭部的長度占 20 字節。UDP 首部長度只有 8 字節，沒有額外長度。
- TCP 進行流式傳輸，沒有數據邊界。UDP 基于數據包傳輸，可能會丟包與亂序。
- TCP 數據的大小如果大于 MSS，則會在傳輸層進行分片。對端收到數據分片后會在傳輸層進行組裝。中間如果發生丟包，傳輸方會重傳丟失的分片。UDP 數據的大小取決于 MTU 的大小，會在 IP 層分片，對端收到數據后，會在 IP 層組裝。
- 應用場景：TCP 可用于 FTP 文件傳輸；UDP 用于包總量較少的通信，比如 DNS、SNMP 等。視頻、音頻等多媒體通信以及廣播通信也可用 UDP 實現。
TCP 傳輸時出現粘包問題應該如何解決？
在數據的頭部指定當前數據包的數據長度，由應用層根據數據長度來分包拆包。粘包是需要在應用層解決的問題。
TCP 的 keepalive 和 HTTP 的 keepalive 的區別？
- HTTP 的 keepalive 是由應用層（用戶態）實現的，稱為 HTTP 長連接。而 TCP 的 keepalive 是由傳輸層（內核態）實現的，稱為 TCP 保活機制。
- HTTP 的 keepalive 與 TCP 的 keepalive 作用不同。TCP 的 keepalive 用于探測對端是否仍然在線。而 HTTP 的 keepalive 用于避免重復建立/斷開 TCP 連接，減少 TCP 連接建立與斷開時的開銷。
IP 層可以對較長的報文進行分片，為什么 TCP 層還需要 MSS？
- MTU：一個網絡包的最大長度，在以太網中一般 1500 字節；
- MSS：去除 IP 和 TCP 報文頭部后，一個網絡包中可以容納的 TCP 數據部分的最大長度。
IP 層雖然可以對報文進行分片，但是存在以下問題，TCP 中 MSS 的提出就是為了解決下述問題：
性能消耗
- 重組開銷：IP 層分片傳輸的報文需要在接收端進行重組，消耗 CPU /內存資源。
- 重傳開銷：如果傳輸過程中任意 IP 報文分片丟失，則整個報文都需要重傳。
可靠性風險
- 無分片狀態跟蹤：IP 是無狀態協議，無法感知分片是否全部到達。
- 防火墻 / NAT 干擾：部分網絡設備會丟棄分片報文，導致通信失敗。
路徑 MTU 發現（PMTUD）復雜性
- 動態路徑 MTU：網絡路徑中不同鏈路的 MTU 可能不同。
- PMTUD 失敗：若 ICMP 報文被屏蔽，PMTUD 可能會失敗。
