ACM通信

实践

提高互联网上的性能

汤姆•雷顿
ACM通讯，2009年2月，第52卷第2期，44-51页
10.1145/1461928.1461944
评论

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

但情况并非一直如此。十年前最后一英里是一个可能的罪魁祸首，用户被限制在缓慢的拨号调制解调器访问速度。但是，最近全球宽带的高水平渗透——全球超过3亿用户不仅创造了最后一英里瓶颈的历史，他们也增加了其他互联网基础设施跟上步伐的压力。⁵

今天,第一英里也就是说，在设计Web应用程序时，原始基础设施往往会受到最多的关注。这是问题中最受应用程序架构师控制的部分。实现良好的第一英里性能和可靠性现在是一个相当容易理解和解决的问题。从最终用户的然而，从某种角度来看，健壮的第一英里是实现强大的应用程序性能和可靠性的必要条件，但还不够。

这就是中间一英里的作用。Internet难以驯服且经常被忽略，它模糊的中路将延迟瓶颈、吞吐量限制和可靠性问题注入到Web应用程序性能方程中。实际上,这个词中间一英里本身是一个错误的名称，因为它指的是由许多竞争实体拥有的异构基础设施，通常跨越数百或数千英里。

本文重点介绍了目前“中英里”面临的最严重的挑战，并提供了克服这些挑战和提高Internet性能的方法。

回到顶部

夹在中间

虽然我们经常把互联网看作一个单独的实体，但它实际上是由13000个不同的相互竞争的网络组成的，每个网络都提供对一些终端用户子集的访问。在市场经济的影响下，互联网容量多年来不断演变。随着公司支付托管费用，最终用户支付接入费用，资金从第一英里和最后一英里流入网络。在过去的5到10年里，第一英里和最后一英里的运力分别增长了20倍和50倍。

另一方面，互联网的中间阶段由互联和中转站组成，在这里，网络交易实际上是一个无人区。在这方面，从经济上讲，几乎没有什么动力去建设产能。如果有什么区别的话，网络想要最小化进入他们的网络的流量，而这些流量是他们没有得到报酬的。因此，对等点经常会出现负载过重的情况，从而导致丢包和业务退化。

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

其他可靠性问题也困扰着中路。互联网中断的原因多种多样，如跨洋电缆切断、电力中断和DDoS(分布式拒绝服务)攻击。例如，2008年2月，由于一系列海底电缆被切断，东南亚和中东地区的通信严重中断。根据TeleGeography的数据，欧洲和中东之间的带宽连接减少了75%。⁸

像BGP(边界网关协议，互联网的主要网络路由算法)这样的互联网协议就像物理网络基础设施一样容易受到影响。例如，在2008年2月，当巴基斯坦试图通过广播一条更具体的BGP路由来阻止国内对YouTube的访问时，它意外地导致了几乎全球范围内的YouTube中断，这凸显了BGP在人为错误(以及违规操作)下的脆弱性。²

这些因特网可靠性和点点问题的普遍存在意味着数据在中间传输的距离越长，就越容易出现拥塞、包丢失和性能差的问题。目前最显著的趋势是最后一英里运力和需求的增加，进一步加剧了这些中英里的问题。随着互联网服务提供商对“最后一英里”基础设施的投资，宽带普及率和速度都在持续上升。美国电话电报公司(AT&T)刚刚花费了大约65亿美元推出其U-verse服务，而威瑞森(Verizon)则花费230亿美元，到2010年为1800万家庭提供FiOS(光纤服务)。^6，7康卡斯特最近也宣布计划在一年内提供高达100Mbps的网速。^3.

需求推动了这最后一英里的繁荣:皮尤互联网研究中心2008年的报告显示，三分之一的美国宽带用户选择为更快的连接支付更高的费用。⁴Akamai技术公司的数据显示在图159%的全球用户拥有宽带连接(速度超过2mbps)， 19%的全球用户拥有超过5mbps的“高宽带”连接，速度足以支持dvd质量的内容。²高宽带数据在短短三个月内就增长了19%。

回到顶部

规模的问题

随着宽带需求和可用性的增加，用户对更快的站点、更丰富的媒体和高度交互的应用程序的期望也在增加。增加的流量负载和性能要求反过来对互联网的内部基础设施施加了更大的压力。事实上，视频的迅速普及已经引发了关于互联网是否能够扩大规模以满足需求的辩论。

例如，考虑向5000万观众提供电视质量的流媒体(2Mbps)，这大约是一个流行电视节目的观众规模。该场景产生100Tbps的聚合带宽需求。这是近期(未来2到5年)一个合理的设想，但它比今天最大的在线事件大了几个数量级，导致人们对互联网处理这种需求的能力产生怀疑。此外，这些数字还只是一个电视节目的数字。如果数以亿计的终端用户定期通过互联网下载蓝光质量的电影，由此产生的流量负荷将增加一到两个数量级。

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

事实证明，由于底层网络协议的工作方式，延迟和吞吐量是直接耦合的。例如，TCP每次只允许发送少量数据(即TCP窗口)，然后必须暂停并等待接收端的确认。这意味着吞吐量被网络往返时间(延迟)有效地限制了，这可能成为文件下载速度和视频观看质量的瓶颈。

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

图2说明了(服务器和最终用户之间的)距离对吞吐量和下载时间的影响。5年或10年前，拨号调制解调器的速度可能是这些文件的瓶颈，但当我们展望今天和未来的互联网时，中英里距离成为瓶颈。

回到顶部

内容交付的四种方法

考虑到这些瓶颈和可伸缩性挑战，如何达到通过Internet有效交付内容和应用程序所需的性能和可靠性水平?在内容交付体系结构中有四种主要的分发内容服务器的方法:集中托管、“大数据中心”CDNs(内容交付网络)、高度分布式CDNs和对等网络。

集中的主机。传统架构的Web站点使用一个或少量的搭配站点来承载内容。商业规模的站点通常至少有两个地理上分散的镜像位置，以提供额外的性能(通过更接近不同的终端用户组)、可靠性(通过提供冗余)和可伸缩性(通过更大的容量)。

这种方法是一个很好的开始，对于面向本地化用户的小型网站来说，这可能已经足够了。然而，其性能和可靠性低于商业级站点和应用程序的预期，因为终端用户的体验取决于不可靠的互联网和它的中英里瓶颈。

还有其他的挑战:站点镜像复杂且昂贵，管理容量也是如此。交通水平波动很大，因此需要为高峰交通水平提供供应，意味着昂贵的基础设施在大多数时间都没有得到充分利用。此外，准确预测流量需求是极其困难的，集中式托管模型无法提供处理意外激增的灵活性。

大数据中心cdn。内容分发网络通过将可缓存内容的分发从源服务器转移到更大的共享网络，从而提高了可伸缩性。一种常见的CDN方法可以被描述为“大数据中心”架构，从可能连接到主要骨干的几十个大容量数据中心中获取和交付客户内容。

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

这似乎是违反直觉的，在几十个主要骨干的存在并不足以实现商业级别的性能。事实上，即使是这些网络中最大的，也只能控制很少的终端用户访问流量。例如，排名前30的网络结合只提供50%的终端用户流量，并且从那里迅速下降，在互联网的13000个网络中有着非常长的尾分布。即使连接到所有最大的骨干网络，数据也必须通过中间一英里的沼泽才能到达14亿互联网用户中的大多数。

一个快速的粗略计算表明，当我们走向视频世界时，这种类型的架构在可伸缩性方面遇到了瓶颈。考虑在这样的架构上进行慷慨的向前投影，50个大容量数据中心，每个中心有30个出站连接，每个10Gbps。这为这种类型的网络提供了15Tbps的总容量上限，远远低于短期内支持视频所需的100Tbps。

将高度分散。另一种内容传递的方法是利用高度分布式的网络——服务器分布在数千个网络中，而不是几十个。从表面上看，这种架构可能与“大数据中心”CDN非常相似。然而，在现实中，这是一种完全不同的内容服务器放置方法，在分发程度上有两个数量级的差异。

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

此外，这个架构是可伸缩的。例如，它可以实现100Tbps的容量，通过部署20台服务器，每个服务器能够在5000个边缘位置提供1Gbps的容量。

另一方面，部署一个高度分布式的CDN是昂贵和耗时的，并伴随着它自己的一系列挑战。从根本上说，从部署和管理的角度来看，网络必须设计成能够有效伸缩。这就需要发展一些技术，包括:

• 复杂的全局调度、映射和负载平衡算法
• 分布式控制协议和可靠的自动化监控和报警系统
• 智能和自动化的故障转移和恢复方法
• 大规模数据聚合和分发技术(设计用于处理及时性、准确性或完整性之间的不同权衡)
• 健壮的全球软件部署机制
• 分布式内容新鲜度、完整性和管理系统
• 先进的缓存管理协议确保高缓存命中率

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

点对点网络。由于高度分布式体系结构对于实现视频分发中的可伸缩性和性能至关重要，因此很自然地考虑采用P2P(对等)体系结构。P2P可以被认为是将分布式体系结构发挥到其逻辑极限，理论上提供了几乎无限的可伸缩性。此外，在当前的网络定价结构下，P2P提供了有吸引力的经济。

然而，在现实中，P2P面临着一些严重的限制，最显著的原因是，P2P网络的总下载容量受到其总上行容量的限制。不幸的是，对于消费者宽带连接来说，上行速度往往比下行速度低得多:例如，康卡斯特的标准高速互联网包提供6Mbps的下载，但只有384Kbps的上传(下载吞吐量的十六分之一)。

这意味着，在直播这种情况下，上传者(共享内容的对等者)的数量受到下载者(请求内容的对等者)的数量的限制，平均下载吞吐量相当于平均上行吞吐量，因此甚至不能支持普通的web质量流。类似地，P2P在“快闪人群”的场景中失败了，在这种场景中，需求突然急剧增长，下载者的数量大大超过了网络中上传者的容量。

使用混合方法可以获得更好的结果，利用P2P作为分布式交付网络的扩展。特别是，在某些情况下，P2P可以帮助降低整体分发成本。然而，由于P2P网络的容量有限，网络的非P2P部分的体系结构仍然控制着整体性能和可伸缩性。

这四种网络体系结构各有其优缺点，但最终，为了向全球Web受众交付富媒体，高度分布式体系结构提供了交付商业级别性能、可靠性和伸缩性的唯一健壮解决方案。

回到顶部

应用程序加速

历史上，内容交付解决方案一直专注于静态内容的卸载和交付，到目前为止，我们的讨论也集中在这一点上。然而，随着Web站点变得越来越动态、个性化和应用程序驱动，这种能力将会加速当前时间内容对于提供强大的终端用户体验同样至关重要。

Ajax、Flash和其他RIA(富Internet应用程序)技术可以增强Web应用程序在浏览器端的响应能力，但最终，这些类型的应用程序仍然需要大量的往返到原始服务器。这使得它们非常容易受到我前面提到的所有瓶颈的影响:点拥塞、网络延迟、糟糕的路由和互联网中断。

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

优化1:减少传输层开销。基于可靠性而非效率的架构，TCP等协议的开销很大。它们需要多次往返(在通信双方之间)来建立连接，使用较慢的初始数据交换速率，并缓慢地从数据包丢失中恢复。相比之下，使用持久连接并优化参数以提高效率(已知当前网络条件)的网络可以通过减少交付相同数据集所需的往返次数来显著提高性能。

优化2:寻找更好的路线。除了减少所需的往返次数外，我们还希望减少在Internet上每次往返所需的时间。乍一看，这似乎是不可能的。所有的Internet数据必须通过BGP路由，并且必须在众多的自治网络中传输。

BGP简单且可扩展，但不是非常高效或健壮。通过利用一个高度分布式的网络(在许多不同的网络上提供潜在的中间服务器)，你实际上可以通过使用更快、更少拥塞的路由，将非缓存通信速度提高30%到50%或更多。当缺省路由中断时，您还可以通过寻找替代路由来实现更大的通信可靠性。

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

这种优化的有效性依赖于让服务器靠近终端用户，这样用户就能感受到应用程序的响应程度，就像直接从附近的服务器交付应用程序一样，尽管事实上，一些嵌入的内容是通过长途Internet从原始服务器获取的。例如，通过前向缓存进行预取就不能提供这种性能优势，因为预取的内容在到达最终用户之前仍然必须经过中间一英里。另外，请注意，与链接预取(也可以进行)不同，嵌入内容预取不会占用额外的带宽资源，也不会请求终端用户可能不会请求的无关对象。

随着当前高度个性化应用程序和用户生成内容的趋势，不可缓存或长尾(也就是说，不太可能在缓存中)嵌入内容的数量在增长。在这些情况下，预抓取对用户感知到的Web应用程序响应能力有很大的影响。

优化4:在边缘组装页面。接下来的三个优化涉及到减少需要经过中间英里的内容数量。一种方法是在边缘服务器缓存页面片段，并在边缘动态地组合它们以响应最终用户的请求。页面可以根据终端用户的位置、连接速度、cookie值等特征进行个性化(在边缘)。在边缘组装页面不仅减轻了原始服务器的负担，而且由于避免了中间的距离，最终用户的延迟也大大降低了。

优化5:使用压缩和增量编码。压缩HTML和其他基于文本的组件可以将经过中间英里的内容量减少到原始大小的十分之一。使用增量编码，服务器只发送区别在缓存的HTML页面和动态生成的版本之间，还可以大大减少必须通过长途Internet传输的内容量。

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

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

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

回到顶部

把它们放在一起

其中许多技术都需要高度分布的网络。如前所述，路由优化依赖于包括许多不同网络中的机器的巨大覆盖网络的可用性。如果交付服务器靠近最终用户，则预抓取和页面组装等其他优化是最有效的。最后，许多传输层和应用层优化需要网络中的双节点连接(也就是说，您可以控制两个端点)。为了最大化这种优化连接的效果，端点应该尽可能靠近原始服务器和最终用户。

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

回到顶部

高度分布式网络设计

前面简要地提到，构建和管理一个健壮的、高度分布式的网络并不是一件容易的事情。在Akamai，我们试图建立一个具有极高可靠性的系统，没有停机时间，而且可以扩展到由一个相对较小的操作人员管理，尽管在一个高度异构和不可靠的环境中操作。以下是一些关于设计方法论的见解。

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

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

原则1:确保所有系统都有足够的冗余，方便故障切换。虽然这在理论上看起来是显而易见的和简单的，但在实践中可能是具有挑战性的。高度分布式的网络可以实现大量冗余，如果某个组件发生故障，多个备份可能性随时可以接管。然而，为了确保所有系统的健壮性，您可能需要绕过现有协议的约束以及与第三方软件的交互，并平衡涉及成本的权衡。

例如，Akamai网络严重依赖于DNS(域名系统)，它有一些影响可靠性的内置约束。一个例子是DNS对响应大小的限制，这限制了我们可以返回到相对静态的13个IP地址的数量。为akamai.net查询提供关键答案的通用顶级域服务器需要更高的可靠性，因此我们采取了几个步骤，包括使用IP Anycast。

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

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

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

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

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

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

回到顶部

实际效果与效益

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

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

最小的操作开销。考虑到庞大的、高度分布式的、基于internet的网络的规模、网络伙伴的数量、异构的性质以及地理、时区和语言的多样性，它可能很难维护。然而，因为Akamai网络设计是基于组件会失效的假设，所以我们的运营团队不需要担心大多数的故障。此外，如果发现任何稍微令人担忧的行为，团队可以主动暂停机器或数据中心。没有必要急于让组件立即恢复在线，因为网络会吸收组件故障，而不会影响整体服务。

这意味着在任何给定的时间，平均只需要8到12名操作人员就可以管理我们大约40000个设备的网络(包括超过35000个服务器、交换机和其他网络硬件)。即使在高峰时期，我们也能用不到20名员工成功地管理这个全球高度分布的网络。

成本更低，更容易扩展。除了管理如此庞大的网络所需的最少操作人员之外，这种设计理念还具有一些影响，可以降低成本并提高可伸缩性。例如，我们使用普通的硬件，而不是更昂贵、更可靠的服务器。我们部署在第三方数据中心，而不是自己的数据中心。我们使用公共互联网，而不是专用的链接。我们将服务器部署在大量较小的区域，其中许多区域的服务器是为了更自由而不是更少、更大、更“可靠”的数据中心，因为那里的拥塞可能会更严重。

回到顶部

结论

尽管在过去的十年中，我们已经看到了Internet在普遍性和实用性方面的巨大进步，但带宽密集的Web内容、富媒体以及基于Web和ip的应用程序的真正增长才刚刚开始。这种增长带来了许多挑战:随着企业将更多的关键功能转移到网上，随着消费者娱乐(游戏、电影、体育)从其他广播媒体转移到互联网，互联网的中路将变得越来越明显和有害。因此，我们相信，随着我们共同努力使互联网适应下一代用户的需求，本文中提出的问题以及高度分布式的内容交付方法的好处只会变得越来越重要。

回到顶部

回到顶部

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2009 ACM有限公司

---

没有发现记录