在TCP传输中，当数据包丢失时，传统的累积确认机制会让发送端重传丢失序号之后的所有数据，即使其中一部分已经被接收方成功缓存。这种低效的重传方式在丢包率较高的网络中会严重降低吞吐量。选择性确认选项（SACK）和重复选择性确认选项（DSACK）的引入，正是为了改善这一问题。Linux内核通过net.ipv4.tcp_sack与net.ipv4.tcp_dsack两个参数来控制这两个特性。下面将深入分析它们的工作机制、配置方法以及调优验证手段。
SACK与DSACK的底层工作机制
SACK选项允许接收方在返回的ACK报文中携带多个数据块的边界信息，这些数据块是接收方已经成功接收但不连续的区域。发送方收到这些信息后，能够精确识别出哪些序号段丢失，从而只重传真正缺失的数据。与传统的Go-Back-N重传策略相比，SACK可以避免重传已经确认接收的数据，大幅节省网络带宽。
例如，发送方发送了序号1到10共10个段，接收方收到了1、2、3、5、6、7、9、10，缺失4和8。在没有SACK的情况下，接收方只能确认到序号3，发送方会从序号4开始重传后续所有数据。启用SACK后，接收方可以在ACK中报告已收到的连续块边界，比如4到4缺失、8到8缺失，发送方只重传4和8两个段，效率提高明显。
DSACK是SACK的扩展，它允许接收方报告已经收到过的重复数据。当发送方错误地重传了一个段，而接收方发现该段之前已经存在于接收缓冲区中时，就会通过DSACK选项通知发送方。发送方据此可以判断这是一次不必要的重传，可能原因是ACK丢失、乱序或重传超时设置过于激进。DSACK为TCP拥塞控制提供了更准确的反馈信息，帮助内核优化重传定时器和拥塞窗口调整策略，减少后续误重传的概率。
内核参数配置与调优实践
在Linux系统中，SACK和DSACK的开关由net.ipv4.tcp_sack和net.ipv4.tcp_dsack两个内核参数控制。参数值为1表示启用，0表示禁用。默认情况下，大多数现代Linux发行版都启用了这两项特性，但部分定制化内核或安全加固配置可能会关闭它们。可以通过以下命令查看当前值：
# 查看SACK与DSACK当前设置 sysctl net.ipv4.tcp_sack net.ipv4.tcp_dsack # 或者直接读取proc文件系统 cat /proc/sys/net/ipv4/tcp_sack cat /proc/sys/net/ipv4/tcp_dsack
如果需要临时开启这两个参数，可以使用sysctl -w命令立即修改，该修改只对之后新建的TCP连接生效，已有连接不受影响。命令如下：
# 临时启用SACK和DSACK sysctl -w net.ipv4.tcp_sack=1 sysctl -w net.ipv4.tcp_dsack=1
为了让配置在系统重启后仍然有效，需要将其写入sysctl配置文件。推荐在/etc/sysctl.d目录下创建一个独立配置文件，例如99-tcp-tuning.conf，内容如下：
# /etc/sysctl.d/99-tcp-tuning.conf net.ipv4.tcp_sack = 1 net.ipv4.tcp_dsack = 1
保存文件后，执行sysctl --system或sysctl -p /etc/sysctl.d/99-tcp-tuning.conf重新加载配置。对于正在运行的关键业务服务器，建议先在测试环境中验证，再逐步推广，因为部分老旧的网络中间设备可能无法正确处理SACK选项，极少数情况下会导致连接异常。
值得注意的是，DSACK功能依赖SACK启用，如果net.ipv4.tcp_sack被设置为0，则net.ipv4.tcp_dsack即使为1也不会产生实际效果。因此，在进行内核调优时，必须先确保SACK处于开启状态，再考虑DSACK的优化。
调优效果验证与常见问题排查
完成参数调整后，需要通过实际数据验证调优是否生效。可以使用ss -ti命令查看活动的TCP连接是否协商了SACK选项。输出中如果包含sack或dsack相关标记，说明连接两端都支持该特性。此外，netstat -s命令提供了更详细的TCP统计信息，其中TCPSACKRecovery表示使用SACK进行恢复的次数，TCPDSACKRecv表示接收到的DSACK块数量，这些计数器持续增长通常说明SACK机制正在正常工作。
还可以使用抓包工具分析TCP报文头中的选项字段。例如通过tcpdump抓取指定端口的流量，并使用Wireshark打开查看TCP选项。在Wireshark的TCP层中，能够直接看到SACK和DSACK选项的具体内容，包括每个已接收数据块的左右边界。这种方法适合需要深入分析特定连接重传行为的场景。
调优过程中可能遇到两类问题。第一类是参数设置后没有效果，这通常是因为新参数只对新连接生效，而旧的连接仍然沿用建立时的协商结果。第二类是开启SACK后个别应用出现吞吐量下降，这可能是由于中间设备或对端TCP栈对SACK选项处理有缺陷。此时可以通过抓包确认SACK协商是否成功，并尝试临时禁用SACK进行对比测试，观察吞吐量变化趋势。如果确认是设备兼容性问题，可以针对特定网络路径禁用SACK，而保留DSACK在其他路径上的使用。
总体而言，启用net.ipv4.tcp_sack和net.ipv4.tcp_dsack是提升TCP重传效率最直接的内核调优手段之一。合理配置这两个参数，能够显著减少不必要的重传流量，提高高丢包率网络环境下的数据传输吞吐量。只要网络环境支持，建议始终保持开启状态。