备案 网站服务内容,坪山医院网站建设,免费建设网站的好么,朔州网站建设价格低网络物理层丢包是一种需要偿还的债务#xff0c;可以容忍低劣的传输质量#xff0c;这为 UDP 类服务提供了空间#xff0c;而对于 TCP 类服务#xff0c;可以用另外两类代价来支付#xff1a;
主机端采用轻率的 GBN 策略恢复丢包#xff0c;节省 CPU 资源#xff0c;但…网络物理层丢包是一种需要偿还的债务可以容忍低劣的传输质量这为 UDP 类服务提供了空间而对于 TCP 类服务可以用另外两类代价来支付
主机端采用轻率的 GBN 策略恢复丢包节省 CPU 资源但浪费网络带宽主机端采用极其谨慎的 SACK 策略恢复丢包浪费 CPU 资源但节省带宽
无论哪种都属于异常处理路径可靠传输协议丢包总要恢复省是省不了的要么用 CPU 换带宽要么用带宽换 CPUTCP 协议已经可以将策略完美配置在两个极端。
上述两类策略我特意加上 “轻率” 和 “谨慎” 修饰以表明标准版 GBN 和 SACK 是恢复丢包的最小代价CPU 和 带宽是决策的两端。我写这个目的在于表明但凡你稍微给 GBN 或 SACK 加戏就要付出额外代价结局是既浪费了 CPU 又浪费了带宽。
来举两个例子先看 GBN我们知道 GBN 几乎不费 CPU只要超时或 3 次 dupack 立马就重传 snd_una 到 snd_nxt 间所有段如果你发明一个新的 GBN 算法加入了比超时和 3 次 dupack 更复杂的丢包判断由于重传动作省不了就额外增加了丢包判断的 CPU 消耗。
再看 SACK从相关 RFC 中我们看到 TCP SACK 谨慎到鉴别 scoreboard 每一个段的状态虽然 RACK 后有所松散但依然保持谨慎的底色这意味着作为 GBN 反面的 SACK 不希望浪费一个段的带宽但如此复杂的状态鉴定显然需要更多 CPU如果你发明了一个更加 “高效” 的 SACK 算法希望丢包能更加快速恢复势必要冒险重传不该重传的段精确鉴定省不了多发的额外重传段却浪费了带宽。
那么是否存在一个交易点在这个点位重传动作更快开始恰到好处的精确丢包判定恰到好处的精确重传。理论上这个点肯定存在但实际上根本找不到因为端到端传输协议携带的信息量根本不足以找到这个点TCP/IP 框架下的传输协议的网络度量在本质上是不可观测的比如 RTT 和 delivery rate 根本无法测准。
若要解决测不准问题要么需要协议携带更多信息这增加了协议头开销要么端网协同这增加了转发节点的计算和状态存储开销本质上还是交易在分布式复杂系统中买卖的收益是递减的也就是说增加一个机制会引入该机制本身的消耗而它带来的收益却只是解决一个不值得解决的问题。
在现实中我们经常看到类似不值得做的事只要它工作的还不至于糟糕就让它继续工作。
解决丢包重传问题的根本方法就是升级底层网络提高线路质量提高交换容量。自下而上才能起到优化效果而自上而下只能规避问题是为 workaround这一点上TCP 用最小代价处理(而不是解决解决只能靠物理层链路层)丢包恢复已经足够好。如果算法上没有明显的缺陷优化效果几乎只能自下而上呈现而 TCP GBN 和 TCP SACK 没有缺陷。
So还做什么 TCP 传输优化现有信息量约束下每做一个新策略都是在同时浪费 CPU 和带宽同时浪费公司的钱。
还有另一类丢包值得关注即拥塞丢包它不是问题相反它是功能。就像感冒和醉酒一样拥塞丢包是一种功能性信号如何处理拥塞也像如何治疗感冒和醒酒一样常规。在统计复用系统中没有任何机制可以避免拥塞丢包问题在于用最小的代价回应拥塞答案都在 AIMD 或测度方法里不赘述。
浙江温州皮鞋湿下雨进水不会胖。
