国内TCP单边“加速”的“正确”做法
我一直认为，这是一个丑行！跟几位业内的朋友交流之后，让我了解了更多。
站在相反的方向往后看，正确的做法肯定应该是避免Buffer bloat！这确实足够正确，以至于如果以鲁迅的方式看问题，这种正确的做法反而有点政治不正确了！
避免Buffer bloat，这是正确的做法，bbr，vegas，westwood，甚至cdg背后都有理论支撑并解释“为什么这么做是正确的”，然而从国内实际生产环境上产生的效果上看，这些最终都是被虐的，正确的TCP连接的吞吐量非常低，且rtt抖动到无法使用的地步。反而发现足够简单的Scalable的效果“不符合预期的好”。
-----------------------------------
TCP传输速率的单边优化，与双边优化的意义完全不同。双边优化的基础是，你要改变这个协议，或者说你要让这个协议进化。而单边优化的基础则是，你无力改变这个协议，你要寻找哪里可以来点擦边球！
做任何优化的前提都必须是，现状不够好，否则就是损人利己。如果你根本就说不出现在的TCP有什么问题，所有的优化都是跟风扯淡。
当然，国际上相关领域已经意识到了TCP的问题，即在长肥管道下灵敏度下降的问题，然而在国内，互联网带宽却根本不满足这个条件，长吗？有点长！肥吗？很瘦！如果你非要加塞，那无可厚非，你赢了，因为国人都这样，如果你不这样，如果你想保持优雅不加塞，你就输了。但这些，根本就不是TCP的问题！国人大多都是赌徒，因为缺资源。几家大型互联网公司把互联网折腾的水泄不通，以一个数据包发两遍的标准进行数据传输，这是谁的错？！难道就没人管吗？好吧，有人管，管的是迅雷这样的公司，关键是，人家也没有把数据包发两遍，人家也交的有钱。
我接触过国内搞TCP单边加速的人，不光是BAT的人，还包括很多那些假外国人(真外国人很少也干这个行当的)，其原则都是一样，要么引导大家一起加塞，要么就是搞个阴险的算法并且闭源。但是事实上，TCP网络上各个节点的关系是一个社会关系，如果你单方面一厢情愿且采取行动了，你的目的就是想钻空子加塞！人家TCP CUBIC发布后不还是提供了Friendly接口吗？为什么？为了跟传统NewReno TCP一起收敛！
一帮根本不懂网络社会生存原则的人，却在主宰着这个行业！这不是亚欧大陆，你也不是西庇阿或者凯撒，你可能只是傻逼亚历山大！我从来不觉得来自马其顿的亚历山大是一个伟人，他根本不能与西庇阿以及凯撒甚至安东尼相比，他只是在钻空子，一直钻到了印度！去殴打一个自己已经奄奄一息的波斯，算伟大吗？他只是一个收废品的罢了。
如果你不能破一尊雕像，那就不要立一堆垃圾！
-----------------------------------
我为什么总是攻击这个“丑行”，我并不攻击TCP协议本身，我攻击的是人们对TCP协议所依赖链路的无知！在这种无知的背后，恕我直言，其实是我的无知，因为他们的无知是建立在政治正确性的基础之上，他们显然知道自己的行为会造成什么后果，问题是他们可以并且愿意承担这个后果，所以说，他们的无知是鸵鸟般故意的无知。
国内的tcp单边加速技术大多数故意都违背了收敛原则，就像我们路上开车一样，随意的变道加塞几乎成了“规矩”，如果你希望与前车保持安全距离，那么必然会有车子塞入那个“安全距离”内，期间伴随着路怒症固有的鸣笛，咒骂，这种环境下，几乎每人都必须添堵，类似vegas的策略自然无路可走了。外国友人到了中国，会惊愕于我们的交通如此混乱却很少会出现事故，就像他们到了印度会发现路上机动车，非机动车，甚至牛混杂在一起却很少有事故一样。
如果你不加塞，就会有人催你加塞，如果你仍然不加塞，你就必须停车，这是典型的劣币驱良币，只因为大家都在做坏事。
为什么会这样？因为我们这里的任何资源调度系统其实都是一个过载的系统，然而大多数人认可的不是过载，而是资源利用率太低！
我们的资源利用率低的原因吗？不是算法不够优秀，更多的是因为人们自己的行为造成了资源的浪费！
我们在超市购物，在银行办事，在高速路上行驶，总是会出现以下的现象：
推着购物车等着结账的人们，队列已经排到货架处并拐了几个弯了，对侧的收银台依然不肯开放；
看似在调度上非常合理的银行叫号系统在柜员的操作下拼命地工作，却总有大量的柜台在“休眠”；
高速公路的收费站，一侧已经完全拥堵，另一侧却空空如也。
....
诸如此类，不再一一列举。算法都是同一个算法，但在执行上却是不同的效果。就算你把各种排队系统研究得非常透彻又能怎样，在一个本来就过载的场景内，任何排队系统的调度算法都是狗屎，更别提允许那些故意休眠的服务台存在了！更严重的是，大多数的排队系统是认为设置的，比如各类收费站，检查站，互联网上各种清洗设备，各类DPI设备，各类Fire Wall！
在这种“恶劣”的环境下，在任何的排队系统中，政治正确的做法就是加塞！TCP单边加速只是其中之一，远非全部。
你想修改算法换取优化，得了吧，因为算法根本就没有问题。任何文明社会里的个体，都希望获得别人的资源，但共同生存需要收敛，而收敛原则不允许这么做，于是就有了协议，就有了法律。你可以认为大家都遵守法律，我不遵守就赢了，如果大家都这么想，那就只能集体灭亡。
-----------------------------------
对于TCP拥塞控制而言，我早就说过，我们的TCP发送速率慢与拥塞控制无关，而与你的胆量和经验有关！
对于传输大小低于初始拥塞窗口的文件而言，最短平快的做法就是一次性把数据包全部发出去，最后3个包发两遍。稍微带点技巧的方式就是重叠冗余发送，越往后冗余度越高。除此之外，研究什么高深的算法，基本上都是扯淡。
最直接的办法，你一次性把所有数据包都发出去，其实是在赌博，换句话说，你在做一个一锤子买卖！任何的TCP拥塞控制算法，都有拥塞后减窗这个逻辑，旨在退避，或者对主动造成拥塞者进行惩罚，你的一锤子买卖的精妙之处在于，如果你赌博赢了，TCP拥塞控制逻辑想要惩罚你的时候，数据已经发送完毕，连接结束，你的目的已经达到。如果你赌输了，比如出现了丢包，那么后续到达的数据包会触发快速重传，你将有机会进行第二次赌博，为了这个第二次赌博尽快开局，你必须让一些冗余数据为你探路。对于小文件传输，这绝对是一场罪与罚的博弈！
那么，对于大文件的传输，在事故过后，无论如何你也逃不过惩罚，我的观点就是，在保证自己不出事的前提下，越激进越完美！我比较推崇的是最简单的Scalable算法，因为它的AI过程与之前的窗口无关，仅与ACK时钟的驱动频率有关，每收到一次ACK就会将窗口固定增加0.01(Linux默认为0.02)，这样无论如何，收到100次ACK窗口就会增加1个MSS，非常简单！为什么我觉得这个算法比那些其它的让人看起来高大上的算法更合适呢？因为它“不用测量任何东西”。我并非反对测量，而是在持续过载的系统中，大多数测量值是不可用的，至少是不准的！
-----------------------------------
这里插一点形而上的东西...
我相信人们的群体行为是十分固定的，到了什么时间就会做什么事情，而包括TCP传输在内的所有事件都是人们的群体行为驱动的，所以，我相信网络带宽情况在多个周期内都是相同的，就好比虽然道路是一个统计复用系统，单独一次通过的路径并不固定，但是几乎我每天下班到家的时间都是晚上7点14分(在上海时，这个时间是8点25分)，下雨天顺延20分钟左右。
基于这个信念，加之大数据分析，我可能有能力将国内网络带宽的时间空间分布时空图绘制出来，但这件事是一件政治不正确不值得做的事情，就算是做，也只能默默地做，或者拉拢圈内好友一起来做。
这里穿插的内容看起来正是“测量”要做的事，然而此测量不是彼测量！
-----------------------------------
我认为那些复杂的算法之所以能运行，全建立在对各种参量的测量的基础之上，比如测量RTT，比如测量带宽等，结果的准确性也由这些测量值的准确性决定。那么如果这些值根本没有办法测量准确，就别指望模型可以正确运行了。现在的问题是，这些参量根本无法被正确测量！承蒙一位网友提醒，以SACK为例，TCP头的SACK option中只能容纳有限的SACKed段，在特定场景下，这就会造成带宽测量的不正确，这是TCP协议选项本身的缺陷导致的！
如果你连测量都搞不定，你还能搞什么呢？我越发觉得，搞这个行当的人真的好可怜，每天都很疲惫，因为他们根本不懂实情。我承认，我也一样，我也是傻逼。
我为什么推崇Scalable算法，因为它简单！因为它简单到不需要解释。
Scalable可以在收到固定的50个ACK后将拥塞窗口增加1个MSS，而诸如那些复杂的算法，比如CUBIC，在很大的BDP情况下，要在收到大约BDP个ACK后才将拥塞窗口增加1个MSS。Scalable与任何因素都无关，它只与ACK到达的速率有关，只要ACK持续到达，拥塞窗口就持续固定增长，很傻逼但很有效的方法，难得糊涂。
-----------------------------------
拥塞控制的本质在于“避免发送超量的数据”，然而实际上在大多数人的理解中却成了“尽可能多的发送多的数据以不吃亏”，持这种观点的人认为，如果不去抢资源，那资源就会被别人抢走，自己就亏大了，大家都这么想，那么可想而知，结局就是水泄不通！为何不换种思路呢？为何不去觉得自己现在所持有的资源是别人让出的呢？如果大家都这么想，资源利用率一定会收敛到100%！
我觉得这背后还是信任问题。中国社会在秦统一后2000年的时间里从来没有享受过一次资源合理化分配，不可能塑造人人为我，我为人人的心理。任何人可以从任何行业看到类似的现象，TCP加速，道路加塞，高考加分，各种促销加量不加价...类似的现象，统一的丑行。
站在相反的方向往后看，正确的做法肯定应该是避免Buffer bloat！这确实足够正确，以至于如果以鲁迅的方式看问题，这种正确的做法反而有点政治不正确了！
避免Buffer bloat，这是正确的做法，bbr，vegas，westwood，甚至cdg背后都有理论支撑并解释“为什么这么做是正确的”，然而从国内实际生产环境上产生的效果上看，这些最终都是被虐的，正确的TCP连接的吞吐量非常低，且rtt抖动到无法使用的地步。反而发现足够简单的Scalable的效果“不符合预期的好”。
-----------------------------------
TCP传输速率的单边优化，与双边优化的意义完全不同。双边优化的基础是，你要改变这个协议，或者说你要让这个协议进化。而单边优化的基础则是，你无力改变这个协议，你要寻找哪里可以来点擦边球！
做任何优化的前提都必须是，现状不够好，否则就是损人利己。如果你根本就说不出现在的TCP有什么问题，所有的优化都是跟风扯淡。
当然，国际上相关领域已经意识到了TCP的问题，即在长肥管道下灵敏度下降的问题，然而在国内，互联网带宽却根本不满足这个条件，长吗？有点长！肥吗？很瘦！如果你非要加塞，那无可厚非，你赢了，因为国人都这样，如果你不这样，如果你想保持优雅不加塞，你就输了。但这些，根本就不是TCP的问题！国人大多都是赌徒，因为缺资源。几家大型互联网公司把互联网折腾的水泄不通，以一个数据包发两遍的标准进行数据传输，这是谁的错？！难道就没人管吗？好吧，有人管，管的是迅雷这样的公司，关键是，人家也没有把数据包发两遍，人家也交的有钱。
我接触过国内搞TCP单边加速的人，不光是BAT的人，还包括很多那些假外国人(真外国人很少也干这个行当的)，其原则都是一样，要么引导大家一起加塞，要么就是搞个阴险的算法并且闭源。但是事实上，TCP网络上各个节点的关系是一个社会关系，如果你单方面一厢情愿且采取行动了，你的目的就是想钻空子加塞！人家TCP CUBIC发布后不还是提供了Friendly接口吗？为什么？为了跟传统NewReno TCP一起收敛！
一帮根本不懂网络社会生存原则的人，却在主宰着这个行业！这不是亚欧大陆，你也不是西庇阿或者凯撒，你可能只是傻逼亚历山大！我从来不觉得来自马其顿的亚历山大是一个伟人，他根本不能与西庇阿以及凯撒甚至安东尼相比，他只是在钻空子，一直钻到了印度！去殴打一个自己已经奄奄一息的波斯，算伟大吗？他只是一个收废品的罢了。
如果你不能破一尊雕像，那就不要立一堆垃圾！
-----------------------------------
我为什么总是攻击这个“丑行”，我并不攻击TCP协议本身，我攻击的是人们对TCP协议所依赖链路的无知！在这种无知的背后，恕我直言，其实是我的无知，因为他们的无知是建立在政治正确性的基础之上，他们显然知道自己的行为会造成什么后果，问题是他们可以并且愿意承担这个后果，所以说，他们的无知是鸵鸟般故意的无知。
国内的tcp单边加速技术大多数故意都违背了收敛原则，就像我们路上开车一样，随意的变道加塞几乎成了“规矩”，如果你希望与前车保持安全距离，那么必然会有车子塞入那个“安全距离”内，期间伴随着路怒症固有的鸣笛，咒骂，这种环境下，几乎每人都必须添堵，类似vegas的策略自然无路可走了。外国友人到了中国，会惊愕于我们的交通如此混乱却很少会出现事故，就像他们到了印度会发现路上机动车，非机动车，甚至牛混杂在一起却很少有事故一样。
如果你不加塞，就会有人催你加塞，如果你仍然不加塞，你就必须停车，这是典型的劣币驱良币，只因为大家都在做坏事。
为什么会这样？因为我们这里的任何资源调度系统其实都是一个过载的系统，然而大多数人认可的不是过载，而是资源利用率太低！
我们的资源利用率低的原因吗？不是算法不够优秀，更多的是因为人们自己的行为造成了资源的浪费！
我们在超市购物，在银行办事，在高速路上行驶，总是会出现以下的现象：
推着购物车等着结账的人们，队列已经排到货架处并拐了几个弯了，对侧的收银台依然不肯开放；
看似在调度上非常合理的银行叫号系统在柜员的操作下拼命地工作，却总有大量的柜台在“休眠”；
高速公路的收费站，一侧已经完全拥堵，另一侧却空空如也。
....
诸如此类，不再一一列举。算法都是同一个算法，但在执行上却是不同的效果。就算你把各种排队系统研究得非常透彻又能怎样，在一个本来就过载的场景内，任何排队系统的调度算法都是狗屎，更别提允许那些故意休眠的服务台存在了！更严重的是，大多数的排队系统是认为设置的，比如各类收费站，检查站，互联网上各种清洗设备，各类DPI设备，各类Fire Wall！
在这种“恶劣”的环境下，在任何的排队系统中，政治正确的做法就是加塞！TCP单边加速只是其中之一，远非全部。
你想修改算法换取优化，得了吧，因为算法根本就没有问题。任何文明社会里的个体，都希望获得别人的资源，但共同生存需要收敛，而收敛原则不允许这么做，于是就有了协议，就有了法律。你可以认为大家都遵守法律，我不遵守就赢了，如果大家都这么想，那就只能集体灭亡。
-----------------------------------
对于TCP拥塞控制而言，我早就说过，我们的TCP发送速率慢与拥塞控制无关，而与你的胆量和经验有关！
对于传输大小低于初始拥塞窗口的文件而言，最短平快的做法就是一次性把数据包全部发出去，最后3个包发两遍。稍微带点技巧的方式就是重叠冗余发送，越往后冗余度越高。除此之外，研究什么高深的算法，基本上都是扯淡。
最直接的办法，你一次性把所有数据包都发出去，其实是在赌博，换句话说，你在做一个一锤子买卖！任何的TCP拥塞控制算法，都有拥塞后减窗这个逻辑，旨在退避，或者对主动造成拥塞者进行惩罚，你的一锤子买卖的精妙之处在于，如果你赌博赢了，TCP拥塞控制逻辑想要惩罚你的时候，数据已经发送完毕，连接结束，你的目的已经达到。如果你赌输了，比如出现了丢包，那么后续到达的数据包会触发快速重传，你将有机会进行第二次赌博，为了这个第二次赌博尽快开局，你必须让一些冗余数据为你探路。对于小文件传输，这绝对是一场罪与罚的博弈！
那么，对于大文件的传输，在事故过后，无论如何你也逃不过惩罚，我的观点就是，在保证自己不出事的前提下，越激进越完美！我比较推崇的是最简单的Scalable算法，因为它的AI过程与之前的窗口无关，仅与ACK时钟的驱动频率有关，每收到一次ACK就会将窗口固定增加0.01(Linux默认为0.02)，这样无论如何，收到100次ACK窗口就会增加1个MSS，非常简单！为什么我觉得这个算法比那些其它的让人看起来高大上的算法更合适呢？因为它“不用测量任何东西”。我并非反对测量，而是在持续过载的系统中，大多数测量值是不可用的，至少是不准的！
-----------------------------------
这里插一点形而上的东西...
我相信人们的群体行为是十分固定的，到了什么时间就会做什么事情，而包括TCP传输在内的所有事件都是人们的群体行为驱动的，所以，我相信网络带宽情况在多个周期内都是相同的，就好比虽然道路是一个统计复用系统，单独一次通过的路径并不固定，但是几乎我每天下班到家的时间都是晚上7点14分(在上海时，这个时间是8点25分)，下雨天顺延20分钟左右。
基于这个信念，加之大数据分析，我可能有能力将国内网络带宽的时间空间分布时空图绘制出来，但这件事是一件政治不正确不值得做的事情，就算是做，也只能默默地做，或者拉拢圈内好友一起来做。
这里穿插的内容看起来正是“测量”要做的事，然而此测量不是彼测量！
-----------------------------------
我认为那些复杂的算法之所以能运行，全建立在对各种参量的测量的基础之上，比如测量RTT，比如测量带宽等，结果的准确性也由这些测量值的准确性决定。那么如果这些值根本没有办法测量准确，就别指望模型可以正确运行了。现在的问题是，这些参量根本无法被正确测量！承蒙一位网友提醒，以SACK为例，TCP头的SACK option中只能容纳有限的SACKed段，在特定场景下，这就会造成带宽测量的不正确，这是TCP协议选项本身的缺陷导致的！
如果你连测量都搞不定，你还能搞什么呢？我越发觉得，搞这个行当的人真的好可怜，每天都很疲惫，因为他们根本不懂实情。我承认，我也一样，我也是傻逼。
我为什么推崇Scalable算法，因为它简单！因为它简单到不需要解释。
Scalable可以在收到固定的50个ACK后将拥塞窗口增加1个MSS，而诸如那些复杂的算法，比如CUBIC，在很大的BDP情况下，要在收到大约BDP个ACK后才将拥塞窗口增加1个MSS。Scalable与任何因素都无关，它只与ACK到达的速率有关，只要ACK持续到达，拥塞窗口就持续固定增长，很傻逼但很有效的方法，难得糊涂。
-----------------------------------
拥塞控制的本质在于“避免发送超量的数据”，然而实际上在大多数人的理解中却成了“尽可能多的发送多的数据以不吃亏”，持这种观点的人认为，如果不去抢资源，那资源就会被别人抢走，自己就亏大了，大家都这么想，那么可想而知，结局就是水泄不通！为何不换种思路呢？为何不去觉得自己现在所持有的资源是别人让出的呢？如果大家都这么想，资源利用率一定会收敛到100%！
我觉得这背后还是信任问题。中国社会在秦统一后2000年的时间里从来没有享受过一次资源合理化分配，不可能塑造人人为我，我为人人的心理。任何人可以从任何行业看到类似的现象，TCP加速，道路加塞，高考加分，各种促销加量不加价...类似的现象，统一的丑行。