覆盖网络问题浅析

OVERLAY NETWORK最早受到关注始自P2P，在此之前，尽管类似隧道、的技术已经具备了OVERLAY的特征，但是波澜不兴，中规中矩，到了P2P，天翻地覆，颠覆性技术横空出世，人们开始正视OVERLAY的威力。

通常，OVERLAY NETWORK要比基础网络简单，至少从复杂性上来说，P2P、ALM这些网络现在还不能与互联网相提并论，以后也不大可能。原因比较简单，基础网络面向大多数应用，提供的是普遍服务，干的是众口难调的事，而OVERLAY NETWORK只服务于特定的业务，不必像春晚那样焦头烂额。

OVERLAY NETWORK的兴起，说明互联网正在经历一场蜕变。人们不再把互联网看成万能之神，也不打算把它往神不神鬼不鬼的路子上推。越来越多的业务，开始不需要与IP层的地址结构和路由结构绑定，也不再需要看运营商和标准化组织的眼色，在OVERLAY上，电信网络中的很多障碍荡然无存，比如自治域之间的路由策略，可以轻易被OVERLAY ROUTING绕过去。

OVERLAY NETWORK背后的智慧，是把特定的问题从痛苦无比的互联网无穷多目标优化问题中剥离出来，映射到一个独立的平面或空间，在无所羁绊的净室快刀斩乱麻而无需担心伤及无辜。在研究领域，QOS问题聒噪了几十年，从来没有出现过什么有分量的方案，最后，那个学究们认定死路一条的广域网视频传输质量问题，竟然就被OVERLAY NETWORK探囊取物般解决了，我每次抱着IPAD从PPLIVE上看高清大片的时候，都不能不感叹大道至简大智若愚。

OVERLAY NETWORK的玄机，如同回旋镖，看起来绕了个大弯，其实万变不离其宗。IP层路由结构，是一个IP层的端到端FULL MESH结构，端到端的路径，是这个结构里最小粒度的边，这个结构的特点是数据只能在两点之间的直连边上传输，不支持路径级的多跳转发。这种结构的优势，是能够从IP拓扑所蕴含的数量庞大的路径集合中，找出最优路径，而劣势，则是不能充分利用次优路径的多样性以应对故障和异常现象。从这个意义上说，路由结构强调唯一性和最优性，牺牲的是灵活性和多样性，因此适用于稳定的网络环境。这里所说的稳定，一方面是指网络结构稳定，另一方面，是指业务对路径优劣的评价标准稳定。唯一性必然带来片面性，一旦面对多样化的需求，以唯一性为特征的路由结构，就会陷入两难境地。尽管多拓扑、多路径技术可以缓解这一问题，但只要此类问题阈于路由器上解决，就难免会让路由设备在普遍转发服务和个案服务之间疲于奔命。并且，在同一个层面上维护多种路由结构和转发策略本身也不轻松。应用层路由，属于个案服务，属于IP层路由的补充。以IP层的端到端路径为边，根据路径和IP层链路的从属关系，应用层网络中边的粒度，可以小至与IP链路相当，也可以大至包含多条IP链路，就这一点而言，应用层拓扑和IP层路由结构没有本质区别。二者的差异，体现在应用层路由可以跨越多条IP层路径，也就是说，即便IP层端到端路径构成的FULL MESH结构被破坏，只要以路径为边形成的拓扑仍然连通，就有可能通过应用层路径解决路径中断问题。当然，应用层路由器和IP层路由器的重叠度越高，可恢复性就越好。当二者完全吻合的时候，也就意味着IP层的路径多样性可以完全被应用层路由挖掘出来，反之，则只能挖掘出那些包含了应用层路由器的冗余路径。因此，应用层路由结构的优劣，可以用冗余覆盖率来表示：

冗余覆盖率 = 应用层路由结构中包含的路径数量/IP层路由结构中包含的路径数量

这个比例越高，则应用层路由的性能就越好，当然，投资和开销也就越大。其中最佳的平衡点，取决于业务的特性以及网络特性，也就是说，首先要确定应用层路径能够解决问题的程度，比如提供数据转发恢复的成功率;其次，影响这一指标的要素，比如故障模型。以此构造方程求解，可以分析出需要部署节点的数量和位置。比如，网络的故障率越高，则为了达到同样的路径恢复能力，需要部署的应用层路由器节点也就越多。

因为应用层路由提供的通常是个案服务，也就是面向那些IP层路由满足不了的需求，因此在成本核算上也和IP路由不同。IP路由的特点是薄利多销，虽然构造路由结构是一个高开销高复杂性的工作，但是因为用户的数据转发任务源源不断，因此平摊下来，每用户的开销其实微乎其微。而应用层路由属于三年不开张、开张吃三年类型，如果仍然沿用IP层路由模式，效费比太低，而且复杂性会超过IP层路由。这一点比较诡异，但也不难理解。假设把OSPF协议直接搬到应用层，首先面临的问题就是每个路由器的邻居数量过于庞大，等于节点总数减一，节点有可能被HELLO给噎死。而应用层链路的稳定性，是这条链路对应路径中所有IP链路稳定度百分比的乘积，这一乘，就把稳定度给搞下来了。而最为致命的，是一旦吸上了最X路径优先这口大麻，也就会像IP层路由一样，丧失对多样性的操控能力。有人可能会说，只要让应用层路由采用急速收敛，无论网络如何变化，都能马上找到最优路径，不行吗?答案是不行，因为计算的依据LSDB很难在HELLO噎死的条件下保证实时精确，而即便能保证，在一个稳定性不高的网络中，频繁的重计算也会把骆驼压死。这里有一个非常重要的概念，凡是最优的东西，一定是从众多侯选中挑出来的，只有一个可选项，是无从讨论最优的。而挑选的过程是不是靠谱，全赖两个条件，第一是能不能保证所有有资格的候选项都进入了挑选的范围，第二是挑选的过程是否合理高效。没有这两个条件作为铺垫，像王昭君这样的大美女黯然落榜只能下嫁蛮夷的悲剧就无法避免。

既然如此,当如何是好?

方法不复杂，而且早已被AD HOC网络以及P2P网络屡试不爽，那就是概率不够、数量来凑。如果一次命中的可能性不高，多开几枪就行了。早期的加特林机关枪，精度很差，故障率也很高，曾经被嘲笑，但是嘲笑的人忘记了加特林的秘籍——射速。只要单位时间内射出的弹丸数量足够多，命中率和杀伤力就会大幅度提高。后来，性能更加优越的马克沁水冷式机关枪展示时，也被认为是愚蠢的设计，当时李鸿章也在场。只有德国人脑子好使，看出了射速的威力，大量装备陆军，在一次大战中成为与坦克齐名的大杀器。在AD HOC网络中，OSPF之类的路由协议被变幻莫测的网络结构折磨得焦头烂额，而AODV这样的按需发起路有协议却大行其道。AODV的秘诀，就在于以广播方式向外发送路径查询消息，网络结构再动荡，却奈何广播不得，虽然一次查询的开销相当可观，但和维持一个常备路由结构相比，仍然相当廉价。这就是个案服务的优势，虽然每次启动的开销和最终传输的数据量相比明显过大，但只要这些高开销行为在时间轴上稀疏，就不至于把网络压垮。在OVERLAY NETWORK中，通过一次查询消息的齐射，就能够把路径查找的成功率大幅度提升。

其中的技巧，存在于两个方面：

第一是一次齐射中问讯邻居的数量如何优化。当选取的数量小于最优值时，成功率随问讯邻居数量显著上升，而一旦越过最优值，成功率曲线就变得非常平滑，再增加问讯邻居的数量也是收益甚微。这一点，在很多讨论OVERLAY NETWORK的文章中都得到了实证。

第二是问讯邻居的位置如何选择。显然，问讯挤成一坨的一组邻居和问讯其中的一个在效果上几乎没有区别，因为从源点到这些密集邻居之间的路径重合度很高，而从这些邻居到目的点路径的重合度也很高。被问讯的邻居之间越是分散则各条路径的交叉性也就越低，IP层路径的冗余性也就能够被越好地挖掘。

这两点虽然看起来独立，其实有很大的关联性，当然在最极端的方案——问讯所有邻居中，邻居之间的位置可以忽略不计。

问讯所有的邻居并非万无一失，如果从源点到目的点之间，不存在等于2跳的应用层路径,这种方式一样会失效。在RESILIENT OVERLAY NETWORK这篇文章中，作者虽然设计了一种能够支持多跳应用层路由的方案，但实验的结果证明只要经过一个中间结点就能够实现应用层的迂回路径。但这个结论只有在网络故障率很低的情况下才能成立。Resilient Overlay Networks以及Improving the Reliability of Internet Paths with One-hop Source Routing这两篇文章对于这种情况进行了更为细致的分析，实验数据表明，针对不同的故障类型，经由一跳转发方式的成功率也表现出差异性，并非总是所向披靡。其中比较重要的影响因素，是应用层节点所连接路由器的度数，度数越大，则应用层节点可用的路径数也就越多，应对故障的能力也就越强。

在RESILIENT OVERLAY NETWORK这篇文章中，作者使用一种类似于OSPF的路由协议来计算和维护应用层转发表，为了避免频繁的路由震荡，作者设计了一种根据应用层链路历史状态累积计算权值的方法，并通过变速探测在探测效率和开销之间寻求平衡。Improving the Reliability of Internet Paths with One-hop Source Routing则代表了另外一种截然不同的设计思想，应用层节点完全不构造和维护路由表，只有在需要的时候才向几个随机选取的邻居发出讯问。Scalable Resilient Overlay Networks Using Destination-Guided Detouring把位置信息作为决策辅助，而位置信息来源于各个节点所计算出的到标志节点的RTT值，并不依赖于GPS或者IP层拓扑，基本的理念和Improving the Reliability of Internet Paths with One-hop Source Routing相同。后两篇文章都没有涉及多跳转发的问题，但他们对于一跳转发问题的分析非常值得借鉴。此外,RON的路由表只能覆盖RON节点，对于RON以外的目的地无能为力，而一跳源路由这种技术就不受此约束，这也是按需服务的好处。正如孙子所说，备前则寡后，备坐则寡右，无所不备则无所不寡。

上述文章都将应用层路由节点部署在边缘网络，独立于运营商，倘若运营商希望借助此技术解决网络生存性等问题，则具备在核心网部署的优势。无论是解决控制平面的可靠性问题，还是为特定业务提供高可靠的转发服务，应用层网络都是一个富有前景的选项。而其中的秘诀，就在于能够将缠斗于一个层面的问题分离到不同的层次隔离解耦。针对此类需求，我们考虑高故障率环境下应用层路由需要考虑的问题可以归纳为以下几点：

1、网络中存在度值较大的节点，应用层路径的丰富性和优化程度会高于仅在边缘部署的应用层路由技术;

2、由于需要承载控制信息，因此对可靠度的要求很高，需要考虑多跳应用层转发问题，充分挖掘IP路径的多样性;

3、对时效性要求较高，因此对应用层可用路径查找的效率有要求，需要通过测量保存一部分应用层链路信息，以便查找时先从优质节点入手，提高成功率;

4、不依赖网络层拓扑信息，保持独立性。

针对上述问题，可以考虑以下设计：

1、设立地标节点，作为应用层节点定位坐标的基准，利用每个节点的坐标计算节点间相对位置，将避免冗余路径交叉问题映射为寻找相对位置偏离度较大的中间节点问题。举一个简单的例子，位于同一个接入网络中的一组应用层路由器，坐标会非常接近，这些节点到其他节点之间的路径也不会有什么差异性，而当这些节点中的某一个需要查询路由时，也完全没有必要问讯一个窝里的兄弟。在Scalable Resilient Overlay Networks Using Destination-Guided Detouring这篇文章中，作者利用坐标来选取距离目的地最远或最近的节点作为中转节点，这种方法存在明显的缺陷，因为距离并不代表路径重合度，距离目的地最远的节点到目的地的路径上，有可能恰好包含源点，而距离目的地最近的节点，可能就是和目的地位于同一个子网中的节点。但是，通过坐标，可以计算出源点、目的点以及中转节点构成三角形的内角度以及边长，也就很容易判断由“源节点-中转节点”以及“中转节点-目的节点”构成的边与“源节点-目的节点”这条边的偏离程度，偏离程度越大，则路径重叠的可能性也就越低。

但单纯追求路径偏离度也存在隐患，与原始路径不相交叠的路径可能有多条，这些路径都不会受到原始路径中故障或拥塞的影响，因此，偏离度最大的路径反而有可能是这些路径中性能最差的。因此，路径偏离度可以作为筛选候选路径的条件，但不能作为优选的条件。我的想法，是首先筛选出符合数据流QOS特性的中间节点作为查询候选对象，获得应用层路径集合之后，首先按照QOS特性排序，之后利用坐标找出那些路径重叠度高的路径(重叠度如何计算、门限如何设定需要考虑)，保留其中负荷最轻者，余者退至备用路径序列的末尾。其中理念，乃是重叠度高的路径，往往是一根绳上的蚂蚱，俱损俱荣，相互之间的可替代性差，而备用路径最重要的属性就是相对于主用路径的可替代性。

路径重叠度可以从三个方面判断：

第一是两条路径中相同节点的数量;

第二是相同链路的数量;

第三是路径中位置接近的节点数量。

其中前两条容易判别，但第三条标准很难做到精确判别，因为RTT值与网络拥塞程度等非地理因素密切相关，RTT小固然可以表明位置接近，但RTT大亦未必表明位置疏远，且RTT与网络层位置以及网络拓扑特性(比如随机网络和无标度网络)之间的准确关系还有待利用实测累计经验值，因此误判难以避免，而消弭这种不确定的方法，目前来看，莫过于增加问询节点的数量。

坐标的计算需要定时进行，并结合历史信息计算最新的坐标均值。之所以不以最新的坐标值示人，是因为以RTT为计算依据的坐标本来就不存在精确值，只会围绕某个均值上下浮动，这个均值，从无限大时间尺度衡量，确实是存在的，我们不妨称之为绝对均值。但在有限的时间尺度上，不同时间段的均值会有差异，对于应用层路由而言，有价值的是均值而不是最新值。因为一方面最新值有可能和均值差异巨大却不能持久，反而带来不必要的动荡，另一方面坐标的作用是评价相对位置，在每个节点的坐标都随网络环境变化的情况下，以坐标均值计算出来的相对位置会与实际网络拓扑位置更加吻合。此外，更新后的坐标值，若相对于上一次发布坐标值的变化不超过一定的比例(此比例为可配置变量)，则不发布更新，这也是为了避免频繁变化造成的不必要开销，因为每一次计算出来的最新均值倒底和无限大时间尺度上的绝对均值有多少偏离，永远是一个未知数，虽然从大的趋势上来说，越是后计算出的均值和绝对均值之间的差异越小，但不排除在某个时段出现背离的情况。地标节点，可以由连接路由器度值较大的节点充当。为了提高应用层路由的普适性以及扩展性，我不打算让应用层节点了解与其相连路由器的信息，尽管获得网络层拓扑、路由表等信息必会如虎添翼，但和多打几枪相比，成本过于高昂，而且信息的精确性和实时性也难以得到保证。因此，指定地标节点这个步骤就需要依赖人工来完成。

2、以变速方式(测量周期也是可配置变量)探测节点间链路状态。变速体现在两个方面，第一是采用变速检测链路状态，无事则慢速检测，一旦发现异常则进入快速检测，也就是只在需要集中精力的地方集中。第二是在获得各条应用层链路的初步测量结果之后，对高质量链路进行较为快速的探测，对低质量链路进行慢速探测，并不断根据测量结果进行优胜劣汰，更新高质量链路(或高质量邻居节点)集合。维护高质量邻居集合(优质邻居的判别标准以及集合中邻居的数量也是可配置变量)的作用，就如同在地图上区分高速公路和乡间小路，为路由查询提供更好的依据。如果不加区分，每次随机选择邻居进行询问，有可能出现较差路径人品爆发反而胜出的情况，因为在网络中，路径质量好坏是一个统计意义上的指标，高速公路有可能恰好在查询那一刻出现了瞬间的拥堵而令乡间小路胜出，但这并不意味着乡间小路就能够在数据传输阶段仍然优越。

也有人会说按需服务本来就只关心当时的情况，不需要考虑长期特性，因此维护优质邻居集合属于画蛇添足。这种想法的合理性，需要建立在无差别广播基础之上，只有在这种情况下，才能保证当时最优的路径一定会被发现。如果只是向部分邻居节点询问，就必然面临一个基本问题：如何提高查询成功的概率?这个问题又可以表述为：如何提高每一个邻居查询成功的概率?答案不言自明：问讯高质量邻居是也。

让每个节点维护高质量邻居节点集合，并不意味着网络中的每个节点都要遵循统一的链路优劣判别标准，因为互联网中的链路和路径本来就良莠不齐，每个节点所处的环境千差万别，贫富不均，某些节点的所谓优质邻居甚至可能比其他节点的劣质邻居还差，按照统一标准有可能会让某些靠近边缘的节点根本找不到优质的应用层链路。因此，我认为使用相对标准更具有弹性，即每个应用层节点只将它所能探测到的N个最佳邻居放入优质邻居集合。

这么做的隐患，是在一个没有统一评价标准、鱼龙混杂的世界中，有可能仍然无法避免查询齐射命中较差的目标。而解决的方法，可以考虑在每个查询反馈信息中附加应用层链路质量信息，由源节点择优录取，这样既可省去维护全网链路状态之苦，又能保证附加信息的实时性，链路状态检测的速度不必再受制于链路状态更新的速度，也是一种形式的隔离解耦。

3、支持多跳路径查询，可以参照AODV、DSR实施广播控制以及路径缓存。但和AD HOC网络不同的是，OVERLAY NETWORK中节点的位置是固定的，链路的动态性也不像无线链路那么剧烈，应用层路由的稳定性还没有差到朝生暮死的地步，因此并不需要采用极端激进的广播方式，可以将查询扩散的范围限制在优质邻居集合，即源端只向优质邻居发送请求，而收到请求的节点也只向其优质邻居中转请求，避免无限扩散可能造成的劣质路径问题。借助于第二点中提到的附加信息方式，可以避免劣币驱逐良币现象发生。若依照此方法无法找到可用的应用层路径，则跳转至无差别广播方式，死马当成活马医，有盘菜总比没有菜强。至于防止循环广播之类的问题，直接参照AODV DSR现成的方法就行。

4、以业务的QOS需求为依据，对扩散查找得到的多条路径进行筛选，并在数据转发期间维护备用和主用路径信息，以便主用路径故障时快速启动备用路径，备用路径的数量以网络破坏度上限(例如考虑30%破坏度情况，此参数可配置)、主备用路径同时失效概率等参数为计算基准，数据传输结束之后(以某一时间范围内没有监测到数据转发为标准)，则不再维护路径信息。若备用路径皆失效，则重新进行路由查找。这一点也和AODV路由缓存的方法一致，只不过由于OVERLAY NETWORK应用的环境比AD HOC网络稳定，因此缓存的时间可以更长。对于应用层路由器来说，缓存路由条目还有一个特殊的意义。在AD HOC网络中，本来就不存在常备的IP层路径，广播路由查询消息的动机多半是因为有数据要发送(如果查询到的路径失效，也会重新发起查询)，而不是因为IP层路径受损，因此源节点以外的节点缓存路由条目的作用多半是为了准备不时之需，并没有应对故障这一层的考虑。而本文所讨论的互联网应用层路由，是对于IP层路由结构的补充，触发的动机是IP路由出现了问题，由于应用层路由节点并不维护IP拓扑和路由信息，因此源节点以外的节点无法确知自己到目的点的路径是否也受到了同一个故障的影响，缓存路由条目就有了预防的意思。可以想象，在故障密集的情况下。

5、为了避免优质节点过载，在路径查找阶段，节点负荷(节点转发流量大小)也作为一项依据加以考虑，在同等条件下，优选负荷较轻节点。

6、在选取路径时，不妨按照以下顺序进行筛选：首先选取QOS最优的路径，若有多条同等路径，则比较这些路径与原始路径的重叠度，优选重叠度最小者，其次比较各条路径包含的应用层跳数，优选跳数最小者，若仍有并列者，则比较各条路径中负荷最大节点承载的流量，优选负荷最小者，若仍有并列候选路径，则随机选择一个作为主用，其他作为备用。备用路径排序，可以参照第1点提到的方法进行。

7、新的应用层节点加入时，如何获悉、维护地标节点信息，如何获得和维护其他节点信息以及其他节点到地标节点的距离信息，节点退出或失效时，如何让其他节点获悉，如何判断一个节点已经失效或退出，如果一个节点维护的其他节点信息无法保证实时精确性，会有什么负面的影响，这种影响是否可以忽略，或者有什么办法可以消除这种负面的影响?这些工程问题，留给开发人员解决。