网站建设项目心得体会,代运营公司的套路,typecho对比wordpress,php网站开发应具备能力一个关于时延统计分布的小测试#xff0c;用 netem delay jitter distribution pareto 模拟#xff0c;得到下面的结果#xff1a;
netem 的 jitter 并不是真 jitter#xff0c;只是通过延时阻滞部分报文模拟 jitter#xff0c;对保序流而言#xff0c;就表现为乱序用 netem delay jitter distribution pareto 模拟得到下面的结果
netem 的 jitter 并不是真 jitter只是通过延时阻滞部分报文模拟 jitter对保序流而言就表现为乱序如下图所示通过 ack 号和时间戳均能看出
netem 的局限有目共睹这里不纠结。问题是如果现实中真的发生 ack 乱序会怎样。
Linux kernel TCP 单独处理了 old_ack
if (before(ack, prior_snd_una)) {goto old_ack;
}
...
old_ack:/* If data was SACKed, tag it and see if we should send more data.* If data was DSACKed, see if we can undo a cwnd reduction.*/if (TCP_SKB_CB(skb)-sacked) {flag | tcp_sacktag_write_queue(sk, skb, prior_snd_una,sack_state);tcp_fastretrans_alert(sk, prior_snd_una, num_dupack, flag,rexmit);tcp_newly_delivered(sk, delivered, flag);tcp_xmit_recovery(sk, rexmit);}return 0;注意 tcp_sacktag_write_queue 调用它会将 sack_block in old_ack 累加到当前 tp-delivered 字段累加过去的 sack_block 会过估当前 delivery rate。
这是一个明确的 ack 乱序导致的 tp-delivered 延后累加先再次解释 delivery rate 的计算方法
找到当前 ack 中被 ack/sack 的最晚发送的报文 p确认 p 被发送的时间 t_p 及当时成功 delivered 的数据量 n_p计算速率 r (n_curr - n_p) / (t_curr - t_p)
整件事可用下面的 tcptrace 时空图解释
当 old_ack 到达时发送的报文被 ack 后迟到累加的 tp-delivered 对带宽的过估影响才能消除。否则在 sack_block in old_ack 的实际核算区域计算 delivery rate 时均要减去本 sack_block 覆盖的数据量由于 old_ack 迟到造成的此前带宽低估就随它去吧。
这个修改背后的思想是合理的任何时间序列(而不是空间)中历史的误判不应让未来买单要及时止损否则可能面临双倍惩罚。如果前面一个 rtt 低估了带宽低估就低估吧不要以下一个 rtt 高估带宽来弥补。
像 bbr 类 rate-based 算法低估带宽不可怕它自己的状态机(比如 probe up)能搞定但高估带宽甚至直接打乱状态机的正常运行比如 buffer 以非预期方式被占用竟然因为高估带宽而不是 probe up则 0.75x drain 就没用了就像飞机失速很难改出一样。
简单的例子bbr 流故意高估带宽带来更大的 delivery rate 被记住几乎没有任何机制排空 buffer这是个相当不稳定的状态。如果抖动真由 buffer 带入很容易由于瞬时 minrtt 造成带宽高估(这也是 netem 靠乱序模拟抖动时吞吐更高的原因但凡有几个极小的 rtt 就赢了)将状态机引入难以控制的未知。
本文内容实在想不通就考虑 old_ack 丢了但丝毫不影响传输的场景丢就丢了呗为什么要为过去的事揪心呢迟到了就是晚了就当它丢了得了。为过去的事搅乱当前的安排(schedule)不值当那就干脆点全部干掉好了广义地说maybe undo 和 maybe retrans 也不要才好那就把 old_ack 这个 label 去掉吧。
皮鞋没有蹬上露着白袜子。
浙江温州皮鞋湿下雨进水不会胖。
