编者按：本文系SDN实战团技术分享系列，我们希望通过SDNLAB提供的平台传播知识，传递价值，欢迎加入我们的行列。
嘉宾简介：
--------------------------------------------------------------------------------------------------
邢森：Java、Python码农，运营“写程序的康德”自媒体。现就职于上海电信信息网络部任职架构师，参与上海电信CORD项目建设（外部名称LSN），主要负责网络相关产品的研发工作。
--------------------------------------------------------------------------------------------------
大家好，我叫邢森目前上海电信信息网络部担任架构师，主要负责一些网络产品的研发工作。这次想和大家一起分享我在SDN学习路上的一些体会和心得。
首先介绍一下自己的来路，我是一个纯粹的开发出身，比较熟悉的开发语言是Java和Python。之前的工作也基本上都是和开发相关，对于云计算仅仅懂得“调用调用API”。
和很多初入云计算和SDN的人一样，随着工作和“云计算”的关系越来越深入，特别是自己加入到电信之后发现对“网络”的要求越来越高。没有任何传统网络基础的我是一脸懵逼，凭借着大学时候学过《计算机网络》的一点基础知识通过很长时间的摸爬滚打有那么一点“感悟”。现在把自己的“感悟”分享出来，希望能对“在路上”的朋友有点帮助。
我先分享一下自己对SDN和做SDN开发技能栈的理解。
1.SDN的本质是可编程，传统网络设备也会提供编程能力——比如SNMP、REST API，但是这种编程能力的粒度比较粗，API本质上是对配置命令的一种封装所以是一种北向接口。而SDN描绘的编程能力粒度更加细，不但定义了北向接口也定义了面向数据平面的南向接口。
2.细粒度的可编程就引出了“控制、转发分离”，这种分离不是指物理意义上的分离而是逻辑的分离，明确定义控制平面和数据平面之间的“API”。
基于以上的两点分析我认为一个合格的SDN工程师有四大部分“基础”知识是必须要掌握的：
- 传统网络知识
- 软件开发知识
- 数据平面开发
- Linux相关知识
我绘制了一张图细化这部分内容：
“网络基础”、“软件开发”是两大SDN研发的基础，我觉得SDN研发一言蔽之就是“用代码重新实现各种网络系统”，所以开发能力和网络基础是这一切的基础。
下面为大家详细分析图中的每个部分，说明我把这部分内容列上的原因。
传统网络知识
时代的发展总是蕴含着泡沫，云计算和SDN的如火如荼让很多开发者“被迫”（或者“主动”）成为了 “SDN研发工程师”，其中有不少人甚至搞不清“广播域”、“冲突域”；分不清“NAT”、“路由”也能大刀阔斧的抡的有模有样。就像演员比拼到最后是比拼文化，所有的工程师比拼到最后比拼的是基础——对于SDN研发来说就是网络基本功和开发能力。所以我再怎么强调“传统网络知识”的重要性都不过分，毕竟这份底蕴是真正价值的体现，即便有一天SDN研发不做开发了也能去做网络工程师囧。
这部分的学习我的建议是——按照一个正统的网络工程师要求自己，我明确划分出了“路由”、“交换”两条主干。
交换技术主要学习以太网，VLAN原理，STP。学习的重点是弄清楚网络交换的基本原理，数据转发过程，以太网、802.1Q的数据包格式，STP算法。路由技术基本上是搞清楚路由的原理，转发过程；各种路由协议算法和数据包格式。
既然是按照正统网络工程师要求自己那么就有大量的资料可供我们选择，比如我个人比较喜欢的Cisco的CCNA、CCNP教材，H3C出版的《路由交换技术》。需要特别注意的是学习的过程不但要要求自己“配置一把”还要搞清楚概念和算法，其中的一些算法我们一定要搞清楚它们的原理，这不但有利于我们对网络系统的理解同时还能帮助我们更好的做开发，乃至于触类旁通。（比如搞清楚了这些我们对LVS、keepalived的理解更加深刻）
软件开发
就像强调“网络基础知识”一样，再怎么强调软件开发能力也不过分。SDN研发本质上就是游走在“网络”、“软件”之间的“交叉学科”，缺少任何一方面在基础修炼都无法成为一个合格的SDN研发。
我把这部分内容划分为——编码能力（某种语言）、工程能力、架构能力。任何SDN系统的表现形式都是软件（其实硬件的表现形式也是软件，代码），所以编码能力是第一位的。编码能力是指熟悉某个编程语言以及相关的编程技术，特别是线程、网络（Socket API）相关；熟悉该编程语言涉及到的相关工具（编译、打包工具，版本控制工具、IDE、调试工具）。现代的软件系统通常都是一个复杂的软件系统，开发这种复杂就需要一定的工程能力，基本的开发素养是非常重要的，这包括数据结构算法、操作系统原理、计算机体系结构等。
我特意在这部分里面加入了“系统架构”，尤其是SDN相关的系统基本上都是分布式系统，所以几乎都涉及到很多分布式系统的基本架构理论和架构范式。比如Neutron各个组件之间的通讯协议，各个组件的逻辑关系。理解这些内容必须有一定的架构能力。
这部分书籍不太好推荐，没有标准教材可以参考，只能给出一些基础性的《深入理解计算机系统》、《代码大全》、《分布式系统概念与设计》
TCP/IP协议
每一个SDN研发工程师都是“双重人格”，一面是网络工程师；一面是软件工程师，TCP/IP协议则是双重人格中重合的部分。无论是出于网络工程师的要求——DEBUG配置还是出于软件工程师的要求——对系统底层了解更深入，TCP/IP协议都是非常重要的。
TCP/IP是我们最熟悉的也是最不了解的，我们每天都在用它但是很少有人能讲清楚IP协议分片、MTU和VxLAN数据包大小之间是有很密切的联系的；为什么有了TCP重传OVSDB还设计出心跳？熟悉TCP/IP协议不但有助于我们Debug各种问题而且能够让我们洞悉到更多设计背后的原因和无奈。通过这种协议分析的训练让我们回过头去再看曾经学习过的网络中涉及到的交换、路由算法数据包就会理解的更加透彻，要知道无论是GRE、VxLAN还是EVPN其实都是在传统协议上做的变种。
这部分推荐《TCP/IP协议详解卷一》，注意我只推荐卷一，因为我认为TCP/IP协议学习的第一步应该是熟悉协议设计的原因而不是一上来就干代码。《精通Linux内核网络》这本书是介于大量代码分析和纯粹理论之间的一本书。
Linux工具栈
我始终认为Linux是一个大宝库，无论是它的内核的架构、解决问题的思路还是它上面提供的丰富的网络工具都非常值得我们学习。
Tcpdump是帮助我们学习TCP/IP协议的最好助手也是帮助我们Debug的绝对利器，对于它的掌握是毋庸置疑的。
Iproute2旨在代替net-tools，ip系列的命令就包含在这个下面。Neutron对它的依赖程度简直是深入骨髓。
Linux的namespace是容器技术的基础，我们可以单独使用其中的某个namespace，比如network namespace。Neutron会针对每个Router或者DHCP启动一个独立的Python进程，这些进程的隔离就是直接通过namespace实现的。
Linux虚拟网络设备也是是Linux创建本地虚拟网络的基础，它提供的Bridge、TAP、VETH几乎成为了标配，无论Neutron、OVS、Docker五花八门的SDN、甚至直接用KVM都会用到这些东西。
这部分内容都是“工具”性质的知识，更多强调实际操作所以没有成体系的书籍可以参考，大家去读一些网文。
设备研发能力
有了TCP/IP协议保驾护航和对Linux工具栈也就有了一个传统网络设备研发工程师的基本素质。传统的网络设备开发基础在SDN系统中是非常重要的，比如大家都在说DPDK都知道它能提高性能，但是我们不能把它当做大力丸——吃了就能超神。如果不知道libpcap、不知道libpcap的性能限制，不知道Linux网卡工作原理、DMA、ZeroCopy这些名称，我们很难理解DPDPK的价值和意义。DPDPK就是为了解决这些问题的，它本质上是Linux数据平面的优化库，如果没有搞清楚这一点就好比没有搞清楚问题直接就看解决方案——必然一脸懵逼。
我的一个学习方式是从libpcap开始的，用它实现了tcpdump类似的功能，顺藤摸瓜去分析理解Linux网卡的工作机制和libpcap的性能瓶颈、pf_ring、netmap、dpdk做出的改进和努力。网卡作为一个Linux设备它或多或少都和I/O系统直接打交道，所以我认为理解Linux I/O架构对于理解网卡的工作原理是很有必要的。
这部分的书比较杂《深入Linux内核架构》、《Linux内核探秘 深入解析文件系统和设备驱动架构与设计》、《精通Linux内核网络》（之前推荐过）
OpenFlow
可能大家已经感觉到了，我上面罗列的所有东西都是和SDN“无关”的“老技术”。我个人认为SDN本身就没有什么新技术，它就是一场“多学科”交叉的运动而已。如果非要SDN的新技术那么只能是下面这位——OpenFlow。
OpenFlow有两层含义，1. 控制平面下发转发规则到数据平面的通讯协议；2.转发规则本身。就现实意义而言OpenFlow更多情况是指转发规则本身；通讯协议一般是OVSDB。
OpenvSwitch（OVS）是一款兼容OpenFlow规则的、软件实现的虚拟交换机。毫不过分的说，如果没有OVS那么无论是OpenStack还是各种SDN Controller都完全没法用了。SDN是把控制平面和数据平面做分离，OVS承担了分离后的数据平面角色，而Neutron和SDN Controller只是定义了一层网络模型，通过OVSDB协议下发OpenFlow表到OVS。
基于OVS我们可以做很多研究，一种方法是向上和Neutron、SDN Controller做的工作一样定义出一些网络模型，通过流表去实现这些模型。比如：VTN、OVN、Neutron的L2、L3都是做这种工作。一种方法是向下优化OVS的性能，通过增强Linux的数据平面采集性能从而提高OVS的处理能力，比如通过DPDK对OVS进行优化。
我个人觉得这部分学是所有SDN必须学的基础课程，也是最被忽略的内容。相关的书籍推荐比较难推荐，大家都喜欢写一些大而全或者只讲概念的数据这里只能推荐一本《图解OpenFlow》（我个人其实不太喜欢这本书）
新技术
我觉得有了OVS和OpenFlow之后剩下的工作就是定义一些网络抽象模型然后实现这些模型的下发、通过HTTP提供北向接口。图谱中我列出了四种技术，它们都是完成这种工作的，无论它们怎么宣称自己本质上他们都是“控制平面”——后面我统一称为SDN Controller。
首先表达一下我的个人喜欢，我理想中的SDN Controller要符合1. 独立可以单独部署的；2. 简单，提供简单的模型，可以方便开发和调试。非常遗憾的是很少有系统能满足我的个人偏好。
作为一个开发者我认为OSGI给开发带来的只有痛苦和不便于调试，不客气的说它就是一个变种的EJB，万恶之源。所以基于OSGI的ODL、ONOS仅仅是一种政治正确对开发者没有任何帮助，反而是各种掣肘。OpenStack的Neutron就更过分了，它是属于OpenStack的一部分不可能单独部署和使用。所以只剩下一种选择OVN，它是直接基于OVS实现的轻量级的SDN Controller，如果你读它的代码会发现非常简单，几乎就是在下发流表仅此而已。
从学习的角度考虑所有的SDN Controller的作用都是一样的，这一点一定要铭记于心。它们的区别就是实现机制的区别，对模型定义的区别，我们学习它们其实就是学习它们的“区别”。
ODL、ONOS本身就没有定义模型，它只是提供给我们一个运行时（容器），所以我们要学习如何开发自己的模型嵌入进去，它内置的一些模型和各种特性反而是其次的。Neutron和OVN就是一个模型，它就是在按照定义的模型下发流表，所以我们的学习重点是分析它的流表pipeline。
这里推荐的资料是官方的一些参考文档，特别注意的是如果不熟悉OVS、OpenFlow那么就谈不上学SDN Controller，乃至于谈不上学SDN。
最后做一个总结，我觉得现在对SDN研发工程师的培养缺少一种体系，毕竟这是一个“交叉”型的研发素质要求。从这点来说成为一名合格的SDN研发工程师要走的路很长，希望大家都不要被各种酷炫名称所迷惑，不要被各种重概念轻实践的资料所迷惑，认认真真做好基础。
Q&A
Q：网络工程师转sdn，linux方面不是很好，可以说是新手，在搭建实验平台和在linux下编码有一定难度，有什么好的书籍和论坛推荐下的吗？
A：实验平台最好的是mininet，编程环境我觉得不一定要Linux。ovs学习方面咱们sdnlab有相关课程我觉得接地气；编程相关的参考资料很多，我建议按照一个标准的程序员要求自己。基础的，编码的，架构的都要学都要看。学习是个过程，不要心急，钢铁冰与火的淬炼。
Q：我是个学生，之前不想学编程才选择了学网络，现在刚接触sdn发现要有编程基础，我想请问一下现在要针对sdn学编程的话学哪种语言比较好？在学习的过程中要学的像专门学编程的那么细吗？
A：我个人建议学习Python，两种原因1. Python的语法比较灵活，简洁；2. Java的Oracle JVM运行在专用硬件上是收费的，这注定会打击ODL、ONOS之类的市场。学习的过程中需要建议关注：多线程、Socket，要熟悉各种库。最后要强调的是一定要按一个软件工程师的标准要求自己。
Q：传统网工可以做哪些方面的SDN工作？不会linix和py，只会配命令
A：传统网络工程师如果不做研发那么可以深耕自己的领域，TCP/IP协议，各种路由协议、数据包格式，各种网络涉及到的算法，SDN涉及到的VxLAN、GRE之类协议都值得研究和深耕。另外推荐一本相关的书籍《云计算网络珠玑》，我个人觉得这是一本写给传统网工（乃至研发）的很好的书，短小精干。可惜只有第一版。
Q：libpcap的性能限制体现在什么地方？
A：libpcap的的底层是基于BPF，它直接使用的Linux的网卡驱动。网卡的工作模式和现代CPU、内存的机制都不适合大量的数据抓取。具体可以参考netmap、pf_ring、dpdk的设计目标。
Q：是学习java好还是学习JavaScript 好呢
A：这个话题会引发世界大战的，我觉得学习PHP好。呵呵。如果做SDN的话我建议选择Python，语法简单，库丰富。
Q：对OSGI的吐槽能否展开讲多几句？
A：我个人觉得OSGI的开发非常麻烦，它提供的是一个容器，我程序需要debug、运行都必须在它里面运行。理想的情况是一个程序直接就DEBUG了而不是必须依赖容器。
Q：请问OSGI对于开发的痛苦，具体是指？
A：我个人觉得OSGI的开发非常麻烦，它提供的是一个容器，我程序需要debug、运行都必须在它里面运行。理想的情况是一个程序直接就DEBUG了而不是必须依赖容器。
Q：老师您好，我是研一小白，本科学通信的，现在导师搞SDN这个方向，没有小论文毕不了业，现在很迷茫，请问目前SDN有哪几个方向可以研究，比较好出论文
A：我不是做学术研究的，所以只能谈谈自己的想法。如果我来做的话我会作一篇关于ovs网络模型的，研究neutron、OVN之类的流表pipeline。
--------------------------------------------------------------------------
SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立，携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛，每周都会组织定向的技术及业界动态分享，欢迎感兴趣的同学加微信：eigenswing，进群参与，您有想听的话题可以给我们留言。
