1. 丢包恢复概述

各位同学好，我是这门课的主讲。在正式开始之前，我想先聊聊一个基础问题——网络丢包。你可能觉得丢包是个小概率事件，但我在一线摸爬滚打这么多年，可以负责任地告诉你：丢包是网络通信的常态，不是异常。

先说说丢包是怎么来的。说白了，数据包在网络上传输，就像快递在路上跑。路况不好、仓库爆满、司机开小差，包裹就可能丢。网络丢包的原因，我归纳为三类：

丢包的影响有多大？我举个例子。你在视频会议里看到对方画面卡成 PPT，声音断断续续——这背后大概率就是丢包在作祟。对于实时通信，丢包率超过 1% 就能明显感知；对于文件传输，丢包意味着重传，延迟直接翻倍。

核心观点：丢包恢复不是可选项，而是网络系统的必备能力。没有丢包恢复机制，任何上层应用都不可靠。

丢包恢复机制怎么分类？我个人习惯把它们分成三大流派。你想想看，丢包了怎么办？无非三种思路：

ARQ 是最朴素的想法。发送方发一个包，接收方收到后回一个 ACK。如果发送方没收到 ACK，就认为包丢了，重新发一次。

我在项目中遇到过一个问题：高延迟链路上，ARQ 的效率非常低。比如卫星链路，RTT 可能 500ms，重传一次就要等 1 秒。这时候 ARQ 就不太够用了。

避坑指南：我曾经在无线网络环境下过度依赖 ARQ，结果丢包率没降下来，反而因为重传风暴把网络打死了。后来加了 FEC 做前置保护，问题才解决。

FEC 的思路不一样。发送方在发送数据时，额外生成一些冗余包。接收方即使丢了一部分包，也能通过冗余信息把原始数据算出来。说白了，就是「多带点备胎」。

FEC 的好处是不需要等待重传，延迟可控。但代价是带宽浪费——你本来传 10 个包，现在可能要传 12 个。冗余度怎么选？这是个技术活。

实际工程中，我很少只用一种方案。混合方案才是王道。比如：

我参与过的一个实时音视频项目，就是用的这种混合方案。效果嘛，丢包率从 5% 降到 0.1% 以下，用户体验提升了一大截。

这门课的目标很明确：让你从零到一，掌握丢包恢复机制的设计与实现。不是纸上谈兵，而是能真正写代码、能上线跑的那种。

学习路径我设计成了三个阶段：

下面这张图，是我梳理的本章知识体系，也是整门课的骨架：

重要提醒：这门课不是纯理论课。我会带着你写 C/C++ 和 Python 代码，从零实现一个可用的丢包恢复库。如果你只是想来听故事，那可能会失望。但如果你想真正掌握这项技能，跟紧我，不会错。