SDN-软件网络如何实现颠覆

网络技术和软件技术的鸿沟曾经越来越深，如今它们终于要走到一起了，软件是胜出者！

1.网络技术一直掌握在巨头手中

教科书上，我们可以知道很多关于TCP/IP的知识，以及协议处理的细节，然而除了可以借助Linux这种开源的系统自带的协议栈实现之外，你很难深窥网络技术的内幕，一直以来，网络技术被Cisco这样的企业垄断着，而且它们的技术是和它们某个型号产品深度关联的，离开了那款产品，也就离开了那门技术，于是乎，网络技术的培训也就成了厂商产品的培训，众所周知的CCNA/NP，HCSE等认证如果你取得了，并不能说明你是网络技术的达人，因为很多的协议包括特有实现技术都是厂商私有的，比如Cisco HSRP，Cisco CEF...精通网络原理的人和精通设备操作的人很大程度上成了两个群体，而且还互相倾轧。网络技术很大程度上成了一中独门匠艺，掌握了它的人于是也就趾高气扬，不可一世，直到让他知道你比他更趾高气扬和不可一世。
总之，如今的网络大没有到达标准化的阶段，所标准化的，只是网络协议。如今搞网络的，正和中世纪的铁匠一样。

2.软件技术已经开放了很多年

教科书上，我们学到了C++，Java，设计模式，Web等知识，等到我们毕业了，工作中我们进一步的将学到的这些东西强化。30年前，懂编程的人被认为是高科技极客，并不多，那时他们掌握的是一种独门匠艺，可是如今不一样了，任何一个人都可以在App Store里面贡献一个收费或者免费的软件，任何一个人，只要你肯花半天的时间来了解相关流程，都可以为Linux源代码写一行注释，如今你想写一个串口程序，你面对的东西已经不再是串口的电气特性，而是一整套的API或者库，就像组装家具一样，螺母套螺丝，参照组装说明文当，板材摆在正确的位置，就成了。
总之，软件技术标准已经足够开放，API的设计有一套成型的大家都公认的标准，只要参照标准行事，你就是软件达人，如今的软件技术人员（开发，测试...），正如现在的社会化流水线上的工人一样。

3.网络技术和软件技术

网络技术和软件技术都是IT技术，可它们之间确实存在很大的鸿沟，网络技术很大程度是厂商驱动的，而软件却纯粹是需求驱动的，当然上述说法这可能有些极端，然而话语不极端化，很难说清问题之所在。
你有一个点子，你可以快速写出代码实现它，仅仅代码而已，没什么阻止你，如果你只懂一种语言，你可以用一种语言来完成。可是在网络上，你却要受制于很多东西，你是一个精通Linux网络的人，面对的却是一台Cisco的设备，你发出了数据包，却只能用traceroute来很不完整得跟踪它...掌握网络技术的代价实在是太大了，纵使再好的特性，只要厂商不跟进，你自己很难去模拟，去实现，你能做的，估计只能是用Linux来凑合了。

4.虚拟化和云对网络提出的新要求

虚拟化技术为网络提出了新的需求，可是老牌厂商们还是遵循老路，采用基于网络层级的封装技术来解决，于是出现了很多新词，比如VN-TAG，VPLS，OTV，VXLAN，甚至标准化协会也提出了诸如LISP等新技术，虽然这些新技术很大程度上解决了大多数的问题，并且其背后的理论也足够精妙，但是我们都知道，不管是老牌厂商还是标准化协会，它们都是既得利益者，谁也不想颠覆既有的标准，这，可以理解！
可是，封装技术治标不治本啊，为何出现了如此多的封装技术，且不多说上面那些新词，仅拿VPN说事就够了。之所以出现了这么多的重封装技术，并不是说逻辑意义上的递归层次划分会使网络结构更清晰，而是说明这个本来就不安静的世界上确实出现了很多很多的新需求，试问，30多年前的技术对于这些新的需求能hold住么？

5.传统网络模型的不给力

上述毕，当今的网络已经无法满足越来越多的新鲜需求，很多方面表现出吃力。

5.1.单点控制，没有全局视图

如今的网络技术几乎都是集中在网络设备这种硬件实体上，在管理上，第一，出现问题要排错，不得不牵连几十号人，一个一个点的登录排查，第二，要更新配置，不得不一个一个点的登录配置，没有一个统一下发的机制，我不想再夸OpenVPN了...在协议处理上，姑且不谈RIP这种矢量协议，即是OSPF也需要把链路状态洪泛到全部路由器才能使大家得到一致的视图；在QoS上问题更严重，QoS本来就需要在全局来控制，MTU发现是一种类似QoS的技术，可传统的网络除了诸如RSVP这种类似MTU发现这种自力更生的协议之外，没有一种在配置层面的机制可以完成全程的QoS监控和管理，况且，就算有这种自力更生的协议，最终的结果也是被动的，如果一个路由器配置了只能给你1M的带宽，你甚至都不能说你只需要0.5M就够了这句话！

5.2.收敛问题多多

STP，RSTP，RIP，OSPF，...一旦发生抖动，或者新加入一台新设备，大家都要折腾一番，某个环节出现了问题，你甚至都很难快速定位到底是哪里出了问题。

5.3.扩展性太低

如果需要一台路由器提供对下游双机热备设备的冗余，我们需要菱形的交叉连线，我们要做的是查阅该路由器的型号以确定是否可以支持新的接口模块，如果不支持那么就需要更换路由器，如果支持，我们需要提供整个配置列表用来更新路由器的配置，比如配置Teaming等；如果一个网络新加入了一台设备，可能需要对整个网络进行配置变更（近期我们的产品在实施，我可是深知其害，因此此文不是吹出来的），反之，撤掉一台设备也同样！
5.4.门槛太高
前文所述，如今的网络技术人员的技术水平几乎都是和特定厂商绑定的，因此一般的企业不敢随意变更设备，这意味着整个支持团队的变更或者再培训，而这些都是需要成本的。

6.转发和控制的分离

在讲三层交换机课程的时候，我们都听说过ASIC芯片，它其实是一种很傻的芯片，只会按照固定的程式来进行固定的动作，虽然有可编程的ASIC出现，然而它并没有持续编程能力，Cisco高端机型上，都存在一板子的ASIC芯片用来快速转发数据；和ASIC芯片处在另一个对立面的是CPU（别说GPU啊，它有时还更像ASIC），CPU核心芯片密集复杂，重复板块并不多，它需要你为它持续注入代码来为你快速计算出结果，比如路由计算和路由表hash查询或者数据任意算法加解密通常都是它来完成的，高端的Cisco机型除了具有ASIC芯片之外，还要具有一板子的高端CPU来提供快速计算能力，于是乎，高端机型的价值自然而然就上去了，掌握了操作它的人自然而然也就得瑟了，正如一个刚拿到驾照的小破孩开着一辆兰博基尼会嘲笑一个二十年驾龄的老师傅一样，那个小破孩可能不是富二代，可能只是一个卖车的，然而他要的是一种操控感，我想玩过Cisco 7400ASR的小破孩应该也有这种感觉吧。
CPU和ASIC同居一处的弊端是很多的，把它们拆开就成了SDN的核心，即CPU专门用于软件的处理，而ASIC专门用于硬件的转发，它们之间通过传统的网络通道来通信，CPU计算出来的转发策略通过网络注入到ASIC芯片，于是，它们中的任何一个都是可以替换的，成本立即节省了，操控人员的职责立即分离了，门槛也降低了！喜欢较真的同学们注意了，我只是用ASIC芯片来举例，真正的SDN并不一定非要用ASIC。

7.用代码写出网络

可编程芯片最好的选择是什么？是CPU！我们每一个IT人士都会对CPU编程，无论你写一个编译器，还是写一个BASH脚本，都是对CPU的编程，且看如下：
if [ $inport == 'E2' ] && [ $ip_src == '1.2.3.4' ]; then
set_outport E3;
fi
这是一个很简单的脚本片断，一般人都看得懂，是不是比以下这个更清晰呢：
ip rule add form 1.2.3.4 in E2 tab e3
ip route add 0.0.0.0/0 dev E3 onlink;
以上是一个Linux版本的Policy routing的配置，如果你不懂Linux的iproute2，你就要花大量的时间来学习，另外还有Cisco，H3C等不同的配置方式。哪一种更简单呢？我们希望的是将上述的BASH脚本注入到ASIC芯片中，上述的BASH脚本可以在一台普通的PC机器上编写和运行，然后通过网络将其结果写入到远端的一台定制的交换机或者路由器上，我们可以在一台PC机上写出无数的这样的代码，然后注入到不同的交换机和路由器，这个过程当然可以批量进行，这样真正实现了控制和转发的分离，用代码定义出了一个复杂的网络，而你根本就需要登录那些路由器和交换机，甚至也不要知道它们是什么牌子的，就像一个程序员那样，你只需要在那一台PC机上编程即可！

8.Cache思想-快速路经和慢速路径

Cache思想无处不在，SDN中，类似LISP，也采用了Cache思想，如果支持SDN的交换机查到了远端CPU注入的规则，那么就按照规则指示的行为继续，这个过程是很快的，如果没有找到注入的规则，那么就将数据包发送给远端CPU，由CPU来处理这个数据包，处理完了之后，CPU会将处理结果以及数据包的匹配项会送给支持SDN的交换机，这个过程不用多说了吧。

9.分层模型不再是厂商实现设备的依据

行文至此，我们需要插补一些关于网络协议分层模型的东西，一句话，协议分层简化了厂商为设备功能的定位，分层模型的核心是设备设计的简化，当初互联网络处于襁褓中之时，简化实现要素是首要需求，比如三层设备用来转发IP数据报，二层设备用来转发帧，这些分层的设备部署在不同逻辑层次的物理边界，比如公司出口要部署一台路由器实现公司内外的网段隔离，部门之间要通过三层交换机这个怪胎来隔离不同的VLAN（三层交换机是打破分层模式设备的首例！）。可是随着需求的膨胀和技术的发展，这种设计越来越多的被打破，出现了N层交换机，出现了XXXoYY等封装技术，划分如此规则的层次还有意义吗？
如果能用软件写出网络，SDN变成现实，那么我觉得分层模型真的就不想以前那么重要了，他留下来的唯一作用就是用来解析数据包用来匹配流表项最终确定如何来转发。既然它能完成数据包的匹配，那么更好的方式也能完成，目前Openflow是基于10元组通配来定义一个流的，既然网络支持虚拟化了，你可以用任何的元组来定义一个流，只是TCP/IP已经流行多年，况且IPv6解决了物联网（不是互联网）地址的问题，因此TCP/IP被证明还是一个成功的协议栈，因此SDN自然而然也就迎合了它，但是记住，SDN的出现，允许你自定义自己的网络协议（此处没有栈这个字，默认它不是分层的）。