CN113196723B

CN113196723B - 在公共云上限定的虚拟网络中的层四优化

Info

Publication number: CN113196723B
Application number: CN201980084056.0A
Authority: CN
Inventors: A·马尔库兹; C·达尔; A·伯格曼; I·希东; P·维努戈帕尔; E·左哈尔
Original assignee: Weirui LLC
Current assignee: Weirui LLC
Priority date: 2018-11-15
Filing date: 2019-11-01
Publication date: 2024-06-07
Anticipated expiration: 2039-11-01

Abstract

一些实施例在几个公共云提供方的若干公共云上和/或在若干区域中为实体建立虚拟网络。在一些实施例中，虚拟网络是跨越若干公共云以互连一个或多个私有网络(例如，实体的分支机构、部、部门或其相关联数据中心内的网络)、移动用户和SaaS(软件即服务)提供方机器以及实体的其它web应用的覆盖网络。在一些实施例中，虚拟网络能够被配置为优化实体的数据消息到其目的地的路由，以获得最佳的端到端性能、可靠性和安全性，同时尝试最小化这个流量通过互联网的路由。而且，在一些实施例中，虚拟网络可以被配置为优化通过网络的数据消息流的层4处理。

Description

在公共云上限定的虚拟网络中的层四优化

背景技术

如今，公司企业网络是安全地连接公司的不同办公室和部门的通信骨干。这种网络通常是广域网(WAN)，其连接：(1)分支机构和区域园区中的用户，(2)托管业务应用、内联网及其对应数据的公司数据中心，以及(3)通过公司防火墙和DMZ(非军事区)的全球互联网。企业网络包括专用硬件，诸如交换机、路由器和通过昂贵的租用线路(诸如帧中继和MPLS(多协议标签交换))互连的中间体(middlebox)装置(appliance)。

在最近若干年中，公司服务和消费通信服务的方式发生了范式转变。首先，移动性革命已允许用户使用移动设备(主要是智能电话)随时随地访问服务。此类用户通过公共互联网和蜂窝网络访问业务服务。同时，第三方SaaS(Software as a Service，软件即服务)供应方(例如，Salesforce、Workday、Zendesk)已取代了传统的内部部署的(on-premise)应用，而私有数据中心中托管的其它应用已被重定位到公共云。虽然这种流量仍承载在企业网络内，但其中很大一部分在企业网络周界之外发起和终止，并且必须穿过公共互联网(一次或两次)和企业网络二者。最近的研究表明，40％的公司网络报告，回程流量(即，在公司网络中观察到的互联网流量)所占的百分比高于80％。这意味着公司流量的大部分都通过昂贵的租用线路和消费者互联网承载。

作为以消费者为中心的服务，互联网本身是业务流量的不佳媒介。它缺乏关键业务应用所预期的可靠性、QoS(服务质量)保证和安全性。而且，不断增长的消费者流量需求、网络中立法规以及通过主要参与者(例如，Netflix、Google、公共云)创建的互联网旁路降低了每个流量单位的货币回报。这些趋势降低了服务提供方迅速赶上消费者需求并提供足够业务服务的动机。

鉴于公共云的增长，公司正在将其更多的计算基础设施迁移到公共云数据中心。公共云提供方一直处于计算和联网基础设施投资的前沿。这些云服务已在全世界建立了许多数据中心，其中Azure、AWS、IBM和Google在2016分别扩展到38、16、25和14个世界范围区域。每个公共云提供方都通过使用昂贵的高速网络来使其自己的数据中心互连，这些高速网络采用由潜艇部署的海底电缆和暗光纤。

如今，虽然有这些改变，但是公司网络政策常常迫使所有公司流量通过其安全WAN网关。随着用户变得移动并且应用迁移到SaaS和公共云，公司WAN变成代价高的绕路，这使所有公司通信变慢。大多数公司WAN的流量或者来自互联网，或者前往互联网。通过互联网发送这种流量的替代安全解决方案由于其不佳且不可靠的性能而不适用。

在过去的几年中，SD-WAN(软件定义的WAN)供应方已经解决了昂贵且带宽有限的分支机构到WAN骨干网和互联网的最后一英里连接性(通常为T1或T3)。这些供应方充分利用一群(bundle)消费者级宽带技术(例如，DOCSIS、ADSL、LTE)以及MPLS，以承载与使用单个宽带互联网接入相比多得多的流量并具有扩展的可靠性。它们的技术主要是基于对跨群的应用流量进行优化和优先级划分，通常是在放置在远程办公室和数据中心中的装置之间执行。由于它们依赖装置，因此它们常常不解决移动设备或IoT。更重要的是，它们常常也不解决公司WAN中的中距离(即，长程)连接问题，而常常连接到由电信公司提供的MPLS中距离(mid-mile)骨干，其也可以提供其SD-WAN解决方案。

另一个第二类SD-WAN供应方通过维持基于托管的存在点(通常在电信公司的数据中心)和常常基于MPLS的租用线路的私有全球网络来解决中距离问题。但是，依靠旧的租用线路模型，这些供应方忍受相同的成本和容量有限问题。Microsoft Azure最近宣布了一项称为Azure虚拟WAN的中距离WAN服务。这个云化的虚拟WAN在使用Azure云网络作为公司WAN的长程部分。它依靠中心辐射型配置以使用位于Azure云中的单个共享集线器连接多个分支。

发明内容

一些实施例为实体在一个或多个区域(例如，若干城市、州、国家等)中的一个或多个公共云提供方的若干公共云数据中心上建立虚拟网络。可以为其建立这种虚拟网络的实体的示例包括商业实体(例如，公司)、非营利实体(例如，医院、研究机构等)和教育实体(例如，大学、学院等)或任何其它类型的实体。公共云提供方的示例包括Amazon Web Services(AWS)、Google Cloud Platform(GCP)、Microsoft Azure等。

在一些实施例中，高速、可靠的私有网络互连公共云数据中心(公共云)中的两个或更多个。一些实施例将虚拟网络限定为跨越若干公共云以互连一个或多个私有网络(例如，实体的分支、部、部门或其相关联的数据中心内的网络)、移动用户、SaaS(软件即服务)提供方的机器、(一个或多个)公共云中的机器和/或服务以及其它web应用的覆盖网络。

在一些实施例中，虚拟网络可以被配置为优化实体的数据消息到其目的地的路由，以获得最佳的端到端性能、可靠性和安全性，同时尝试最小化通过互联网的这种流量的路由。而且，在一些实施例中，虚拟网络可以被配置为优化通过网络的数据消息流的层4处理。例如，在一些实施例中，虚拟网络通过跨连接路径拆分速率控制机制来优化TCP(传输控制协议)连接的端到端速率。

一些实施例通过配置在若干公共云中部署的若干部件来建立虚拟网络。在一些实施例中，这些部件包括基于软件的测量代理、软件转发元件(例如，软件路由器、交换机、网关等)、层4连接代理和中间体服务机器(例如，装置、VM、容器等)。在一些实施例中，这些部件中的一个或多个使用标准化或通常可用的解决方案，诸如Open vSwitch、Open VPN、strong Swan和Ryu。

一些实施例利用逻辑上集中的控制器集群(例如，一个或多个控制器服务器的集合)，其配置公共云部件以在若干公共云上实现虚拟网络。在一些实施例中，这个集群中的控制器位于各种不同的位置(例如，位于不同的公共云数据中心中)，以便改进冗余性和高可用性。在一些实施例中，控制器集群按比例增大或减小用于建立虚拟网络的公共云部件或分配给这些部件的计算或网络资源的数量。

一些实施例在相同公共云提供方的相同公共云集合上和/或在相同或不同公共云提供方的不同公共云集合上为不同实体建立不同的虚拟网络。在一些实施例中，虚拟网络提供方提供软件和服务，其允许不同的租户(tenant)在相同或不同的公共云上限定不同的虚拟网络。在一些实施例中，相同的控制器集群或不同的控制器集群可以被用于配置公共云部件，以针对若干不同实体在相同或不同的公共云集合上实现不同的虚拟网络。

为了在一个或多个公共云上为租户部署虚拟网络，控制器集群(1)基于租户的分支机构、数据中心、移动用户和SaaS提供方的位置来识别用于进入和离开租户的虚拟网络的可能入口和出口路由器，以及(2)识别通过实现虚拟网络的其它中间公共云路由器从识别出的入口路由器遍历到识别出的出口路由器的路由。在识别出这些路由之后，控制器集群将这些路由传播到(一个或多个)公共云中虚拟网络路由器的转发表。在使用基于OVS的虚拟网络路由器的实施例中，控制器通过使用OpenFlow来分发路由。

本发明的一些实施例使用层4会话拆分(例如，TCP拆分)，以便优化跨虚拟网络的数据消息流的遍历。在这种方法下，当从源到目的地的流量通过一个或多个公共云提供方的两个公共云时，它通过两个公共云中的两个公共云中继器(例如，作为中继器操作的两个虚拟机器)，并且这些中继器中的一个或两个中继器执行层4会话拆分。在下面的讨论中，所描述的层4拆分是TCP拆分，但是本领域普通技术人员将认识到的是，在其它实施例中，执行其它层4拆分操作。

一些实施例的TCP拆分为大的流提供了明显更好的下载时间。为了提高针对较小的流的性能，一些实施例使用优化的TCP拆分实施方式，诸如使用预定义线程池来处理SYN请求并使用预定义连接池来在云中继器中转发SYN请求。一些实施例还使用积极的云内拥塞控制过程以获得附加的改进。一些实施例还使用冗余云中继器并跨这些冗余中继器进行优化以获得通过公共云的多条路径。

因为一些实施例的虚拟网络体系架构是基于公共云，所以所部署的虚拟网络受益于公共云的管理，损失率低，IT管理员可容易地访问，并且可以由虚拟网络提供方(VNP)部署在公共云中的VM进行管理。这个体系架构也不依赖于在租户站点或租户机器(即，分支、移动用户或IoT)上安装特殊软件或使用特殊装置。如上面所提到的，在一些实施例中，通过使用(例如，基于IPSec的)标准边缘VPN软件来部署虚拟网络，其将每个用户安全地连接到云中继器。

而且，通过在不同的公共云中部署VM以实现MFN组件，可以为多个公共云上的多个不同实体限定多个虚拟网络。这些虚拟网络具有公共云的典型优势，从低成本、即用即付的支付模式到由云提供的高数据速率和吞吐量(例如，与MPLS上的远程分支的连接(通常为1-3Mbps或更低，成本比典型分支高出一个数量级)相比，每GB10美分，每VM的吞吐量为2Gbps)。

这种方法也不限于任何一个公共云提供方的基础设施。绑定到单个云提供方的解决方案常常基于单个固定共享云中继器。这种方法仅适用于单个地理区域中的公司分支，而不能扩展到全球公司WAN。例如，位于纽约的两个分支通过位于旧金山的唯一公司虚拟集线器进行通信将是没有意义的，更不用说全球分支了。

上述实施例的虚拟网络方法在其从资源受限的内部部署的计算到资源丰富的云计算的转变中遵循计算和存储的路径。如存储和计算，一些实施例的虚拟网络方法提供了几乎无限的资源，即，网络容量，并且虚拟化使得能够将本地任务委托给云，诸如域间路由和拥塞控制。

前面的发明内容旨在充当本发明的一些实施例的简要介绍。它并不意味着是本文档中公开的所有发明性主题的介绍或概述。以下的具体实施方式和在具体实施方式中引用的附图将进一步描述在发明内容中描述的实施例以及其它实施例。因而，为了理解本文档描述的所有实施例，需要对发明内容、具体实施方式、附图和权利要求书的全面回顾。而且，要求保护的主题不受发明内容、具体实施方式和附图说明中的说明性细节的限制。

附图说明

在所附权利要求书中阐述了本发明的新颖特征。但是，出于解释的目的，在以下附图中阐述本发明的若干实施例。

图1A给出了在两个公共云提供方的若干公共云数据中心上为公司限定的虚拟网络。

图1B图示了在公共云上部署的两个公司租户的两个虚拟网络的示例。

图1C可替代地图示了两个虚拟网络的示例，其中一个网络部署在公共云上，而另一个虚拟网络部署在另一对公共云上。

图2图示了本发明一些实施例的受管理转发节点和控制器集群的示例。

图3图示了在一些实施例中控制器测量-处理层产生的测量图的示例。

图4A图示了在一些实施例中控制器路径识别层从测量图产生的路由图的示例。

图4B图示了将两个SaaS提供方的已知IP添加到路由图中的在数据中心中的两个节点中的最接近这些SaaS提供方的数据中心的两个节点的示例。

图4C示出了通过添加代表两个SaaS提供方的两个节点而生成的路由图。

图4D图示了路由图，其中添加了附加节点以表示分别连接到两个公共云的具有已知IP地址的分支机构和数据中心。

图5图示了控制器路径识别层用来根据从控制器测量层接收到的测量图生成路由图的过程。

图6图示了一些实施例的IPsec数据消息格式。

图7图示了一些实施例的两个封装报头的示例，而图8给出了图示在一些实施例中如何使用这两个报头的示例。

图9-图11图示了当入口、中间和出口MFN接收在两个不同分支机构中的两个计算设备之间发送的消息时分别由入口、中间和出口MFN执行的消息处置过程。

图12图示了不涉及入口和出口MFN之间的中间MFN的示例。

图13图示了当接收到从分支机构中的公司计算设备发送到另一个分支机构中或SaaS提供方数据中心中的另一个设备的消息时由入口MFN的CFE执行的消息处置过程。

图14图示了在出口路由器处执行的NAT操作。

图15图示了由接收从SaaS提供方机器发送到租户机器的消息的入口路由器执行的消息处置过程。

图16图示了被放置在虚拟网络的到互联网的出口路径上的每个虚拟网络网关中的这种TM引擎。

图17图示了在一些实施例中使用的双NAT方法，而不是图16中示出的单NAT方法。

图18提供了图示入口NAT引擎的源端口翻译的示例。

图19图示了SaaS机器响应于其对图18的数据消息的处理而发送的回复消息的处理。

图20给出了示出一个或多个公共云提供方的N个公共云中具有网络基础设施和(一个或多个)控制器集群的虚拟网络提供方的M个租户的M个虚拟公司WAN的示例。

图21概念性地图示了由虚拟网络提供方的控制器集群执行的为特定租户部署和管理虚拟WAN的过程。

图22图示了一些实施例的三层SaaS部署模型。

图23图示了一些实施例的两层SaaS部署模型。

图24图示了一些实施例的中央控制器集群用来限定用于多宿主(multi-homed)多机器计算节点(MMCN)的路由的过程。

图25给出了SaaS数据中心和两个MMCN的两个分支节点的示例。

图26图示了一些实施例的中央控制器集群用来限定用于多宿主SaaS提供方的路由的过程。

图27图示了依赖于执行TCP拆分优化的两个云中继器的优化的虚拟网络的示例。

图28图示了图27的示例的默认数据传输机制。

图29图示了用于请求内容的理想的从头开始(clean-slate)的方法，其中对内容的请求将直接通过，从而触发所有响应分组的传输。

图30图示了客户端和服务器机器通过执行三次TCP握手来建立端到端连接的情况。

图31图示了本发明的一些实施例的TCP拆分方法。在这种方法下，客户端和服务器侧云中继器通过执行TCP拆分操作来充当TCP连接端点。

图32图示了一个示例，该示例示出当客户端和服务器侧云中继器执行TCP拆分操作时，对于小流量，TTFB和总下载时间受到不利影响。

图33图示了使用early-SYN方法来移除SYN-ACK和ACK延迟。

图34图示了使用线程池来移除分叉延迟。

图35图示了使用连接池来消除连接设置延迟。

图36图示了使用Turbo-Start TCP，从而消除TCP窗口递增延迟。

图37图示了在一些实施例中在公共云数据中心中的主机计算机上实现的云中继器的K拆分模块。

图38图示了一些实施例的K-拆分模块一旦接收到这个筛选程序(filter)已捕获第一SYN分组的Netfilter中断就执行的过程。

图39-图44图示了若干分配和配对示例，以解释图38的过程的操作。

图45概念性地图示了利用其实现本发明的一些实施例的计算机系统。

具体实施方式

在本发明的以下详细描述中，阐述并描述了本发明的许多细节、示例和实施例。但是，对于本领域技术人员而言将清晰和清楚的是，本发明不限于所阐述的实施例，并且可以在不讨论其中一些具体细节和示例的情况下实践本发明。

一些实施例针对实体在一个或多个区域(例如，若干城市、州、国家等)中的一个或多个公共云提供方的若干公共云数据中心上建立虚拟网络。可以针对其建立这种虚拟网络的实体的示例包括商业实体(例如，公司)、非营利实体(例如，医院、研究机构等)和教育实体(例如，大学、学院等)或任何其它类型的实体。公共云提供方的示例包括Amazon WebServices(AWS)、Google Cloud Platform(GCP)、Microsoft Azure等。

一些实施例将虚拟网络限定为覆盖网络，该覆盖网络跨越若干公共云数据中心(公共云)以使一个或多个私有网络(例如，实体的分支、部门(division)、部(department)或其相关联的数据中心内的网络)、移动用户、SaaS(软件即服务)提供方机器、(一个或多个)公共云中的机器和/或服务以及其它web应用互连。在一些实施例中，高速、可靠的私有网络使公共云数据中心中的两个或更多个公共云数据中心互连。

一些实施例通过配置在若干公共云中部署的若干部件来建立虚拟网络。在一些实施例中，这些部件包括基于软件的测量代理、软件转发元件(例如，软件路由器、交换机、网关等)、层4连接代理和中间体服务机器(例如，装置、VM、容器等)。

一些实施例利用逻辑上集中的控制器集群(例如，一个或多个控制器服务器的集合)，其配置公共云部件以在若干公共云上实现虚拟网络。在一些实施例中，这个集群中的控制器在各种不同的位置(例如，在不同的公共云数据中心中)，以便改进冗余性和高可用性。当控制器集群中的不同控制器位于不同的公共云数据中心中时，在一些实施例中，控制器共享它们的状态(例如，配置数据，控制器生成该配置数据以识别租户、通过虚拟网络的路由等)。在一些实施例中，控制器集群按比例增大或减小用于建立虚拟网络的公共云部件的数量或分配给这些部件的计算或网络资源的数量。

一些实施例在相同的公共云提供方的相同的公共云集合上和/或在相同或不同的公共云提供方的不同的公共云集合上针对不同实体建立不同的虚拟网络。在一些实施例中，虚拟网络提供方提供软件和服务，该软件和服务允许不同的租户在相同或不同的公共云上限定不同的虚拟网络。在一些实施例中，相同的控制器集群或不同的控制器集群可以被用于配置公共云部件，以针对若干不同实体在相同或不同的公共云集合上实现不同的虚拟网络。

在下面的讨论中提供公司虚拟网络的若干示例。但是，本领域的普通技术人员将认识到的是，一些实施例针对其它类型的实体(诸如其它业务实体、非营利组织、教育实体等)限定虚拟网络。而且，如本文档中所使用的，数据消息是指跨网络发送的以特定格式的位的集合。本领域普通技术人员将认识到的是，术语数据消息在本文档中用于指代跨网络发送的各种格式化的位的集合。这些位的格式可以由标准化协议或非标准化协议指定。遵循标准化协议的数据消息的示例包括以太网帧、IP分组、TCP片段、UDP数据报等。而且，如本文档中所使用的，对L2、L3、L4和L7层(或层2、层3、层4或层7)的引用是分别对OSI(开放系统互连)层模型的第二数据链路层、第三网络层、第四传输层和第七应用层的引用。

图1A给出了虚拟网络100，该虚拟网络100是在两个公共云提供方A和B的若干公共云数据中心105和110上针对公司限定的。如图所示，虚拟网络100是安全的覆盖网络，其通过在不同的公共云中部署不同的受管理转发节点150以及通过覆盖隧道152将受管理转发节点(MFN)彼此连接来建立。在一些实施例中，MFN是公共云数据中心中的若干不同部件的概念性分组，其与其它公共云数据中心中的其它MFN(与部件的其它组)一起针对一个或多个实体建立一个或多个覆盖虚拟网络。

如以下进一步描述的，在一些实施例中，形成MFN的部件的组包括：(1)一个或多个VPN网关，用于与作为在公共云数据中心外部的外部机器位置的实体的计算节点(例如，办公室、私有数据中心、远程用户等)建立VPN连接，(2)一个或多个转发元件，用于在彼此之间转发经封装的数据消息，以便在共享的公共云网络架构上限定覆盖虚拟网络，(3)一个或多个服务机器，用于执行中间体服务操作以及L4-L7优化，以及(4)一个或多个测量代理，用于获得关于公共云数据中心之间的网络连接质量的测量，以便识别通过公共云数据中心的期望路径。在一些实施例中，出于冗余和可伸缩性的原因，不同的MFN可以具有不同的布置和不同数量的此类部件，并且一个MFN可以具有不同数量的此类部件。

而且，在一些实施例中，每个MFN的部件组在MFN的公共云数据中心中的不同计算机上执行。在一些实施例中，MFN的部件中的若干或全部部件可以在公共云数据中心的一个计算机上执行。在一些实施例中，MFN的部件在还执行其它租户的其它机器的主机计算机上执行。这些其它机器可以是其它租户的其它MFN的其它机器，或者它们可以是其它租户的不相关机器(例如，计算VM或容器)。

在一些实施例中，虚拟网络100由虚拟网络提供方(VNP)部署，该虚拟网络提供方在相同或不同的公共云数据中心上针对不同实体(例如，虚拟网络提供方的不同公司客户/租户)部署不同的虚拟网络。在一些实施例中，虚拟网络提供方是实体，该实体部署MFN并提供用于配置和管理这些MFN的控制器集群。

虚拟网络100将公司计算端点(诸如数据中心、分支机构和移动用户)彼此连接，并连接到驻留在公共云中或驻留在可通过互联网访问的私有数据中心中的外部服务(例如，公共web服务，或SaaS服务，诸如Office365或Salesforce)。如下面进一步描述的，在一些实施例中，SaaS是软件分发模型，其中第三方提供方托管应用并使应用可以通过互联网供客户使用。

虚拟网络充分利用不同公共云的不同位置以将不同的公司计算端点(例如，公司的不同移动用户和/或不同的私有网络)连接到它们附近的公共云。在下面的讨论中，公司计算端点也被称为公司计算节点。在一些实施例中，虚拟网络100还充分利用将这些公共云互连的高速网络以通过公共云将数据消息转发到它们的目的地或尽可能接近它们的目的地，同时减少它们通过互联网的遍历。当公司计算端点在虚拟网络所跨越的公共云数据中心外部时，这些端点被称为外部机器位置。公司分支机构、私有数据中心和远程用户的设备就是这种情况。

在图1A所示的示例中，虚拟网络100跨越公共云提供方A的六个数据中心105a-105f和公共云提供方B的四个数据中心110a-110d。在跨越这些公共云时，这种虚拟网络连接位于不同地理区域的若干分支机构、公司数据中心、SaaS提供方和公司租户的移动用户。具体而言，虚拟网络100连接两个不同城市(例如，加利福尼亚州的旧金山和印度的浦那)中的两个分支机构130a和130b、另一个城市(例如，华盛顿州的西雅图)中的公司数据中心134、在另外两个城市(华盛顿州的雷德蒙德和法国的巴黎)中的两个SaaS提供方数据中心136a和136b、以及世界上各个地点处的移动用户140。照此，这种虚拟网络可以被视为虚拟公司WAN。

在一些实施例中，分支机构130a和130b具有其自己的私有网络(例如，局域网)，该私有网络连接分支位置处的计算机和在公共云外部的分支私有数据中心。类似地，在一些实施例中，公司数据中心134具有其自己的私有网络，并且驻留在任何公共云数据中心外部。但是，在其它实施例中，公司数据中心134或分支130a和130b的数据中心可以在公共云内，但是虚拟网络不跨越这个公共云，因为公司或分支数据中心连接到虚拟网络100的边缘。

如上面所提到的，经由通过覆盖隧道152连接不同公共云中不同部署的受管理转发节点150来建立虚拟网络100。每个受管理转发节点150包括若干可配置的部件。如上面进一步描述和下面进一步描述的，在一些实施例中，MFN部件包括基于软件的测量代理、软件转发元件(例如，软件路由器、交换机、网关等)、层4代理(例如，TCP代理)和中间体服务机器(例如，VM、容器等)。在一些实施例中，这些部件中的一个或多个使用标准化或通常可用的解决方案，诸如Open vSwitch、OpenVPN、strongSwan等。

在一些实施例中，每个MFN(即，概念上形成MFN的部件的组)可以由在公共云数据中心中部署和配置MFN的虚拟网络提供方的不同租户共享。结合地或可替代地，在一些实施例中，虚拟网络提供方可以在用于特定租户的一个或多个公共云数据中心中部署MFN的独有的集合。例如，出于安全性原因或服务质量原因，特定租户可能不希望与另一个租户共享MFN资源。对于这样的租户，虚拟网络提供方可以跨若干公共云数据中心部署其自己的MFN集合。

在一些实施例中，逻辑上集中的控制器集群160(例如，一个或多个控制器服务器的集合)在公共云105和110中的一个或多个的内部或外部操作，并配置受管理转发节点150的公共云部件，以在公共云105和110上实现虚拟网络。在一些实施例中，这个集群中的控制器在各种不同的位置(例如，在不同的公共云数据中心中)，以便改进冗余性和高可用性。在一些实施例中，控制器集群按比例增大或减小用于建立虚拟网络的公共云部件的数量或分配给这些部件的计算或网络资源的数量。

在一些实施例中，控制器集群160或虚拟网络提供方的另一个控制器集群在相同的公共云105和110上和/或在不同公共云提供方的不同公共云上为另一个公司租户建立不同的虚拟网络。除了(一个或多个)控制器集群之外，在其它实施例中，虚拟网络提供方还在公共云中部署转发元件和服务机器，这允许不同租户在相同或不同的公共云上部署不同的虚拟网络。图1B图示了用于在公共云105和110上部署的两个公司租户的两个虚拟网络100和180的示例。图1C可替代地图示了两个虚拟网络100和182的示例，其中一个网络100部署在公共云105和110上，而另一个虚拟网络182部署在另一对公共云110和115上。

通过MFN的经配置的部件，图1A的虚拟网络100允许公司租户的不同私有网络和/或不同移动用户连接到相对于这些私有网络和/或移动用户而言在最优位置的不同公共云(例如，如在物理距离方面、在连接速度、损失、延迟和/或成本方面，和/或在网络连接可靠性方面等等所测量的)。在一些实施例中，这些部件还允许虚拟网络100使用使公共云互连的高速网络，以通过公共云将数据消息转发到其目的地，同时减少它们通过互联网的遍历。

在一些实施例中，MFN部件还被配置为在网络、传输和应用层运行新颖的过程，以优化端到端的性能、可靠性和安全性。在一些实施例中，这些过程中的一个或多个实现专有的高性能联网协议，而没有当前的网络协议僵化。照此，在一些实施例中，虚拟网络100不受互联网自治系统、路由协议或者甚至端到端传输机制的限制。

例如，在一些实施例中，MFN 150的部件(1)创建优化的多路径和自适应集中式的路由，(2)提供强大的QoS(服务质量)保证，(3)优化通过中间TCP拆分和/或终止的端到端TCP速率，以及(4)将可伸缩的应用级中间体服务(例如，防火墙、入侵检测系统(IDS)、入侵防御系统(IPS)、WAN优化等)重新定位到全局网络功能虚拟化(NFV)中云的计算部分。因而，可以优化虚拟网络以适应公司的定制的且不断变化的需求，而不必束缚于现有的网络协议。而且，在一些实施例中，虚拟网络可以被配置为“即用即付”的基础设施，其可以根据连续的要求改变而动态且弹性地在性能能力和地理范围上按比例增大和减小。

为了实现虚拟网络100，虚拟网络所跨越的每个公共云数据中心105a-105f和110a-110d中的至少一个受管理转发节点150必须由控制器集合配置。图2图示了本发明一些实施例的受管理转发节点150和控制器集群160的示例。在一些实施例中，每个受管理转发节点150是在公共云数据中心中的主机计算机上执行的机器(例如，VM或容器)。在其它实施例中，每个受管理转发节点150由在一个公共云数据中心中的同一主机计算机上执行的多个机器(例如，多个VM或容器)实现。在还有其它实施例中，一个MFN的两个或更多个部件可以由在一个或多个公共云数据中心中的两个或更多个主机计算机上执行的两个或更多个机器来实现。

如图所示，受管理转发节点150包括测量代理205、防火墙和NAT中间体服务引擎210和215、一个或多个优化引擎220、边缘网关225和230以及云转发元件235(例如，云路由器)。在一些实施例中，这些部件205-235中的每一个可以被实现为两个或更多个部件的集群。

在一些实施例中，控制器集群160可以动态地按比例增大或减小每个部件集群(1)以添加或移除机器(例如，VM或容器)以实现每个部件的功能，和/或(2)以向实现那个集群的部件的先前部署的计算机添加或移除计算和/或将网络资源。照此，公共云数据中心中的每个部署的MFN 150可以被视为MFN的集群，或者它可以被视为包括执行MFN的不同操作的多个不同部件集群的节点。

而且，在一些实施例中，控制器集群在公共云数据中心中为不同的租户部署MFN的不同集合，控制器集群在公共云数据中心上为租户限定了虚拟网络。在这种方法中，任何两个租户的虚拟网络都不共享任何MFN。但是，在下面描述的实施例中，每个MFN可以被用于为不同的租户实现不同的虚拟网络。普通技术人员将认识到的是，在其它实施例中，控制器集群160可以利用其自己的部署的MFN的专用集合来实现第一租户集合中的每个租户的虚拟网络，同时利用部署的MFN的共享集合来实现第二租户集合中的每个租户的虚拟网络。

在一些实施例中，分支网关225和远程设备网关230分别与连接到MFN 150的一个或多个分支机构130和远程设备(例如，移动设备140)建立安全的VPN连接，如图2中所示。这种VPN连接的一个示例是IPsec连接，下面将对其进行进一步描述。但是，本领域普通技术人员将认识到的是，在其它实施例中，此类网关225和/或230建立不同类型的VPN连接。

在一些实施例中，MFN 150包括执行一个或多个中间体服务操作(诸如防火墙操作、NAT操作、IPS操作、IDS操作、负载平衡操作、WAN优化操作等)的一个或多个中间体引擎。通过在公共云中部署的MFN中并入这些中间体操作(例如，防火墙操作、WAN优化操作等)，虚拟网络100在公共云中实现传统上由公司的(一个或多个)数据中心和/或(一个或多个)分支机构处的公司WAN基础设施执行的许多功能。

因而，对于许多中间体服务，公司计算节点(例如，远程设备、分支机构和数据中心)不再必须访问私有数据中心或分支机构中公司的公司WAN基础设施，因为这些服务中的许多现在已被部署在公共云中。这种方法加快了企业计算节点(例如，远程设备、分支机构和数据中心)对这些服务的访问，并避免了私有数据中心处以其他方式将专用于提供此类服务的昂贵的拥塞网络瓶颈。

这种方法有效地将WAN网关功能分发到公共云数据中心中的各种MFN。例如，在一些实施例的虚拟网络100中，传统公司WAN网关安全功能(例如，防火墙操作、入侵检测操作、入侵防御操作等)中的大多数或全部被移动到公共云MFN(例如，将来自计算端点的数据接收到虚拟网络中的入口MFN)。这有效地允许虚拟网络100具有在实现虚拟网络100的许多不同的MFN处实现的分布式WAN网关。

在图2所示的示例中，MFN 150被示为包括防火墙引擎210、NAT引擎215和一个或多个L4-L7优化引擎。普通技术人员将意识到的是，在其它实施例中，MFN 150包括用于执行其它中间体操作的其它中间体引擎。在一些实施例中，防火墙引擎210对以下施行(enforce)防火墙规则：(1)在其进入虚拟网络中的入口路径上的数据消息流(例如，对网关225和230从分支机构130和移动设备140接收并处理的数据消息流)以及(2)在其从虚拟网络离开的出口路径上的数据消息流(例如，对通过NAT引擎215和互联网202发送到SaaS提供方数据中心的数据消息流)。

在一些实施例中，MFN 150的防火墙引擎210还在防火墙引擎属于MFN时施行防火墙规则，该MFN是数据消息流进入虚拟网络的入口MFN与数据消息流离开虚拟网络的出口MFN之间的中间跳。在其它实施例中，防火墙引擎210仅在它是数据消息流的入口MFN和/或出口MFN的一部分时才施行防火墙规则。

在一些实施例中，NAT引擎215执行网络地址翻译，以改变从虚拟网络离开通过互联网202到第三方设备(例如，到SaaS提供方机器)的数据消息流的出口路径上的数据消息流的源网络地址。此类网络地址翻译确保第三方机器(例如，SaaS机器)可以被正确地配置为处理数据消息流，如果没有地址翻译，则可能会指定租户和/或公共云提供方的私有网络地址。由于不同租户和/或云提供方的私有网络地址可能重叠，因此这尤其成问题。地址翻译还确保来自第三方设备(例如，SaaS机器)的回复消息可以通过虚拟网络(例如，通过消息从其离开虚拟网络的MFN NAT引擎)正确接收。

在一些实施例中，MFN的NAT引擎215对离开虚拟网络到达第三方机器或从第三方机器进入虚拟网络的每个数据消息流执行双NAT操作。如下面进一步描述的，两个NAT操作中的一个NAT操作在这种数据消息流进入虚拟网络时在该数据消息流的入口MFN处对该数据消息流执行，而另一个NAT操作在数据消息流离开虚拟网络时在该数据消息流的出口MFN处对该数据消息流执行。

这种双NAT方法允许将更多租户私有网络映射到公共云提供方的网络。这种方法还减轻了用于将关于改变的MFN数据分发给租户私有网络的负担。在入口或出口NAT操作之前，一些实施例执行租户映射操作，该租户映射操作使用租户标识符首先将租户的源网络地址映射到另一个源网络地址，该另一个源网络地址然后通过NAT操作映射到又一个源网络地址。执行双NAT操作减轻了用于将关于改变的数据分发给租户私有网络的数据分发负担。

优化引擎220执行新颖的过程，该过程优化实体的数据消息到其目的地的转发，以实现最佳的端到端性能和可靠性。这些过程中的一些过程实现专有的高性能联网协议，而免于当前的网络协议僵化。例如，在一些实施例中，优化引擎220通过中间TCP拆分和/或终止来优化端到端TCP速率。

云转发元件235是MFN引擎，当数据消息流必须遍历另一个公共云以到达其目的地时，该MFN引擎负责将该数据消息流转发到下一跳MFN的云转发元件(CFE)，或者当数据消息流可以通过同一公共云到达该数据消息流的目的地时，该MFN引擎负责将该数据消息流转发到同一公共云中的出口路由器。在一些实施例中，MFN 150的CFE 235是软件路由器。

为了转发数据消息，CFE用隧道报头封装消息。不同的实施例使用不同的方法来用隧道报头封装数据消息。当数据消息必须遍历一个或多个中间MFN以到达出口MFN时，以下描述的一些实施例使用一个隧道报头来识别用于进入和离开虚拟网络的网络入口/出口地址，并使用另一个隧道报头来识别下一跳MFN。

具体而言，在一些实施例中，CFE发送具有以下两个隧道报头的数据消息：(1)识别用于进入和离开虚拟网络的入口CFE和出口CFE的内部报头，以及(2)识别下一跳CFE的外部报头。在一些实施例中，内部隧道报头还包括租户标识符(TID)，以便允许虚拟网络提供方的多个不同租户使用虚拟网络提供方的共用的MFN CFE集合。其它实施例不同地限定隧道报头以便限定覆盖虚拟网络。

为了在一个或多个公共云上为租户部署虚拟网络，控制器集群(1)基于租户的公司计算节点(例如，分支机构、数据中心、移动用户和SaaS提供方)的位置来识别用于进入和离开租户的虚拟网络的可能入口和出口路由器，以及(2)识别通过实现虚拟网络的其它中间公共云路由器从识别出的入口路由器遍历到识别出的出口路由器的路由。在识别出这些路由之后，控制器集群将这些路由传播到(一个或多个)公共云中的MFN CFE 235的转发表。在使用基于OVS的虚拟网络路由器的实施例中，控制器通过使用OpenFlow来分发路由。

在一些实施例中，控制器集群160还可以配置实现虚拟网络以优化若干网络处理层的每个MFN 150的部件205-235，以便获得最佳的端到端性能、可靠性和安全性。例如，在一些实施例中，这些部件被配置为(1)优化层3流量路由(例如，最短路径、分组重复)，(2)优化层4TCP拥塞控制(例如，分段、速率控制)，(3)实现安全性特征(例如，加密、深度分组检查、防火墙)，以及(4)实现应用层压缩特征(例如，去重、高速缓存)。在虚拟网络内，对公司流量进行安全保护、检查和日志记录。

在一些实施例中，为公共云数据中心中的每个MFN部署一个测量代理。在其它实施例中，公共云数据中心或数据中心的集合中(例如，附近相关联的数据中心(诸如，一个可用性区中的数据中心)的集合中)的多个MFN共享一个测量代理。为了优化层3和层4处理，与每个受管理转发节点150相关联的测量代理205重复地生成对其节点与若干其他“相邻”节点之间的网络连接的质量进行量化的测量值。

不同的实施例不同地限定相邻节点。对于特定公共云提供方的一个公共云数据中心中的特定MFN，在一些实施例中，相邻节点包括(1)在该特定公共云提供方的任何公共云数据中心中操作的任何其它MFN，以及(2)在与该特定MFN处于同一“区域”内的另一个公共云提供方的数据中心中操作的任何其它MFN。

不同的实施例不同地限定相同区域。例如，一些实施例按照距离来限定区域，该距离指定围绕特定受管理转发节点的边界形状。其它实施例按照城市、州或地区来限定区域，诸如北加利福尼亚、南加利福尼亚等。这种方法的假设是，同一公共云提供方的不同数据中心以非常高速的网络连接进行连接，而不同公共云提供方的数据中心之间的网络连接在这些数据中心位于同一区域中时很可能快，而在这些数据中心位于不同区域中时很可能不那么快。当数据中心在不同区域中时，不同公共云提供方的数据中心之间的连接可能必须通过公共互联网遍历长距离。

在不同的实施例中，测量代理205不同地生成测量值。在一些实施例中，测量代理周期性地(例如，每秒、每N秒、每分钟、每M分钟等一次)向其相邻的受管理转发节点的每个测量代理发送查验(pinging)消息(例如，UDP回声消息)。鉴于查验消息的小尺寸，它们不会导致大的网络连接费用。例如，对于其中每个节点每10秒向每个其它节点发送ping的100个节点，每个节点生成大约10Kb/s的入口和出口测量流量，并且鉴于当前的公共云价格，这将导致每个节点每年几美元(例如，＄5)的网络消耗费用。

基于其接收到的回复消息的速度，测量代理205计算并更新测量度量值(诸如网络连接吞吐速度、延迟、损失和链路可靠性)。通过重复进行这些操作，测量代理205限定并更新测量结果矩阵，该矩阵表述与其相邻节点的网络连接的质量。当代理205与其相邻节点的测量代理交互时，其测量矩阵仅量化与其本地节点团(clique)的连接的质量。

不同的受管理转发节点的测量代理将其测量矩阵发送到控制器集群160，该控制器集群160然后聚合所有不同的团连接数据以获得不同对的受管理转发节点之间的连接的聚合网格视图。当控制器集群160为两对转发节点之间的链路收集不同的测量(例如，由一个节点在不同时间进行的测量)时，控制器集群从不同的测量中产生混合的值(例如，产生测量的平均值或加权平均值)。在一些实施例中，聚合网格视图是每对受管理转发节点之间的所有网络连接的全网格视图，而在其它实施例中，它是比由各个受管理转发节点的测量代理产生的视图更完整的视图。

如图2中所示，控制器集群160包括一个或多个测量处理引擎280、一个或多个路径识别引擎282和一个或多个管理接口284的集群。为了避免以不必要的细节模糊本描述，下面将按照单个引擎或接口层(即，按照测量处理层280、路径识别层282和管理接口层284)提到这些集群中的每一个。

测量处理层280从受管理转发节点的测量代理205接收测量矩阵，并处理这些测量矩阵以产生表述不同对的受管理转发节点之间的连接质量的聚合网格矩阵。测量处理层280将聚合网格矩阵提供给路径识别层282。基于聚合网格矩阵，路径识别层282识别通过虚拟网络的用于连接不同公司数据端点(例如，不同分支机构、公司数据中心、SaaS提供方数据中心和/或远程设备)的不同期望路由路径。然后，这个层282在路由表中提供这些路由路径，路由表被分发给受管理转发节点150的云转发元件235。

在一些实施例中，针对每对数据消息端点的识别出的路由路径是基于优化准则集合被认为最优的路由路径，例如，它是最快的路由路径、最短的路由路径或最少使用互联网的路径。在其它实施例中，路径识别引擎可以识别并提供(在路由表中)相同的两个端点之间的多个不同的路由路径。在这些实施例中，受管理转发节点150的云转发元件235然后基于它们正在施行的QoS准则或其它运行时准则来选择路径之一。在一些实施例中，每个CFE235不接收从CFE到虚拟网络的出口点的整个路由路径，而是接收该路径的下一跳。

在一些实施例中，路径识别层282使用聚合网格矩阵中的测量值作为其执行以构造全局路由图的路由算法的输入。在一些实施例中，这个全局路由图是测量处理层280产生的测量图的聚合和优化的版本。图3图示了在一些实施例中控制器测量处理层280产生的测量图300的示例。这个图描绘了AWS和GCP公共云310和320中(即，AWS和GCP的数据中心中)各个受管理转发节点150之间的网络连接。图4A图示了在一些实施例中控制器路径识别层282从测量图300产生的路由图400的示例。

图5图示了控制器路径识别层用来根据从控制器测量层接收到的测量图生成路由图的过程500。当路径识别层282从控制器测量层重复接收到更新后的测量图时，路径识别层282重复执行这个过程500(例如，每次其接收到新测量图时，或每N次其接收到新测量图时，执行过程500)。在其它实施例中，路径识别层282周期性地执行这个处理(例如，每12小时或24小时一次)。

如图所示，路径识别层最初将路由图限定(在505处)为与测量图相同(即，在相同对的受管理转发节点之间具有相同的链路)。在510处，该过程从测量图300中移除坏链路。坏链路的示例包括消息损失过多或可靠性差的链路(例如，最近15分钟内消息损失大于2％的链路，或最近2分钟内消息损失大于10％的链路)。图4A图示了在路由图400中排除了测量图300中的链路302、304和306。这个图通过用虚线描绘这些链路来图示这些链路的排除。

接下来，在515处，过程500计算链路权重得分(成本得分)作为若干计算出的且特定于提供方的值的加权组合。在一些实施例中，权重得分是链路的(1)计算出的延迟值、(2)计算出的损失值、(3)提供方网络连接成本和(4)提供方计算成本的加权组合。在一些实施例中，由于通过链路连接的受管理转发节点是在(一个或多个)公共云数据中心中的主机计算机上执行的机器(例如，VM或容器)，因此考虑了提供方的计算成本。

在520处，该过程将用于虚拟网络中的数据消息流的已知源和目的地IP地址(例如，由公司实体使用的SaaS提供方的已知IP)添加到路由图。在一些实施例中，该过程将可能的消息流端点的每个已知IP地址添加到路由图中最接近那个端点的节点(例如，添加到表示MFN的节点)。在这样做时，在一些实施例中，该过程假设每个这样的端点通过具有零延迟成本和零损失成本的链路连接到虚拟网络。图4B图示了将两个SaaS提供方的已知IP添加到路由图中的两个节点402和404(表示两个MFN)的示例，该两个节点在最靠近这些SaaS提供方的数据中心的数据中心中。在这个示例中，一个节点在AWS公共云中，而另一个节点在GCP公共云中。

可替代地或相结合地，在一些实施例中，通过将节点添加到路由图中以表示源和目的地端点、将IP地址指派给这些节点以及将权重值指派给将这些添加的节点连接到路由图中的其它节点(例如，连接到路由图中表示公共云中的MFN的节点)的链路，过程500将已知的源和目的地IP地址添加到路由图。当流的源和目的地端点被添加为节点时，路径识别引擎282可以在识别出在不同源和目的地端点之间的通过虚拟网络的不同路由时考虑到达这些节点的成本(例如，距离成本、延迟成本和/或财务成本等)。

图4C图示了通过将两个节点412和414添加到图4A的节点图400以便表示两个SaaS提供方而生成的路由图410。在这个示例中，已知的IP地址被指派给节点412和414，并且这些节点通过链路416和418连接到节点402和404(表示两个MFN)，链路416和418具有被指派给它们的权重W1和W2。这种方法是用于添加两个SaaS提供方的已知IP地址的图4B中所示方法的替代方法。

图4D图示了更详细的路由图415。在这个更详细的路由图中，添加了附加节点422和424，以表示分别连接到AWS和GCP公共云310和320的具有已知IP地址的外部公司计算节点(例如，分支机构和数据中心)。这些节点422/424中的每一个通过具有相关联的权重值Wi的至少一个链路426连接到表示MFN的路由图节点中的至少一个。这些节点中的一些(例如，分支机构中的一些)通过多条链路连接到同一个MFN或不同的MFN。

接下来，在525处，过程500计算每个MFN与可以充当公司实体的数据消息流的虚拟网络出口位置的每个其它MFN之间的最低成本路径(例如，最短路径等)。在一些实施例中，出口MFN包括连接到外部公司计算节点(例如，分支机构、公司数据中心和SaaS提供方数据中心)的MFN，以及作为移动设备连接和出口互联网连接的候选位置的MFN。在一些实施例中，这种计算使用识别不同MFN对之间的最短路径的传统的最低成本(例如，最短路径)识别过程。

对于每个候选MFN对，当在MFN对之间存在多条这样的路径时，最低成本识别过程使用计算出的权重得分(即，在510处计算出的得分)来识别具有最低得分的路径。下面将进一步描述用于计算最低成本路径的若干方式。如上面所提到的，在一些实施例中，路径识别层282识别两个MFN对之间的多条路径。这是为了允许云转发元件235在不同情况下使用不同路径。因而，在这些实施例中，过程500可以识别两个MFN对之间的多条路径。

在530处，该过程从路由图中移除未被在525处识别出的最低成本路径中的任一个使用的MFN对之间的链路。接下来，在535处，该过程根据路由图生成用于云转发元件235的路由表。在535处，该过程将这些路由表分发给受管理转发节点的云转发元件235。在535之后，该过程结束。

在一些实施例中，虚拟网络具有两种类型的外部连接，它们是：

(1)与实体的计算节点(例如，分支机构、数据中心、移动用户等)的外部安全连接，以及(2)通过互联网与第三方计算机(例如，SaaS提供方服务器)的外部连接。一些实施例通过为终止于虚拟网络之外的源和目的地节点处的每条数据路径找到最优虚拟网络入口和出口位置来优化虚拟网络。例如，为了将分支机构连接到SaaS提供方服务器(例如，salesforce.com服务器)，一些实施例将分支机构连接到最优边缘MFN(例如，具有到分支机构的最快的网络连接或最接近分支机构的网络连接的MFN)，并识别到最优定位的SaaS提供方服务器的最优边缘MFN(例如，最接近分支机构的边缘MFN的SaaS，或者具有通过连接到SaaS提供方服务器的边缘MFN到分支机构的边缘MFN的最快路径的SaaS)。

为了通过VPN连接使实体的每个计算节点(例如，分支机构、移动用户等)与最近的MFN相关联，在一些实施例中，虚拟网络提供方在公共云中部署一个或多个权威域名服务器(DNS)供计算节点联系。在一些实施例中，每当公司计算节点在一些实施例中需要建立到虚拟网络提供方的MFN的VPN连接(即，为了初始化或重新初始化VPN连接)时，计算节点首先解析其与具有这个权威DNS服务器的虚拟网络(例如，virtualnetworkX.net)相关联的地址，以便从这个服务器获得由这个服务器识别为最接近企业计算节点的MFN的MFN的身份。为了识别这个MFN，在一些实施例中，权威DNS服务器提供MFN标识符(例如，MFN的IP地址)。然后，公司计算节点建立到这个受管理转发节点的VPN连接。

在其它实施例中，企业计算节点在每次其需要与VNP的MFN建立VPN连接时不首先执行DNS解析(即，不首先解析特定域的网络地址)。例如，在一些实施例中，公司计算节点在特定持续时间内(例如，一天、一周等内)坚持使用DNS解析的MFN，之后执行另一个DNS解析以确定这个MFN是否仍然是应当连接的最优MFN。

当DNS请求中的源IP地址是公司计算节点的本地DNS服务器的源IP地址而不是节点本身的源IP地址时，在一些实施例中，权威DNS服务器识别最接近本地DNS服务器的MFN而不是最接近公司计算节点的MFN。为了解决这个问题，在一些实施例中，DNS请求按照域名来识别公司计算节点，该域名包括一个或多个由点联结和定界的部分(标签)，其中这些部分之一识别公司，而另一个部分识别公司的计算节点。

在一些实施例中，这个域名指定域名中从右标签到左标签降序的域和子域的层次结构。最右侧的第一标签识别特定域，第一标签左侧的第二标签识别公司实体，并且如果实体有多于一个外部机器位置，那么第二标签左侧的第三标签识别实体的外部机器位置。例如，在一些实施例中，DNS请求将公司计算节点识别为公司myCompany的myNode，并请求地址myNode.myCompany.virtualnetwork.net的解析。然后，DNS服务器使用myNode标识符更好地选择公司计算节点应当建立VPN连接的入口MFN。在不同的实施例中，myNode标识符被不同地表述。例如，其可以被寻址为IP地址、位置的纬度/经度描述、GPS(全球定位系统)位置、街道地址等。

即使在IP地址正确地反映位置的情况下，也可能存在若干个潜在的入口路由器，例如，属于同一个云中的不同数据中心或属于同一区域中的不同云。在这种情况下，在一些实施例中，虚拟网络权威服务器发送回潜在的MFN CFE(例如，C5、C8、C12)的IP的列表。然后，在一些实施例中，公司计算节点对列表中的不同CFE执行ping操作，以产生测量(例如，距离或速度测量)，并在CFE候选的集合当中通过对测量进行比较来选择最接近的一个。

此外，企业计算节点可以通过识别由企业实体的其它计算节点当前使用的MFN来以这种选择为基础。例如，在一些实施例中，公司计算节点将连接成本添加到每个MFN，因此，如果许多公司分支已经连接到给定的云，那么新的计算节点将具有连接到同一个云的动机，从而在处理、等待时间和美元方面最小化云间成本。

其它实施例使用其它DNS解析技术。例如，每次公司计算节点(例如，分支机构、数据中心、移动用户等)需要执行DNS解析时，公司计算节点(例如，分支机构或数据中心处的移动设备或本地DNS解析器)与充当许多实体的权威DNS解析器的DNS服务提供方进行通信。在一些实施例中，这个DNS服务提供方具有位于一个或多个私有数据中心中的DNS解析器，而在其它实施例中，它是一个或多个公共云数据中心的一部分。

为了识别直接连接到互联网的N个受管理转发节点中的哪一个应当被用于到达SaaS提供方服务器，在一些实施例中，虚拟网络(例如，入口MFN或配置该MFN的控制器集群)从N个受管理转发节点中识别一个或多个候选边缘MFN的集合。如以下进一步描述的，在一些实施例中，每个候选边缘MFN是基于准则的集合(诸如到SaaS提供方服务器的距离、网络连接速度、成本、延迟和/或损失、网络计算成本等)被认为是最优的边缘MFN。

为了帮助识别最优边缘点，一些实施例的控制器集群为实体维持最流行的SaaS提供方和消费者web目的地及其IP地址子网的列表。对于每个这样的目的地，控制器集群将最优MFN(同样根据物理距离、网络连接速度、成本、损失和/或延迟、计算成本等进行评判)中的一个或多个指派为候选出口节点。对于每个候选出口MFN，控制器集群然后计算从每个可能的入口MFN到该候选MFN的最佳路由，并相应地在MFN中设置结果产生的下一跳表，使得互联网SaaS提供方或web目的地关联到正确的虚拟网络下一跳节点。

鉴于服务目的地常常可以在若干位置处通过若干IP子网到达(如由权威DNS服务器提供的)，存在若干潜在的出口节点，以最小化等待时间并提供负载平衡。因而，在一些实施例中，控制器集群为每个MFN计算最佳位置和出口节点，并相应地更新下一跳。而且，到达SaaS提供方(例如，office365.com)的最佳出口节点可以是通过一个公共云提供方(例如，Microsoft Azure)，但是单纯从距离或连接速度来看，最佳入口MFN可以是在另一个公共云提供方(例如，AWS)中。在此类情况下，就等待时间、处理和成本而言，离开虚拟网络之前遍历另一个云(即，具有最佳出口MFN的公共云)可能不是最优的。在这种情况下，提供多个候选边缘节点将允许选择最优边缘MFN和到所选择的边缘MFN的最优路径。

为了识别通过虚拟网络到连接到互联网或连接到公司实体的公司计算节点的出口MFN的最优路径，控制器集群识别MFN之间的最优路由路径。如上面所提到的，在一些实施例中，控制器集群通过首先对一对直接连接的MFN之间的每个链路进行成本计算(costing)(例如，基于反映所估计的等待时间和财务成本的加权和的度量得分)来识别任何两个MFN之间的最佳路径。在一些实施例中，等待时间和财务成本包括(1)链路延迟测量、(2)所估计的消息处理等待时间、(3)从特定数据中心或者到同一公共云提供方的另一个数据中心或者离开公共云(PC)提供方的云(例如，到另一个公共云提供方的另一个公共云数据中心或到互联网)的传出(outgoing)流量的云费用，以及(4)所估计的与公共云中的主机计算机上执行的MFN相关联的消息处理成本。

使用这些成对链路的计算出的成本，控制器集群可以通过聚合由路由路径使用的各个成对链路的成本来计算使用这些成对链路中的一个或多个的每条路由路径的成本。如上所述，控制器集群然后基于计算出的路由路径成本来限定其路由图，并基于所限定的路由图来生成MFN的云路由器的转发表。而且，如上面所提到的，控制器集群周期性地(例如，每12小时、24小时等一次)或者在其从MFN的测量代理接收到测量更新时重复执行这些成本计算、图形构建以及转发表更新和分发操作。

每当在MFN CFE C_i处的转发表指向下一跳MFN CFE C_j时，CFE C_i就将C_j视为邻居。在一些实施例中，CFE C_i建立到CFE C_j的安全、主动维持的VPN隧道。在一些实施例中，安全隧道是要求对经封装的数据消息的有效载荷进行加密的隧道。而且，在一些实施例中，隧道通过隧道的一个或两个端点向另一个端点发送保持活动信号而被主动维持。

在其它实施例中，CFE不建立安全、主动维持的VPN隧道。例如，在一些实施例中，CFE之间的隧道是静态隧道，其不通过传输保持活动信号而被主动监视。而且，在一些实施例中，CFE之间的这些隧道不对其有效载荷进行加密。在一些实施例中，CFE对之间的隧道包括两个封装报头，其中内部报头识别租户ID以及用于数据消息进入和离开虚拟网络(即，进入和离开(一个或多个)公共云)的入口和出口CFE，而外部封装报头指定从入口CFE到出口CFE遍历通过零或多个CFE的源和目的地网络地址(例如，IP地址)。

除了内部隧道之外，在一些实施例中，虚拟网络还使用VPN隧道将公司计算节点连接到其边缘MFN，如上面所提到的。因此，在使用安全隧道连接CFE的实施例中，数据消息使用完全安全的VPN路径通过虚拟网络中转(transit)。

当使用虚拟网络内的封装来转发虚拟网络数据消息时，在一些实施例中，虚拟网络使用其自己的独有的网络地址，该网络地址不同于租户的不同私有网络所使用的私有地址。在其它实施例中，虚拟网络使用它被限定在其上的公共云的私有和公共网络地址空间。在还有其它实施例中，对于虚拟网络的一些部件(例如，其MFN、CFE和/或服务中的一些)，该虚拟网络使用其自身独有的网络地址中的一些，而对于该虚拟网络的其它部件，使用公共云的私有和公共网络地址空间。

而且，在一些实施例中，虚拟网络使用具有其自己的专有协议的从头开始通信平台。在数据消息完全通过软件MFN路由器(例如，通过软件CFE)转发的实施例中，虚拟网络可以为长程端到端连接提供优化的速率控制。在一些实施例中，这是通过在每个MFN 150处操作TCP优化代理引擎220来实现的。在不破坏TCP本身(例如，使用HTTPS)的其它实施例中，这是通过代理引擎220使用中间每流缓冲以及TCP接收器窗口和ACK操纵来分割速率控制而实现的。

由于其从头开始性质，在一些实施例中，虚拟网络优化了其许多部件以提供甚至更好的服务。例如，在一些实施例中，虚拟网络使用多路径路由来支持跨虚拟网络进行路由的高级带宽保证的VPN设置。在一些实施例中，类似于ATM/MPLS路由，此类VPN在每个MFN中包括状态数据，并且它们的建立和移除是集中控制的。一些实施例或者通过直接测量每个传出链路的可用带宽(通过分组对或类似过程)或者通过具有针对链路的给定容量并从这个容量中减少已经通过这个链路发送的流量来识别每个传出链路的可用带宽。

一些实施例使用链路的剩余带宽作为约束。例如，当链路不具有至少2Mbps的可用带宽时，一些实施例的控制器集群从用于计算到任何目的地的最低成本路径(例如，最短路径)的链路集合中移除该链路(例如，从路由图(诸如图400)中移除该链路)。如果在移除这个链路之后端到端路由仍然可用，那么新的VPN将跨这个新路由进行路由。VPN移除可以使给定链路恢复可用容量，这进而可以使得这个链路能够被包括在最低成本路径(例如，最短路径)计算中。一些实施例将其它选项用于多路径路由，诸如跨多路径的流量的负载平衡，例如，使用MPTCP(多路径TCP)。

一些实施例通过利用路径并行性和廉价的云链路复制通过虚拟网络内的两个不相交的路径(例如，最大不相交的路径)的从入口MFN到出口MFN的流量来为高级客户提供更好的服务。在这种方法下，最早到达的消息被接受，之后的消息被抛弃。这种方法以增加出口处理复杂性为代价增加了虚拟网络可靠性并减少了延迟。在一些此类实施例中，使用前向纠错(FEC)技术来增加可靠性，同时减少重复流量。由于其从头开始性质，一些实施例的虚拟网络执行其它上层优化，诸如应用层优化(例如，去重和高速缓存操作)和安全性优化(例如，DPI(深度分组检查)、防火墙和加密的添加)。

一些实施例的虚拟网络考虑了与云提供方的协作，以通过使用任播消息传递来进一步改进虚拟网络设置。例如，在一些实施例中，当所有MFN获得相同的外部IP地址时，使用任播连接将任何新的公司计算节点连接到最优边缘节点(例如，最接近的边缘节点)更容易。同样，任何SaaS提供方都可以获得这个IP地址并连接到最优MFN(例如，最接近的MFN)。

如上面所提到的，不同的实施例使用不同类型的VPN连接将公司计算节点(例如，分支和移动设备)连接到建立公司实体的虚拟网络的MFN。一些实施例使用IPsec来设置这些VPN连接。图6图示了一些实施例的IPsec数据消息格式。具体而言，该图图示了公司计算节点处由机器生成的数据消息605的原始格式，以及在数据消息605已被封装之后(例如，公司计算节点或MFN处)的IPsec封装的数据消息610，用于通过IPsec隧道传输(例如，传输到MFN或传输到公司计算节点)。

在这个示例中，利用ESP隧道模式(端口50)设置IPsec隧道。如图所示，在这个示例中通过利用ESP协议标识符替换IP报头中的TCP协议标识符来设置这个模式。ESP报头识别消息615(即，报头620和有效载荷625)的开始。消息615必须由IPsec封装的数据消息的接收者(例如，由MFN的IPsec网关)认证。有效载荷625的开始由消息615的下一字段622的值识别。而且，有效载荷625被加密。这个有效载荷包括原始数据消息605的IP报头、TCP报头和有效载荷，以及包括下一字段622的填充字段630。

在一些实施例中，每个MFN IPsec网关可以为相同或不同的虚拟网络租户(例如，为同一公司或为不同的公司)处置多个IPsec连接。因而，在一些实施例中，MFN IPsec网关(例如，网关230)按照隧道ID、租户ID(TID)和公司计算节点子网来识别每个IPsec连接。在一些实施例中，租户的不同公司节点(例如，不同的分支机构)不具有重叠的IP子网(根据RFC 1579)。在一些实施例中，IPsec网关具有将每个IPsec隧道ID(其包含在IPsec隧道报头中)映射到租户ID的表。对于配置IPsec网关以处置的给定租户，IPsec网关还具有那个租户的所有子网的映射，这些子网连接到由MFN及其云转发元件建立的虚拟网络。

当第一公共云数据中心中的入口第一MFN通过IPsec隧道接收到与租户ID相关联并发往连接到第二公共云数据中心中的出口第二MFN的目的地(例如，分支或数据中心子网或SaaS提供方)的数据消息时，第一MFN的IPsec网关移除IPsec隧道报头。在一些实施例中，第一MFN的CFE然后利用两个封装报头来封装消息，这两个封装报头允许消息直接地或者通过一个或多个其它中间MFN来遍历从入口第一MFN到出口第二MFN的路径。第一MFN的CFE通过使用其控制器配置的路由表来识别这条路径。

如上面所提到的，在一些实施例中，两个封装报头包括(1)外部报头，该外部报头指定下一跳MFN CFE，以允许经封装的数据消息遍历通过虚拟网络的MFN以到达出口MFNCFE，以及(2)内部报头，该内部报头指定租户ID以及识别进入和离开虚拟网络的数据消息的MFN的入口和出口MFN CFE。

具体而言，在一些实施例中，内部封装报头包括有效IP报头，其具有出口第二MFN的CFE的目的地IP地址和入口第一MFN的CFE的源IP地址。这种方法允许在MFN的每个CFE中使用标准IP路由器软件。封装还包括租户ID(例如，客户CID)。当消息到达出口第二MFN的CFE时，它被解封装并由第二MFN发送到其目的地(例如，由第二MFN的IPsec网关经由与消息的租户ID和目的地子网相关联的另一个IPsec隧道发送到目的地)。

某些云提供方禁止机器“欺骗”源IP，和/或对TCP和UDP流量施加其它限制。为了应对此类可能的限制，一些实施例使用外部报头来连接由一条或多条路由使用的相邻对MFN。在一些实施例中，这个报头是指定源和目的地IP地址以及UDP协议参数的UDP报头。在一些实施例中，入口MFN CFE将其IP地址指定为外部报头的源IP地址，而将下一个MFN CFE跳的IP地址指定为外部报头的目的地IP地址。

当到出口MFN的CFE的路径包括一个或多个中间MFN CFE时，中间CFE用其IP地址替换其接收到的双重封装消息的外部报头中的源IP地址。它还使用内部报头中的目的地IP地址在其路由表中执行路由查找，以识别位于到内部报头的目的地IP地址的路径上的下一跳MFN CFE的目的地IP地址。然后，中间CFE将外部报头中的目的地IP地址替换为其通过其路由表查找所识别出的IP地址。

当经双重封装的数据消息到达出口MFN的CFE时，CFE在其检索内部报头中的目的地IP地址并确定这个目的地IP地址属于它时确定该出口MFN是该数据消息的出口节点。然后，这个CFE从数据消息中移除两个封装报头，然后将其发送到目的地(例如，通过其MFN的IPsec网关到达目的地，经由与数据消息的原始报头中的租户ID和目的地IP地址或子网相关联的另一个IPsec隧道)。

图7图示了一些实施例的两个封装报头的示例，而图8给出了图示在一些实施例中如何使用这两个报头的示例。在下面的讨论中，内部报头称为租户报头，因为它包括租户ID以及与租户的公司计算端节点连接的虚拟网络入口/出口节点的身份。外部报头在下文中被称为VN-hop隧道报头，因为当数据消息遍历入口和出口MFN CFE之间的通过虚拟网络的路径时，它用于识别通过虚拟网络的下一跳。

图7示出了VN-hop隧道报头705和租户隧道报头720，其封装了具有原始头755和有效载荷760的原始数据消息750。如图所示，在一些实施例中，VN-hop隧道报头705包括UDP报头710和IP报头715。在一些实施例中，UDP报头是根据UDP协议限定的。在一些实施例中，VN-hop隧道是标准UDP隧道，而在其它实施例中，这个隧道是专有UDP隧道。在还有其它实施例中，这个隧道是标准或专有的TCP隧道。在一些实施例中，隧道报头705是加密其有效载荷的加密的报头，而在其它实施例中，它是未加密的报头。

如以下进一步描述的，在一些实施例中，隧道报头705被用于限定覆盖VNP网络，并且被每个MFN CFE用于在底层公共云网络上到达下一跳MFN CFE。照此，隧道报头705的IP报头715识别由VNP隧道连接的第一和第二相邻MFN的第一和第二CFE的源和目的地IP地址。在一些情况下(例如，当下一跳目的地MFN与源MFN在不同公共云供应方的不同公共云中时)，源IP地址和目的地IP地址是由包括MFN的公共云数据中心使用的公共IP地址。在其它情况下，当源和目的地MFN CFE属于同一个公共云时，源和目的地IP地址可以是仅在公共云中使用的私有IP地址。可替代地，在此类情况下，源和目的地IP地址仍可能是公共云供应方的公共IP地址。

如图7中所示，租户隧道报头720包括IP报头725、租户ID字段730和虚拟电路标签(VCL)735。在入口跳CFE之后由每一跳CFE使用租户隧道报头720来识别下一跳，以将数据消息转发到出口MFN的出口CFE。照此，IP报头725包括作为入口CFE的IP地址的源IP地址和作为出口CFE的IP地址的目的地IP地址。与VN-hop报头705的源和目的地IP地址一样，租户报头720的源和目的地IP地址可以或者是一个公共云提供方的私有IP地址(当数据消息遍历通过仅一个公共云提供方的数据中心的路由时)，或者是一个或多个公共云提供方的公共IP地址(例如，当数据消息遍历通过两个或更多个公共云提供方的数据中心的路由时)。

在一些实施例中，可以通过使用任何标准的软件路由器和IP路由表来路由租户报头720的IP报头。租户ID字段730包含租户ID，该租户ID是独有的租户标识符，其可以在入口和出口MFN处使用以独有地识别租户。在一些实施例中，虚拟网络提供方为作为提供方的租户的不同公司实体限定不同的租户ID。VCL字段735是可选的路由字段，一些实施例使用该字段来提供用于将消息转发通过网络的替代方式(基于非IP的方式)。在一些实施例中，租户隧道报头720是GUE(通用UDP封装)报头。

图8给出了图示在一些实施例中如何使用这两个隧道报头705和710的示例。在这个示例中，数据消息800从公司的第一分支机构805中的第一机器802(例如，第一VM)发送到公司的第二分支机构810中的第二机器804(例如，第二VM)。这两个机器位于两个不同的子网中，这两个不同的子网分别是10.1.0.0和10.2.0.0，其中第一个机器的IP地址为10.1.0.17，而第二个机器的IP地址为10.2.0.22。在这个示例中，第一分支805连接到第一公共云数据中心830中的入口MFN 850，而第二分支810连接到第二公共云数据中心838中的出口MFN 855。而且，在这个示例中，第一和第二公共云数据中心的入口和出口MFN 850和855通过第三公共云数据中心836的中间MFN 857间接连接。

如图所示，来自机器802的数据消息800沿着IPsec隧道870被发送到入口MFN 850，该IPsec隧道870将第一分支机构805连接到入口MFN 850。这个IPsec隧道870在第一分支机构的IPsec网关848和入口MFN 850的IPsec网关852之间建立。通过利用IPsec隧道报头806封装数据消息800来建立这个隧道。

MFN 850的IPsec网关852对数据消息进行解封装(即，移除IPsec隧道报头806)，并将解封装后的消息直接地或通过一个或多个中间体服务机器(例如，通过防火墙机器，诸如图2的机器210)传递给这个MFN的CFE 832。在传递这个消息时，在一些实施例中，MFN 850的IPsec网关或某个其它模块将该消息与IPsec隧道的隧道ID和公司的租户ID相关联。这个租户ID在虚拟网络提供方的记录中识别公司。

基于相关联的租户ID和/或IPsec隧道ID，入口MFN 850的CFE 832识别消息通过虚拟网络到达其目的地机器的子网(即，到达第二分支机构810)的路由，该路由由不同公共云数据中心中的MFC建立。例如，CFE 832使用租户ID和/或IPsec隧道ID来识别公司的路由表。然后，在这个路由表中，CFE 832使用接收到的消息的目的地IP地址10.2.0.22来识别记录，该记录将公共云数据中心838的出口MFN 855的CFE 853识别为用于数据消息800的目的地出口转发节点。在一些实施例中，识别出的记录将第二分支机构810的整个子网10.2.0.0/16映射到MFN 855的CFE 853。

在识别出出口CFE 853之后，入口MFN 850的CFE 832用租户隧道报头860封装接收到的数据消息，该租户隧道报头860在其IP报头725中包括入口CFE 832的源IP和出口CFE853的目的IP。在一些实施例中，这些IP地址在公共IP地址空间中限定。隧道报头860还包括与入口MFN 850处的数据消息相关联的租户ID。如上面所提到的，在一些实施例中，这个隧道报头还包括VCL报头值。

在一些实施例中，入口CFE 832还识别在到出口CFE 853的期望CFE路由路径上的下一跳MFN。在一些实施例中，入口CFE 832通过使用出口CFE 853的目的地IP地址在其路由表中识别这个下一跳CFE。在这个示例中，下一跳MFN CFE是第三公共云数据中心836的第三MFN 857的CFE 856。

在识别出下一跳MFN CFE之后，入口MFN CFE用VN-hop、第二隧道报头862来封装经封装的数据消息800。这个隧道报头允许消息路由到下一跳CFE 856。在这个外部报头862的IP报头715中，入口MFN CFE 832指定源和目的地IP地址作为入口CFE 832的源IP和中间CFE856的目的地IP。在一些实施例中，它还将其层4协议指定为UDP。

当第三MFN 857的CFE 856接收到经双重封装的数据消息时，它移除VN-hop、第二隧道报头862，并且从租户报头860中提取出口MFN 855的CFE 853的目的地IP地址。由于这个IP地址未与CFE 856相关联，因此该数据消息仍必须遍历到另一个MFN以到达其目的地。因而，CFE 856使用提取出的目的地IP地址来识别其路由表中识别下一跳MFN CFE 853的记录。然后，它利用外部报头705改变重新封装数据消息，并在其IP报头715中将源和目的地IP地址指定为其自己的IP地址和MFN CFE 853的目的地IP地址。接下来，CFE 856通过公共云数据中心836和838的介入路由架构将经双重封装的数据消息800转发到出口CFE 853。

在接收到经封装的数据消息之后，当出口CFE 853检索到内部报头860中的目的地IP地址并确定这个目的地IP地址属于它时，出口CFE 853确定经封装的消息是指向它的。出口CFE 853从数据消息800中移除两个封装报头860和862，并在数据消息的原始报头中提取目的地IP地址。这个目的地IP地址识别第二分支机构的子网中的第二机器804的IP地址。

使用移除的租户隧道报头860中的租户ID，出口CFE 853识别要搜索的正确路由表，然后基于从接收到的数据消息的原始报头值中提取出的目的地IP地址来搜索这个路由表。根据这种搜索，出口CFE 853识别记录，该记录识别用于将数据消息转发到其目的地的IPsec连接。然后，它将数据消息以及IPsec连接标识符提供给第二MFN的IPsec网关858，该IPsec网关858再用IPsec隧道报头859封装这个消息并且然后将其转发到第二分支机构810的IPsec网关854。然后，网关854移除IPsec隧道报头，并将数据消息转发到其目的地机器804。

现在将参考图9-图15描述若干更详细的消息处理示例。在这些示例中，假设的是每个租户IPsec接口在同一本地公共IP地址上，VNP隧道同样是这样。照此，在一些实施例中，接口被附接到单个VRF(虚拟路由和转发)命名空间。这个VRF命名空间在下文中被称为VNP命名空间。

图9-图11图示了消息处置过程900-1100，它们在入口、中间和出口MFN接收到在租户的两个不同的外部机器位置(例如，分支机构、数据中心等)的两个计算设备之间发送的消息时分别由该入口、中间和出口MFN执行。在一些实施例中，当每个MFN的CFE是用作用于租户的不同数据消息流的入口、中间和出口CFE的候选时，控制器集群160将每个这样的CFE配置为作为入口、中间和出口CFE操作。

下面将参考图8和图12中的两个示例来解释过程900-1100。如上面所提到的，图8图示了当数据消息经过中间MFN到达出口MFN时的示例。图12图示了不涉及入口和出口MFN之间的中间MFN的示例。具体而言，其图示了当两个分支机构利用两个直接连接的MFN 1250和1255连接到两个公共云数据中心1230和1238时数据消息1200从第一分支机构1205中的第一设备1202发送到第二分支机构1220中的第二设备1210。如图所示，在这些示例中，MFN的CFE 1232和1253执行与每个MFN相关联的路由操作。

在一些实施例中，入口MFN 850和1250的入口CFE(例如，入口CFE 832或1232)执行过程900。如图9中所示，入口过程900开始于基于接收到的数据消息中的IPsec隧道的标识符(例如，806或1206)最初识别(在905处)租户路由上下文。在一些实施例中，IPsec网关或其它MFN模块在映射表中存储针对IPsec隧道ID的租户ID。每当沿着特定IPsec隧道接收到数据消息时，IPsec网关提取IPsec隧道ID，这个网关或另一个MFN模块随后使用这个IPsec隧道ID通过参考其映射表来识别相关联的租户ID。通过识别租户ID，该过程识别租户路由表或VRF命名空间的租户部分以使用。

在910处，该过程递增识别出的IPsec隧道的RX(接收)计数器，以考虑接收到这个数据消息。接下来，在915处，该过程在识别出的租户路由上下文中(例如，在VRF命名空间的租户的部分中)执行路由查找(例如，最长前缀匹配(LPM)查找)以识别离开在公共云数据中心上构建的租户的虚拟网络的出口接口的IP地址。对于分支到分支的示例，出口接口是连接到目的地分支的MFN的出口CFE(例如，CFE 853或1253)的IP地址。

在920处，处理将租户隧道报头(例如，报头860或1260)添加到接收到的数据消息，并且嵌入入口CFE(例如，入口CFE 832或1252)的源IP地址和出口CFE(例如，出口CFE 853或1253)的目的地IP地址作为这个隧道报头中的源IP地址和目的地IP地址。在租户报头中，该过程还将租户ID(在905处识别出的)存储在租户报头中。在920处，该过程在租户报头之外添加VN-hop隧道报头(例如，报头862或1262)，并将其IP地址作为源IP地址存储在这个报头中。该过程还指定(在920处)VNP隧道报头的UDP参数(例如，UDP端口)。

接下来，在925处，该过程递增租户的VN-transmit计数器，以考虑传输这个数据消息。在930处，该过程在识别出的VNP路由上下文中(例如，在VRF命名空间的VNP的部分中)执行路由查找(例如，LPM查找)，以识别这个数据消息的下一跳接口。在一些实施例中，这个路由查找是至少部分地基于出口CFE的目的地IP的LPM查找(例如，在VRF命名空间的VNP的部分中)。

在935处，该过程确定下一跳出口接口是否是入口CFE的本地接口(例如，物理或虚拟端口)。如果是，那么该过程将VN-hop外部隧道报头中的目的地IP地址限定(在937处)为915处识别出的出口接口IP地址。接下来，在940处，该过程将经双重封装的数据消息提供给其本地接口，以便可以将其转发到目的地出口CFE。在940之后，过程900结束。

图12图示了入口CFE 1232从第一分支机构1205的设备1202接收的数据消息1200的操作905-940的示例。如图所示，这个CFE的MFN 1250在其IPsec网关1252处从第一分支机构1205的IPsec网关1248接收这个数据消息作为IPsec封装的消息。入口CFE 1232用VN-hop隧道报头1262和租户隧道报头1260封装接收到的消息1200(在其IPsec报头已被IPsec网关1252移除之后)，并将这个经双重封装的消息转发到公共云1238的MFN 1255的出口CFE1253。如图所示，在这个示例中，两个隧道报头1260和1262的源和目的地IP地址是相同的。鉴于这两个IP地址集合是相同的，一些实施例在数据消息未通过任何中间CFE(诸如CFE856)进行路由时放弃使用外部IP报头1262。

当该过程确定(在935处)下一跳出口接口不是入口CFE的本地接口而是另一个路由器的目的地IP地址时，该过程在VN-hop隧道中报头中嵌入(在945处)下一跳中间CFE(例如，中间CFE856)的目的地IP地址作为VN-hop隧道报头的目的地IP地址。

接下来，在950处，该过程在识别出的VNP路由上下文中(例如，在VRF命名空间的VNP的部分中)执行另一个路由查找(例如，LPM查找)。这次，查找是基于VNP隧道报头中识别出的中间CFE的IP地址。由于中间CFE(例如，CFE 856)是虚拟网络中用于入口CFE(例如，CFE832)的下一跳CFE，因此路由表识别用于被发送到中间CFE的数据消息的本地接口(例如，本地端口)。因此，在VNP路由上下文中的这种查找识别入口CFE将经双重封装的消息提供(在950处)到的本地接口。然后，该过程递增(在955处)VN中间计数器以考虑传输这个数据消息。在955之后，该过程结束。

图10图示了在一些实施例中出口MFN的CFE(例如，CFE853或1253)在接收到应当转发到连接到该MFN的公司计算节点(例如，分支机构、数据中心、远程用户位置)的数据消息时执行的过程1000。如图所示，该过程最初在与虚拟网络相关联的接口上接收(在1005处)数据消息。这个消息用VN-hop隧道报头(例如，报头862或1262)和租户隧道报头(例如，报头860或1260)封装。

在1010处，该过程确定VN-hop隧道报头中的目的地IP地址是其CFE的目的地IP地址(例如，CFE 853或1253的IP地址)。接下来，在1015处，该过程移除两个隧道报头。然后，该过程从被移除的租户隧道报头中检索(在1020处)租户ID。为了考虑接收到的数据消息，CFE然后递增(在1025处)它为由提取出的租户ID指定的租户维持的RX(接收)计数器。

接下来，在1030处，该过程在识别出的租户路由上下文中(即，在由在2020处提取出的租户ID识别出的租户的路由上下文中)执行路由查找(例如，LPM查找)以识别用于这个数据消息的下一跳接口。在一些实施例中，该过程基于接收到的数据消息的原始报头(例如，报头755)中的目的地IP地址来执行这个查找。从通过这种查找识别出的记录中，过程1000识别IPsec接口，数据消息必须通过该IPsec接口发送到其目的地。因而，过程1000将解封装的接收到的数据消息发送到其MFN的IPsec网关(例如，网关858或1258)。

然后，这个网关用IPsec隧道报头(例如，隧道报头859或1259)封装数据消息，并将其转发到目的地公司计算节点(例如，目的地分支机构)中的网关(例如，网关854或1254)，然后将其解封装并转发到其目的地。在1030之后，CFE或其MFN递增(在1035处)它维持的计数器，以沿着IPsec连接向目的地公司计算节点(例如，网关854和858之间或网关1254和1258之间的IPsec连接)传输消息。

图11图示了在一些实施例中，中间MFN的CFE(例如，CFE856)在其接收到应当被转发到另一个MFN的另一个CFE的数据消息时执行的过程1100。如图所示，该过程最初在与虚拟网络相关联的接口上接收(在1105处)数据消息。在一些实施例中，这个消息用两个隧道报头(即，VN隧道报头(例如，报头862)和租户隧道报头(例如，报头860))进行封装。

在1110处，该过程终止VN-hop隧道，因为它确定这个隧道报头中的目的地IP地址是其CFE的目的地IP地址(例如，是CFE856的目的地IP地址)。接下来，在1115处，该过程确定VN-hop隧道报头是否指定正确的UDP端口。如果不是，那么该过程结束。否则，在1120处，该过程移除VN-hop隧道报头。为了考虑接收到的数据消息，CFE然后递增(在1125处)它维持的RX(接收)计数器，以量化其作为中间跳CFE已经接收到的消息的数量。

在1130处，该过程在识别出的VNP路由上下文中(例如，在VRF命名空间的VNP的部分中)执行路由查找(例如，LPM查找)，以识别用于这个数据消息的下一跳接口。在一些实施例中，这个路由查找是至少部分地基于在内部租户隧道报头中识别出的出口CFE的目的地IP的LPM查找(例如，在VRF命名空间的VNP的部分中)。

然后，该过程确定(在1135处)下一跳出口接口是否是中间CFE的本地接口。如果是，那么该过程将VN-hop隧道报头添加(在1140处)到已用租户隧道报头封装的数据消息。该过程将VN-hop隧道报头中的目的地IP地址设置(在1142处)为在租户隧道报头中指定的出口CFE的目的地IP地址。该过程还将VN-hop隧道报头中的源IP地址设置(在1142处)为其CFE的IP地址。在这个隧道报头中，该过程还设置UDP属性(例如，UDP端口等)。

接下来，在1144处，该过程将经双重封装的数据消息提供给其本地接口(在1130处识别出的)，以便可以将其转发到目的地出口CFE。上面参考图8中的CFE 856的操作描述了这种VN-hop隧道解封装和转发的示例。为了考虑接收到的数据消息，CFE然后递增(在1146处)它维持的TX(传输)计数器，以量化它作为中间跳CFE已传输的消息的数量。在1146之后，过程1100结束。

另一方面，当该过程确定(在1135处)下一跳出口接口不是其CFE的本地接口而是另一个路由器的目的地IP地址时，该过程将VN-hop隧道报头添加(在1150处)到它先前从中移除了VN-hop隧道报头的数据消息。在新的VN-hop隧道报头中，过程1100嵌入(在1150处)其CFE的源IP地址和下一跳中间CFE的目的地IP地址(在1130处识别出的)作为VN-hop隧道报头的源和目的地IP地址。这个VNP隧道报头还指定了具有UDP目的地端口的UDP层4协议。

接下来，在1155处，该过程在识别出的VNP路由上下文中(例如，在VRF命名空间的VNP的部分中)执行另一个路由查找(例如，LPM查找)。这次，查找是基于新VN-hop隧道报头中识别出的下一跳中间CFE的IP地址。由于这个中间CFE是虚拟网络中当前中间CFE的下一跳，因此路由表识别用于发送到下一跳中间CFE的数据消息的本地接口。因此，VNP路由上下文中的这个查找识别当前中间CFE将经双重封装的消息提供到的本地接口。然后，该过程递增(在1160处)VN中间TX(传输)计数器，以考虑传输这个数据消息。在1160之后，该过程结束。

图13图示了当入口MFN接收到从租户的公司计算设备(例如，在分支机构中)发送到另一个租户机器(例如，在另一个分支机构、租户数据中心或SaaS提供方数据中心中)的针对租户的消息时由入口MFN的CFE执行的消息处置过程1300。如下面进一步描述的，图9的过程900是这个过程1300的子集。如图13中所示，过程1300开始于基于传入IPsec隧道的标识符而初始识别(在905处)租户路由上下文。

在1310处，该过程确定接收到的数据消息的报头中的源和目的地IP地址是否均为公共IP地址。如果是，那么该过程(在1315处)丢弃(drop)该数据消息，并递增其为接收到的数据消息的IPsec隧道维持的丢弃计数器。在1315处，该过程丢弃计数器，因为当它通过租户的IPsec隧道接收到消息时，它不应当正在接收寻址到公共IP地址和从公共IP地址寻址的消息。在一些实施例中，过程1300还将ICMP错误消息发送回源公司计算机器。

另一方面，当该过程确定(在1310处)数据消息不是来自公共IP地址和去往另一个公共IP地址时，该过程确定(在1320处)接收到的数据消息的报头中的目的地IP地址是否是公共IP地址。如果是，那么，除了在过程1300的开始已经执行的操作905之外，该过程转变到1325以执行图9的过程900。在1325之后，过程1300结束。另一方面，当过程1300确定(在1320处)接收到的数据消息的报头中的目的地IP地址不是公共IP地址时，该过程递增(在1330处)识别出的IPsec隧道的RX(接收)计数器，以考虑接收到这个数据消息。

然后，过程1300在识别出的租户路由上下文中(例如，在VRF命名空间的租户的部分中)执行(在1335处)路由查找(例如，LPM查找)。这个查找识别用于离开在公共云数据中心上构建的租户虚拟网络的出口接口的IP地址。在图13所示的示例中，当数据消息旨在针对SaaS提供方数据中心中的机器时，过程1300到达查找操作1335。因此，这个查找识别用于离开租户的虚拟网络以到达SaaS提供方机器的出口路由器的IP地址。在一些实施例中，所有SaaS提供方路由都被安装在一个路由表中或VRF命名空间的一个部分中，而在其它实施例中，用于不同SaaS提供方的路由被存储在不同的路由表或不同的VRF命名空间部分中。

在1340处，该过程将租户隧道报头添加到接收到的数据消息，并嵌入入口CFE的源IP地址和出口路由器的目的地IP地址作为这个隧道报头中的源和目的地IP地址。接下来，在1345处，该过程为租户递增VN-transmit计数器，以考虑传输这个数据消息。在1350处，该过程在VNP路由上下文中(例如，在VRF命名空间的VNP的部分中)执行路由查找(例如，LPM查找)以将其本地接口之一识别为用于这个数据消息的下一跳接口。当下一跳是另一个CFE(例如，在其它公共云数据中心中)时，在一些实施例中，该过程还用VN-hop报头封装数据消息，并且嵌入其CFE的IP地址和另一个CFE的IP地址作为VN-hop报头的源和目的地地址。在1355处，该过程将经封装的数据消息提供给其识别出的本地接口，以便可以将数据消息转发到其出口路由器。在1355之后，过程1300结束。

在一些情况下，入口MFN可以接收其CFE可以直接转发到数据消息的目的地机器而无需通过另一个MFN的CFE的针对租户的数据消息。在一些此类情况下，当CFE不需要将任何特定于租户的信息中继到任何其它后续VN处理模块或者所需的信息可以通过其它机制提供给后续的VN处理模块时，不需要用租户报头或VN-hop报头封装数据消息。

例如，为了将租户的数据消息直接转发到外部SaaS提供方数据中心，入口MFN的NAT引擎215将必须基于租户标识符执行NAT操作，如下面进一步描述的。入口CFE或入口MFN中的另一个模块必须将租户标识符提供给入口MFN的相关联NAT引擎215。当入口CFE和NAT引擎在同一个计算机上执行时，一些实施例通过将其存储在共享存储器位置中来在这两个模块之间共享这个信息。另一方面，当CFE和NAT引擎不在同一个计算机上执行时，一些实施例使用其它机制(例如，带外通信)在入口CFE和NAT引擎之间共享租户ID。但是，在此类情况下，其它实施例使用封装报头(即，使用带内通信)在入口MFN的不同模块之间存储和共享租户ID。

如以下进一步描述的，一些实施例在将消息发送到租户的虚拟网络之外之前对数据消息的源IP/端口地址执行一个或两个源NAT操作。图14图示了在出口路由器处执行的NAT操作。但是，如下面进一步描述的，即使以上没有参考图13描述这个额外的NAT操作，一些实施例也在入口路由器处对数据消息执行另一个NAT操作。

图14图示了在一些实施例中出口路由器在接收到应当通过互联网转发到SaaS提供方数据中心的数据消息时执行的过程1400。如图所示，该过程最初在与虚拟网络相关联的接口上接收(在1405处)数据消息。这个消息用租户隧道报头进行封装。

在1410处，该过程确定这个隧道报头中的目的地IP地址是其路由器的目的地IP地址，并且此后它移除租户隧道报头。然后，该过程从被移除的隧道报头中检索(在1415处)租户ID。为了考虑接收到的数据消息，该过程递增(在1420处)它为由提取出的租户ID指定的租户维持的RX(接收)计数器。

接下来，在1425处，该过程确定数据消息的原始报头中的目的地IP是否是可通过出口路由器的本地接口(例如，本地端口)到达的公共IP。这个本地接口是不与VNP隧道相关联的接口。如果不是，那么该过程结束。否则，该过程执行(在1430处)源NAT操作，以改变这个消息的报头中的数据消息的源IP/端口地址。NAT操作及执行它的原因将在下面参考图16和图17进一步描述。

在1430之后，该过程在互联网路由上下文中(即，在路由数据的互联网路由部分中，例如路由器的互联网VRF命名空间)中执行(在1435处)路由查找(例如，LPM查找)，以识别用于这个数据消息的下一跳接口。在一些实施例中，该过程基于接收到的数据消息的原始报头的目的网络地址(例如，目的地IP地址)执行这个查找。从通过这个查找识别出的记录中，过程1400识别数据消息被发送到其目的地所必须通过的本地接口。因而，在1435处，过程1400将源网络地址翻译的数据消息提供给其识别出的本地接口，用于转发到其目的地。在1435之后，该过程递增(在1440处)其维持的用于将消息传输到SaaS提供方的计数器，并且然后结束。

图15图示了由入口路由器执行的消息处置过程1500，该入口路由器接收从SaaS提供方机器发送到租户机器的消息。如图所示，入口过程1500开始于首先在具有用于若干或全部SaaS提供方通信的公共IP地址的专用输入接口上接收(在1505处)数据消息。在一些实施例中，这个输入接口是具有与用于与虚拟网络进行通信的IP地址不同的IP地址的不同接口。

在接收到消息之后，该过程通过使用包含在接收到的数据消息的报头中的目的地IP地址在公共互联网路由上下文中执行(在1510处)路由查找。基于这个查找，该过程确定(在1515处)目的地IP地址是否是本地的并且与使能的NAT操作相关联。如果不是，那么该过程结束。否则，该过程递增(在1520处)互联网RX(接收)计数器，以考虑接收到数据消息。

接下来，在1525处，该过程执行反向NAT操作，该反向NAT操作将数据消息的目的地IP/端口地址翻译成新目的地IP/端口地址，虚拟网络使该新目的地IP/端口地址与特定租户相关联。这个NAT操作还产生租户ID(例如，从使租户ID与翻译的目的地IP相关联的映射表中检索租户ID，或者从用于获取新目的地IP/端口地址的同一映射表中检索租户ID)。在一些实施例中，过程1500使用过程1400在其执行(在1430处)其SNAT操作时创建的连接记录来执行(在1525处)其反向NAT操作。这个连接记录包含由SNAT和DNAT操作使用的内部和外部IP/端口地址之间的映射。

基于翻译的目的地网络地址，该过程然后在识别出的租户路由上下文(即，由租户ID指定的路由上下文)中执行(在1530处)路由查找(例如，LPM查找)，以识别用于离开租户的虚拟网络并到达公司计算节点中(例如，分支机构中)租户的机器的出口接口的IP地址。在一些实施例中，这个出口接口是出口MFN的出口CFE的IP地址。在1530处，该过程将租户隧道报头添加到接收到的数据消息，并嵌入入口路由器的IP地址和出口CFE的IP地址作为这个隧道报头中的源和目的地IP地址。接下来，在1535处，该过程为租户递增VN-transmit计数器，以考虑传输这个数据消息。

在1540处，该过程在识别出的VNP路由上下文中(例如，在路由数据的VNP的部分中，诸如在路由器的VRF命名空间中)执行路由查找(例如，LPM查找)，以识别其本地接口(例如，其物理或虚拟端口)，入口路由器向该本地接口提供经封装的消息提供到的。然后，该过程向接收到的数据消息添加(在1540处)VN-hop报头，并嵌入入口路由器的IP地址和下一跳CFE的IP地址作为这个VN-hop报头的源和目的地IP地址。在1555之后，该过程结束。

如上面所提到的，在一些实施例中，MFN包括NAT引擎215，该NAT引擎215在进出虚拟网络的数据消息的入口和/或出口路径上执行NAT操作。如今，NAT操作通常在许多上下文中并且由许多设备(例如，路由器、防火墙等)执行。例如，通常在流量离开私有网络时执行NAT操作，以将内部IP地址空间与在互联网中使用的受调节的公共IP地址空间隔离开。NAT操作通常将一个IP地址映射到另一个IP地址。

随着连接到互联网的计算机的激增，挑战在于计算机的数量将超过IP地址的可用数量。遗憾的是，即使有4294967296个可能的独有地址，为每个计算机指派独有的公共IP地址也已经不切实际。解决方式之一是将公共IP地址仅指派给私有网络的边缘点处的路由器，而网络内部的其它设备获得仅在其内部私有网络中独有的地址。当设备想要与在其内部私有网络之外的设备进行通信时，其流量通常通过互联网网关，该互联网网关执行NAT操作，以将这个流量的源IP替换为该互联网网关的公共源IP地址。

虽然私有网络的互联网网关在互联网上获得经注册的公共地址，但是连接到该网关的私有网络内部的每个设备接收未注册的私有地址。内部私有网络的私有地址可以在任何IP地址范围内。但是，互联网工程任务组(IETF)已建议用于私有网络的若干私有地址范围以供使用。这些范围一般在公共互联网上不可用，因此路由器可以容易地区分私有地址与公共地址。这些私有地址范围被称为RFC 1918，并且是：(1)A类10.0.0.0-10.255.255.255，(2)B类172.16.0.0-172.31.255.255，和(3)C类192.168.0.0-192.168.255.255。

重要的是对离开私有网络的数据消息流执行源IP翻译，以便外部设备可以区分不同私有网络内使用相同内部IP地址的不同设备。当外部设备必须将回复消息发送到在私有网络内部的设备时，外部设备必须将其回复发送到互联网上独有且可路由的公共地址。它无法使用可能由众多私有网络中的众多设备使用的内部设备的原始IP地址。外部设备将其回复发送到公共IP地址，原始NAT操作用该公共IP地址替换内部设备的私有源IP地址。在接收到这个回复消息之后，私有网络(例如，网络的网关)执行另一个NAT操作，以将回复中的公共目的地IP地址替换为内部设备的IP地址。

在私有网络内部的许多设备以及在这些设备上执行的许多应用必须共享一个或有限数量的与私有网络相关联的公共IP地址。因而，NAT操作通常还翻译层4端口地址(例如，UDP地址、TCP地址、RTP地址等)，以能够使外部消息流与在不同的内部机器和/或这些机器上的不同应用上开始或终止的内部消息流独有地相关联。NAT操作还常常是有状态操作，因为在许多上下文中，这些操作需要跟踪连接并动态地处置表、消息重组、超时、强制终止到期的被跟踪连接等。

如上面所提到的，一些实施例的虚拟网络提供方在多个公共云上将虚拟网络作为服务提供给不同的租户。这些租户可能在其私有网络中使用共用的IP地址，并且它们共享虚拟网络提供方的网络资源的共用的集合(例如，公共IP地址)。在一些实施例中，不同租户的数据流量通过隧道在覆盖网络的CFE之间托管，并且该隧道用独有的租户ID来标记每个消息。这些租户标识符允许将消息发送回源设备，即使当私有租户IP空间重叠时也是如此。例如，租户标识符允许从源地址为10.5.12.1的租户17的分支机构发送到Amazon.com的消息与从具有相同源地址(并且甚至具有相同的源端口号55331)的租户235的分支机构发送到Amazon.com的消息区分开。

根据RFC 1631实现的标准NAT不支持租用的概念，因此无法区分具有相同私有IP地址的两个消息。但是，在一些实施例的许多虚拟网络部署中，使用标准的NAT引擎是有益的，因为当今存在许多成熟的开源的高性能实施方式。实际上，当今许多Linux内核都具有运行的NAT引擎作为标准特征。

为了对租户虚拟网络的不同租户使用标准NAT引擎，一些实施例的虚拟网络提供方在使用标准NAT引擎之前使用租户映射(TM)引擎。图16图示了此类TM引擎1605，该TM引擎1605被放置在虚拟网络到互联网的出口路径上的每个虚拟网络网关1602中。如图所示，每个TM引擎1605在通过互联网1625到SaaS提供方数据中心1620的消息出口路径上被放置在NAT引擎1610之前。在一些实施例中，MFN的每个NAT引擎215包括TM引擎(如TM引擎1605)和标准NAT引擎(如NAT引擎1610)。

在图16所示的示例中，消息流来自两个虚拟网络租户的两个分支机构1655和1660及数据中心1665，并且通过相同的入口网关1670进入虚拟网络1600，但是情况不一定是这样。在一些实施例中，虚拟网络1600是在多个公共云供应方的多个公共云数据中心上限定的。在一些实施例中，虚拟网络网关是受管理转发节点的一部分，并且TM引擎在出口MFN中被放置在NAT引擎1610之前。

当数据消息到达出口网关1602以在其通往SaaS提供方数据中心1620的路上离开虚拟网络时，每个TM引擎1605将这些数据消息的源网络地址(例如，源IP和/或端口地址)映射到新的源网络地址(例如，源IP和/或端口地址)，并且NAT引擎1610将新的源网络地址又映射到另一个源网络地址(例如，另一个源IP和/或端口地址)。在一些实施例中，TM引擎是无状态元件并且通过静态表为每个消息执行映射，而无需查看任何动态数据结构。作为无状态元件，TM引擎在其处理数据消息流的第一数据消息时不创建连接记录，以便在执行其地址映射以处理数据消息流的后续消息时使用这个连接记录。

另一方面，在一些实施例中，NAT引擎1605是有状态元件，其通过参考存储反映其先前SNAT映射的连接记录的连接存储装置来执行其映射。当NAT引擎接收到数据消息时，在一些实施例中，这个引擎首先检查其连接存储装置，以确定其先前是否为接收到的消息的流创建了连接记录。如果是，那么NAT引擎使用这个记录中包含的映射来执行其SNAT操作。否则，它基于准则集合来执行SNAT操作，其使用该准则集合为新的数据消息流导出新的地址映射。为此，在一些实施例中，NAT引擎使用共用的网络地址翻译技术。

在一些实施例中，当NAT引擎从SaaS提供方机器接收到回复数据消息时，在一些实施例中该NAT引擎还可以使用连接存储装置，以便执行DNAT操作以将回复数据消息转发到发送了原始消息的租户机器。在一些实施例中，用于每个经处理的数据消息流的连接记录具有包括该流的标识符的记录标识符(例如，具有翻译的源网络地址的五个元组标识符)。

在进行映射时，TM引擎确保来自使用相同源IP和端口地址的不同租户的数据消息流被映射到独有的非重叠地址空间。对于每个消息，TM引擎识别租户ID并基于这个标识符执行其地址映射。在一些实施例中，TM引擎将不同租户的源IP地址映射到不同的IP范围，使得来自不同租户的任何两个消息将不被映射到相同的IP地址。

因此，具有不同租户ID的每个网络类型将映射到IP地址的完整2³²区域(0.0.0.0-255.255.255.255)内的独有的地址。A类和B类网络的可能IP地址是C类网络的256倍和16倍。根据A、B和C类网络的尺寸比例，可以按以下方式分配256个A类网络：(1)240，以映射240个具有A类网络的租户，(2)15，以映射240个具有B类网络的租户，以及(3)单个A类网络，以映射240个具有C类网络的租户。更具体而言，在一些实施例中，最低范围的A类网络(以0.x.x.x/24开始，1.x.x.x/24...，直到239.x.x.x/24)将被用于将来自10.x A类网络的地址映射到240个不同的目标A类网络。接下来的15个A类网络240.x.x.x/24至254.x.x.x/24各自将被用于各自包括16个B类网络(例如，总共240个网络(15*16))。最后一个A类网络255.x.x.x/24将被用于包括至多256个私有C类网络。即使可以容纳256个租户，也只使用240个，并且不使用16个C类网络。总而言之，一些实施例使用以下映射：

·10.x.x.x/24网络→1.x.x.x/24-239.x.x.x/24，导致每个租户有240个不同的映射；

·172.16-31.x.x/12网络→240x.x.x/24-254.x.x.x/24，导致每个租户有240个不同的映射；

·192.168.x.x/16→255.x.x.x/24网络，导致每个租户有256个可能的映射中的240个。

假设事先不知道租户将使用什么类型的网络类别，上述方案可以支持至多240个租户。在一些实施例中，公共云网络使用私有IP地址。在这种情况下，期望不再次映射到私有地址空间中。由于一些实施例移除了A类网络和B类网络，因此在这些实施例中仅可以支持239个不同的租户。为了实现独有的映射，一些实施例将所有租户ID从1编号到239，然后以240为模，将私有域的未掩码部分的最低有效8位添加到租户ID(以8位表述)。在这种情况下，对于A类地址，第一个租户(编号1)将被映射到11.xx.xx.xx/24，并且最后一个租户(编号239)将被映射到9.xx.xx.xx/24。

在图16所示的实施方式中，一些实施例向每个TM引擎1605提供任何潜在的租户ID子网，以及将消息路由回到每个这种子网中任何具体IP地址的方式。当添加或移除租户、分支机构和移动设备时，这个信息可以动态改变。因此，这个信息必须被动态地分发到虚拟网络的互联网出口网关中的TM引擎。由于虚拟网络提供方的出口互联网网关可能被大量租户使用，因此分发和定期更新的信息的量可以是大的。而且，租户的ID的240(或239)的限制是全局限制，并且只能通过将多个IP地址添加到出口点来解决。

图17图示了在一些实施例中使用的双NAT方法，而不是图16中所示的单NAT方法。图17中所示的方法要求将更少租户数据分发到大多数(如果不是全部)TM引擎并允许更多私有租户网络被映射到虚拟网络提供方的内部网络。对于从租户机器遍历通过虚拟网络1700并且然后通过互联网1625到达另一个机器(例如，到达SaaS提供方数据中心1620中的机器)的数据消息流，图17中所示的方法将NAT引擎放置在进入虚拟网络的数据消息流的入口网关1770处和离开虚拟网络并进入互联网1625的这个流的出口网关1702或1704处。这种方法还将TM引擎1705放置在入口网关1770的NAT引擎1712之前。

在图17所示的示例中，消息流来自两个虚拟网络租户的两个分支机构1755和1760及数据中心1765，并且通过相同的入口网关1770进入虚拟网络1700，但是情况不一定是这样。如虚拟网络1600，在一些实施例中，虚拟网络1700被限定在多个公共云供应方的多个公共云数据中心上。而且，在一些实施例中，虚拟网络网关1702、1704和1770是受管理转发节点的一部分，并且在这些实施例中，TM引擎被放置在这些MFN中的NAT引擎215之前。

TM引擎1605和1705在图16和图17中类似地操作。如TM引擎1605，当数据消息去往SaaS提供方数据中心1620(即，具有针对其的目的地IP地址)时，TM引擎1705将进入虚拟网络的数据消息的源IP和端口地址映射到新的源IP和端口地址。对于每个这样的数据消息，TM引擎1705识别租户ID，并基于这个标识符执行其地址映射。

如TM引擎1605，在一些实施例中，TM引擎1705是无状态元件，并且通过静态表为每个消息执行映射，而无需查看任何动态数据结构。作为无状态元件，TM引擎在其处理数据消息流的第一个数据消息时不创建连接记录，以便在执行其地址映射以处理数据消息流的后续消息时使用这个连接记录。

在进行其映射时，入口网关1770中的TM引擎1705确保来自使用相同源IP和端口地址的不同租户的数据消息流被映射到独有的非重叠地址空间。在一些实施例中，TM引擎将不同租户的源IP地址映射到不同的IP范围，使得来自不同租户的任何两个消息将不被映射到相同的IP地址。在其它实施例中，TM引擎1705可能将两个不同租户的源IP地址映射到相同的源IP范围但不同的源端口范围。在还有其它实施例中，TM引擎将两个租户映射到不同的源IP范围，而将另外两个租户映射到相同的源IP范围但不同的源端口范围。

与TM引擎1605不同，虚拟网络入口网关处的TM引擎1705只需要识别连接到入口网关的分支机构、公司数据中心和公司计算节点的租户。这显著减少了最初需要供应给每个TM引擎并为每个TM引擎周期性更新的租户数据。而且，像前面一样，每个TM引擎只能将239/240个租户映射到独有的地址空间。但是，由于TM引擎被放置在虚拟网络提供方的入口网关处，因此TM引擎各自可以独有地映射239/240个租户。

在一些实施例中，入口网关1770的NAT引擎1712可以使用或者外部公共IP地址或特定于入口网关1770所驻留的公共云(例如，AWS、GCP或Azure)的内部IP地址。在任一种情况下，NAT引擎1712将传入的消息(即，进入虚拟网络1700的消息)的源网络地址映射到其入口网关的私有云网络内独有的IP地址。在一些实施例中，NAT引擎1712将每个租户的数据消息流的源IP地址翻译成不同的独有IP地址。但是，在其它实施例中，NAT引擎1712将不同租户的数据消息流的源IP地址翻译成相同的IP地址，但使用源端口地址来区分不同租户的数据消息流。在还有其它实施例中，NAT引擎将两个租户的源IP地址映射到不同的源IP范围，而将另外两个租户的源IP地址映射到相同的源IP范围但不同的源端口范围。

在一些实施例中，NAT引擎1712是有状态元件，其通过参考存储反映其先前SNAT映射的连接记录的连接存储装置来执行其映射。在一些实施例中，当NAT引擎从SaaS提供方机器接收到回复数据消息时，在一些实施例中NAT引擎还可以使用连接存储装置，以便执行DNAT操作以将回复数据消息转发到发送了原始消息的租户机器。在一些实施例中，TM和NAT引擎1705、1710和1712由控制器集群160配置(例如，提供有用于描述要用于不同租户和网络地址空间的不同范围的映射的表)。

图18给出了图示入口NAT引擎1712的源端口翻译的示例。具体而言，其图示出了当数据消息1800通过入口网关1770进入虚拟网络1700和当其在出口网关1702处离开虚拟网络时租约映射引擎1705和入口NAT引擎1712对该数据消息1800执行的源地址映射。如图所示，租户网关1810发送数据消息1800，该数据消息1800到达具有源IP地址10.1.1.13和源端口地址4432的IPsec网关1805。在一些实施例中，这些源地址是由租户机器(未示出)使用的地址，而在其它实施例中，这些源地址中的一个或两个是由租户网关或租户数据中心中的另一个网络元件执行的源NAT操作产生的源地址。

在这个消息已被IPsec网关1805处理之后，这个网关或入口MFN的另一个模块将这个消息与租户ID 15相关联，该租户ID识别消息1800所属的虚拟网络租户。如图所示，基于这个租户ID，租户映射引擎1705然后将源IP和端口地址映射到源IP和端口地址对15.1.1.13和253。这个源IP和端口地址独有地识别数据消息1800的消息流。在一些实施例中，TM引擎1705以无状态方式(即，不参考连接跟踪记录)执行这个映射。在其它实施例中，TM引擎以有状态的方式执行这个映射。

入口NAT引擎1712接下来(1)将数据消息1800的源IP地址翻译成独有的私有或公共(内部或外部)IP地址198.15.4.33，以及(2)将这个消息的源端口地址翻译成端口地址714。在一些实施例中，虚拟网络将这个IP地址用于相同或不同租户的其它数据消息流。因此，在这些实施例中，NAT引擎1712的源网络地址翻译(SNAT)操作使用源端口地址来区分在虚拟网络内使用相同IP地址的不同租户的不同消息流。

在一些实施例中，由入口NAT引擎的SNAT操作指派的源端口地址也是被用于区分在虚拟网络1700外部的不同消息流的源端口地址。在图18所示的示例中就是这种情况。如图所示，这个示例中的出口NAT引擎1710在其执行其SNAT操作时不改变数据消息的源端口地址。代替地，它只是将源IP地址改变为外部IP地址198.15.7.125，在一些实施例中，该外部IP地址198.15.7.125是虚拟网络的(一个或多个)出口网关的公共IP地址。在一些实施例中，这个公共IP地址也是入口和出口网关1770和1702在其中操作的公共云数据中心的IP地址。

利用源IP 198.15.7.125和端口地址714，数据消息被路由通过互联网以到达SaaS提供方的数据中心的网关1815。在这个数据中心中，SaaS提供方机器基于这个消息执行操作并发送回回复消息1900，下面将参考图19描述其处理。在一些实施例中，SaaS提供方机器基于通过参考源IP 198.15.7.125和端口地址714限定的一个或多个服务规则来对数据消息执行一个或多个服务操作(例如，中间体服务操作，诸如防火墙操作、IDS操作、IPS操作等)。在这些实施例中的一些当中，用于不同租户的不同服务规则可以在规则标识符中指定相同的源IP地址(例如，198.15.7.125)，同时在这些规则标识符中指定不同的源端口地址。规则标识符指定属性集，用于在执行识别与数据消息匹配的规则的查找操作时与数据消息流属性进行比较。

图19图示了SaaS机器(未示出)响应于其对数据消息1800的处理而发送的回复消息1900的处理。在一些实施例中，回复消息1900可以与原始数据消息1800相同，它可以是原始数据消息1800的经修改的版本，或者它可以是全新的数据消息。如图所示，SaaS网关1815基于目的地IP 198.15.7.125和端口地址714发送消息1900，该目的地IP 198.15.7.125和端口地址714是这个消息到达SaaS网关1815时数据消息1800的源IP和端口地址。

在虚拟网络的网关(未示出)处接收消息1900，并且这个网关将数据消息提供给NAT引擎1710，该NAT引擎1710在将消息1800发送到SaaS提供方之前对这个消息执行最后的SNAT操作。虽然在图19所示的示例中数据消息1900是在执行最后一个SNAT操作的同一个NAT引擎1710处接收的，但是不必在每种部署中都如此。

NAT引擎1710(现在充当入口NAT引擎)对数据消息1900执行DNAT(目的地NAT)操作。这个操作将外部目的地IP地址198.15.7.125改变为目的地IP地址198.15.4.33，虚拟网络使用该目的地IP地址198.15.4.33通过公共云路由架构并在虚拟网络部件之间转发数据消息1900。同样，在一些实施例中，IP地址198.15.4.33可以是公共或私有IP地址。

如图所示，在NAT引擎1710翻译其目的地IP地址之后，NAT引擎1712(现在充当出口NAT引擎)接收消息1900。NAT引擎1712然后对这个消息1900执行第二DNAT操作，该第二DNAT操作将其目的地IP和端口地址替换为15.1.1.13和253。这些地址是TM引擎1705识别出的地址。TM引擎1705将这些地址替换为目的地IP 10.1.1.13和端口地址4432，将数据消息1900与租户ID 15相关联，并将具有这个租户ID的消息1900提供给IPsec网关1805以转发到租户网关1810。

在一些实施例中，虚拟网络提供方使用上述处理、系统和部件来在相同或不同的公共云提供方的多个公共云上为多个不同租户提供多个虚拟WAN(例如，多个公司的多个不同公司WAN)。图20给出了示例，该示例示出了在一个或多个公共云提供方的N个公共云2005中具有网络基础设施和(一个或多个)控制器集群2010的虚拟网络提供方的M个租户的M个虚拟公司WAN 2015。

每个租户的虚拟WAN 2015可以跨越所有N个公共云2005或这些公共云的子集。每个租户的虚拟WAN 2015连接一个或多个分支机构2020、数据中心2025、SaaS提供方数据中心2030和租户的远程设备。在一些实施例中，每个租户的虚拟WAN跨越VNP的控制器集群认为对于在租户的不同计算节点2020-2035之间高效转发数据消息所必需的任何公共云2005。在选择公共云时，在一些实施例中，控制器集群还考虑租户选择的公共云和/或租户(或租户的至少一个SaaS提供方)在其中具有一个或多个机器的公共云。

每个租户的虚拟WAN 2015允许租户的远程设备2035(例如，移动设备或远程计算机)避免在任何分支机构或租户数据中心处与租户的WAN网关进行交互以便访问SaaS提供方服务(即，访问SaaS提供方机器或机器集群)。在一些实施例中，通过将这些WAN网关(例如，WAN安全网关)的功能移至虚拟WAN所跨越的公共云中的一个或多个机器，租户的虚拟WAN允许远程设备避开分支机构和租户数据中心处的WAN网关。

例如，为了允许远程设备访问租户或其SaaS提供方服务的计算资源，在一些实施例中，WAN网关必须施行防火墙规则，该防火墙规则控制远程设备如何可以访问租户的计算机资源或其SaaS提供方服务。为了避开租户的分支机构或数据中心WAN网关，租户的防火墙引擎210被放置在由租户的虚拟WAN跨越的一个或多个公共云中的虚拟网络MFN中。

这些MFN中的防火墙引擎210对来自和去往远程设备的数据消息流执行防火墙服务操作。通过在部署在一个或多个公共云上的虚拟网络中执行这些操作，与租户的远程设备相关联的数据消息流量无需不必要地通过租户的(一个或多个)数据中心或分支机构进行路由以便接收防火墙规则处理。这减轻了租户数据中心和分支机构中的流量拥塞，并避免了在这些位置处消耗昂贵的入口/出口网络带宽来处理不去往这些位置处的计算资源的流量。由于这种方法允许在数据消息流遍历到它们的目的地(例如，在它们的入口MFN、出口MFN或中间跳MFN处)时在虚拟网络内进行介入式防火墙规则处理，因此它还有助于加快来自和去往远程设备的数据消息流量的转发。

在一些实施例中，MFN的防火墙施行引擎210(例如，防火墙服务VM)从VNP中央控制器160接收防火墙规则。在一些实施例中，防火墙规则包括规则标识符和动作。在一些实施例中，规则标识符包括要与数据消息属性(诸如层2属性(例如，MAC地址)、层3属性(例如，五元组标识符等)、租户ID、位置ID(例如，办公位置ID、数据中心ID、远程用户ID等))进行比较的一个或多个匹配值，以便确定防火墙规则是否与数据消息匹配。

在一些实施例中，防火墙规则的动作指定当防火墙规则与数据消息的属性匹配时防火墙施行引擎210必须对数据消息采取的动作(例如，允许、丢弃、重定向等)。为了解决多个防火墙规则与数据消息匹配的可能性，防火墙施行引擎210将(从控制器集群160接收的)防火墙规则以分层的方式存储在防火墙规则数据存储装置中，以便一个防火墙规则可以具有比另一个防火墙规则更高的优先级。在一些实施例中，当数据消息与两个防火墙规则匹配时，防火墙施行引擎应用具有较高优先级的规则。在其它实施例中，防火墙施行引擎根据防火墙规则的层次结构检查防火墙规则(即，在较低优先级规则之前检查较高优先级规则)，以便确保在另一个较低优先级规则也可能是针对数据消息的匹配的情况下，数据消息首先与较高优先级规则匹配。

一些实施例允许控制器集群配置MFN部件，以使防火墙服务引擎在数据消息进入虚拟网络时在入口节点(例如，节点850)处、在虚拟网络上的中间节点(例如，节点857)处或者在数据消息离开虚拟网络时在出口节点(例如，节点855)处检查该数据消息。在一些实施例中，在这些节点中的每个节点处，CFE(例如，832、856或858)调用其相关联的防火墙服务引擎210以对CFE接收到的数据消息执行防火墙服务操作。在一些实施例中，防火墙服务引擎将其决定返回给调用它的模块(例如，返回给CFE)，从而这个模块可以对数据消息执行防火墙动作，而在其它实施例中，防火墙服务引擎对数据消息执行其防火墙动作。

在一些实施例中，其它MFN部件指示防火墙服务引擎执行其操作。例如，在一些实施例中，在入口节点处，VPN网关(例如，225或230)指示其相关联的防火墙服务引擎执行其操作，以便确定数据消息是否应当被传递到入口节点的CFE。而且，在一些实施例中，在出口节点处，CFE将数据消息传递到其相关联的防火墙服务引擎，如果它决定允许数据消息通过，那么该防火墙服务引擎将数据消息传递通过外部网络(例如，互联网)到其目的地，或将数据消息传递到其相关联的NAT引擎215以在通过外部网络将数据消息传递到其目的地之前执行其NAT操作。

一些实施例的虚拟网络提供方允许在公共云中限定的租户的WAN安全网关实现除了防火墙服务之外的或代替防火墙服务的其它安全服务。例如，租户的分布式WAN安全网关(在一些实施例中，其分布在由租户的虚拟网络跨越的每个公共云数据中心上)不仅包括防火墙服务引擎，而且还包括入侵检测引擎和入侵防御引擎。在一些实施例中，入侵检测引擎和入侵防御引擎在体系架构上被结合在MFN 150中以占据与防火墙服务引擎210相似的位置。

在一些实施例中，这些引擎中的每一个包括存储由中央控制器集群160分发的入侵检测/预防策略的一个或多个存储装置。在一些实施例中，这些策略将引擎配置为检测/防止到租户的(被部署在若干公共云数据中心上的)虚拟网络中的未授权的入侵，并响应于检测到的入侵事件而采取动作(例如，生成日志、发出通知、关闭服务或机器等)。像防火墙规则，可以在于其上限定虚拟网络的各种不同的受管理转发节点(例如，数据消息流的入口MFN、中间MFN和/或出口MFN)处施行入侵检测/预防策略。

如上面所提到的，通过在由虚拟WAN跨越的每个公共云中部署至少一个MFN并配置所部署的MFN以限定MFN之间允许租户的消息流进入和离开虚拟WAN的路由，虚拟网络提供方部署每个租户的虚拟WAN。而且，如上面所提到的，在一些实施例中，每个MFN可以由不同的租户共享，而在其它实施例中，每个MFN仅为一个特定的租户部署。

在一些实施例中，每个租户的虚拟WAN是安全虚拟WAN，该安全虚拟WAN通过经由覆盖隧道连接由那个WAN使用的MFN而建立。在一些实施例中，这种覆盖隧道方法用每个租户所独有的隧道报头(例如，包含独有地识别该租户的租户标识符)封装每个租户的数据消息流。对于租户，在一些实施例中，虚拟网络提供方的CFE使用一个隧道报头来识别用于进入/离开租户的虚拟WAN的入口/出口转发元件，并使用另一个隧道报头来遍历虚拟网络的中间转发元件。在其它实施例中，虚拟WAN的CFE使用不同的覆盖封装机制。

为了在一个或多个公共云上为租户部署虚拟WAN，VNP的控制器集群(1)基于租户的公司计算节点(例如，分支机构、数据中心、移动用户和SaaS提供方)的位置为租户识别可能的边缘MFN(其可以用作用于不同数据消息流的入口或出口MFN)，并且(2)识别所有可能的边缘MFN之间的路由。一旦识别出这些路由，它们就被传播到CFE的转发表(例如，使用OpenFlow传播到不同的基于OVS的虚拟网络路由器)。具体而言，为了识别通过租户的虚拟WAN的最佳路由，与这个WAN相关联的MFN生成量化它们与它们的相邻MFN之间的网络连接的质量的测量值，并定期将其测量提供给VNP的控制器集群。

如上面所提到的，控制器集群然后聚合来自不同MFN的测量，基于这些测量生成路由图，限定通过租户的虚拟WAN的路由，并且然后将这些路由分发到MFN的CFE的转发元件。为了动态更新用于租户的虚拟WAN的所限定的路由，与这个WAN相关联的MFN周期性地生成其测量并将这些测量提供给控制器集群，然后该控制器集群基于它接收到的更新后的测量周期性地重复其测量聚合、路由图生成、路由识别和路由分发。

在限定通过租户的虚拟WAN的路由时，VNP的控制器集群针对期望的端到端性能、可靠性和安全性对路由进行优化，同时尝试最小化租户的消息流通过互联网的路由。控制器集群还配置MFN部件，以优化穿过网络的数据消息流的层4处理(例如，通过跨连接路径拆分速率控制机制来优化TCP连接的端到端速率)。

随着公共云的激增，常常很容易找到与公司的每个分支机构靠近的主要的公共云数据中心。类似地，SaaS供应方越来越多地将其应用托管在公共云内，或者类似地位于某个公共云数据中心附近。因此，虚拟公司WAN 2015安全地使用公共云2005作为在公司计算节点(例如，分支机构、数据中心、远程设备和SaaS提供方)附近存在的公司网络基础设施。

公司WAN要求带宽保证，以便始终以可接受的性能提供关键业务应用。此类应用可以是交互式数据应用，例如，ERP、财务或采购、面向最后期限的应用(例如，工业或IoT控制)、实时应用(例如，VoIP或视频会议)。因此，传统的WAN基础设施(例如，帧中继或MPLS)提供了这样的保证。

在多租户网络中提供带宽保证的主要障碍是需要对于某个客户在一条或多条路径上预留带宽。在一些实施例中，VNP提供QoS服务，并提供入口承诺速率(ICR)保证和出口承诺速率(ECR)保证。ICR是指进入虚拟网络的流量速率，而ECR是指离开虚拟网络到租户站点的流量速率。

只要流量不超过ICR和ECR限制，在一些实施例中，虚拟网络就提供带宽和延迟保证。例如，只要HTTP入口或出口流量不超过1Mbps，就保证带宽和低延迟。这是点到云模型，因为出于QoS的目的，只要其目的地在ICR/ECR界限之内，VNP就无需跟踪流量目的地。这个模型有时被称为软管(hose)模型。

对于其中客户期望点对点保证的更严格的应用，需要构建虚拟数据管道来递送高度关键的流量。例如，企业可能想要以高服务水平协议保证连接的两个集线器站点或数据中心。为此，VNP路由自动选择满足针对每个客户的带宽约束的路由路径。这被称为点对点模型或管道模型。

VNP在向终端用户提供有保证的带宽方面的主要优点是根据变化的带宽需求来调整VNP基础设施的能力。大多数公共云在位于同一个云的不同区域处的每两个实例之间提供最小带宽保证。如果当前网络没有足够的未使用容量来为新请求提供有保证的带宽，那么VNP为其设施添加新资源。例如，VNP可以在高需求区域中添加新的CFE。

一个挑战是在规划路线以及扩展和缩小基础设施时优化这个新维度的性能和成本。为了促进算法和带宽核算，一些实施例假设不拆分端到端带宽预留。以其它方式，如果在某个租户的分支机构A和分支机构B之间保留一定带宽(例如，10Mbps)，那么在从分支机构A所连接的入口CFE开始并且然后遍历零个或多个中间CFE的集合以到达连接到分支B的出口CFE的单条路径上分配带宽。一些实施例还假设带宽有保证的路径仅遍历单个公共云。

为了考虑在网络拓扑上相交的各种带宽预留，在一些实施例中，VNP静态地限定在预留的带宽路径上的路由，使得数据消息流总是遍历通过为带宽要求预留的相同路由。在一些实施例中，用单个标签识别每条路由，该路由所遍历的每个CFE与和这条路由相关联的单个传出接口匹配。具体而言，每个CFE将单个传出接口与在其报头中具有这个标签并从具体传入接口到达的每个数据消息匹配。

在一些实施例中，控制器集群维持由若干互连节点形成的网络图。图中的每个节点n具有与这个节点相关联的所分配的总的有保证的带宽(TBW_n)以及这个节点已经预留(分配给某条预留路径)的带宽量(RBW_n)。此外，对于每个节点，该图包括以分/千兆字节为单位的成本(C_ij)以及与这个节点和图中所有其它节点之间的发送流量相关联的以毫秒为单位的延迟(D_ij)。与节点i和节点j之间的发送流量相关联的权重为W_ij＝a*C_ij+D_ij，其中a是通常在1到10之间的系统参数。

当对于分支A和B之间的值为BW的带宽预留的请求被接受时，控制器集群首先将该请求映射到分别绑定到分支A和B的具体入口和出口路由器n和m。然后，控制器集群执行路由过程，该路由过程在n和m之间进行两次最低成本(例如，最短路径)计算。第一次是与沿着计算出的路由的可用带宽无关的在n和m之间的最低成本(例如，最短路径)路由。该路由的总权重被计算为W₁。

第二最低成本(例如，最短路径)计算最初通过消除其中BW＞TBW_i-RBW_i的所有节点i来修改图。经修改的图被称为经修剪的图。然后，控制器集群在经修剪的图上执行第二次成本最低(例如，最短路径)路由计算。如果第二条路由的权重比第一条路由高不超过K％(K通常为10％-30％)，那么选择第二条路由作为优选路径。另一方面，当不满足这个要求时，控制器集群将具有TBW_i-RBW_i的最小值的节点i添加到第一条路径，并且然后重复两次最低成本(例如，最短路径)计算。控制器集群将继续添加更多路由器，直到满足条件为止。那时，保留的带宽BW被添加到所有RBW_i，其中i是所选择的路由上的路由器。

对于为已经具有预留带宽的路由请求附加带宽的特殊情况，控制器集群将首先删除节点A和B之间的当前带宽预留，并将计算这些节点之间的总带宽请求的路径。为此，在一些实施例中为每个节点保存的信息还包括为每个标签或者每个源和目的地分支而预留的带宽，而不仅仅是预留的总带宽。在将带宽预留添加到网络之后，只要通过虚拟网络的测得的网络延迟或成本没有重大改变，一些实施例就不再访路由。但是，当测量和/或成本改变时，这些实施例重复带宽预留和路由计算处理。

图21概念性地图示了过程2100，该过程2100由虚拟网络提供方的控制器集群160执行以为特定租户部署和管理虚拟WAN。在一些实施例中，过程2100由在控制器集群160上执行的若干不同的控制器程序执行。这个过程的操作不一定必须遵循图21中所示的顺序，因为这些操作可以由不同程序并行或以不同顺序执行。因而，在这个图中示出这些操作仅是为了描述由控制器集群执行的操作的一个示例性序列。

如图所示，控制器集群最初在若干不同的公共云提供方(例如，Amazon AWS、Google GCP等)的若干公共云数据中心中部署(在2105处)若干MFN。在一些实施例中，控制器集群为一个或多个其它租户配置(在2105处)这些部署的MFN，这一个或多个其它租户与为其示出了过程2100的特定租户不同。

在2110处，控制器集群从特定租户接收关于特定租户的位置和外部机器属性的数据。在一些实施例中，这个数据包括由特定租户使用的私有子网以及该特定租户在其处具有外部机器的一个或多个租户办公室和数据中心的标识符。在一些实施例中，控制器集群可以通过API或通过控制器集群提供的用户界面来接收租户数据。

接下来，在2115处，控制器集群从由作为候选MFN的MFN150的测量代理205收集以用于为特定租户建立虚拟网络的测量中为特定租户生成路由图。如上面所提到的，路由图具有表示MFN的节点以及表示MFN之间的网络连接的节点之间的链路。链路具有相关联的权重，该权重是量化使用由链路表示的网络连接的质量和/或成本的成本值。如上面所提到的，控制器集群首先从收集到的测量中生成测量图，然后通过从测量图中移除非最优的链路(例如，具有大的延迟或丢弃率的链路)来生成路由图。

在构造路由图之后，控制器集群执行(在2120处)路径搜索，以识别不同对的候选入口和出口节点(即，MFN)之间的可能路由，租户的外部机器可以使用该可能路由将数据消息发送到(由MFN部署的)虚拟网络并从虚拟网络接收数据消息。在一些实施例中，控制器集群使用已知的路径搜索算法来识别节点的每个候选入口/出口对之间的不同路径。用于此类对的每条路径使用在被级联时从入口节点通过零个或多个中间节点遍历到出口节点的一个或多个链路。

在一些实施例中，任何两个MFN之间的成本包括两个MFN之间的连接链路的估计的等待时间和财务成本的加权和。在一些实施例中，等待时间和财务成本包括以下中的一项或多项：(1)链路延迟测量、(2)估计的消息处理等待时间、(3)从特定数据中心或者到同一公共云提供方的另一个数据中心或者离开公共云(PC)提供方的云(例如，到另一个公共云提供方的另一个公共云数据中心，或到互联网)的传出流量的云费用以及(4)与在公共云中的主机计算机上执行的MFN相关联的估计的消息处理成本。

一些实施例评估遍历通过公共互联网的两个MFN之间的连接链路的惩罚(penalty)，以便在任何可能的情况下最小化这种遍历。一些实施例还激励两个数据中心之间的私有网络连接的使用(例如，通过降低连接链路成本)，以便使路由生成偏向使用这种连接。使用这些成对链路的计算出的成本，控制器集群可以通过聚合由路由路径使用的各个成对链路的成本来计算使用这些成对链路中的一个或多个的每条路由路径的成本。

控制器集群然后基于每个候选入口/出口节点对之间的识别出的候选路径的计算出的成本(例如，最低聚合成本)来选择(在2120处)一条或多达N条识别出的路径(其中N是大于1的整数)。在一些实施例中，如上面所提到的，每条路径的计算出的成本是基于该路径使用的每个链路的权重成本(例如，是每个链路的相关联权重值之和)。当两个MFN之间需要多于一条路由以允许入口MFN或中间MFN执行多路径操作时，控制器集群可以选择一对入口/出口节点之间的多于一条路径。

在为每个候选的入口/出口节点对选择(在2120处)一条或N条路径之后，控制器集群基于所选择的路径限定一条或N条路由，然后为实现特定租户的虚拟网络的MFN生成路由表或路由表部分。生成的路由记录识别到达特定租户的不同子网的边缘MFN，并识别下一跳MFN，以遍历从入口MFN到出口MFN的路由。

在2125处，控制器集群将路由记录分发到MFN，以便配置这些MFN的转发元件235以实现用于特定租户的虚拟网络。在一些实施例中，控制器集群通过使用通信协议与转发元件通信以传递路由记录，该通信协议当前用于软件限定的多租户数据中心，以配置在主机计算机上执行的软件路由器以实现跨越主机计算机的逻辑网络。

一旦已经配置了MFN并且虚拟网络可操作用于特定租户，边缘MFN就从租户的外部机器(即，在虚拟网络外部的机器)接收数据消息并将这些数据消息转发到虚拟网络中的边缘MFN，该边缘MFN转而将数据消息转发到租户的其它外部机器。在执行此类转发操作时，入口、中间和出口MFN收集关于其转发操作的统计信息。而且，在一些实施例中，每个MFN上的一个或多个模块在一些实施例中收集关于公共云数据中心中的网络或计算消耗的其它统计信息。在一些实施例中，公共云提供方收集此类消耗数据，并将收集到的数据传递给虚拟网络提供方。

当接近计费周期时，控制器集群收集(例如，在2130处)由MFN收集的统计信息和/或由MFN收集或由公共云提供方提供的网络/计算消耗数据。基于收集到的统计信息和/或所提供的网络/计算消耗数据，控制器集群生成(在2130处)计费报告，并将计费报告发送给特定租户。

如上面所提到的，在计费报告中的计费金额考虑控制器集群接收(例如，在2130处)的统计信息和网络/消耗数据。而且，在一些实施例中，账单考虑虚拟网络提供方操作MFN(为特定租户实现虚拟网络)所产生的成本加上回报率(例如，增加10％)。这种计费方案对于特定租户而言是方便的，因为特定租户不必处理来自其上部署了租户的虚拟网络的多个不同公共云提供方的账单。在一些实施例中，VNP的所发生的成本包括由公共云提供方向VNP收取的成本。在2130处，控制器集群还对信用卡收费或针对账单报告中反映的费用以电子方式从银行账户中提取资金。

在2135处，控制器集群确定它是否已经从测量代理205接收到新的测量。如果不是，那么处理转变到2145，这将在下面进行描述。另一方面，当控制器集群确定它已经从测量代理接收到新的测量时，它确定(在2140处)它是否需要基于新的测量为特定租户重新检查其路由图。在没有MFN故障的情况下，在一些实施例中，控制器集群最多在特定时间段期间(例如，每24小时或每周一次)基于接收到的更新后的测量为每个租户更新一次其路由图。

当控制器集群基于其已接收到的新测量确定(在2140处)它需要重新检查路由图时，该过程基于新接收到的测量生成(在2145处)新的测量图。在一些实施例中，控制器集群使用加权和将每个新测量与先前测量混合，以便确保与测量图的链路相关联的测量值不会在每次接收到新的测量集时剧烈波动。

在2145处，控制器集群还基于经调整的测量图来确定是否需要调整路由图(例如，是否需要为路由图链路调整权重值，或者由于与链路相关联的经调整的测量值，在路由图中添加还是移除链路)。如果是，那么控制器集群(在2145处)调整路由图，执行路径搜索操作(诸如操作2120)以识别入口/出口节点对之间的路由，基于识别出的路由生成路由记录，并将路由记录分发到MFN。从2145，处理转变到2150。

当控制器集群确定(在2140)它不需要重新检查路由图时，过程也转变到2150。在2150处，控制器集群确定它是否必须收集关于所处理的数据消息和所消耗的网络/计算资源的统计信息。如果不是，那么过程返回到2135，以确定它是否已经从MFN测量代理接收到新的测量。否则，过程返回到2130，以收集统计信息和网络/计算消耗数据并生成和发送计费报告。在一些实施例中，控制器集群重复执行过程2100的操作，直到特定租户不再需要跨公共云数据中心部署的虚拟网络为止。

在一些实施例中，控制器集群不仅在公共云数据中心中为租户部署虚拟网络，而且还协助租户在公共云数据中心中部署和配置计算节点机器和服务机器。所部署的服务机器可以是与MFN的服务机器分开的机器。在一些实施例中，给特定租户的控制器集群计费报告还考虑了由所部署的计算和服务机器消耗的计算资源。再次，与从多个公共云提供方接收多个账单相比，对于租户而言，具有来自一个虚拟网络提供方的针对在多个公共云提供方的多个公共云数据中心中消耗的网络和计算资源的一个账单是更优选的。

其它实施例使用其它部署模型在网络上部署单租户或多租户虚拟网络，并计算两个或更多个公共云提供方的基础设施。例如，在一些实施例中，虚拟网络提供方允许一个或多个云服务转卖方为其客户中的一个或多个部署单租户或多租户虚拟网络。图22图示了这个部署模型。如图所示，这个部署模型使用三个级别的SaaS提供方2205-2215，它们提供SaaS服务的三个集合。

第一SaaS层2205由一个或多个公共云提供方2220提供，它们在多个不同的公共云2250中提供计算和网络基础设施(例如，计算元件(诸如主机计算机、VM和/或容器)和连接计算元件的网络元件(硬件或软件交换机、路由器、中间体元件等))。第二SaaS层2210由VNP2225提供，该VNP 2225提供用于跨多个公共云2250为云转卖方部署虚拟网络的工具。云转卖方2230向其客户2240提供第三SaaS层2215，该第三SaaS层2215使用云转卖方工具来限定计算元件和网络基础设施(例如，虚拟网络)以跨一个或多个公共云2250部署。

在一些实施例中，云转卖方2230具有其自己的与每个公共云提供方的客户账户。在一些实施例中，云转卖方直接与每个公共云提供方建立其客户账户(如虚线弧2252所识别的)，然后将用于这个客户账户的安全凭证提供给VNP提供方2225。在其它实施例中，云转卖方通过VNP提供方的机器2225建立其公共云客户账户。为了指示VNP在公共云基础设施上为其租户之一部署虚拟网络，云转卖方机器2230最初向VNP机器2225提供云转卖方的VNP安全凭证(例如，用户名、密码、证书等)，以便认证云转卖方。

如图所示，云转卖方还向VNP 2225提供期望的网络配置。这种配置描述了需要为租户部署的虚拟网络的属性。在一些实施例中，这种配置数据还包括云转卖方2230为其客户使用的租户标识符，其指示VNP 2225为该客户部署虚拟网络。在一些实施例中，这个租户标识符是从VNP获得的。在其它实施例中，配置数据包括由VNP提供的租户标识符，云转卖方将该租户标识符映射到用于其租户的其自己的租户标识符。

在一些实施例中，VNP机器2225在为转卖方的客户部署虚拟网络时(例如，当部署MFN、用适当的路由记录配置MFN CFE等时)向公共云机器2220提供云转卖方的安全凭证。这些安全凭证(例如，用户名、密码、安全证书等)允许VNP机器将自身认证为按照云转卖方的要求操作的机器(例如，登录到公共云机器2220上，如同云转卖方机器2230正在登录到公共云机器2220)。

为了为云转卖方的每个租户部署虚拟网络，在一些实施例中，VNP机器还用针对云转卖方的租户的租户标识符来配置形成虚拟网络的组件(例如，MFN、MFN网关/服务箱/CFE等)。在一些实施例中，这些配置的组件然后将它们收集的统计信息(例如，路由统计信息和部署机器计算统计信息)与租户标识符相关联，以便可以基于这些统计信息对云转卖方的客户适当收费，如下面进一步描述的。

在其中云转卖方将用于其客户的租户标识符提供给VNP机器2225的一些实施例中，VNP机器2225将由云转卖方2230提供的每个租户标识符映射到VNP的独有的租户标识符，并且在将统计信息提供给云转卖方之前将收集到的统计信息的VNP租户标识符翻译成云转卖方的租户标识符。在其它实施例中，云转卖方机器2230和/或VNP提供方机器2225使用由公共云提供方机器2220提供的租户标识符。

VNP机器2225使用由云转卖方2230提供的租户网络配置数据来为云转卖方的每个客户部署和/或配置虚拟网络的虚拟网络组件(例如，MFN等)。在一些实施例中，多个不同的客户共享相同的虚拟网络和/或虚拟网络组件。结合地或可替代地，在一些实施例中，VNP机器2225可以为云转卖方的任何个体客户限定单个租户虚拟网络。如图所示，VNP机器2225通过公共云提供方机器2220部署和配置虚拟网络和/或虚拟网络组件。在一些实施例中，转卖方、VNP和公共云机器2220-2230通过其各自的API接口和中间网络架构(例如，互联网)彼此通信。

VNP机器2225从部署虚拟网络组件收集每个租户统计信息(例如，来自CFE和网关等的路由统计信息)，聚合统计信息，并将聚合的统计信息转发到云转卖方。在其中VNP机器将转卖方客户标识符映射到VNP租户标识符的实施例中，VNP机器在以翻译的客户标识符供应聚合的统计信息之前将租户标识符翻译为客户标识符。而且，在其中VNP机器将公共云标识符映射到VNP租户标识符的实施例中，VNP机器将公共云标识符翻译成VNP标识符。

如图所示，VNP机器2225周期性地将计费报告发送到云转卖方2230，以便为由VNP执行的服务收取费用。在一些实施例中，这些计费报告向云转卖方收取用于在两个或更多个公共云上为云转卖方部署虚拟网络的VNP的服务费。这些部署费用包括执行支持此类部署的辅助操作(诸如产生量化公共云中MFN之间以及租户外部机器位置之间的链路的质量和/或成本的测量的测量操作)的费用。

而且，在一些实施例中，VNP机器2225从一个或多个公共云提供方接收针对云转卖方的计费数据。在一些实施例中，这种计费数据与云转卖方的客户凭证(例如，云转卖方的PC提供方客户编号)相关联。在这些实施例中，VNP机器2225将计费数据传递给云转卖方(例如，具有加价(markup)调整或不具有加价调整)。在其它实施例中，如虚线2252所示，公共云提供方将计费报告直接发送到云转卖方机器2230。

在一些实施例中，云转卖方机器2230使用由VNP机器2225提供的使用统计信息来针对虚拟网络向其客户收费。在一些实施例中，VNP机器2225不仅部署网络基础设施，而且还部署用于云转卖方2230的计算基础设施。在这些实施例中的一些当中，使用统计信息反映了所使用的计算资源，并且云转卖方机器2230使用这些统计信息来向其客户收费。在一些实施例中，云转卖方不使用收集到的统计信息来向其客户收费，而是基于客户请求部署的计算和/或网络配置向其客户收费。

为了进一步说明图22的三层SaaS部署模型之间的差异，图23图示了上面先前描述的两层SaaS部署模型的相似图。图23的这个两层模型没有任何云转卖方2215。而是，在这种两层模型中，VNP的客户是使VNP仅为其部署单租户虚拟网络或共享VNP已为若干客户部署的多租户虚拟网络的实体。如上所述，由于每个客户的网络流量与其它客户的网络流量安全地隔离，因此不同的客户可以在一个或多个公共云上安全地共享限定多租户虚拟网络的组件。

在图23的两层模型中，第一SaaS层2205由一个或多个公共云提供方2220提供，该一个或多个公共云提供方2220在多个不同的公共云2250中提供计算和网络基础设施，而第二SaaS层2210由VNP2225，该VNP 2225为其客户中的若干客户提供用于跨多个公共云2250部署虚拟网络的工具。如图所示，VNP机器2225向公共云提供方提供用于公共云的VNP安全凭证。

VNP机器为(与租户标识符相关联的)每个客户接收租户网络配置数据，并且基于这个数据，部署和/或配置用于其客户中的每个客户的虚拟网络的虚拟网络组件(例如，MFN等)。如图所示，VNP机器2225通过公共云提供方机器2220部署和配置虚拟网络和/或虚拟网络组件。在一些实施例中，公共云机器2220和VNP机器2225通过其各自的API接口和中间网络架构(例如，互联网)彼此通信。

如进一步所示，VNP机器2225从部署虚拟网络组件收集每个租户统计信息(例如，从CFE和网关收集路由统计信息等)，并且聚合所收集的统计信息。VNP机器2225周期性地向VNP客户中的每一个发送计费报告，以收集针对由VNP执行的服务的费用。如上面所提到的，在一些实施例中，这些费用包括公共云提供方针对由客户的虚拟网络消耗的资源(例如，计算和/或网络资源)向VNP收取的费用，加上一定的加价百分比。VNP机器基于这些机器收集和聚合的针对客户的相关联标识符的统计信息来识别通过每个客户的虚拟网络的资源量。在其它实施例中，VNP机器将每个公共云提供方针对由客户虚拟网络消耗的资源的费用加上针对每个客户对VNP资源的使用的费用传递给每个客户。

一些实施例通过到一个或多个公共云提供方的多个公共云(例如，多个公共云数据中心)的多个连接链路将租户的多机器计算节点(例如，分支机构或数据中心)连接到租户的公共云虚拟网络。在多机器计算节点(MMCN)与公共云虚拟网络之间具有多个链路允许虚拟网络是高度可用的，因为它可以承受一个或多个连接链路的故障。在一些实施例中，一个链路是主要链路，而其它每个链路是故障转移链路。通过选择用于从MMCN进入虚拟网络的最佳入口节点以实现通过虚拟网络到达用于离开虚拟网络到达另一个MMCN或SaaS提供方数据中心的出口节点的最佳路由，这种方法还允许建立从每个MMCN到每个其他MMCN或SaaS提供方数据中心的最佳路由。

下面的讨论使用术语多宿主MMCN来指租户的多机器计算节点，其通过到一个或多个公共云提供方的多个公共云的多个连接链路连接到租户的公共云虚拟网络。下面的讨论还使用术语多宿主SaaS数据中心来指虚拟网络将一个或多个公共云提供方的一个或多个公共云(例如，多个公共云数据中心)中的多个MFN与之关联的SaaS数据中心。在一些实施例中，这些MFN是用于遍历经过虚拟网络以到达SaaS提供方的路由的候选出口节点。使用两个或更多个出口节点来连接SaaS数据中心的虚拟网络的优势还在于它使能链路故障转移支持并且它允许在不同外部计算机节点对(例如，远程计算机或MMCN)和SaaS提供方数据中心之间使用最优路由。

在一些实施例中，即使当虚拟网络控制器160将多个MFN与SaaS数据中心关联时，SaaS数据中心也不需要发起到多个公共云数据中心中虚拟网络的多个MFN的路由。另一方面，在一些实施例中，多宿主MMCN需要通过到虚拟网络的不同链路来主动发起路由。为此，通过具有带故障转移能力的适当路由器(例如，通过使用Cisco2800系列)，在多宿主MMCN中促进应变(fallback)能力。

为了最优路由，在一些实施例中，多宿主MMCN包括一个或多个计算机或装置，该一个或多个计算机或装置执行测量处理以测量MMCN与MMCN可以连接到的不同公共云数据中心之间的性能(延迟、损失等)。此外，在一些实施例中，MMCN基于由集中式控制器集群(例如，控制器集群160)限定的路由来执行其总体路由操作，该集中式控制器集群(例如，控制器集群160)为实体(例如，为租户)限定虚拟网络。为了实现这一点，多宿主MMCN配备有SD-WAN能力(诸如Velocloud和Viptela装置)，其作为用于部署虚拟网络的集中式控制平面的一部分进行操作。如上面所提到的，在一些实施例中，集中式控制平面由两个或更多个控制器的集群来实现。

图24图示了由一些实施例的中央控制器集群用于为特定的多宿主MMCN限定路由的过程2400。这个过程在特定的多宿主MMCN中使用专用路由器来使用所限定的路由执行通过多个连接链路将数据消息从MMCN转发到虚拟网络的路由操作。在一些实施例中，专用路由器是软件路由器或软件路由器的集群，而在其它实施例中，专用路由器是路由装置(例如，SD-WAN装置)。MMCN中的专用路由器或路由器集群在以下讨论中被称为MMCN的边缘节点。在一些实施例中，中央控制器集群通过互联网远程控制MMCN的边缘节点。

如图所示，中央控制器集群最初根据DNS服务器服务和边缘节点IP地址识别(在2405处)来自最接近特定MMCN边缘节点的N个不同云区域中的N个MFN的子集(例如，10到12个)。在一些实施例中，N个MFN在特定MMCN的一定距离内具有来自每个云提供方的至少一个候选MFN。而且，在一些实施例中，N个MFN中的每个MFN包括网关(例如，分支网关225)，以与特定MMCN边缘节点建立安全连接链路。

而且，如上面所提到的，在一些实施例中，DNS服务器服务是在一个或多个公共云中操作并向实体的MMCN的DNS服务器提供DNS信息的服务机器或若干服务机器的集群。在这些实施例中的一些当中，DNS服务器由虚拟网络提供方或由另一个实体操作。在其它实施例中，DNS服务器服务是(例如，第三方的)geo-IP服务，该geo-IP服务驻留在实现虚拟网络的公共云外部并且可以识别公共云中靠近为其执行过程2400的特定MMCN的边缘节点。

接下来，在2410处，控制器集群将识别出的列表下载到至特定MMCN的边缘节点的N个节点，从而MMCN的边缘节点可以进行量化与列表中N个MFN中的每个MFN的连接的质量的测量。在一些实施例中，每个MMCN边缘节点具有生成此类测量的测量代理(例如，在MMCN计算机之一上执行的处理)。在不同实施例中，这个测量代理不同地生成测量值。在一些实施例中，测量代理周期性地(例如，每秒、每N秒、每分钟、每M分钟等一次)向列表中的N个MFN的测量代理中的每一个发送查验消息(例如，UDP回声消息)。基于其接收到的答复消息的速度，MMCN测量代理计算并更新测量度量值(诸如网络连接吞吐速度、延迟、损失和链路可靠性)。在一些实施例中，多个MFN共享一个测量代理(例如，在托管MFN的公共云提供方的相同数据中心或附近数据中心中)。

在一些实施例中，特定MMCN的测量代理周期性地执行这些测量，并且将新的测量周期性地发送到控制器集群，使得控制器集群可以更新其权重计算和路由生成，如下面参考2420-2435进一步描述的。而且，每当在新添加的或先前使用的公共云数据中心中添加新的MFN时，在一些实施例中，控制器集群就生成N个候选MFN的更新列表。

在2415处，控制器集群接收由特定MMCN的边缘节点进行的测量。基于这些测量，集中式控制器集群针对将特定MMCN的边缘节点连接到N个MFN中的每个MFN的每个连接链路计算(在2420处)链路权重。例如，在一些实施例中，中央控制器通过对延迟测量使用指数滤波器并使用损失参数作为权重乘数(例如，对于每1％的损失，权重加倍)来计算每个链路的权重。

基于计算出的权重，中央控制器然后(在2425处)将M个(例如，5个或6个)MFN的子集识别为边缘节点将连接到的“归属”节点。在一些实施例中，这M个节点是具有最低权重值的节点。在其它实施例中，这M个节点是具有最低权重值的节点，但是每个云提供方中的至少一个代表性MFN被包括在这M个节点中。M个节点的列表可以随时间改变，并且在添加新MFN时和/或从特定的MMCN边缘节点接收到新测量时可以将MFN丢弃和添加到列表中。在一些实施例中，控制器集群使用“滞后”处理来避免M个MFN的列表中的频繁改变。在一些实施例中，滞后处理使用MFN列表的先前状态(即，先前成员)来减少向MFN列表添加成员/从MFN列表移除成员的速率。而且，在一些实施例中，除非另一个MFN在测量的窗口(例如，时间段)内平均权重减小10％，否则控制器集群不会从列表中丢弃MFN。

如上面所提到的，在一些实施例中，特定MMCN边缘节点维持到M个MFN中的每个MFN的虚拟网络网关的安全连接(例如，IPsec连接)。在一些实施例中，控制器集群指示(在2425处)特定MMCN边缘节点与M个MFN中的每个MFN建立安全连接。在2430处，控制器集群使用所选择的M个MFN的计算出的权重来识别最优路由和故障转移路由，以用于使特定MMCN边缘节点与每个其它可能的节点连接，以使数据消息流通过虚拟网络在特定MMCN边缘节点与其它MMCN边缘节点或SaaS提供方数据中心之间遍历。为了生成此类路由，如上所述，在一些实施例中，控制器集群使用最短路径路由识别过程。

在一些实施例中，控制器集群周期性地或每当计算出的权重值改变时(例如，基于新测量或M个MFN的列表中MFN的添加/删除)重复其路由识别过程。在一些实施例中，控制器集群执行针对特定MMCN边缘节点的路由标识操作(在2430处)连同针对其它多宿主MMCN和/或多宿主SaaS提供方的路由识别操作一起，因为到其它MMCN和到SaaS提供方的多个连接链路在识别来自和去往特定MMCN的最优路由中会是相关的。这些计算出的路由还考虑了去往/来自虚拟网络MFN的路由，这些虚拟网络MFN是用于连接到远程设备(例如，远程膝上型计算机、桌上型计算机、或移动设备，诸如智能电话、平板电脑等)的候选。

在识别出这些路由之后，控制器集群(在2435处)针对到特定MMCN边缘节点和MFN的一条或多条路由供应转发记录。例如，在一些实施例中，控制器集群向特定MMCN边缘节点并向MFN CFE提供转发记录(例如，指定下一跳的路由记录、指定虚拟网络出口节点的路由记录等)。通过使用这些转发记录来执行其路由操作，特定MMCN边缘节点和MFN CFE实现了由控制器集群限定(在2430处)的最优和故障转移路由。在一些实施例中，每当识别出新的最优或故障转移路由时，控制器集群就将新的路由记录供应给特定MMCN边缘节点和MFNCFE。

以这种方式，图24的过程2400使其路由计算基于计算出的权重值，该权重值表达特定MMCN及其与虚拟网络的若干连接中的每个连接之间的连接的质量。在这种方法下，可以为特定MMCN边缘节点和不同的MMCN、不同的SaaS节点和/或不同的远程设备选择不同的虚拟网络入口/出口节点对。因此，如上面所提到的，在一些实施例中，控制器集群对一个或多个多宿主MMCN和/或多宿主SaaS提供方一起执行路由识别操作(即，操作2430)。

图25给出了两个MMCN 2505和2510的两个分支节点EN1和EN2以及SaaS数据中心2515的示例。每个分支节点通过在两个或三个公共云提供方的三个公共云数据中心中限定的虚拟网络MFN2525-2535连接到虚拟网络2520。另一方面，可以通过虚拟网络MFN 2540和2545访问SaaS数据中心2515。相关分支节点EN1和EN2、MFN 2525-2545和SaaS数据中心2515之间测得的权重在这些节点之间的链路上描绘。在这个示例中，假设其它权重(如节点2525和2535之间的权重)高得多(例如，10)，因此最短路径路由算法不会在最佳成本路径中使用它们。

如从这个示例可以看到的，从EN1到SaaS数据中心的最佳路径遍历节点2525和2540，因为这条路径的权重和为14，这小于其它路径的其它权重成本。例如，经过节点2530将在第一跳中产生较小的权重，但将导致总的最小权重为15。来自分支节点EN2的最优路由将通过路由器2535和2545，其总权重为15。因此，两个分支将使用两个不同的路由到达SaaS数据中心。为了在EN1和EN2之间进行通信，最佳路由将是通过MFN 2530，其总权重为13。

如上面所提到的，一些实施例使两个或更多个虚拟网络MFN与每个SaaS提供方的数据中心相关联。SaaS是一种软件分发模型，其中第三方提供方托管应用并使客户可通过互联网获得。SaaS移除了组织在其自己的计算机上或在其自己的数据中心中安装和运行应用的需要。这消除了硬件购置、供给和维持以及软件许可、安装和支持的开支。而且，客户订阅SaaS提供物(offering)，而不是购买软件以安装或支持该软件的其它硬件。一般而言，他们使用即付即用模式按月为这项服务付费。将成本转变成循环发生的运营开支允许许多企业行使更好、更可预测的预算。用户还可以随时终止SaaS提供物，以停止这些循环发生的费用。

SaaS提供高可扩展性，这使客户可以选择访问更多或更少的服务或特征，而无需供应或购买更多计算机。当需要更新软件而不是购买新版本或更新客户自己的版本时，客户可以依靠SaaS提供方来自动执行更新和补丁管理。这进一步减轻了内部IT员工的负担。由于SaaS应用是通过互联网交付的，因此用户可以从任何互联网使能的设备和位置访问它们。这些优势已使SaaS成为使用客户硬件安装在客户场所的打包软件的非常受欢迎的替代方案。SaaS提供方可以将服务托管在其(一个或多个)私有数据中心中的一个或多个服务器上，或托管驻留在公共云中的一个或多个区域中的一个或多个服务器上。

SaaS提供方通常由其服务的域名(例如，www.myworkday.com)识别。常常存在与运行SaaS提供方的公共网页的服务器相关联的域名(www.workday.com)，其与运行SaaS应用的服务器的域名(www.myworkday.com)不同。可以通过DNS查询来解析这个域名，以提供SaaS应用服务器的IP地址。

在存在多个服务器的情况下，DNS服务器可以向可以与不同服务器相关联的两个不同请求返回不同的IP地址。不同名称的逻辑是基于位置的。如果SaaS提供方在世界上具有它拥有服务器的若干区域，那么每个请求者将取回与其更近的IP服务器。在同一区域内，DNS服务仍可以根据负载平衡观点选择不同的服务器；返回的IP地址与同一区域中的不同服务器相关联。后一种情况将返回通常共享同一IP子网的不同服务器的IP地址。

在一些实施例中，虚拟网络的控制器集群保持已知IP SaaS地址的表。当虚拟网络从客户那里得到分组时，目的地IP可以是三种不同的类型。第一，分组可以与实体的私有位置相关联(即，在实体的私有IP空间中具有目的地地址)。在这种情况下，在一些实施例中，虚拟网络将分组路由到与分组的目的地地址相关联的实体的对应计算节点。

第二，分组具有目的地地址，该目的地地址是对于虚拟网络未知的公共(非私有)IP地址。这些IP地址被称为通用公共IP地址。在一些实施例中，虚拟网络将这种分组从入口虚拟网络节点发送到互联网。第三，分组具有目的地地址，该目的地地址是对于虚拟网络已知的公共(非私有)IP地址，是SaaS提供方的IP地址。此类IP地址被称为SaaS IP地址。在一些实施例中，这种分组将从第一虚拟网络节点(例如，第一MFN的第一CFE)被路由到第二虚拟网络节点(例如，第二MFN的第二CFE)，在一些实施例中，它以最短可能方式从其中提供给SaaS IP。

图26图示了由一些实施例的中央控制器集群用来为多宿主SaaS提供方限定路由的过程2600。这个过程识别与SaaS服务相关联的各种IP地址并识别从不同的计算端节点到一个或多个SaaS提供方数据中心的最短可能路由。如图所示，在一些实施例中，当控制器集群接收到SaaS域名列表时，过程2600开始(在2605处)。在一些实施例中，由公共云虚拟网络提供方的管理员提供SaaS域列表，而在其它实施例中，由虚拟网络提供方所限定的公共云虚拟网络的实体的管理员提供这个列表。下表提供了这种SaaS列表的示例。

/>

在2610处，控制器集群将SaaS域列表存储在数据库中。在一些实施例中，这个数据库是虚拟网络提供方的和/或为其部署虚拟网络的实体(例如，租户)的管理员可通过一个或多个接口(例如，web服务器接口和/或API接口)访问的。通过这个接口，管理员可以对该列表添加或移除SaaS提供方和/或相关联的域名。

接着在2615处，控制器集群在其域名列表中学习与域相关联的SaaS服务器的尽可能多的IP地址。为此，在一些实施例中，控制器集群指示公共云中的不同测量代理205(由VNP为部署在不同公共云上的一个或多个虚拟网络部署)对列表上的每个域名执行DNS查询。周期性地(例如，每30分钟)重复这种查询。测量代理205将它们为每个域名学习的IP地址传送回(在2615处)控制器集群。

由于许多SaaS正在使用地理DNS服务来将相邻服务器与客户端进行匹配，因此不同的测量代理可以返回不同的IP地址。SaaS提供方通常使用具有SaaS服务器及其位置的列表的权威DNS服务器。当这种DNS服务器得到DNS请求时，它接收测量代理的IP地址，并将这个IP地址用于Geo-IP映射以识别测量代理的位置并返回用于测量代理的“最佳”服务器的IP地址。在一些实施例中，测量代理还提供虚拟网络的端计算节点的IP地址，并且由SaaS提供方使用的DNS服务器基于端计算节点的IP地址提供IP地址。

控制器集群(在2620处)将返回的IP地址及其相关联的域名存储在数据库中。当至少某个数量的IP(例如，5个)属于同一IP子网(例如，包含255个或更少的不同地址的C类子网)时，控制器集群将子网本身添加到数据库。在一些实施例中，这个数据库是虚拟网络提供方的和/或为其部署虚拟网络的实体(例如，租户)的管理员可通过一个或多个接口(例如，web服务器接口和/或API接口)访问的。通过这个接口，管理员可以添加或移除IP地址。这个接口还允许添加/移除与由管理员添加/移除的域名相关联的记录。而且，在一些实施例中，控制器集群清除在一段时间内(例如，每天、每若干天、每周或每若干周等)未报告为正在使用的IP地址。

在2620之后，中央控制器针对在一个或多个公共云(报告区域)中从报告测量代理接收到的每个所报告的IP地址识别(在2625处)在报告区域附近(即，在阈值距离之内)的公共云(附近区域)的集合。在一些实施例中，两个区域的接近度是根据区域之间分别测量的网络距离来确定的。在一些实施例中，过程2600使用第三方DNS服务来识别每个IP地址的近似位置，然后使用IP地址的识别出的位置来量化两个IP地址之间的距离。为所有所报告的IP地址识别出的区域的集合的列表被称为IP邻近报告。当不执行这种操作时，IP邻近报告将把所有虚拟网络区域限定为位于每个IP地址附近。

在2630处，中央控制器将IP邻近报告提供给已部署的测量代理205，该测量代理205由VNP为部署在不同公共云上的一个或多个虚拟网络部署。然后，每个测量代理周期性地(例如，每隔若干分钟或若干小时一次)测量测量代理与在IP邻近报告中被识别为在测量代理附近的每个SaaS提供方IP地址之间的距离。在一些实施例中，测量代理根据用于在这个IP地址处发起与服务器的TCP连接的延迟来计算到IP地址的这个距离。当具有这个IP地址的服务器正在响应时，测量到那个响应的时间。在一些实施例中，一旦考虑到第一响应，测量代理就主动终止TCP连接。在一些实施例中，测量代理还对成功TCP连接事件和/或损失的分组的数量进行计数。其它实施例中的测量代理使用其它测量技术，诸如以上描述的测量技术中的任何一种。

在2635处，控制器集群从测量代理接收距离测量。接下来，在2640处，控制器集群使用返回的测量(例如，从每个测量代理报告的延迟和损失数量)来识别从每个可能的入口MFN和/或从每个可能的MMCN到每个SaaS提供方(例如，到每个SaaS IP地址)的路由。为了识别路由，在一些实施例中，控制器集群执行最短路径路由识别过程，该过程依赖于基于到不同SaaS IP地址、不同MFN之间和到不同MMCN的测量而计算出的权重值。

在一些实施例中，控制器集群周期性地或每当计算出的权重值改变时(例如，基于新测量或MFN和SaaS IP地址的添加/删除)重复其路由识别过程。在一些实施例中，由于与MMCN和SaaS提供方相关联的多个出口节点将在识别到任何一个SaaS提供方的最优路由中是相关的，因此控制器集群针对多个MMCN和SaaS IP地址一起执行路由识别操作(在2640)。

在识别出这些路由之后，控制器集群将这些路由供应给(在2645处)MMCN边缘节点和MFN。例如，在一些实施例中，控制器集群向MMCN边缘节点和向MFN CFE提供转发记录(例如，指定下一跳的路由记录、指定虚拟网络出口节点的路由记录等)。通过使用这些转发记录来执行其路由操作，特定MMCN边缘节点和MFN CFE实现由控制器集群限定的最优路由(在2640处)。在一些实施例中，每当识别出新路由时，控制器集群就向MMCN边缘节点和MFN CFE供应新的路由记录。

在一些实施例中，假设通过上述过程发现的SaaS IP地址到它们所连接到的虚拟网络节点的路由距离为零(即，假设其虚拟地位于虚拟网络的公共云区域中)。在其它实施例中，公共云区域和SaaS IP地址之间的路由链路具有与之相关联的权重(如图25的示例中反映的)，并且这些权重反映了与从这些公共云区域到SaaS IP地址的路径相关联的成本(例如，测得的延迟和/或损失)。在这种方法下，连接到特定IP地址的最佳区域是从其计算出的权重值(即，根据分组延迟和损失测得的成本)小的区域。

将SaaS IP地址与多于一个公共云区域中的多于一个MEN CFE相关联的一种合理性是SaaS服务器到多个区域的距离远小于区域之间的典型距离。此外，路由源自一个公共云的流量可能成本更低，因此它将一直保留直到同一个云中的出口节点。在这种情况下，在一些实施例中，控制器集群将每个SaaS IP绑定到每个公共云中的至少一个区域，只要来自最近的区域的成本(例如，延迟和损失)低于某个成本(例如，延迟和损失)阈值即可。当路由识别过程需要计算到某个IP地址的最短路径时，它首先查看这个IP地址绑定到的区域，然后计算从每个出口节点到绑定区域的最短路径。在一些实施例中，路由器中的路由表本身不需要包括外部IP地址，因为数据消息将在隧道中携带直到目的地出口节点为止，其然后将查找隧道中的IP地址。

如上面所提到的，在一些实施例中，计算出的权重值考虑了两个公共云区域之间、公共云区域与SaaS提供方数据中心之间、或公共云区域和租户的计算端节点之间的链路中的分组延迟和/或损失的成本。在其它实施例中，根据其它类型的参数(诸如由公共云提供方收取的数据吞吐成本和/或由公共云提供方收取的计算成本(对于用于在公共云中实现MFN组件的计算元件))来计算针对每个这种链路的计算出的权重值。

为了将一个分支中的公司客户端连接到第二个分支中的公司服务器，连接将通过与相应分支位置相关联的至少两个公共云受管理转发节点(MFN)的云转发元件(CFE)。在一些实施例中，每个公共云MFN充当可以执行TCP拆分优化以帮助减少大文件的下载时间的云中继器。为了利用小文件下载进行改进，一些实施例实现了新颖的TCP拆分改进，诸如使用预定义的线程池来处理SYN请求，以及使用预定义的连接池来转发云中继器中的SYN请求。在一些实施例中，这些改进是基于内核的(例如，基于Linux内核的)改进。在一些实施例中，TCP拆分优化处理在下文中被称为K拆分，因为它使用内核套接字来避免源于用户模式实施方式的大量系统调用的惩罚。

一些实施例的虚拟网络利用由公共云提供的租户之间的公平性优化。在一些实施例中，虚拟网络提供方是公共云的付费租户。作为付费租户，在分配给它的带宽(例如，2Gbps)内，虚拟网络提供方不需要提供与其它云租户相关的公平性。所有云允许VNP在其带宽预算内发送不受限制的UDP，这一事实进一步强调了这一点。因而，一些实施例的虚拟网络在云中继器对之间(用于遍历公共云以连接两个外部计算节点)在云内部使用更进取性的拥塞控制而无需更改公共云外部的任何租户机器的配置或设置。这种方法改进了虚拟网络性能，并且以相反的直观的方式提高短距离和长距离TCP流之间的公平性。

在一些实施例中，当路由经过多个公共云而不是一个时，虚拟网络的性能可以被改进。在一些情况下，第三个TCP云中继器也可以改进性能，但是在使用主动拥塞控制时，这种改进可以是可忽略的。与当前的端到端方法相比，一些实施例的优化的虚拟WAN方法可以将文件下载时间减少一半。一些实施例还使用冗余的云中继器并跨这些冗余的中继器进行优化以获得通过公共云的多条路径。

图27图示了依赖于执行TCP拆分优化的两个云中继器的优化的虚拟网络2700的示例。在这个示例中，在法兰克福的端主机2705向在纽约的端主机2710发送流量。主机2705在下文被称为服务器，而主机2710被称为客户端。在没有图27的虚拟网络的情况下，用于将流量从主机2705转发到主机2710的默认数据传输机制沿着两者之间的BGP路径进行路由。如图28中所示，这条路径将经由一个或多个中间ISP 2825将主机2705的ISP 2815连接到主机2710的ISP 2820。在这个示例中，从主机2705到主机2710的流量的调制是经由TCP拥塞控制，其通过自适应地调整发送速率来对路径上的网络状况(拥塞、释放的容量)做出反应。

代替使用主机2705和2710的ISP 2815-2825，图27的优化的虚拟网络从主机2705直接向公共云提供方的慕尼黑数据中心2760中的地理上接近的MFN 2730发送流量，该公共云提供方在纽约也有数据中心2765。在这个示例中，来自主机2705的流量然后遍历公共云提供方的基础设施，以到达这个提供方的纽约数据中心2765中的出口MFN 2735。流量从这个MFN离开公共云，到达客户端主机2710。

图27的优化的虚拟网络2700将服务器主机2705和客户端主机2710之间的TCP连接拆分为三个单独的连接，每个连接都采用TCP(例如，CUBIC)拥塞控制。这三个连接是服务器主机2705和入口MFN 2730之间的连接2740、两个MFN 2730和2735之间的连接2745以及MTN2735和客户端主机2710之间的连接。通过将每个计算端节点2705和2710的分支位置连接到最优公共云中继器(例如，最近的中继器、具有到端节点的最快连接的中继器等)，并在这些中继器中的每一个处拆分TCP连接，图27的方法大大改进了大文件下载时间。

但是，这种方法在一些情况下不能充分改进小文件的下载时间。为了利用小文件下载进行改进，一些实施例实现了新颖的TCP拆分改进，诸如使用预定义的线程池来处理SYN请求，以及使用预定义的连接池来转发云中继器中的SYN请求。但是，在描述这些改进之前，图29-图32给出了图示在图27的拆分优化方法下文件的下载时间的示例。

在图29-图32所示的示例中，一个公司位置中的客户端机器2905从另一个公司位置中的服务器机器2910请求内容。每个请求的分组具有最大段尺寸(MSS)。这些请求是在TCP上使用HTTP完成的，并且初始TCP窗口处为一个MSS，并且没有损失。而且，在这些示例中，Rc和Rs分别是客户端侧中继器2915和服务器侧云中继器2920。

图29图示了理想的从头开始方法，其中对内容的请求将直接通过，从而触发所有响应分组的传输。在这种虚构方法下，沿着路径在任何两个跳之间不执行TCP握手。到第一字节时间(TTFB)仅为一个往返时间(RTT)，这是最低的可能TTFB。在这个示例中，内容以三个分组下载。由于第二和第三个响应分组在获得第一个响应分组之后不久由客户端机器2905接收，因此下载时间不太高。

图30图示了其中客户端机器2905和服务器机器2910通过执行三次TCP握手来建立端对端连接的情况。再次，这个示例中的内容以三个分组下载。如图所示，与图29的理想TTFB相比，这种方法对TTFB增加了一个RTT延迟。此外，在接收到第一响应分组之后为客户端的ACK等待达一个RTT进一步增加了整体下载(即，接收三个响应分组所花费的时间)的延迟。在这个示例中，服务器在从客户端接收到针对第二个分组的ACK之前发送第三个分组，因为客户端和服务器使用CUBIC TCP拥塞控制，这非线性地增加TCP窗口尺寸，以允许在客户端确认接收到更早的分组(在这种情况下为第二个分组)之前在TCP窗口中发送多个分组。

图31图示了本发明的一些实施例的TCP拆分方法。在这种方法下，客户端侧云中继器2915和服务器侧云中继器2920通过执行TCP拆分操作来充当TCP连接端点。这种方法导致TCP三次握手的三个集合，如图所示，这改进了大流量的总下载时间，因为它减少了TCP端点(例如，服务器2910)接收到针对其SYN-ACK的ACK和分组的时间。在图31中，客户端和服务器再次使用CUBIC TCP拥塞控制，这非线性地增加了TCP窗口尺寸，以允许在客户端确认接收到更早的分组之前在TCP窗口中发送多个分组。在这个示例中，服务器可以在接收到客户端已接收到第二个分组的确认之前发送分组三至七。

图32图示了示例，该示例示出了当客户端侧云中继器2915和服务器侧云中继器2920执行TCP拆分操作时，对于小流量，TTFB和总下载时间受到不利影响。具体而言，它示出客户端2905接收第一分组的TTFB以及客户端获得三分组流的总下载时间比图30的端到端TCP连接的TTFB和总下载时间慢。

图32图示了五种类型的延迟，每种类型被标记为1-5。第一延迟(延迟1)考虑TCP端点在用SYN-ACK回复SYN(即，使其SYN-ACK被确认)之后必须等待接收ACK的时间。这个延迟发生在图32中的每对相邻TCP端点之间。客户端机器2905与云中继器2915之间的这种延迟的实例在图32中用图例Δc注释。

第二延迟(延迟2)考虑TCP端点必须创建重复TCP连接线程以与从客户端机器2905到服务器机器2910的一系列相继TCP连接端点中的后续TCP端点执行三次握手的时间。第二延迟被称为分叉延迟，因为表达分叉通常被用于指创建重复线程的动作。

第三延迟(延迟3)考虑两个云中继器2915和2920设置TCP连接所需的时间。这个延迟被称为连接设置延迟。第四延迟(延迟4)考虑在云中继器2920接收到第二分组和第三分组并且等待直到接收到云中继器2915已经接收到第一分组的确认为止之后，云中继器2915接收到该第二分组和第三分组的时间。这个延迟被称为TCP窗口递增延迟。第五延迟(延迟5)是服务器2910等待云中继器2920确认接收到第一分组的时间。这个延迟在图32中用图例Δs注释。

如以下进一步描述的，除了客户端侧延迟Δc和服务器侧延迟Δs之外，因为一些实施例不改变客户端位置和服务器位置处的机器或装置配置，图32中所示的每个延迟可以用新颖的基于内核的TCP拆分改进来解决。但是，如下面所提到的，一些实施例通过使云中继器Re和Rs靠近客户端和服务器位置来最小化这些延迟Δc和Δs。

图33-图37图示了可以被用于消除图32中识别出的延迟1-4的四个可组合的TCP拆分改进。具体而言，图33图示了使用early-SYN方法来移除SYN-ACK和ACK延迟(图32中的延迟1)，图34图示了使用线程池来移除分叉延迟(图32中的延迟2)，图35图示了使用连接池来消除连接设置延迟(图32中的延迟3)，并且图36图示了使用Turbo-Start TCP从而消除TCP窗口递增延迟(图32中标记为延迟4)。

在云中继器2915从客户端机器2905接收到SYN分组之后，图33的early-SYN方法将来自云中继器2915的SYN分组发送到云中继器2920。云中继器2915执行这个操作而无需等待与客户端机器2905完成三次握手。充当云中继器(即，充当中间TCP拆分节点)的虚拟网络MFN捕获这个第一个SYN分组并触发到下一个节点的新连接的开始。这允许云中继器2915并行建立拆分连接的两个支腿。这种方法移除了在图32中标记为延迟1的SYN-ACK和ACK延迟。但是，这种方法不能移除分叉延迟2，因为云中继器2915必须浪费时间来起动用于处理将SYN分组转发到云中继器2920的线程。

为了消除分叉延迟，云中继器2915和2920创建可重用内核线程的池，用于在接收到传入的SYN分组之后处理传出的SYN分组。图34图示了这种线程池方法如何消除为新的拆分连接创建新的内核线程所花费的时间。为每个新的拆分连接创建新的内核线程是耗时的并且大大地增加了连接抖动。一些离群值可能需要数十毫秒，从而极大地影响了性能。对于由时间敏感的应用使用的小文件/对象，这种抖动甚至可能使层4优化的虚拟网络的优势无效。

为了减轻这个问题，在一些实施例中，每个云中继器创建可重用内核线程的池，以处理与在从源机器到目的地机器的路径中的后续TCP端点设置新的拆分连接。如上面所提到的，源机器和/或目的地机器可以驻留在多机器节点(诸如分支机构或数据中心)中。在一些此类情况下，TCP连接以及通过公共云数据中心的路径在多机器节点处在网关之间。但是，为简洁起见，即使当从在一个或多个公共云上限定的虚拟网络的角度来看路径终止于网关，本文档中的讨论有时还指源和目的地机器之间的路径。

可重用内核线程是睡眠线程，等待被指派给新任务。在图34中消除了图33的分叉延迟，因为如图所示，中间云中继器2915可以使用先前创建的线程之一在从前一跳接收到SYN分组后立即将SYN分组发送到下一个云中继器2920。在图34中，这个SYN分组被指定为SYN'分组，因为它没有在两个云中继器2915和2920之间发起三次握手。代替地，它仅仅指示云中继器2920将SYN分组转发到目的地机器2910(或目的地机器的分支或数据中心位置)，并与这个目的地机器(或与这个机器的分支或数据中心位置的网关)执行三次握手。在一些实施例中，SYN'分组是将SYN分组封装在发送到下一跳云中继器的另一个分组中的特殊分组。下一跳云中继器将知道它需要从SYN'分组中提取这个SYN分组并使用这个SYN分组来与目的地机器2910或目的地机器的分支机构或数据中心位置执行三次握手。

图35图示了连接池方法，其使用云中继器之间的预先建立的连接来消除与沿着从源机器到目的地机器的路径通过两个公共云在第一云中继器2915和第二云中继器2920之间设置连接相关联的延迟。在这两个云中继器之间使用预先建立的连接改进了长连接(即，其中两个云中继器之间的RTT占主导地位的连接)上的性能。目的是消除长的三次握手的延迟。

为了实现这个目标，一些实施例将可以用作TCP拆分优化入口/出口节点的每个特定MFN抢先连接到(1)可以为特定MFN使用TCP拆分优化出口/入口节点并且(2)远离特定MFN的每个另外的MFN。在一些实施例中，TCP拆分优化操作由MFN的TCP优化引擎220执行。在一些实施例中，TCP优化引擎220在与MFN的云转发元件235(CFE)相同的机器(例如，相同的VM或容器)上执行。

一些实施例在每对远距离中继器之间创建预先建立的连接的池(连接池)，并在每次使用连接时重新装满这个池。这种方法消除了从云中继器(第一中继器)发送SYN分组与然后在从另一个云中继器(第二中继器)接收到SYN-ACK之后从该中继器(第一中继器)发送ACK之间的延迟。因为第一中继器利用其SYN分组识别出它为与第二中继器进行的这个通信会话已从连接池中选择的先前创建的连接，所以这个延迟被消除。

图36图示了使用Turbo-Start TCP来消除TCP窗口递增延迟，其在图32中被标记为延迟4。如上面所提到的，现有的TCP拥塞控制处理非线性地增加TCP窗口尺寸，以允许在客户端确认接收到更早的分组之前在TCP窗口中发送越来越多的分组。在这些现有的TCP拥塞控制处理(例如，CUBIC TCP处理)中，TCP窗口尺寸是自上次拥塞事件以来的时间的函数，其中转折点被设置为事件之前的窗口尺寸。

由于云提供方负责维持不同租户之间的公平性，因此无需使用遗留或默认TCP拥塞控制机制来维持TCP友好性。此外，拥塞在云内不再是一个问题。因此，一些实施例在层4优化的云中继器上配置为比正常的初始拥塞窗口(CWND)和接收窗口(RWIN)更大的窗口。如图36中所示，这些更大的窗口允许云中继器2920立即将第二分组和第三分组转发到云中继器2915，而无需来自云中继器2915的ACK来确认接收到第一分组。此外，一些实施例的Turbo-Start TCP处理增加了用于云中继器的套接字缓冲器，使得存储器尺寸不限制云内流的性能。一些实施例不改变在任何面向互联网的流上使用的CWND，因此不影响任何多计算机节点(例如，分支机构或数据中心)。

除了使用图33-图36的四个改进来避免执行TCP拆分操作中的延迟1-4之外，一些实施例的每个云中继器还使用新颖的内核模块(称为K拆分)，该模块相当快地实现基于内核的TCP拆分操作。在一些实施例中，K拆分在Ubuntu中实现。此外，在一些实施例中，K拆分使得能够利用可容易地部署的商品VM以及标准编程API(POSIX/Berkeley套接字)。

以内核模式实现K拆分的决定的优势在于，它允许虚拟网络(1)利用仅在内核中可用的资源，诸如Netfilter，以及(2)避免源自大量系统调用的惩罚。在内核中实现K拆分还消除了去往和来自用户空间的冗余转变，并避免了不必要的系统调用。由于所有套接字API都有对应的内核对等物的事实，进一步简化了在内核中实现K拆分组件的决定。而且，在一些实施例中，内核内实施方式不具有用于可伸缩的I/O事件通知机制(epoll)的内核API。因此，一些实施例使用内核线程来服务套接字。

在一些实施例中，K拆分具有三个组件：(1)监听传入连接的源侧第一套接字；(2)将特定TCP分组重定向到源侧第一套接字的IP表规则；以及(3)连接到目的地或到目的地的下一跳的目的地侧第二套接字，并且因此完成拆分连接的第二个支腿。一旦建立了两个连接，单个流的字节被从一个套接字读取，并且然后由两个处理程序之一(源侧处理程序或目的地侧处理程序)转发到其对等方。这种转发在两个方向上发生。当任一连接经由错误或TCP FIN标志而终止时，另一个连接将正常(gracefully)关闭。这意味着正在传输(即，尚未确认)的字节将到达其目的地，但将不发送新的字节。

一些实施例特别地挑选用于从套接字读取数据和向套接字写入数据的缓冲器尺寸。例如，代替使用较小的4KB缓冲器，一些实施例使用16KB和64KB缓冲器尺寸。为了实现Early-SYN，一些实施例使用Linux Netfilter钩子(hook)，因为没有标准API使得能够捕获第一SYN分组。添加的钩子捕获TCP分组。然后为目的地和SYN标志解析报头。利用这个信息，K拆分选择预分配的内核线程，其发起到目的地的连接或沿着到目的地的路径的下一跳。捕获SYN允许中继器并发地建立连接的两侧。

为了实现线程池，每个拆分连接由两个处理程序处理，在一些实施例中，这两个处理程序是专用的内核线程。每个处理程序从一个套接字接收并写入其对等方。每个处理程序负责连接的一个方向。一些实施例通过套接字使用阻塞发送/接收调用，以保持实施方式简单；这也意味着每个活动套接字都需要内核线程。新的内核线程的创建是代价高昂的过程，因为离群值会消耗若干毫秒的时间，从而导致抖动现象。为了减轻这个问题以及从中断上下文创建新的内核线程的问题，一些实施例创建可重用线程的池以实现处理程序。

这个池中的每个内核线程最初在状态TASK_INTERRUPTIBLE(准备执行)下等待。当将线程分配给特定处理程序时，发生两件事：(1)设置要执行的函数，以及(2)调度任务以运行(TASK_RUNNING)。当函数终止时，线程返回到状态TASK_INTERRUPTIBLE，并且返回到挂起的线程的列表，等待再次分配。因此，预先分配的内核线程的池移除了创建新的内核线程的开销。

为了实现预先建立的连接，一些实施例使用目的地侧第二套接字。与源侧第一套接字不同，在一些实施例中，这个套接字监听来自正在发起新的预先建立的连接的其它中继器的连接。为了防止连接在被使用前关闭，套接字用KEEP_ALIVE配置。在建立后，这些连接等待从发起对等方发送的目的地地址。目的地址通过连接本身发送。这个信息在最开始的字节中发送，并且所有随后的字节都属于转发的流。一旦接收到目的地地址，就建立到目的地的连接，并建立拆分连接的第二个支腿。就像在基本设计中一样，流在套接字之间转发。一些实施例对这些套接字禁用Nagle的算法，以便保持到第一字节时间短。在不禁用它的情况下，在一些实施例中，到第一字节时间增加了几百毫秒。

一些实施例经由proc文件系统(procfs)来控制线程池的尺寸、预先建立的连接的目的地以及它们的数量，该proc文件系统是Linux中的特殊文件系统，其在类似于文件的分层的结构中给出有关过程的信息和其它系统信息，与跟踪方法或直接访问内核存储器相比，提供了更方便和更标准化的用于动态访问内核中保存的处理数据的方法。

对于10K拆分连接，套接字缓冲器的存储器占用量可能超过一些服务器的共享L3高速缓存的尺寸。可能审慎的是将epoll API扩展到内核并且从而为每个拆分连接节省18KB的存储器。除了扩展epoll API之外，一些实施例还尝试避免在内核中不必要地复制套接字API，因为这个API不是零副本。而且，网络I/O由中断服务。对于虚拟机，这意味着昂贵的VM退出。因此，一些实施例使用SRIOV设备和带有支持Intel的vt-d发布的中断的CPU的机器来实现接近裸机的性能。

图37图示了在一些实施例中在公共云数据中心中的主机计算机上实现的云中继器的K拆分模块3700。如图所示，这个模块包括K拆分处理器3705、IP表3710、源侧套接字3715、目的地侧套接字3720、源侧处理程序3725和目的地侧处理程序3730。K拆分处理器向主机计算机的操作系统的筛选程序3750注册(例如，向Linux操作系统的Netfilter注册)，以接收主机计算机为云中继器接收的SYN分组的通知。

对于每个这样的SYN分组，K拆分处理器3705使用SYN分组的属性(例如，SYN分组的报头中的源和目的地IP地址)来识别IP表3710中的指定沿着通过公共云从源机器到目的地机器的路由的下一跳的记录。基于识别出的下一跳，K拆分处理器(1)从在K拆分的云中继器和其它云中继器之间限定的预先建立的连接的集合3760中选择到下一跳的预先建立的连接，(2)将这个选择的连接的套接字分配为目的地侧套接字3720，并且(3)选择预定义的处理程序的集合3755中的一个以实现目的地侧处理程序3730以处理沿着到目的地的路由到下一跳的TCP连接(例如，以传递SYN分组)。通过所选择的连接，在K拆分模块3700的目的地侧套接字3720和下一跳云中继器(或者当下一跳是目的地机器时为目的地机器)的K拆分模块的源侧套接字3715之间交换分组。

K拆分模块3700还分配源侧套接字3715以存储与前一跳交换的分组(例如，前一跳的云中继器的目的地侧套接字3720或源机器)，并分配源侧处理程序3725以处理与前一跳的TCP连接。源侧处理程序通过从源侧套接字3715中检索这些分组并将其存储在这个套接字的对应目的地侧套接字3720中来处理来自前一跳的分组。相反，目的地侧处理程序3730通过从目的地侧套接字3720中检索这些分组并将其存储在这个套接字的对应源侧套接字3715中来处理来自下一跳的分组。

图38图示了一些实施例的K拆分模块3700一旦接收到这个筛选程序已经捕获了第一SYN分组的Netfilter中断就执行的过程3800。这个过程3800分配源侧套接字和目的地侧套接字以及处理程序以处理由新的SYN分组发起的新连接。过程3800还通过将用于源侧套接字和目的地侧套接字的处理程序最初固定到主机计算机的同一处理器核心以便这些处理程序可以使用共用的数据结构(例如，树)来快速识别用于连接的匹配套接字对，使用新颖的技术快速配对源侧套接字和目的地侧套接字。这些分配和配对操作将通过参考图39-图44中所示的示例进行描述。

如图所示，当K拆分模块3700接收到这个筛选程序已捕获第一SYN分组的中断Netfilter中断时，过程3800开始。图39图示了这个中断的处理最初被指派给主机计算机处理器的核心0。这个指派可以是随机的，或者基于某种启发方法。基于这个分组的属性(例如，SYN分组的报头中的源和目的地IP地址)，在这个核心上运行的中断过程识别(在3805处)IP表3710中指定沿着通过一个或多个公共云数据中心从源机器到目的地机器的路由的下一跳的记录。这个过程还分配(在3805处)预定义的处理程序3750之一以充当目的地侧处理程序3720。这个过程最初通过散列SYN分组的五个元组(源和目的地IP地址、源和目的地端口以及协议)并使用这个散列在使散列值和核心标识符相关联的查找表中识别核心标识符来将这个处理程序固定到处理器的核心2。识别出的核心标识符指定目的地侧处理程序应当固定到的核心。

图40图示了最初被指派给核心2的目的地侧处理程序3720。它还图示了这个处理程序的操作。如图38和40中所示，目的地侧处理程序最初选择(在3810处)到下一跳的预先建立的连接以连接到下一跳(例如，将接收到的SYN分组传递到下一跳云中继器或目的地机器)。在3810处，目的地侧处理程序还将目的地侧套接字3720限定为预先建立的连接的套接字。

它还限定(在3810处)搜索记录，该搜索记录存储所分配的目的地侧套接字3720的身份以及与这个套接字相关联的键。在一些实施例中，键是接收到的SYN分组的报头中的源和目的地IP地址以及源和目的地端口地址。如下面进一步描述的，在一些实施例中，源侧处理程序和目的地侧处理程序使用这个键来匹配两个搜索记录，这进而允许它们匹配源侧套接字和目的地侧套接字。在一些实施例中，目的地侧处理程序3720将其创建的搜索记录添加(在3810处)到存储在核心2的本地高速缓存中的本地树结构，使得这个核心可以随后在需要查找用以匹配到源侧搜索记录的目的地侧搜索记录以匹配两个套接字时快速搜索这个树结构。

在3810处，当下一跳是目的地时，目的地侧处理程序将SYN分组发送到目的地，或者当下一跳是另一个云中继器时，将SYN'分组发送到下一跳云中继器。当下一跳是目的地机器时，目的地侧处理程序与下一跳目的地机器执行三次握手，以与这个机器建立TCP连接。如上面所提到的，当目的地机器在分支机构或数据中心中时，SYN分组被转发到这个位置处的网关，并且目的地侧处理程序将SYN分组转发到这个位置处的网关并利用这个网关建立TCP连接。

另一方面，到下一跳云中继器的SYN'分组是特殊分组，其将SYN分组封装在发送到下一跳云中继器的另一个分组中。下一跳云中继器将知道它需要从SYN'分组中提取这个SYN分组并使用这个SYN分组来：(1)当目的地机器是从下一跳的后续跳时，与目的地机器执行三次握手，或者(2)当另一个云中继器是后续跳时，将另一个SYN'分组中的SYN分组转发到该另一个云中继器。然后，目的地侧处理程序进入(在3810处)等待周期，以供源侧处理程序将两个套接字配对并唤醒目的地侧处理程序，以便目的地侧处理程序可以通过将分组从目的地侧套接字移动到源侧套接字来开始处理分组。

在3815处，过程3800执行一系列操作以接受从源的连接。图41图示了这些操作落在主机计算机的处理器的核心3上。再次，这些操作是随机地或基于某种启发方法落在这个核心上的。如图所示，过程(在3815处)(1)分配源侧套接字3715，(2)分配搜索结构以存储这个套接字的身份及其相关联的键，键同样是接收到的SYN分组的报头中的源和目的地IP地址以及源和目的地端口地址，并且(3)分配预定义的处理程序之一，以便为这个新连接实现源侧处理程序3725。在3815处，处理通过从SYN分组的五个元组生成散列值并使用这个散列在使散列值与核心标识符相关联的查找表中识别核心标识符来将这个源侧处理程序3725的执行指派给核心2。识别出的核心标识符指定目的地侧处理程序应当固定到的核心。由于在3805和3815处使用了相同的散列函数和查找表，因此源侧处理程序和目的地侧处理程序将总是最初固定到同一核心。

图42图示了源侧处理程序在核心2上的操作。在图38的3820处也图示了这些操作。如图所示，源侧处理程序使用在3815处分配的搜索记录的搜索键来查找存储在本地搜索树中的匹配搜索记录(即，具有匹配搜索键的目的地侧搜索记录)。在3810处分配的搜索记录包含目的地侧套接字的身份，而在3815处分配的搜索记录包含源侧套接字的身份。因此，匹配这两个搜索记录允许K拆分过程3800将两个相关联的源侧套接字和目的地侧套接字配对以用于新的连接。一旦搜索记录匹配，源侧处理程序就从搜索树中移除搜索记录，以便使本地树结构保持小，以便更快地进行后续搜索。

在匹配套接字之后，源侧处理程序然后唤醒目的地侧处理程序。此时，两个处理程序都可以开始在两个套接字之间转发分组，其中源侧处理程序将分组从源套接字移动到目的地套接字，而目的地侧处理程序将分组从目的地套接字移动到源套接字，如图43中所示。一旦套接字已配对并且处理程序开始在套接字之间移动分组，处理程序就不再固定到任何一个核心并且可以在不同的时钟周期中在不同的核心上执行，如图44中所示。如上面所提到的，最初将两个处理程序指派给相同的核心，以允许它们在同一搜索树中存储和搜索对应的搜索记录，以便快速识别对应的套接字对。通过使用一个核心在核心本地高速缓存中搜索一个搜索结构来配对两个套接字要比使用多个核心搜索所有核心都可访问的一个全局搜索结构快得多。

许多上述特征和应用被实现为被指定为记录在计算机可读存储介质(也称为计算机可读介质)上的指令集的软件处理。当这些指令由一个或多个处理单元(例如，一个或多个处理器、处理器的核心或其它处理单元)执行时，它们使(一个或多个)处理单元执行指令中指示的动作。计算机可读介质的示例包括但不限于CD-ROM、闪存驱动器、RAM芯片、硬盘驱动器、EPROM等。计算机可读介质不包括无线地或通过有线连接传递的载波和电子信号。

在本说明书中，术语“软件”意在包括驻留在只读存储器中的固件或存储在磁性存储装置中的应用，其可以被读入存储器以供处理器处理。而且，在一些实施例中，可以将多个软件发明实现为更大程序的子部分，同时保留不同的软件发明。在一些实施例中，多个软件发明也可以被实现为分开的程序。最后，一起实现这里描述的软件发明的分开的程序的任意组合在本发明的范围内。在一些实施例中，软件程序在被安装以在一个或多个电子系统上操作时限定实行并执行软件程序的操作的一种或多种具体机器实施方式。

图45概念性地图示了计算机系统4500，利用该计算机系统4500来实现本发明的一些实施例。计算机系统4500可以被用于实现任何上述主机、控制器和管理器。照此，它可以被用于执行任何上述过程。这个计算机系统包括各种类型的非暂态机器可读介质以及用于各种其它类型的机器可读介质的接口。计算机系统4500包括总线4505、(一个或多个)处理单元4510、系统存储器4525、只读存储器4530、永久存储设备4535、输入设备4540和输出设备4545。

总线4505共同表示通信上连接计算机系统4500的众多内部设备的所有系统总线、外围和芯片集总线。例如，总线4505将(一个或多个)处理单元4510与只读存储器4530、系统存储器4525和永久存储设备4535通信上连接。

(一个或多个)处理单元4510从这些各种存储单元中检索要执行的指令和要处理的数据，以便执行本发明的过程。在不同的实施例中，(一个或多个)处理单元可以是单个处理器或多核处理器。只读存储器(ROM)4530存储(一个或多个)处理单元4510和计算机系统的其它模块所需的静态数据和指令。另一方面，永久存储设备4535是读写存储器设备。这个设备是非易失性存储器单元，即使计算机系统4500关闭，它也存储指令和数据。本发明的一些实施例使用大容量存储设备(诸如磁盘或光盘及其对应的磁盘驱动器)作为永久存储设备4535。

其它实施例使用可移动存储设备(诸如软盘、闪存驱动器等)作为永久存储设备。就像永久存储设备4535一样，系统存储器4525是读写存储器设备。但是，与存储设备4535不同，系统存储器是易失性读写存储器，诸如随机存取存储器。系统存储器存储处理器在运行时所需的一些指令和数据。在一些实施例中，本发明的过程被存储在系统存储器4525、永久存储设备4535和/或只读存储器4530中。(一个或多个)处理单元4510从这些各种存储器单元中检索要执行的指令和要处理的数据，以便执行一些实施例的处理。

总线4505还连接到输入设备4540和输出设备4545。输入设备使用户能够向计算机系统传达信息并选择到计算机系统的命令。输入设备4540包括字母数字键盘和指点设备(也称为“光标控制设备”)。输出设备4545显示由计算机系统生成的图像。输出设备包括打印机和显示设备，诸如阴极射线管(CRT)或液晶显示器(LCD)。一些实施例包括诸如触摸屏之类的设备，其既充当输入设备又充当输出设备。

最后，如图45中所示，总线4505还通过网络适配器(未示出)将计算机系统4500耦合到网络4565。以这种方式，计算机可以是计算机网络(诸如局域网(LAN)、广域网(WAN)或内联网)的网络的一部分或网络的网络(诸如互联网)的一部分。计算机系统4500的任何或所有部件可以与本发明结合使用。

一些实施例包括电子部件，诸如微处理器、存储装置和存储器，其将计算机程序指令存储在机器可读或计算机可读介质(可替代地称为计算机可读存储介质、机器可读介质、或机器可读存储介质)中。此类计算机可读介质的一些示例包括RAM、ROM、只读光盘(CD-ROM)、可记录光盘(CD-R)、可重写光盘(CD-RW)、只读数字多功能光盘(例如，DVD-ROM、双层DVD-ROM)、各种可记录/可重写DVD(例如，DVD-RAM、DVD-RW、DVD+RW等)、闪存(例如，SD卡、mini-SD卡、micro-SD卡等)、磁性和/或固态硬盘驱动器、只读和可记录的盘、超密度光盘、任何其它光学或磁性介质以及软盘。计算机可读介质可以存储可由至少一个处理单元执行并且包括用于执行各种操作的指令集的计算机程序。计算机程序或计算机代码的示例包括机器代码(例如由编译器产生的)以及文件，包括由计算机、电子部件或微处理器使用解释器执行的高级代码。

虽然以上讨论主要是指执行软件的微处理器或多核处理器，但是一些实施例是由一个或多个集成电路(诸如专用集成电路(ASIC)或现场可编程门阵列(FPGA))执行的。在一些实施例中，此类集成电路执行存储在电路本身上的指令。

如本说明书中使用的，术语“计算机”、“服务器”、“处理器”和“存储器”均指电子或其它技术设备。这些术语不包括一个人或一群人。为了本说明书的目的，术语显示或在显示是指在电子设备上显示。如本说明书中所使用的，术语“计算机可读介质”、“计算机可读介质”和“机器可读介质”完全限于以计算机可读的形式存储信息的有形物理对象。这些术语不包括任何无线信号、有线下载信号以及任何其它短暂或暂态的信号。

虽然已经参考许多具体细节描述了本发明，但是本领域普通技术人员将认识到的是，在不脱离本发明的精神的情况下，可以以其它具体形式来实施本发明。例如，上述示例中的若干示例说明了虚拟网络提供方的公司租户的虚拟公司WAN。本领域普通技术人员将认识到的是，在一些实施例中，虚拟网络提供方在一个或多个公共云提供方的若干公共云数据中心上为非公司租户(例如，学校、学院、大学、非营利实体等)部署虚拟网络。这些虚拟网络是连接非公司实体的多个计算端点(例如，办公室、数据中心、远程用户的计算机和设备等)的虚拟WAN。

上述若干实施例在覆盖封装报头中包括各种数据。普通技术人员将认识到的是，其它实施例可能不使用封装报头来中继所有这种数据。例如，代替在覆盖封装报头中包括租户标识符，其它实施例从转发数据消息的CFE的地址中导出租户标识符，例如，在一些实施例中，其中不同租户在公共云中部署了其自己的MFN，租户身份与处理租户消息的MFN相关联。

而且，若干附图概念性地图示了本发明的一些实施例的处理。在其它实施例中，这些处理的具体操作可以不按照这些图中所示和描述的确切次序来执行。具体操作可以不在一个连续的操作系列中执行，并且不同的具体操作可以在不同实施例中执行。此外，处理可以使用若干子处理来实现，或者作为更大的宏处理的一部分来实现。因此，本领域普通技术人员将理解的是，本发明不限于前述说明性细节，而是由所附权利要求书限定。

Claims

1.一种用于限定通过在用于实体的一个或多个公共云的集合上限定的虚拟网络到软件即服务SaaS提供方的多条路由的方法，所述方法包括：

向公共云的集合中多个受管理转发节点(MFN)中的每个MFN提供识别针对MFN的SaaS提供方的标识符，以生成量化MFN与识别出的SaaS提供方之间的网络路径的属性的测量；

从每个MFN接收针对识别出的SaaS提供方的测量；

基于接收到的测量，选择至少两个MFN的集合以用于从虚拟网络到达SaaS提供方，MFN的所述集合不包括多个MFN中的全部MFN；以及

使用所选择的至少两个MFN的集合来限定通过所述虚拟网络从多机器计算节点到所述SaaS提供方的路由，所述多机器计算节点属于所述实体，位于所述公共云的集合的外部，且包括边缘转发元件，所述边缘转发元件将所述多机器计算节点处的多个计算机通过至少一个MFN连接至所述虚拟网络；以及

基于所限定的路由，将一组转发规则提供至所述多机器计算节点的所述边缘转发元件以用于将数据消息经由所选择的MFN中的一者和所述虚拟网络转发至所述SaaS提供方。

2.如权利要求1所述的方法，其中，针对SaaS提供方的标识符是与SaaS提供方相关联的网络地址。

3.如权利要求2所述的方法，其中，网络地址是与SaaS提供方的一个或多个数据中心的集合相关联的网络地址。

4.如权利要求1所述的方法，其中

向所述多个MFN中的每个MFN提供识别SaaS提供方的标识符包括向所述多个MFN中的每个MFN提供识别针对MFN的多个SaaS提供方的标识符，以生成量化MFN与每个识别出的SaaS提供方数据中心之间的连接的属性的测量，以及

选择至少两个MFN的集合以用于到达SaaS提供方包括对于SaaS提供方的集合中的每个SaaS提供方选择至少两个MFN以用于到达SaaS提供方。

5.如权利要求4所述的方法，其中，使用所述MFN的集合来限定到达每个SaaS提供方的路由包括：

生成路由图，以识别从在虚拟网络外部的实体的多机器计算节点通过虚拟网络到每个SaaS提供方的路由；

使用接收到的测量来计算路由图中的链路的权重；以及

使用路由图来执行路由识别过程，以识别到SaaS提供方的路由，所述路由针对每个SaaS提供方使用用于那个SaaS提供方的MFN的集合。

6.如权利要求5所述的方法，其中提供所述一组转发规则包括将路由提供给用于限定虚拟网络的MFN以及提供给在虚拟网络外部的实体的至少一个多机器计算节点，每条路由识别用于遍历从所述多机器计算节点到SaaS提供方的路由路径的下一跳或到SaaS提供方的路由路径。

7.如权利要求1所述的方法，其中，每个MFN生成关于与MFN和SaaS提供方之间的路径相关联的多个属性的多个测量，所述方法还包括基于从MFN接收到的多个测量来计算每个MFN和SaaS提供方之间的路径的权重值。

8.如权利要求7所述的方法，其中，所述多个测量包括针对SaaS提供方和每个MFN之间的路径的消息损失率和消息延迟。

9.如权利要求8所述的方法，其中，所述多个测量还包括与SaaS提供方和每个MFN之间的路径相关联的财务成本。

10.如权利要求1所述的方法，其中，每个MFN具有测量代理，所述测量代理与SaaS提供方交换消息以生成针对MFN的测量。

11.一种存储用于限定通过在用于实体的一个或多个公共云的集合上限定的虚拟网络到软件即服务SaaS提供方的多条路由的程序的非暂态机器可读介质，所述程序包括用于以下的指令集：

从每个MFN接收针对识别出的SaaS提供方的测量；

使用所选择的至少两个MFN的集合来限定通过虚拟网络从多机器计算节点到所述SaaS提供方的路由，所述多机器计算节点属于所述实体，位于所述公共云的集合的外部，且包括边缘转发元件，所述边缘转发元件将所述多机器计算节点处的多个计算机通过至少一个MFN连接至所述虚拟网络；以及

12.如权利要求11所述的非暂态机器可读介质，其中，针对SaaS提供方的标识符是与SaaS提供方相关联的网络地址。

13.如权利要求12所述的非暂态机器可读介质，其中，网络地址是与SaaS提供方的一个或多个数据中心的集合相关联的网络地址。

14.如权利要求11所述的非暂态机器可读介质，其中

用于向所述多个MFN中的每个MFN提供识别SaaS提供方的标识符的指令集包括用于向所述多个MFN中的每个MFN提供识别针对MFN的多个SaaS提供方的标识符以生成量化MFN与每个识别出的SaaS提供方数据中心之间的连接的属性的测量的指令集，以及

用于选择至少两个MFN的集合以用于到达SaaS提供方的指令集包括用于对于SaaS提供方的集合中的每个SaaS提供方选择至少两个MFN以用于到达SaaS提供方的指令集。

15.如权利要求14所述的非暂态机器可读介质，其中，用于使用所述MFN的集合来限定到达每个SaaS提供方的路由的指令集包括用于以下的指令集：

生成路由图，以识别从在虚拟网络外部的实体的所述多机器计算节点通过所述虚拟网络到每个SaaS提供方的路由；

使用接收到的测量来计算所述路由图中的链路的权重；以及

使用所述路由图来执行路由识别过程，以识别到所述SaaS提供方的路由，所述路由针对每个SaaS提供方使用用于那个SaaS提供方的MFN的集合。

16.如权利要求15所述的非暂态机器可读介质，其中，用于提供所述一组转发规则的所述指令集还包括用于将路由提供给用于限定所述虚拟网络的MFN以及提供给在所述虚拟网络外部的实体的至少一个多机器计算节点的指令集，每条路由识别用于遍历从所述多机器计算节点到SaaS提供方的路由路径的下一跳或到SaaS提供方的路由路径。

17.如权利要求11所述的非暂态机器可读介质，其中，每个MFN具有测量代理，所述测量代理与所述SaaS提供方交换消息以生成针对所述MFN的测量。

18.如权利要求17所述的非暂态机器可读介质，其中，至少两个MFN当两个MFN与同一公共云相关联时共享一个测量代理。

19.如权利要求11所述的非暂态机器可读介质，其中，针对所述SaaS提供方的标识符是网络地址，所述程序还包括用于以下的指令集：

在提供标识符之前将SaaS提供方的列表提供给MFN的子集，以及

指示MFN的所述子集执行DNS操作以识别与列表上的SaaS提供方相关联的IP地址。

20.如权利要求11所述的非暂态机器可读介质，其中，用于向所述多个MFN中的每个MFN提供标识符的指令集包括用于以下的指令集：

为所述多个MFN中的每个MFN生成识别在MFN附近的SaaS提供方的邻近报告；以及

指示每个MFN生成针对MFN和在MFN的邻近报告上的每个SaaS提供方之间的连接路径测量。