type
Post
status
Published
date
Oct 12, 2025
slug
network4
summary
tags
技术探索
category
icon
password
引言在复杂的互联网中，底层的物理网络其实是非常“不靠谱”的，丢包、乱序、拥堵简直是家常便饭。但我们在下载文件、浏览网页时，却几乎从未遇到过数据损坏的问题。这一切都要归功于传输层的“定海神针”——TCP 协议。今天，我用最通俗的“大白话+图解”，扒一扒 TCP 的四大核心机制。
一、 确认应答与超时重传：TCP 的“兜底防线”
这是 TCP 实现可靠性的最底层逻辑，通过序列号（Sequence Number）和确认应答（ACK）机制，保证了数据的不丢、不重、不乱序。
二、 滑动窗口：用“空间换时间”的效率引擎
如果寄一个包裹，必须等收到回执才能寄下一个（停等协议），那传输效率简直惨不忍睹。为了解决效率问题，TCP 引入了滑动窗口（Sliding Window）机制。
滑动窗口运作原理图解：
(注：当左侧绿色的“ACK”到达时，蓝色的“窗口区域”整体向右滑动，原本不能发送的红色区域就会进入蓝色区域，变成允许发送状态。)
三、 流量控制：保护接收方的“安全阀”
发送方如果性能太强，发得太快怎么办？这就需要端到端的流量控制（Flow Control）。
流量控制确保了发送方的发送速度，严格受限于接收方的实际处理能力，防止把接收方“撑死”。
四、 拥塞控制：保护全网的“智能调度”
流量控制只顾及了“发送方”和“接收方”两端，但没考虑“中间的公路（网络链路）”堵不堵。如果早高峰大塞车，大家还拼命发包裹，整个网络会直接瘫痪。拥塞控制就是 TCP 根据当前的网络路况，智能踩油门和刹车的机制。
拥塞控制主要包含四个阶段算法，下面结合折线图来理解：
【四大阶段全解析】
- 慢启动（轮次 1~5）： 刚上路不知道路况多堵，先发1个包裹试探，没问题发2个，没问题发4个。拥塞窗口（
cwnd）呈指数级（$2^n$）猛踩油门增长。
- 拥塞避免（轮次 5~9）： 速度加到一定程度（达到了慢启动阈值
ssthresh），不能再狂踩油门了，变成每次只加1个，进入线性巡航状态。
- 快速重传（轮次 9 突降）： 如果突然发现前面的车急刹车（即发送方连续收到了 3 个重复的 ACK），说明网络轻度拥塞导致了丢包，不等超时了，立刻重传丢失的包。
- 快速恢复（轮次 10之后）： 既然只是轻度拥塞，就不像超时重传那样直接把速度跌到0重开，而是把阈值直接减半（例如图中的20减半为10），然后从新的阈值开始继续线性增长。
五、 总结：四大机制的协作博弈
为了方便记忆，我们将这四大核心机制总结为一张对比表：
机制名称 | 核心机制与手段 | 解决的核心问题 | 大白话比喻 |
确认应答与
超时重传 | 序列号 + ACK + 定时器(RTO) | 【基础兜底】
解决网络丢包、乱序问题。 | 寄挂号信，没收到回执就再寄一次。 |
滑动窗口 | 批量发送 + 累计确认 | 【效率提升】
解决停等协议效率低下的问题。 | 从“零售”升级为“搞批发”。 |
流量控制 | 接收窗口大小反馈 ( rwnd) | 【保护接收方】
防止发送方过快导致缓冲区溢出。 | 告诉对方“我仓库满了，发慢点”。 |
拥塞控制 | 拥塞窗口 ( cwnd)
慢启动/拥塞避免/快重传等 | 【保护全网络】
防止整个网络链路过载瘫痪。 | 遇早高峰堵车，全网司机动态调速。 |
💡 终极思考：发送方到底以什么速度发数据？
这四个机制不是孤立运行的。在实际传输中，发送方最终的发送速度，实际上受限于：
min(接收方反馈的窗口 rwnd, 当前网络拥塞窗口 cwnd)TCP 的设计哲学就在于此：在保证极端可靠（超时重传）的前提下，通过局部博弈（流量控制）和全局博弈（拥塞控制），在危机四伏的网络世界中，探寻传输效率的极限值。
分享