根本原因在于tcp重传和重复确认是传输层自愈机制，只要重传在rto内完成且未触发应用层超时阈值，业务就不会报错；dup ack仅表示乱序，retransmission不等于失败。
为什么 Dup ACK 和 Retransmission 不一定导致业务超时
根本原因在于：TCP 重传和重复确认是传输层的自愈机制，只要重传成功、应用层未感知到丢包或延迟，上层 HTTP/gRPC/DB 连接就不会报错。业务日志无超时，恰恰说明重传在 RTO（Retransmission Timeout）内完成，且应用层 socket 读写未触发超时阈值。
常见误判点：Dup ACK 只反映接收端检测到乱序包（比如包 1、3 到达，2 丢失），不等于丢包已发生；Retransmission 也不等于失败——它只是 TCP 在等不到 ACK 时的主动补救。
- RTO 通常动态计算（基于 RTT 样本），可能低至 200ms～500ms，远小于业务层设置的 5s/30s 超时
- 现代内核（如 Linux 4.1+）默认启用
tcp_reordering（默认 3），允许最多 3 个包乱序而不立即触发快速重传 - 如果丢包发生在响应体末尾（如大文件下载最后几个包），应用层可能已返回 200 状态码，后续 FIN 流程仍可正常完成
如何确认这些重传是否真实影响了业务时延
关键不是看有没有 Dup ACK，而是看它们是否推高了实际 RTT 或导致窗口停滞。用 tcpdump -ttt 或 tshark -o tcp.calculate_timestamps:TRUE 提取时间戳后，重点关注三类模式：
- 连续多个
[TCP Dup ACK]后紧接[TCP Retransmission]，且重传包的seq与原始包一致 → 真实丢包，需查链路 -
Retransmission出现在ACK已到达发送端之后 → 可能是虚假重传（spurious retransmit），常见于时钟漂移或 ACK 延迟抖动 - 重传后紧接着收到多个
[TCP Window Update]或ACK窗口跳变 → 接收端缓冲区曾阻塞，问题可能在下游消费能力不足
示例命令定位重传延迟：
tcpdump -r trace.pcap -nn 'tcp[tcpflags] & (tcp-rst|tcp-syn) == 0' -w nohandshake.pcap<br>tshark -r nohandshake.pcap -Y 'tcp.analysis.retransmission || tcp.analysis.duplicate_ack' -T fields -e frame.time_epoch -e tcp.seq -e tcp.len -e tcp.analysis.rtt
哪些场景下业务无超时但性能已受损
即使 HTTP status 200 正常返回，以下情况仍会静默拖慢吞吐或提高 P99 延迟：
- 频繁小包重传（如 TLS record 层每个 1388 字节包都重传一次）→ 实际吞吐跌至理论带宽 30% 以下
- 重传集中发生在某条连接的中后段（如 POST 请求 body 上传到 80% 时丢包）→ 客户端感知为“卡顿”，但服务端日志只记一条完整请求
-
tcp_slow_start_after_idle开启（默认开启）→ 长连接空闲后恢复传输时退回到慢启动，即使没丢包也会临时限速 - 接收端
net.ipv4.tcp_rmem设置过小（如 4096 65536 65536）→ 窗口缩成 64KB，持续触发Window Full+Dup ACK循环
下一步排查必须检查的 4 个地方
别只盯着 tcpdump 输出，这四个位置才是根因高发区：
- 本机
/proc/net/snmp中TcpExt:行的SyncookiesSent、TCPSpuriousRtxHostQueues、TCPTimeouts—— 若TCPTimeouts显著高于TCPRetransSegs，说明 RTO 设置过短或网络抖动严重 - 对端设备（交换机/防火墙/NIC）的输入错误计数：
ethtool -S eth0 | grep -i "err\|drop\|over"，特别关注rx_missed_errors和rx_over_errors - 路径 MTU 是否被中间设备暗改：用
ping -M do -s 1472 x.x.x.x测试，若不通而-s 1400通，则存在 PMTU 黑洞，引发大量 ICMP "Fragmentation Needed" 但被过滤 - 是否启用了
tcp_sack（默认开启）但接收端内核版本
真正棘手的问题往往藏在 NIC offload 功能和网卡驱动之间——比如某些 Mellanox CX-4 卡在启用 lro 时，会对分片重组失败的包反复生成 Dup ACK，但业务完全无感，直到并发连接数上万才暴露吞吐瓶颈。
