目錄
一、TCP概述?
二、TCP三大核心特性
三、?對比UDP??
(1)TCP、UDP對比?
(2)TCP、UDP頭部格式:
(3)應用場景??
?四、TCP的三次握手、四次揮手
(1)三次握手(建立連接)?
面試常問:為什么不是2次、不是4次?
(2)四次揮手(斷開連接)
1、為什么需要四次揮手???
2、為什么TIME_WAIT的等待時間是2MSL
3、為什么需要TIME_WAIT狀態
五、TCP可靠傳輸性細解
1、流量控制
2、擁塞控制
TCP擁塞控制三種算法:
(1)慢啟動
(2) 擁塞避免?
(3)快速啟動?
3、重傳機制
(1)超時重傳
(2)快速重傳
一、TCP概述?
??所屬層級??:傳輸層
??核心角色??:為應用進程提供??端到端??的可靠通信服務
??關鍵特性:??
面向連接??(需先握手建立邏輯連接)
可靠傳輸??(確保數據不丟失、不重復、有序)
??基于字節流??(無邊界、有序的數據流)
二、TCP三大核心特性
面向連接、可靠傳輸、字節流
??特性?? | ??說明?? |
---|---|
??面向連接?? | 通信前需三次握手建立連接(邏輯鏈路) 僅支持一對一通信(不支持廣播/組播) |
??可靠傳輸?? | 超時重傳、確認應答(ACK) 流量控制(滑動窗口) 擁塞控制(慢啟動、擁塞避免) |
??字節流?? | 數據無固定邊界(如發送方寫10次,接收方可讀1次合并) ?嚴格保序(先發先到) |
三、?對比UDP??
(1)TCP、UDP對比?
對比項?? | ??TCP?? | ??UDP?? |
---|---|---|
??連接方式?? | 面向連接(需三次握手) | 無連接(直接發送數據) |
??服務對象?? | 一對一通信 | 支持一對一、一對多、多對多 |
??可靠性?? | 可靠傳輸(不丟、不重、有序) | 盡最大努力交付(不保證可靠性) |
??擁塞/流量控制?? | 有(滑動窗口、慢啟動等) | 無(即使網絡擁堵也不降速) |
??首部開銷?? | 較長(20字節起,選項字段可擴展) | 固定8字節(極簡) |
TCP像打電話??:需先撥號(握手),通話中確保對方聽清(可靠),掛斷前需告別(四次揮手)。
??UDP像發短信??:直接發送,不保證對方是否收到。
(2)TCP、UDP頭部格式:
TCP頭部:
UDP頭部:
(3)應用場景??
??TCP適用場景??:
? 需要可靠傳輸的服務:
FTP
(文件傳輸)、HTTP/HTTPS
(網頁瀏覽)、SMTP
(郵件發送)
??UDP適用場景??:
? 實時性或效率優先的服務:
DNS
(域名解析)、SNMP
(網絡管理)、視頻/音頻流(如Zoom、直播)、廣播/組播(如IPTV)
?四、TCP的三次握手、四次揮手
(1)三次握手(建立連接)?
目的??:確保通信雙方具備??雙向收發能力??,同步初始序列號(ISN)
握手流程:
一SYN帶SEQ,二SYN+ACK全都有,三ACK省字段!
三次交互后,雙方均進入ESTABLISHED
狀態,證明連接已可靠建立。
-
第一次握手(客戶端主動出擊)??
客戶端從?CLOSE
?進入?SYN_SEND
?狀態、發送報文:SYN=1, SEQ=100
-
??第二次握手(服務端雙響應)??
- 服務端從?
LISTEN
?進入?SYN_RCVD
?狀態 - 回復報文:
SYN=1, ACK=1
:同意連接 + 確認收到客戶端SYNSEQ=200
:服務端數據從200開始編號ACK_NUM=101
:期望下次收到客戶端序號101的數據
- 服務端從?
-
??第三次握手(客戶端最終確認)?
??注意:必須等待客戶端最終確認??(第三次握手),才能確保雙向通信能力。
- 客戶端發送:
ACK=1, ACK_NUM=201
(200+1)、第三次握手只需ACK確認 - 雙方進入?
ESTABLISHED
?狀態,連接正式建立
- 客戶端發送:
面試常問:為什么不是2次、不是4次?
(1)兩次握手的缺陷?
- 歷史重復連接:若客戶端第一次發送的
SYN=100
因網絡延遲未到達,超時重發SYN=101
并完成通信后關閉連接,舊的SYN=100
突然到達服務端,服務端會誤認為新請求并建立無用連接,但客戶端實際已關閉,導致服務端資源浪費(半開連接) - 單向連接風險:服務端無法確認客戶端是否收到自己的SYN-ACK(客戶端可能已崩潰),導致服務端資源浪費
(2) 四次握手的多余性
三次握手已能達成目的,第三次握手客戶端發送ACK確認服務器的SYN+ACK,此時雙向連接已確認雙方都能正常收發數據,四次握手是多余的
- 無實際意義:TCP是全雙工協議,第三次握手的
ACK=1;ACK_NUM=200+1
已完全確認雙向連接。 - 效率降低??:額外交互增加延遲,但未提升可靠性。
(2)四次揮手(斷開連接)
關鍵字:
FIN=1
??:終止連接標志(類似說“我要掛了”)
??ACK=1
??:確認標志(回應“知道了”)
1、為什么需要四次揮手???
??TCP全雙工特性??:雙方需獨立關閉兩個方向的連接:
- ??第一次揮手??:客戶端→服務端方向關閉(發
FIN
) - ??第二次揮手??:服務端確認客戶端的
FIN
(回ACK
) - ??第三次揮手??:服務端→客戶端方向關閉(發
FIN
) - ??第四次揮手??:客戶端確認服務端的
FIN
(回ACK
)
??如果合并第二次和第三次揮手??:服務端可能在發送ACK
后仍有數據要發送(如未傳完的文件),需延遲發送FIN
。圖中?CLOSE_WAIT
?狀態即為此設計(服務端處理剩余數據)。
2、為什么TIME_WAIT的等待時間是2MSL
關鍵詞:
??術語?? | ??含義?? | ??區別?? |
---|---|---|
??MSL?? | 報文最大生存時間,默認30秒(Linux) | 單位是時間(秒) |
??TTL?? | 數據報可經過的最大路由跳數(Time To Live),每經過一個路由器減1,到0丟棄 | 單位是跳數(次) |
??2MSL?? | TIME_WAIT狀態的等待時長 = 2 × MSL | 確保舊報文完全消失 |
??原因一:雙向報文消亡??
- 網絡中可能殘留發送方的數據包又要回應對方,一來一回最長需要2倍等待時間也就是
2×MSL
時間消亡。(TCP報文(含序列號、FIN/ACK標志)被封裝在IP數據包中傳輸)
??原因二:容錯重傳??
若最后一個ACK丟失,被動關閉方會重發FIN:客戶端在TIME_WAIT
期間收到重傳的FIN,會??重置2MSL計時器??并重發ACK。
3、為什么需要TIME_WAIT狀態
主動發起并關閉連接的一方??才有TIME_WAIT狀態
存在意義??:
1、避免相同四元組(源IP/端口 + 目標IP/端口)的延遲報文干擾新連接。
2、保證被動關閉方能收到最終ACK,正常關閉連接。
五、TCP可靠傳輸性細解
1、流量控制
防止發送方數據發送速率超過接收方處理能力,避免:
- 接收方緩沖區溢出導致丟包
- 觸發不必要的重傳(浪費網絡資源)
swnd:min(cwnd,rwnd)
swnd:發送窗口
cwnd:擁塞窗口(變化規則:網絡中沒有擁塞則cwnd變大,反之變小)
rwnd:接收窗口(接收方告知發送方當前可用的緩沖區空間(單位:字節)、動態調整)
如果一直無腦的發送數據給對方,但是對方處理不過來,就會導致觸發重發機制,造成網絡浪費
為了解決這種現象發生,TCP提供一種機制可以讓「發送方」根據「接收方」的實際接收能力控制發送的數據量,這就是所謂的流量控制。
TCP通過使用一個接收窗口(receive window)的變量來提供流量控制。接收窗口會給發送方一個指示到底還有多少可用的緩存空間。發送端會根據接收端的實際接受能力來控制發送的數據量。
接收端主機向發送端主機通知自己可以接收數據的大小,發送端會發送不超過這個限度的數據,這個大小限度就是窗口大小,(TCP的首部,有一個接收窗口,我們上面聊的時候說這個字段用于流量控制。它用于指示接收方能夠/愿意接收的字節數量)
發送端主機會定期發送一個窗口探測包,這個包用于探測接收端主機是否還能夠接受數據,當接收端的緩沖區一旦面臨數據溢出的風險時,窗口大小的值也隨之被設置為一個更小的值通知發送端,從而控制數據發送量。
2、擁塞控制
TCP的??擁塞控制??用于防止發送方的數據填滿整個網絡(而流量控制僅關注接收方緩存)。核心機制是??擁塞窗口(cwnd)??,它是發送方動態調整的變量,根據網絡擁塞程度變化:
- ??窗口關系??:發送窗口(swnd)取擁塞窗口(cwnd)和接收窗口(rwnd)的最小值(
swnd = min(cwnd, rwnd)
)。 - ??調整規則??:
- 無擁塞時增大
cwnd
; - 有擁塞時減少
cwnd
。
- 無擁塞時增大
- ??擁塞判定??:若發送方未按時收到ACK(觸發超時重傳),則認為網絡擁塞。
TCP通過這種機制主動犧牲發送速率,避免網絡陷入惡性循環(丟包→重傳→更擁堵)。
TCP擁塞控制三種算法:
慢啟動(探測帶寬)→ 擁塞避免(線性保守)→ 快速恢復(快速調整)???
(1)慢啟動
慢啟動是TCP擁塞控制的初始階段,用于動態探測網絡可用帶寬。其核心規則如下:
- ??初始窗口??:建立連接時,擁塞窗口(
cwnd
)初始化為 ??1個MSS??(最大報文段大小)。 - ??指數增長??:每收到一個ACK確認,
cwnd
增加1個MSS,導致窗口大小按輪次??指數級增長??(1→2→4→8…)。 - ??發送速率??:初始發送速率約為?
MSS/RTT
(例如:MSS=1000字節,RTT=200ms,則初始速率為40kb/s)。
ssthresh(慢啟動閾值)
當cwnd<ssthresh時;使用慢啟動算法;
當cwnd>ssthresh時;停止使用慢啟動算法,使用擁塞避免算法;
當cwnd=ssthresh時;既可以使用慢啟動算法,又可以使用擁塞避免算法;
(2) 擁塞避免?
- ??觸發條件??:
cwnd ≥ ssthresh
。 - ??增長規則??:每經過一個RTT(往返時間),
cwnd
???線性增加1個MSS??(而非指數增長)。 - ??目的??:減緩窗口增長速率,避免網絡過載。
- ??擁塞響應??:若發生超時重傳,則:
- 將
ssthresh
設為當前cwnd
的一半; - 重置
cwnd = 1
,重新進入慢啟動。
- 將
(3)快速啟動?
- ??觸發條件??:收到 ??3個重復ACK??(表明部分數據包丟失,但網絡仍可傳輸)。
- ??核心操作??:
- ??乘法減小??:將
ssthresh
降為cwnd/2
; - ??加法增大??:
cwnd = ssthresh + 3 MSS
(因3個重復ACK表明3個數據包已到達); - ??進入擁塞避免??:此后每收到一個重復ACK,
cwnd
增加1 MSS;若收到新ACK,則退出快速恢復,進入擁塞避免。
- ??乘法減小??:將
- ??目的??:快速調整窗口大小,減少因丟包導致的性能驟降。
3、重傳機制
(1)超時重傳
超過指定時間沒有收到對方的ACK應答報文,重新發送該數據
1、數據包丟失
2、確認應答丟失
每次超時重傳的的時候,下次的超時時間會設置到原來的兩倍。兩次超時就說明網絡差,別發了
(2)快速重傳
收到??3個重復ACK??(表明后續數據包已到達,但中間某個報文段丟失),就會立即重傳??丟失的報文段,不以時間為驅動,以數據為驅動重傳
工作流程:
- 發送方發出Seq1-5數據包
- Seq2丟失,接收方收到Seq3/4/5后仍返回Ack=2
- 發送方收到3個重復Ack=2后立即重傳Seq2
- 接收方收齊數據后返回Ack=6
SACK(選擇性確認):在TCP頭部選項字段添加SACK信息,接收方通過SACK告知已收到的數據段,發送方精確重傳確實丟失的數據段
Duplicate SACK:使用SACK告訴發送方哪些數據被重復接收了