人们普遍对拥塞控制存在误解。
人们普遍认为设计一个牛逼的拥塞控制算法就能提高TCP的传输性能。
人们普遍认为拥塞控制是为优化存在的。
不仅仅如此。
人们普遍认为有意义的事都是为优化而存在的。
我记得我高中的时候，数学老师讲完一道题的巧妙解之后，我总是在下面嚷嚷我还有更麻烦的方法来解这道题，我的意思是不想等下课了大家一个个来问我问题，与其如此，我还不如公开一种大家都懂但更麻烦的方法呢，当大家都在追求奇技淫巧时，我显得有点特立独行。
与此类似，TCP的拥塞控制就是一种麻烦的方法，加上拥塞控制机制之后，数据可能传输的更慢而不是更快了，带来的是大家公平畅通，所谓不患寡而患不均。如果你想更快，那就不要拥塞控制。
很多搞TCP加速的个人或者公司，寄希望于设计一个牛逼的拥塞控制算法，这种思路是多么的幼稚，大错特错。他们没完没了地阅读各种算法的paper，甚至不看正文直接跳到最后的对比数据，企图寻找一种碾压CUBIC，碾压BBR的新算法，然后在这个新算法的基础上魔改，胡乱改一些参数，把小数改大，把13改成23这种，然后拿着一些偶然的数据去抑扬顿挫。
其实网吧打游戏的或者做web的人都比这些专业TCP加速的人理解得更正确。
这些人很明确地希望去掉拥塞控制，去掉AIMD操作，有数据时直接发包就是了，这难道不是更正确的做法吗？
可能有人知道APPEX，这家公司的做法就很 “正确” ，它们只要保证自己不和自己打架，几乎是不会进行拥塞控制的。所谓的TCP加速，你需要去设计一个什么时候发包的逻辑，而不是去设计一个控制窗口或者控制速率的发多发少的逻辑。
把红绿灯的意义看成是为了让你的车跑的更快，这不是笑话吗？在一个限速且有红绿灯的道路上，你想加速？如果你不违章超速，如果你不闯红灯，你想加速？
来点真实的场景。极端点说，在直连独享带宽的情况下，把窗口写死成网卡速率和RTT的乘积，你就能得到最快的速率，然而现实中却根本不可能存在这种环境，你拿这个环境下测得的数据去忽悠人，这不是欺骗吗？
RTT为什么会剧烈抖动？带宽测量为什么不靠谱？但这些都是常态，不靠谱的是你的认知。
你以为网络上的流量都在拉大文件吗？你以为大家都在看直播吗？你以为一个固定的源到固定的目的地之间的路径是固定且唯一的吗？事实上网络上大部分的流量都是一次或几次pingpong的流量，一个连接的生命周期不超过几个RTT，这种不可预见且突发的流量才是网络的常态！
看看开车的，骑电瓶车的以及公交地铁上的人们，看走路的，坐在沙发上以及躺在床上的人们，有多少是在做大文件传输呢？ 是什么动机让他们拉取一个超过一个屏幕大小的数据呢？人眼浏览一屏所需的时间是秒级的。
绝大多数都是胡乱划来划去打开一个页面再关闭，打开一个视屏再下一个吧。每一次数据传输的时间大概也就是几个到几十个RTT，没有人能预测谁会在什么时候请求一个一屏幕大小的图片或者文字，这才是互联网的常态！
只有你在安装新app前下载该app安装包的时候，才会涉及到那么几十M，几百M的稍大的文件传输。再加上时不时的更加不可预测且不可管理的UDP流量，事情就更加不利用TCP加速了。
在这种海量无法预测的，短时间突发的，转瞬即逝的流量海洋中如何加速，你作为一个长连接在那傻乎乎的测量带宽并且预测丢包，这不是犯傻吗？你预测的那些行为都是一些早已逝去的连接引发的，人家都已经事了拂衣去了。
按照网吧打游戏的人或者做web的人理解，单纯加大初始窗口就能解决绝大多数问题了，别的什么都不用做。在我看来他们是更懂TCP加速的。
与其在一个长连接里搞不靠谱的TCP加速，还不如搞几个固定1000000000000000初始窗口的fastopen短连接呢，明白人看出来了，哈哈，运营商不支持fastopen怎么办？这个问题让网吧打游戏的人或者做web的人殴打你一顿就知道答案了。
又有人想跟我提APPEX，我承认那些人的算法牛逼，但我还是不看好，我不觉得这种灰色的东西可以长久持续下去，互联网上公平的速率才是正确的，这是一种博弈正确，任何企图加速的都是垃圾。
但凡涉及这个话题，我都是喷的态度，但工作归工作，态度是态度，尘归尘，土归土，我个人也是有TCP加速的能力的，事实上，说到底，我自己也是垃圾。
浙江温州皮鞋湿，下雨进水不会胖。