先讲一个冷笑话，我心目中的SDN交换机：
在我心目中，SDN交换机是这样的：
一个机框，
插上接口卡，可以做高性能数据交换;
插上控制卡，可以做网络层路由转发;
插上业务卡，可以做应用层流量管理、负载均衡、网络控制、用户管理、VPN……
多插业务卡，可以变成刀片服务器提升应用处理能力;
多插硬盘，可以变成网络存储;
多个机框之间可以采用全网状、fabric互联;
全网统一集中式管理。
但总觉得这个东西很早我就见过，一回头，我看到了——机柜!
也谈SDN
软件定义网络(Software Defined Network, SDN)这个概念在近期被炒的很火爆，但是很长一段时间内，并没有引发我的过多关注。原因很简单，大家都很闲吗?可以有事没事就对网络流量节构进行修改?况且自打Windows时代开始，系统编程再也不是一个独行侠可以解决的问题。没有一个研发团队的支持，网络流量的系统管理控制就会成为天方夜谭!开源软件是好，可是依靠一两个未经广泛验证的开源软件就可以解决用户网络应用管理的诸多问题吗?恐怕没有一个网络管理员敢把赌注压在这个上面。
然而去年对下一代防火墙的研究测试，给于了我新的启发。实际上下一代防火墙并未采用过多的全新技术，直白的说它就是一个应用流量控制与IPS、传统防火墙的高性能统一集合体。但却在短时间内迅速获得了广大用户的认同，得到了飞速的发展。为什么会出现这种情况?究其原因有两点:网络应用的安全与管理。了解网络中应用是否安全并对其进行可靠的管理这两点正是目前网络用户所迫切需要的。切中这两个关键点，即可解决目前网络用户所需要解决的主要问题，自然也就可以快速获得广大用户对产品的认同。
既然下一代防火墙就可以解决用户的网络应用问题，那为什么还要谈SDN?这就要从下一代防火墙与生具来无法解决的问题谈起。下一代防火墙无论性能如何提升，目前为止它都是一款网关类的安全产品。而目前，大规模(大型企业或电信级)的网络用户希望在网络的核心层同样实现这样的功能。在保障网络核心安全的同时，通过核心层的管理可以更有效的对网络应用流量进行控制。出于这种原因，我又把目光重新转向了SDN。
要解决核心层的网络应用流量安全及管理控制问题最终还得需要SDN。OpenFlow虽然实现了基于数据流的路径转发，但基毕竟还仅是基于网络层进行处理，无法在应用层上对数据流的内容进行过多的分析判断。要想实现应用层的网络安全管控，还得要看SDN的!再通过去年对路由、交换类产品新技术的了解，于是我构想出了文章最初冷笑话中的SDN交换机……
有人会问，SDN功能实现主要是依靠SDN控制器，而对交换机的SDN功能进行研究是否是本末倒置?对于这一点我个人是从这个角度来考虑的：SDN控制器无论是做为一个功能模块集成于交换机内部，还是做为一个独立硬件产品放置于交换机之外，均需要对整网的应用流量进行管理与控制。SDN控制器的整体性能取决于交换机SDN功能的处理能力。因此对交换机SDN功能的评估，也就从本质上反映出了SDN控制器的管理控制能力。
SDN 前行?踏步?!
如何对产品进行评估，测试无疑是最有效的方法。于是春节前我做了一个小功课，向各大厂商征询了一下厂商各自对交换机SDN功能的测试方法。由于离放假时间比较近，并未收取到所有厂商的回复。然而，从目前收集到的结果来看，让我不由得感到一些失望。大部份厂商给予的回复是基于OpenFlow技术规范要求进行测试，并留有API接口……
OpenFlow并不是不好，技术规范的制定解决了不同品牌交换机在虚拟网络架构下的数据流互通问题，同时也可以完成虚拟机全网迁移的功能，协助用户更好的进行云计算应用的实施。从云计算的角度来讲，OpenFlow确实是现在虚拟化网络的稳固基石，为虚机迁移提供了一个可靠的解决方案。然而用户在网络应用中，并非仅有云计算这一种网络应用需求，SDN其它网络应用管控功能全是未知，更无法了解到其SDN功能是否可以满足用户应用管控的实际需求。这样的产品是否可以放心选择，实在是令我难以判断。
难道SDN就是在云计算的台阶上原地踏步吗?如果真是那样SDN也就不会引发我的过多关注了。我的SDN功能畅想启蒙于两个厂商：思科与迪普。思科给我的启迪是在2013年初的一次6500交换机测试里，6500虽然是一款老机型，但思科为其提供了一个当时最新可以实现Nexus所有功能的引擎。在当时，那款引擎上已经提供了对网络应用进行深度内容分析的API接口，再利用思科的与UCS结合的网络应用管理软件即可实现基于网络应用的流量管理功能。当时，我就开始有一种交换机将与下一代防火墙相融合的初步设想。在去年年中，迪普发布那个不知应该叫交换机还是其他什么的可以基于应用进行负载均衡、特征分析具备强大应用层处理能力的DPX19000时，在我心目中对交换机的定义已经混乱了。当我把思维重新整理清楚后，我心目中的SDN交换机也就随之诞生了。同时我也坚定的认为，这将是网络核心交换产品未来的发展方向。
产品?功能?指标?评估?
产品
目标明确了，那么在现在交换机厂商中，是否可以通过已有的产品对其功能进行实现呢?可能通过什么样的交换产品来实现这个目标，SDN是否仅能存在于核心交换产品中，架顶式产品是否也可也完成同样的任务?但在交换产品厂商已有的公开发布产品中很难获取相关信息。
博科到是明确表标了在其现有的博科的MLXe系列交换路由器和Brocade NetIron® CES和CER边缘平台上优先进行了OpenFlow开发，但相关SDN功能性的指标还不是十分明确。
在迪普的网站上到是可以了解到DPX19000的各类技术指标，但其并未明确表明这是一款SDN交换产品，而是以“新一代去级业务核心平台”来为其产品命名……
由于存在着这些疑问，下一步我们还需要再进一步对厂商的SDN交换产品进行更深入的逐一了解。
功能
用户关注SDN交换机是为了获得更好的应用体验，而更好的应用体验需要在应用功能上进地实现，那么SDN交换目前及将来可以带来什么样的新功能呢?我们在下面试着来总结一下。
1、网络功能
SDN交换机的网络功能基本上可以通过OpenFlow相关标准协议来进行实现。目前可提供功能主要有以下几项：
(1)大流量网络数据传输
当前遵循OpenFlow协议标准的不同厂商SDN交换机之间可以做到数据流的互联互通。为高性能网络数据传输提供了相关的技术保障。
(2)用户认证、流量管理、 VPN
由于OpenFlow是基于数据流的路径转发，先天带有了用户认证、流量管理方面的技术优势。再通过MPLS等加密隧道进行数据传输，可以很方便的实现虚拟机迁移、BYOD接入控制等多方面的网络数据传输管理工作。
2、应用功能
上述SDN交换设备的网络功能在几年前的云计算网络产品中就已经可以实现，OpenFlow只不过是通过一个统一的技术规范来使各厂商产品之间数据流可以进行互联互通。然而这种互通还仅限于数据层面，在控制层面，不同厂商网络产品间统一进行管理目前尚未得以实现。因此如果用户采用不同厂商SDN网络交换产品，在集中管理控制上还存在相当多的问题。这也是用户不敢贸然采用SDN技术的原因之一。况且，即便不采用SDN技术，在各厂商的网络解决方案中，也有对相关功能的全面解决方法。无非是以后需要统一采用同一厂商的网络核心及接入设备而已。因此，如果SDN交换设备的产品功能仅能提供基于网络层相关功能，那SDN的发展，前景堪忧。
因此SDN交换设备要相获得大多用户的认同，势必需要向网络应用功能方向进行发展。然而目前所获得的SDN应用功能还仅限一句空洞的“可以向第三方提供API接口”。这让人不由得产生一种想住七层的房子，但开发商告诉你只能建到三层，剩下你只能私搭自建的郁闷感。
但这并不能阻挡我对SDN网络应用功能的期望。于是我依据现有网络产品可提供的网络应用处理功能试着罗列了一下
(1)网络应用可视化
网络应用分析，这是目前用户关注的热点，只有知道网络中具体在跑那些应用，才可以有针对性的去进行进一步管理。
(2)应用流量管理
应用分析后自然需要进行管理，这自然也是SDN今后必然需要提供的一项功能
(3)深度文件内容分析
无论何种企业在网络应用中，网络安全问题始终在对用户进行着困扰。深度文件内容分析不但可以做为网络安全防泄密的最后一道防线，还可以协助用户更好的实现网络安全等级保护。因此，此项工作在未来SDN网络应用中也将必不可少。
(4)网络应用安全
这项功能实际上是从深度文件内容分析引申出来的，在可以进行文件内容深度分析后，自然可以通过一系统数据对比，将IPS、AV等网络安全功能也加载进去，但这种功能确实可以由第三方安全厂商来提供，没有十分的必要让网络厂商再亲力亲为了。
在这里，我不由得想起了华为在13年中发布的AR G3企业应用路由器，这款产品通过华为提供的OSP开放业务平台，为用户提供集成多种业务和应用的开放式一体化解决方案。AR G3就好像一个智能手机一样，提供一套开放的系统平台，用户需要什么应用，就可以自行在上面添加。从而满足用户在语音、安全、管理和网络优化等方面的不同需求。我想未来的SDN交换系统可能也会采用同样的架构，提供相应的软、硬件系统平台，让用户自由选择所需的应用功能，自行搭建可以满足自身应用需求的应用网络系统。就好像建好了七层的毛坯房后，让用户自己选择如何去装修，而不是让用户自己去建房子了。
指标与评估
光有功能是不行的，我们还需要理智的对产品去进行分析与判断。判断问题要讲方法明需求。OpenFlow的相关技术规范，可以令我们了解交换机在网络层数据转发的处理性能。然而在我设想的SDN交换机中，还有许多网络应用功能，这是需要对网络应用流量处理性能进行了解的。这是OpenFlow测试所不能提供的。如何解决这个问题。恐怕还是需要借鉴目前已相对成熟的网络应用性能测试指标。那么哪些指标需要我们去进行关注呢?下面我试着罗列了一下：
基本性能指标：吞吐量、时延
虽然OpenFlow实现了基于数据流的路径转发，但其基础的网络传输性能还是要靠吞吐量和时延去进行判定
但是在去年的下一代防火墙测试中，发现了一个问题，那就是在吞吐量测试中，64Byte的小包吞吐量是否需要达到100%?得益于流量分析及应用可视化技术的发展，我们现在可以清晰的对网络中流量数据进行分析，在分析过程中我们发现64Byte的小数据包在网络数据传输中所占比例基本上未达到1%，不同网络应用模式下的平均数据包长度在600Byte-700Byte之间(不同网络应用平均数据包大小会有差异)，也就是说在吞吐量性能在64Byte可以达到线速的情况下，实际应用中有90%的处理性能是被空置的。这就产生了一个问题，我们需不需要因为这“1%(64Byte线速吞吐量)”而浪费那90%的处理性能?这个问题希望在后面的测试评估中再进一步进行一下分析。
可以提一下的是，为了避免性能浪费，在去年下一代防火墙性能测试中我们设置一个网络性能的及格线：64Byte吞吐量10%、512Byte吞吐量90%、1518吞吐量100%。由于SDN交换机是基于数据流进行数据转发，必然会在数据包中加一些识别标记，这样可能在吞吐量测试中会无法达到100%的传输速率，这时吞吐量应如何统计?这个问题我想还需要在下一步的实际测试中再进一步研究一下。
OpenFlow性能测试指标：
OpenFlow的性能测试指标目前常见的有OpenFlow协议握手(兼容性：例如OpenDaylight、Floodlight、NOX等)、流表下发、报文传输、流表容量功能验证等几种，虽然上述指标可以在基本性能指标的吞吐量、时延中也能得以体现，但利用最大流表进行相关OpenFlow的满流量测试，我们可以更好的对有关交换机OpenFlow数据传输时的性能进行分析。
SDN应用处理性能：
虽然目前SDN交换机还没有提供十分详尽的应用层处理功能，只是提供了相关的API接口，但没有应用处理能力进行支持的话，SDN交换产品也就会仅局限于为云计算应用提供支持，这样SDN交换的应用范围也会随之急剧变小。
要想对SDN交换机应用处理性能进行评估，还要对SDN控制器的应用处理性能进行测试。这里，不妨借鉴一下网络应用处理的性能指标：新建连接速率、并发连接数以及应用层吞吐量(应用流量)这三个指标。
有关这三个性能指标，在去年的下一代防火墙测试中，我们也进行了一下研究，并试验着也划出一个及格线，这里也来简单介绍一下：
新建连接：每兆带宽、每IP、每秒8个连接
并发连接：每兆带宽、每IP、200连接
应用流量：64KB、512KB、1024KB文件大小下，带宽的95%
简单说明一下：这个及格线的标准实际上定的并不低，通过以往应用性能统计我们可以了解，在实际应用中，用户实际用到的新建连接速率平均下来，也就在每兆带宽每秒4个连接左右。而并发连接，每个用户同时用到的连接数不会超过100个连接。而应用流量，如果用户的网络流量使用率在70%以上，用户首先想到的就是网络扩容了。因此，这个及格线已经为用户网络发生异常留下了一定的冗余空间。当然如果碰到12306春运时的网络应用状态，这个及格线可能就会不够了……
