数据中心作为海量数据存储及高效处理的强力后盾，规模、体量都在急剧的扩张，同时数据中心内部应用需求和模式的变化对其网络又产生连带影响，所以我们需要首先看到数据中心发生的变化趋势以及寻找应对策略
1、云计算的持续繁荣，规模的持续扩大预示着对计算、存储、网络等资源的贪婪需求
2、AI和机器学习的普及，AI和机器学习目前看来向着基础设施的方向发展，这业就激发出了大规模使用基础资源的需求，而原有独特定制化的硬件及高昂成本成为了阻碍，目前很多公有云大厂推出了他们自己的解决方案
3、5G及边缘计算，整合云边端三个位置资源成为迫切需要解决的问题，它使数据中心慢慢演变为一个超级规模的分布式计算系统
以上的趋势其实对数据中心底层能力产生了非常大的挑战
1、数据中心如何跟上数据生产的速度，目前随着AI和机器学习以及大数据的技术普及，数据产生量有了前所未有的提升，有统计表明近几年数据产生量已经远远超过了人类诞生时期至此时产生的所有数据，海量、多样的数据以及这些数据非常大的不确定性产生了产生数据和处理数据的矛盾，目前数据中心数据只有20%被处理
2、处理数据需要大量的CPU和内存，目前已经明显出现摩尔定律墙的现象，CPU一个是频率升不上去 后来走多核，但多核目前也出现了发展的瓶颈，同时内存增长也在放缓，受益于摩尔定律的驱动，过去 5 年中，CPU 保持 1.5x/ 年的性能提升，并驱动传统计算体系快速发展。然而，随着单线程性能与主频增长逐渐放缓、单核性能平均每年提升不足 10%，通用 CPU 的发展遇到了一系列技术瓶颈，摩尔定律逐渐失效，算力供应日益稀缺， 亟待新的算力体系驱动新一轮算力供给提升。特别是云计算、人工智能和 5G 等新的技术应用，它们的技术和生态架构往往需要在更加多元生动的新计算世界下才能发挥更大实力
3、储存数据的存储目前也遇到发展瓶颈，我们能看到单GB容量的成本在降低、单位密度容量在提升体积在下降而且性能也在不断的提升，但是如果我们对比IOPS/GB这个参数来看，却能发现它在下降，走到了业务发展对存储要求的对立面，进一步加剧了处理数据的单位时长
4、网络，计算和存储其实已经发展很快，尤其是存储，那网络如何匹配，业界目前为了防止故障爆炸半径过大的问题，一般认为10W台服务器是一个比较合理的配置，而10W台服务器一般会产生10PB/s的网络带宽需求，即便按照10:1的收敛比计算也需要1PB/s网络支撑，如果配置最新的存储介质其读写速度已经<10us，对于这些TB级别1M+IOPS对时延的要求，网络改如何支撑。随着发展目前爆炸半径能包含30W台服务器的规划已经呼之欲出，在稳定性、成本、性能和超大规模上都对网络提出了非常大的挑战
数据中心面临的挑战可以归结为---“爆炸性增长的算力和存储需求以及多样性业务 vs 性能、稳定性、成本 ”之间的矛盾
在2019年的论文“A New Golden Age for Computer Architecture”里提到了计算机体系结构发展的新方向，就是“Domain-specific architectures” DSA，不光有软件定义的数据中心，也会有硬件重构的数据中心。
基于通用芯片的服务依靠摩尔定律或者说制程改良已经不再是唯一的提升性能、优化成本的最佳方案，各个垂直领域的加速和定制芯片能够提供2-10倍的效能释放，大大缓解摩尔定律墙带来的压力，各类传统cpu、dram、gpu、nic依然会持续在纵向上scale-up，而新的专用芯片和硬件会在横向上大力发展，比如AI专用芯片 google的TPU 百度昆仑，通用计算及虚拟化专用硬件 aws nitro、阿里moc、微软catapult，新型存储aep等等
DSA必然还会从代码层面带来一些新的变化，在使用通用硬件的时候，程序员不会特别关注硬件，只要把程序功能实现即可，即便现在的硬件不能跑，过一段时间后新的硬件出现了一定就可以跑，但是现在要求软件需要认真考虑在硬件上的高效执行的问题，会有更多特定领域的专用语言会出现。
对于网络来说，数据中心业务多样性会带来内部流量的爆发性增长，甚至于终端用户---服务之间的瓶颈已经从原来端云之间逐渐转移到云网络内部，内部大量的流量负载很难控制得当，当越来越多的流量搅和在一起的时候，计算型业务的时延敏感要求和存储型的高吞吐之间产生严重冲突，目前云原生模型下的分布式计算虽然提供了高效可靠的性能，但是分布式计算的短消息传输，俗称老鼠流对网络的传输时延成为计算业务的瓶颈，而存储业务大象流常常影响其他业务的使用，把低时延和高吞吐这一对矛盾体如何更好的满足成为了数据中心内部网络的主要挑战。
Incast又称TCP incast，是一种典型的many-to-one的通信模式，也是目前云原生分布式系统的一大特点，当一个父服务器向一组节点发起一个请求时，集群中的节点会同时收到该请求，并且会在同时进行相应，这导致一个“微突发流”，这会经常性的导致交换机缓冲区溢出，从而进一步发生流量崩溃
数据中心网络的物理拓扑形态目前大规模clos架构已经成为主流，其实是产业界从性能成本等多方面的综合考虑的结果，其已经非常成熟和可靠，目前在整个TCP/IP的数据传输过程中，硬件网络交换机随着P802.3df已经剑指800G和1.6T的单端口速率，但是由于TCP设计问题在主机网络协议栈上会消耗大量cpu资源和总线资源，尤其是cpu速度、内存速度和nic速度不匹配时，会加大增加网络延迟的效应。这个时候服务器内部网络协议栈优化的矛盾解决成为目前网络发展的热潮。
此时数据中心内部网络的性能指标有了一定的变化，包括
1、有效吞吐量，不是throughtput而是goodput，指的是单位时间内正确发送到目标接口的比特数，并且goodput是应用程序级的吞吐，它一般会低于传统屯度量
2、流完成时间，flow completion time FCT，从TCP发送第一个数据包（SYN包），直到最后一个数据包为止。对比有效吞吐量可以评估应用使用网络的真实指标
3、RTT，传统指标。反应当前网络拥塞程度
4、slowdown，完成一个PRC（remote procedure call）所需实际时间和无负载网络完成RPC的比值，最优值为1
5、收敛时间，针对公平性指标，指当多条流并发到瓶颈段节点，多条流从不公平到公平的时间，理论上，收敛之间越短，公平性越高并且性能越好
6、丢包数，随着数据中心无丢包技术引入，慢慢这个指标被弃用
为了优化主机网络协议栈矛盾，利用智能硬件提升网络传输的性能及减少CPU利用率成为主流，TCP卸载引擎、RDMA以及NetDAM是目前主流的技术方向，TCP offload engine，TOE就是这样一种NIC技术，它会吧整个TCP/IP协议栈处理卸载到其上，主要应用在高速网络接口上。而RDMA则更加彻底，他是从DMA发展而来，绕过整个TCP/IP协议栈，从应用角度直接通过网卡访问对端主机的内存，这样可以不消耗CPU，RDMA over converged ethernet---ROCE则是一种网络协议，允许通过以太网进行RDMA访问，目前有RCOE v1和v2两个版本，虽然绕过了TCP协议栈，但是TCP面临的拥塞控制、流量工程和负载均衡依然是ROCE不可能绕过去的问题。
一、拥塞控制
1、基于丢包的拥塞控制，就是TCP使用的cubic算法，它遵循先污染再治理的模型，只要没有出现丢包的情况下不会主动降低发送速度，但是其专门针对广域网的设计思路并不适合数据中心内部，持续的流量注入会增加数据包的缓冲排队，造成bufferfloat现象，增加无谓的网络抖动
2、基于ECN的拥塞控制，2010年诞生的DCTCP（datacenter TCP）针对TCPcubic算法存在问题进行了更新，把TCP包头中一直没有使用过的ECN位拉了出来，已一种侵入性很低的方式实现了数据中心内部流量的优化，已经被微软windows server 2012采纳，作为其默认协议算法。DCTCP问题也很明显，它利用了传输路径上设备的能力感知到了网络的真实情况，但是并没有区分各类流量，胡子眉毛一把抓，要死一起死。
2012年HULL算法推出，High-bandwidth ultra-low latency为小流量提供了一个较低的时延和排队时间，简单来说就是在交换机上进行带宽保留，类似PQ队列，发送端通过DCTCP进行调节来选择不同的队列。由于其需要对交换机及网卡均作出修改，现实场景部署较难
2015年DCDCN提出，是基于速率的端到端拥塞控制协议，控制位置主要位于网卡之上，能够实现基于流的拥塞控制，对于数据中心网络高带宽、高突发、低时延需求做了很强的契合，但是由于DCDCN与TCP不兼容其在大型数据中心性能表现没有进一步的数据支撑
3、基于RTT的拥塞控制，2015年的TIMELY协议，基于RDMA的端到端TRR测量执行发送端控制传输速率，通过RTT测量、速率计算和速率控制三个模块实现。同样的这种基于RTT的算法通病就是RTT在微观世界是极其敏感的，准确测量RTT其实十分困难，其次TIMELY对网卡改的较大推广普及面临难题较多
4、基于其他信息的拥塞控制，2014年Cut Payload CP协议，用在交换机上的辅助拥塞控制协议，他认为数据中心内部大流量突发时必然造成排队丢包，原因是TCP时钟状态丢失然后只能依靠重传，这个时候可以在交换机上在即将拥塞是直接抛弃负载 cut payload，从而维持原有TCP时钟，使TCP能够迅速进行拥塞调整而不必要等待超时重传。它的问题也在于部署成本，因为要在交换机上增加硬件功能。
2014年Fastpass协议，它改变了以往通过收发端和交换机分布式解决时延的方式，设置一个集中仲裁器，所有收发端要与仲裁器交互信息，从而确定传送速率和路径达到低延时和零丢包效果。类似SDN这种集中控制当其规模急剧扩展后，必然面临多个仲裁器的同步和聚合问题。所以仲裁器模式是一种理论最优的选择，它可以作为与其他算法比较的基础，因为任何一种算法只能无限在理论上接近他而不能超越他
2017年ExpressPass提出，是一种端到端基于credit的拥塞控制协议，发送数据包前使用credit包遇险探测拥塞，核心思想是将网络传输过程中的正向拥塞通过交换机漏桶算法转换为反向credit的拥塞，同时通过对短小的credit进行拥塞控制保证正向网络不丢包，从而提升网络性能。
2019年阿里的HPCC及2020年AWS的SRD协议也属于此类范畴，这里不再详细描述
二、流量工程
流量工程主要是做存量生意，在有限资源情况下给各个应用更好的体验，细化可以分为两个方向，分别是流调度和负载均衡。
1、流调度的前提是给流量做一个评级，如何定义合适的优先级成为关键问题，这里有依据流量大小进行分类、流量截止时间也就是越早越优先以及基于链路价格三种方式来确定优先级。这些种类的选择要求拥塞控制协议选择对应的流控制。
2、负载均衡，主要在两个技术方向上进行权衡，一个是传统基于流的ECMP，它在数据中心场景下的问题主要是非对称网络性能损失，在大象流和老鼠流混杂的场景下容易造成撑死一些链路同时空闲一些链路。对应的就是Random Packet Spraying--RPS，随机包喷洒。它基于数据包进行负载，最大的问题就是乱序。如何在二者之间权衡就称为负载均衡需要考虑的重要问题。
数据中心属于互联网体系结构中的演进式，相比传统架构，它确定性及可控性是比较高的，所以可以更加革命性以及采用全新的设计。这里定制硬件程度较高，然间也处于百家争鸣的阶段，虽然蓬勃发展但尚不充分。随着底层硬件能力进一步释放，数据中心网络发展还有很长的路要走
1、综合考量拥塞、流调度及负载均衡，三个方向的总体目标都是为了客户提供更好的使用体验，但目前研究局限在一个或者两个方向，为了bypass掉TCP提升了一些方面的能力，但是目前体系结构远不如发展数十年的TCP体系，把拥塞、流调度及负载均衡统筹考虑，并在非冲突、互补的各种机制组合起来的传输技术才是未来的发展方向
2、中心控制及分布式控制，中心控制SDN和分布式控制都有自己的应用场景，更精确的规划流控制、全局的信息掌控等等。规模扩张集中控制器会成为瓶颈及SDN的效率低下和可部署问题都是需要解决的问题，交换机在很多情况下被认为可以在转发基础上提供更多的控制能力。
3、高性能专用设备部署，比如RDMA技术目前是热点，但其也存在一系列问题，如何利用好当前各种高性能设备将面临极大挑战
4、特定场景下流量控制，比如HyperLoop框架，专门针对大规模数据存储应用场景，针对网络分布式存储过程中网络流量的特性将其卸载到高速智能网卡上smartNIC，节约大量CPU消耗
5、AI和流控结合，AI的自适应性、自学习能力为其和传输技术结合创造了天然条件，在广域网络上有些AI算法应用，但是在数据中心内部由于其速率远远大于AI决策速度，往往是决策还没有发出传输已经完成的情况。但是数据中心中流调度依靠目前静态算法僵硬的应对又催生了对AI的需求
