tcp early retransmit 和 rack 中神奇的 1/4 minrtt

雨中跑步十公里，沿河看柳，发了一则朋友圈：

为什么采用 1/4 minrtt 作为重传和探测的延时，上图解释的已经很清楚了，主要还是怕乱序，关于乱序的度量，上图解释得非常清楚，乱序预期可在 0.5rtt/w(相邻两个报文乱序) 到 0.5rtt(满载管道首尾报文乱序) 之间被检测到。

不管是 early retrans 前，还是 rack 判定一个报文丢失前，都要等待至少 1/4 个 minrtt，以确认事实或在此期待时间内反悔。如果 1/4 minrtt 还不足以断定，即采取措施，对于 rack 而言将延展乱序窗口，直到 srtt。

但千万别把这当教条，在早期网络或者如今的 iot 网络上，乱序可以乱几百个 rtt，只在概率上，上述推理是足的。量 = 速率*时间，这是线性保证，但现实中要按统计规律算，为啥还是算术平均 1/4 minrtt，那是算术期望，这就是排队论的事了，不多说，周末愉快。

浙江温州皮鞋湿，下雨进水不会胖。