编程实现路由算法_“网络编程” 还是 “可编程网络”？

去年年底到今年早些时候，参与到某司的一款新的路由芯片架构设计，产生了许多争议，甚至发现很多设计的资深工程师已经连很多最基本的东西都忘掉了，有些震惊。这些年亲历了网络芯片从软变硬又从硬变软的过程，有些感慨。 加上最近一段时间软件定义的网络，智能网卡，SRv6，P4等一系列技术对网络可编程性的体系结构上的改变，在此写一篇综述，一方面是回看历史，另一方面是告诉大家设计东西的时候别走弯路。 注：希望大家看此文的时候从三个维度来看待问题，即软件/硬件/网络报文编码 1986~1995 软件实现为主 1995~2010 由软向硬的过渡 2010~2015 由硬到软：软件定义时代 2015~2019 由软到硬：可编程的智能网卡时代 网络的本质其实就是快速，可靠，安全，可控，便捷，便宜的通信 ，无论哪个厂商设计产品，其实都是在这几个方向上做trade off，不同的时代，有着不同的软硬件选择，但人们常常因为知识受限和对客户使用场景的把握不够，做出错误的选择，或者是过分强调软件， 或者是过分优化硬件，其实从历史的长河来看，这只是一个反复迭代的过程，只希望这小小的一文能给一些在十字路口做决策的人一点点帮助，也给出一个我的“NewIP"的答案。 2020~未来 ：NewIP：后浪：给更多的终端可以智能选择的权力 1. 其实网络一开始就是软件定义的

一开始的路由器其实是叫服务器的，1986年思科发布的AGS(Advanced Gateway Server). 而Cisco IOS本质上不就是一个软件的操作系统么.

最早的报文处理系统就是软件的，当然密级高的资料我是不会说的，接下来每个资料我都会引用公开的文档以免惹来麻烦，第一本公开文档就是一本老书

1.1 进程交换

那个年代也是极力的从软件算法上优化，最早的时候就是进程交换，如下图所示，在操作系统上执行一个转发进程，每个包进来都走这个进程去查询路由表，然后转发：

1.2 快速交换->CEF

但是这样是不是太蠢了点，每个报文都要查询一次路由表，随着网络规模的扩大，路由表多了就发现性能有问题了，所以后面出现了所谓的快速交换，也就是增加了一个Cache用于路由查询,也就是我们常说的Fast Switching。后来随着路由表规模进一步加大，然后只能在数据结构上改了， 也就是逐渐出现的基于各种树的查询， 例如Linux Kernel很长一段时间都在使用Radix Tree,而Cisco也是从RadixTree到后期的CEF。

1.3 第一个软件转发时代的总结

其实从这个时代来看，网络通信数据量并不是太大，协议也相对复杂，更多的是通过IP协议和其它各种协议互通互联，通信需求来看也基本上是在100Mbps处理能力以内，用软件转发是相对较好的解决方案，这一时代的很多产品都是基于MIPS处理器实现的，所以本质上CPU内部还是执行的标准的MIPS指令集， 而路由器的升级更多的就是CPU的升级，从最早AGS使用的Motorola 68000,到后面开始采用 R4600， R4700，到后期的R5000， 总线结构从最早的私有的Cisco Cbus到后期标准的PCI总线的PA卡，以及CyBus这些东西，本质上结构并没有太多的变化：

当然这种也是集中式的转发架构， 很多人就会自然而然的想到：性能不够那么就换成多个CPU来转发吧，当年Cisco 7500系列的推出便是这样，在所谓的线卡上放置了CPU，然后将转发表下载到线卡上成就了所谓的Distributed-CEF

2. 软件到硬件转发的变革 历史真的是看多了会打脸，最搞笑的是执行这个变革的主导者居然是日后硬件转软件定义网络的先驱，斯坦福老教授Nick Mckeown. 但是也不得不说，其实在不同的时间段人们根据现有的技术做取舍从而满足客户的需求，才是最重要的。 但是从软件到硬件转发，技术上还是有一些区别，一方面就是线卡的ASIC如何设计，另一方面就是Fabric的ASIC如何设计，下面分两章谈。 2.1 硬件转发之Fabric 由于大量的通信来自同一网段的主机，广域网通信带宽本来就小很多， 所以伴随着一个叫“交换机”的东西的出现，思科连续收购了三家以太网交换的公司：Cresendo / Grand Junction / Kalpana，还有ATM交换LightStream，本质上这些公司都是在用ASIC进行特定的转发加速， 毕竟就精确匹配目的地址嘛，做个硬件查表肯定比CPU指令慢慢译码快吧。但在处理上各家又有不同：直接检查目的MAC的Cut-Through交换，但是在传统的以太网中容易产生碰撞和残帧，所以又出现了检查前64B的Fragment-Free交换用来避免碰撞的碎片，当然还有更稳妥的store-forward机制，但是又会增加延迟。其实这些本质就是产生了一个交叉矩阵来控制开关，这也是switch这一词的由来：

与此同时，总线型的分布式路由器平台也遇到了背板瓶颈， 在很长一段时间, 从ISA-->EISA-->PCI总线的增长速度相对较为缓慢.  但是随着Internet的快速发展, 需要更快的backplane. 基于共享总线的交换方式虽然实现简单, 但无法避免内部产生冲突, 使得高速总线设计受到限制. 难度越来越大. 于是也就诞生了把各个接到总线上的分布式线卡换成交换机互联的想法。一个交换平面不够， 那么接多个？ Crossbar是一种严格的非阻塞交换结构, 输入输出之间可建立多条通路. 当然别引诱我说更多，我只会拿各种市面上能找到的资料给你们比划， 这是当年给电信做GSR培训的胶片。

注: Crossbar架构由斯坦福大学Nick Mckeown在论文《 Fast Switched Backplan for a Gigabit Switched Router》中提出. 该作者也在1995年开始成为Cisco Systems 设计GSR系列路由器的架构师. 随后Cisco推出了基于Crossbar架构的GSR 12000系列路由器.  当然任何技术都会有利也有弊，一方面是如何利用和同步多个Crossbar？另一个是如何防止阻塞？ 2.1.1 Cell based Switch 报文通过Crossbar传输时通常可以有两种选择, 一种是基于变长报文, 直接将报文通过crossbar进行传输. 另一种做法是将报文分割为一个个小的固定长度的单元(例如ATM将报文封装成为固定长度的信元), 然后通过crossbar传输. 在输出端再重新组合成为完整的变长报文.   使用固定长度的Cell非常使得转发非常简单. 我们可以计算和估计出固定长度信元的转发时间. 并将其成为一个时隙, 所有的输入/输出都可以在一个固定的时隙内完成. 在每个时隙结束后, Scheduler根据正在等待通过crossbar switch转发的报文来选择crossbar switch的配置. 这样就很好的做到了基于时隙的同步操作.  而对于变长报文转发则显得十分困难, 尤其是在Scheduler. 由于变长报文转发所需要的时间是无法估计的. Scheduler需要不停地监测哪些报文已经转发完毕, 同时还要不停地监测矩阵中其它节点的状态. 因此需要消耗很大的资源. 并且Scheduler无法做到在某一时刻同步的对fabric进行配置更改.  因此造成大量的时隙处于等待阶段. 无法有效地利用带宽. Cisco定义的Cell大小为64bytes, 格式如右图所示: 根据计算和仿真, 固定长度的cell转发可以使用100%的crossbar资源, 则对于变长报文转发, 则只能使用大约60%的资源.  因此Cisco在设计GSR 12000时采用了固定长度的cell 转发模式.   2.1.2 HOL Blocking & VOQ 另一个问题就是当所有的卡向一个卡发送时，会产生阻塞，也就是我们常说的HOL Blocking，聪明的人类总会在十字路口前后加宽一点作为缓冲，也就是所谓的Input Queue和Output Queue：

可惜问题又来了，对于Output Queue而言, 虽然可以最大限度的使用带宽, 但需要队列缓存具有N*R的操作速度.  而对于Input Queue, 缓存可以用R的速度进行处理, 但是会遇到HOL Blocking的问题.  在一个IQ交换机上受制于HOL Blocking的crossbar最大吞吐量计算可得为 58.6%， 解决IQ HOL Blocking问题的一种简单方案是使用虚拟输出排队(virtual output queueing , VOQ).在这种结构下,每个输入端口为每个输出设置一个队列,从而消除了HOL Blocking. 并保持缓存的操作速度为R.

对于VOQ的解决方案, 核心部分在"matching Scheduler"上, 如何调度将是一个难题. 其数学模型实质上是一个二分图匹配的问题. (敲黑板：华为任总说的数学很重要)通常调度算法被分为两类, 最大匹配(maximum size matching, MSM)是指边数达到最大,而最大权重匹配(maximum weight matching, MWM)是指边的权重之和达到最大.由于这两种算法具有复杂度高、硬件实现复杂等缺点, 在实际应用中, 我们一般用极大匹配(maximal matching)近似最大匹配. 所谓的极大匹配是指在当前已完成的匹配下, 无法再通过增加未完成匹配的边的方式来增加匹配的边数或权重. 

这也就是日后那个引领SDN的Nick教授搞的事情：Cisco GSR 12000上实现了基于VOQ+iSLIP调度的算法.  如下左图所示: 在使用共享总线的架构中, 仅有最大吞吐量的25%, 使用不带VOQ的FIFO队列时, 吞吐量为最大值的58.6%. 而如果使用变长报文而不使用Cell模式转发, 则吞吐量大约为最大值的60%. 使用VOQ+iSLIP的方式后, 吞吐量为100%, 非常接近理论的最大值.

VOQ这种技术在日后Nexus7000，ASR9000上继续使用着... 当然还有一种技术是华为使用的CIOQ,这个技术来自于Avici，至于Avici的TSR和华为的NE5000是什么关系以及日后的什么什么，自己感兴趣去搜吧。对于CIOQ的调度, 通常采用的是基于稳定婚姻问题(Stable marriage Problem)的算法.  稳定婚姻问题也是一种二分图的匹配。

2.1.3 CLOS架构 随着技术的发展，问题又来了，1Tbit以下的交换结构, 一般采用多个并行交换的Crossbar 构成, 可称为多平面单路径的交换结构, 每个Crossbar完成几十Gbit/s到上百Gbit/s的交换. 但是, 基于Crossbar的交换结构存在扩展性差的问题:一方面, 实现很大的Crossbar有一定困难, 主要受芯片的管脚和IC实现复杂度的限制(其复杂度以O(N^2 )增长); 另一方面,  Crossbar 采用集中调度的仲裁器, 调度算法的复杂度也高于O(N^2 ). 当端口速率增大到10Gbit以上, 端口数增加到10以上时, 仲裁器难于在一个信元时隙完成仲裁, 其处理速度极大地限制了系统容量的提升.  新的做法便是使用多级交换架构来替代原有的基于单级架构的crossbar技术. 多级交换结构的基本组成单位叫交换单元, 每个交换单元具有输入和输出功能. 各个交换单元通过一定的逻辑顺序相互连接, 形成一个巨大的、可扩展的交换网络. 多级交换结构的形式有很多种, 包括Clos、Banyan、Butterfly和Benes等, 各种交换结构的不同主要在于交换单元的互联方式.   例如Cisco的CRS-1则采用了BENES架构：

这样多个芯片构成的交换网可以作为并行作为多个fabric连接到线卡上，也可以做成路由器集群构建专门的Fabric机框。

基于Benes网络的转发平面非常容易扩展从而支持路由器集群技术. Cisco使用新的Fabric Card机箱(FCC)和原有的LineCard机箱(LCC)的方式构建Multichasis的集群技术. 最多支持8xFCC+72xLCC的方式群集. 从而使得转发容量从原有的1.25T上升为92T.  但为什么标题是CLOS呢， 因为这段时间Huawei NE5000E和Juniper T-Series采用的是CLOS架构，后期很多交换机厂商没有12.8T的单芯片交换也用这种方式堆，本质上是一样的。

最近一些年的某些厂商的实践也类似：

例如为了提供128x100GE接口能力，如果采用3.2T芯片，需要4(Spine)+8(Leaf)共12颗芯片的 架构，本质上其实都在玩十多年前的老东西，没啥创新。 详细的专著可以看下面这本书：

2.2 硬件转发之Linecard

Fabric设计是相对简单的，困难的还是在线卡上，一方面是路由表的容量越来越大，另一方面是对功能的需求越来越多了。 线卡结构的发展历程参考Cisco可以清晰地看到, 从最早的路由器全部使用核心CPU转发. 到后来在总线上使用控制器调度. 再到后期Cisco 7500上使用VIP接口卡, 实现分布式的CPU处理;  然后在基于Crossbar的平台上使用ASIC进行处理.  例如7600上OSM线卡和Cisco 10000系列所使用的PXF. 到最后在线卡上使用网络处理器(NP), 例如Cisco的SPA/SIP架构.  后期例如在CRS-1使用的SPP处理器以及使用全新QuantumFlow网络处理器构建的ASR1000边缘路由器平台等. 其实那些年有很多的争论也有很多的实现，真是百花齐放的年代：

注：GPP表示General Purpose Proccesor, ASIP表示Application Specific Instruction Processor 2.2.1 不得不说的ASIC：TCAM

传统的表项查找方法都是基于SRAM的软件查找方法，共同特点是查找速度慢。线型查找法需要遍历表中的所有表项；二叉树查找法需要遍历树中大多数节点，而且查找速度受树的深度影响较大；基于硬件的TCAM查找法正是在这种背景下提出的，用此方法进行查找时，整个表项空间的所有数据在同一时刻被查询，查找速度不受表项空间数据大小影响。TCAM为啥叫Ternary Content呢，其实就是每个bit位有三种状态， 0，1，Don't care，这样不就很容易去做一些匹配了么，特别是路由器那样的Longest Match

一般来说的做法如下，通过TCAM查询然后获取Index，然后再到内存里面把index对应的信息返回给路由器。

基本上那个年代所有的网络设备都采用这个方式查表，ACL匹配等功能也在这上面实现，直到现在也有很多厂商还在这么做，例如华为的NE40系列以及大量的交换机产品。 2.2.2 固定流水线的ASIP 当我们开始对线卡处理器进行加速时，最先想到的便是将一些固定的功能Offload到硬件上批量执行，Cisco PXF(Parralled eXpress Forwarding)也就是在那个特定的年代诞生的， 所以那个年代非常成功的7200系列路由器便是基于这个架构实现的，也使得IOS第一次用上了类多核的转发。只可惜这个处理器不算是真正的处理器，还需要很多微码编程。

本质是是不是觉得和现在的P4ASIC类似了啊，其实就是一长串的流水线和内存构成的一个ASIC，第一级做A功能，第二级做B功能，一次性并发处理多个报文(后面开源的VPP架构其实也类似于这个东西)。 有个教授写了一段话，原文摘录,： “The PXF consists of a pair of ICs, each comprised of 16 processors arranged in 4 pipelines. When used together, the pair of PXFs results in a 4x8 systolic array. Each of the 32 processors is a 2-issue VLIW with special instructions for packet processing. Each processor has an independent memory and each column of processors has access to its own separate memory (off-chip). Each of the 8 stages in the pipeline is responsible for a different packet forwarding function. ” 文章来源 《Understanding Network Processors，Niraj Shah》更多的东西就不多透露了也不是本文的重点 2.2.2 RTC的网络处理器(SPP/QFP) 固定流水线的网络处理器会面临一些问题， Feature的使用并不是那么的均衡的，可能有些资源放在那里，功能没用上，但是还是要走，而且可能还会存在某些功能用的多，资源不够的状况, 另外一方面随着那个年代MPLS VPN的兴起，路由表容量的需求也越来越大， 另外针对不同功能例如BRAS/DSLAM/Cable接入也推出了大量的硬件平台，使得研发难以维护，微码编程也逐渐的无法满足丰富的市场需求，在这个年代发生的一些事情，不得不提Will Eatherton，最开始有一篇论文,然后通过这样的方法避免了IP路由查询受限于TCAM， Will设计了思科的SPP和QFP，然后又去Juniper 设计了Trio系列处理器。但是2019年一次测试碰到华X的NXXX，还在用TCAM，而且似乎还丝毫没有意识到路由表容量大有那么多好处，同时也可把TCAM的资源节省出来给ACL用。

FP的设计都是采用Run-To-Compile(RTC)的结构，即即便功能再多，一个处理器处理完一个包的所有功能， 然后编程上以C代码为主，内存操作也非常灵活：

它从逻辑上很好的把功能抽象分离了， 一部分是On-Chip Memory用于等待调度到网络处理器PPE中，PPE是一个多核心的专用指令集的处理器(Tensillica的一个精简指令集)，这也是我需要强调的，提高性能的方法也可以把通用CPU的指令集精简获得，同时针对网络处理，内存访问的位宽并不一定需要64bit或者32bit，所以很多时候用8bit 16bit的内存访问可以获得很好的加速，然后针对加密和ACL查询采用了片外的TCAM和加密协处理器，QoS这些采用了专用的TM芯片，而路由表查询就是采用了前文所述的Tree Bitmap的算法直接使用DRAM来处理。 这样的做法在软件编程上就有足够的弹性了，想加什么功能加什么功能，后期基本上一台设备单挑了一堆盒子，成为名副其实的瑞士军刀：

它的IOS XE软件架构也成为后期企业网软件的拳头产品，如今单芯片单系统肩负了所有企业网路由/交换/无线的功能。但是这里要强调的只是它的多芯片融合的设计方案和RTC的解决方案，类似的解决方案还有Juniper MX/SRX系列使用的Trio,从最早的查表引擎LU/XL，到转发引擎MQ/XM，QoS的TM使用的XQ/QX，到接口上使用的IX/XF芯片，至于后面的Trio3D和Penta ASIC,后面会讲， 其它我就不多说了，说多了危险啊~~商用的可以看到的书就是下面这本，读读也行。

2.2.3 商用多核网络处理器(RMI/Cavium/Tilera) 思科QFP的使得大量的厂商开始尝试构建商用的多核处理器，在这段时间里有RMI 和Cavium各个厂商提供，基本上都是以MIPS多核为主的架构，本质上还是片上网络的发展，但是它们为了更加通用的编程能力，采用的多是标准的MIPS核心，同时在上面辅助一些特殊的与网络相关的加速协处理器。

2.2.4 Cache 一致性与FBD 这些芯片极大的丰富了中低端的市场，但是多核调度又变成了一个难题， 如何将数据包调度到不同的核， 也就是说多核处理器的平台如何进行负载均分， 思科的做法是Cache非一致性的，然后反正内存带宽大，要干嘛自己去查，然后一个锁锁住flow，不让同一个flow的其它包更新。而另一种做法就是Flow Based Distribution， 例如华X的SXXX，采用首包查好，然后建立好流表，然后根据流表分配到不同的核上处理的方式， 但在一些特殊的测试中， 很容易两个elephant flow hash到一个核上面去导致丢包，甚至在源目的IP地址各一个并采用随机端口发送流时，性能下降到几百兆，完全无法使用。 2.2.5 商用网络处理器(Ezchip NP5c) 当你以为各种方案都很完美的时候，总会出现一些意想不到的方案出来，并且成功了， 这就是基于EzChip NP系列的ASR9000. 

在网络这一行，各种Trade Off才是真正的艺术，CRS-1和ASR1000虽然有SPP和QFP，但输在了一个字上：“贵” ，在那些年互联网宽带业务快速发展和城域以太网快速兴起以及MPLS快速普及的年代，给了运营商边缘路由器很大的发展空间， 很多高速Fabric交换芯片的面世也使得CRS那种多级交换架构显得过于昂贵，而ASR1000也一直没有把QFP做成分布式的架构，这个时候借助NP4和NP5的ASR9000获得了极大的成功，原因就是在运营商边界和大型企业网核心/DCI的位置， 软件特性需求相对简单， 业务场景适合并行的向量化的包处理，具体EzChip的东西我就不多说了，放本它家的书自己看看吧：

挑出两三页挺重要的贴个图就好，意会一下，详细的宝宝不说~~

其实那些年设计路由器都有很多很独到的计算和调度算法以及严格的数学证明和计算， 现在好像变得很随意了，纪念一下那个年代SDN它爹的胶片，紧接着他将登上那个闪耀的舞台。

2.3 总结 这真是一个百花齐放的年代，伴随着软件算法遇到瓶颈， 一方面各个厂商从协议上采用MPLS标签来降低查表的复杂度，另一方面则是 大量的ASIC和网络处理器的出现，在指令集上针对网络处理进行精简指令集，使用TCAM加速查询，使用Tree Bitmap+DRAM和TCAM解决方案容量上和速度上做取舍， 多核心处理器和片上网络架构在网络处理器中逐渐出现，这也为以后商用处理器出现多核心架构打下了基础。 这一章讲了这么多，给大家灌输的观念只有一个，在软件出现瓶颈后，可以通过硬件和报文编码的方式解决， 这个故事过十年又会再重演一次。

1995~2010 由软向硬的过渡

3. 软件定义的网络

分分合合，合合分分，谁都没想到随着虚拟化的兴起，虚拟机内互相通信的网络成为网络设备再一次软件化的开端，当然开始的时候只有交换机， 于此同时为了大量的虚拟交换机编程和转发方便，openflow和openvswtich诞生了，然后公有云和私有云的部署使得网络设备进一步虚拟化，虚拟云路由器也随之诞生,  后面伴随着VDC/VPC的发展，更多的设备虚拟化了：

3.1  SR-IOV 软件虚拟化带来的一个问题就是大量的设备通信该怎么弄，于是有了PCI-E SR-IOV实现：

经过演化，最后形成了如下的标准架构：

System Image(SI)主要指的客户机，也就是虚拟机的OS， Virtual Intermediary(VI)主要是虚拟机的管理层，SR-PCIM配置和管理SR-IOV功能和PF/VF，PF是PCIE的物理功能，每个PF都可以被物理主机发现管理，而VF是每个PF虚拟出来的。传统虚拟化系统中大量的资源和时间损耗在Hypervisor(或者VMM)软件层面，PCIe设备的性能优势因此无法彻底发挥。而SR-IOV的价值在于消除这一软件瓶颈，助力多个虚拟机实现物理资源共享。 3.2  DPDK 在由硬到软的过程中，传统的Linux转发遇到了瓶颈：

• 数据包到达网卡设备。

• 网卡设备依据配置进行DMA操作。

• 网卡发送中断，唤醒处理器。

• 驱动软件填充读写缓冲区数据结构。

• 数据报文达到内核协议栈，进行高层处理。

• 如果最终应用在用户态，数据从内核搬移到用户态。

• 如果最终应用在内核态，在内核继续进行。

所以本质上我们需要一套在IA-X86多核处理器上的包快速处理机制，报文直接进入用户态， DPDK使用了轮询(polling)而不是中断来处理数据包。在收到数据包时，经DPDK重载的网卡驱动不会通过中断通知CPU，而是直接将数据包存入内存，交付应用层软件通过DPDK提供的接口来直接处理，这样节省了大量的CPU中断时间和内存拷贝时间。

具体去看一本书撸一圈代码都会了：

3.3  VPP 本质上就是对报文编程一个向量，然后批量处理，同时它定义了灵活的转发链状结构，可以很容易的在转发链条上添加新的软件特性：

3.4  总结 在这个年代，报文编码的发展主要是为了解决虚拟化的问题，基于VXLAN和LISP的overlay技术逐渐兴起，并且随着虚拟化的进程，大量的网络设备被要求在X86的虚拟化平台下运行，虚拟路由器交换机防火墙逐渐出现。当然这个年代为了优化虚拟机的性能出现了DPDK/VPP等开源的软件库，伴随着BGP-EVPN和Yang/netconf等技术的控制器的兴起，SDN逐渐落地，一些专门的虚拟化交换机厂商出现，但似乎最终都没能过上好日子。倒是那些卖交换机的过的日子蛮舒服的， 硬件技术上在这个年代其实就是Serdes的加强，然后大家在Chip上堆料，MAC上定义到100G，似乎整个行业进入了一个简单粗暴的发展过程。 2010~2015 由硬到软：软件定义时代 4. 又硬了....么？网卡也智能~网络也编程 历史真是一次次的打脸， 等大家全软件了，发现CPU资源的50%以上都被网络占用了，于是各位大爷们又不开心了，特别是公有云，得靠CPU资源挣钱啊， “Intel那糟老头子坏得很~ CPU价格贵贵的~” 于是轰轰烈烈的Offload运动开始了，大家突然又硬了。 4.1  Segment Routing & P4 渐渐的人们发现软件又不行了， 弄硬件又需要嗑药才能加速，于是所有的目光在软硬兼施都不行的时候，想到了指令集。一方面，通过SR对网络设备进行编码有了SID，然后再编码一个Function和Args， 这样传统的网络设备在执行包头的Destination Lookup的时候， 就可以有更灵活的一个函数Callback栈来实现更多灵活的功能了。

另一方面，我们对网络处理器的抽像可以表示成为大量的连续的Match-Action操作，可以弄成pipeline，于是P4也就顺理成章的诞生了。当然在此之前还有Cisco自己的UADP 芯片的实现就不多说了. 这里面也就诞生了几个公司， Barefoot后来被Intel收购了，Intel开始搞One API, Xilinx做了一个SDNet的库用来将P4重新编译成IPCore。 4.2  Storage & ROCE NVMe SSD的兴起，使得IOPS越来越低，传统的存储协议无法应对这样的低延迟，而另一方面AI训练的繁荣促进了对低延迟IO的需求，ROCEv2和Lossless DC ethernet也就在这个时候逐渐出来了。 4.3 AWS AWS最早实在2011年引入的智能网卡，主要提供的SRIOV一类的VF，随后推出了收购annapu rna设计的25G智能网卡， 主要功能就是： 承担了原本物理机内虚拟交换机的路由、contrack匹配、ACL过滤、VTEP查表、MAC代答、tunnel建立等工作负载，大幅度降低了网络延时，提高了网络吞吐量。 同时硬件实现了虚拟机粒度的、严格的带宽以及五元组流的QoS，保证基本所有类型以及规格的云主机都有稳定可预测的网络性能。 4.4 Microsoft Azure 微软的智能网卡的论文就有些多了，并且图文并茂，例如不光是智能网卡这块，连AI的Offload也一起在玩， 专门的论文有一篇 《 A Reconfigurable Fabric for Accelerating Large-Scale Datacenter Services 》

后面还有一些论文《A Cloud-Scale Acceleration Architecture》

4.3 Baremetal AWS的Nitro和阿里云的神龙都是这一系列的代表， 随着对性能的需求，对虚拟机方案的延迟和虚拟损耗导致很多企业，特别是一些做数值仿真和低延迟交易的行业上云带来了阻碍，于是这两家算是一个代表，另一个代表就是Fungible，它们的DPU非常有趣：

4.5 Pensando 如果说智能网卡，不给Pensando留个位置真的就说不过去了，不过MPLS真的老了，在智能网卡这个年代，它只看中的是对标Nitro的位置,P4的编程引擎在那里还算不错，又同时内置了HBM用于高性能的路由查表，而且还有几个加密或者正则的协处理器，总体来说中规中矩，真感兴趣可以读读它们的一本书：

4.6 总结 这个年代是一个美好的年代， 是一个体系结构大改的年代，虚拟机都逐渐的被抛弃，更轻量级的容器，Service-Mesh和serverless的架构出现给这个年代带来了太多的机会，人工智能的兴起，高速分布式存储的繁荣，Persistent RAM，一切都为新的时代铺好了基石。 人们在一波波的炼丹比分比速度的过程中，终于又想到了网络，开始对网络编程，开始利用ROCE降低延迟，体系结构的变革，P4的出现为报文编码的扩充也提供了良好的机遇，这真是一个非常美好的时代~ 2015~2019 由软到硬：可编程的智能网卡时代 5. 后浪？敢问路在何方~ 当我们回归本源，再一次看待网络的时候， 发现了很多问题，但是你没法推到重来， 有一家公司想推倒重来做NewIP，其实想法非常好，但是工程上不可行，那么后路在哪？

这是一个前些年的PPT，TCP的问题逐渐被BBR修掉，新的QUIC协议也伴随着HTTP/3和TLS1.3会迅速的登场，QUIC赋予了我们太多的有点，UDP完全在Userspace可以加速，有独立的CONNECTION-ID，可以做不同IP地址的Migration，延迟也低，然后传输也安全，传输可以选可靠的quic-transport，也可选不可靠的quic-datagram，可以多流复用，也可以流控。似乎在传输层已经很完美了。 前一段时间响应一带一路号召，测试了上海到莫斯科的通信质量，大概25%的丢包 300ms的延迟，但是如果从一些公有云上绕一圈，效果就很好

丢包的统计如下图：

所以到了2020年了，每个老司机开车都有选择道路的权力了，而我们是否应该赋予我们手机选路的权利呢？

那么和SR的结合也就成了一个非常不错的选择了：

也就是我们常说的，安全，可靠，可控， 其实对QUIC协议的扩展也非常简单，加一个带SRH的明文的quic-packet放在UDP payload里面就好：

后浪就真的拥有可选择的能力了：

由于它还是一个L4的传输层协议，有CONNECTION-ID维持连接特征， IP头随便改啦，V4/V6 MPLS随便穿越，把对应的下一跳信息放在uSID和一个KVmapping表里就好了

其实还有一个问题就是，过去的十年，我们用了太多的Overlay了，既然QUIC已经和IP地址无关的传输了，那么为什么不借机把Overlay干掉呢？都2020年了，你还IPsecVPN拨到VPC么？

服务器端支持也变得容易了，反正有sidecar改QUIC-SR

其实连数据中内部的ROCE都可以改成这个，毕竟能让SmartNIC选择Spine switch也是一件好事啊：

5G和WIFI的融合也会更加平滑可控：

做安全，微分段也可以给你加字段啊：

这就是一个前浪过去10多年的从业经验和见到的盛世繁华，以及给后浪的选择的权力。

2020~未来 ：NewIP：后浪：给更多的终端可以智能选择的权力