北京治疗白癜风在那个医院比较好 https://wapjbk.39.net/yiyuanzaixian/bjzkbdfyy/xcxbdf/Gbps网络将又是一个“硬件准备好了，可软件没跟上”的场景。
把一条TCPFlow看作一个操作系统进程，多条Flow共享10Gbps带宽和多进程被同一个CPU调度一样。
我们知道，SMP场景下，应用程序和操作系统需要重新设计，将原来的大块逻辑拆得粒度更细，以便并行，同时，操作系统尽量避免争锁，比如Linux内核大量采用per-cpu变量。数据结构互不依赖，细逻辑便可自由在多个核心并行乱序执行。
但以上这段话发生地极其缓慢，从我记忆中的年开始，直到今天很多逻辑依然没有完成改造，这是“硬件准备好了，软件没跟上”的典型一例。
Gbps网络将是另外一例，不管厂商叫得多欢，软件难题依然改变不了挑战。
我来用Gbps场景重写上面那段话。
我们知道，Gbps场景下，端到端传输协议和交换机需要重新设计，将流拆得粒度更细，以便并行传输和处理，同时，交换机尽量避免将多个流安排到同一个队列，避免HoL。数据包orsubflow/flowlet前后互不依赖，便可自由在多条路径乱序传输并被端主机多核资源负载均衡处理。
就差指名道姓了，说的就是传统TCP。
先看端能力的问题。
TCP的保序性约束同一个流不能并行传输和处理。简单算一笔账，单流Gbps吞吐需要每秒收发(/8)*/个数据包，大致个，即每微秒处理34个数据包。
大致估算一下25Gbps场景下Intel?Xeon?PlatinumCPU
2.40GHz的收包能力，关闭GRO/LRO，下图三栏分别为top/iperf-s-i1/funclantencytcp_v4_rcv的结果：
一款不错的CPU单核极限能力不到10Gbps，发送端关闭TSO/GSO，接收端CPU下降，但tcp_v4_rcv的执行能力已达上限，接收端打开GRO/LRO，tcp_v4_rcv开销变大，达到us以上。
双边启用硬件卸载，志强CPU的TCP单流处理极限大约在60～80Gbps。
TCP协议逻辑过于复杂，这意味着更多的CPU指令周期，难有CPU能支撑20ns～30ns处理一个字节的数据包(或者80ns～ns处理一个更大的LRO聚合数据包)。
既然单个CPU不行，多个总可以。32个CPU并行，妥妥1us处理30+个数据包。但TCP需要保序，不允许并行处理同一条流。这便是一个简单的障碍。
如果允许乱序传输，上述瓶颈即可被打破。我说TCP不适合Gbps网络，这话并不过分。一定是便于并行处理的乱序传输协议才更适配Gbps。
对于非TCP协议，仍然受限于CPU的指令周期处理极限以及内存带宽极限，越复杂的协议逻辑有效吞吐越低，虽然通过堆CPU核数能有所优化，但专用硬件显然更适合适配Gbps。
各类Hardwareoffloading方案，RDMA/RoCEv2只是开端。
再说拥塞控制。
范雅各布森管道理论，瓶颈buffer等于BDP可在AIMD策略下获得最佳带宽利用率，buffer小于BDP-alpha为浅队列，buffer大于BDP+alpha属深队列。各类端到端拥塞控制算法孰优孰劣便围绕着buffer大小展开。
Gbps，40us链路，BDP达2MB，需更大buffer平滑统计突发，但更大buffer承受更大突发的同时，在大收敛比节点也要承受更大扇入，引入更大延迟，影响公平性。同时，更大的buffer意味着更大的成本。
虽然PFC，ECN机制已经可逐跳或者端到端反馈拥塞，但却不得不以额外延时为代价。即便如此，绝大多数数据都可在1个RTT无反馈传输完毕(GbpsBDP约MB级别)而无缘ECN之惠。
说到底，如今的拥塞控制机制几乎全依赖反馈到端执行，中间节点没有一种简单的分流能力。
比方说，一个端口发生拥塞，交换机立即将流量引导到稍微空闲的等价路径。而该机制需要不同于传统最短路径路由的新基础设施来支撑。虽然SDN控制器可提供支撑，但分布式方案目前尚未存在。
Google的PLB提供了重新选路的思路，但依然需要将拥塞反馈到端后由端执行re-path，考虑流的Multi-Path，乱序传输，需要由端来综合调度拥塞信息。
由于收敛比，扇入的存在，拥塞不可避免，高吞吐与低延时看似不可兼得。但该结论显然来自传统的假设，端到端传输协议控制数据流沿着最短路径到达对端。在Gbps场景，反过来更合适，即哑端专用硬件盲发数据包，数据包沿着多条路径乱序传输，转发节点以分流，反压的方式进行拥塞控制，可同时获得高吞吐和低延时。
简单举一例，一服务器网卡按照Gbps发送(而不是传统单流)，其中一个或几个数据包属于某类低延时敏感业务，由于途中交换机某端口拥塞，这些数据包不得不忍受排队，而对它们标记ECN毫无意义，因为它们属于单数据包(此类数据包非常多)。
无论对于短消息还是长流，即时处理拥塞总是低延时的最佳选择：
与端到端原则的TCP/IP协议栈相反，Gbps场景的传输控制协议族，复杂性从端移到了中心，第一时间处理拥塞代替反馈拥塞，这是低延时的核心。连带效果，端在传输逻辑方面的弱化也将更多资源留给了计算，端资源给计算，中心资源给传输。
只要TCP深刻在你心里，你可能就不明白我说的“依赖反馈”到底意味着什么。再举一例，假设瓶颈带宽达Tbps(而不是Gbps)，你要在40us的链路传输MB。简单算一下，MB大概需要个字节的数据包，仍假设初始窗口10(很不合理)，慢启动阶段，窗口随RTT倍增，大概不到12个RTT就能传完MB，而慢启动尚未结束，诸如BBR复杂的逻辑不起作用。如果初始窗口因大带宽改为00(很合理)，一个初始窗口即可完成传输，甚至慢启动也不需要，至多一次丢包反馈后重传。
或者说就问一句，如果不依赖反馈，如何进行拥塞控制。端到端算法可榨取的收益早已捉襟见肘，需修改中心的算法才能有所改变。
Gbps准备好了，人们依然指望TCP可适配，一个进程无法充分利用SMP，一条TCP也无法跑Gbps，人们一开始用多个进程去跑SMP，现在人们用多条TCP跑满Gbps，显然，后者粒度太粗，正如进程粒度太粗一样。核心还是分割可并行单元，进程之外可调度更细粒度的线程，协程。同理，重写传输协议可实现消息粒度(介于数据包和传统数据流之间)并行传输和处理，当“X程”在多核上无阻塞调度时，消息也在网络无排队分流。
总之，无论从端能力还是拥塞控制来看，Gbps网络受上层逻辑约束越少越好(与直觉相反，比如，如果网卡不认识五元组，便可将每个数据包分发到不同的CPU)：
消息短小则数据包之间无依赖，可有效利用端主机资源并行处理。
消息短小则数据包之间无依赖，可有效利用多等价路径乱序传输。
不存在长流，交换机更看不到长流，长流要切成短消息乱序传输。
Gbps网络只管传输，不管协议逻辑。
显然，硬件准备好了，可软件还没跟上。但早晚会跟上，各类RDMA，Homa，以及AWS的SRD已经在路上，拭目以待。
最近跟朋友聊起Gbps，Gbps，Gbps网络，总觉得这玩意儿能跑起来吗，在协议层面尚未ready时，会不会造成浪费。联想修高速公路，一般双向8车道就顶配了，剩下的就是提升限速和提升安全车速，而不是增加车道，所以我觉得为什么不去研究空心光纤呢，将光纤传输速率提升到光速的80%+(不细说，容易被民科)。…想到TCP诞生的s，网速远小于主机处理速度，它的一切协议逻辑都是合理的，适应彼时硬件的，一路发展到网卡将要逆袭CPU，CPU反而成了外设的当今，TCP反而成了鸡肋，还是有点适者生存的进化理念的，什么样架构的硬件，就需要什么样的软件与之搭伴，否则硬件就是没有竞争力的。正如CSMA/CD搭伴了同轴电缆，迅速以简单易部署占领了市场，才发展到如今的百Gbps，软件伴随硬件的强化而升级，比较有趣，写篇随笔。
————————————————
版权声明：本文为CSDN博主「dog」的原创文章，遵循CC4.0BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：
