标题 | TCP数据重传时间细节探秘及数据中心优化 |
内容 | 在数据中心网络内,机器之间数据传输的往返时间(rtt)一般在10ms以内,为此调内部服务的超时时间一般会设置成50ms、200ms、500ms等,如果在传输过程中出现丢包,这样的服务超时时间,tcp层有机会发现并重传一次数据么?如果设置成200ms以内,答案是没有机会,原因是linux系统下第一次重传时间等于传输的往返时间上至少加上200ms的预测偏差值,即如果rtt值是7ms,第一次重传超时时间至少是207ms,这样如果对某个接口的超时时间设置成200ms以内, 即便是rtt时间很小,仍然无法容忍一次丢包,因为在tcp发现丢包之前,该接口已经超时了。 本文针对linux系统tcp数据包第一次重传时间的计算进行探究,结果会让人大吃一惊。提出的优化方法,理论上能够降低内部服务调用时延和出错量。 tcp发送数据包后,会设置一个定时器,到期后如果还没有收到对方的回复(ack),就会重传数据包。从发出数据包到第一次重传之间的间隔时间称为retransmission timeout(RTO),rto由数据包的往返时间(rtt)加上rtt的预测偏差(波动值)计算出来。 即 rto = srtt + rttvar,其中srtt是rtt的平滑值,而rttvar是波动值,代表可能的预测偏差。 接下来我们做一个试验。 先ping一下,看一下数据包的往返时间,如下: [xiaohong@localhost ~]$ ping PING (123.125.104.197) 56(84) bytes of data. 64 bytes from 123.125.104.197: icmp_seq=1 ttl=55 time=3.65 ms 64 bytes from 123.125.104.197: icmp_seq=2 ttl=55 time=3.38 ms 64 bytes from 123.125.104.197: icmp_seq=3 ttl=55 time=4.34 ms 64 bytes from 123.125.104.197: icmp_seq=4 ttl=55 time=7.82 ms 再看一下tcp对到的rtt相关数据,下面的命令是针对centos7(如果是以下的版本,运行的命令是ip route list tab cache)如下: [xiaohong@localhost ~]$ sudo ip tcp_metrics 123.125.104.197 age 22.255sec rtt 7375us rttvar 7250us cwnd 10 由上面看出,平滑后的rtt值约为7ms,rttvar约为7ms,那按理说rto值应该是14ms左右,也就是等14ms后,如果没有收到对方的响应,就会重传数据。实际的情况会是这样么? 在一个命令窗口里,运行下面的命令: [xiaohong@localhost ~]$ nc 80 GET / HTTP/1.1 Host: Connection: 同时再开一个命令行窗口里,运行下面的命令: [xiaohong@localhost iproute2-3.19.0]$ ss -eipn '( dport = :www )' tcp ESTAB 0 0 10.209.80.111:56486 123.125.104.197:80 users:(("nc",1713,3)) uid:1000 ino:14243 sk:ffff88002c992d00 <-> ts sack cubic wscale:0,7 rto:207 rtt:7.375/7.25 mss:1448 cwnd:10 send 15.7Mbps rcv_space:14600 从上面的结果可以看出,实际的rto值是207ms,相当于rtt值加上200ms,为什么呢? 下面从内核tcp源代码中分析原因。 设置超时时间的函数是tcp_set_rto,在net/ipv4/tcp_input.c中,如下: static inline void tcp_set_rto(struct sock *sk) { const struct tcp_sock *tp = tcp_sk(sk); inet_csk(sk)->icsk_rto = __tcp_set_rto(tp); tcp_bound_rto(sk); } 可以看出,重传的定时值isck_rto实际上是调用 __tcp_set_rto,接着看它的源码,这个在文件include/tcp/net/tcp.h中,如下: static inline u32 __tcp_set_rto(const struct tcp_sock *tp) { return (tp->srtt >> 3) + tp->rttvar; } 为了避免浮点数运算,rtt乘以8保存在socket数据结构中,从代码可以确认: icsk_rto = srtt + rttvar 而计算和影响srtt和rttvar的函数是tcp_rtt_estimator,在文件net/ipv4/tcp_input.c中,代码如下: static void tcp_rtt_estimator(struct sock *sk, const __u32 mrtt) { struct tcp_sock *tp = tcp_sk(sk); long m = mrtt; /* RTT */ /* The following amusing code comes from Jacobson's * article in SIGCOMM '88. Note that rtt and mdev * are scaled versions of rtt and mean deviation. * This is designed to be as fast as possible * m stands for "measurement". * * On a 1990 paper the rto value is changed to: * RTO = rtt + 4 * mdev * * Funny. This algorithm seems to be very broken. * These formulae increase RTO, when it should be decreased, increase * too slowly, when it should be increased quickly, decrease too quickly * etc. I guess in BSD RTO takes ONE value, so that it is absolutely * does not matter how to _calculate_ it. Seems, it was trap * that VJ failed to avoid. 8) */ if (m == 0) m = 1; if (tp->srtt != 0) { m -= (tp->srtt >> 3); /* m is now error in rtt est */ tp->srtt += m; /* rtt = 7/8 rtt + 1/8 new */ if (m < 0) { m = -m; /* m is now abs(error) */ m -= (tp->mdev >> 2); /* similar update on mdev */ /* This is similar to one of Eifel findings. * Eifel blocks mdev updates when rtt decreases. * This solution is a bit different: we use finer gain * for mdev in this case (alpha*beta). * Like Eifel it also prevents growth of rto, * but also it limits too fast rto decreases, * happening in pure Eifel. */ if (m > 0) m >>= 3; } else { m -= (tp->mdev >> 2); /* similar update on mdev */ } tp->mdev += m; /* mdev = 3/4 mdev + 1/4 new */ if (tp->mdev > tp->mdev_max) { tp->mdev_max = tp->mdev; if (tp->mdev_max > tp->rttvar) tp->rttvar = tp->mdev_max; } if (after(tp->snd_una, tp->rtt_seq)) { if (tp->mdev_max < tp->rttvar) tp->rttvar -= (tp->rttvar - tp->mdev_max) >> 2; tp->rtt_seq = tp->snd_nxt; tp->mdev_max = tcp_rto_min(sk); } } else { /* no previous measure. */ tp->srtt = m << 3; /* take the measured time to be rtt */ tp->mdev = m << 1; /* make sure rto = 3*rtt */ tp->mdev_max = tp->rttvar = max(tp->mdev, tcp_rto_min(sk)); tp->rtt_seq = tp->snd_nxt; } } 从上面的代码可以看出,srtt = 7/8 old srtt + 1/8 new rtt,这个跟RFC一致,没有啥可以说的。 获得第一个往返时间数据时(一般是建立连接完成时,对于客户端就是发出sync请求,收到服务端的回应时,而对于服务器端就是发出syc+ack后,收到客户端的ack时)的计算分析如下: } else { /* no previous measure. */ /* 以前没有rtt的数据,这是收到第一个rtt的样本数据的代码逻辑 */ /* m是本次的rtt值,乘以8保存到 srtt中 */ tp->srtt = m << 3; /* take the measured time to be rtt */ /* rtt的初始偏差值mdev是 2倍rtt值 */ tp->mdev = m << 1; /* make sure rto = 3*rtt */ /* 设置rttvar和rtt偏差的最大值mdev_max这两者的初始值 */ /* 2倍的rtt值,tcp_rto_min之间,那个大,就选那个 */ tp->mdev_max = tp->rttvar = max(tp->mdev, tcp_rto_min(sk)); tp->rtt_seq = tp->snd_nxt; } 再看tcp_rto_min的代码,在文件include/net/tcp.h中: static inline u32 tcp_rto_min(struct sock *sk) { struct dst_entry *dst = __sk_dst_get(sk); u32 rto_min = TCP_RTO_MIN; /* 200ms */ if (dst && dst_metric_locked(dst, RTAX_RTO_MIN)) rto_min = dst_metric_rtt(dst, RTAX_RTO_MIN); return rto_min; } 结合起来看,如果第一个数据包往返时间在100ms以内,rtt预测初始的偏差值就固定为200ms,当数据包往返时间超过100ms,rtt预测偏差的初始值是2倍的rtt值,也就是说rttvar最小值是200ms。 接着分析计算和影响srtt和rttvar的函数是tcp_rtt_estimator的代码: if (tp->mdev > tp->mdev_max) { /* 跟踪rtt的偏差,记录偏差最大值mdev_max */ tp->mdev_max = tp->mdev; if (tp->mdev_max > tp->rttvar) /* 偏差最大值大于 rttvar时,rttvar跟着变大 */ tp->rttvar = tp->mdev_max; } if (after(tp->snd_una, tp->rtt_seq)) { /* 偏差最大值小于 rttvar时,rttvar也会相应减少 */ if (tp->mdev_max < tp->rttvar) tp->rttvar -= (tp->rttvar - tp->mdev_max) >> 2; tp->rtt_seq = tp->snd_nxt; /* 每个发送周期结束,重置mdev_max为tcp_rto_min */ tp->mdev_max = tcp_rto_min(sk); } 也就是说,rtt预测偏差值rttvar会跟着实际的rtt预测偏差值变化,如果波动变大,则跟着变大,反之,如果波动变小,也会跟着变小。但因为每个发送周期内,偏差的最大值会重置为tcp_rto_min,所以,rtt预测偏差值rttvar不会小于200ms。 那这200ms的限制,有啥简单的方法调整么?继续看tcp_rto_min的代码,前面也贴过,如下: static inline u32 tcp_rto_min(struct sock *sk) { struct dst_entry *dst = __sk_dst_get(sk); u32 rto_min = TCP_RTO_MIN; /* 200ms */ if (dst && dst_metric_locked(dst, RTAX_RTO_MIN)) rto_min = dst_metric_rtt(dst, RTAX_RTO_MIN); return rto_min; } 从上面的代码可以看出,如果对应的目标的路由表项中设置了rto_min值,则以设置的值为准。这可以通过netlink机制来修改,具体可以通过ip route命令,增加rto_min选项来完成。 分析完源代码,接着试验一下。 运行下面的命令修改成20ms: sudo ip route add 123.125.104.197/32 via 10.209.83.254 rto_min 20 看以下修改后的结果: [xiaohong@localhost ~]$ ip route list default via 10.209.83.254 dev enp0s3 proto static metric 1024 10.209.80.0/22 dev enp0s3 proto kernel scope link src 10.209.80.111 123.125.104.197 via 10.209.83.254 dev enp0s3 rto_min lock 20ms 清除以下路由表的缓存,这样可以立即查看效果: sudo ip tcp_metrics flush 再测试访问weibo.com: [xiaohong@localhost ~]$ nc80 GET / 在另外的终端中确认一下结果: [xiaohong@localhost iproute2-3.19.0]$ ss -eipn '( dport = :www )' tcp ESTAB 0 0 10.209.80.111:56487 123.125.104.197:80 users:(("nc",1786,3)) uid:1000 ino:14606 sk:ffff88002c992d00 <-> ts sack cubic wscale:0,7 rto:22 rtt:2/1 mss:1448 cwnd:10 send 57.9Mbps rcv_space:14600 可以看出,本次的rtt值是2ms,rto为22ms,即已经生效。 欢迎一起讨论,拍砖也可以。呵呵。 |
随便看 |
|
在线学习网考试资料包含高考、自考、专升本考试、人事考试、公务员考试、大学生村官考试、特岗教师招聘考试、事业单位招聘考试、企业人才招聘、银行招聘、教师招聘、农村信用社招聘、各类资格证书考试等各类考试资料。