对 Linux TCP 特性表明一个否定态度并非大不敬,而是这玩意儿没鸟用。
还是 TCP Timestamps 的精度问题,本文仅针对 Linux TCP,不针对别的实现,看一下为什么它没鸟用。
源码分析,看我添加的注释:
static bool tcp_ack_update_rtt(struct sock *sk, const int flag,
long seq_rtt_us, long sack_rtt_us,
long ca_rtt_us, struct rate_sample *rs)
{
const struct tcp_sock *tp = tcp_sk(sk);
/* Prefer RTT measured from ACK's timing to TS-ECR. This is because
* broken middle-boxes or peers may corrupt TS-ECR fields. But
* Karn's algorithm forbids taking RTT if some retransmitted data
* is acked (RFC6298).
*/
// 不要优先选择时间戳计算 RTT,但这里是另一个理由。
if (seq_rtt_us < 0)
seq_rtt_us = sack_rtt_us;
/* RTTM Rule: A TSecr value received in a segment is used to
* update the averaged RTT measurement only if the segment
* acknowledges some new data, i.e., only if it advances the
* left edge of the send window.
* See draft-ietf-tcplw-high-performance-00, section 3.3.
*/
// 到此为止,看看 seq_rtt_us,ca_rtt_us 的单位,us,这是微秒,1000 us = 1 ms
if (seq_rtt_us < 0 && tp->rx_opt.saw_tstamp && tp->rx_opt.rcv_tsecr &&
flag & FLAG_ACKED) {
u32 delta = tcp_time_stamp(tp) - tp->rx_opt.rcv_tsecr;
// TCP 时间戳单位是 ms,这里 delta 是两个 ms 相见,只有 ms 精度。
if (likely(delta < INT_MAX / (USEC_PER_SEC / TCP_TS_HZ))) {
if (!delta)
delta = 1;
// seq_rtt_us 的最小值是 1000,这里就是问题所在。
// 曾经,没有 delta = max(delta, 1),那时 delta 最小值就是 0。
seq_rtt_us = delta * (USEC_PER_SEC / TCP_TS_HZ);
ca_rtt_us = seq_rtt_us;
}
}
rs->rtt_us = ca_rtt_us; /* RTT of last (S)ACKed packet (or -1) */
if (seq_rtt_us < 0)
return false;
/* ca_rtt_us >= 0 is counting on the invariant that ca_rtt_us is
* always taken together with ACK, SACK, or TS-opts. Any negative
* values will be skipped with the seq_rtt_us < 0 check above.
*/
tcp_update_rtt_min(sk, ca_rtt_us, flag);
tcp_rtt_estimator(sk, seq_rtt_us);
tcp_set_rto(sk);
/* RFC6298: only reset backoff on valid RTT measurement. */
inet_csk(sk)->icsk_backoff = 0;
return true;
}
发生重传且没有序列被 SACKed ,若开启 Timestamps,Linux TCP 使用 tsecr 和当前 ms 的差计算 RTT,这在 ms 精度时代是个优化,但在 us 精度时代就是累赘。
上述代码来自 5.10 内核,检测到乱序或丢包时,灌入 tcp_update_rtt_min 和 tcp_rtt_estimator 的 RTT 参数最小值为 1000,这对于 IDC 网络而言实在太大了,在 50 us 级 RTT 的连接中,1000 us 就是个噪点,它会拉偏 RTT 的移动指数平均值,进而拉偏 RTO。
检测到乱序或丢包,对端立即回复 ACK,此时实际 RTT 足够小到排除掉对端任何 Delay,若丢包属于随机丢包而非拥塞,该 RTT 有希望更新 rtt_min,但为了避免精度损失导致 delta == 0 异常,增加 delta = max(delta, 1) 约束,从而将足够大的值注入计算,反而帮了倒忙。
可若不增加 delta = max(delta, 1) 约束,又会遇到 0 这个极小异常点,怎么都不行。
看下面的脚本:
#!/usr/local/bin/stap
global dsrtt
probe kernel.function("tcp_ack_update_rtt")
{
srtt = (@cast($sk,"struct tcp_sock")->srtt_us);
dport =(@cast($sk, "struct sock")->__sk_common->skc_dport);
if (dport == 0x8913) { // 过滤 iperf 端口
dsrtt <<< srtt
}
}
probe timer.s(2) {
printf("-----------\n")
print(@hist_log(dsrtt))
delete dsrtt
}
分别设置 net.ipv4.tcp_timestamps 为 1 或 0,观察一下分布,可呈现:
如果将 sack 也关闭,GBN 将持续使用 Timestamps 计算 RTT,结果就是持续值为 1000 us 的采样值被灌入移指平均计算。关掉 sack ,持续采样,不再 delete,分布如下:
所以,在 IDC 环境,请关闭 Timestamps。
在公网环境,这个问题不大,广域网 RTT 大于 1 ms,时间戳损失的精度有限,2.9 - 1.1 约等于 2,按 ms 精度计算,结果是 1,大约损失一半,这是损失的最大误差,在普遍 RTT 均大于 10 ms 的环境,偶尔的计算精度损失不会带来问题。
然而,对于 BBR ,即便精度损失不会带来计算问题,也还是会影响 BBR 的状态机。问题出在下面代码:
static void bbr_update_min_rtt(struct sock *sk, const struct rate_sample *rs)
{
struct tcp_sock *tp = tcp_sk(sk);
struct bbr *bbr = inet_csk_ca(sk);
bool filter_expired;
/* Track min RTT seen in the min_rtt_win_sec filter window: */
filter_expired = after(tcp_jiffies32,
bbr->min_rtt_stamp + bbr_min_rtt_win_sec * HZ);
if (rs->rtt_us >= 0 &&
(rs->rtt_us <= bbr->min_rtt_us ||
(filter_expired && !rs->is_ack_delayed))) {
bbr->min_rtt_us = rs->rtt_us;
bbr->min_rtt_stamp = tcp_jiffies32;
}
...
在 Recovery 状态用时间戳计算 RTT,精度损失将使 rs->rtt_us <= bbr->min_rtt_us 恒成立,进而持续 reset min_rtt_stamp,也就进不去 ProbeRTT 状态了。该问题已解决,去掉等号即可:
[PATCH net] tcp: only postpone PROBE_RTT if RTT is < current min_rtt estimate
无论如何,Timestamps 总是在帮倒忙。
如果 Timestamps 没鸟用,还留着它空消耗选项空间有何用?
- 要么改了它,像我一样改成 us 精度。
- 要么学 Google:draft-yang-tcpm-ets-00
- 要么关了它。
周末测的那版 BBR 发现一个问题,最近我总吐槽的 TCP Timestamps 精度问题还真的出了问题,换成我修改的那个 us 精度 Timestamps 后问题解决,我发现在 100 us 量级 RTT 的链路上问题更严重。梳理了之后,这是两个问题,三言两语试图说清楚。
浙江温州皮鞋湿,下雨进水不会胖。
原文链接: https://blog.csdn.net/dog250/article/details/125628259
欢迎关注
微信关注下方公众号,第一时间获取干货硬货;公众号内回复【pdf】免费获取数百本计算机经典书籍;
也有高质量的技术群,里面有嵌入式、搜广推等BAT大佬
原创文章受到原创版权保护。转载请注明出处:https://www.ccppcoding.com/archives/405451
非原创文章文中已经注明原地址,如有侵权,联系删除
关注公众号【高性能架构探索】,第一时间获取最新文章
转载文章受原作者版权保护。转载请注明原作者出处!