内核-syn-ack RTO修改
尝试修改SYN ACK 包的重传时间修改,刚开始 使用
ip route list
ip route change ... rto_min 20ms
ss -ite
使用命令 ss -ite 发现RTO 从200+ ms 降到30ms 等,说明配置有生效,网上说的RTO_MIN 200ms 修改生效
问题在于,如果仅仅是通过这种不科学的验证方式 无法确定syn ack 的丢失重传时间,经过验证 syn ack 的 丢失重传时间 为 TCP_TIMEOUT_INIT 1秒 而不是 TCP_RTO_MIN
TCP_TIMEOUT_INIT
搜索与之相关的函数
tcp_schedule_loss_probe 此函数为尾部丢失定时探测 不是syn ack
if (tp->srtt_us) {
timeout = usecs_to_jiffies(tp->srtt_us >> 2);
if (tp->packets_out == 1)
timeout += TCP_RTO_MIN;
else
timeout += TCP_TIMEOUT_MIN;
} else {
timeout = TCP_TIMEOUT_INIT;
}
tcp_timeout_init
修改 返回的为配置值
tcp_connect_init 作为客户端对外建联
tcp_connect_request 作为服务端 接收客户端建联
if (!want_cookie)
inet_csk_reqsk_queue_hash_add(sk, req,
tcp_timeout_init((struct sock *)req)); //
af_ops->send_synack(sk, dst, &fl, req, &foc,
!want_cookie ? TCP_SYNACK_NORMAL :
TCP_SYNACK_COOKIE);
在实际测试过程中 配置值 需要乘以10 倍才是真实的超时重传值。可能与最小tick 间隔10ms 有关吧
测试工具:
packet drill 、或者使用 raw socket 封装的发包工具
ip route 修改的是路由缓存中的值:
static inline u32 tcp_rto_min(struct sock *sk)
{
const struct dst_entry *dst = __sk_dst_get(sk);
u32 rto_min = TCP_RTO_MIN;
if (dst && dst_metric_locked(dst, RTAX_RTO_MIN))
rto_min = dst_metric_rtt(dst, RTAX_RTO_MIN);
return rto_min;
}