tcp_syn_retries怎样SYN重试

本文目录导读：

1. 核心机制：指数退避 + 固定上限
2. 参数值含义
3. 如何查看和修改
4. 与其他参数的对比
5. 实际案例分析
6. 注意事项

tcp_syn_retries 是 Linux 内核中用于控制 TCP 三次握手中 SYN 报文（主动发起连接） 重试次数的参数，它决定了一个 TCP 连接在首次发送 SYN 后，如果没有收到 SYN-ACK，内核会重试多少次，以及每次重试的间隔。

核心机制：指数退避 + 固定上限

1. 触发条件：当客户端调用 connect() 发送第一个 SYN 后，开始等待 SYN-ACK，如果超时未收到，则触发重试。
2. 重试间隔：采用 指数退避 算法。
   • 第一次超时：1 秒（默认的初始 RTO，即 tcp_rto_min，通常为 HZ/5 = 200ms，但第一次重传通常是 1 秒，具体取决于内核实现）。
   • 后续重试：每次超时时间翻倍（1s -> 2s -> 4s -> 8s ...）。
   • 上限：总的重试次数由 tcp_syn_retries 决定（默认值通常为 6）。
3. 总超时时间：总等待时间约为 初始超时 * (2^(retries+1) - 1)。retries=6 时，总时间约 63 秒（1+2+4+8+16+32+64=127 秒理论上限，但实际上内核会限制在 60-120 秒左右，具体看内核实现和 RTO 基数）。

参数值含义

• 取值：整数，通常范围是 0 到 255。
• 默认值：在大多数 Linux 发行版上为 6。
• 推荐值：
  • 对可靠性要求高（如数据库、内网服务）：6，即使丢包严重，也能等待 60-120 秒，确保绝大多数情况下连接能建立。
  • 对响应速度要求高（如 Web 服务器面向公网）：3 或 4，7-15 秒内还没收到 SYN-ACK，大概率是对端不可达或拒绝连接（如端口未开放），继续等待无意义，此时缩短等待时间可以更快释放资源（内存、端口）并返回错误给应用层。
  • 极低延迟场景（如高频交易、实时通信）：1 或 2，快速失败，快速切换。

如何查看和修改

查看当前值：

sysctl net.ipv4.tcp_syn_retries
# 或
cat /proc/sys/net/ipv4/tcp_syn_retries

临时修改（立即生效，重启丢失）：

sysctl -w net.ipv4.tcp_syn_retries=3

永久修改（写入配置文件）：

echo "net.ipv4.tcp_syn_retries = 3" >> /etc/sysctl.conf
sysctl -p  # 立即生效

与其他参数的对比

实际案例分析

场景：客户端尝试连接一个不存在的 IP 或端口未开放的服务。

1. tcp_syn_retries=6：客户端会重试 6 次（共发送 7 个 SYN 包），总耗时约 60-120 秒，connect() 返回 ETIMEDOUT。
2. tcp_syn_retries=3：客户端重试 3 次（共发送 4 个 SYN 包），总耗时约 7-15 秒，然后快速返回错误。

优化建议：

• 如果你是一个 公网 Web 服务器，面向大量来自互联网的客户端请求，设置 tcp_syn_retries=3 可以：
  • 让有问题的连接（如网络不通、客户端崩溃）更快释放操作系统资源（端口、内存）。
  • 让应用层（如 Nginx）更快收到失败结果，从而处理下一个请求或记录错误。
• 如果是 内部服务（数据库、微服务 RPC），网络环境稳定可靠，建议保留默认值 6，避免因偶发的网络抖动导致连接频繁失败。

注意事项

1. 仅对主动连接方：tcp_syn_retries 只影响主动调用 connect() 的一方（通常是客户端），对于被动监听方（服务端），SYN-ACK 的重试由 tcp_synack_retries 控制。
2. 攻击防御：如果将 tcp_syn_retries 设得过小（如 0 或 1），攻击者可以很容易地通过发送大量伪造的 SYN 包来耗尽服务端的半连接队列（SYN Flood），但这与参数本身的正规用途无关，防御 SYN Flood 主要靠 tcp_syncookies 等机制。
3. RTO 细节：第一次重试的超时时间并不是固定的 1 秒，它取决于内核中的 tcp_rto_min 和 tcp_init_cwnd 等参数的动态计算，但通常首次 RTO 在 1 秒左右，指数退避的基数也不是严格的 2，会略微随机化以防止全局同步。

标签： SYN重试