SACK（Selective Acknowledgment）基本原理
SACK 是 TCP 协议的扩展选项（RFC 2018），核心思想是：接收方在 ACK 报文中显式告知发送方“哪些非连续数据块已成功接收”，而非仅返回累积确认序号。
- 工作方式：当数据失序到达时，接收方在 TCP 选项字段中携带 1~4 个“块”（Block），每个块包含已接收数据段的左右边界（Left/Right Edge）。
- 发送方行为：结合累积 ACK 和 SACK 信息，精准标记丢失段，仅重传真正缺失的数据，避免盲目重传已接收内容。
- 前提：需双方在三次握手时协商启用（SYN 报文携带
SACK_PERMITTED选项）。
与类似方案对比（聚焦“多丢包场景下的重传效率”）
表格
| 方案 | 核心机制 | 多丢包场景缺陷 | 与 SACK 对比优势 |
|---|---|---|---|
| 传统累积 ACK | 仅确认连续接收的最高序号，失序时重复发送同一 ACK | 无法区分哪些非连续段已接收，导致重传已成功数据或长时间等待超时（RTO） | ❌ 效率最低，高丢包网络性能骤降 |
| Reno | 依赖 3 个重复 ACK 触发“快速重传”，但仅重传单个段 | 多段连续丢失时需多次触发快速重传或超时，恢复慢（如丢 2 段需 2 次 RTT） | ❌ 仅适合单丢包场景 |
| NewReno | 引入“部分 ACK”：收到部分确认后继续重传后续丢失段，保持快速恢复状态 | 仍需逐个重传丢失段（1 RTT 仅恢复 1 段），恢复速度受限 | ⚠️ 比 Reno 优，但精度和效率仍低于 SACK |
| SACK | 显式反馈所有已接收非连续块，发送方可并行重传多个丢失段 | 需双方支持；老旧中间设备可能剥离 TCP 选项；历史存在安全漏洞（如 CVE-2019-11477，已修复） | ✅ 精准定位丢失、减少重传次数（实测↓67%）、提升吞吐（↑71%） |
关键补充说明
- 定位差异：
SACK 本质是确认机制优化，可与 Reno/NewReno/CUBIC/BBR 等拥塞控制算法配合使用（如 Linux 默认tcp_sack=1+ CUBIC）。而 Reno/NewReno 是拥塞控制状态机，依赖 ACK 行为推断丢包。 - 实际价值：
在高延迟/高丢包网络（如移动网络、跨洲链路）中，SACK 能显著降低卡顿（视频流）、缩短传输时间（大文件）、提升实时性（在线游戏）。现代操作系统与云服务普遍默认启用。 - 注意误区：
- ❌ 非“萨克斯实验”（力学实验，与 TCP 无关）
- ❌ 非 ECN（显式拥塞通知，属拥塞信号维度，与确认机制不同）
- ✅ SACK 解决的是“重传歧义”问题，而非拥塞检测本身。
💡 总结：SACK 通过“用空间换效率”（ACK 携带额外信息），将 TCP 从“盲重重传”升级为“精准手术式重传”，是当前高性能网络传输的基石优化之一。在需兼顾兼容性与性能的场景中，SACK 已成为事实标准。