人们普遍对拥塞控制存在误解。

人们普遍认为设计一个牛逼的拥塞控制算法就能提高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加速的能力的,事实上,说到底,我自己也是垃圾。

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

技术
友情链接
码工具
Toolsou
API参考文档
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:766591547
关注微信