Lec 13 应用层

思考题

1. 内容交付介绍。客户端/服务器模型如何交付内容？主要的缺点是什么？

2. P2P

   • P2P 网络如何交付内容？
   • BitTorrent P2P 网络如何共享内容？具体来说
     • .torrent 文件是用来干什么的？
     • 追踪器（tracker）是用来干什么的？
     • 通信流程是怎样的？（例如，谁与谁进行通信？）
     • 如何激励节点上传数据？

3. CDNs

   • CDN 如何交付内容？

   • CDN 所有者（例如，Akamai）在放置他们的机器和分发内容时需要考虑哪些因素？

   • CDN 所有者（例如，Akamai）在决定哪个服务器对某个特定客户端是“最佳”时可能会考虑哪些特性？

4. PCDN

内容交付介绍

客户端/服务器模型如何交付内容？主要的缺点是什么？

对于一个互联网视频公司，或许提供流式视频服务最直接的方法就是建立单一的大规模数据中心，在数据中心存储所有视频，并直接从该数据中心向全世界访问客户传输流式视频。但是这种方法存在 3 个问题，

• 如果客户远离数据中心，服务需要跨越多个 ISP
• 流行视频很可能经过相同的通信链路发送很多次，浪费带宽，对于内容提供公司需要反复向其 ISP 运营商支付费用
• 单个数据中心代表一个单点故障。

CDNs

动机

为了应对向分布于全世界用户分发巨量视频数据的挑战，几乎所有主要视频流公司都利用 CDN。

CND 集群的放置

采用两种不同的服务器放置策略

1. 深入（enter-deep）。Akamai 首创，该原则是通过在遍及全球的接入 ISP 中部署服务器集群来深入到 ISP 的接入网。Akamai 在约 1700 个位置采用这种方法部署集群，其目标是靠近端用户，减少端用户和 CND 集群之间链路和路由器的数量。
2. 邀请做客（Bring Home）。策略将 CDN 服务器集群部署在与多个 ISPs 互连的互联网交换点（IXPs）中，而不是直接放置在 ISPs 的接入网络内部。与第一种设计原则相比，通常产生较低的维护和管理开销。

CDN 操作

当用户的浏览器检索一个特定视频时，CDN 必须截获该请求以便能够

1. 确定此时适合该客户的 CDN 服务器集群；
2. 将客户的请求重定向到该集群的某台服务器

我们首先探讨截获和重定向请求所依赖的机制。大多数 CND 利用 DNS 来截获和重定向请求；假定一个内容提供商 NetCinema，买了第三方 CDN 公司 KingCDN 来为其分发视频，在 NetCinema 的 Web 网页上，每个视频的 URL 上有带有字符串"video"。接下来出现 6 个步骤。

1. 用户访问 NetCinema 的某个视频
2. 该用户发送了一个 video.NetCinema.com 的 DNS 请求
3. 用户的本地 DNS（LDNS）将该 DNS 请求中继到一台用于 NetCinema 的权威 DNS 服务器，服务器观察到主机名 video.netcinema.com 中的字符串"video"。为了将该 DNS 请求移交给 KingCND，NetCinema 权威服务器并不返回一个 IP 地址，而是范围一个 KingCND 域的主机名，如 a1105.kingcdn.com
4. 此时，DNS 请求进入到了 KingCND 专用 DNS 基础设施。用户的 LDNS 发送第二个请求，此时是对 a1105.kingcnd.com 的 DNS 请求，并返回 IP 地址
5. LDNS 将 CND 节点的 IP 给到用户主机
6. 用这个返回的 IP 进行 TCP 连接。。。

集群选择策略

任何 CDN 的部署，其核心是集群选择策略（Cluster selection strategy），即动态地将客户定向到 CDN 中的某个服务器集群或者数据中心的机制。

站长如何使用？

购买 CDN 服务之前需要考虑如下因素

价格：大多数根据带宽量计费，一些 CDN 可能还根据 cache hit，miss 和刷新次数来收费

可用性和可靠性：CDN 服务商通常力求 100%的正常运行时间，但几乎不可能完全实现。考虑你的可用性需求以及每个 CDN 如何支持这些需求。特别是针对预期服务的区域，比较各 CDN 的接入点（PoP）正常运行时间而不是整体正常运行时间。如果可能，确保你的 CDN 提供备选路由，以绕过故障的接入点。

接入点位置：根据用户所在地，选择在用户附近管理接入点的 CDN，这样可以有效提高性能。如果接入点离用户较远，可能会错失 CDN 所带来的许多性能提升。

如何将 CDN 添加到我的网站？

• 网页托管提供商

• 内容管理系统（CMS）

  • 像 WordPress 和 Squarespace 这样的 CMS 通常通过插件支持 CDN

• 自托管

  • 自己托管的网站在选择 CDN 方面具有最大的灵活性，但也需要更多设置。例如，在 Google Cloud Platform（GCP）上启用 Google Cloud CDN

具体配置步骤：

1. 配置 DNS 记录： 传统做法是直接更改网站资源的 URL，但现代 CDN 大多提供 DNS 管理，可以让你直接在域名系统中配置 CDN，而无需更改网站本身的代码。

   • 设置 CNAME 记录：将域名（例如 www.example.com）指向 CDN 提供的域名或别名（如 cdn.example.com）。这样一来，用户的请求将自动通过 CDN 路由
   • A 记录（如果 CDN 提供 IP 地址）：将域名直接指向 CDN 提供的 IP 地址

2. 配置源站和缓存策略：确保 CDN 知道你的源服务器（origin server），即原始内容的位置。大多数 CDN 允许你配置：

   • 缓存设置：设置缓存策略（如 Cache-Control 头），使 CDN 可以存储静态内容（如图片、CSS、JavaScript 文件）以减少对源服务器的请求。
   • 缓存刷新：配置刷新策略以便在内容更新后自动同步缓存。

   示例：

   • 在 Web 服务器上添加缓存控制头（例如Cache-Control: public, max-age=3600），以确保 CDN 缓存一个小时，减少频繁的源服务器访问。

3. 使用“拉取”或“推送”方式：大多数网站运营者无需上传内容，因为 CDN 会自动缓存用户访问时从服务器拉取的资源，即所谓的“拉取方法”。

4. 配置和优化 SSL：如果你的站点使用 HTTPS，确保 CDN 提供 SSL 支持并配置证书。很多 CDN 提供商都提供自动的 SSL 证书，但也可以使用自定义证书

   • 在 CDN 控制台中开启 SSL 选项，以确保所有流量都通过 HTTPS 加密

P2P

C/S 的体系结构，依赖于服务器总是处于打开状态，而 P2P 对于这个有最小依赖。成对间歇的主机（对等方 Peer）彼此直接通信。 Bittorrent 是全世界最流行的 P2P 文件分发协议。

BitTorrent(BT)

参与特定文件分发的所有对等方的集合被称为一个洪流（torrent）。在洪流中的对等方彼此下载等长度的文件块（chunk），典型的块长 256KB。当一个对等方首次加入洪流，他没有块，他会慢慢积累。当它下载块时，也为其他对等方上传了多个块。一旦某对等方获得了整个文件，它也许（自私地）离开洪流，或者继续上传。当然对等方是可以任何时候离开的，并在以后重新加入进来。

每个洪流有一个基础设施节点，称为追踪器（tracker）。当一个对等方加入时，它向追踪器注册自己，周期通知追踪器它仍然在该洪流中。当新的对等方 Alice 加入时，追踪器随机地选择一个对等方子集，将他们的 IP 发送给 Alice。Alice 试图并行地创建 TCP 连接。Alice 周期性的查询他们所拥有的文件块列表，利用这个信息它将作出两个决定：

1. 他应当从她邻居请求哪些块？
2. 她应当向哪些向她请求块的邻居发送快。

对于第一个问题，Alice 使用一种最稀缺优先原则（rarest first），针对她没有的块在她的邻居中确定最稀缺的块，并首先请求这些。目标是均衡在洪流中每个块的副本数量。

对于第二个问题，BitTorrent 使用了一种机灵的对换算法，基本想法是：Alice 根据当前能以最高速率向她提供数据的邻居，给出其优先权。周期性地测量出速率最高的前几名，用术语来说，这几个对等方被疏通（unchoked）。重要的是，每过 30 秒，她也要随机地选择另一个邻居作为伴侣，并向其发送块。其他的相邻对等方均被阻塞。这个激励机制称为“一报还一报”（tit-for-tat）

分布式散列表（DHT）

一种简单的数据库，记录分布在 P2P 系统的多等方上，DHT 得到了广泛实现（如在 BitTorrent 中）

PCDN

论文阅读：Akamai 网络（CDN)

The Akamai Network: A Platform for High-Performance Internet Applications, SIGOPS'10

思考题

1. Akamai 的设计目标是什么？

2. 当用户访问特定的 URL 时会发生什么？内容如何传送到他们的设备上？

3. 论文区分了“内容传递网络”和“应用程序传递网络”。内容和应用程序之间有什么区别？为什么这种区别对 Akamai 很重要？

   • 前者主要是静态内容，后者是主要是动态内容。因为它们需要不同的技术和基础设施支持。CDN 强调的是静态内容的分发和性能优化，而应用程序传递则需要更多的动态数据处理和复杂的网络支持。

4. 为什么对于 Akamai 来说点对点网络不够用？

5. 论文提到了“终端用户”和“客户”。Akamai 的终端用户是谁？它的客户又是谁？

   终端用户： 浏览客户内容的上网冲浪者； 客户是指购买了他们 CDN 网络的客户

6. Akamai 的平台旨在克服互联网基础设施的哪些方面？

7. 平台如何设计来克服这些方面？

8. 为什么 Akamai 有必要克服这些方面？

9. 一些公司（如 Netflix）建立了自己的“私有”CDN。这样做的优势是什么？劣势是什么？

10. 如果您要专门为内容分发设计互联网，您会如何设计？

本讲导览

Akamai 平台由位于 70 个国家、近 1,000 个网络中的 61,000 多台服务器组成，每天处理数百亿次互联网交互，帮助成千上万的企业提高其互联网应用的性能和可靠性。本文概述了该大规模分布式计算平台的组件和功能，并提供了关于其架构、设计原则、运作和管理的一些见解。

1. 引言

本文概述了当前的 Akamai 平台，讨论了许多关键技术和架构方法，用于实现其成功的技术成果。我们希望能深入探讨该平台的丰富性以及实现这样一个大规模系统所需的广泛技术研究与创新。

本文的组织结构如下：首先，我们介绍问题领域并探讨创建此平台的动机。接下来，我们概述 Akamai 平台，并分析它如何克服互联网在交付 Web 内容、媒体流和动态应用时的固有限制。我们提出，分布式网络是实现这些目的最有效的架构，尤其是当内容变得更加互动和更需要带宽时。然后，我们详细探讨 Akamai 平台的主要组件，重点介绍其设计原则和容错架构。最后，我们提供一些客户的实际成果，以验证平台在现实世界中的有效性。

2. Akamai 需要克服的问题

互联网由数千个不同的网络组成，每个网络只为一小部分终端用户提供访问。即使是最大的网络也仅占互联网访问流量的约 5%，而且这些百分比会急剧下降（见图 1）。实际上，需要超过 650 个网络才能覆盖 90%的访问流量。这意味着集中托管的内容必须通过多个网络才能到达终端用户。

互联网工作方式的固有特性——异构自治网络的松散拼接。跨网络的数据通信既不高效也不可靠，会受到许多因素的不利影响。最显著的因素包括：

• 互联点拥塞（Peering point congestion）。钱都花在了内容服务器（起点）以及终端用户（终点）上面了，而中间地带（跨网络）就成为瓶颈， 导致丢包和延迟增加。
• 低效的路由协议（例如 BGP）。尽管 BGP 在扩展尽力而为的互联网方面表现出色，但它有许多已知的局限性。BGP 的路由计算主要基于自治系统跳数，对底层网络的拓扑、延迟或实时拥塞情况一无所知。实际上，它主要用于执行网络之间的商业协议，而不是提供良好的端到端性能。
• 不可靠的网络（故障等）。互联网各处的中断随时都在发生。
• 低效的传输协议（例如 TCP）。尽管 TCP 是为可靠性和拥塞避免而设计的，但它携带了显著的开销，对于具有高延迟或数据包丢失的链路，其性能可能不理想，这在广域互联网中很常见。中间跨网络的拥塞加剧了问题，因为数据包丢失会触发 TCP 重传，进一步减慢通信速度
• 可扩展性问题。
• 应用程序和企业客户无法控制他们向终端用户提供的服务水平。

3. 交付网络的总览

十多年前，Akamai 提出了内容分发网络（CDN）的概念来应对这些挑战。这项技术迅速发展，超越了静态网页内容的传输。如今，Akamai 已发展出能够加速整个 Web 或基于 IP 的应用程序的应用传输网络，提供高清视频质量的直播和点播媒体的媒体传输网络，以及能够以分布式方式部署和执行整个 Java J2EE 应用程序的 EdgeComputing 网络。

3.1 交付网络作为虚拟网络

从观念上说，交付网络是一个虚拟网络，构建为实际互联网之上的软件层，部署在广泛分布的硬件上。虚拟网络方法的美妙之处在于它可以在现有互联网的基础上工作，无需客户端软件和底层网络的任何更改。而且，由于它几乎完全由软件构建，因此可以轻松适应未来的需求

3.2 交付网络的结构

Akamai 网络是一个非常庞大的分布式系统，由成千上万台全球部署的服务器组成。这些服务器能实现高扩展的分布式应用交付。可以将其视为由多个交付网络组成，每个网络都为不同类型的内容量身定制——例如，静态网页内容、流媒体或动态应用程序。 Akamai 交付网络的组要部分如下：

• 映射服务（Mapping System），当用户在浏览器中输入网址时，URL 的域名将被映射系统翻译为边缘服务器的 IP 地址，以提供内容（箭头 1）。映射系统根据大量的历史和当前数据，处理全球网络和服务器的状况，选择一个靠近终端用户的边缘服务器来响应请求。
• 边缘服务平台（Edge Server Platform），由大量的边缘服务器组成，负责处理来自附近的用户请求。图上箭头 2。
• 传输系统（Transport system）， 边缘服务器之间的虚拟网络。边缘服务器可能需要从源服务器请求内容。例如，定制化的网页内容不能完全通过边缘平台缓存，必须从源服务器获取。传输系统负责以可靠和高效的方式下载所需数据，并且通常也会缓存静态内容。
• 通信和控制系统（Communications and Control System）。用于发布状态信息、控制消息和配置更新，确保系统的容错性和及时性。
• 管理门户（Management Portal）：管理门户提供了两个功能。首先，它提供了一个配置管理平台，使企业客户能够保持对其内容和应用程序如何提供给最终用户的细粒度控制。这些配置通过通信和控制系统从管理门户更新到整个边缘平台。此外，管理门户为企业提供了用户如何与其应用程序和内容交互的可见性，包括观众人口统计和流量指标的报告。
• 数据收集与分析（Data Collection and Analysis）：负责从各种来源（如服务器日志、客户端日志以及网络和服务器信息）收集和处理数据。收集的数据可用于监控、警报、分析、报告和计费

后面会详细介绍每个组成部分。

3.3 系统设计原则

为了指导设计选择，需要假设网络中始终会发生大量故障。这意味着我们设计交付网络时采用了“故障是正常的，交付网络必须在故障发生时仍能无缝运行”的理念。我们投入了大量的精力设计从所有类型的故障中恢复的机制，包括多重并发故障。

这一理念指导了每个设计决策——甚至包括选择购买何种类型的服务器：在这种环境下，使用稳健的商用服务器比使用具备大量硬件冗余的昂贵服务器更有意义。虽然能够立即识别故障硬件仍然非常重要（例如，通过 ECC 内存和磁盘完整性检查来使服务器自动退出服务），但与其在硬件（如双电源）上建立冗余，不如将冗余更多地体现在软件中。

以下是关键的设计原则

• 设计可靠性。 目标是实现接近 100%的端到端可用性。我们必须确保组件的完全冗余（没有单点故障），构建多个级别的容错，并使用诸如 PAXOS [26] 和去中心化领导者选举等协议来适应系统组件故障的可能性。
• 可扩展性。扩展意味着处理更多的流量、内容和客户。这还意味着处理越来越大的数据量，这些数据必须被收集和分析，以及建立能够支持越来越多的分布式机器的通信、控制和映射系统
• 减少人工管理。在很大程度上，我们将系统设计为自治系统。这是故障是普遍的，系统必须在故障中无缝运行。为了管理其超过 60,000 台机器，Akamai 的网络运营中心目前雇佣了约 60 人，分布在全天候工作。
• 性能优化。我们持续进行工作，优化系统的关键路径性能，不仅从改善最终用户响应时间的角度，还从平台上多个不同指标（如缓存命中率和网络资源利用率）的角度进行提升。例如，通过内核和其他软件的优化，使得可以用更少的机器提供更大的容量和更多的流量。

4. 高性能流媒体交付

基本原则是通过互联网中间环节的瓶颈减少长途通信。这一目标只能通过一个广泛分布的架构来实现，服务器尽可能靠近最终用户。从用户性能的角度来看，理想的情况是服务器位于每个用户所在的 ISP 和地理位置内，从而减少对跨网络和长距离通信的依赖。

一个关键问题是这种架构需要如何分布化。Akamai 的做法通常是扩展到互联网的真正边缘。不仅在大型一级和二级数据中心部署，而且还在大量的终端用户 ISP 中部署。这种方法增加了系统设计和管理的复杂性，但我们认为这是最有效的。如果 CDN 仅在少数几十个服务器位置部署，全球大部分用户将无法享受他们最后一公里宽带接入所允许的高质量视频流。

互联网访问流量在网络中高度碎片化——幂律性。Akamai 的做法是尽可能将服务器部署在靠近最终用户的位置，最大限度地减少在交付内容时的对等点拥塞、延迟和网络中断的影响。

最后，尽管点对点技术提供了为静态网页内容服务的高度分布式选项，但目前实现中缺乏管理和控制功能，使其不适合作为企业级交付的独立解决方案。Akamai 的企业客户将 Akamai 网络视为其自身的延伸，因为他们希望在整个网络中保持对其内容的控制和可见性。这包括内容的新鲜度和正确性的管理、对不同内容的精细控制、查看实时分析和流量报告的能力，以及对安全性（包括完整性、可用性和机密性）的保证。这些能力对企业业务需求与性能优势同样关键。

4.1 视频级的可扩展性

除了速度和可靠性之外，高度分布的网络架构还提供了另一个关键优势——端到端的可扩展性。大多数 CDN（包括 Akamai）的一个目标是通过允许客户（购买他们产品的）按需利用更大的网络来提供可扩展性。因为网站不再需要构建一个庞大的原始基础设施，除非在受欢迎的事件期间。

随着高吞吐量视频的出现，可扩展性需求达到了新的数量级，奥巴马就职典礼是 2Tbps 记录。在如此规模下，仅仅拥有足够的服务器和出口带宽资源已经不再足够。必须考虑从编码器到服务器再到最终用户的整个路径的吞吐量瓶颈。瓶颈不再仅仅出现在原始数据中心，可能会出现在对等点、网络的回程容量、ISP 的上游连接，或是服务器与最终用户之间的网络延迟。也就是说， 在视频规模下，一个数据中心的名义出口容量与其到最终用户的实际吞吐量几乎无关，因为被由于互联网中各个瓶颈的容量限制。通过采用了高度分布式的架构，把服务器部署在数千个位置，而每个位置只需支持数十 Gbps 的输出即可。

4.2 流媒体性能

几个关键指标。第一个指标是流的可用性，衡量用户播放流时的无失败次数。其次，由于用户希望流快速启动，因此重要的是尽量减少启动时间，第三个指标是播放期间中断的频率和持续时间。最后，用户希望以其最后一英里连接、桌面或设备允许的最高比特率体验媒体。

Akamai 做法是， 部署了一个全球监控基础设施，能够从用户的角度测量流质量指标。该基础设施包括在全球部署的“代理”进行的主动测量。

4.3 内容和流媒体交付的传输系统

在 Akamai 的每个交付网络中，传输系统负责以可靠和高效的方式将数据从源服务器传输到边缘服务器。该系统使用的技术是针对传输数据的特定需求量身定制的。以下是两种技术的示例：第一种针对不常访问的内容，第二种用于实时流媒体传输。

4.3.1 分层转发

拥有大量内容库且其中一部分内容可能是“冷”或者访问不频繁的客户来说，Akamai 的分层分发平台可以通过减少对起源服务器的内容请求进一步提升性能。分层分发利用一组称为 Akamai“父”集群的集群。当边缘集群没有所请求的内容缓存时，它会从其父集群而不是起源服务器中检索该内容。

4.3.2 实时流媒体的覆盖网络

由于其独特的要求，许多实时流在 Akamai 网络上处理的方式与其他类型的内容有所不同。一旦实时流被捕获和编码，该流将发送到 Akamai 服务器集群，称为入口点。为了避免入口点成为单点故障，通常会将流的副本发送到额外的入口点，并配备自动切换机制，以防某个入口点故障。在入口点集群内部，分布式领导选举用于容忍机器故障。

实时流的传输系统将流的数据包从入口点传输到需要该流的边缘服务器的子集。该系统采用发布-订阅模式，每个入口点发布其拥有的流，每个边缘服务器订阅所需的流。值得注意的是，传输系统必须同时将数千个实时流从各自的入口点传输到所需的边缘服务器子集。为了以可扩展的方式执行此任务，使用了称为反射器的中间层服务器。反射器（reflector）充当入口点和边缘集群之间的中介，其中每个反射器可以从入口点接收一个或多个流，并将这些流发送到一个或多个边缘集群。

反射器能够制作每个接收到的流的多个副本，每个副本可以发送到不同的边缘集群。这一特性使得迅速将流复制到大量边缘集群，以便为热门事件提供服务。此外，反射器提供了入口点和边缘集群之间的多条备用路径。这些备用路径可以用于通过路径优化增强端到端质量，如下所述。

传输系统的目标是通过互联网中间路段以最小的失败、端到端数据包丢失和成本同时传输每个流。为了实现这个目标，系统考虑了入口点和边缘服务器集群之间可用的多条备用路径，并为每个流选择最佳的性能路径。

因为最佳路径随着互联网条件的变化而快速变化。构建覆盖路径的问题可以被描述为一个复杂的优化问题。关于使用 LP-四舍五入高效解决该问题的研究进展等先进算法技术高效、接近最优地解决这个问题的研究进展

5. 高性能应用交付

目的提升其他不可缓存内容的性能。通过两种方法，第一种方法是通过将 Akamai 平台作为高性能覆盖网络，加速长途互联网通信。第二种方法则是将应用程序逻辑从源服务器推送到互联网的边缘。

5.1 为应用加速，优化传输系统

通过一系列技术（包括路径优化和协议增强），可以优化任何两个 Akamai 服务器之间的通信。在典型情况下，首先将终端用户映射到附近的服务器。然后，该服务器利用高性能覆盖网络穿越互联网，达到企业源服务器附近的 Akamai 服务器。通常情况下，Akamai 服务器位于与企业源相同的网络甚至同一数据中心，因此二者之间的延迟非常低。下面描述的这些技术都是正在进行性能研究的领域：

• 路径优化。根据映射系统提供的互联网网络拓扑，和性能数据，可以动态选择特定路径。
• 减少数据包丢失。对于延迟敏感应用，如 AJAX 等。可以使用多路径技术进行冗余，结合前向纠错技术，减少数据包丢失。
• 传输协议优化，Akamai 的服务器之间可以使用专有的传输协议。

对于最后一公里问题，加速向终端用户的通信。

• APP 优化
• 内容压缩

5.2 将应用分发至边缘

虽然应用程序传输系统能够加快广域互联网的通信速度，但当应用程序本身能够分发到边缘时，性能、可靠性和可扩展性才会得到最大的提升。但如今大多数云计算服务仍然缺乏这一点。

实现一个支持 EdgeComputing 服务的平台需要克服许多技术挑战，包括会话管理（和跨机器的会话复制）、安全沙箱、故障管理、分布式负载均衡、资源监控和管理，以及提供合适的测试和部署工具。

并非所有类型的应用程序都可以完全在边缘运行；那些高度依赖大型事务性数据库的应用程序通常需要与源基础设施进行大量通信。然而，许多类型的应用程序（或应用程序的部分）可以从 EdgeComputing 中显著受益。以下是一些应用场景类别的总结：

• 内容聚合/转换。这类相对基础的应用程序不需要事务性数据库，只需从 Web 服务或其他来源收集内容并重新格式化以供展示（如使用 XSLT）。
• 静态数据库。产品目录、商店定位器、网站搜索和产品配置器是使用相对静态数据库的应用示例，可以完全在边缘运行。
• 数据收集。许多需要表单或其他用户输入的应用程序可以在边缘处理，数据批量发送到源服务器。例如，对于投票应用，边缘服务器可以本地存储数据，并以较大的数据块发送回源服务器（或 Akamai 的存储系统），而非许多单独的请求。数据验证和其他基本逻辑可以由边缘服务器执行，无需源服务器参与。这种内容聚合方法可以显著减少源服务器的负载。

复杂应用程序。即使是需要实时数据库事务的应用程序，在边缘运行应用程序的表示层组件仍然可以带来性能优势，因为与源服务器的通信仅包括原始数据，而不是完整的 HTML 页面。例如，源服务器可以生成一个小的动态页面，引用较大的可缓存片段，使最终的 HTML 页面能够使用 Akamai 的 ESI（Edge Side Includes）技术在边缘组装并提供。

6. 平台组件

图 5 提供了我们将讨论的主要组件的架构概览

6.1 边缘服务平台

Akamai 的边缘服务器负责处理终端用户请求并提供所请求的内容，同时也充当了其覆盖网络中的中介。该平台提供了丰富的功能和内容处理特性，这些特性源于十多年为互联网中最复杂的网站和应用程序提供服务的经验。

边缘服务器平台的一个重要特性是其通过元数据配置的强大可配置性，这使得企业可以在内容处理上保持精细的控制，以充分利用平台的多种功能。例如，单个虚拟主机（具有单个 DNS 主机名）往往包含各种特征的内容。某些路径可能被配置为高度动态、不可缓存的内容，使用客户的应用层作为源；同时，其他路径可能对应于从 Akamai 的存储系统提供的静态对象。特定路径可以配置身份验证和其他安全策略，而其他路径则可以配置修改特定 HTTP 请求和响应头。

以下列出了几类边缘服务器的功能，帮助理解由元数据控制的功能类型：

• 源服务器位置和内容路径：这可能与提供给终端用户的 URL 路径不同
• 缓存控制：包括是否缓存对象或对象的一部分以及缓存时间。
• 缓存索引：客户可以指定要在缓存索引中包含的对象元素
• 访问控制：提供多种身份验证和授权机制来控制内容访问，包括分布式机制（如在边缘验证 Cookie 或客户端证书）以及可查询源身份验证服务器的集中机制。
• 响应源服务器故障：在源服务器故障情况下，客户可以选择是否从缓存中提供（可能是过期的）内容，使用备用源服务器，或从 Akamai 的存储系统提供静态内容。超时时间和退避参数也可配置。
• 头信息更改：边缘服务器可以添加、删除或重写 HTTP 请求和响应头，例如 Cookie 头。此功能可用于向源服务器和定制客户端传递信息、管理下游缓存以及处理不同浏览器的行为。
• EdgeComputing：或将请求传递到边缘的 Java 应用服务器。
• 性能优化：为最大化不同条件下和适用于不同类别的应用程序或内容的性能，开发了多种功能。这些包括诸如分层分发和覆盖路径优化等主要功能，按连接调整 TCP 参数，内容的异步预取和刷新。

6.2 映射系统

Akamai 的映射系统是该平台的全球流量控制器，它利用关于 Akamai 网络和整个互联网健康状态的历史和实时数据，创建用于可靠、高效且性能优良的流量引导的地图。

该系统主要包括两部分：评分系统和实时映射系统。评分系统首先创建一个当前的拓扑地图，捕捉整个互联网的连接状态。更准确地说，该地图将互联网划分为 IP 地址的等价类，表示它们之间的连接方式及质量。这需要收集和处理大量历史及实时数据，包括 ping、traceroute、BGP 数据、日志和 IP 数据，这些数据在多年的积累下不断更新。网络延迟、丢包率和连接性被高频监控，从而可以立即响应网络故障和性能变化。

实时映射系统负责创建实际用于引导终端用户（由用户和其 DNS 服务器的 IP 地址标识）到最佳 Akamai 边缘服务器的地图。这部分系统还选择中间服务器，以便实现分层分发和覆盖网络。这个分配过程分为两个主要步骤：

• 映射到集群：首先，顶层地图为每个用户等价类选择一个首选的边缘服务器集群，将互联网的每个小片段分配给 Akamai 数千个边缘服务器位置之一。该映射通常基于多种因素，包括评分系统提供的信息（如地理和网络/AS 与用户的邻近性）、实时丢包和延迟、实时容量和需求信息、流量类别（例如确保满足对延迟敏感的流量和大流量需求）以及集群健康状态的实时信息。此映射每分钟更新，以反映当前条件。例如，如果观察到某个集群与一组终端用户之间的连接问题，则会将这些用户定向到可以提供更好性能的集群。反馈控制系统会跟踪负载、容量和需求的多个维度，确保发送到任一集群的需求不会使该集群的负载超出其容量目标。
• 映射到服务器：一旦被分配到特定集群，集群内的低层地图会根据多个因素（例如某台服务器缓存中存在请求内容的可能性）将用户引导到特定机器。保持集群内的局部性（将对同一内容的请求映射到同一台机器）是理想的，因为这样可以提高性能并高效利用缓存空间。挑战在于在动态环境中进行此操作，同时考虑负载变化和机器故障。Akamai 在这方面的开创性研究始于十多年前的一致性哈希，目前已从那时起显著发展。

当识别出硬件和网络故障（例如服务器硬盘故障）时，故障的边缘服务器将被“暂停”，这些服务器将完成正在进行的请求处理，但在故障修复之前不再接收新的终端用户。

映射系统本身是一个容错分布式平台，能够在多个数据中心发生故障的情况下不中断运行。系统的评分和映射到集群部分在多个独立站点上运行，并基于每个站点的当前健康状态进行领导选举。映射到服务器的部分在每个目标集群内的多台机器上运行。系统的所有部分，包括监控代理和 DNS 服务器，都通过一个多路径覆盖传输进行通信（第 7.3 节中更详细描述），可以容忍网络故障。

由于映射系统的有效性对 Akamai 系统的整体性能至关重要，因此该系统的研究和开发工作持续进行，以改进和优化。这包括不断提高评分数据输入的质量，改善大流量内容的局部性，处理互联网架构变化，开发增强故障隔离的新方法，以及优化系统组件性能以实现更快的响应时间。

其中一个改进的例子是，增强了服务器调整其自身容量输入到映射系统的能力，基于资源利用率的自我监控。这使运行不同类型应用的异构硬件在整个网络中得到了更高效的利用。

映射系统中处理的数据量（以及频率）也带来了挑战。在早期系统重设计时，分析表明最初提出的设计所需收集和传递的数据量将超过所服务的终端用户流量。自那时以来，进行了大量工作来减少数据通信负担，同时保留所有对高质量映射至关重要的信息。

6.3 通信和控制系统

Akamai 平台使用了多种内部通信模型，每种模型都在高度分布式的互联网平台上面临独特的挑战。这些系统的关键挑战在于规模（需要与超过 6 万台机器进行通信和控制）以及可靠性（特别是在通信方面，因为某些 Akamai 集群与其终端用户有良好的连接和性能，但与互联网的其他部分连接较差）。

以下是几个示例系统的扩展说明：

• 状态和控制信息的实时分发：这里需要在整个网络中传播小型消息（如映射系统的输入和输出信息，包括负载、健康状况、连接性和控制信息）。为此，Akamai 采用发布/订阅模型，并结合多路径分层扇出架构。发布者将消息发布到一组全球分布的中间节点，订阅者可以订阅一个或多个中间节点。该多路径架构在扩展性和容忍网络故障的同时，最小化了延迟。
• 点对点 RPC 和 Web 服务：在需要高度可靠和低延迟的点对点通信的情况下（例如 Web 服务），Akamai 能够利用其高性能覆盖网络（详见第 6.1 节），以提高可靠性和性能，即使面对网络问题也能实现。
• 动态配置更新：Akamai 的许多系统组件需要频繁接收低延迟的配置更新，频率可能达到每隔几分钟一次。例如，用于配置边缘服务器平台的客户元数据配置文件（详见第 7.1 节）。此设计的关键目标包括确保网络中版本一致性（包括在连接问题和机器随时可能故障和重启的情况下的平稳处理）、系统的可靠性和可扩展性，以及确保传播的更改不会对网络造成不利影响。Akamai 的解决方案是将数据发布到一组高可用性存储服务器，这些服务器通过基于法定人数的复制机制“接受”更新。为了实现规模和低延迟的分发，更新随后使用 Akamai 的内容分发服务在网络中传播。最后，配置更新以阶段性方式自动推送，每一步都进行健康检查，以保护网络。进一步的细节，包括基于向量交换的接受算法和索引合并恢复机制，详见文献[39]。
• 密钥管理基础设施：对于诸如 SSL 密钥等敏感加密密钥，Akamai 致力于将它们始终不写入机器的磁盘。Akamai 的密钥管理基础设施会在分发密钥之前，对机器进行广泛的安全审核。多个密钥分发服务器使用 PAXOS 协议协调其数据库复制，以便即使在网络问题情况下，机器也可以获得审核和密钥。尚未获得密钥的机器将自动暂停，并不会被包括在映射系统的映射中。
• 软件和机器配置管理：Akamai 用于在其网络中分发软件和系统配置信息的系统，旨在应对平台的异构和分布特性。一个关键需求是，即使在回滚和由于连接问题导致的更新步骤丢失的情况下，机器也必须趋于正确的软件和系统配置。在每台机器的软件和系统配置更新的过程中，系统会构建出机器的期望状态，并将其与当前状态进行比较。系统随后会采取必要的操作，使运行状态与期望状态一致，例如更新软件组件。由于采用了高可靠性设计原则，软件更新可以无任何外部可见的影响进行。例如，需要更新的机器会被暂停，新的请求将被引导到其他服务器；机器在完成正在进行的请求后会重新启动其服务。

6.4 数据收集与分析系统

Akamai 平台采用了多种数据收集和分析机制，这些机制在设计上都面临着可扩展性和容错性的挑战，具体包括：

日志收集 客户的业务需求通常要求访问其原始日志文件，Akamai 也依赖日志文件来计费。平台每天处理的 HTTP 请求超过 1,000 万次/秒，日志数据超过 100TB。压缩后的日志被可靠地聚合到集群中进行处理，通过管道验证和过滤这些日志。选择的日志属性被传递到系统中，用于分析、加载到数据库中进行历史报告和计费，或交付给客户。

实时数据收集和监控 Akamai 的 Query 系统是一种分布式实时关系数据库，用于在整个分布式网络中近实时地监控状态信息。Akamai 平台中的几乎每个软件组件都将状态数据提供为表格行，然后这些行被聚合到 Query 系统的数千个表中。Query 支持标准 SQL 接口，能够进行任意查询，而不必事先定义具体问题。有关 Query 架构和功能的详细信息，请参阅[36]。

Akamai 大量使用 Query 系统来监控和发出警报。例如，网络范围内的不变式可以用 SQL 语句表达（例如，“某个地理区域内的机器表现出某种系统行为的数量不应超过 N，同时不应发生其他系统行为”），任何返回的行都将生成警报，供运营中心进一步调查。其他 SQL 语句（例如，“某些进程的资源利用率的 95 百分位数，按硬件类型和软件版本分解”）可用于提取系统状态的复杂特征，用于趋势分析。

分析与报告 Akamai 的分析与报告系统允许客户查看其网站的流量和性能信息。系统从日志收集、Query 和其他系统中获取输出数据，处理成多维度的报告格式。最新一代系统采用修改后的 MapReduce 框架提取各种属性，将数据提交到容错的列式数据库系统中。客户可以通过报告界面构建和发出多维度查询，以深入了解其网站流量、用户分布和网络性能。

6.5 其他系统和服务

Akamai 平台还包含其他多种高度可扩展和高可用性的基础设施，尽管它们在 Akamai 提供的服务中起着重要作用，但在此不做详细介绍。

6.5.1 DNS

DNS 是大多数互联网应用的重要组成部分，用于帮助终端用户将主机名映射到 IP 地址。它也是与 Akamai 映射系统交互的主要机制之一，负责传达哪些终端用户应被分配到哪些 Akamai 集群和机器。因此，Akamai 部署了全球分布的高可用性权威 DNS 服务器系统，这些服务器既能根据 Akamai 的映射决策动态回答请求，也能为客户域提供静态权威答案。Akamai 采取了多种措施确保 DNS 系统的强大容错能力，使用多种机制支持系统的高请求率处理和全球卓越性能。

该高可用性系统也可以作为权威 DNS 服务提供给客户。通过该服务，DNS 区域内容可从客户的主 DNS 服务器安全传输，无需直接面向终端用户，内容将分发至 Akamai 的全球 DNS 基础设施，从而处理客户的 DNS 查询。

6.5.2 监控代理

Akamai 在全球范围内部署了多个监控代理系统，用于监控网络和网站性能。不同的代理能够执行 ping、traceroute 以及通过 HTTP 等多种协议的请求。映射系统可以配置这些测试（例如，绘制互联网地图，实时监控丢包率和延迟），客户也可以配置这些测试（例如，用于测量网站可用性和性能，结果将反馈至分析系统）。

6.5.3 全球流量管理器（GTM）

为了实现故障容错和负载均衡，客户通常希望将源服务器部署在多个位置。Akamai 将其映射技术的一部分作为服务提供给客户，即全球流量管理器（GTM）。此服务包括在客户源位置的代理，它们监控互联网性能并收集负载信息反馈到映射系统。最终的答案通过 DNS 分发给终端用户（或使用这些自定义源的 Akamai 服务器），依据负载、网络延迟、地理和网络邻近性以及客户业务规则进行选择。

6.5.4 存储

Akamai 平台包含一个高可用性的存储系统，可用于各种内容类型的源服务器，如静态对象、大型媒体库和备份站点。边缘计算应用程序也可以将此存储系统用作某些类型数据的存储库。存储架构设计上没有单点故障；服务器部署在多个地理位置的集群中，提供集群内和多集群的自动复制。多种上传方式可供选择，包括 rsync-over-ssh 和 HTTPS POST。

6.5.5 客户端传输

Akamai 提供了客户端传输系统，帮助客户提升终端用户性能并降低成本。该系统包括安装在终端用户机器上的客户端软件，与分布式 Akamai 系统进行安全通信。客户端 Web 应用程序（在浏览器内运行）可以与客户端软件进行本地通信，以请求内容（例如，用于分发大型软件包）。客户端传输系统类似于许多对等网络系统，但提供了企业客户所需的额外功能。尤其是大多数企业客户非常重视内容的性能和可用性保证，不希望失去对内容传输的控制或可见性。此系统通过 Akamai 平台播种内容，并在对等方无法提供足够性能时自动回退至请求最近的 Akamai 服务器。通过与 Akamai 边缘服务器平台的紧密集成，客户端软件可以为客户提供对内容传输的控制和可见性，并确保传输内容的完整性。客户端软件通过与 Akamai 控制面板通信，基于映射系统对互联网拓扑的实时理解来决定与哪些对等方通信。

**6.5.6 **管理门户

Akamai 的基于 Web 的管理门户为客户提供了高可用性的配置和管理平台，使客户能够掌控并监控其内容、应用程序和流量。客户可以查看诸如流量报告、网络性能和丢包率、终端用户群体数据、下载完成率、媒体播放时间/缓冲时间以及自定义报告等信息。门户的其他功能还包括自助服务配置（如管理站点元数据配置或清除内容）、诊断、管理、警报和报告。此门户系统使用 Akamai 的应用程序传输网络加速，提升了全球客户的性能和可靠性

7. 示例：多级故障切换

如第 4.3 节所述，Akamai 的整个平台设计采取类似于恢复导向计算的策略——假设故障是操作中的不可避免因素，因此系统必须具备在故障情况下继续运行的能力。这里简要说明了 Akamai 内容交付服务如何在多个组件出现故障的情况下维持可用性（有关系统旧版本的更多详细信息请参见[1]）。

要了解其工作原理，首先需要了解一个 HTTP 请求的基本流程。

HTTP 请求流程

首先，DNS 查找用于解析 Akamai 的主机名，该过程包括几个步骤：

1. 首次请求进入通用顶级域名（TLD）服务器，这些服务器返回 Akamai 顶级名称服务器（TLNS）作为权威，通常带有较长的 DNS 生存时间（TTL）。Akamai TLNS 分布于全球，使用 IP Anycast 和大规模集群的组合。
2. 第二步查询发送至 Akamai TLNS，返回具有较短 TTL 的 Akamai 低级名称服务器（LLNS）列表。这些 LLNS 通常位于解析名称服务器的近距离网络。
3. 最后查询，发送至 Akamai LLNS，返回基于集群分配和低级映射的边缘服务器 IP 地址。这些应答的 TTL 极短，以便快速分发映射更改（如响应故障或需求变化）。

然后，用户浏览器向边缘服务器的 IP 地址发送 HTTP 请求以获取内容。如果内容未缓存，边缘服务器从源服务器检索内容并传送给最终用户。

故障处理场景

• 机器故障：在边缘集群内，Akamai 实现了高可用性技术，类似于 TCPHA[42]的原理，使得在机器故障时能够无缝响应，另一台机器会接替故障机器的 IP 地址。此外，低级映射每隔几秒更新一次，适当地重定向新的请求来应对故障。
• 集群故障：当整个集群故障或连接不稳定时，映射的集群分配会快速更新，不再分配故障或连接出现问题的集群。
• 连接故障：如果源服务器和边缘服务器之间的连接性能下降，平台会快速检测并利用路径优化技术，通过 Akamai 平台的中间节点找到其他良好的路径。

即使上述所有故障同时发生，平台仍能迅速恢复。

恢复导向设计的附加优势

1. 减少运维人员需求：网络设计假设组件随时可能出现故障，工作人员无需紧急处理大多数故障，可以在发现问题时主动暂停组件，而不会影响系统整体性能。尽管运维人员分布于多个地点，但他们不在网络操作的关键路径上。
2. 快速且无中断的软件更新：正如第 7.3 节所述，由于多个机器或集群的故障不会影响整体系统，Akamai 能够快速执行分区软件更新，且不会中断客户服务。相关的有趣指标可参见[1]。