实例演示如何在公共互联网构建overlay实现SDWAN

overlay网络并不是什么高端的技术，我们使用了几十年的互联网本身就是一张层叠的overlay网络，列举下面的点对点聊天网络：

4个用户点对点聊天，它们并未意识到底层IP传输网络的存在，在它们看来，彼此之间是直连的，如蓝色虚线所示，4个用户连接成了一张full mesh网络。

如果能构建上述结构的实例，那么实现SDWAN就是一件很简单的事了，而实现一个点对点聊天程序程序早在2006年就是一个大专(注意，是大专)毕业设计被选烂了的课题，这意味着它并不困难。

我简单写了一个聊天程序代码：
https://github.com/marywangran/overlay/blob/master/SimpleChat.c

它的逻辑非常简单：

• 保持一个中心服务器online。
• 新User上线即上报中心服务器，服务器为该User分配ID并推送所有已上线User的信息。
• 新User获取已上线User列表，选择需要对话的User，发送消息。
• 消息直接传递给对方，无需经由中心服务器中转。
• 若需要加密，密钥在一对用户之间自行协商。

没有比这更简单的事了。效果如下：

来来来，让我们逐渐将事情复杂化。

上例中，消息来自console，如果是来自tun/tap网卡呢？那么消息本身就是一个IP数据报或者以太帧了，也就是说我们发给对端的message就是一个网络包：

基于上图的逻辑，我们接下来构建一个overlay的虚拟以太网交换机来玩玩看，该交换机结构如下：

实现上图逻辑的代码在：
https://github.com/marywangran/overlay/blob/master/SimpleVswitch.c

为了实现MAC地址的学习以及转发，overlay隧道头的封装以及解封装，我采用了一个栈式处理结构：

基本的构件已经准备好了，并且我已经实现了两个简单的示例：

• 点对点聊天。
• overlay交换机。

接下来，只需要将MAC Routing handler进行更换，就可以很方便实现一个Segment Routing的overlay SDWAN。

当然，我这里只是表达SR类似的意思，并没有按照SR协议的规范去实现它，我只是表达了通过这个框架可以实现基于标签的分段路由实现的可能性。

设计一个网络，其最最重要的就两点：

• 编址系统。
• 寻址系统。

也是，网络的意义无非就是将信息从一个点传输到另一个点，那么 如何找到任意一个点就是网络的基础，如何高效找到任意的点就是网络的优化 。 在我的例子中，我的思路是按照SR来的，但我的方法却是自己的方法，我把从controller获得的节点ID作为标签来使用，而将underlay的路由算法作为overlay的基础，在此之上，我的overlay网络可以有自己的寻址机制，比方说完全按照TCP的丢包率作为度量指标，由此行使Dijkstra算法。大致就是这个意思，我在例子中没有给出涉及丢包率度量以及Dijkstra算法的部分，这是另两个话题，而且都是很大的话题。我将注意力集中在数据平面上。

为了实现SR的数据平面，需要将节点进行分类：

• 边缘节点：为数据包设置标签栈。
• 转发节点：基于数据包的标签栈进行转发。

处理起来非常简单，先看边缘节点：

再看转发节点，它更简单，因为它无需维护标签数据库，只需要进行裸转发即可：

转发节点收到数据包后，解出隧道头里的标签栈，取出栈顶的标签，在我的例子里它是一个节点的ID，然后通过该ID映射成一个IP地址/UDP端口对，就知道下一跳发给谁了，非常简单。

我的例子里忽略了异常检查，比如这个包到底是不是发给自己的，这一切都是为了代码的简洁，不然就要写非常长。

实现上述逻辑的代码在：
https://github.com/marywangran/overlay/blob/master/SimpleSDWAN.c

如此一来，我们可以在公共互联网上的任意节点之间通过隧道构建一张overlay网络，在overlay层面上，看起来就像构建了一张广域网，这一切是由软件实现的，因此我觉得这就可以称作Software Defined，是为SDWAN。

Software Defined的灵活性在于，你可自由灵活地基于公共链路的丢包率，RTT等指标随时重新规划最优路径， 在我的例子中就是控制器可以随时将最新最优路径更新到每一个边缘节点的标签数据库，在数据包看来，这就意味着有一条新的最优路径可选。

至于具体实现，我这里只是一个POC框架，真实世界的SDWAN并非是Software的，基于Tap/UDP socket的隧道性能实在太低，那么采用Netmap/DPDK怎么样？

啊哦，Netmap/DPDK是非常适合这种栈式(或者链式)处理流程的实现的！另外，在使用非Intel网卡时，XDP也是一个不错的选择，将来会有越来越多的网卡越来越Smart，基于SmartNIC的XDP是在实现SDWAN转发平面时除DPDK之外的另一条路。

Intel拥有强大的CPU生态，在这种优良的生态上构建DPDK看起来是一个必然的结果，让自家的CPU接力处理自家网卡递上来的数据。然而对于那些没有CPU产品的网卡厂商，若要bypass内核实现高效率的数据转发平面，则必然选择另一条路，即在网卡上内置NPU(Network Processing Unit)，既然主板上没处安放它们的处理器，那就直接放在网卡上呗，这就是SmartNIC。

本文的例子其实是基于我在2017年五一假期时写的一个版本的基础上改的：
https://blog.csdn.net/dog250/article/details/70945840
这篇文章中有一些实现上的细节，可以参考。但由于大家都懂的原因，这篇文章被删除了，所以我只能通过修改关键字来规避。

OK，接下来我想谈谈我对SDWAN的一种形而上的看法。

诚然，现如今SDWAN如火如荼，无论是大型互联网公司还是初创公司都在瞄准一个或者几个点有意为之，但无论如何这些点都是运营商管理范围的灰色地带，SDWAN类似一种灰产的存在。

因此，跨境链路上做这个就在合适不过了。不管在哪里实施怎样的措施，其目标总是在于提高网络传输质量，这块貌似是运营商的空白地带。

但是，5G来临，6G也终将至，5G所宣称的那些牛X的特征其实和现如今的骨干网是相悖的，但这正是各种SDWAN在做的事，以实时视频流传输为重之根本。这意味着，如果骨干网技术不进行变革，5G将根本无法推广。

然而，仅凭着一些灰色的SDWAN野厂商可以动摇骨干网传输技术吗？远远不。你看，overlay下面的underlay，依然是那些老旧的技术，除非动摇这些技术才可以用比较正规的方式来实现SDWAN，而这些，正是运营商的领地。

话说回来，运营商虽然有权挖路修渠，但它们可能并不善于运营一些业务相关的事情，那么运营商的角色如何转变。

参考中国邮政和快递公司的关系，传统运营商作为监管机构更加合适，具体的一切就让提供并运营数据的互联网公司来经理吧。若非如此，传统运营商拿什么和互联网公司较量，就好像邮政打不过顺丰，圆通一个道理，就靠掣肘吗？

传统运营商联合行动起来是必要的，因为互联网需要一种严格的监管，否则，互联网将被各种灰色的overlay SDWAN阻塞得水泄不通！网络将彻底被经理，自私和罪恶经理一切！

哦，呜呼。

互联网是什么，互联网是平权的，互联网是去中心的，那么何以来得监管？经理啊经理。

---

浙江温州皮鞋湿，下雨进水不会胖。