提升互联网性能 -

2008年12月4日
第6卷，第6期

提升互联网性能

鉴于互联网的瓶颈，我们如何构建快速、可扩展的内容交付系统？

Tom Leighton，Akamai Technologies

当涉及到为商业级Web应用程序实现性能、可靠性和可扩展性时，最大的瓶颈在哪里？在今天的许多情况下，我们看到限制性瓶颈是中间一英里，或者数据在源服务器和最终用户之间通过互联网来回传输所花费的时间。

情况并非总是如此。十年前，最后一英里很可能是罪魁祸首，用户受限于缓慢的拨号调制解调器访问速度。但是，近来全球宽带普及率的提高——全球超过 3 亿用户——不仅使最后一英里的瓶颈成为历史，而且还增加了互联网基础设施其余部分跟上步伐的压力。⁵

今天，第一英里——即源基础设施——在设计 Web 应用程序时往往会受到最多的关注。这是问题中最受应用程序架构师控制的部分。实现良好的第一英里性能和可靠性现在是一个相当容易理解和解决的问题。然而，从最终用户的角度来看，强大的第一英里是实现强大的应用程序性能和可靠性的必要条件，但并非充分条件。

这就是中间一英里发挥作用的地方。互联网模糊的中间一英里难以驯服且经常被忽视，它将延迟瓶颈、吞吐量限制和可靠性问题注入到 Web 应用程序性能方程式中。事实上，“中间一英里”这个术语本身就是一个用词不当，因为它指的是由许多竞争实体拥有且通常跨越数百或数千英里的异构基础设施。

本文重点介绍了当今中间一英里提出的最严峻挑战，并展望了克服这些挑战和提高互联网性能的方法。

困在中间

虽然我们经常将互联网称为一个单一实体，但它实际上由 13,000 个不同的竞争网络组成，每个网络都为一小部分最终用户提供访问权限。互联网容量多年来不断发展，受市场经济的影响。资金从第一英里和最后一英里流入网络，公司为托管付费，最终用户为访问付费。在过去的 5 到 10 年中，第一英里和最后一英里的容量分别增长了 20 倍和 50 倍。

另一方面，互联网的中间一英里——由网络交换流量的对等互连点和传输点组成——实际上是一个无人区。在这里，从经济角度来看，几乎没有动力来扩建容量。如果说有什么的话，网络希望尽量减少流入其网络且他们没有获得报酬的流量。因此，对等互连点通常负担过重，导致数据包丢失和服务降级。

脆弱的对等互连经济模式可能会产生更严重的后果。例如，在 2008 年 3 月，两家主要的网络提供商 Cogent 和 Telia 因商业纠纷而取消对等互连。在一个多星期的时间里，Cogent 的客户无法访问 Telia 以及与之相连的网络，反之亦然，这意味着 Cogent 和 Telia 的最终用户根本无法访问某些网站。

其他可靠性问题也困扰着中间一英里。互联网中断的原因多种多样，例如跨洋电缆中断、断电和 DDoS（分布式拒绝服务）攻击。例如，在 2008 年 2 月，当一系列海底电缆被切断时，东南亚和中东地区的通信受到严重破坏。据 TeleGeography 称，电缆切断使欧洲和中东之间的带宽连接减少了 75%。⁸

互联网协议，如 BGP（边界网关协议，互联网的主要网络间路由算法），与物理网络基础设施一样容易受到攻击。例如，在 2008 年 2 月，当巴基斯坦试图通过广播更具体的 BGP 路由来阻止从国内访问 YouTube 时，它意外地导致了近乎全球性的 YouTube 中断，突显了 BGP 容易受到人为错误（以及恶意行为）的影响。²

这些互联网可靠性和对等互连点问题的普遍存在意味着数据在中间一英里中传输的时间越长，就越容易受到拥塞、数据包丢失和性能不佳的影响。当前趋势进一步加剧了这些中间一英里问题——最值得注意的是最后一英里容量和需求的增加。随着 ISP 投资最后一英里基础设施，宽带普及率持续上升，包括普及率和速度。AT&T 刚刚花费了大约 65 亿美元推出其 U-verse 服务，而 Verizon 计划在 2010 年之前花费 230 亿美元为 1800 万户家庭铺设 FiOS（光纤服务）。^7,6 Comcast 最近也宣布计划在一年内提供高达 100 Mbps 的速度。³

需求推动了最后一英里的繁荣：皮尤互联网 2008 年的报告显示，三分之一的美国宽带用户选择花更多的钱购买更快的连接。⁴ Akamai Technologies 的数据（如表 1 所示）显示，其全球用户中有 59% 拥有宽带连接（速度高于 2 Mbps），19% 的全球用户拥有“高宽带”连接（速度高于 5 Mbps）——速度足以支持 DVD 质量的内容。² 高宽带数字在短短三个月内就增长了 19%。

规模问题

随着对宽带的更大需求和可用性，用户对更快的网站、更丰富的媒体和高度交互式应用程序的期望也随之提高。流量负载和性能要求的增加反过来又给互联网的内部基础设施——中间一英里——带来了更大的压力。事实上，视频的快速普及引发了关于互联网是否能够扩展以满足需求的争论。

例如，考虑向 5000 万观众（大致相当于热门电视节目的观众规模）交付电视质量的流媒体（2 Mbps）。这种情况产生的总带宽需求为 100 Tbps。这对于近期（未来两到五年）来说是一个合理的愿景，但它比当今最大的在线活动规模大几个数量级，导致人们怀疑互联网是否有能力处理如此大的需求。此外，这些数字仅适用于单个电视质量的节目。如果数亿最终用户定期通过互联网下载蓝光质量的电影，则由此产生的流量负载将再增加一到两个数量级。

距离瓶颈

视频和富媒体文件大小增长的另一个有趣的副作用是，服务器和最终用户之间的距离对于最终用户性能变得至关重要。这是一个有点违反直觉的现象的结果，我们称之为“胖文件悖论”：鉴于数据包可以接近光速的速度穿越网络，为什么即使网络不拥塞，“胖文件”也需要这么长时间才能穿越国家？

事实证明，由于底层网络协议的工作方式，延迟和吞吐量是直接相关的。例如，TCP 仅允许一次发送少量数据（即 TCP 窗口），然后必须暂停并等待接收端的确认。这意味着吞吐量实际上受到网络往返时间（延迟）的限制，这可能会成为文件下载速度和视频观看质量的瓶颈。

数据包丢失使问题更加复杂，因为如果检测到数据包丢失，这些协议会退避并发送更少的数据，然后再等待确认。更长的距离增加了拥塞和数据包丢失的可能性，从而进一步损害吞吐量。

表 2 说明了距离（服务器和最终用户之间）对吞吐量和下载时间的影响。五到十年前，拨号调制解调器速度将成为这些文件的瓶颈，但当我们展望今天的互联网和未来时，中间一英里的距离将成为瓶颈。

内容交付的四种方法

鉴于这些瓶颈和可扩展性挑战，如何才能实现通过互联网有效交付内容和应用程序所需的性能和可靠性水平？在内容交付架构中，有四种主要方法来分发内容服务器：集中式托管、“大数据中心”CDN（内容交付网络）、高度分布式 CDN 和 P2P（对等网络）。

集中式托管

传统架构的网站使用一个或少量托管站点来托管内容。商业规模的站点通常至少有两个地理位置分散的镜像站点，以提供额外的性能（通过更靠近不同的最终用户群体）、可靠性（通过提供冗余）和可扩展性（通过更大的容量）。

这种方法是一个良好的开端，对于服务于本地受众的小型网站来说可能足够了。然而，性能和可靠性达不到商业级站点和应用程序的期望，因为最终用户体验受制于不可靠的互联网及其中间一英里的瓶颈。

还存在其他挑战：站点镜像复杂且成本高昂，容量管理也是如此。流量水平波动剧烈，因此需要为峰值流量水平配置资源，这意味着昂贵的基础设施大部分时间都将处于未充分利用状态。此外，准确预测流量需求极其困难，集中式托管模型无法提供处理意外激增的灵活性。

“大数据中心”CDN

内容交付网络通过将可缓存内容的交付从源服务器卸载到更大的共享网络上，从而提供改进的可扩展性。一种常见的 CDN 方法可以描述为“大数据中心”架构——从可能连接到主要骨干网络的几十个高容量数据中心缓存和交付客户内容。

尽管这种方法比集中式托管提供了一些性能优势和规模经济，但潜在的改进是有限的，因为 CDN 的服务器仍然远离大多数用户，并且仍然从中间一英里的瓶颈的错误一侧交付内容。

即使在几十个主要骨干网络中拥有业务也不足以实现商业级性能，这似乎有悖常理。事实上，即使是最大的网络也控制着非常少的最终用户访问流量。例如，排名前 30 的网络加起来仅交付 50% 的最终用户流量，并且从那里迅速下降，在互联网的 13,000 个网络中呈非常长的尾部分布。即使连接到所有最大的骨干网络，数据也必须穿过中间一英里的泥潭才能到达互联网的 14 亿用户中的大多数。

一个简单的粗略计算表明，当我们走向视频世界时，这种类型的架构在可扩展性方面遇到了瓶颈。考虑一下对这种架构的慷慨前瞻性预测——例如，50 个高容量数据中心，每个数据中心有 30 个出站连接，每个连接 10 Gbps。这为这种类型的网络提供了 15 Tbps 总容量的上限，远低于近期支持视频所需的 100 Tbps。

高度分布式 CDN

另一种内容交付方法是利用高度分布式的网络——服务器位于数千个网络中，而不是几十个网络中。从表面上看，这种架构可能看起来与“大数据中心”CDN 非常相似。然而，实际上，这是一种根本不同的内容服务器放置方法，在分布程度上存在两个数量级的差异。

例如，通过将服务器放置在最终用户 ISP 中，高度分布式的 CDN 从中间一英里的瓶颈的正确一侧交付内容，消除了对等互连、连接、路由和距离问题，并减少了成功所需的互联网组件数量。

此外，这种架构具有可扩展性。例如，通过在 5,000 个边缘位置部署 20 台服务器（每台服务器能够交付 1 Gbps），它可以实现 100 Tbps 的容量。

另一方面，部署高度分布式的 CDN 成本高昂且耗时，并且会带来自身的一系列挑战。从根本上说，网络必须设计为从部署和管理角度有效扩展。这需要开发许多技术，包括

复杂的全局调度、映射和负载均衡算法
分布式控制协议和可靠的自动化监控和警报系统
智能和自动化的故障转移和恢复方法
海量数据聚合和分发技术（旨在处理时间性和准确性或完整性之间的不同权衡）
强大的全局软件部署机制
分布式内容新鲜度、完整性和管理系统
复杂的缓存管理协议，以确保高缓存命中率

这些都是不小的挑战，我们将在本文后面介绍我们的一些方法。

对等网络

由于高度分布式的架构对于在视频分发中实现可扩展性和性能至关重要，因此自然而然地会考虑 P2P 架构。P2P 可以被认为是将分布式架构发挥到极致，理论上提供了近乎无限的可扩展性。此外，P2P 在当前的网络定价结构下提供了有吸引力的经济性。

然而，实际上，P2P 面临一些严重的限制，最值得注意的是，P2P 网络的总下载容量受到其总上行链路容量的限制。不幸的是，对于消费者宽带连接，上行链路速度往往远低于下行链路速度：例如，Comcast 的标准高速互联网套餐提供 6 Mbps 的下载速度，但仅提供 384 Kbps 的上传速度（下载吞吐量的 1/16）。

这意味着，在直播等情况下，上传者（共享内容的对等方）的数量受到下载者（请求内容的对等方）的数量的限制，平均下载吞吐量相当于平均上行链路吞吐量，因此甚至无法支持中等 Web 质量的流媒体。同样，P2P 在“突发流量”场景中也会失败，在这些场景中，需求突然急剧增加，下载者的数量大大超过了网络中上传者的容量。

通过混合方法可以获得稍好一些的结果，即利用 P2P 作为分布式交付网络的扩展。特别是，P2P 可以在某些情况下帮助降低总体分发成本。然而，由于 P2P 网络的容量有限，因此网络非 P2P 部分的架构仍然决定着总体性能和可扩展性。

这四种网络架构各有优缺点，但最终，对于向全球 Web 受众交付富媒体而言，高度分布式的架构是提供商业级性能、可靠性和规模的唯一可靠解决方案。

应用程序加速

从历史上看，内容交付解决方案一直专注于静态内容的卸载和交付，到目前为止，我们的对话也集中在这一点上。然而，随着网站变得越来越动态、个性化和应用程序驱动，加速不可缓存内容的能力对于提供强大的最终用户体验也变得同样重要。

Ajax、Flash 和其他 RIA（富互联网应用程序）技术致力于增强浏览器端的 Web 应用程序响应能力，但最终，这些类型的应用程序仍然需要大量往返源服务器。这使得它们极易受到之前提到的所有瓶颈的影响：对等互连点拥塞、网络延迟、不良路由和互联网中断。

加速这些往返是一个复杂的问题，但通过使用高度分布式的基础设施，可以实现许多优化。

优化 1：减少传输层开销。TCP 等协议为可靠性而非效率而设计，具有大量的开销。它们需要多次往返（在两个通信方之间）来建立连接，使用缓慢的初始数据交换速率，并缓慢地从数据包丢失中恢复。相比之下，使用持久连接并针对效率优化参数（在了解当前网络状况的情况下）的网络可以通过减少交付相同数据集所需的往返次数来显着提高性能。

优化 2：找到更好的路由。除了减少所需的往返次数外，我们还希望减少每次往返所需的时间——每次穿越互联网的旅程。乍一看，这似乎不可能。所有互联网数据都必须通过 BGP 路由，并且必须通过众多自治网络传输。

BGP 简单且可扩展，但效率不高且不稳健。通过利用高度分布式的网络——一个在许多不同网络上提供潜在中间服务器的网络——您实际上可以通过使用更快且拥塞程度低得多的路由，将不可缓存的通信速度提高 30% 到 50% 或更多。当默认路由中断时，您还可以通过查找备用路由来实现更高的通信可靠性。

优化 3：预取嵌入内容。您可以在应用层执行许多其他操作来提高最终用户的 Web 应用程序响应能力。一种方法是预取嵌入内容：当边缘服务器向最终用户交付 HTML 页面时，它还可以解析 HTML 并在最终用户的浏览器请求之前检索所有嵌入内容。

这种优化的有效性取决于服务器是否靠近最终用户，以便用户感知到的应用程序响应能力类似于直接从附近服务器交付的应用程序，即使事实上，某些嵌入内容是从长途互联网上的源服务器获取的。例如，前向缓存的预取不提供这种性能优势，因为预取的内容在到达最终用户之前仍然必须穿过中间一英里。另请注意，与链接预取（也可以完成）不同，嵌入内容预取不会消耗额外的带宽资源，也不会请求最终用户可能不需要的无关对象。

随着当前高度个性化的应用程序和用户生成内容的趋势，不可缓存或长尾（即，不太可能在缓存中）嵌入内容有所增长。在这些情况下，预取对用户感知的 Web 应用程序响应能力产生了巨大的影响。

优化 4：在边缘组装页面。接下来的三个优化涉及减少需要通过中间一英里传输的内容量。一种方法是在边缘服务器上缓存页面片段，并在边缘动态组装它们以响应最终用户请求。可以（在边缘）根据最终用户的位置、连接速度、cookie 值等特征对页面进行个性化设置。在边缘组装页面不仅卸载了源服务器，而且还大大降低了最终用户的延迟，因为避免了中间一英里。

优化 5：使用压缩和增量编码。压缩 HTML 和其他基于文本的组件可以将通过中间一英里传输的内容量减少到原始大小的十分之一。增量编码的使用（服务器仅发送缓存的 HTML 页面与动态生成的版本之间的差异）也可以大大减少必须通过长途互联网传输的内容量。

虽然这些技术是 HTTP/1.1 规范的一部分，但浏览器支持不可靠。通过使用高度分布式的网络（控制中间一英里的两个端点），无论浏览器如何，都可以成功地使用压缩和增量编码。在这种情况下，性能得到提高，因为只有很少的数据通过中间一英里传输。然后，边缘服务器解压缩内容或应用增量编码，并将完整、正确的内容交付给最终用户。

优化 6：将计算卸载到边缘。将应用程序分发到边缘服务器的能力提供了应用程序性能和可扩展性的极致。Akamai 的网络能够将 J2EE 应用程序分发到边缘服务器，这些服务器根据需要按需创建虚拟应用程序实例。与边缘页面组装一样，边缘计算实现了完全的源服务器卸载，从而为最终用户带来了巨大的可扩展性和极低的应用程序延迟。

虽然并非每种类型的应用程序都是边缘计算的理想选择，但大型流行的应用程序（例如竞赛、产品目录、商店定位器、调查、产品配置器、游戏等）非常适合边缘计算。

整合在一起

许多这些技术都需要高度分布式的网络。如前所述，路由优化取决于庞大的覆盖网络的可用性，该网络包括许多不同网络上的机器。如果交付服务器靠近最终用户，则预取和页面组装等其他优化最有效。最后，许多传输和应用层优化都需要网络内的双节点连接（即，您控制两个端点）。为了最大化这种优化连接的效果，端点应尽可能靠近源服务器和最终用户。

另请注意，这些优化协同工作。TCP 开销在很大程度上是保守方法的结果，该方法保证在面对未知网络状况时具有可靠性。由于路由优化为我们提供了高性能、无拥塞的路径，因此它允许对传输层优化采取更积极和高效的方法。

高度分布式网络设计

正如我们之前所触及的那样，构建和管理强大、高度分布式的网络并非易事。在 Akamai，我们力求构建一个具有极高可靠性的系统——永不宕机——并且可扩展到足以由相对较少的运营人员管理，尽管在高度异构且不可靠的环境中运行。以下是一些关于设计方法的见解。

指导理念：预期会发生故障

Akamai 设计理念背后的基本假设是，网络中始终会发生大量组件或其他故障。互联网系统存在许多故障模式，例如机器故障、数据中心故障、连接故障、软件故障和网络故障——所有这些故障发生的频率都比人们想象的要高。例如，如前所述，大规模网络中断的原因有很多——包括对等互连问题、跨洋电缆中断和重大病毒攻击。

设计在这种条件下工作的可扩展系统意味着将故障视为自然和预期的事件。网络应继续无缝地工作，尽管发生了这些事件。我们已经确定了一些由此理念产生的实用设计原则。¹

原则 1：确保所有系统中的显着冗余以方便故障转移。尽管这在理论上可能看起来显而易见且简单，但在实践中可能具有挑战性。拥有高度分布式的网络可以实现大量的冗余，如果组件发生故障，可以随时接管的多个备份可能性。然而，为了确保所有系统的稳健性，您可能需要解决现有协议的约束以及与第三方软件的交互，并权衡涉及成本的权衡。

例如，Akamai 网络在很大程度上依赖于 DNS（域名系统），DNS 具有一些影响可靠性的内置约束。一个例子是 DNS 对响应大小的限制，这限制了我们可以返回的 IP 地址数量，这是一个相对静态的 13 个。通用顶级域名服务器为 akamai.net 查询提供关键答案，需要更高的可靠性，因此我们采取了多项措施，包括使用 IP 任播。

我们还在设计系统时考虑了 DNS 使用 TTL（生存时间）来在一段时间内修复解析。虽然通过使用 TTL 获得的效率很重要，但我们需要确保用户不会根据过时的数据被发送到服务器。我们的方法是使用两层 DNS——在全球级别使用更长的 TTL，在本地级别使用更短的 TTL——从而减少 DNS 效率与对变化条件响应之间的权衡。此外，我们在每个级别都内置了适当的故障转移机制。

原则 2：使用软件逻辑来提供消息可靠性。此设计原则直接关系到可扩展性。我们没有在数据中心之间构建专用链路，而是使用公共互联网在我们的整个网络中分发数据——包括控制消息、配置、监控信息和客户内容。我们改进了现有互联网协议的性能——例如，通过使用多路由和有限的 UDP（用户数据报协议）重传来实现可靠性，而不会牺牲延迟。我们还使用软件通过中间服务器路由数据，以确保通信（如优化 2 中所述），即使发生重大中断（例如电缆中断）。

原则 3：使用分布式控制进行协调。同样，此原则对于容错和可扩展性都很重要。一个实际的例子是领导者选举的使用，其中领导者评估可能取决于许多因素，包括机器状态、与其他机器的网络连接以及监控能力。例如，当本地领导服务器的连接性降低时，会自动选举新的服务器来承担领导者的角色。

原则 4：干净地故障并重新启动。基于之前的原则，网络已经被设计为快速且无缝地处理服务器故障，因此我们能够对故障服务器采取更积极的方法，并从上次已知的良好状态重新启动它们。这大大降低了在潜在损坏状态下运行的风险。如果给定机器继续需要重新启动，我们只需将其置于“长睡眠”模式，以最大限度地减少对整体网络的影响。

原则 5：分阶段发布软件。在通过 QA（质量保证）流程后，软件分阶段发布到实时网络。它首先部署到单台机器。然后，在执行适当的检查后，将其部署到单个区域，然后可能部署到网络的其他子集，最后部署到整个网络。发布的性质决定了有多少阶段以及每个阶段持续多长时间。之前的原则，特别是冗余、分布式控制和积极重启的使用，使得可以使用这种分阶段方法频繁且安全地部署软件版本。

原则 6：注意并主动隔离故障。隔离故障的能力，特别是在面向恢复的计算系统中，可能是最具挑战性的问题之一，也是重要且正在进行的研究领域。这是一个例子。考虑一个假设的情况，其中对具有一组罕见配置参数的特定内容的请求触发了潜在的错误。自动使受影响的服务器发生故障是不够的，因为对该内容的请求随后将被定向到其他机器，从而传播问题。为了解决这个问题，我们的缓存算法将每组内容限制在某些服务器上，以限制致命请求的传播。一般来说，没有单个客户的内容足迹应在可用服务器中支配任何其他客户的内容足迹。这些约束是根据当前内容需求水平动态确定的，同时保持网络安全。

实际结果和好处

除了固有的容错优势外，围绕这些原则设计的系统还提供了许多其他好处。

更快的软件推出。由于网络吸收了机器和区域故障而不会产生影响，因此 Akamai 能够使用分阶段推出方法安全但积极地推出新软件。作为一个基准，我们历史上每月在全球网络上实施大约 22 个软件版本和 1,000 个客户配置版本，而不会中断我们的始终在线服务。

最低限度的运营开销。一个庞大、高度分布式、基于互联网的网络可能非常难以维护，因为它规模庞大、网络合作伙伴数量众多、性质异构以及地理区域、时区和语言的多样性。然而，由于 Akamai 网络设计基于组件将发生故障的假设，因此我们的运营团队无需担心大多数故障。此外，如果团队看到任何略微令人担忧的行为，可以积极地暂停机器或数据中心。无需急于使组件立即恢复在线状态，因为网络会吸收组件故障，而不会影响整体服务。

这意味着在任何给定时间，平均只需要 8 到 12 名运营人员来管理我们的大约 40,000 台设备（包括 35,000 多台服务器以及交换机和其他网络硬件）的网络。即使在高峰期，我们也能成功地用不到 20 名工作人员管理这个全球性的高度分布式网络。

更低的成本，更易于扩展。除了管理如此庞大网络所需的最低运营人员外，这种设计理念还产生了若干影响，从而降低了成本并提高了可扩展性。例如，我们使用商品硬件而不是更昂贵、更可靠的服务器。我们在第三方数据中心部署，而不是拥有自己的数据中心。我们使用公共互联网而不是专用链路。我们在更多的小区域（其中许多区域免费托管我们的服务器）而不是更少、更大、更“可靠”的数据中心中部署，在这些数据中心中，拥塞可能最为严重。

总结

尽管在过去十年中，我们看到了互联网的普及性和实用性的显着进步，但带宽密集型 Web 内容、富媒体和基于 Web 和 IP 的应用程序的真正增长才刚刚开始。这种增长带来的挑战是多方面的：随着企业将更多关键功能转移到线上，以及消费者娱乐（游戏、电影、体育）从其他广播媒体转移到互联网，互联网中间一英里承受的压力将变得越来越明显和有害。因此，我们认为，随着我们共同努力使互联网能够扩展以满足下一代用户的需求，本文中提出的问题以及高度分布式内容交付方法的优势将只会变得越来越重要。

参考文献

Afergan，M.，Wein，J.，LaMeyer，A. 2005。构建互联网规模可靠系统的一些原则的经验。在第二届真实大型分布式系统会议论文集 2。（这些原则在这篇研究论文中更详细地阐述。）
Akamai 报告：2008 年第二季度互联网状况；http://www.akamai.com/stateoftheinternet/。（Akamai 的季度报告讨论了这些和其他最近的互联网可靠性事件。）
Anderson，N. 2008。Comcast 在 CES：今年将推出 100 Mbps 连接。ars technica（1 月 8 日）；http://arstechnica.com/news.ars/post/20080108-comcast-100mbps-connections-coming-this-year.html。
Horrigan，J. B. 2008。2008 年家庭宽带普及率。皮尤互联网与美国生活项目；http://www.pewinternet.org/pdfs/PIP_Broadband_2008.pdf。
互联网世界统计。2007。宽带互联网统计：2007 年互联网宽带用户最多的世界国家；http://www.internetworldstats.com/dsl.html。
Mehta，S. 2007。Verizon 在光纤上的豪赌。财富（2 月 22 日）；http://money.cnn.com/magazines/fortune/fortune_archive/2007/03/05/8401289/。
Spangler T. 2007。AT&T：U-verse 电视支出将增加。多频道新闻（5 月 8 日）；http://www.multichannel.com/article/CA6440129.html。
TeleGeography。2008。电缆切断中断了中东和印度的互联网。CommsUpdate（1 月 31 日）；http://www.telegeography.com/cu/article.php?article_id=21528。

TOM LEIGHTON 于 1998 年 8 月共同创立了 Akamai Technologies。他担任首席科学家和董事会董事，是 Akamai 的技术远见家，也是执行委员会的关键成员，负责制定公司发展方向。他是网络应用算法领域的权威。Leighton 是美国艺术与科学院院士、美国国家科学院院士和美国国家工程院院士。他已发表 100 多篇研究论文，其关于并行算法和体系结构的权威著作已被翻译成多种语言。他以最优等成绩毕业于普林斯顿大学，获得工程学学士学位。他获得了麻省理工学院数学博士学位。

最初发表于 Queue 杂志第 6 卷第 6 期—
在数字图书馆中评论这篇文章

更多相关文章

Niklas Blum, Serge Lachapelle, Harald Alvestrand - WebRTC - 面向开放 Web 平台的实时通信
在疫情期间，世界比以往任何时候都更依赖于基于互联网的 RTC（实时通信）。在过去十年中，RTC 产品的数量激增，这在很大程度上是由于更便宜的高速网络接入和更强大的设备，同时也归功于一个名为 WebRTC 的开放、免版税平台。WebRTC 的作用正在从提供有用的体验发展到在疫情期间让数十亿人继续工作和学习，并保持重要的人际联系方面变得至关重要。WebRTC 未来的机遇和影响确实令人着迷。

Benjamin Treynor Sloss, Shylaja Nukala, Vivek Rau - 重要的指标
衡量您的网站可靠性指标，设定正确的目标，并努力准确地衡量这些指标。然后，您会发现您的服务运行得更好，停机时间更少，用户接受度更高。

Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - 跟踪和控制微服务依赖项
如果您曾将钥匙锁在家里或车里，您会对依赖循环感到熟悉。没有钥匙您无法打开锁，但没有打开锁您也无法拿到钥匙。有些循环很明显，但更复杂的依赖循环可能很难在它们导致中断之前被发现。跟踪和控制依赖项的策略对于维护可靠的系统是必要的。

Diptanu Gon Choudhury, Timothy Perrett - 为互联网规模服务设计集群调度器
希望构建调度系统的工程师应考虑他们使用的底层基础设施的所有故障模式，并考虑调度系统的操作员如何配置补救策略，同时在租户系统所有者进行故障排除期间帮助保持租户系统尽可能稳定。