关于 TCP 与 100Gbps+ 场景的细说,参见:单流 TCP 100Gbps+ 难题的直观解释

400Gbps 网络将又是一个 “硬件准备好了,可软件没跟上” 的场景。

把一条 TCP Flow 看作一个操作系统进程,多条 Flow 共享 10Gbps 带宽和多进程被同一个 CPU 调度一样。
我们知道,SMP 场景下,应用程序和操作系统需要重新设计,将原来的大块逻辑拆得粒度更细,以便并行,同时,操作系统尽量避免争锁,比如 Linux 内核大量采用 per-cpu 变量。数据结构互不依赖,细逻辑便可自由在多个核心并行乱序执行。

但以上这段话发生地极其缓慢,从我记忆中的 2006 年开始,直到今天很多逻辑依然没有完成改造,这是 “硬件准备好了,软件没跟上” 的典型一例。

400Gbps 网络将是另外一例,不管厂商叫得多欢,软件难题依然改变不了挑战。

我来用 400Gbps 场景重写上面那段话。

我们知道,400Gbps 场景下,端到端传输协议和交换机需要重新设计,将流拆得粒度更细,以便并行传输和处理,同时,交换机尽量避免将多个流安排到同一个队列,避免 HoL。数据包 or subflow/flowlet 前后互不依赖,便可自由在多条路径乱序传输并被端主机多核资源负载均衡处理。
就差指名道姓了,说的就是传统 TCP。

先看端能力的问题。

TCP 的保序性约束同一个流不能并行传输和处理。简单算一笔账,单流 400Gbps 吞吐需要每秒收发 (400/8)10001000*1000/1460 个数据包,大致 34246575 个,即每微秒处理 34 个数据包。

大致估算一下 25Gbps 场景下 Intel® Xeon® Platinum 8260 CPU @ 2.40GHz 的收包能力,关闭 GRO/LRO,下图三栏分别为 top/iperf -s -i 1/funclantency tcp_v4_rcv 的结果:

一款不错的 CPU 单核极限能力不到 10Gbps,发送端关闭 TSO/GSO,接收端 CPU 下降,但 tcp_v4_rcv 的执行能力已达上限,接收端打开 GRO/LRO,tcp_v4_rcv 开销变大,达到 1500us 以上。

双边启用硬件卸载,志强 CPU 的 TCP 单流处理极限大约在 60~80Gbps。

TCP 协议逻辑过于复杂,这意味着更多的 CPU 指令周期,难有 CPU 能支撑 20ns~30ns 处理一个 1460 字节的数据包(或者 80ns~200ns 处理一个更大的 LRO 聚合数据包)。

既然单个 CPU 不行,多个总可以。32 个 CPU 并行,妥妥 1us 处理 30+ 个数据包。但 TCP 需要保序,不允许并行处理同一条流。这便是一个简单的障碍。

如果允许乱序传输,上述瓶颈即可被打破。我说 TCP 不适合 400Gbps 网络,这话并不过分。一定是便于并行处理的乱序传输协议才更适配 400Gbps。

对于非 TCP 协议,仍然受限于 CPU 的指令周期处理极限以及内存带宽极限,越复杂的协议逻辑有效吞吐越低,虽然通过堆 CPU 核数能有所优化,但专用硬件显然更适合适配 400Gbps。

各类 Hardware offloading 方案,RDMA/RoCEv2 只是开端。

再说拥塞控制。

范雅各布森管道理论,瓶颈 buffer 等于 BDP 可在 AIMD 策略下获得最佳带宽利用率,buffer 小于 BDP - alpha 为浅队列,buffer 大于 BDP + alpha 属深队列。各类端到端拥塞控制算法孰优孰劣便围绕着 buffer 大小展开。

400Gbps,40us 链路,BDP 达 2MB,需更大 buffer 平滑统计突发,但更大 buffer 承受更大突发的同时,在大收敛比节点也要承受更大扇入,引入更大延迟,影响公平性。同时,更大的 buffer 意味着更大的成本。

虽然 PFC,ECN 机制已经可逐跳或者端到端反馈拥塞,但却不得不以额外延时为代价。即便如此,绝大多数数据都可在 1 个 RTT 无反馈传输完毕(400Gbps BDP 约 MB 级别)而无缘 ECN 之惠。

说到底,如今的拥塞控制机制几乎全依赖反馈到端执行,中间节点没有一种简单的分流能力。

比方说,一个端口发生拥塞,交换机立即将流量引导到稍微空闲的等价路径。而该机制需要不同于传统最短路径路由的新基础设施来支撑。虽然 SDN 控制器可提供支撑,但分布式方案目前尚未存在。

Google 的 PLB 提供了重新选路的思路,但依然需要将拥塞反馈到端后由端执行 re-path,考虑流的 Multi-Path,乱序传输,需要由端来综合调度拥塞信息。

由于收敛比,扇入的存在,拥塞不可避免,高吞吐与低延时看似不可兼得。但该结论显然来自传统的假设,端到端传输协议控制数据流沿着最短路径到达对端。在 400Gbps 场景,反过来更合适,即哑端专用硬件盲发数据包,数据包沿着多条路径乱序传输,转发节点以分流,反压的方式进行拥塞控制,可同时获得高吞吐和低延时。

简单举一例,一服务器网卡按照 400Gbps 发送(而不是传统单流),其中一个或几个数据包属于某类低延时敏感业务,由于途中交换机某端口拥塞,这些数据包不得不忍受排队,而对它们标记 ECN 毫无意义,因为它们属于单数据包(此类数据包非常多)。

无论对于短消息还是长流,即时处理拥塞总是低延时的最佳选择:
与端到端原则的 TCP/IP 协议栈相反,400Gbps 场景的传输控制协议族,复杂性从端移到了中心,第一时间处理拥塞代替反馈拥塞,这是低延时的核心。连带效果,端在传输逻辑方面的弱化也将更多资源留给了计算,端资源给计算,中心资源给传输。

只要 TCP 深刻在你心里,你可能就不明白我说的 “依赖反馈” 到底意味着什么。再举一例,假设瓶颈带宽达 400Tbps (而不是 400Gbps),你要在 40us 的链路传输 100MB。简单算一下,100MB 大概需要 68493 个 1460 字节的数据包,仍假设初始窗口 10(很不合理),慢启动阶段,窗口随 RTT 倍增,大概不到 12 个 RTT 就能传完 100MB,而慢启动尚未结束,诸如 BBR 复杂的逻辑不起作用。如果初始窗口因大带宽改为 100000(很合理),一个初始窗口即可完成传输,甚至慢启动也不需要,至多一次丢包反馈后重传。

或者说就问一句,如果不依赖反馈,如何进行拥塞控制。端到端算法可榨取的收益早已捉襟见肘,需修改中心的算法才能有所改变。

400Gbps 准备好了,人们依然指望 TCP 可适配,一个进程无法充分利用 SMP,一条 TCP 也无法跑 400Gbps,人们一开始用多个进程去跑 SMP,现在人们用多条 TCP 跑满 400Gbps,显然,后者粒度太粗,正如进程粒度太粗一样。核心还是分割可并行单元,进程之外可调度更细粒度的线程,协程。同理,重写传输协议可实现消息粒度(介于数据包和传统数据流之间)并行传输和处理,当 “X程” 在多核上无阻塞调度时,消息也在网络无排队分流。

总之,无论从端能力还是拥塞控制来看,400Gbps 网络受上层逻辑约束越少越好(与直觉相反,比如,如果网卡不认识五元组,便可将每个数据包分发到不同的 CPU):

  • 消息短小则数据包之间无依赖,可有效利用端主机资源并行处理。
  • 消息短小则数据包之间无依赖,可有效利用多等价路径乱序传输。
  • 不存在长流,交换机更看不到长流,长流要切成短消息乱序传输。
  • 400Gbps 网络只管传输,不管协议逻辑。

显然,硬件准备好了,可软件还没跟上。但早晚会跟上,各类 RDMA,Homa,以及 AWS 的 SRD 已经在路上,拭目以待。

最近跟朋友聊起 100Gbps,200Gbps,400Gbps 网络,总觉得这玩意儿能跑起来吗,在协议层面尚未 ready 时,会不会造成浪费。联想修高速公路,一般双向 8 车道就顶配了,剩下的就是提升限速和提升安全车速,而不是增加车道,所以我觉得为什么不去研究空心光纤呢,将光纤传输速率提升到光速的 80%+(不细说,容易被民科)。… 想到 TCP 诞生的 1970s,网速远小于主机处理速度,它的一切协议逻辑都是合理的,适应彼时硬件的,一路发展到网卡将要逆袭 CPU,CPU 反而成了外设的当今,TCP 反而成了鸡肋,还是有点适者生存的进化理念的,什么样架构的硬件,就需要什么样的软件与之搭伴,否则硬件就是没有竞争力的。正如 CSMA/CD 搭伴了同轴电缆,迅速以简单易部署占领了市场,才发展到如今的百Gbps,软件伴随硬件的强化而升级,比较有趣,写篇随笔。

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

400Gbps 网络面临的挑战相关推荐

  1. 5G时代渐行渐近 移动承载网络面临新挑战

    随着5G商用脚步的临近,5G技术日益成为业界焦点,5G承载方案研究也被提上日程.如何继续发挥以太网优势,又满足5G时代要求,是移动承载领域面临的新挑战. 近几年来,随着移动互联网和物联网市场与业务应用 ...

  2. ISME:微生物网络构建与分析面临的挑战

    关注我们 一起探索微生物领域的奥妙 摘要 微生物网络作为当下一种流行的数据分析方法被广泛应用于微生物群落研究.虽然目前已有许多并不断有新的微生物网络构建方法被开发出来,但与数据预处理.混杂因素.网络评 ...

  3. 5G网络的关键技术及特点,面临的挑战!

    01  5G关键技术 超密集组网:5G需要满足热点高容量场景(高流量密度.高速率) 超密集组网:大量增加小基站,以空间换性能 基站一般包括:宏基站和小基站 宏基站:即"铁塔站",一 ...

  4. 运营商网络采用SDN所面临的挑战(一)

    运营商网络采用SDN所面临的挑战(一) Babak Samimi 将数据平面.控制平面与管理平面分隔开来所实现的软件定义网络(SDN)改善了OPEX及CAPEX,并且使得网络资源的集中调配和管理成为可 ...

  5. 网络空间安全有哪些定义?我国网络空间安全面临哪些机遇?我国网络空间安全面临哪些挑战?

    1.网络空间安全有哪些定义? (1)我们常说的网络空间,是为了刻画人类生存的信息环境或信息空间而创造的词.早在1982年,移居加拿大的美国科幻作家威廉•吉布森William Gibson在其短篇科幻小 ...

  6. 《实施Cisco统一通信管理器(CIPT2)》一1.6 拨号计划方面面临的挑战

    本节书摘来异步社区<实施Cisco统一通信管理器(CIPT2)>一书中的第1章,第1.6节,作者: [美]Chris Olsen 译者: 刘丹宁, CCIE#19920 , 卢铭 , 陈国 ...

  7. MPLS服务采购面临哪些挑战?

    毫无疑问,特定运营商在特定区域的网络传输效果优于其竞争对手.也就是说,要想清楚地了解一个国内特定运营商能够提供的实际效果和功能对企业的影响,需要进行一些详细的分析.因此,我们建议创建一个射频识别(信息 ...

  8. 深度研究 | 区块链在征信业的应用探讨:切中了痛点,但也面临四大挑战

     深度研究 | 区块链在征信业的应用探讨:切中了痛点,但也面临四大挑战 雷锋网按:本文由中国信息通信研究院和腾讯研究院区块链联合课题组的王强.卿苏德.巴洁如所作.转载自公众号腾讯研究院.雷锋网(公 ...

  9. 视频传输面临的挑战和解决之道

    音视频行业的发展,用户对音视频画质的清晰度.播放的流畅度.互动的低延迟.突破终端限制等的要求越来越高.这些需求从客观上对视频的传输提出更高的挑战,而目前不同业务的视频传输方式各有不同,如何基于视频传输 ...

最新文章

  1. squid代理(传统代理)
  2. spring面试重点
  3. Redis,传统数据库,HBase,Hive区别联系
  4. [译]Stack View 自定义间隙
  5. 第三课--EFM32GG11系列--串口接收不定长度数据的几种方式
  6. PHP 更高效的字符长度判断方法(转)
  7. centos系统下安装python3以及pip3
  8. 率土之滨鸿蒙之初,率土之滨:最记仇联盟?投诚玩家结算前被乱世,称是主盟要求...
  9. Hadoop |集群的搭建
  10. html5怎么在画布怎么旋转,javascript – 如何旋转HTML5画布的现有内容?
  11. ThinkPad特有设计和特色软件
  12. 菜鸟学自动化测试(八)----selenium 2.0环境搭建(基于maven)
  13. cuteftp pro 3.2多线程下载导致文件MD5校验值改变
  14. 我是如何在开源系统中(Vue)中引入阿里巴巴Icon图标的?
  15. 阿里 酷家乐:实习生面试
  16. 高效技巧篇:化繁为简、高效使用金蝶K3WISE(金蝶K3WISE-主控台编辑)
  17. 请定义一个方法用于判断一个字符串是否是对称的字符串,并在主方法中测试方法。例如:“abcba“、“上海自来水来自海上“均为对称字符串。
  18. 数据挖掘之OneR算法(原来数据挖掘如此简单!)
  19. Sql执行平时都很快但是偶尔就会很慢
  20. java基础小记_Java基础学习小记--多态

热门文章

  1. 第1章第8节:如何删除、复制和隐藏幻灯片 [PowerPoint精美幻灯片实战教程]
  2. python文件中单词的删除_使用python删除文件中的多余单词
  3. ERP系统在元器件贸易企业中的应用
  4. 如何进入互联网行业,成为产品经理?没有项目经验如何转行当上产品经理?
  5. 基本数据结构——线性结构(有序表)
  6. 前端js导出Excel库(js-export-excel)在React/Vue中使用参考
  7. 我还是不用百度免费的CDN好了!
  8. 《认知天性》告诉我们如何学习
  9. 今年国家高新技术企业认定,审核要求有变?
  10. rstudio线性回归_R语言统计分析(一元线性回归和多元线性回归)