用户说："我 200G 的线路，上传视频文件怎么只有几 M？"后台一查，链路没丢包、光衰正常，但上行丢包率------8%。TCP 检测到丢包就"踩刹车"，把速度从几百 Mbps 一路打到几 Mbps。今天就把 TCP 的"又稳又防撞"驾驶技术讲透：它凭什么保证"不丢不漏"，又是怎么自动调速的。
一、可靠性的三块基石：序号 + 确认 + 重传
TCP 面对的现实是：底层线路会丢包、会乱序、会重复。它要在这上面保证"发送的字节一个不多、一个不少、顺序不变"地到达。靠的就是三件套：
| 机制 | 干什么 | 类比 |
|---|---|---|
| 序号（SEQ） | 给每个字节编号，接收端按号拼装、查漏 | 快递单号 |
| 确认（ACK） | 收方告诉发方"你发到第几号了" | 签收回执 |
| 重传 | 超时没回执就补发 | 没签收就再寄一次 |
三者配合：发方给数据编号寄出，收方按号签收并回报，发方发现没签收就重发------不重不漏就这么实现了。
二、滑动窗口：从"一件一件寄"到"流水线发货"
如果真的一件件等确认再发下一件，速度太慢。TCP 用的是滑动窗口：一次允许一批数据"在路上"，不用等每一件的确认。
- 发送窗口：发方允许"在途未确认"的数据量上限，窗口内的数据随确认到来不断"向前滑动"；
- 接收窗口：收方告诉发方"我还能收多少"，用于流量控制（接收方处理不过来就减小窗口，逼发方放慢）。
打个比方：窗口 = 允许同时"在高速上跑"的车数量。路况好、对方吞吐快，窗口就大；丢包了、对方处理不过来，窗口就缩。
小窍门 ：网速"先快后慢"或者"跑不满"，很多时候不是带宽不够，而是窗口没撑开（延迟高时窗口需要更大才能跑满带宽）。
三、重传的两种姿势：超时重传 vs 快速重传
① 超时重传（Timeout）：发出去后，超过重传超时（RTO）没收到 ACK 就重发。缺点是可能要白等很久。
② 快速重传（Fast Retransmit） ：不用等超时------接收方连续收到 3 个重复 ACK（一直说"我还在等第 N 号"），发方立刻知道第 N 号丢了，马上补发。这是现代 TCP 的主力。
SACK（选择性确认） 再进一步：收方明确告诉发方"哪些到了、缺哪些"，发方只重传缺的那几段，而不是整段重来------就像寄了 100 件货丢了一件，只补那一件。
四、拥塞控制：在"快"和"稳"之间自动找平衡
TCP 不能光自己快，还得考虑整条路径 的承载能力------这就是拥塞控制。它通过一个"拥塞窗口（cwnd）"来感知并控制流量，整个过程分三个阶段：
- 慢启动（Slow Start）：刚开始像"试水温"，窗口从 1 开始指数翻倍，快速探测网络上限；
- 拥塞避免（Congestion Avoidance）：达到阈值后改为线性增长，不再激进；
- 快恢复（Fast Recovery）：一旦丢包（网络拥堵信号），窗口砍半甚至回 1，再慢慢爬回来。
一句话：TCP 的发送速度不是固定的，而是跟着网络的"脸色"走------没丢包就试探加速，一丢包就果断减速。这就是为什么丢包率高时，你网速会"断崖式"下降：不是运营商限速，是 TCP 自己在保护网络。
五、装维视角：丢包排障三板斧
① 看丢包率 ：ping -n 100 目标看 loss%；或更精确用 MTR（WinMTR） 逐跳看，能定位丢包发生在哪一跳。
② 区分"丢包"与"假丢包" ：有些设备在 ping 流量高时不回显（优先处理数据包），会显示"丢包"但实际业务没影响------用 TCP 建连测试（curl 重复请求）验证真实连通性。
③ 丢包高了怎么办：先分责任（有线直连 vs WiFi、多时段对比），排除家里设备；再逐跳定位，是运营商的某段链路拥塞就报障；对外海外的丢包，换优质线路/加速服务都是思路。
小结
- 可靠性 = 序号 + 确认 + 重传，滑动窗口让"一边等确认一边发"成为流水线；
- 快速重传 + 选择性确认，把"重发损失"降到最低；
- 拥塞控制让 TCP 学会看脸色开车：慢启动试水温、丢包即减速------丢包率高时网速变慢，是协议在"自我保护"。
思考题：内网直连两台电脑传大文件，延迟只有 1ms，但速度只有 20MB/s。网卡、网线都正常。问题可能出在哪？（提示：先想"窗口"------延迟低窗口却小，可能是接收缓冲默认值没调大；再想"单流"------TCP 单流参数是否有瓶颈。）
下期预告
TCP 又稳又智能，代价是"开销大、慢半拍"------实时视频、语音、游戏要的是快，它不总能跟上。明天开讲：UDP 与 QUIC------为什么视频会议不卡，是它俩的功劳。