盗版小说网站怎么做,如何用ppt形式做网站,物联网技术主要学什么,网页制作基础教程我的足球网从历史和文化内涵的视角看 TCP 协议的优势和局限#xff0c;这些都刻在基因里。节约和经济获得向下兼容#xff0c;但这也意味着它没有浪费带宽的本意#xff0c;任何相左的优化策略终将遇到无法解决的困难#xff0c;大致就这样#xff0c;这为设计新协议提了意见#x… 从历史和文化内涵的视角看 TCP 协议的优势和局限这些都刻在基因里。节约和经济获得向下兼容但这也意味着它没有浪费带宽的本意任何相左的优化策略终将遇到无法解决的困难大致就这样这为设计新协议提了意见别抄 TCP否则就容忍继承它的一切。 最近看了一份考古文献来自范雅各布森(VJ)The original Van Jacobson memo它讲的是一个正常流优化的故事即坊间著名的 “30 instruction TCP receive”。
结合相关 RFC 和实现讨论一下 TCP 的文化内涵。
如果过度关注 TCP 性能会发现这实际上是与 TCP 的核心思想相违背的而 TCP 核心思想能用两个字总结“节约” 或 “经济”。
RTO 被认为是个兜底策略总是被各种优化试图绕开这是从快速重传(rfc1072VJ88)开始的这些优化逐渐模糊并偏离了 TCP 的内涵给人 “优化可以一直持续下去” 的错觉现在我们很清楚很多困难根本无法解决。
VJ 开启了 TCP 优化但这种优化风格却最终终止了优化从 RTO 开始结束于无解的 rate-based cc大致我们可以看清这个过程。
TCP 作为一个端到端协议经过多跳收到确认所需时间的概率密度函数图像随着距离的增加越发矮胖这意味着 RTT 预测非常困难这是固有的。举例说明去阳台拿个东西超过 10 秒就会被催去 500 米外买东西20 分钟到 30 分钟都是允许的因为过路口排队结账都不可预期去 30 公里以外上班1 小时到 2 小时之间都合理。
RTO 最终被确定为 R T O S R T T γ ⋅ R T T V A R RTOSRTT\gamma\cdot RTTVAR RTOSRTTγ⋅RTTVAR
其中 R T T V A R β ⋅ R T T V A R ( 1 − β ) ⋅ ∣ S R T T − R ∣ RTTVAR\beta\cdot RTTVAR(1-\beta)\cdot|SRTT-R| RTTVARβ⋅RTTVAR(1−β)⋅∣SRTT−R∣ S R T T α ⋅ S R T T ( 1 − α ) ⋅ R SRTT\alpha\cdot SRTT(1-\alpha)\cdot R SRTTα⋅SRTT(1−α)⋅R
VJ 的著名参数 α 7 8 , β 3 4 , γ 4 \alpha\dfrac{7}{8},\beta\dfrac{3}{4},\gamma4 α87,β43,γ4 多少有些随意“调得一手好参数” 并不能被人信服但 “容易计算” 似乎是一个更好的理由仅用简单的移位加减就能快速计算正体现了节约和经济这与文初的引用连接的思想完全一致这就是 VJ-Style。
粗看起来节约似乎和优化在结果看来都是 “速度更快”但也仅仅是结果一致。“更快” 只是节约的顺便而不是它的目标。这个文化内涵让 TCP 可运行在所有设备上就像 Linux 和猫科动物适应所有环境向下兼容的高尚正由此文化内涵体现向下兼容确实好。
节约和经济决定了 TCP 的保守。
TCP 尽量少处理异常因为异常处理需要比正常流执行更多的指令这意味着节约和经济的反面。如文初链接所体现要让正常流变得普遍就要让异常不发生这决定了传输策略的保守够用但不逞强。一个具体的例子就是 “重传期间不更新 SRTT”我前面专门说过这个遗憾源自 TCP 最初的内核就是上面这段话的意思。同时这也决定了测量 TCP 的 RTT 真的很难即便如今已经为其添加了那么多 feature依然摆脱不了这个难题。
另一方面对指令的节约为我们设计新传输协议也指明了方向空间换时间设计更大的序列号空间避免回绕问题剪除 PAWS设计更大滑动窗口空间剪除 WSCALE设计更大的端口号空间剪除端口分配的把戏。
再看看这种文化内涵的背景摩尔定律吉尔德定律的曲线即便已经弯折通信速度的提升仍然快于计算速度的提升为计算速度而不是带宽来做优化是划算的。软件开发中有一个类似的例子不要优化代码而要等待更新的硬件。
在这种背景中孕育的文化的影响下TCP 不会故意注入更多数据到网络以获得更大的吞吐因为这种为吞吐而进行的赌博需要更多的异常处理来兜底赌输的情景这与节约和经济的文化内涵不符。这也是近些年各种为带宽而做优化的算法效果普遍不好的原因因为这与 TCP 的内核相左于是人们开始纷纷研发新协议。
让我们再看看现实马上就会明白为什么 TCP 不再合时宜也就知道新协议应该怎么做。
网络带宽越来越大虽然从计算的视角看依然要节约但带宽却是可是浪费的于是 TCP 在 2010 年代遭遇带宽利用率不足的问题也就是不足为奇了。我们看一下 VJ-Style 的 loss-based 拥塞控制模型设 B 为吞吐带宽p 为容忍丢包率 B α ⋅ p β B\alpha\cdot p^{\beta} Bα⋅pβ这个公式对 p 要求过高了要想获得更大吞吐p 必须足够低低到超过介质的传输误码率极限。
这意味着若要适配高速网络这个模型必须被废弃BBR 只解决了理论问题因为互联网规模已经足够庞大全网如何平滑切换到一个仅仅吞吐较高但尚未论证稳定性和公平性的算法风险何其大。
在尚未有能力切换到一个 “完备的下一代协议” 之前来看 TCP 的解法会存在哪些问题并给出新协议的建议。
随着网络越加长肥TCP 反馈慢的代价越大如果网络过长拥塞信号至少 1 个 RTT 的反馈时间就显得很慢而如果网络同时又过肥这 1 个 RTT 的时间段中 sender 会注入非常大量的数据到网络从而加重拥塞。CDN 的部署缓解了这个问题但远未解决。
虽 CDN 已大量部署但静态资源的需求逐渐减少随着直播流量占比增加传统远距离高吞吐认知中的长肥管道拥塞问题会越来越严重。
在本质上避免反馈的协议才是正确解法receiver 主导的拥塞控制或许要胜过 sender 依赖的确认反馈但如何让 sender 对拥塞快速反应就依赖层间协作了。
总之不光 TCP连同整个 TCP/IP 协议族都不太适应越来越高速的网络和本文前面说的节约的文化内涵一致这也是整个 TCP/IP-based 互联网的文化内涵而它源自旨在抵抗核打击的 DARPA。
分组交换带来的收益一定需要付出成本来交换成本之一就是性能。
so是层间解耦与高速网络不适应那耦合它们呢很难。
幸运的是这条路在数据中心完全可以走通(infiniband? roce?)总之网络越往高速发展就越不可抗拒地将设计推回到面向连接的电路交换。 范雅各布森的 style 就是 TCP 的文化精髓谨慎保守精细。如果你问 srtt 的 α 为什么是 1/8rto 的 β 为啥是 4真是调得一手好参数吗非也因为 2 的次幂容易算啊这不但迎合了低端机器也迎合了 Linux 内核不支持浮点数顺便和统计概率吻合而已只有 1% 的概率超过 4 确定的平均方差边界道出了统计复用动力学的本质。在遥远的 1980 年代为计算速度而不是带宽优化已经开始成了信条最终成了文化。 浙江温州皮鞋湿下雨进水不会胖。
