这些年不那么内卷的传输协议加速

Posted dog250

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了这些年不那么内卷的传输协议加速相关的知识,希望对你有一定的参考价值。

移动互联网和4G的发展让互联网内容变得越来越丰富也更加易得,这便促进了CDN,直播的发展,几乎所有生产内容的互联网公司都面临同样一个问题:

  • 如何将内容以最快最有效的方式送到用户的终端上。

由于几乎所有(如果不是全部)的内容都要通过要么TCP,要么UDP承载递送到对端,因此对于内容生产者而言,首先面临的就是如何对这些传输控制协议采取一些手段,让它们表现得更好。

于是几乎所有生产内容的互联网公司都有了这么一类职位:

  • 传输协议加速
  • 传输协议优化
  • TCP协议栈加速
  • TCP协议栈优化
  • QUIC…

如果对这个领域不是很了解,可能就会觉得只要对TCP协议栈实现做一些类似spinlock,hash table查找方面的优化,TCP承载的内容就会更快到达对端。确实会快那么几微秒,但这实际上传输协议优化并不关注这些。

上海开车到苏州,奥迪就一定比奥拓先到吗?未必。同样的,TCP只是车,加速效果关键要看路。

走普通道路,奥迪真不一定比奥拓先到,但是在路面状况恶劣的场景,奥迪一定比奥拓先到,这涉及到对抗恶劣状态的反馈机制是否优秀,比方说爬坡,奥迪轻松可以越过,因为动力足,扭力大,而奥拓似乎只能在平路上显得自己和奥迪速度差不多。

以TCP加速为例,对抗弱网环境的能力,可以更加直接地显示出算法的优劣。在评价TCP加速算法的时候,模拟直连机器对打是没有意义的,因为你看不出发生了异常情况,这些算法是如何应对的,事实上很难模拟出弱网环境下那些不可预期的异常。

TCP加速的一般思路都是扩大拥塞窗口,激进猛发,我是很不赞同这一点的。窗口能扩多大,这一点像CUBIC,BBR已经做得很好了,如果非要在此基础上再加那么三五个窗口配额,显然你就要为这多出来的配额导致的丢包设计应对措施,这显然是一种冒险。

即使你没有额外增加窗口配额激进发送,丢包也在所难免,这是路面性质导致的,与车无关,丢包可能因为网络拥塞,可能是线路噪声误码,和端到端协议无关,TCP能做的是如何更快探测到丢包,以及如何更快地将丢包重传恢复。

在弱网环境下,如何探测丢包,如何快速重传,这才是TCP优化的重点,而不是给拥塞窗口增加几个配额,超额发送。奥拓爬坡不行不是因为它的油装的不够。

在非弱网环境,TCP加速的要点在于选择一条更顺畅的路,依然不是为拥塞窗口增加几个配额激进超额发送。无论是天然拥塞导致的丢包,还是由于超额发送导致的丢包,重传都是必不可少的,重传一个报文就需要额外一个RTT的时间,RTT越大,代价越大,选择一条更畅通更不拥塞的路显然可以节省很多丢包重传引入的额外RTT时间。

然而TCP无法控制选路的。对于内容透明传输而言,可以用代理,分段隧道解决这个问题。无论如何,宗旨就是在减少丢包重传消耗的时间。

在丢包重传这些问题都解决了之后,比如你已经有了一个超猛的算法,可以快速探测到丢包,并且可以快速重传恢复丢包,并且已经有能力选择一条更畅通路径之后,增加发送配额才是要考虑的事。而这件事是比较有难度的。你需要一个算法去计算还能发送多少数据,该算法要有理论基础,这样才可推演,可预测,可重现。

增加发送配额的目标是提高带宽利用率,而不是投机。

作为端到端的传输协议,无论是TCP,还是基于UDP的QUIC,对于加速所要做的事情不外乎下面几点:

  • 设计一个算法,尽快发现丢包。Linux内核中的TCP拥塞状态机已经做的足够好。
  • 设计一个算法,尽快将丢包重传恢复。Linux内核中的重传机制一直在迭代优化。
  • 保证发送端的发送缓存够用,保证接收端的接收缓存够用。
  • 丢包预测,重传恢复做好的基础上,设计一个算法,提高带宽利用率。
  • 在overlay网络上规划一条畅通的路径,用代理,隧道等技术将流引入该路径。
  • 少发一个包,就能最少节省一个pacing slot的时间,最多节省一个RTT的时间。

最后一点才是核心,再畅通再快的传输也不如不传输,不要去优化本不应该存在的东西。如果应用层可以配合对数据进行编码,压缩,这种优化是比任何TCP层面的优化都要好使的。

网络数据面技术已经内卷起来了,传输协议加速还没有。这是该领域天然的anti-敏捷决定的。

一个算法无法一天一个版本地敏捷迭代,甚至根本无法做版本规划,这个领域更像是学界的范畴。

传输协议优化很难通过迭代多个版本来获得好的绩效,甚至可能一年也不一定能出来一个明确的结论,这意味着该领域几乎很难适应互联网公司的结果导向。一个好的算法并不意味着很长的代码,比如BBR算法也就1200行代码,一个C文件。在一个内卷的环境一个人用了半年时间仅仅写了一个1200行代码的C文件,这意味着什么经理很清楚,更别提可能一年都写不出1000行,这意味着很低的产出。这便是该领域不内卷的原因吧。

但这个领域挺有意思的,做得好的并不多,这意味着短期内依然卷不起来,有什么奇技淫巧的想法都可以快速动手实验测试,完全不用担心别人的产出是否超过了自己,这反而更容易带来实质上的突破。比如我自己,好几个周末我都会愉快地魔改BBR,昨天还改了一版。

是的,我曾经就是干这个的,现在虽然主业不在这领域了,然而我依然使用杠铃原理继续在做这个,有感兴趣的,欢迎一起讨论,也欢迎加入我们。对了,杠铃原理,就是《反脆弱》那本书里说的杠铃原理。


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

以上是关于这些年不那么内卷的传输协议加速的主要内容,如果未能解决你的问题,请参考以下文章

扒一扒能加速互联网的QUIC协议

E百科 | 第2期 扒一扒能加速互联网的QUIC协议

远程桌面协议浅析(VNC/SPICE/RDP)

TCP是如何实现可靠传输的?

邮件传输协议的SMTP命令

数据传输的协议