上网第三十九课：TCP 的可靠性——滑动窗口、重传与拥塞控制

用户说：“我 200G 的线路，上传视频文件怎么只有几 M？“后台一查，链路没丢包、光衰正常，但上行丢包率——8%。TCP 检测到丢包就"踩刹车”，把速度从几百 Mbps 一路打到几 Mbps。今天就把 TCP 的"又稳又防撞"驾驶技术讲透：它凭什么保证"不丢不漏”，又是怎么自动调速的。

一、可靠性的三块基石：序号 + 确认 + 重传

TCP 面对的现实是：底层线路会丢包、会乱序、会重复。它要在这上面保证"发送的字节一个不多、一个不少、顺序不变"地到达。靠的就是三件套：

三者配合：发方给数据编号寄出，收方按号签收并回报，发方发现没签收就重发——不重不漏就这么实现了。

二、滑动窗口：从"一件一件寄"到"流水线发货"

如果真的一件件等确认再发下一件，速度太慢。TCP 用的是滑动窗口：一次允许一批数据"在路上"，不用等每一件的确认。

• 发送窗口：发方允许"在途未确认"的数据量上限，窗口内的数据随确认到来不断"向前滑动"；
• 接收窗口：收方告诉发方"我还能收多少"，用于流量控制（接收方处理不过来就减小窗口，逼发方放慢）。

打个比方：窗口 = 允许同时"在高速上跑"的车数量。路况好、对方吞吐快，窗口就大；丢包了、对方处理不过来，窗口就缩。

小窍门：网速"先快后慢"或者"跑不满"，很多时候不是带宽不够，而是窗口没撑开（延迟高时窗口需要更大才能跑满带宽）。

三、重传的两种姿势：超时重传 vs 快速重传

① 超时重传（Timeout）：发出去后，超过重传超时（RTO）没收到 ACK 就重发。缺点是可能要白等很久。

② 快速重传（Fast Retransmit）：不用等超时——接收方连续收到 3 个重复 ACK（一直说"我还在等第 N 号"），发方立刻知道第 N 号丢了，马上补发。这是现代 TCP 的主力。

SACK（选择性确认） 再进一步：收方明确告诉发方"哪些到了、缺哪些"，发方只重传缺的那几段，而不是整段重来——就像寄了 100 件货丢了一件，只补那一件。

四、拥塞控制：在"快"和"稳"之间自动找平衡

TCP 不能光自己快，还得考虑整条路径的承载能力——这就是拥塞控制。它通过一个"拥塞窗口（cwnd）"来感知并控制流量，整个过程分三个阶段：

一句话：TCP 的发送速度不是固定的，而是跟着网络的"脸色"走——没丢包就试探加速，一丢包就果断减速。这就是为什么丢包率高时，你网速会"断崖式"下降：不是运营商限速，是 TCP 自己在保护网络。

五、装维视角：丢包排障三板斧

① 看丢包率：ping -n 100 目标看 loss%；或更精确用 MTR（WinMTR） 逐跳看，能定位丢包发生在哪一跳。

② 区分"丢包"与"假丢包"：有些设备在 ping 流量高时不回显（优先处理数据包），会显示"丢包"但实际业务没影响——用 TCP 建连测试（curl 重复请求）验证真实连通性。

③ 丢包高了怎么办：先分责任（有线直连 vs WiFi、多时段对比），排除家里设备；再逐跳定位，是运营商的某段链路拥塞就报障；对外海外的丢包，换优质线路/加速服务都是思路。

小结

• 可靠性 = 序号 + 确认 + 重传，滑动窗口让"一边等确认一边发"成为流水线；
• 快速重传 + 选择性确认，把"重发损失"降到最低；
• 拥塞控制让 TCP 学会看脸色开车：慢启动试水温、丢包即减速——丢包率高时网速变慢，是协议在"自我保护"。

思考题：内网直连两台电脑传大文件，延迟只有 1ms，但速度只有 20MB/s。网卡、网线都正常。问题可能出在哪？（提示：先想"窗口"——延迟低窗口却小，可能是接收缓冲默认值没调大；再想"单流"——TCP 单流参数是否有瓶颈。）

下期预告

TCP 又稳又智能，代价是"开销大、慢半拍"——实时视频、语音、游戏要的是快，它不总能跟上。明天开讲：UDP 与 QUIC——为什么视频会议不卡，是它俩的功劳。