在IDC内部，如果你还遵循传统为广域网而生的拥塞控制逻辑做事，那就错了。当然，我下面说的也不一定都对。
正确的做法就好像我之前说的一种情况的反例，那种情况是，让你优化长肥链路传输，你却在优化spinlock。IDC的情况相反，把前面的例子反过来说，把spinlock换成ECN(可扩展)就对了。但这就够了吗？
广域网传输优化只能基于RTT为周期，你有足够的时间利用足够的资源去做运算，但IDC内部这么做不太现实，在IDC内部，任何误判的代价都会被放大，一个5us的延时除了做重传之外几乎做不了任何事，再靠盲猜，靠复杂计算积累学习就比较扯了。
如果盲猜不行，那怎么做行？不是有ECN吗？
ECN可以通告拥塞，但无法控制调度，怎么还需要调度？
无论你将IDC网络看作是PCIe，还是把主板总线看作是CLOS变体，其实都是一回事，两者也变得越来越无法区分。不把IDC网络看成是网络和把主机内部看作网络是一回事，既然大家对主机优化积累了这么多经验，就把IDC网络看成是一个主机的内部好了，用资源调度的思路去优化它就好了。说白了就是仲裁流能不能通过，就像调度task那样去调度流。
既然可以将task迁移到另一个CPU上，显然也就可以将流量迁移到另一个交换机。
我在上周的文章里说了，DCTCP应该优待突发短流而惩罚长流，这并没有问题，事实上这是唯一的措施，因为如果不这样，怎么做都是错：
- 突发短流和长流均不惩罚？这就是常规cc的做法，那就任由其丢包吧。
- 惩罚突发短流？已经拥塞了，突发短流得不到服务，长流半天才能恢复。
- 突发短流和长流双双惩罚？任何流都会受到影响，服务受损。
所谓的惩罚长流并未影响任何流的延迟，相反，正因为同时惩罚了所有流但相对狠地惩罚了长流，才保证了所有流的延迟均不增加。
但相对狠地惩罚长流只是事情的一个方面，为了缓解拥塞，毕竟长流来日方长，暂时的损失可以被时间稀释。但事情还有另一方面。如果长流也是FCT敏感的呢？任何吞吐的损失都会带来FCT的延期，又当如何？得让长流的数据包告诉交换机才是，这就需要在端主机对数据包进行分类打标。
那么这个时候惩罚谁呢？换一条不拥塞的路径即可，这就是所谓流量调度的意义。
总的来讲，把IDC网络看作是一个整体的资源池就好了，剩下的就是最大化这个资源池的利用率了。这个思路和MPTCP有些像，但我觉得MPTCP在广域网上效果不一定好，但在IDC网络不妨一试。
以上都是拥塞控制，传输优化还有另一面，流量控制。
TCP不好做并行传输，因为要保序，一旦有空洞窗口就憋住了。有人想过这个问题吗？
针对小内存主机，长肥管道，TCP只能做串行，因为哪怕一个空洞，至少一个BDP的数据憋住，所以在早期，即便是SACK都不现实。假设TCP可以忽略序列号的连续发送，将很消耗内存。另一方面，补充这个空洞无论如何至少也要到一个RTT，30ms量级的RTT内并行传输产生新的空洞的概率很大，最终传输将崩溃。
对于IDC网络这种超短超肥管道，事情起了变化。10us量级的RTT几乎和协议栈处理时延属于同级，协议栈的重排序和重传可以同步进行，一系列传输行为将流水线化：
- 发送端：发送，重传
- 接收端：排序，反馈
即便有空洞，窗口也不必憋住，因为传输和重传是并行的，传输只管传输，重传只管重传，保序操作在接收端完全和TCP解耦，它可以作为一个独立的逻辑存在，比如有些流不需要保序。
其实，只要不要求流式，TCP的什么问题都解决了，把重排序加一个层次来做。但比较悲哀的是，大部分问题都是工程问题，而不是算法问题。如何保证兼容性，是最大的问题。
最后不妨说说性能优化的边际效益递减。
第一个找到关键热点并将其优化掉的，收益会很大，这个人肯定会获得丰厚的奖励。大家纷纷模仿，但却陷入了内卷，几乎没什么拿得出手的产出。
一个系统不可能存在多个独立热点，即便有多个，也是相关联的，符合幂律分布，抽掉第一个，后面的都不是问题。
拥塞控制领域，CUBIC是一个创举，和之前Reno/BIC相比，是个飞跃，之后的那些算法都很拉胯，直到2016年BBR的出现，又是个飞跃，再往后所有针对BBR的优化同样拉胯。无论是CUBIC还是BBR，事后看，都很简单，但为什么大家都没想到？反而等这些都出来后，纷纷挑毛病，觉得这里可以改，那里可以调，这就是走火入魔。
性能优化最关键的那一步其实不难，大家都没想到恰恰因为大家都希望优化一个已有系统，而不是去做一个新需求。Google意识到网络带宽利用率不高，定位了Bufferbloat根因，就开发了BBR。如果包括Neal在内的Google人把一天天的时间花在优化CUBIC上，那几乎也同样拉胯。
所以还是要系统看问题，而不是只盯着某些点挑毛病找bug拿大奖，真正的大奖都藏在系统，且一般只有一个。
不知不觉，近年来做优化的越来越多，做功能的越来越少，有时Demo还没出来就开始考虑优化，有时都没有找到关键热点就开始考虑优化…如果我说很多人都在优化用不到的东西，那这句话必然是忠告。
考虑一个做了点手脚的骰子，1点那面重一点，大概1.2/6的概率吧，有个人凭肉眼发现了这个骰子不公平，在押注时押1点稍微多一点，赢了不少钱就走了，其余人一拥而上，有的allin了1点，有的买来了精密仪器去测量算计这个骰子，企图发现更加确定性的事实…结果，大家总体上是血亏的，即便是微赢的那些专家，扣掉买设备的钱，也不剩多少了。我们要学第一个人，去发现并解决关键问题，而不是去优化已经被发现的关键问题。
有人会问我自己扯这么多，有做过什么拿得出手的作品吗？事实上是没有的，我也不是唯作品论者。
但我是做过的，在BBR之前，我曾经做过Westwood和Vegas的结合，差一点就改成了BBR，效果比CUBIC好很多，我赢在考虑到了实时测量bandwidth，并监控RTT的增加，主动probe后再次测量监控，抛弃AIMD做主动收敛，这就是BBR的思路，我相信我已经找到了关键点，但我输在了编码能力太差，没能写出Delivery rate的测量代码，直接借用了Westwood的实现，所以效果不如预期。我的目的是希望具有良好编程技术的人可以读懂这篇文章。
浙江温州皮鞋湿，下雨进水不会胖。