常州网站建设套餐昭通建网站

当前位置： 首页 > news >正文

常州网站建设套餐,昭通建网站,wordpress代码主题,天津武清网站建设分享一个 TCP 面试题#xff1a;单条 TCP 流如何打满香港到旧金山的 320Gbps 专线#xff1f;(补充#xff0c;写成 400Gbps 更具迷惑性#xff0c;但预测大多数人都会跑偏#xff0c;320Gbps 也就白给了) 这个题目是上周帮一个朋友想的#xff0c;建议他别问三次握手单条 TCP 流如何打满香港到旧金山的 320Gbps 专线(补充写成 400Gbps 更具迷惑性但预测大多数人都会跑偏320Gbps 也就白给了) 这个题目是上周帮一个朋友想的建议他别问三次握手慢启动快速重传何时发 RST 了来个情景分析吧。 如果候选人提到 TCP 序列号空间 4GB香港到旧金山往返 200ms320Gbps 管道容量 8GBTCP 最大窗口受限无法这个管道至于后面说与不说都算通过了。上来就 BBR 的还得继续问三次握手。 下面是这个题目的解析。 先求一下 TCP 最大窗口。 在 32bit 的 unsigned int 圆环域上两个数字顺时针间隔在一个半圆内才能无歧义比较大小(参考 Linux kernel 的 beforeafter 宏定义) 如上图的无歧义共识TCP 窗口最大值被限制在 2^31 字节以内。 此外根据 TCP 滑动窗口原理sender 和 receiver 的窗口之间最大可相差一整窗
因此TCP 窗口的最终最大值为 2^³¹⁄₂ 2^30 字节。这是 TCP 窗口上限即 1GB。200ms 链路TCP 最多只能打满 1GB*⁸⁄₀.2s 160Gbps 的带宽。 如果允许稍微 patch TCP如何填满 8GB 管道呢这是个更有趣的问题。 Netflix 有个直接的方案扩展序列号空间64-bit Sequence Numbers for TCP 我这里重点说另一个 PAWS Pacing 方案。 timestamp 是个天然升序标识每 1ms 滴答一下32bit timestamp 回绕一次要 49 天值得使用。 320Gbps 40GBps大约 1ms 发出 40MB 数据即每 100ms 发生序列号回绕。但只要控制 sender 的 pacing rate每 1ms 送出 40MB 数据就可将 rwnd 最大值扩至 2^31不再受回绕限制 道理很简单1ms 粒度 pacing相当于为 seq 增加了额外的顺序号按 timestamp 编号每 40MB 数据receiver 对 100 个 1ms 和 1ms 的 40MB 数据归并排序即可恢复 send 顺序
注意timestamp 指的是原始报文传输时的时间即便发生重传其timstamp 还是原始那个。 若发生丢包由于 “since the sender and receiver windows can be out of phase by at most the window size【RFC1323-2.3】”sender 和 receiver 之间最大 2^31 相差在 2^32B 范围内每个 seq 只出现一次以 timestamp 做序号自然不会有歧义。 大致算一下 2^31B 的窗口用 timestamp 做顺序号可以支撑多大的带宽。以 timestamp 的 1ms 精度1ms 至少需要将 2^32 的两个半圆区分开1ms 标识 2^31B 数据即 16Tbps 2TBps 的带宽。
进一步设想若 timestamp 精度达到 us所支撑的带宽将继续扩大但系统开销也随之扩大由于二者非线性关系所以我不敢说 1000 倍。 以上是理论值计算考虑到丢包乱序拥塞控制等因素理论值几乎达不到但它展示了一种可能性。 万变不离其中我经常强调单调递增编码 packet并设计新协议但实际上 timestamp 就是一个天然编码标识它确实编码了 “packet(每一个 segment 包含若干 byte)”而非 Byte stream。 byte 大小固定没弹性byte-based 滑动窗口没扩展性带宽越大传输字节越多越快回绕。而 packet 不固定它提供 1B mss B 的弹性且 mtu 可随底层传输技术发展而增加(如巨帧)显然 packet-based 滑动窗口可扩展性更佳。可见2^32B 4GB 的序列号空间直接参与传输和确认不适应长肥网络不过在 byte/packet-based 滑动窗口争论正当时(参见The design philosophy of the darpa internet protocols 第 10 节)管道既不长更不肥选择 byte-based 没毛病。 回到这个面试题为什么不能上来就说 BBR因为 cwnd limit 前先碰到 rwnd limit这才是硬伤是壁垒。所以必须先解决 rwnd limit 问题突破 rwnd 限制至于 BBR只是优化。 这个题目主要考察 3 个点首先是对 TCP 协议头字段的理解主要是 seq 和 wcale option其次是对数字的敏感比如东亚到加州湾区的时延再次就是根本问题和次要问题的甄别能力刚接触 BBR 的可能觉得 BBR 能解决一切问题从而把根本问题疏忽了。 至于更多讨论参见另一篇文章流控问题两则。 现在来看可靠保序传输的本质。 要在 receiver 恢复 sender 端顺序需顺序标识数据。将数据顺序装入 packet然后顺序标识 packet 即可但这个我已说过太多现在看如何顺序标识数据本身。 TCP 序列号算一种顺序标识但它会面临回绕歧义。TCP 将最大窗口限制在 2^30B 消除了歧义但同时也限制了其填充长肥网络的能力。在引入 timestamp 后可重新审视这个问题。 无论 seq space 多大它终究被定义在环形域上(计算机算术一切数据类型都在环形域)环形域无歧义比较大小需在一个半圆内当这个环形域不够大时就会遇到 TCP 一样窗口限制但若将这个环形域定义足够大却可能占用额外报头空间最好就是根据实际所需将环形域定义成变长(比如 QUIC)。但还有别的解法。 当我们发现时间序是一个天然顺序后这个环形域便可分级解释就像 MMU 分级页表一样。将顺序标识分为两层外层是时间序内层是环形域的半圆设序列号空间 m 位timestamp 精度为 n只需要在 1 个 n 时间内能最大识别 2^(m-1)B 即可也就是说同一 timestamp 编码一个半圆。 m 32n 1ms 就是 TCP 的情况解释是只要在 1ms 内发送数据不超过 2^31B 即可。2^31B 就是 2GB对于 TCP它可以支撑的带宽为 2TBps与 RTT 无关。对于 receiver执行两层归并排序首先将时间分割为精度为 n 的 slot根据 timestamp 将报文对应到 slot再根据 seq 将报文在该 slot 内排序 为什么 RTT 消失了 RTT 并没消失它回绕需要太久的时间以至于可以将它近似为绝对单调递增量前面算过以 1ms 精度滴答的 timestamp 发生回绕需要 49 天远超一个报文在互联网上最长逗留时间当然如果处在比地球大的多的星球这一点需要修正。 这里有一个 packetization 过程一个 slot 即一个 packetization 单位内容是一个没有歧义的半圆内的 seq。 原始报文的 timestamp 时间序和 seq 字节序共同消除了保序歧义另一面为保证可靠传输丢包重传还需要一个报文( whatever 原始报文 or 重传报文)实际发送的时间序列号用来消除原始报文和重传报文的歧义这个虽然不是流控必须的但对拥塞控制意义重大不得不察但这方面我强调过太多不再啰嗦。 现在可以和 Netflix 的方案(见上面链接)对应了二者殊途同归Netflix 方案直接采用了 64bit 序列号而 PASW Pacing 也使用 64bit 序列号只是将它分为了 32bit 原始序列号和 32bit timestamp 两层。在我看来PAWS Pacing 更灵活可以适配不同时钟精度和不同带宽。 所以我有个建议TCP 在同时启用 timestamp 和 wscale 时wscale 需另作解释将其最大值限制在 15 而不是 14而 timestamp 也另解释为顺序号为 2 倍的滑动窗口(即以 wscale 最大值 15 取代 RFC7323 规定的 14)消除回绕歧义。 从刚毕业参加工作面试一直到此后的 10 年多被面试官问了无数次 TCP 三次握手为什么三次TimeWait快速重传之类的问题自己作为面试官也问了候选人无数次这般问题我上一次被问这些是大约 5 年前但也差不多从那时起我也不问候选人这些问题了我想了一些更好玩的比如 “如何用 TCP 实现不可靠传输(考察 ACK/SACK/滑动窗口)”“如何旁路修改传输中的 TCP 数据(考察 RFC5961)?” … 正好有朋友也厌倦了上面那些老掉牙的问题要我帮忙新出一个面试题问题已经被问过所以延迟一周写下本文。 浙江温州皮鞋湿下雨进水不会胖。