SDN测试系统的研究与开发.docx

SDN测试系统的研究与开发摘 要软件定义网络（Software Defined Networking，SDN）是近年提出的一种创新型的网络架构，其核心思想是控制与转发分离，使得网络具有可编程的特性。与传统的网络相比，SDN可以简化网络的管理，提高网络灵活性，并且赋予网络强大的可编程特性。随着SDN 的不断发展，越来越多的组织参与到SDN 的相关研究与开发中来。所以，不同SDN 参与者对SDN 中协议理解的一致性与对SDN相关功能实现的正确性，变得越来越重要。而测试正是检验和保证相关一致性与正确性的最佳方法。但是，因为SDN 北向接口尚未统一等原因，目前针对SDN 测试的相关研究主要都是针对SDN南向接口相关的研究，SDN北向接口测试的相关研究几乎没有，而同时结合SDN南向接口与北向接口的研究更是一片空白。本文针对以上情况，对SDN测试相关技术问题展开了讨论，提出了SDN测试系统架构，并实现了其功能。主要工作如下：（1）结合测试相关技术以及SDN现状，分析SDN测试需求，分析总结出SDN测试需要包括的SDN测试内容。将SDN测试内容划分为协议测试与功能测试两部分。在北向接口协议测试部分，考虑到北向接口并没有统一，在制定相关测试内容时，根据北向接口抽象的功能而不是具体的协议内容制定测试内容。（2）结合SDN测试内容，提出SDN测试系统架构，并实现其功能。在实现北向接口相关测试时，采用了抽象功能与配置文件相结合的方式。在具体针对某种SDN北向接口协议进行测试时，可以通过配置文件将具体的北向接口协议与测试内容结合起来，从而实现了对不同北向接口协议的兼容。（3）提出了一种动态SDN路由校验算法。在对SDN控制器进行功能测试时，需要对SDN控制器为数据包计算的路径优劣进行评判，如果使用KSP 算法，时间性能较差。本文在KSP算法的基础上，提出了一种动态的SDN路由校验算法。算法的验证结果表明，该算法的时间性能明显优于KSP算法。关键词： 软件定义网络 协议测试 功能测试RESEARCH AND DEVELEPMENT OF SOFTWARE DEFINED NETWORING TEST SYSTEM ABSTRACTSoftware defined networking (SDN), where network control is decoupled from forwarding and is directly programmable, has been put forward in the last several years. The new form of network architecture has been proving the effectiveness, management convenience and enables the programmability. With the continuous development of SDN, a growing number of organizations take part in the research and development of SDN. As a result, it is more and more important to make sure that different participants understanding of the agreement is consistent with each other and they implemented SDN functions correctly, and testing is the best way to achieve this goal. However, because the northbound interface of SDN has not been standardized yet, current research and study of SDN test are Southbound interface-related test, and there is almost no study of the test of SDN northbound interface or the test combined with northbound interface and southbound interface. This paper focus on the research and application of SDN test system which can do northbound interface-related test as well as the test combine with northbound interface and northbound interface, and this paper includes following work:(1) Analyzed SDN testing requirements according to test technology and SDN situation. Determined SDN test content which includes protocol test and function test. Considering that the northbound interface of SDN has not been modified yet, the northbound interface-related test content is determined by the northbound interfaces function but not the specific protocol.(2) Proposed a SDN test system architecture according to SDN test content and achieve its functions. The system is not associated with any specific northbound interface but abstract northbound interface functions. When doing northbound interface-related test, the system can recover northbound interface protocol according to configuration file, so the system is compatible with different northbound interface protocol. (3) Proposed a dynamic routing verification algorithm for SDN. When verifying the route path calculating function of controller, the test system have to judge the merits of the route path calculated by controller. If use KSP algorithm, the test will waste a lot time, so we proposed a new algorithm base on KSP algorithm whose time performance is better than KSP algorithm.KEY WORDS: Software Defined Networking, Protocol Testing, Functions Testing目录第一章 绪论11.1 选题背景及意义11.2主要工作21.3论文组织结构3第二章 相关技术研究52.1 SDN52.1.1 SDN 概述52.1.2 SDN 南向接口与OpenFlow72.1.3 SDN北向接口与REST架构风格92.2 测试技术122.1.1 协议测试122.1.2 系统功能测试132.3 SDN测试研究现状142.4 本章小结17第三章 SDN测试内容设计183.1 SDN 接口协议测试183.1.1 南向接口协议测试183.1.2 SDN北向接口协议测试223.2 SDN 功能测试263.3 本章小结27第四章 SDN测试系统设计与实现284.1 SDN测试系统架构284.2 协议测试功能实现294.2.1南向协议测试294.2.2北向协议测试294.3SDN算路功能测试实现304.3.1SDN路由算法314.3.2动态SDN 路由验证算法344.3.3动态SDN路由验证算法性能验证354.4 本章小结37第五章 SDN测试系统功能验证385.1 南向接口协议一致性测试385.1.1 实验环境说明385.1.2 典型测试用例与结果395.2 北向接口协议一致性测试405.2.1 实验环境说明405.2.2 典型测试用例与结果415.3 控制器功能测试435.3.1实验环境说明435.3.2 典型测试用例与结果445.4 本章小结46第六章 总结与展望476.1 本文总结476.2 未来展望48参考文献49攻读学位期间发表的学术论文51第一章 绪论第一章 绪论本章首先介绍了什么是软件定义网络（Software Defined Networking， 即SDN），然后说明了对SDN测试系统进行研究的意义，其次介绍了本文的主要工作，最后介绍了本文的章节安排和论文组织。1.1 选题背景及意义在当今社会中，随着互联网的不断发展，互联网在人们的日常生活中，发挥着越来越重要的作用，但是，也正是因为互联网的不断发展，整个互联网变得越来越臃肿，导致其原有的网络架构，不足以满足当下各种企业、数据中心、运营商或者是个人用户的需求1。在传统的网络架构中，不同的网络设备之间相互配合，共同连接成完整的网络。每个网络设备都有比较独立的控制平台与操作系统，不同的网络设备之间通过分布式的网络协议进行信息与数据的交换。例如，在传统的交换机和路由器的设计中，其数据转发平面与控制平面是紧耦合在一起的。随着整个互联网的不断发展，各种问题随之而来，为了解决相应的问题，研究人员不得不提出更多，更复杂的网络协议，尤其是在传统的控制平面和数据平面紧耦合的情况下，每当出现一种新的需求，就需要定制或者修改相关的网络协议，以便实现这种需求。不难理解，随着网络的不断发展，这个网络设备的控制功能就会变得越来越复杂，同时，对设备进行相应的配置也会变得越来越困难。不仅如此，设备的复杂性也使得为当前设备添加新的功能变得越来越困难，对网络的发展带来了很多负面的影响。这种网络架构一方面使得其原本的重要缺陷与不足在相当长一段时间内都得不到修改，网络很难得到有效的控制，网络的安全相关的问题层数不穷；在另一方面，新的网络应用的出现，比如在线高清视频、云计算、网络电话和高速互联网的出现都对现有的网络提出了很大的挑战。除此之外，对于网络管理人员、网络研究人员以及网络设备商来说，要在现有的网络基础之上进行网络创新是十分困难的。具体来说，新的网络技术、网络理论很难得到验证，网络管理人员也无法根据网络的实际情况，对网络管理过程进行简化；网络运营商也难以针对具体的需求对网络进行相关的定制、优化以及维护；对设备商来说，也难以开发新的网络设备，来满足新出现的用户需求2。为了解决上述的问题， 软件定义网络（Software Defined Networking， 即SDN）应运而生。SDN是一种新型的网络架构，于2006年诞生于斯坦福大学，并且自提出以来就受到业内的普遍关注，并且相关技术取得了迅猛的发展。SDN的最大特点就是控制与转发分离，并且使其可以直接进行编程2。从而，网管人员可以通过软件编程的方式来配置简化的、抽象的网络实体，而不是像以前那样，手动得去编写分散在每个设备当中的，成千上万行的配置命令。不仅如此，因为SDN具有集中控制的特性，网络的管理者可以实时地去调整网络的转发行为并且可以再短时间之内部署新型网络服务与应用。通过SDN的控制平台对网络状态进行集中的收集处理，SDN不仅给网络管理者提供了在配置、管理、优化和保护网络资源的灵活性，并且也可以通过自动化的SDN程序来完成这些工作3。SDN的网络架构分为三个层级，自下而上分别是转发层、控制层和应用层。这三个层级通过两个不同的接口进行交互，转发层与层之间的接口为南向接口，控制层与应用层之间的接口为北向接口2。随着SDN的不断发展，越来越多的组织和厂商参与到SDN的相关研究与开发中来，为了实现不同厂商和组织的SDN设备的协调运作，就需要不同SDN 参与者对SDN 中相关协议具有一致性的理解以及对其相关功能进行正确得实现。而对SDN的协议以及各个模块进行测试，正是检验不同SDN参与者对协议理解的一致性和对功能实现的正确性的最好方式4,5。但是遗憾的是，因为SDN北向接口尚未统一等原因，目前，对SDN测试的相关研究都集中在SDN的南向接口相关的测试研究上，对SDN北向接口的相关研究几乎没有，而同时集合SDN的南向接口和北向接口的研究更是一片空白，所以，对具有SDN北向接口测试功能以及南北向接口进行联合测试功能的SDN测试系统进行研究，具有重要的意义。1.2 主要工作本文主要针对SDN 测试相关内容进行了研究，结合SDN 测试要求，提出了SDN 测试系统，主要工作有：（1） 调研SDN 技术以及SDN 相关测试技术发展现状，结合SDN 具体情况，分析SDN 测试需求，结合测试技术，制定SDN 测试内容。将SDN 测试分为协议测试和功能测试两部分。在协议测试中北向接口测试部分。根据SDN 北向接口尚未统一，但是SDN 北向接口的功能大体类似的情况，对SDN 北向接口进行功能抽象，根据抽象的SDN 北向接口内容，制定SDN 北向接口相关测试项。（2） 结合具体的SDN 测试内容，提出SDN 测试系统设计方案，并且实现其功能。在北向接口测试部分，由于测试内容是根据北向接口实现的功能所制定的，并没有关联到具体的协议。所以提出了一种抽象功能和配置文件相结合的方式。根据北向接口的功能划分制定相关的测试用例，然后在实际测试过程中，通过配置文件将具体北向接口协议内容与相关测试用例结合起来，从而进行与具体北向接口协议相关的测试。（3） 在针对SDN 控制器算路优劣进行测试时，虽然可以使用传统的KSP 算法进行评判，但是使用KSP 算法进行评判时，会消耗比较多的时间。所以，针对这一实际情况，本文提出了一种基于KSP 算法的动态SDN 路由验证算法。并且通过实验验证了使用该算法进行路由验证的时间性能明显优于使用KSP 算法。（4） 搭建SDN 测试环境，使用SDN 测试系统进行了SDN 南向接口和北向接口的协议一致性测试以及SDN 功能测试，验证了SDN 测试系统的可用性。1.3 论文组织结构本论文共六章，其组织结构如下：第一章绪论简要介绍了 SDN 技术以及相关技术发展现状，指出了现有的对SDN 测试相关研究的不足，进而阐明了本文的研究意义。第二章介绍了本文研究内容所设计到的一些技术背景内容。首先介绍了SDN 相关的基础知识，包括SND 架构进行了介绍、SDN 南向接口以及南向接口使用的标准协议OpenFLow 协议进行了、SDN 北向接口发展情况以及目前SDN 北向接口普遍采用的REST 架构风格；接着介绍了SDN 测试所涉及到的一些测试技术；最后介绍了SDN 测试目前的发展状况。第三章根据SDN 具体情况，制定了SDN 测试的测试内容。SDN 测试内容包括协议测试和功能测试两部分。其中协议测试包括南向接口协议测试和北向接口协议测试，其中在北向接口协议测试的部分，考虑到北向接口并未统一的情况，对北向接口的功能进行了抽象，根据北向接口的功能而不是具体协议内容制定了相关的测试内容。功能测试包括对交换机、控制器以及网络应用相关功能的测试。第四章根据第三章提出的SDN 测试内容，设计并实现了SDN 测试系统。在北向接口相关的测试部分，因为北向接口的测试内容是根据抽象的北向接口功能制定的，所以在实际测试过程中，测试系统根据配置文件，将具体的北向接口协议与北向接口功能结合起来，从而进行相关测试。在对控制器进行算路功能测试时，提出了一种时间性能较好的SDN 动态路由校验算法，并对算法的时间性能进行了验证。第五章搭建实验环境，使用测试系统，分别进行了SDN 南向接口协议一致性测试、北向接口协议一致性测试以及对SDN 控制进行了功能测试，并且展示了部分测试结果。第六章。对整篇文章进行了总结，并且提出了当前工作中尚且存在的不足，对下一步的工作进行了展望。53第二章 相关技术研究第二章 相关技术研究2.1 SDN2.1.1 SDN 概述如图2-1所示，在传统的网络中，其体系架构是分布式的，每个网络设备具有相对独立的控制器平台和操作系统，不同设备之间通过网络协议交换数据和信息6。图2-1. 传统互联网体系架构这样的结构有以下的缺点：（1） 网络设备比较复杂在当今运行的互联网中，有大量的相对独立的协议，网络通过这些协议保证主机在任意拓扑结构、任意距离和任意链接距离上的可靠连接。在过去的几十年中，业界为了提高网络的可靠性、性能、安全性，不断提出新的网络协议，来满足技术和商业上的需求。但是，这些协议都是相对独立的，即每种协议往往只解决一个特定的问题，缺少协同，从而使得网络变得越来越复杂，网络设备的设计和实现的复杂性不断提高2。（2） 控制平面与转发平面的耦合使得新的特性难以添加在网络的实际运作当中，用户的需求是不断的变化的，这就要求企业和运营商不断部署新的服务来满足用户变化的需求2。但是，在传统的网络中，网络应用和网络设备是绑定在一起的。每个厂商的网络设备都要有自己独特的操作系统和硬件，并且大多数情况下是互不兼容的。要添加新的特性，往往需要硬件厂商的支持，而且很难在不同厂商的硬件设备之间通用6，这无疑会限制商业与用户需求的满足。 （3） 配置相对困难现有的网络体系架构，决定了网络当中必然有大量的网络设备需要配置，对持续增长的用户实施统一的安全、接入、Qos等控制策略需要消耗大量的人力物力，并且有可能引发其他的负面效果2。针对以上问题，软件定义网络应运而生。SDN 的主要特征可以概括为将网络的控制平面与转发平面分离，并且使得网络具有可编程的特性2,7。因为SDN 将网络的控制平面与转发平面分离，所以，SDN 的转发设备并没有本地的控制逻辑，完全依赖于控制器平面对其转发行为进行配置与维护。SDN 的核心价值在于降低了在控制平面之对进行满足特定需求的应用的开发难度，这点对于发展新的应用尤为重要，这使得对网络的控制变得更加灵活，并且能够降低网络维护的成本8。图2-2. 软件定义网络架构SDN 的网络架构如图2-2是所示。SDN 从下往下分为三层，依次是转发层、控制层和应用层。转发层主要包括SDN 的转发节点，最常见的转发节点是SDN 交换机，转发层与SDN 控制层协同工作，根据控制层的指令，完成对数据包的转发；控制层是整个SDN 的核心部分，主要由SDN 控制器组成，与传统网络的每个控制节点只能控制一个转发节点不同，在SDN中，整个网络的智能控制部分全部集中在控制器上，控制器可以从转发层获取整个网络的全局视图，也可以对所控制器域内的任何一个转发层的节点进行操作，很明显，这能够在很大程度上提高网络变动和设计的自由度，并且使得在短时间内部署新的应用成为了可能；应用层主要有开发者根据控制层所提供的网络接口所开发的网络应用组成2。在SDN 架构中，存在两个接口：南向接口和北向接口。南向接口是控制层与转发层之间的接口。控制器获取转发层的全局网络拓扑以及对特定的转发节点进行操作，都是通过南向接口完成的。北向接口是应用层与控制层之间的接口。控制器通过北向接口向应用层暴露所提供的功能，应用层的网络应用北向接口从控制层获取底层网络信息或者向控制层下发相应的命令。此外，SDN强调网络的可编程特性，网络的操作者可以对经过抽象和简化处理的网络进行网络编程，而不是给分散的各种网络设备发送成千上万的冰冷代码，这样就使得网络管理者对网络配置、管理和优化有了更大的灵活性，对计算、存储和网络资源利用更加充分。总之，SDN的出现，刷新了人们对网络架构的认识，使得人们对未来网络架构有了更广阔的概念。2.1.2 SDN 南向接口与OpenFlow 在互联网的发展过程中，由于网络设备商为了保护自己的利益，往往会在生产转发设备的过程中，对其内部实现进行封闭。这无疑会对互联网的发展带来负面的影响。在此背景之下，在SDN 发展的初期，美国斯坦福大学的研究人员就提出了一种标准的SDN 南向协议OpenFLow 协议7。如今，OpenFlow 协议已经受到了业内的广大认可，并且被各设备厂商所接受，几乎在所有的SDN 网络中，都采用了OpenFlow 协议作为南向接口通信协议。OpenFlow定义了转发设备上的一个标准化接口， 该接口可以用于转发设备中转发规则的定义与修改，从而使得网络设备可以灵活快速地对新型网络协议提供支持。这种创新的设计方式不仅可以保证不对外公开设备商产品的内部实现，而且能够支持研究人员充分利用大规模网络设备进行试验，同时不对网络上运行的原有业务造成影响7。自从被提出以后，OpenFlow 的相关维护与其新版本的发布都有开放网络基金会（Open Networking Foundation， ONF）9主要负责。在2008年3月，版本号为0.2.0 的OpenFlow 第一版被发布。随后，0.8.0,0.8.1和0.8.2版本相继问世。在2008年12月，增加了数据统计功能和IP 子网掩码功能的0.8.9版本发布。2009年末，ONF 发布了OpenFlow 的第一个正式版本OpenFlow 1.0版10。OpenFlow 1.0版一经发出，就得到了各种SDN 设备的广泛支持。随后，ONF 又发布了OpenFlow 1.1 版、1.2 版、1.3.0版、1.3.1版、1.3.2版、1.3.3版、1.3.4版、1.3.5版、1.4.0版、1.4.1版、1.5.0版以及目前最新的1.51版（截止2015年10月）。OpenFlow 1.1 版本相对于OpenFlow 1.0 版本，最大的变化就是增加了对组表和多级流表的支持。除此之外，对协议中用来匹配的字段进行了扩展，并且支持MPLS 标签匹配。因为加入了多级流表，转发设备对数据包的处理方式也有所改变：数据包先会与第一个流表中进行匹配，如果可以匹配，就执行相应的转发策略，如果匹配后指向另外一个流表，数据包则会被传到另外一个流表中。与此同时，流表中的条目也可以指向组表，组表中定义的action 是多个流表条目的集合，使得负责的转发策略，比如多链路和链路集合可以通过组表来实现11。ONF 在2011年12月发布了OpenFlow 1.2版本。1.2版本与之前的1.1版本相比，增加了对Ipv6地址的支持，所以在流匹配的时候，具有基于Ipv6源地址和目的地址的匹配功能。此外，OpenFlow 1.2 版本的另一个重要改变是，使得一个交换机可以和多个控制器建立连接，从而在控制器发生故障的时候，可以快速切换，提升了网络的可靠性12。OpenFlow1.3版本在2012年6月发布。在1.3版本中，增加了对报文速率控制的功能。此外，1.3版本还在流统计的报文中添加了特定的时间字段以及在报文中添加了对cookies 的支持13。OpenFlow1.4版本于2013年10月发布。OpenFlow1.4版本在数据转发部分增加了流表同步机制，可以让多个流表在共享匹配字段的同时，又可以定义不同的动作。同时，OpenFlow1.4还增加了Bundle 消息，Bundle 消息可以确保控制层同时向多个转发节点下发消息时候状态的一致性。另外，OpenFlow1.4还增加了对光网络的相关支持，支持对光属性接口的相关描述14。目前，最新版的OpenFlow 版本为OpenFlow1.5版，其中，1.5.0在2014年8月发布，1.5.1版本在2015年4月发布。与之前的版本相比，OpenFlow1.5增加了对数据包在输出端口的处理。在之前的版本中， 对数据包进行的处理，都是在数据包进入端口的时候进行处理，而在OpenFlow1.5中，符合特定要求的数据包，可以在对其进行输出之前进行处理。此外，OpenFlow1.5引入了数据包识别管道，使得可以同时支持多种数据包，比如IP 数据包和PPP 数据包15。基于OpenFlow 的SDN 网络中转发节点与SDN 控制器如图2-3所示。图2-3. 基于OpenFlow 的SDN 网络转发节点与控制器OpenFlow 的工作原理大致如下：当一个数据包到达转发节点之后，转发节点会将该数据包的头部取出，将数据包头部信息与该节点中的流表中的信息相匹配，如果找到匹配的流表，则根据该流表的策略进行处理。同时，转发节点需要预设如果数据包头部与流表不匹配情况下的策略，比如丢弃报文、将报文信息上报给控制器等。若控制器收到转发节点所上报的消息时，需要根据转发节点所上报的消息以及目前网络情况，为该数据包计算新的路由，并将路由下发给所有相应的转发节点。2.1.3 SDN北向接口与REST架构风格SDN 北向接口是控制层与应用层之间的接口。通过北向接口，控制器可以向网络应用提供获取底层网络资源信息与控制底层网络的能力。通过北向接口，网络应用的开发人员可以通过软件编程的形式来获取整个网络的网络资源状态，并且根据整个网络的情况，对底层资源进行整合调度。因为北向接口是直接面向网络业务的，所以，北向接口在设计时需要与相关网络业务紧密结合，同时，因为网络业务的多样性，北向接口也需要满足各种业务多样性的要求。不仅如此，北向接口作为一个直接面向众多网络应用开发人员的接口，北向接口设计的合理性、便捷性等都会影响到北向接口相关控制器的发展前景。目前，虽然对于SDN北向接口的具体内容上仍存在些许争议，但是业内已经对于SDN北向一口一些应有的特征有了一致的意见。从设计目标上看，SDN控制器北向接口需要足够的开放性，使其可以为网络运营者提供足够的能力，使他们能够快速进行网络调整和定制，以及使所有网络用户都能利用他开发网络应用。从技术实现上看，目前REST 形式的接口已经成为SDN 北向接口的主流实现方式，目前绝大多数的开源控制器，比如OpenDayLight16、Floodlight17等的北向接口都采用了REST 接口的形式。REST 即表述性状态传递（Representational State Transfer，简称REST），它并不是一种具体的协议，而是一种基于Web应用的软件架构风格。REST在2000年由Roy Fielding博士在他的博士论文中首次被提出。 与传统的架构风格相比，REST可以明显提高系统的伸缩性并且降低软件应用开发的复杂性18,19,20。在REST 中，有两个比较重要的概念：资源状态和应用状态。其中，资源状态以表示的形式发送给客户端，保存在服务端。应用状态保存在客户端。当对一个资源进行改动时，应用状态会作为POST、PUT、DELETE 请求的一部分，发送给服务端，转变成资源状态。在REST 风格的服务中，服务器端在相应GET 请求或者客户端在发送POST 和PUT 请求的时候，都需要附上相关的表示，而服务的状态也从应用状态向资源状态转移，这便是表述性状态转移，也是REST 风格无状态性的基础18。REST 具有如下主要特点：（1） 可寻址性可寻址性表示在REST 风格的实现中，会为每一个对外提供的信息都发布一个对应的URI 。在REST 中，所有的资源都是通过 RUI 向用户暴露的，所以，作为一个以资源为中心的架构风格，REST 具有可寻址性的特点18。站在用户的角度，无论对于网站还是应用来说，可寻址性都是十分必要的。因为对于那些用户需要访问的资源，只有这些资源是可寻址的，用户就会去访问他们，但是，如下相应的资源在应用或者服务端中是不可寻址的，用户就无从访问这些资源19。（2） 无状态性无状态性，表示在REST 架构风格中，每个HTTP 请求都是相互独立的。即每个由客户端发出的HTTP 请求都会包含服务器端相应该请求的全部信息，服务器端不需要依赖之前任何请求提供的信息。如果服务器端在相应某些请求时需要之前请求的信息，那么，在本次请求中就需要携带之前请求的相应信息。同时，无状态性与可寻址性直接也有相应的联系。如上文所述，可寻址性要求在服务器端，所有有价值的数据有需要以资源的形式来进行发布，请求需要为每个资源关联唯一的URI 。与之类似，无状态性要求服务端可能的资源状态也是一种资源，也具有与之对应的URI。所以，这样就避免了服务器接受了某个请求之后，进入另一种状态，从而避免了多次同样的请求获得不一样的结果，实现资源请求的独立性。无状态性还有助于服务器端负载均衡的实现：因为请求的无状态性，所以任何请求都不需要服务器之间的协作，每个请求都可以放在某个单独的服务器上进行处理。在需要提升或者降低服务器规模的时候，只需简单得增加或者减少服务器的数量即可。除此之外，无状态性也给用户带来的方便，比如，如果用户在访问了一个资源之后，如果随后又需要访问该资源，那么只需要简单的访问之前访问过的URI 即可，而不必在访问之前恢复前一次访问的状态。（3） 链接与连通性在REST 架构风格中，HTTP 会话的当前状态并不会作为资源保存在服务器上并且向客户端提供，而是通过客户端的应用状态来进行跟踪。服务器端可以通过在请求返回的表示中给出链接，来引导客户端应用状态的改变，这里的链接将各种资源连接起来。客户端在服务端的指引下进行状态改变，客户端的状态与状态之间，通过服务端给出的不同的链接的引导实现相互到达，这便是服务的连通性。如果一个服务具有很好的连通性，那么对于客户端来说，只需要通过链接和请求就可以实现应用状态的转换。与之相反，对于那些没有很好连通性的连接，客户端状态的转换就相对困难，只能根据事先与服务端约定的规则，构造相应的URI ，实现状态的转换。（4） 统一接口REST 在对资源进行操作时，采用了统一的接口，即HTTP 协议中的GET（获取现有资源）、PUT（修改现有资源）、DELETE（删除现有资源）、POST（创建一个新的资源）、HEAD（获取一个只包含元数据的表示） 和OPTIONS（查看一个资源支持哪些HTTP 方法） 等方法。其中，GET、PUT、DELETE 和POST 为常用的四个方法，HEAD 和OPTIONS 用得较少。因为使用了统一的接口，降低了服务端与应用端的耦合程度18。2.2 测试技术2.1.1 协议测试随着网络的不断发展，各种新的协议不断涌现，并且协议的内容变得越来越复杂。不仅如此，在一般情况下，协议都是使用自然语言描述的，所以，不同的厂商对同一个协议的理解难免会有不同，同时，对协议的具体实现上，也难免会与原始协议有所偏差。为了验证对协议实现的正确性，协议测试技术应运而生。并且经过不断的发展，已经成为了协议工程的一个重要组成部分21。一般的协议测试，主要包括四部分内容22：（1） 一致性测试(Conformance Testing)：一致性测试是协议测试的基础，用于检测所实现的协议与协议规范描述的符合程度；（2） 互操作性测试(Interoperability Testing)：检测统一协议的不同实现版本之间、同一类协议不同版本之间互操作和互通能力；（3） 性能测试(Performance Testing)：检测协议实体或系统的性能指标（数据传输率、联接时间、执行速度、吞吐量和并发度等）；（4） 鲁棒性测试(Robustness Testing)：检测协议实体或系统在各种恶劣的情况下运行的能力（掉电、注入干扰报文和信道被切断等）。在以上四种测试中，协议一致性测试是最重要的测试，只有通过了协议一致性测试，才能证明协议的实现符合协议规范的要求，在此基础之上，其他的协议测试才能得以进行。针对协议一致性测试，ISO 组织专门制定了ISO 一致性测试方法及框架。协议一致性测试就是检验待测的实体的行为是否与相关的协议规范一致。在进行协议一致性测试的过程中，采用的是黑盒测试的方法，即测试人员不需要了解被测实体的内部实现原理，只需要按照测试用例，对被测是实体的激励的响应进行分析，比较其与规范的一致性程度。协议一致性测试的模型可以由图2-4表示。图2-4 协议一致性测试模型从协议测试的执行角度来看，协议一致性测试包括两个阶段：控制阶段和观察阶段。在控制阶段，测试系统向被测实例发送测试数据包，激发待测实体的功能。在观测阶段，测试系统对待测实体进行监控，对待测实体返回的数据包进行分析，与标准的协议规范相比较。在一致性测试的整个执行过程中，测试系统通过对向待测实体输入的测试数据与待测实体的测试响应进行统一的分析，得到本次测试的结论21。协议一致性测试分为三部分：必要要求测试、有条件要求测试和可选要求测试。其中，必要要求测试是对那些在所有情况下都需要达到的要求进行测试；有条件要求测试是对那些根据协议规范，在某些条件下才需要满足的要求进行测试；可选要求测试表示，对那些协议规范中规定，可以选择性实现的要求进行测试。2.1.2 系统功能测试功能测试（Functions Testing）是指对被测实体应当实现的具体的功能进行验证。根据被测实体实现的功能规范，指定功能测试用例，然后依照测试用例，对每一项功能进行测试验证，检测相应功能点是否达到规范要求23。从是否了解被测实体内部的实现机制的角度来说，功能测试分为以下3类：黑盒测试（Black box）、白盒测试（White box）和灰盒测试（Gray box）24。（1） 黑盒测试。黑盒测试，顾名思义，就是将被测实体看做一个黑盒子，测试者并不需要了解被测实体内部是如何实现的，只需要按照相应的功能需求规范，通过向被测实体的相应接口发送测试激励，校验被测实体的响应是否满足功能规范即可。（2） 白盒测试。白盒测试，是对被测实体的内部的细节内容进行测试验证。在进行白盒测试时，测试人员需要了解被测实体的内部实现逻辑，将被测实体看做一个打开的盒子，测试人员需要根据被测实体内部的结构关系，来选择设计测试用例。（3） 灰盒测试。灰盒测试是一种介于黑盒测试和白盒测试之间的测试。灰盒测试关注被测实体输入输出的正确性，同时也关注被测实体的内部实现。但是灰盒测试对于被测实体的内部实现逻辑的关注并没有白盒测试那么细致，与白盒测试相比的优点就是效率要高于白盒测试。从测试范围的大小来说，功能测试可以分为单元测试（Unit Testing）、集成测试（Integration Testing）和系统测试（System Testing）三部分。（1） 单元测试。单元测试是对被测实体中最基本组成单位进行测试。目的是验证被测实体最基本组成单位的正确性。单元测试是集成测试和系统测试的基础。（2） 集成测试。集成测试是指对被测实体中，多个基本单位进行联合测试。集成测试的目的是判断在被测实体中，多个基本单元之间是否能够协调工作没有冲突。（3） 系统测试。系统测试是对完整的、已经集成好的软件进行测试。目的是验证整个系统实现的功能是否与相关的功能规范相吻合。系统测试要依赖于单元测试和集成测试，只有在进行了单元测试和集成测试之后，进行系统测试才有意义。2.3 SDN测试研究现状随着SDN 技术的不断发展与成熟，SDN 市场正在快速增长。越来越多的厂商开始提供支持OpenFlow 协议的SDN 交换机以及参与到SDN 控制器和应用的开发中来。但是，SDN 仍然是一项发展中的技术，不同SDN 参与者对SDN 各种细节理解难免会出现偏差，SDN 测试正是发现校验这种偏差的最佳手段，所以，SDN 测试需求也越发明显。SDN 与传统网络相比，有很多不同，传统的网络中，网络的控制逻辑和相关的应用大多和转发设备集中在一起，但是在SDN 中，控制逻辑、网络应用与转发设备是相互分开的，并且通过特定的接口进行交互。所以在一些情况下，对SDN 的测试可能会打破传统IP 网络测试的相关规则。但是幸运的是，并不是所有的SDN 测试与传统的网络测试都有所不同，所以在进行SDN 测试的时候，传统的网络测试对SDN 测试也具有重要的指导意义。目前，对SDN 的测试主要包括协议一致性测试、互通性测试、功能测试和性能测试四部分。其中协议执行性测试是为了确保OpenFlow 交换机与SDN 控制器都遵循了OpenFlow 协议规范，是SDN 测试的基础；互通性测试是对不同的SDN 组成部分之间的是否可以协同工作进行测试；功能测试主要是对OpenFlow 转发设备相关功能的测试验证；性能测试则是对SDN 交换机和控制器对网络业务承载能力的测试4,5。（1） 协议一致性测试目前，对SDN 协议一致性的测试的研究主要是对OpenFlow 协议一致性测试的研究，即SDN 南向接口一致性测试。针对OpenFlow 协议的一致性测试，开放式网络基金会（Open Networking Foundation ，即ONF）专门成立了ONF 测试和互操作性工作组（ONF Testing and Interoperability Working Group）。并且于2013年6月和2015年4月分别发布了OpenFlow 测试规范Conformance Test Specification for OpenFlow Switch Specification 1.0.1（以下简称OpenFlow1.0测试规范）25与Conformance Test Specification for OpenFlow Switch Specification 1.3.4（以下简称OpenFlow1.3测试规范）26。在相应的测试规范中，对如何进行OpenFlow 协议进行一致性测试与测试用例进行了详尽的规定。比如，在OpenFlow1.0测试规范中， 将OpenFlow 1.0协议测试划分为10个测试部分：基本的完整性检查（Basic Sanity Checks）、基本的OpenFlow协议消息（Basic OpenFlow protocol）、生成树（Spanning Tree）、流修改消息（Flow modification messages）、流匹配（Flow Matching）、计数器（Counters）、行为（Actions）、消息（Messages）、异步消息（Async Messages）和错误消息（Error Messages）25。OpenFlow 协议一致性测试，主要是对SDN 控制器和转发设备的OpenFlow 协议一致性进行测试，其中包括必选和可选功能两部分。待测实体只有通过了所有的一致性测试用例，才算通过OpenFlow 一致性测试。（2） 互通性测试SDN 互通性测试主要是对不同的SDN 组成部分之间是否能够实现互联互通进行测试。目前，SDN 互通性测试，主要是对测试控制器与交换机之间互通性的测试。进行SDN 互通性测试主要有两点好处：首先，在进行互通性测试的时候，可以对被测实例对协议的理解情况与相关功能的实现情况进行校验，发现被测实例的问题，从而可以对有问题的被测实例进行优化；同时，进行互通性测试，也有助于发现协议本身存在的问题，在互通性测试过程中，暴露出来的协议的问题，有助于对协议的完善和改进。现阶段基本的SDN 互通性测试主要包括：流表测试、请求消息测试、流超时测试、控制器通道建立测试和流表测试等。（3） 功能测试功能测试主要是对SDN 转发设备的功能进行测试和验证。因为SDN 是一项不断发展中的技术，同时，针对一些不同的具体情况，有一些必要功能和可选功能，所以不同厂商对于SDN 相关功能的支持程度是不同的。此外，因为OpenFlow 协议中保留了一些扩展字段用于对其进行扩展，所以，不同厂商可能对原始的OpenFlow 协议进行扩展，实现更多的功能（比如扩展OpenFlow 协议，使其可以应用在光网络中）。所以对SDN 转发设备进行功能测试是十分重要的。鉴于SDN 的具体情况，功能测试是需要建立在协议测试的基础上的，尤其是协议一致性测试，只有相关设备满足了协议的一致性，才能对其进行功能测试。在进行功能测试的时候，测试系统模拟控制器，向被测交换机发送OpenFlow 协议报文，同时对交换机控制器端口和转发端口的报文信息进行分析，得出功能测试的结果。（4） 性能测试性能测试，主要是对SDN 控制器和SDN 转发设备进行性能测试。通过协议一致性测试、互通性测试和功能测试可以保证网络是否可用，但是网络可用并不一定代表网络好用，所以，为了评判网络是否好用，具体量化网络元素的性能指标，对SDN 各个组成部分进行性能测试，也是十分必要的。因为技术原因，目前对SDN 进行性能测试，主要是对单个SDN 设备进行单独的性能测试，并不能做到测试一个网络的性能。目前对SDN 性能的测试主要包括对控制器最大交换机连接数量测试、流表下发性能测试、转发设备流表容量性能测试等。不难看出，在协议测试方面，目前对 SDN 的协议测试研究，都集中在SDN 南向接口（OpenFlow）的测试，对SDN 北向接口测试的相关研究几乎没有。而SDN 北向接口不仅是SDN 网络架构的重要组成部分，而且也是支持应用层，距离用户最近的接口。所以，北向接口实现的正确与否，直接关系到SDN 的可用性。所以，对SDN 北向接口的测试研究，也具有重要意义。在功能测试方面，目前对SDN 设备进行的功能