我想创个网站,需要网站建设的是哪一类人,安徽建设项目建设工程在线,项目管理软件免费前面提到过 ECMP 和 TCP 之间的互不友好#xff0c;pacing 收益和中断开销的互斥#xff0c;在事实上阻碍了 packet-based LB 的部署#xff0c;也限制了交换机#xff0c;服务器的并发性能#xff0c;同时潜在增加了 bufferbloat 的概率#xff0c;而适用 packet-based …前面提到过 ECMP 和 TCP 之间的互不友好pacing 收益和中断开销的互斥在事实上阻碍了 packet-based LB 的部署也限制了交换机服务器的并发性能同时潜在增加了 bufferbloat 的概率而适用 packet-based LB 的短突发老鼠流又无法承受 TCP 的建连开销向后兼容的普遍刚性意味着几乎所有基础设施若不迁就 TCP其崭新特性难尽其功。
虽在广域网领域很难改变现状但在数据中心仔细读上段文字理解了掣肘间前因后果之后在做双边传输优化或自研新协议之时我们将获得启发。下面以最小修改 TCP 为例描述一个原教旨多路径 TCP 的构建过程。
我们的目标不是多路径多路径只是手段我们的目标是充分利用基础设施的并发能力提高资源利用效率只不过在数据中心普遍的 CLOS 架构下多路径的策略非常合理且容易实现因为 CLOS 在拓扑上本身就是 ECMP 原生的。问题转化为如何让 TCP 支持按 packet 分发在宏观上充分利用 ECMP 能力在微观上让转发节点解除流约束充分利用硬件多处理能力让硬件变得更简单自然也就更高效。
若要 TCP 数据分发可按 packet 而不是 5-tuple-flow 执行如何最小化修改 TCP这个问题很有趣。
MPTCP 的路子显然把问题复杂化了因为 MPTCP 是以 TCP 为基准的多路径协议而不是以底层网络为基准的。交换机和服务器处理 MPTCP 的行为不能有任何不同每一个 subflow 仍是一个 5-tuple-flow这在底层的视角看和标准 TCP 并无不同。TCP 流式约束只约束端并不约束网络转发节点TCP 又无法区分乱序和丢包所以 TCP 在对待乱序需要非常谨慎而严格避免无效重传。
TCP 的方式是维护一个 reordering 度量在该度量的约束下TCP 以重复 ACK 或 SACK 立即回复乱序状态将处理收敛到 sender 的 update scoreboard 算法。
若以底层资源为基准来分析自然就会有另一种不同于 reordering 度量但却更自然的方法处理乱序。如果底层网络是严格按照 packet 分发数据包的那跑在该网络上的传输协议天然就是多路径的因为乱序几乎是必然的所以必须对乱序宽容而宽容的方式自然就是提供一个时间窗口 w在该时间窗口 w 之后再以重复 ACK 或 SACK 回复乱序状态。
这将是最简单的支持 packet-based 多路径分发的方法sender 端无需任何改动这才是真正的多路径 TCP无论底层网络如何实现这种 w-based MPTCP 都可兼容例如在传统的 5-tuple-flow 分发的网络中w 将等于 0相当于标准 TCP 收到乱序报文后立即回复 ACK/SACK。问题转化为 w 的计算问题。
设带宽为 B已知的或测得的RTT 为 T已知的或测得的若单路径送达C (B*T)/MSS 则为单路径报文容量若 n 路径送达每条路径承担 C / n 报文到达时间为 T / n因此需容忍等待 w T - T / n 时间n 可通过测量实际 delivery_rate 和 B 之比获得。
除了在延迟 w 之后按照标准 TCP 的方式发送重复 ACK/SACK 外还可以直接发 NACK但这就要修改更多代码了。
如果底层网络是一个不丢包的无损网络将不再需要区分乱序和丢包而在现实中底层网络的误码丢包率本就很低加之 w-based MPTCP 充分利用 ECMP 路径反过来极大均匀分发了流量几乎避免了拥塞因此这种方式大有可为。
最后这是一个思想不针对 TCP只是用 TCP 最容易讲明白记住若不是 TCP可在双边交互更多信息这需要设计更好的协议头。
浙江温州皮鞋湿下雨进水不会胖。
