Aug. 17, 2014, 11:47 a.m.

之前预告了要讲讲SDN的，后来发生了若干次博客荒芜事件。。最后不了了之。其实我的内心也是很想写博客的，每次想写的时候发现博客没法上传图片就停下来了。。 昨天狠下心终于用阿里云的OSS解决了博客上传图片的问题。可以看到图片的链接已经是华丽丽的aliyuncs.com

——题记

恩，去年夏天实习完后，就不得不进入了毕设阶段。毕设的老师选的是大二的《局域网和城域网》这门课的任课老师。

简单交流之后，就确定了我们的关系。呵呵呵。

然后他告诉我，我可以去看看NOX控制器。本来在这方面没有啥经验，听到XXX控制器感觉瞬间高大上。实习了一个暑假的Java结果又要用C++来做毕设，心里也比较呵呵。不过觉得也是锻炼机会，就接手了。

其实在那个时候我对交换机这一块完全没接触过（虽然自己各种折腾家里的路由器），我还在想SDN和CDN之间是不是有什么关系呢。。。蛤哈。。

于是，我与SDN的故事就这么开始了。

首先，不谦虚地，我说说传统交换 机吧。传统交换机分为两层：控制层和转发层（或者你可以说是控制面和数据面）

恩，多图杀猫。。。。。

就像图上这样。。

而SDN做了个什么事情呢？

答：就是把控制层抽了出来，使得多台交换机被一个控制层来控制。这样，只需要更改软件定义的控制层就可以在不更改硬件的情况下重写整个网络。再把功能抽成一个个的App（或者叫组件/component）实现自由扩展。

这就是SDN主要做了的事情。

SDN以控制层为中心，抽象出两个接口，所谓的“南向接口”和“北向接口”，意思就是字面意思。一个对应用，一个对交换机。

继续上图。

说到SDN就难免谈到OpenFlow。

如果说SDN是接口的话，OpenFlow就是这个接口的一种实现。OpenFlow就是SDN南向接口的实现。打通控制器和硬件之间的路。

控制器这里我们使用的是NOX，其实基于Java的FloodLight估计也差不多。

而北向接口的实现，自然我就只用过我们选的NOX控制器的组件接口了。。

OK，背景介绍到这里，我们进入正题

OpenFlow要求每个实现其接口的交换机配备一个 流表（Flow Table），流表用来记录符合某一规则的数据包的处理方式。

其实我觉得对这个机制的理解可以类似于软负载中心这么一个概念。

在软负载中：

服务调用者通过软负载中心获得服务提供者的地址，软负载中心处于旁路，服务调用者通过软负载找到服务提供者，软负载中心负责调度以及感知各个节点的状态。

OpenFlow中，交换机不仅是相互的通信，包括对数据包本身的处理都通过控制器的来告知。当交换机本地流表中有与数据包匹配的项目时，就不会再走控制器。大概类似上图的软负载结构如下：

流表也类似一个缓存，当不知如何处理一个数据包的时候交换机就会与控制器通信。

交换机和控制器之间的通信是OpenFlow协议，即基于TCP的一种自定义协议（这里注意TCP是第四层协议。。） 不过这里的链路也只是交换机开的一个特殊的口。不是交换口。

总之，通过以上这种架构，就能够通过对控制器的编程达成对下层网络的控制。在这种体系下实现一些链路层协议就比较容易了。于是我最后毕设做了个VLAN功能（通过在控制器上维持一个VLAN关系表，控制交换机之间数据的VLAN加标去标等事情，然后对连接到交换机的主机们透明）

使用SDN也能实现三层交换机的诸多功能。以及常见的spanning tree等协议。这时的交换机只是简单地执行者，而不会去计算各种算法。

目前的SDN在我看来还没怎么普及。我觉得这种体系首先面临着与软负载中心类似的挑战：

1.控制器负载很高的时候可能会存在错判的可能，即错误认为一台交换机已经down了。而实际交换机之间的网络是通畅的。这时候按理说交换机应该主动去检查网络连通情况，但链路不同怎么能在一起。。。

2.高并发下数据的正确性保证

3.单点扩成集群后同步的效率

还有就是作为二层设备依赖四层协议处理或多或少应该会牺牲些性能。

据说google内部已经把SDN用起来了，这玩意的好坏让时间去证明吧。。

大概就说这么多，写这些也是因为毕设做过，还是应该留下点痕迹。

如果你能看到这里真的是不容易。。谢谢关注。。