关于Web 应用的性能、可靠性和可伸缩性，最大的瓶颈在哪里？在许多情况下，限制性的瓶颈是网络传输，或者说是数据在互联网上往返于服务器和终端用户之间的时间。
如今，设计网络应用时，服务端的基础设施往往最受关注，这也是容易受架构师控制的部分。基础设施的良好性能和可靠性现在是一个相对容易理解和处理的问题。然而，从最终用户的角度来看，为了实现强大的应用性能和可靠性，服务端的基础设施只是个必要不充分条件。
难以驾驭和经常被忽视的是，互联网“中间网络”的模糊将延迟瓶颈、吞吐量约束和可靠性问题注入到 Web 应用的性能公式中。实际上，“中间网络”这个词本身就是模糊的，因为它指的是由许多竞争实体拥有的、通常跨越数百或数千公里的异构基础设施。
在服务器与用户中间的网络问题
虽然我们把互联网称为一个单一的实体，但它实际上是由数万个不同的互相竞争的网络组成的，每个网络都提供一些最终用户的子集访问。随着市场需求的增长，承载服务器的IDC和用户的接入网络都有了极大的提升，互联网的容量也在不断发展。
另一方面，那些由网络流量交换的对等节点和中转节点组成的互联网“中间网络”实际上是一片无人区。在这里，从经济上讲，几乎没有动力去扩大产能。如果说有什么不同的话，那就是网络希望尽量减少流入他们网络的无偿流量。因此，对等节点通常负载过重，导致数据包丢失和服务退化。对等节点经济模型的脆弱可能会带来更严重的后果，其他的可靠性问题也困扰着它们。互联网中断的原因多种多样，包括跨洋电缆中断、断电和DDOS。互联网主要的网间路由算法协议是 BGP，它和物理网络基础设施一样容易受到影响。
这些互联网可靠性和对等节点问题的普遍存在意味着数据经过中间网络的时间越长，它就越容易受到拥塞、数据包丢失和性能差的影响。
规模问题
随着对宽带需求和可用性的增加，用户对更快的网站、更丰富的媒体和高交互性应用程序的期望也在上升。不断增加的流量负载和性能要求反过来又给互联网的“中间网络”带来了更大的压力。
距离瓶颈
视频和富媒体文件大小增长的一个有趣的副作用是，服务器和最终用户之间的距离对最终用户的性能至关重要。既然数据包可以以接近光速的速度穿越网络，在网络并不拥挤的时候，为什么一个“大文件”要花这么长时间才能穿越网络到达用户呢？
这归因于底层网络协议的工作方式，延迟和吞吐量是直接耦合的。例如，TCP 窗口一次只允许发送少量数据 ，然后必须暂停并等待接收端的确认。这意味着网络往返时间(延迟)有效地抑制了吞吐量，这可能成为文件下载速度和视频观看质量的瓶颈。
数据包丢失使问题进一步复杂化，因为如果检测到数据包丢失，这些协议在等待确认之前会退出并发送更少的数据。较长的距离增加了拥塞和数据包丢失的机会，从而进一步损害吞吐量。
内容分发的主要方式
考虑到这些瓶颈和可伸缩性挑战，如何实现通过互联网有效交付内容呢？以及如何提升应用程序所需的性能和可靠性水平呢？内容分发体系中主要有四种方法: 集中托管、CDN、分布式CDN 和 P2P (对等网络)网络。
集中托管
传统的Web 站点使用一个或少量的配置站点来承载内容。商业站点通常至少有两个地理上分散的镜像站点，以提供额外的性能、可靠性和可伸缩性。
这种方法是一个良好的开端，对于迎合本地化用户的小型网站来说，这可能已经足够了。然而，由于最终用户体验受不可靠的互联网“中间网络”的影响，其性能和可靠性一般会低于对商业级网站和应用程序的预期。
另外， 站点镜像复杂且成本高昂，管理也是如此。流量水平波动很大，因此需要为峰值流量提供更多的冗余资源，这意味着昂贵的基础设施在大多数时候将得不到充分利用。而准确地预测流量需求是极其困难的，集中托管无法提供灵活性来处理突发的流量。
数据中心
通过将可缓存内容从源服务器转移到更大的共享网络，内容分发网络提供了更好的可伸缩性。一种常见的 CDN被描述为“数据中心”，包括可能连接到骨干网的几十个高容量数据中心缓存和分发的资源。
虽然这种方法比集中托管提供了一些性能优势和规模经济，但潜在的改进是有限的，因为 数据中心的服务器仍然远离大多数用户，仍然收到中间网络的瓶颈影响。有了自己的骨干网仍不足以实现商业级的性能，这似乎有悖常理。事实上，即使是最大的网络所控制的最终用户也是有限的，互联网的网络上用户是一个长尾分布。即使连接到主干网，数据也必须穿过“中间网络”的泥沼才能到达互联网的大多数用户。
分布式CDN
另一种方法是利用一个高度分布式的网络，一个有数千个网络服务器的网络，而不是几十个。从表面上看，这可能看起来非常类似于“数据中心”的CDN。然而，在现实中，它是一种完全不同的内容服务器部署方式，在分布程度上高出两个数量级。例如，通过将服务器放在最终用户的ISP中，一个高度分布的 CDN 消除了对等、连接、路由和距离问题，并减少了所依赖的互联网组件数量。此外，这种架构具有扩展性。
另一方面，部署高分布式 CDN 成本高、耗时长，并伴随着一系列挑战。从根本上说，必须从部署和管理的角度有效地设计网络的规模，包括:
- 复杂的全局调度、映射和负载平衡算法
- 复杂的缓存管理协议，以确保高缓存命中率
- 分布式控制协议和可靠的自动监测和报警系统
- 分布式内容更新机制、数据完整性保证和管理系统
- 智能自动故障转移和恢复方法
- 大规模数据聚合和分发技术
- 健壮的全局软件部署机制
这些都是非常重要的挑战，是CDN的核心技术。
P2P 网络
由于高分布式体系结构对于视频分发中的可伸缩性和性能至关重要，因此考虑 P2P 体系结构是很自然的。P2P 可以被认为是将分布式体系结构发挥到了逻辑极致，理论上提供了近乎无限的可伸缩性。此外，在当前的网络定价结构下，P2P 提供了很有吸引力的经济性。
然而，在现实中，P2P 面临着一些严重的限制，主要是因为 P2P 网络的总下载容量受到其总上行容量的限制，对于用户的宽带连接，上行速度往往比下行速度低得多。
这意味着，在实时流媒体等情况下，上传(对等点共享内容)的数量受到下载(对等点请求内容)数量的限制，平均下载吞吐量相当于平均上行吞吐量，因此往往不能支持高质量的Web流量。
使用一种混合方法可以获得更好的结果，即利用 P2P 作为CDN的扩展，P2P 可以帮助降低在某些情况下的总体分发成本。然而，由于 P2P 网络的容量有限，网络中的非 P2P的体系结构仍然决定着整体性能和可伸缩性。
这四种网络体系结构各有其优缺点，为我们在考虑内容分发的时候提供了方向。
CDN选择中的技术因素
在网络中的任何时候都会发生大量的组件或其他故障，互联网系统出现了许多故障模式，例如机器故障、数据中心故障、连接故障、软件故障和网络故障等等，所有这些故障发生的频率都比人们想象的要高。我们希望尽管发生了故障，网络应该还能够继续无缝地工作。
在我们的应用系统中，需要选择一个健壮的、高分布式CDN，这里从技术层面给出了几点建设性的建议。
考察点1: 确保所有系统具有大量冗余，以方便故障转移
拥有一个高度分布式的CDN可以带来大量的冗余，如果一个组件出现故障，可以进行多种备份。然而，为了确保所有系统的健壮性，可能需要绕过现有协议的约束和与第三方软件的交互，以及涉及成本的折衷，看看是否在每个级别都构建了适当的故障转移机制。
考察点2: 使用软件逻辑提供消息的可靠性
在数据中心之间建立专用的链接，还是使用公共互联网在CDN网络中分发数据么？包括控制信息、配置、监控信息和客户的内容。是否使用了 UDP 的多路由和有限重传，在不牺牲延迟的情况下实现可靠性。
考察点3: 使用分布式控制进行协调
主要是考量容错和可伸缩性，主服务器的评估可以依赖于许多因素，包括机器状态，与网络中其他机器的连接，以及监控能力。当本地主服务器的连接性降低时，是否自动选择一个新服务器来承担主服务器的角色。
考察点4: 简单失败，优雅重启
网络已经被设计成能够快速无缝地处理服务器故障，并从最后一个已知的良好状态重新启动它们。这降低了在潜在的损坏状态下工作的风险。如果给定的机器继续需要重新启动，只需将其置于“休眠”模式，以尽量减少对整个网络的影响。
考察点5: 阶段性软件发布
CDN的供应商是否分阶段将网络软件发布到实时的网络中，即先单台部署，然后，在执行适当的检查之后，进行单区域部署，然后可能部署到网络的其他子集，最后全网部署。发布的性质决定了每个阶段持续的时间和数量。
考察点6: 主动检查缺陷
隔离故障的能力，特别是在面向恢复的计算/系统中，也许是最具挑战性的问题之一。如果有这样一种情况，即对具有一组罕见配置参数的特定内容的请求会引发潜在的 bug。仅仅自动让受影响的服务器失效是不够的，因为对这些内容的请求将被定向到其他机器，从而扩大了故障域。是否有缓存算法将每组内容限制在特定的服务器上呢？这些约束是否根据当前对内容的需求水平动态确定的，同时保证了网络的安全。
考虑到CDN庞大的规模异构的性质以及地理、时区和语言的多样性，大型的、高度分布的、基于 internet 的网络可能很难维护。我们需要的是操作更少，成本更低，而且容易扩容的CDN 网络。
应用程序的网络优化
从历史上看，CDN方案主要关注静态内容的卸载和交付，然而，随着 Web 应用变得越来越动态化、个性化和业务逻辑驱动，加速非内容的处理能力对于提供强大的用户体验也变得同样重要。
加速数据的往返是一个复杂的问题，但是通过使用高分布式的基础结构，许多优化都是可能的。
1: 减少传输层开销
TCP 协议有着巨大的开销，数据在两个通信方之间需要多次往返来建立连接，使用缓慢的初始数据交换速率，并从数据包丢失中缓慢恢复。相比之下，使用持久连接并优化参数以提高效率的网络可以通过减少传送同一组数据所需的往返次数来显著提高性能。
2: 寻找更好的路由
除了减少往返所需的时间外，我们还希望减少每次往返所需的时间，确切地说，每次通过互联网的时候数据往返所需的时间。乍一看，这似乎是不可能的。所有的互联网数据必须由BGP路由，并且必须通过许多自治网络传输。
BGP 是简单的和可扩展的，但不是非常有效或健壮。通过利用CDN，可以使用更快、更少拥堵的路由，可以将通信速度提高30%甚至更多，还可以通过在缺省路由中断时寻找替代路由来实现更高的通信可靠性。
3: 内容预取
我们可以在应用程序层执行许多其他操作，以提高最终用户的 Web 应用程序响应能力。一种方式就是内容预取: 当边缘服务器向终端用户提供资源时，它也可以解析并缓存，在终端用户的浏览器请求之前检索所有预取的内容。
这种优化的有效性依赖于在最终用户附近有服务器，这样用户就可以感知到应用程序响应的级别类似于直接从附近服务器发出的，尽管事实上，一些预取的内容是通过长途跋涉从源服务器获取的。另外，请注意，与链接预取不同，内容预取不会消耗额外的带宽资源，也不会请求与终端用户请求无关的对象。在这些情况下，预取对于 Web 应用程序的用户感知响应能力有着巨大的影响。
4: 边缘组装
在边缘服务器上缓存页面片段，并在边缘节点动态地组装它们，以响应最终用户的请求。页面可以是个性化数据，包括最终用户的位置，连接速度，cookie 值等。在边缘组装页面不仅可以为源服务器减压，而且可以避免中间的延迟，从而降低最终用户的响应时间。
5: 使用压缩和增量编码
对基于文本的组件进行压缩可以将内容减少到原来大小的十分之一。使用增量编码，即服务器只发送缓存页面和动态生成页面之间的差异，也可以大大减少必须在互联网上传输的内容量。
通过使用一个CDN来控制“中间网络”的两个端点，无论使用哪种浏览器，压缩和增量编码都可以成功使用。在这种情况下，性能得到了提高，因为只有很少的数据传输到中间网络。然后，边缘服务器解压缩内容，并将完整、正确的内容交付给最终用户。
6: 边缘计算
将应用程序分发到边缘服务器提供了应用程序性能和可伸缩性的极限。与边缘页面组装一样，边缘计算支持完整的源服务器加载，从而为终端用户带来巨大的可伸缩性和极低的应用程序延迟。
虽然并非每种类型的应用程序都适合于边缘计算，但是大量流行的应用(如产品目录、存储、产品配置、游戏等)都非常适合边缘计算。
综合使用
其中许多优化技术都需要依赖高分布式CDN网络。路由优化依赖于一个庞大的覆盖层网络的可用性，该覆盖层网络包括了许多不同网络上的机器。如果交付服务器靠近最终用户，则内容预取和页面动态组装的优化方法将最为有效。最后，许多传输层和应用层优化需要在网络中使用双节点连接。为了最大化这个优化连接的效果，端点应该尽可能接近源服务器和最终用户。
这些优化是协同工作的，TCP 开销在很大程度上是在未知网络条件下保证可靠性的结果。因为路由优化给我们提供了高性能、无拥塞的路径，它允许采用更积极、更有效的方法来优化传输层。
结束语
尽管、互联网在不确定性和有用性方面的巨大进步，但是带宽密集型的网络内容、富媒体以及基于 Web 和 ip 的应用在跳跃式增长。这种增长带来的挑战有很多: 随着企业将更多的关键功能转移到网上，消费者娱乐(游戏、电影、体育)已经转移到了互联网，互联网“中间网络“的压力将变得越来越明显，越来越有害。因此，使互联网能够满足用户的需求，面向应用系统的网络优化是必须的。
