SACK在2.4内核已经规模使用，NACK比较特殊才用

这两个机制在现代网络通信中都扮演着重要角色，但它们的应用方式和普及程度有所不同。简单来说：SACK 是 TCP 协议中广泛普及的标准配置，而 NACK 更多是一种设计思想，在特定协议或底层硬件中应用较多。

以下是详细的分析：

1. SACK (选择性确认)：TCP 的标配

SACK 在现代互联网中使用非常普遍，几乎是高性能网络通信的“默认设置”。

• 使用频率：极高。
  • 绝大多数现代操作系统（Linux, Windows, macOS, Android, iOS）在 TCP 协议栈中都默认开启了 SACK 功能。
  • 只要通信双方（客户端和服务端）都支持（现代设备基本都支持），SACK 就会自动协商并生效。
• 主要应用场景：
  • 高丢包率环境：如无线网络（Wi-Fi, 4G/5G），信号波动导致数据包随机丢失。SACK 能确保只重传丢失的那一小部分，而不是重传一大片已收到的数据。
  • 高带宽、长距离传输：如跨国海底光缆、卫星通信。在这些场景下，重传成本极高（RTT 长），SACK 能极大提升吞吐量，避免“一丢丢，停半天”的现象。
  • 视频流与大数据传输：如 YouTube、Netflix 或云存储同步。SACK 能有效减少缓冲时间，提升加载速度。
• 内核集成情况：
  • 已深度集成。
  • 在 Linux 内核中，SACK 支持早在 2.4 版本就已引入。
  • 你可以通过命令 sysctl net.ipv4.tcp_sack 查看状态，通常默认值为 1（开启）。
  • 注意：虽然集成度高，但历史上曾出现过利用 SACK 进行攻击的漏洞（如 CVE-2019-11477，即 "SACK Panic"），导致部分管理员在打补丁前临时关闭它。不过，现在的内核版本早已修复了这些问题，建议保持开启。

2. NACK (否定应答)：特定领域的利器

NACK 在通用的 TCP 协议中并没有作为标准选项被广泛使用（TCP 主要依靠 SACK 和超时重传），但在其他协议和底层硬件中应用很广。

• 使用频率：在特定领域很高，但在通用 TCP 中很少见。
  • TCP 协议本身更倾向于 SACK 机制，因为 SACK 报告“已收到的数据”比 NACK 报告“丢失的数据”在逻辑上更稳健（避免了 NACK 包本身丢失导致的状态不一致）。
• 主要应用场景：
  • 组播/广播传输 (Multicast)：在“一对多”的传输中（如直播流、软件分发），如果让接收方都用 ACK 确认，发送方会被淹没。使用 NACK，只有没收到数据的人才发送 NACK，大大减轻了网络负担。
  • 实时音视频协议 (如 RTP/RTCP)：在视频会议中，为了低延迟，通常不会等待 TCP 式的重传，而是通过 RTCP 协议发送 NACK 请求重传关键帧，或者直接丢弃（因为已经过时了）。
  • 嵌入式与硬件通信 (如 I2C, CAN 总线)：在汽车电子、工业控制中，NACK 是标准的硬件信号。例如，I2C 总线上的从设备如果无法处理数据，会主动拉高电平发送 NACK 信号，告诉主机“我忙，别发了”。
• 内核集成情况：
  • TCP 栈中无独立 NACK 选项：Linux 内核的 TCP 栈没有专门的“NACK”开关，它是通过 SACK 和重复 ACK (DupACK) 机制来实现类似功能的。
  • 其他子系统已集成：内核的网络驱动（针对组播协议）和硬件接口驱动（如 I2C 驱动）中已经集成了 NACK 的处理逻辑。

总结对比表

表格

 

特性	SACK (选择性确认)	NACK (否定应答)
核心逻辑	“我收到了这些” (报告数据块)	“我没收到这些” (报告空洞)
TCP 协议地位	标准选项，默认开启	未作为标准选项使用
普及程度	极高 (Web, App, 云服务的基石)	中等 (特定协议和硬件)
典型场景	网页浏览、文件下载、跨国传输	视频直播(组播)、嵌入式硬件通信
内核支持	深度集成 (net.ipv4.tcp_sack)	集成于特定驱动或协议栈中

一句话建议：
如果你是在优化服务器或网络应用的性能，确保 SACK 开启