这应该算是我在博客园的第一篇技术性的文章。
OH，不，这不是一篇技术性的文章，只是一篇很好玩的浅显分析接触到的技术的文章。只是个人的理解，并没有任何的代码和执行的操作。初次带来的，是从08年开始火起来的OpenFlow技术，希望对大家有所帮助，同时对文章中出现的一些错误的概念和理解，希望大家能提出宝贵的意见。
众所周知，计算机的快速发展无异于网络的出现，使得本来高高早上的计算机走进了千家万户。但是，网络这一概念刚刚提出来的时候，谁又能想到它会有现在这样宏大二不可或缺的地位呢？
这是当时提出互联网的技术人员所没有想到的，于是尽管科技在不断地向前发展，但是网络上面出现的问题也在逐渐的增加。
在这个网络时代，试想一下，如果某一天你起来的时候，世界网络受到黑客严重的摧毁，四周所有的东西发生了变化，你不能再上网去订餐，也不可能看网络上面那形形色色的国际新闻，也不能再去逛自己喜欢的论坛，和遥远的朋友也不能进行网络视频和对话，好似这世界的你突然变得孤单无助了。
OK，废话说了很多，不过这也是必须的，就像是两个人做爱一样，总要有一些前戏的，呵呵，请允许我如此放浪的比喻。
当前网络出现的问题越来越明显起来。我以我的观点归结一下，博友们还可以继续给我补充。
一、当前网络构架的缺陷。也就是当时提供互联网的技术人员并没有相当网络会发展到如此壮大，构架显得某些方面臃肿，某些方面不完善。
二、当前网络安全性很低。这应该算是主要的问题吧，现在黑客横行，世界上每年因为黑客攻击造成的损失都是一个巨大的天文数字。面对如此的问题，网络安全的要求便会变得越来越高。
三、网络逐渐脱离了我们的掌控。随着网络规模的扩大，越来越多的东西变得随意且不受控制起来，如果是公司或者是政府的网络连我们自己都控制不了，那么可想而知，问题就会接连不断的产生。
所以，一种安全的网络构架便成为了人们迫切的需求。而Openflow在这种情况下应运而生。
说了这么多，我们的猪脚终于出现了，真是千呼万唤始出来啊。当然，安全的框架并不是openflow这一种，真正的大规模的安全框架，包括美国欧盟和中国都在做，在此不再赘述，喜欢的朋友可以上网搜查。
控制整个网络，这好似有点出乎了我们的现在的能力的范畴，那么如何才能更安全的让网络为我们服务，有安全可控的特点呢？最好的解决办法，就是控制好网络中的设备，也就是交换机和路由器。
仔细想一下，交换机和路由器里面，对于网络流量的处理，是基于一张张控制转发表来控制的，那么我们只要控制了流量的转发，那么就可以达到控制网络的地步，Openflow就是在这样的环境下产生的一种协议，同时定义了一套可以利用的管理的API而通过控制交换机的转发。
而openflow实现这一操作，是通过对交换机下发一条条的流表项达到的。这样，就会使得转发层面和控制层面分离，变得更为安全可控。
一个可以控制的openflow交换机如何才能得到我们的控制呢。那么就离不开两样东西。一个叫做控制器，一个叫做命令集。
1，控制器（Controller），用来连接交换机，对交换机中的Vlan、接口进行控制，从而达到流量符合自己需求的转发的目的。
2，命令集（Command），openflow协议规定的一套接口所组成的一些命令，Controller通过命令集下发的命令来控制交换机中的流量。
对于上面的Vlan，大家可以在网络上搜索相关的信息，在此不再赘述。
而控制器的一个最主要的特点就是，在自己控制下的Vlan和属于这个Vlan之内的所有接口，都只听从自己的命令，只有自己下发命令的时候，它们才会做相应的动作。那么，它又是如何做到这一点的呢，知道了网络中acl的定义，大家应该就能很快理解了。
ACL访问控制列表是应用在路由器接口的指令列表，这些指令列表用来告诉路由器哪些数据包可以接收、哪些数据包需要拒绝。
Controller对交换机下发的流表项相当于是对交换机下发了一条条的规则ACL，来制定交换机中流量的动向。那么，这些流表项又是由那些东西组成呢？
大家先想象一下，我们在交换机里面的表项都是怎么组成的呢？
例如，路由表，有两个地址，一个是目的ip地址，一个是下一跳的ip地址。那么我们下发的流表项应该怎么构造呢？
1，流表项命令可以添加修改和删除，也就是含有ADD、DELETE、MODIFY三个参数的COMMAND命令。
2，流表项需要匹配我们需要的东西，比如源IP、目的IP、源MAC、目的MAC等。所有会有MATCH的操作。
3，对于我们匹配到的表项，我们要做和处理，于是就有了一个动作的组合，便有了ACTION操作。
于是，便可以知道了，基本流表项的组成就是COMMAND、MATCH、ACTION三部分。
我们就可以对我们想要转发的在控制列表之中的特定的流量进行转发，从而达到安全、可控的目的。
不过，虽然有这样的好处，但是Openflow之中也会存在着这样那样的问题，毕竟这个协议还不成熟。大概有以下几点问题。
一、下发流表项的时间可能会长一些。
二、openflow规定的接口API之中，并不能完全满足我们所有的需求，还有待完善。
三、设备制造商在全球范围内都被几个大公司垄断，在设备上使能Openflow协议便有了许多技术上的不开放性，这些和openflow协议刚提出的理念有些冲突。
综合来说，这是我刚接触openflow的一些浅显的认知，没有具体的实现和操作讲解，感兴趣的博友可以在网上搜一些openflow相关的技术性文章，相信大家看了我这篇文章再看他们的文章会更好理解一些。
我主要是为了抛砖引玉，希望勾起大家对于openflow的兴趣，同时弄一块简陋的垫脚石，让大家可以踩在上面，少一些对于学习openflow的疑惑。