博客探讨了Linux系统中，由于delay_ack机制导致的TCP BBR速率骤降问题。尽管升级内核能解决此问题，但并未直接禁用或改变delay_ack行为。作者通过分析吞吐曲线和间隔时间，发现内核更新后的关键变化在于BBR pacing机制由qdisc层转移到hrtimer实现，从而避免了配额计算错误。
前一篇说到delay_ack对应数据包采样值带宽值很不巧刚好更新了带宽，造成了速率的陡降的问题。客户表示升级了linux系统也能解决问题，但是升级所有线上机器的内核周期太长。升级内核版本为何能修复这个问题呢？新内核版本并没有禁用delay_ack，也没有增加delay_ack情况下不进行带宽更新操作。所以还需要弄明白是新版本的内核是哪个变更规避了delay_ack带来的影响。
重新仔细看了下吞吐曲线图，实际上4分钟内不止出现了4次码率掉底问题，比较明显的就出现了6次，还有好几个很快就恢复吞吐量下降的点，为何会出现有的恢复快有的恢复慢呢？于是从新回到的出问题点，看看是如何恢复。比较奇怪的点，是发生带宽陡降之后的几次带宽采样，rs->interval_us前面几次都接近40ms，之后几次降低到20ms左右，而从wrieshark到图上来看实际的interval_us应该之后9ms左右，而且之后几次interval_us图上看起来是us级别的值，但是打印出来的却是20ms附近的值。
所以需要知道int
最低0.47元/天 解锁文章
639
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
