四、中间盒

中间盒 Middleboxs，是逻辑集中式控制的的实现方式，而 SDN 也是采用了这种方式。

阅读资料

• Making Middleboxes Someone Else’s Problem: Network Processing as a Cloud Service, SIGCOMM’12

论文阅读： 将中间盒外包到云服务

本讲导览

现代企业几乎普遍部署中间盒处理服务来提升网络的安全性和性能。尽管如此，我们发现如今的中间盒基础设施成本高昂，管理复杂。鉴于云计算能够降低成本、简化管理，并提供弹性和容错能力，我们认为中间盒处理可以从将其外包到云端中获益。然而，得出一个可行的实现方案是具有挑战性的，因为需要在不牺牲性能或增加网络复杂性的前提下，实现与传统中间盒部署功能上的等效性。

我们提出、设计并实现了 APLOMB，这是一个将企业中间盒处理外包到云端的实用服务。我们展示了 APLOMB 能够解决网络管理员面临的实际问题，可以外包典型大型企业网络中超过 90%的中间盒硬件设备。此外，在对一个真实企业的案例研究中，APLOMB 平均只增加了 1.1 毫秒的延迟，并带来了中位值 3.8%的带宽膨胀

1. 介绍

现代企业网络几乎无一例外地依赖于各种专用设备或中间盒。中间盒提供了诸多有价值的好处，例如改善安全性（如防火墙和入侵检测系统）、提升性能（如代理服务器）、以及减少带宽成本（如广域网优化器）。然而，中间盒也带来了高昂的基础设施和管理成本，原因在于其复杂且专门的处理方式、不同设备和供应商之间的管理工具差异，以及策略交互问题。我们设想，企业可以将其流量的处理外包给运行在云中的第三方中间盒服务提供商，我们通过对 57 个企业网络的研究，旨在理解真实世界中的中间盒部署情况、网络管理员面临的“痛点”、以及故障模式。

研究结果表明，中间盒确实在各种企业网络中带来了显著的基础设施和管理开销，且典型企业中的中间盒数量与其传统的 L2/L3 基础设施相当。为了使这种架构切实可行，必须满足三个挑战：

• 功能等效
• 企业端的低复杂性
• 低性能开销

总结而言，我们的主要贡献包括：

• 对 57 个真实世界的中间盒部署进行的研究，涵盖了各种企业场景的成本和关切点。
• 对外包中间盒需求和设计空间的系统探讨。
• APLOMB 架构的设计、实现和评估。
• 对我们的系统如何影响大型企业中间盒部署的案例研究。

网络设计中的核心问题之一是网络功能应嵌入何处——端到端原则。我们的工作继承了这一方向，重点关注高级流量处理（网络数据平面中越来越重要的部分），并权衡了将这些处理功能嵌入云端与传统路径内中间盒的相对优劣。

2. 中间盒的今天

部署情况

调查了 57 家企业网络， 大企业可能有数千个中间盒设备，小企业则有数十个。中间盒的硬件成本高，部署维护需要大量资金。大企业在五年内花费上百万美元，小企业也可能需要投入数万美元

管理复杂性

• 中间盒的管理需要广泛的专业知识，并且往往需要 6-25 人的管理团队
• 升级硬件、配置设备、监控和故障诊断等任务非常复杂，导致运维成本高
• 多样化的设备和供应商增加了管理的复杂性（平均每个网络有 4.9 个供应商）

云端外包好处

• 硬件成本
• 管理简化
• 弹性扩展
• 培训减少

中间盒外包的商机

云服务不仅解决了现有的挑战，还为中小企业提供了按需付费的模式，使得即使是无法承担高昂硬件成本的小型网络也能享受中间盒功能

3. 设计空间

我们现在考虑如何实现这一目标，考虑一个中间盒 m，它在端点 a 和 b 之间服务流量，我们将 m 的位置从企业迁移到云端。这将消除当前中间盒部署的三个关键属性：

• 直连路径上：m 位于 a 和 b 之间的直接 IP 路径上。
• 汇聚点：从 a 到 b 的所有路径都经过 m。
• 本地：m 位于企业内部。

外包中间盒的挑战源于失去这三个属性。首先，处于直连路径上，并处于汇聚点使得中间盒能够轻松获取必须处理的流量，并确保中间盒可以看到两个端点之间流量的双向流动（需要再会话级别上工作）。其次，相比之下，云端绕行发送流量可能会增加路径延迟。第三，如代理和 WAN 优化器，我们称之为位置依赖的盒子（location dependent boxes），依赖于物理位置来减少延迟和带宽成本。例如，代理有效地终止企业主机 a 与外部主机 b 之间的通信，从而将通信延迟从路径 a-m-b 减少到 a-m 的延迟。类似地，通过使用冗余消除技术，WAN 优化器避免在广域网上传输数据。

这引出了三个自然问题，它们共同定义了将中间盒外包到云端的整体设计空间。

1. 外包后企业网络架构的有效复杂性是什么——例如，哪些类型的中间盒可以外包，企业端需要哪些功能以实现这样的外包？
2. 为了保持功能等效性和低延迟操作，需要什么样的重定向架构——例如，确保 a 和 b 之间通过云的双向流量始终经过同一云接入点（PoP, Point to Presence）？
3. 低延迟操作需要什么类型的提供商基础设施——例如，亚马逊式的基础设施（几个分布式的 PoP）是否足够，还是需要更大规模的 Akamai 风格基础设施？

至少，我们需要一种通用设备将企业流量重定向到云端；我们称之为中间盒外包设备（Appliance for Outsourcing Middleboxes），或称 APLOMB。我们将在§3.1 中探索重定向的选项，并在§3.2 中讨论低延迟操作的策略以及评估提供商基础设施的影响。此外，为了保持本地代理和 WAN 优化器所提供的带宽消耗节省，我们考虑扩展 APLOMB 以具备压缩能力（我们称之为 APLOMB+），在§3.3 中进行探讨。

3.1 重定向（引流器）

有三种自然的方法来引流。

反弹重定向

Bounce Redirection，在最简单的情况下，企业的 APLOMB 网关将进入和出去的流量都隧道化到云端。如图所示，传入的流量被反弹到 POP（1），由中间盒处理后再发送回企业（2,3）出站流量也以类似方式重定向（4-6）。这种架构的直接缺点是由于每个数据包额外的往返旅行而导致的端到端延迟增加。然而，这种设计是可行的——尤其是在云提供商具有广泛基础设施的情况下，这样到/从云的 RTT 会很小。——并且在架构的简易性上提供了吸引人的好处。只有 APLOMB 网关需要对云有意识，现有企业应用程序无需修改。企业主机的命名和地址保持不变。

IP 重定向

为了避免图 5(a)中的额外往返，我们可以直接路由流量到/从云端，使得流量从互联网用户直接到云，然后到企业。实现这一目标的一个可能设计是让云提供商代表企业通告 IP 前缀 P。与企业通信的主机将流量定向到 P，从而企业的流量被云提供商接收。云提供商在处理流量后，将其隧道传输到企业网关。然而，在实践中，企业可能希望通过云提供商的多个数据中心进行重定向，以提高延迟、负载分配和容错能力。为此，云提供商可能会从多个 PoP 广播 P，以便客户端流量有效地任何播到最近的 PoP。不幸的是，在多 PoP 场景中，基于 IP 的重定向将破坏有状态中间盒的语义，因为它不能确保从客户端 a 到企业 b 的流量将路由到与 b 到 a 的流量相同的云 PoP，如图 5(b)所示。此外，由于流量是在网络层根据 BGP 路径选择标准（如 AS 跳数）进行重定向的，企业或云提供商对选择的 PoP 控制有限，无法例如选择 PoP 来优化端到端延迟。

DNS 重定向

为了通过多个云 PoP 实现重定向，我们可以依赖基于 DNS 的重定向，类似于 CDN 的使用（如图 5(c)所示）。在这里，云提供商代表企业运行 DNS 解析，并为客户的外部服务注册 DNS 名称，在此示例中为“ MyEnterprise.com”（步骤 1）。访问 MyEnterprise.com 的用户（步骤 2）通过 DNS 被定向到云 PoP（步骤 3）。然后，流量经过相关中间盒处理，并隧道到企业（步骤 4）。来自企业的出站返回流量（以及企业主机发起的流量）也容易控制；APLOMB 网关设备使用简单的查找将流量发送到与入站客户端从 DNS 接收的相同 PoP。这确保了企业与外部主机之间的流量将始终经过相同的云 PoP，即使网络层路由发生变化。然而，基于 DNS 的重定向在外包流量给提供外部客户 IP 地址而不是 DNS 名称的传统应用程序时引入了挑战。

在我们的系统架构中，我们选择了 DNS 重定向，因为它避免了回弹重定向的延迟惩罚，并且比纯 IP 重定向提供了更好的控制能力

3.2 最小化延迟

DNS 重定向可能导致企业和外部客户端之间的延迟增加，即使避免了“回弹”架构等明显问题。

3.2.1 智能重定向

通过分析 300 多个 PlanetLab 节点和 20 个 Amazon CloudFront 位置的延迟影响，研究发现：

• 反弹重定向可能使 20%的路径延迟超过 50 毫秒。
• 基本的 DNS 重定向相比之下将延迟膨胀降低了 2 倍，且 30%以上的测量显示延迟低于直接 IP 路径。
• 进一步的“智能重定向”通过为每个目标选择最佳 PoP，允许 70%以上的情况实现零或负延迟膨胀，90%的流量延迟在 10 毫秒以内。

3.2.3 提供商覆盖范围

分析提供商的地理覆盖范围对延迟的影响，得出以下结论：

• 虽然更大的覆盖范围可以降低延迟，但 Amazon-like 的 PoP 数量（几十个）足以满足大部分企业的需求。
• 针对“位置依赖”的中间盒（如缓存/代理），需要更接近企业的 PoP 以减少延迟。Akamai-like 的覆盖范围能为 20%的站点提供小于 1 毫秒的延迟，而 Amazon-like 的覆盖范围只能为 30%的站点提供小于 5 毫秒的延迟。

3.2.4 位置依赖服务的带宽优化

对于带宽优化问题，讨论了三种可能的方案：

1. 不外包这些设备（如 WAN 优化器和代理），以便更好地满足大企业需求。
2. 在 APLOMB 设备中嵌入通用的流量压缩功能（APLOMB+），能够在一定程度上提供带宽节省。
3. 提供更为“主动”的设备架构，能够动态安装专门的软件模块，尽管这会增加复杂性

外包能力分析：

• 通过分析识别出大多数中间盒能够通过“基本 APLOMB”设备在延迟低于 5 毫秒的情况下进行外包。
• WAN 优化器和代理是例外，需要 APLOMB+设备和更大的覆盖范围以满足远程企业位置的需求。

4. APLOMB：详细设计

在描述 APLOMB 架构的详细设计时，重点关注三个关键组件，如图 10 所示：

1. APLOMB 网关：用于重定向企业流量。
2. 云提供商的功能和中间盒能力。
3. 控制平面：负责管理和配置这些组件。

4.1 企业配置

将流量从企业客户端重定向到云中间盒提供商相对简单：APLOMB 网关与企业的网关路由器共址，APLOMB 不会改变路由或交换，终端主机无需新配置。