計算機網絡(三)傳輸層TCP

目錄

一、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狀態,證明連接已可靠建立。

  1. 第一次握手(客戶端主動出擊)??

    客戶端從?CLOSE?進入?SYN_SEND?狀態、發送報文:SYN=1, SEQ=100
  2. ??第二次握手(服務端雙響應)??

    • 服務端從?LISTEN?進入?SYN_RCVD?狀態
    • 回復報文:
      • SYN=1, ACK=1:同意連接 + 確認收到客戶端SYN
      • SEQ=200:服務端數據從200開始編號
      • ACK_NUM=101:期望下次收到客戶端序號101的數據
  3. ??第三次握手(客戶端最終確認)?

    ??注意:必須等待客戶端最終確認??(第三次握手),才能確保雙向通信能力。

    • 客戶端發送:ACK=1, ACK_NUM=201(200+1)、第三次握手只需ACK確認
    • 雙方進入?ESTABLISHED?狀態,連接正式建立
面試常問:為什么不是2次、不是4次?

(1)兩次握手的缺陷?

  1. 歷史重復連接:若客戶端第一次發送的SYN=100因網絡延遲未到達,超時重發SYN=101并完成通信后關閉連接,舊的SYN=100突然到達服務端,服務端會誤認為新請求并建立無用連接,但客戶端實際已關閉,導致服務端資源浪費(半開連接)
  2. 單向連接風險:服務端無法確認客戶端是否收到自己的SYN-ACK(客戶端可能已崩潰),導致服務端資源浪費

(2) 四次握手的多余性
三次握手已能達成目的,第三次握手客戶端發送ACK確認服務器的SYN+ACK,此時雙向連接已確認雙方都能正常收發數據,四次握手是多余的

  1. 無實際意義:TCP是全雙工協議,第三次握手的ACK=1;ACK_NUM=200+1已完全確認雙向連接。
  2. 效率降低??:額外交互增加延遲,但未提升可靠性。

(2)四次揮手(斷開連接)

關鍵字:

FIN=1??:終止連接標志(類似說“我要掛了”)

??ACK=1??:確認標志(回應“知道了”)

1、為什么需要四次揮手???

??TCP全雙工特性??:雙方需獨立關閉兩個方向的連接:

  1. ??第一次揮手??:客戶端→服務端方向關閉(發FIN
  2. ??第二次揮手??:服務端確認客戶端的FIN(回ACK
  3. ??第三次揮手??:服務端→客戶端方向關閉(發FIN
  4. ??第四次揮手??:客戶端確認服務端的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、流量控制

防止發送方數據發送速率超過接收方處理能力,避免:

  1. 接收方緩沖區溢出導致丟包
  2. 觸發不必要的重傳(浪費網絡資源)

swnd:min(cwnd,rwnd)

swnd:發送窗口

cwnd:擁塞窗口(變化規則:網絡中沒有擁塞則cwnd變大,反之變小)

rwnd:接收窗口(接收方告知發送方當前可用的緩沖區空間(單位:字節)、動態調整)

如果一直無腦的發送數據給對方,但是對方處理不過來,就會導致觸發重發機制,造成網絡浪費

為了解決這種現象發生,TCP提供一種機制可以讓「發送方」根據「接收方」的實際接收能力控制發送的數據量,這就是所謂的流量控制

TCP通過使用一個接收窗口(receive window)的變量來提供流量控制。接收窗口會給發送方一個指示到底還有多少可用的緩存空間。發送端會根據接收端的實際接受能力來控制發送的數據量。

接收端主機向發送端主機通知自己可以接收數據的大小,發送端會發送不超過這個限度的數據,這個大小限度就是窗口大小,(TCP的首部,有一個接收窗口,我們上面聊的時候說這個字段用于流量控制。它用于指示接收方能夠/愿意接收的字節數量)

發送端主機會定期發送一個窗口探測包,這個包用于探測接收端主機是否還能夠接受數據,當接收端的緩沖區一旦面臨數據溢出的風險時,窗口大小的值也隨之被設置為一個更小的值通知發送端,從而控制數據發送量。

2、擁塞控制

TCP的??擁塞控制??用于防止發送方的數據填滿整個網絡(而流量控制僅關注接收方緩存)。核心機制是??擁塞窗口(cwnd)??,它是發送方動態調整的變量,根據網絡擁塞程度變化:

  1. ??窗口關系??:發送窗口(swnd)取擁塞窗口(cwnd)和接收窗口(rwnd)的最小值(swnd = min(cwnd, rwnd))。
  2. ??調整規則??:
    • 無擁塞時增大cwnd
    • 有擁塞時減少cwnd
  3. ??擁塞判定??:若發送方未按時收到ACK(觸發超時重傳),則認為網絡擁塞。

TCP通過這種機制主動犧牲發送速率,避免網絡陷入惡性循環(丟包→重傳→更擁堵)。

TCP擁塞控制三種算法:

慢啟動(探測帶寬)→ 擁塞避免(線性保守)→ 快速恢復(快速調整)???

(1)慢啟動

慢啟動是TCP擁塞控制的初始階段,用于動態探測網絡可用帶寬。其核心規則如下:

  1. ??初始窗口??:建立連接時,擁塞窗口(cwnd)初始化為 ??1個MSS??(最大報文段大小)。
  2. ??指數增長??:每收到一個ACK確認,cwnd增加1個MSS,導致窗口大小按輪次??指數級增長??(1→2→4→8…)。
  3. ??發送速率??:初始發送速率約為?MSS/RTT(例如:MSS=1000字節,RTT=200ms,則初始速率為40kb/s)。

ssthresh(慢啟動閾值)
當cwnd<ssthresh時;使用慢啟動算法;
當cwnd>ssthresh時;停止使用慢啟動算法,使用擁塞避免算法;
當cwnd=ssthresh時;既可以使用慢啟動算法,又可以使用擁塞避免算法;

(2) 擁塞避免?
  • ??觸發條件??:cwnd ≥ ssthresh
  • ??增長規則??:每經過一個RTT(往返時間),cwnd???線性增加1個MSS??(而非指數增長)。
  • ??目的??:減緩窗口增長速率,避免網絡過載。
  • ??擁塞響應??:若發生超時重傳,則:
    1. ssthresh設為當前cwnd的一半;
    2. 重置cwnd = 1,重新進入慢啟動。
(3)快速啟動?
  • ??觸發條件??:收到 ??3個重復ACK??(表明部分數據包丟失,但網絡仍可傳輸)。
  • ??核心操作??:
    1. ??乘法減小??:將ssthresh降為cwnd/2
    2. ??加法增大??:cwnd = ssthresh + 3 MSS(因3個重復ACK表明3個數據包已到達);
    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告訴發送方哪些數據被重復接收了

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/web/87264.shtml
繁體地址,請注明出處:http://hk.pswp.cn/web/87264.shtml
英文地址,請注明出處:http://en.pswp.cn/web/87264.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

Spring、SpringBoot 本身為什么不提供 Bean 的異步初始化

這是一個很有深度的架構問題&#xff01;Spring/Spring Boot 本身為什么不直接提供 Bean 的異步初始化&#xff1f; 下面從原理、歷史、設計哲學、技術挑戰、社區現狀等多個層面為你詳細分析。 一、Spring Bean 初始化的默認行為 Spring IoC 容器在啟動時&#xff0c;會同步地…

第十三節:Vben Admin 最新 v5.0 (vben5) + Python Flask 快速入門 - 接口操作審計日志功能

Vben5 系列文章目錄 ?? 基礎篇 ? 第一節:Vben Admin 最新 v5.0 (vben5) + Python Flask 快速入門 ? 第二節:Vben Admin 最新 v5.0 (vben5) + Python Flask 快速入門 - Python Flask 后端開發詳解(附源碼) ? 第三節:Vben Admin 最新 v5.0 (vben5) + Python Flask 快速入…

AI掌柜失守記:AI Agent商業自動化邊界實驗

1. 實驗設計&#xff1a;數字掌柜接管實體貨架 1.1 硬件載體與虛擬人格構建 位于舊金山的實驗場地被改造成微型零售生態系統&#xff1a;智能冰箱搭配商品籃構成實體貨架&#xff0c;iPad自助結賬系統連接Venmo支付接口&#xff0c;Slack通訊平臺成為人機交互窗口。Claude So…

NAT 打洞

本文基于NAT3NAT3實現upd打洞&#xff08;假設你對NAT類型已經很清楚&#xff09; 如果A網絡的NATAB網絡的NATB的值大于6則打洞會失敗&#xff0c;需要使用turn中繼服務 STUN協議解析 #pragma once #include "hv/UdpClient.h" #include "fmt/format.h" /*…

java近期工作總結

近期工作中的一些總結 &#xff08;1&#xff09;三層模板和流程 我發現很多東西其實吧&#xff0c;三層就是一個模板和流程&#xff1b; 正向推&#xff0c;從控制層開始&#xff0c;反向從內個sql開始寫&#xff0c;大部分應該就是從xml文件開始的&#xff0c;然后寫到控制層…

vue中的torefs

在 Vue 中&#xff0c; toRefs(state) 的返回值是一個 新對象&#xff0c;其中每個屬性都是對應 state 中原始屬性的 ref 對象。具體來說&#xff1a; 返回值的結構與特性 1. 對象結構 - 若輸入 state 為 { a: 1, b: text } &#xff0c;則 toRefs(state) 返回&a…

可編程邏輯器件的演進與對比分析

可編程邏輯器件的演進與對比分析 目錄 離散邏輯芯片與早期PLD的限制CPLD的誕生與結構特點FPGA的架構創新CPLD與FPGA的核心差異總結 1. 離散邏輯芯片與早期PLD的限制 在還沒有發明出可編程邏輯器件&#xff08;PLD: Programmable Logic Device&#xff09;之前&#xff0c;設…

Ubuntu機器開啟root用戶遠程登錄

一般正常情況是可以直接使用非root用戶登錄&#xff0c;但是由于權限問題&#xff0c;所以部分內容需要遠程ROOT用戶登錄&#xff0c;具體如下&#xff1a; 1??配置root用戶密碼 一般情況下系統中root不能直接登錄&#xff0c;所以也沒有保存root密碼&#xff0c;現在需要登…

rockchip android14 設置不休眠

rockchip android14 設置不休眠 文章目錄 rockchip android14 設置不休眠前言一、代碼路徑二、代碼修改前言 在rk 的android14代碼中設置開機后永不休眠 一、代碼路徑 device/rockchip/common/overlay/frameworks/base/packages/SettingsProvider/res/values/defaults.xml二、…

什么是數據孤島?如何解決數據孤島問題?

目錄 一、數據孤島的定義與表現 1. 數據孤島的定義 2. 數據孤島的表現形式 二、數據孤島產生的原因 1. 技術層面 2. 組織管理層面 3. 業務流程層面 三、數據孤島帶來的危害 1. 對企業決策的影響 2. 對業務運營效率的影響 3. 對數據治理和安全的影響 四、解決數據孤…

自定義Cereal XML輸出容器節點

自定義Cereal XML輸出容器節點 CEREAL_SERIALIZE_INTRUSIVE 在 1.優化Cereal宏 一行聲明序列化函數 QString、QVector、QList、QMap序列化在2.在Cereal中支持Qt容器序列化 靜態成員函數type_node檢測在 3.利用SFINAE檢測成員函數 &#x1f680; 告別value0&#xff1a;自定義Ce…

Spark 寫入hive表解析

FileOutputCommitter中提交mapreduce.fileoutputcommitter.algorithm.version有v1和v2兩個版本。 v1版本Spark寫入文件的流程&#xff1a; 1.當task完成的時候&#xff0c;會將task的結果文件先寫入到臨時目錄下面。 2.所有的task完成后&#xff0c;將所有的結果文件寫入到結…

Linux云計算基礎篇(5)

一、sudo是什么&#xff1f; 定義&#xff1a;sudo(SuperUserDO)是一個Linux/Unix系統命令&#xff0c;允許被授權的普通用戶以另一個用戶&#xff08;通常是超級用戶root&#xff09;的身份執行命令。 核心目的&#xff1a; 1.最小權限原則&#xff1a;避免讓用戶長期擁有ro…

Postgresql通過pgpool進行高可用部署主從,災備(單機版)

1、bitnami/postgresql-repmgr:15 &#xff08;鏡像名&#xff09; Bitnami 的 PostgreSQL-Repmgr 鏡像是一個預配置的 Docker 鏡像&#xff0c;集成了 PostgreSQL 數據庫和 repmgr&#xff08;Replication Manager&#xff09;工具&#xff0c;用于快速搭建高可用&#xff08…

Flink-1.19.0源碼詳解-番外補充3-StreamGraph圖

1.StreamGraph圖: StreamGraph是Flink流處理作業的第一個計算調度流圖&#xff0c;它是從用戶編寫的 DataStream API程序轉換而來的邏輯圖。StreamGraph由StreamNode與StreamEdge組成&#xff0c;StreamNode為記錄數據處理的節點&#xff0c;StreamEdge為連接兩個StreamNode的邊…

linux系統---Nginx反向代理與緩存功能

目錄 正向代理和反向代理 正向代理的作用 反向代理可實現的功能 反向代理客戶端ip透傳 1.初始訪問192.168.235.139 結果 2.編輯代理服務器的配置文件 3、重載nginx服務 4、訪問代理服務器 實現反向代理負載均衡 1.先啟用已用另一臺服務端 2.使用192.168.235.140 …

U+平臺配置免密登錄、安裝Hadoop配置集群、Spark配置

文章目錄 1、免密登錄2、安裝hadoop3、Spark配置 具體詳細報告見資源部分&#xff0c;全部實驗內容已經上傳&#xff0c;如有需要請自行下載。 1、免密登錄 使用的配置命令&#xff1a; cd ~/.ssh/ssh-keygen -t rsaEnter鍵回車y回車回車出現如上所示 cat ./id_rsa.pub >…

GitHub vs GitLab 全面對比報告(2025版)

從技術架構到金融估值&#xff0c;深度解析兩大代碼托管平臺的差異化競爭策略 一、技術架構對比 維度GitHub (Microsoft旗下)GitLab (獨立上市公司)關鍵差異核心架構- 分布式Git倉庫 Issues/Projects- 全棧DevSecOps平臺GitLab集成CI/CD、安全、監控部署模式- SaaS為主 - Git…

Python 數據分析與可視化 Day 14 - 建模復盤 + 多模型評估對比(邏輯回歸 vs 決策樹)

? 今日目標 回顧整個本周數據分析 & 建模流程學會訓練第二種模型&#xff1a;決策樹&#xff08;Decision Tree&#xff09;掌握多模型對比評估的方法與實踐輸出綜合對比報告&#xff1a;準確率、精確率、召回率、F1 等指標為后續模型調優與擴展打下基礎 &#x1fa9c; 一…

本周大模型新動向:KV緩存混合精度量化、個體時空行為生成、個性化問答

點擊藍字 關注我們 AI TIME歡迎每一位AI愛好者的加入&#xff01; 01 KVmix: Gradient-Based Layer Importance-Aware Mixed-Precision Quantization for KV Cache 大型語言模型&#xff08;LLMs&#xff09;在推理過程中&#xff0c;鍵值&#xff08;KV&#xff09;緩存的高內…