SDN网络构架及发展历史
sdn的特点之一就是控制平面与数据平面分离，其主张通过集中式的控制器平台实现网络的控制。在sdn架构中，控制平面是逻辑集中的，通过某种协议将控制信息下发至底层的数据平面去执行。所以，控制平面被称为sdn的大脑，指挥整个数据网络的运行。
得益于集中控制的优势，控制平面的存在使得网络的部署和配置更加智能和简化。支持编程的sdn控制平面使得网络更加智能，更加灵活和易于拓展。控制器通过sdn的南向协议的api可以对数据层面的网元设备下发指令，完成控制平面与数据平面的控制传输。目前，在sdn领域中，openflow协议是最流行的南向协议之一。2008年，sdn和openflow一起诞生于斯坦福大学。
sdn出现初期，控制平面的表现形式更多的是以单实例的控制器出现。实现sdn的协议也是以openflow为主，所以在sdn发展初期，sdn控制器更多指的是openflow控制器。sdn出现之后，onf[1]成立。onf(open network foundation),中文名为“开放网络基金会” ，是致力于推进sdn标准化的一个用户驱动的组织。在onf的白皮书中，提出了sdn的架构标准，sdn架构1.0版本和1.1版本分别如图1和 图2所示。
图1 sdn网络架构1.0版本
图2 sdn网络架构1.1版本
第一款sdn控制器是nox，目前nox的社区状态已经不再活跃。在早期的sdn论文中，nox作为唯一的控制器，发挥了重要的作用。nox给后来的控制器开发提供了很好的范例，高层级的编程架构。然而，由于其使用c语言编写，给开发sdn应用带来了许多困难，逐渐在控制器竞争中失去优势。在nox出现不久之后，其兄弟版本pox面世。pox的内部机制和nox一样，但是采用python语言开发。在sdn发展初期，pox也扮演了相当重要的角色，许多sdn学习者都接触过pox。pox因其简单，易入门而得到广泛的关注和使用，成为sdn入门，学习sdn控制器的很好选择。然而，随着技术的发展，更多优秀的控制器，如2012年采用python语言开发的控制器代表ryu，2013年采用java语言开发的控制器代表floodlight等纷纷涌现。他们具有更加成熟的架构，更加优秀的性能，相比之下，pox不具有优势，慢慢在控制器的竞争中处于下风。目前pox的开源社区还是活跃状态，由murphy mccauley继续运营社区。
ryu是日本ntt公司开发的模块化的控制器。ryu因其架构清晰，支持openflow全部版本，有社区的plug-in集成到openstack，性能良好和文档齐全等优点获得了许多sdn研究者的关注。同样，在beacon上改进而来的floodlight，以其企业级别的优秀性能，开发效率更高的java语言，模块化的设计等优点得到了喜欢java语言的sdn研究者的青睐。此时的sdn控制器侧重于提升单例性能，支持的南向协议也是以openflow为主。笔者认为可以称之为openflow式sdn的控制器发展中期。然而这个时期非常短。
sdn经过几年的发展，成为趋势的势头逐渐浮出水面。sdn控制器的发展也因一个重要的sdn“控制器”而展开新的篇章。2013年，由linux foundation和多家网络巨头如cisco、juniper和broadcom等公司一起创立的开源项目opendaylight。其赞助商、发起者多为设备厂商而非运营商等消费者，其目的在于推出一个通用的sdn控制平台。opendaylight不仅仅是一个sdn控制器，它更是一个庞大的开源项目，其中包含许多子项目，而controller只是其中的一个子项目。opendaylight支持多种南向协议，包括openflow(支持1.0和1.3版本）、netconf和ovsdb等，是一个广义的sdn控制平台，而不是openflow系的狭义sdn控制器。
opendaylight的诞生意味着sdn进入一个崭新的时期。此时sdn的概念发生了改变。sdn控制器应支持多南向协议，而不仅仅局限于openflow，当然这给我们带来了很多想象空间，会被巨头引导走向不够开放的另一端吗？sdn控制器应该支持分布式集群，即单实例的控制器变成了分布式的控制平台。分布式的控制平台不仅可以管理更大的网络，性能更好，还可以相互容灾备份，提升系统的可靠性。在分布式系统盛行的今天，sdn控制器虽逻辑集中但也需要架构上分布。
opendaylight的社区的会员很多，早期的会员多为设备商。各个厂商均竭尽所能得把自己的思想，产品放到opendaylight项目中，如cisco的opflex。虽然多家厂商参与社区的维护和opendaylight的开发，但是大多数项目还是cisco在主导开发。在角力的过程中，有的企业就会有其他的打算，如big switch networks推出opendaylight, juniper将经历转向了自己的open contrial。 opencontrial是juniper的商业控制器contrial的开源版本，其使用c++语言编写，支持openflow协议和netconf等南向协议。不过相比之下也有跟进的企业，如hp，就增加了对opendaylight的投入，将自己升级到了铂金会员。huawei则兵分多路，一部分人开发opendaylight，另一部分人则参与了新生代的控制平台onos的开发，还有其他很大一部分人在进行华为敏捷智能网络控制器snc的开发。虽然opendaylight社区势力众多，各自想法也不一样，但是这并不影响opendaylight的性能和在sdn研究者心目中的地位，opendaylight依然凭借自己社区强大的技术，在sdn控制器的竞争中成为最具有影响力的控制器之一。许多企业在自己的产品中或者网络中使用到了opendaylight, 比如brocade一直推基于opendaylight的商业控制器vyatta。腾讯也在最新的技术分享中提到使用了opendaylight管理自己的数据中心网络。
从2013年底到2014年底这段时间内，opendaylight可谓风光无限，提到sdn几乎都会提到opendaylight，仿佛opendaylight就是sdn控制器的最终形态和最终归属。这一局面，在2014年12月5日被打破了。由on.lab开发的onos面世了。onos(open network operating system)是一款同样采用java语言编写，采用osgi架构，同样分布式的控制平台产品。其目标是打造一个开放的sdn网络操作系统，市场定位在运行商级别网络市场。onos底层模块直接借用floodlight优秀的模块如switch模块，不使用yang语言建模，最新版本使用raft作为分布式框架。突然之间，opendaylight遇到了竞争对手。虽然截至2015年之前，并没有使用onos的案例，但是在未来，凭借自身的优秀性能，onos可以取得一部分市场。
sdn开源控制器除了这些比较出名的之外，也有其他用户比较少的控制器，如trame,flower, loom等。笔者参考sdxcentral最新的sdn控制器的数据，将目前sdn开源控制器是否活跃情况列举如下表，先后顺序无关。
然而目前最神秘，最出名的控制应该不是以上提到的任何一个控制器，而是google的分布式控制器onix，onix目前没有开源，相关资料非常少。目前由nicira、ntt和google共同开发。2013年，google在sigcomm上发表了论文《b4: experience with a globally-deployed software defined wan》[3]，论文介绍了google的wan加速sdn方案，其中使用的控制器就是onix。论文发布时，b4已经运行了3年，除了发生过datapath_id相同导致的错误以外，基本正常运行。该方案将带宽利用率提升到了接近100%的恐怖利用率。也即2010年google已经开发出了整套方案，然后上线运行，很明显，google和整个技术发展不在一个时期，这个案例也是sdn支持者心中的最有力的论据。
除了onix之外，还有许多闭源的商业控制器，如hp的van(virtual applications networks)控制器，武汉绿网的gnflush等，更多商业控制器的内容可参考sdxcentral的sdn-controller-report 2015b[4]。
影响sdn控制器发展的因素除了技术因素以外，还有重要的非技术因素，如行业企业对技术的态度等。企业在制定sdn战略时都是从自身的利益出发的，这些战略很大程度上影响着sdn的发展。在一项技术的发展过程中，行业巨头等企业的战略等非技术因素会对技术的发展曲线，发展方向产生非常大的影响。
自sdn发展以来，业界声音不一。支持者声称这将改变传统网络，打破目前固化的网络架构，带来更灵活，更智能的网络；而反对者则认为这并没有良好的发展前途，因为分布式的优点足以支撑目前的网络运行，而sdn所提倡的集中式虽有优点，但劣势多于优势。这些声音代表了不同利益阵营，所以处于不同利益阵营的企业对sdn的态度也不一而足。如传统巨头cisco，态度就很微妙。对于cisco而言，如果不支持sdn，那么万一sdn真成为下一个潮流，那么市场损失过大，影响行业地位。如果完全支持，那么在sdn这个崭新的战场，市场重新布局，门槛降低，更多竞争者进入，且追赶者huawei等企业也会趁机大力发展sdn，最终sdn格局还无法明朗。所以cisco一方面投入研发精力研究sdn，另一方面，剑走偏锋，推出自己的aci（application centric infrustructure），企图另辟蹊径占领sdn市场。aci也是一种广义上的sdn。其控制器为apic( application policy infrastructure controller)，但他区别于我们所理解的之前提到的控制器，他并不负责指挥数据层面如何转发流量，所以在aci中，底层设备nexus9000才是重点，而非控制器。其使用的南向协议也避开了openflow，而使用了私有协议opflex。如此一来，成功避开了sdn白牌交换机的冲击，成功将战场引到了拥有技术壁垒的数据层面产品上。
对于传统网络行业巨头而言，目前稳定市场布局对自己有利，自然不希望新技术打破这一平衡，所以他们对于sdn的态度往往是不够积极。但是为了防止新技术的冲击，他们一定会跟进，也一定会想办法推出兼容产品或者竞争产品，力图在新技术市场上占据有利地位。除了投入研发精力跟进外，还会对有希望的创业公司进行技术收购。若创业公司成长壮大，那么收购是成功的，如果创业公司失败，那也没有太大关系，这笔投资对于巨头而言并不是大事。技术收购的策略在技术发展过程经常被使用，所以近些年关于sdn创业公司被收购的新闻屡见不鲜，相信在sdn发展的道路上，技术收购还会继续发生。
对于第二阵营或者新技术公司而言，必然大力支持sdn的发展。如huawei大力投入研发精力研发sdn相关产品。不仅在开源项目方面参与opendaylight项目，还参与onos项目，一方面，跟进opendaylight项目不落后，另一方面，企图通过onos项目来争取更多的市场。此外，huawei也大力发展snc控制器等sdn产品。和huawei类似的，hp也在投入精力发展sdn，不仅推出了自己的sdn控制器产品，也推出了sdn交换机等数据平面产品。新技术公司方面，国内的盛科，国外的pica8等交换机厂家已经抓住sdn发展的机会，推出了许多数据平面产品，占据了一定的sdn市场。配套的数据平面产品的推出必将推动sdn控制平面的发展及落地。
sdn的发展也给更多的其他领域的竞争者入足的机会，虚拟化产品巨头vmware就是一个很好的例子。瞄准sdn的市场之后，vmware收购了创业公司nicira，在其network virtualization platform (nvp) 的基础之上，结合自己的vcloud networking and security (vcns) 推出了nsx，从而占据了数据中心网络虚拟化的一部分市场，加入了sdn市场的竞争。新的sdn产品的推出，也给业界推动sdn发展的信心，从而促进sdn控制平面的发展。
笔者认为，随着技术的发展，网络规模的扩大，sdn控制器将出现分级分域的概念，多控制器之间将出现协同工作的功能。即管理不同网络的控制器运行对应的应用，而不同控制器之间通过东西向接口进行信息同步，从而完成全网的管理。目前在opendaylight中实现的sdni协议即是一种sdn东西向协议的实现方法。未来的sdn控制平面应该是局域集群，全局分级的架构。此外，未来的sdn控制平台会成为网络操作系统形式的存在，目前onos就是网络操作系统的示范。除此之外，sdn控制平台将和openstack等云管理平台整合运作，这也是当下控制器的一个趋势之一。虽然开发者可以在sdn控制平面上开发部署很多应用，但是未来的sdn控制器将面对特定的网络运行特定的应用，而不会运行全部的应用，甚至于根据不同场景，出现不同的版本的控制平台。
sdn控制器的竞争最终会优胜劣汰，剩下几款经典的控制器分别占领不同的市场，正如当下的计算机操作系统一般。即不会有任何一款控制器垄断整个市场，不同的控制器将会相互竞争相互促进。此外，短期之内openflow不会失去竞争力，但最终同样会存在多种南向协议相互竞争，竞争是常态，是技术发展的源泉。
小米6确定发布时间：4月16首发骁龙835！
同步降压型DC/DC控制器LTC3878/79的性能特点及应用范围
无现金社会还有多远？这把双刃剑还有很长的路要走
光伏探测器的光电特性和哪些因素有关
压电式加速度传感器的安装
SDN网络构架及发展历史
正确的布局和元件选择是控制EMI的关键
1200亿产业扶持基金有望成立 半导体业迎爆发年
魅族Pro7什么时候上市？杨柘亲自辟谣：魅族Pro7后置副屏是假的？但联发科是妥妥的，价格也十分惊人
两个PCBA零件封装技术的详细资料解析
L3/L4自动驾驶落地在即，禾赛科技等头部厂商将受益
研究：运营商支持的RCS将赢得消费者的青睐和品牌预算
网格化微型空气监测站的适用范围及功能特点
全球无人机市场快速发展 中国市场将迎来发展机遇
R5930 G2服务器安装CGSL操作系统后无法识别板载网卡的故障处理方法
浅谈阻抗匹配（四）—传输线的具体拓扑结构
ASML：仍可向中国销售DUV***！
工业人工智能影响工业？
压延铜与电解铜工艺介绍
如何通过GTM Digital monitor读RX Equalizer
得益于集中控制的优势，控制平面的存在使得网络的部署和配置更加智能和简化。支持编程的sdn控制平面使得网络更加智能，更加灵活和易于拓展。控制器通过sdn的南向协议的api可以对数据层面的网元设备下发指令，完成控制平面与数据平面的控制传输。目前，在sdn领域中，openflow协议是最流行的南向协议之一。2008年，sdn和openflow一起诞生于斯坦福大学。
sdn出现初期，控制平面的表现形式更多的是以单实例的控制器出现。实现sdn的协议也是以openflow为主，所以在sdn发展初期，sdn控制器更多指的是openflow控制器。sdn出现之后，onf[1]成立。onf(open network foundation),中文名为“开放网络基金会” ，是致力于推进sdn标准化的一个用户驱动的组织。在onf的白皮书中，提出了sdn的架构标准，sdn架构1.0版本和1.1版本分别如图1和 图2所示。
图1 sdn网络架构1.0版本
图2 sdn网络架构1.1版本
第一款sdn控制器是nox，目前nox的社区状态已经不再活跃。在早期的sdn论文中，nox作为唯一的控制器，发挥了重要的作用。nox给后来的控制器开发提供了很好的范例，高层级的编程架构。然而，由于其使用c语言编写，给开发sdn应用带来了许多困难，逐渐在控制器竞争中失去优势。在nox出现不久之后，其兄弟版本pox面世。pox的内部机制和nox一样，但是采用python语言开发。在sdn发展初期，pox也扮演了相当重要的角色，许多sdn学习者都接触过pox。pox因其简单，易入门而得到广泛的关注和使用，成为sdn入门，学习sdn控制器的很好选择。然而，随着技术的发展，更多优秀的控制器，如2012年采用python语言开发的控制器代表ryu，2013年采用java语言开发的控制器代表floodlight等纷纷涌现。他们具有更加成熟的架构，更加优秀的性能，相比之下，pox不具有优势，慢慢在控制器的竞争中处于下风。目前pox的开源社区还是活跃状态，由murphy mccauley继续运营社区。
ryu是日本ntt公司开发的模块化的控制器。ryu因其架构清晰，支持openflow全部版本，有社区的plug-in集成到openstack，性能良好和文档齐全等优点获得了许多sdn研究者的关注。同样，在beacon上改进而来的floodlight，以其企业级别的优秀性能，开发效率更高的java语言，模块化的设计等优点得到了喜欢java语言的sdn研究者的青睐。此时的sdn控制器侧重于提升单例性能，支持的南向协议也是以openflow为主。笔者认为可以称之为openflow式sdn的控制器发展中期。然而这个时期非常短。
sdn经过几年的发展，成为趋势的势头逐渐浮出水面。sdn控制器的发展也因一个重要的sdn“控制器”而展开新的篇章。2013年，由linux foundation和多家网络巨头如cisco、juniper和broadcom等公司一起创立的开源项目opendaylight。其赞助商、发起者多为设备厂商而非运营商等消费者，其目的在于推出一个通用的sdn控制平台。opendaylight不仅仅是一个sdn控制器，它更是一个庞大的开源项目，其中包含许多子项目，而controller只是其中的一个子项目。opendaylight支持多种南向协议，包括openflow(支持1.0和1.3版本）、netconf和ovsdb等，是一个广义的sdn控制平台，而不是openflow系的狭义sdn控制器。
opendaylight的诞生意味着sdn进入一个崭新的时期。此时sdn的概念发生了改变。sdn控制器应支持多南向协议，而不仅仅局限于openflow，当然这给我们带来了很多想象空间，会被巨头引导走向不够开放的另一端吗？sdn控制器应该支持分布式集群，即单实例的控制器变成了分布式的控制平台。分布式的控制平台不仅可以管理更大的网络，性能更好，还可以相互容灾备份，提升系统的可靠性。在分布式系统盛行的今天，sdn控制器虽逻辑集中但也需要架构上分布。
opendaylight的社区的会员很多，早期的会员多为设备商。各个厂商均竭尽所能得把自己的思想，产品放到opendaylight项目中，如cisco的opflex。虽然多家厂商参与社区的维护和opendaylight的开发，但是大多数项目还是cisco在主导开发。在角力的过程中，有的企业就会有其他的打算，如big switch networks推出opendaylight, juniper将经历转向了自己的open contrial。 opencontrial是juniper的商业控制器contrial的开源版本，其使用c++语言编写，支持openflow协议和netconf等南向协议。不过相比之下也有跟进的企业，如hp，就增加了对opendaylight的投入，将自己升级到了铂金会员。huawei则兵分多路，一部分人开发opendaylight，另一部分人则参与了新生代的控制平台onos的开发，还有其他很大一部分人在进行华为敏捷智能网络控制器snc的开发。虽然opendaylight社区势力众多，各自想法也不一样，但是这并不影响opendaylight的性能和在sdn研究者心目中的地位，opendaylight依然凭借自己社区强大的技术，在sdn控制器的竞争中成为最具有影响力的控制器之一。许多企业在自己的产品中或者网络中使用到了opendaylight, 比如brocade一直推基于opendaylight的商业控制器vyatta。腾讯也在最新的技术分享中提到使用了opendaylight管理自己的数据中心网络。
从2013年底到2014年底这段时间内，opendaylight可谓风光无限，提到sdn几乎都会提到opendaylight，仿佛opendaylight就是sdn控制器的最终形态和最终归属。这一局面，在2014年12月5日被打破了。由on.lab开发的onos面世了。onos(open network operating system)是一款同样采用java语言编写，采用osgi架构，同样分布式的控制平台产品。其目标是打造一个开放的sdn网络操作系统，市场定位在运行商级别网络市场。onos底层模块直接借用floodlight优秀的模块如switch模块，不使用yang语言建模，最新版本使用raft作为分布式框架。突然之间，opendaylight遇到了竞争对手。虽然截至2015年之前，并没有使用onos的案例，但是在未来，凭借自身的优秀性能，onos可以取得一部分市场。
sdn开源控制器除了这些比较出名的之外，也有其他用户比较少的控制器，如trame,flower, loom等。笔者参考sdxcentral最新的sdn控制器的数据，将目前sdn开源控制器是否活跃情况列举如下表，先后顺序无关。
然而目前最神秘，最出名的控制应该不是以上提到的任何一个控制器，而是google的分布式控制器onix，onix目前没有开源，相关资料非常少。目前由nicira、ntt和google共同开发。2013年，google在sigcomm上发表了论文《b4: experience with a globally-deployed software defined wan》[3]，论文介绍了google的wan加速sdn方案，其中使用的控制器就是onix。论文发布时，b4已经运行了3年，除了发生过datapath_id相同导致的错误以外，基本正常运行。该方案将带宽利用率提升到了接近100%的恐怖利用率。也即2010年google已经开发出了整套方案，然后上线运行，很明显，google和整个技术发展不在一个时期，这个案例也是sdn支持者心中的最有力的论据。
除了onix之外，还有许多闭源的商业控制器，如hp的van(virtual applications networks)控制器，武汉绿网的gnflush等，更多商业控制器的内容可参考sdxcentral的sdn-controller-report 2015b[4]。
影响sdn控制器发展的因素除了技术因素以外，还有重要的非技术因素，如行业企业对技术的态度等。企业在制定sdn战略时都是从自身的利益出发的，这些战略很大程度上影响着sdn的发展。在一项技术的发展过程中，行业巨头等企业的战略等非技术因素会对技术的发展曲线，发展方向产生非常大的影响。
自sdn发展以来，业界声音不一。支持者声称这将改变传统网络，打破目前固化的网络架构，带来更灵活，更智能的网络；而反对者则认为这并没有良好的发展前途，因为分布式的优点足以支撑目前的网络运行，而sdn所提倡的集中式虽有优点，但劣势多于优势。这些声音代表了不同利益阵营，所以处于不同利益阵营的企业对sdn的态度也不一而足。如传统巨头cisco，态度就很微妙。对于cisco而言，如果不支持sdn，那么万一sdn真成为下一个潮流，那么市场损失过大，影响行业地位。如果完全支持，那么在sdn这个崭新的战场，市场重新布局，门槛降低，更多竞争者进入，且追赶者huawei等企业也会趁机大力发展sdn，最终sdn格局还无法明朗。所以cisco一方面投入研发精力研究sdn，另一方面，剑走偏锋，推出自己的aci（application centric infrustructure），企图另辟蹊径占领sdn市场。aci也是一种广义上的sdn。其控制器为apic( application policy infrastructure controller)，但他区别于我们所理解的之前提到的控制器，他并不负责指挥数据层面如何转发流量，所以在aci中，底层设备nexus9000才是重点，而非控制器。其使用的南向协议也避开了openflow，而使用了私有协议opflex。如此一来，成功避开了sdn白牌交换机的冲击，成功将战场引到了拥有技术壁垒的数据层面产品上。
对于传统网络行业巨头而言，目前稳定市场布局对自己有利，自然不希望新技术打破这一平衡，所以他们对于sdn的态度往往是不够积极。但是为了防止新技术的冲击，他们一定会跟进，也一定会想办法推出兼容产品或者竞争产品，力图在新技术市场上占据有利地位。除了投入研发精力跟进外，还会对有希望的创业公司进行技术收购。若创业公司成长壮大，那么收购是成功的，如果创业公司失败，那也没有太大关系，这笔投资对于巨头而言并不是大事。技术收购的策略在技术发展过程经常被使用，所以近些年关于sdn创业公司被收购的新闻屡见不鲜，相信在sdn发展的道路上，技术收购还会继续发生。
对于第二阵营或者新技术公司而言，必然大力支持sdn的发展。如huawei大力投入研发精力研发sdn相关产品。不仅在开源项目方面参与opendaylight项目，还参与onos项目，一方面，跟进opendaylight项目不落后，另一方面，企图通过onos项目来争取更多的市场。此外，huawei也大力发展snc控制器等sdn产品。和huawei类似的，hp也在投入精力发展sdn，不仅推出了自己的sdn控制器产品，也推出了sdn交换机等数据平面产品。新技术公司方面，国内的盛科，国外的pica8等交换机厂家已经抓住sdn发展的机会，推出了许多数据平面产品，占据了一定的sdn市场。配套的数据平面产品的推出必将推动sdn控制平面的发展及落地。
sdn的发展也给更多的其他领域的竞争者入足的机会，虚拟化产品巨头vmware就是一个很好的例子。瞄准sdn的市场之后，vmware收购了创业公司nicira，在其network virtualization platform (nvp) 的基础之上，结合自己的vcloud networking and security (vcns) 推出了nsx，从而占据了数据中心网络虚拟化的一部分市场，加入了sdn市场的竞争。新的sdn产品的推出，也给业界推动sdn发展的信心，从而促进sdn控制平面的发展。
笔者认为，随着技术的发展，网络规模的扩大，sdn控制器将出现分级分域的概念，多控制器之间将出现协同工作的功能。即管理不同网络的控制器运行对应的应用，而不同控制器之间通过东西向接口进行信息同步，从而完成全网的管理。目前在opendaylight中实现的sdni协议即是一种sdn东西向协议的实现方法。未来的sdn控制平面应该是局域集群，全局分级的架构。此外，未来的sdn控制平台会成为网络操作系统形式的存在，目前onos就是网络操作系统的示范。除此之外，sdn控制平台将和openstack等云管理平台整合运作，这也是当下控制器的一个趋势之一。虽然开发者可以在sdn控制平面上开发部署很多应用，但是未来的sdn控制器将面对特定的网络运行特定的应用，而不会运行全部的应用，甚至于根据不同场景，出现不同的版本的控制平台。
sdn控制器的竞争最终会优胜劣汰，剩下几款经典的控制器分别占领不同的市场，正如当下的计算机操作系统一般。即不会有任何一款控制器垄断整个市场，不同的控制器将会相互竞争相互促进。此外，短期之内openflow不会失去竞争力，但最终同样会存在多种南向协议相互竞争，竞争是常态，是技术发展的源泉。
小米6确定发布时间：4月16首发骁龙835！
同步降压型DC/DC控制器LTC3878/79的性能特点及应用范围
无现金社会还有多远？这把双刃剑还有很长的路要走
光伏探测器的光电特性和哪些因素有关
压电式加速度传感器的安装
SDN网络构架及发展历史
正确的布局和元件选择是控制EMI的关键
1200亿产业扶持基金有望成立 半导体业迎爆发年
魅族Pro7什么时候上市？杨柘亲自辟谣：魅族Pro7后置副屏是假的？但联发科是妥妥的，价格也十分惊人
两个PCBA零件封装技术的详细资料解析
L3/L4自动驾驶落地在即，禾赛科技等头部厂商将受益
研究：运营商支持的RCS将赢得消费者的青睐和品牌预算
网格化微型空气监测站的适用范围及功能特点
全球无人机市场快速发展 中国市场将迎来发展机遇
R5930 G2服务器安装CGSL操作系统后无法识别板载网卡的故障处理方法
浅谈阻抗匹配（四）—传输线的具体拓扑结构
ASML：仍可向中国销售DUV***！
工业人工智能影响工业？
压延铜与电解铜工艺介绍
如何通过GTM Digital monitor读RX Equalizer