DSACK TCP如何识别重复确认的数据段？

Question

在使用DSACK（Duplicate SACK）机制检测重复数据段时，一个常见问题是：当接收端收到乱序或重复的数据包时，TCP如何准确判断该数据段为重复传输而非正常的新数据？具体而言，内核依据什么条件在SACK选项中标记某段为“重复”？这涉及TCP序号比对、时间戳选项与接收窗口状态的协同判断。理解这一机制对分析重传误判、网络重复拷贝等问题至关重要。

Answer 1

一、TCP DSACK机制基础：什么是DSACK？

DSACK（Duplicate Selective Acknowledgment）是TCP SACK（Selective Acknowledgment）机制的扩展功能，用于标识接收端收到的重复数据段。当发送端收到带有DSACK信息的ACK报文时，可以判断其之前的数据重传是由于网络延迟还是真正丢失。

• TCP头部中通过SACK选项携带已接收但非按序到达的数据块信息。
• DSACK通过在第一个SACK块中标记“已被接收”的数据范围，告知发送方该段数据为重复传输。
• 典型场景包括：快速重传后原数据包迟到、网络复制（如链路层重传）、路径不对称等。

内核在处理入站数据包时，会结合当前接收缓冲区状态与SACK信息生成DSACK标记。

二、判断重复数据的核心依据：序号比对与接收窗口管理

TCP使用序列号作为唯一标识每字节数据的手段。接收端通过维护三个关键变量来判断是否为重复数据：

变量名	含义	作用
rcv_nxt	下一个期望接收的序列号	判断数据是否超前或滞后
rcv_wnd	当前接收窗口大小	控制流量避免溢出
sacked_out	已被SACK确认但未被应用读取的数据量	辅助判断重复性
rcv_lowat	接收低水位线	影响ACK触发策略
copied_seq	最后被应用程序读取的序列号	区分已交付与待处理数据
dsack_high	最高被标记为DSACK的序列号	防止重复上报同一段
reordering	当前估计的网络乱序程度	影响重传决策
last_ack_sent	上次发送ACK的确认号	检测ACK丢失或延迟
snd_una	最老未确认的发送序列号	发送端滑动窗口起点
delivered	已成功交付至接收应用的数据量	用于BBR等拥塞控制算法

三、DSACK生成逻辑流程图解析

if (tcp_sequence_number_check(rcv_nxt, rcv_wnd, seq, end_seq)) {
    if (seq < rcv_nxt) {
        // 数据起始位置小于期望接收点
        if (before(seq, rcv_nxt) && after(end_seq, rcv_nxt)) {
            // 部分重叠新旧边界 → 可能为部分重复
            mark_dsack = true;
        } else if (after(end_seq, rcv_nxt)) {
            // 完全落在已接收区域 → 明确重复
            tcp_mark_dsack(sk, seq, end_seq);
        }
    }
} else {
    // 正常乱序包，进入SACK块记录，不标记DSACK
    tcp_sack_add(&sk->tcp_sock, seq, end_seq);
}

graph TD A[收到TCP数据段] --> B{序列号 < rcv_nxt?} B -- 是 --> C{end_seq > rcv_nxt?} C -- 否 --> D[完全重复: 触发DSACK] C -- 是 --> E[部分重叠: 标记为DSACK边缘情况] B -- 否 --> F{在接收窗口内?} F -- 是 --> G[正常乱序: 加入SACK块] F -- 否 --> H[丢弃: 超出窗口]

四、时间戳选项（TSopt）在重复检测中的协同作用

启用TCP时间戳选项（RFC 1323）可增强重复数据识别能力。接收端维护PAWS（Protect Against Wrapped Sequence Numbers）机制，利用时间戳判断“相同序号”数据是否来自不同生命周期。

• 若两个相同SEQ的数据包时间戳递减，则后者被视为旧副本，直接丢弃并可能触发DSACK。
• 时间戳单调性检查可减少因高速网络导致的序列号回绕误判。
• 结合RTT估算，系统可区分“延迟到达”与“真正重传”。

例如，在Linux内核中，tcp_fast_parse_header()会优先解析时间戳，并更新tp->rx_opt.ts_recent以支持后续去重决策。

五、实际问题分析：DSACK误报与网络诊断

在复杂网络环境中，DSACK可能被错误触发，常见原因包括：

1. 链路层重传导致IP包复制（如Wi-Fi或MPLS网络）
2. 负载均衡器路径切换引发包乱序
3. NAT设备对TCP流状态维护不当
4. 中间件（如LVS、F5）进行连接卸载时缓存异常
5. 虚拟化平台vSwitch丢包重试机制引入重复帧
6. QUIC over UDP隧道封装造成外层重复
7. DNS响应劫持后伪造TCP重传
8. 运营商级NAT（CGNAT）会话表老化异常
9. IPv6分片重组失败引发上层重传
10. 防火墙深度包检测（DPI）修改SEQ/ACK导致同步错乱

通过ss -i或tcpinfo可查看DSACK计数，结合tcp_retransmits统计定位问题根源。