解决了什么
没有选择性确认时，丢一个段可能触发整窗重传；有了它，接收方可以精确告诉发送方「已经收到了哪些不连续的数据块」，发送方只需重传缺失部分（RFC 2018）。在高丢包的长距离链路上，它对吞吐的影响非常明显。
重复确认的用途
除描述缺口的确认之外，还有一类重复确认：接收方主动告知「这段数据我早收到了」（RFC 2883）。它的价值在诊断——帮助发送方判断多余重传是不是网络乱序造成的，从而避免因为误判而把窗口降得过低。
基本信息
| 规范 | RFC 2018 定义选择性确认，RFC 2883 定义重复确认 |
|---|---|
| 协商时机 | 选项只在连接建立阶段协商，双方支持才生效 |
| 本机开关 | 内核参数中的相关开关项，默认通常开启 |
| 观察方式 | ss -ti 查看已建立连接的协商结果，抓包看选项字段 |
典型使用场景
- 长距离、高丢包链路的吞吐优化
- 排查「丢包率不高但速度就是上不去」
- 抓包分析多余重传的来源
- 评估中间设备对传输选项的干扰
查看与开关
查看与开关
sysctl net.ipv4.tcp_sack # 确认本机开关状态
ss -ti | grep -i sack # 看连接实际协商结果
tcpdump -nn -v 'tcp port 443' -c 20 | grep -i sack # 抓包看选项相关概念
| 概念 | 作用 | 典型用途 |
|---|---|---|
| 选择性确认 | 接收方通告已收到的不连续区间 | 只重传真正缺失的部分 |
| 重复确认 | 告知某段数据早先已经收到 | 判断网络乱序，避免误降窗口 |
| 累积确认 | 只确认连续收到的位置 | 基础机制，缺少缺口细节 |
该选项只在连接建立时协商，双方支持才生效：中间设备把它剥掉后，两端即使都开启也用不上。
部分老旧防火墙与地址转换设备会剥掉或改写这类选项，导致吞吐骤降。抓包对比两端看到的协商结果即可确认，问题多半在链路上的设备，而不在服务器。
排查时优先对比两端抓包：只有一端显示选项缺失，就能把范围缩小到中间的哪一段。