惯常TCP吞吐优化均在发送端激进传输，比如一个报文发两遍，盲目扩大cwnd此类。将这种动作称作“猛推”，就必然存在是“猛拉”，即在接收端做一些把戏。

还有一天放假，愉快一下～

如今的TCP都普遍启用了RACK来进行丢包检测和重传，它的机制如下：
​
RACK比旧时的“收到reordering个dupACK/SACK即触发重传”空间序启发式算法更加合理且优雅，它基于时间序，乱序的探测和容忍亦纳入时间序。

若接收端检测到丢包，最好让发送端尽快重传，否则发送端就要等到RACK窗口后才重传，做法很简单：

• 当收到乱序报文回复ACK时，保持ACK字段不变，SACK一个未来到达的报文。

未来到什么时候呢？取大致大于上图wnd即可。这里有几个问题：

• wnd如何测量？
• 真乱序则如何？
• 提前SACK影响发送端测量RTT。
• 提前SACK的报文没到则何如？

wnd测量很容易，若双向传输，取minRTT/4即可，若单向传输，可向发送端发送探测报文探测RTT。
若真乱序呢？这需要在接收端设一个打分机制，如果真乱序+1，假乱序-1。

SACK未来报文使发送端测量RTT变小。这没什么，在发送端检测到RACK LOST之后，缩短的RTT反而会使重传时瞬时pacing rate变大，增加推背感，但不持续，否则BDP就小了，最终cwnd limited。

最后，如果提前SACK的报文丢了怎么办？大概率不会，若预期时间没有到达，reneging即可，此举可能会让发送端延迟半个RTT，取决于实现。不过反正也是赌博，下注难收。

由于大概率UNA会推到未来SACK报文之前，即便wnd估算过长，发送端也不会过多标记LOST造成过度重传。

若希望继续用SACK未来报文的方式触发重传而免除reneging带来的等待，则需通告一个至少1.5倍的rwnd，如此发送端便可继续SACK透支未来的报文。

相当于猛踩油门不刹车，透支对前面路况的信心，最关键是，自己对时间的感知一定要准！

对于推流场景，我之前还玩过一个效果不错的把戏。

很多推流数据并不做校验，在接收端收到乱序报文时，为了不停等，直接用全0自行补洞，然后回复积累ACK，促使发送端推进UNA，推动滑动窗口，减缓卡顿。

不过我也说过，虽然这些把戏不正规，用TCP传输视频流也不正规。如今几乎所有业务都在重用实在太好用的HTTP/1.x，而它over TCP，造成了万物over TCP的局面。等HTTP/2or3吧。

反正也是划水，说点TCP发送端的。

我想在RACK开启时干掉TCP拥塞状态机，RACK完全基于时间序已不再基于scoreboard mark lost，只需要注释掉2行代码：

bool tcp_time_to_recover(struct sock *sk, int flag) 
{ struct tcp_sock *tp = tcp_sk(sk); /* Trick#1: The loss is proven. */ // 下面两行注释掉！ //if (tp->lost_out) //        return true; /* Not-A-Trick#2 : Classic rule... */ if (!tcp_is_rack(sk) && tcp_dupack_heuristics(tp) > tp->reordering) return true; return false; 
} 

但需在RACK mark lost之后将REXMIT_LOST置位，即可在Open状态触发重传，新报文和重传报文不再区分，统一发射，而cwnd就只是一个令牌桶了。

没有了Recovery状态，拥塞控制算法就不会被接管，这要求cc算法一定要好。弱网是一个挑战，是该激进还是该保守，大抵是判断不准的，在不知所措的时候，保守便不会错，这便是Linux TCP当前的做法，所以，在弱网环境，最好把拥塞状态机请回来。

不要觉得Recovery状态是必不可少且理所当然的，事实上它是为Reno准备的，而Reno是Tahoe的优化。随后，BIC本质上也是Reno，BIC的优化版CUBIC本质上依然是Reno，BBR不再是Reno，所以BBR不需要Recovery才是理所当然的。
除了RTO，在RACK之前，dupACK是判断丢包的唯一方式，而后开始重传，这些事件导致了TCP某种状态的切换，冠名为Open，Disorder，Recovery，仅此而已。

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