53、内容分发之一（应用层）

引言

• 由于分发内容的任务与通信完全不同，它对网络提出了不同的需求。例如，如果Sally想与Jitu谈话，她可能向他的移动电话发出IP 语音呼叫。通信必须在特定的计算机上完成：它呼叫Paul 的计算机将不能做得很好。但是，如果Jitu 想观看他团队的最新板球比赛，他很幸福地可以从任何提供服务的计算机上获得视频流。他不介意计算机是Sally 的或者是Paul 的，或者更加可能的是一台Internet 上的未知服务器。也就是说，相对于内容来说位置无关紧要，除了它会影响性能（和合法性〉。
• 另一个不同是一些提供内容的Web 站点已红极一时。YouTube 是一个典型的例子。它允许用户共享他们自己创作的影片，无论任何一个可以想象的主题都能找到相应的视频。You Tube 和其他大型内容提供商建立了它们自己的内容分发网络。这些网络使用了遍布在世界各地的数据中心，为数量极其庞大的客户群提供具有良好性能和可用性的内容。随着时间的推移，内容分发所用技术也已经被开发了出来。
• 研究人员针对内容分发开发了使用带宽的不同体系结构。一种体系结构就是内容分发网络（CDN, Content Distribution Network）。采用这种体系结构，内容提供商在Internet 的某些位置建立一组分布式机器，然后通过它们给客户提供内容。另一种体系结构是对等网络（P2P, Peer-to-Peer ） .采用这种体系结构， 一组计算机把它们的资源集中起来，彼此互相服务提供内容，无须单独配置服务器或者任何中央控制节点。

1、内容和Internet 流量

• 为了设计和工程化工作良好的网络，我们需要理解网络运载的流量。例如，随着Web重心转移到了内容上，服务器己经从公司办公室迁移到了Internet 数据中心，中心提供了大量拥有超级优秀网络连接的机器。如今要运行一个小型服务器，从Internet 数据中心租用一台托管的虚拟服务器，甚至也比在家里或办公室运行一台与Internet 有宽带连接真实的机器更容易和更方便。
• 幸运的是，关于Internet 流量有必要了解的事实只有两个。第一个事实是，流量的变化很快，不仅表现在细节上，而且在整体上也如此。在1994 年之前，大部分流量是传统的FTP 文件传输（在计算机之间移动程序和数据集）和电子邮件。然后Web 出现了，并成倍地增长。在2000 年网络泡沫之前Web 流量将FTP 和电子邮件的流量远远地抛在了后面。从2000 年左右开始，共享音乐，然后是共享电影的P2P 文件异军突起。到2003 年，大多数Internet 流量变成了P2P 流量，它把Web 流量远远地抛在了后面。在2000 年后期的某个时候，使用内容分发方法的网站提供视频流，比如YouTube 等，视频流开始超过P2P 流量。我们必须指出的一点是Internet 流量迅速发生着震撼般的转变，并呈现出一定的规律性。接下来会发生什么？请看本书的第6 版，我们将告诉你答案（期待啊，什么时候出哦）。
• 有关Internet 流量的第二个基本事实是它的高度倾斜特性。我们所熟悉的许多特性都是聚集起来取个平均值。例如，大多数成年人的平均身高接近。有一些很高的人和一些很矮的人，但很少有非常非常高或非常非常矮的人。对于这类特性，有可能设计出一个范围，它不是很大但仍然捕获了大多数人口。Internet 流量与此不同。长期以来，人们一直认为少量Web 站点具有大量的流量，大量的Web 站点具有很少的流量。
• Web 内容，相同的倾斜显而易见的。录影带出租店、公共图书馆和其他类似组织的经验表明，井非所有项目都同样受欢迎。实验中，当有N 个电影可用，所有请求第k 个最流行电影的比例大约为C/K 。在这里， C 用来计算规一化的和，即C = 1/(1 + 1/2 + 1/3 + 1/4 + 1/5 +…+ 1/N)。因此，最流行电影的流行度是排名第七流行度电影的7 倍。这个结果称为齐普夫定律，它以George Zipf 的名字命名，这是一位哈佛大学的语言学教授，他指出一个字在大段文字中的使用频率和它的排名成反比的。例如，第40 个最常见字的使用次数是第80 个最常见字的使用次数的两倍，是第120 个最常见字的使用次数的3 倍。
• 下图a显示了齐普夫分布。它捕获的概念是有少数受欢迎的项目和很多不那么受欢迎的项目。要认识这种形式的分布，把数据绘制在两轴的对数尺度就容易看出，如图b所示。结果应该是一条直线。
• 当人们查看流行的网页时大致遵循齐普夫定律。齐普夫分布是一个称为幕定律（ power law ）家族分布的例子。幕定律在许多人类现象上是显而易见的，比如城市人口和财富的分布。这意味着平均站点并不具备有用的代表性。站点最好描述成受欢迎或不受欢迎。这两种站点才是至关紧要的。流行的网站明显是个问题，因为一些热门网站可能要对Internet 上的大多数流量负责。也许令人惊讶的是不受欢迎的网站也会是个问题。这是因为所有指向不受欢迎网站的流量总额占用了总流量的很大一部分。原因就在于有那么多不受欢迎的网站。许多不受欢迎的选择组合起来就是个问题，这种概念己经通过书籍得到普及，比如《长尾理论》。
• 为了在这个倾斜世界里有效地工作，我们必须能够构建两种类型的Web 站。不受欢迎的网站很容易处理。使用DNS ，把许多不同的站点实际上指向Internet 上的同一台计算机，在这台计算机上运行全部不受欢迎的网站。另一方面，流行的网站很难应付。没有单个的计算机足够强大到能运行所有流行的网站，而且如果使用一台计算机，那么当它发生故障将使数百万用户无法访问网站。为了处理这些网站，我们必须建立内容分发系统。

2、服务器农场和Web 代理

• 到目前为止我们看到的Web 设计都只有一个单独的服务器，这台机器和多个客户端机器交谈。为了构建大型Web 站点并且运行性能良好，我们可以加快服务器端的处理或者客户端的处理。在服务器端，用更强大的Web 服务器建设成一个服务器农场，这里用一个计算机集群替代单个的服务器为客户提供服务。在客户端，可以通过更好的缓存技术来实现更好的性能。尤其是，代理缓存为一组客户提供了大容量的共享缓存。这些流行的站点需要用到内容分发，这些方法还必须与坐落在许多不同地点的计算机结合起来一起发挥作用。

服务器农场

• 无论一台机器的带宽多大，在超负荷之前它也只能为一定数量的Web 请求服务。这种情况的解决方案是使用多台计算机来充当Web 服务器。这个想法导致了如图所示的服务器农场模型的诞生。
• 这个模型看似简单，实质上它的困难之处在于组成服务器农场的一组计算机，在客户看起来必须像单个逻辑网站。如果做不到这样，那我们只是建设了不同的网站，让这些网站并行运行而己。所有的解决方案都假设任何一台服务器可以处理来自任何客户端的请求。要做到这一点，每个服务器必须有一份Web 站点的副本。为此目的，这些服务器都连接到一个共同的后端数据库，图中用虚线表示。
• 一种解决方法是使用DNS 将请求分散到服务器农场中的各个服务器。当来自一个针对Web URL 的DNS 请求时， DNS 服务器会返回一个服务器IP 地址的循环列表。每个客户端尝试一个IP 地址，通常取列表上的第一个。DNS 方法是CDN 的核心。
• 其他的解决方案是基于前端的方式，由前端把入境请求分散到服务器农场的服务器池中。当客户端使用单一目标IP 地址联系服务器农场时，就会发生这种情况。前端通常是一个链路层交换机或IP 路由器，也就是说，是一台处理帧或包的设备。所有的解决方案都基于该台设备（或服务器），该设备窥视网络层、传输层或应用层的头并以非标准的方式使用偷看来的信息。Web 请求和响应都通过TCP 连接运载。为了正常工作，前端设备必须把一个请求的所有数据包分发到同一台服务器。
• 一个简单的设计是前端将所有的入境请求广播给所有的服务器。每个服务器按照事先的约定回答一小部分请求。例如， 16 台服务器可能查看请求的源IP 地址，只有源IP 地址最后4 位与它们配置的选择器相匹配时才回答该请求，其他的包都将被丢弃。虽然这样浪费了入境带宽，但往往响应包远远长于请求包，所以它并不像听起来的那样低效。
• 在更通用的设计中，前端可以检查数据包的IP 、TCP 和HTTP 头，并任意地将它们映射到服务器。这种映射称为负载均衡（ load balancing ）策略，因为目标是为了均衡服务器的工作负载。这种策略可能很简单，也可能很复杂。一种简单策略是依次使用服务器，一个接着一个，或者以一种循环的形式分配服务器的使用。采用这种方法时，前端必须记住每个请求与服务器对应的映射关系，才能确保作为同一请求组成部分的随后包被发送到同一台服务器。此外，为了使网站比单个服务器更可靠，前端应注意到当某个服务器失败后，必须立即停止向它们发送请求。
• 与NAT 类似，这种通用设计违反了分层协议的最基本原则：每一层都必须使用自己的头来实行控制目的。在这种情况下的前端设备是一个交换机或路由器，但它根据传输层或更高层次的信息采取相应的行动。这样的盒子称为中间件盒（ middlebox ），因为它把自己插入到一条网络路径的中间，而根据协议栈的规定它是没有这项业务的。在这种情况下，前端设备最好考虑作为服务器农场内部的一部分，将所有层次都终结到应用层（因此可以使用所有这些层的头信息〉。然而，与NAT 一样，实际上这种设计非常有用。查看TCP 头的原因是它可以比只用IP 信息来处理负载均衡工作得更好。例如，一个IP 地址可能代表了整个公司，因而可能会产生许多请求。只有通过查看TCP 或更高层次的信息，才能将这些请求映射到不同的服务器。
• 查看HTTP 头的原因稍微有些不同。许多Web 交互访问和更新数据库，比如当消费者要查看她的最近购买记录时。处理该请求的服务器将查询后台数据库。将来自同一个用户的后续请求直接指向同一台服务器是有用的，因为该服务器己经缓存了有关该用户的信息。引起这种情况发生的最简单方法就是使用Web Cookie （或其他区分用户的信息），而且检查HTTP 头来找到这些Cookie。尽管我们己经描述了Web 站点的设计，同样可以用其他类型的服务器来构建服务器农场。一个例子是UDP 之上的流媒体服务器。此时仅仅需要改变的是前端，它必须能均衡这些请求的负载（将使用与Web 请求不同的协议头字段）。

Web 代理

• 用HTTP 发送Web 请求和响应。浏览器使用各种头字段和规则来确定一个缓存的网页副本是否还很新鲜。高速缓存因为缩短了响应时间并减少了网络负载，因此能提高性能。如果浏览器可以自己判断缓存的页面是新鲜的，那么页面可以立即从缓存中提取出来，根本不会产生网络流量。然而，即使浏览器必须询问服务器来确认该页面是否依然新鲜，响应时间也缩短，网络负载也得到降低，特别对大页面尤为如此，因为只需要发送一个小的消息。
• 然而，浏览器可以做的最好事情是缓存用户以前访问过的所有网页。实际上，这种特性限制了浏览器缓存的有效性，因为大量的页面只被给定用户访问一次，而这些网页总是必须从服务器获取。使缓存更有效的策略之一是在多个用户之间共享缓存。通过这种方式，为一个用户获取的一个页面可以在另一个用户发出同样请求时返回给他。没有浏览器缓存，这两个用户都需要从服务器获取该页面。当然，这种共享不适用于加密的流量和不可缓存的页面（比如，当前股票的价格），因为前者需要认证，后者是由程序返回。特别是由程序创建的动态网页，仍处于不断增长的情况，因此缓存它是无效的。不过，也有大量的网页可被许多用户访问，而且无论哪个用户发出请求看到的都是同样内容（例如，图像）。
• Web 代理（ Web proxy ）是可以被多个用户共享的一个高速缓存。代理代表别人做某种行为，比如用户。有许多不同种类的代理。例如，一个ARP 代理代表一个在别处的用户（他不能自己回答）应答ARP 请求。Web 代理代表它的用户获取Web 请求。它通常提供缓存的Web 响应，而且因为它被多个用户共享，因此它有一个比所有用户浏览器都大得多的高速缓存。
• 当采用代理时，典型的设置是一个组织为它的所有用户运行一个Web 代理。该组织可能是一个公司或一个ISP 。组织和个人都可以通过加快用户的Web 请求，并减少带宽需求来获得收益。虽然独立于使用，定价对最终用户来说都是一样的，大多数公司和ISP 根据用户所使用的带宽来收费的。这种设置如图所示。为了使用代理，每个浏览器必须配置成向代理而不是页面的真实服务器发出页面请求。如果代理有相应的页面，它就立刻返回页面。如果它没有，它就从服务器获取页面，并将它添加到缓存以备将来使用，同时返回给请求该页面的客户。
• 除了向代理而不是真正服务器发送Web 请求外，客户还要用它的浏览器高速缓存来执行它们自己的缓存。只有在浏览器尝试以自己的高速缓存页面无法满足请求之后，才会咨询代理。也就是说，代理提供了一个第二级的缓存。
• 还可以加入进一步的代理来提供更多一级的缓存。每个代理（或浏览器）向其上行流代理发出请求。每个上行流代理为下行流代理（或浏览器〉缓存页面。因此，有可能一个公司内的浏览器使用一个公司代理，而公司代理再使用一个ISP 代理，该代理直接和Web 服务器联系。然而，一般来说，我们给出的单级代理缓存实际上也往往能获得大部分的潜在好处。相应存在的问题是流行的长尾效应。针对网站流量的研究表明，当用户数量达到一个小公司的规模〈比如， 100人）时，共享缓存特别有益。随着人数增长较大，共享缓存的好处变得边缘化，由于缺乏存储空间，不流行的得不到缓存。
• Web 代理还提供了额外的好处，这往往是决定部署它们的一个因素。好处之一是内容过滤。管理员可以配置代理过滤掉一些被列入黑名单的网站，或者把代理配置成其他过滤器，对发出的某些请求予以过滤。例如，许多系统管理员对员工在公司上班时间观看You Tube 视频会皱起眉头，因而会相应地设置它们的过滤器。用代理的另一个好处是隐私或匿名，代理作为盾牌向服务器隐匿了用户的身份。

3、内容分发网络

• 服务器农场和Web 代理有助于建立大型网站，并提高Web 性能，但对于构建一个真正流行的网站，在全球范围内提供内容服务，这些还不够。对于这些网站，需要不同的方法。内容分发网络（ CON, Content Delivery Network）彻底扭转了传统的Web 缓存想法。与客户在附近的缓存中寻找请求的页面副本不同， CON 为客户提供了这样的信息：在一组分布在不同地点的节点中哪个节点拥有所请求页面的副本，并且指示客户端使用附近的节点作为服务器。
• 图中给出了一个CON 网络中数据分发所遵循的路径例子。CON 的源服务器将一份内容副本分发到CON 中的其他节点。在这个例子中，这些节点分别位于悉尼、波士顿和阿姆斯特丹，图中用虚线表示。然而，客户端从就近的CON 节点获取页面，图中用实线表示。这样，在悉尼的客户获取的都是存储在悉尼的页面副本，他们不会从源服务器处获取页面，源服务器可能在欧洲。
• 使用树结构有3 个好处。首先，内容的分发具备可扩展性。随着越来越多的客户需要，可以使用更多的CON 节点。源服务器不会超载，因为它通过CON 节点树和许多客户交谈：而它自己不需要应答每个页面请求。其次，每个客户都享有不错的性能，因为他是从附近的服务器而不是一个遥远的服务器那里获取页面。这是因为建立连接所需要的往返时间较短，而往返时间越短TCP 慢启动得更快，而且较短的网络路径经过Internet 上拥塞区域的可能性较小。最后，放置在网络上的总负荷也保持在最低水平。如果CDN 节点都放置在恰当的位置，一个给定页面的流量应该恰好通过网络中各个部分一次。这点非常重要，最终总会有人要为网络带宽付费。
• 采用分发树的想法很直截了当。最简单的是如何组织客户使用这棵树。这种策略未能在实际中奏效，原因主要有3 个。第一个原因，网络中位于一个给定区域的客户可能属于不同的组织，所以他们可能会使用不同的Web 代理。回想一下，大量的客户端共享缓存所获得的利益有限，而且从安全方面的考虑出发，缓存机制通常不能跨组织共享。其次，可能存在多个CDN，但每个客户端只使用一个代理缓存。客户端应该选择哪个CDN 作为其代理呢？最后，也许所有问题中最实际的是客户端配置了Web 代理。他们可能会也可能不会再配置一个CDN 来受益于内容分发，而且对此CDN 能做的很少。
• 支持一棵分发树的另一种简单方法是使用镜像（ mirroring ）。在这种方法中，源服务器跟以前一样将内容复制给CDN 节点。不同网络区域中的CDN 节点称为镜像点（ mirror ）。源服务器上的网页包含了指向不同镜像点的显式链接，通常告诉用户这些镜像点的位置。这种设计可以让用户手动选择一个附近的镜像点来下载内容。镜像的典型应用是把一个大的软件包放在不同位置的镜像点上。镜像站点通常是完全静态的，而且选择的站点可以保持稳定数月或数年。它们是一种经受住考验的技术。然而，它们依靠用户做内容的分发，因为镜像点实际上是不同的Web 站点，即使它们被链接在一起。
• 第三种方法克服了前两种方法的困难，使用了DNS 技术，因而称为DNS 重定向（ DNS redirection ）。假设一个客户要获取URL 为http://com/page.html 的页面。为了提取页面，浏览器将使用DNS把 www.cdn.com 解析为一个IP 地址。DNS 查找过程以通常的方式进行。通过使用DNS 协议，浏览器了解到 cdn.com 域名服务器的IP 地址，然后与该域名服务器联系，请求它解析 www.cdn.com。 现在到了真正展示聪明才智的地方。该域名服务器同时作为CDN 节点运行。它不是为每个请求返回相同的IP 地址，而是根据发出请求的客户端IP地址返回不同的查询结果。答案将是最靠近客户端的CDN 节点的IP 地址。针对在悉尼客户 ，域名服务器将返回悉尼CDN 节点的IP 地址。
• 在域名解析后，悉尼的客户端将直接从悉尼CDN 节点获取页面。由于DNS 缓存，对相同“服务器”页面的进一步请求将直接从悉尼CDN 节点获取。整个步骤如图所示。
• 上述过程中的一个复杂问题是怎样才算找到最近的CDN 节点。在将客户端映射到某个CDN 节点时至少有两个因素需要考虑。一个因素是网络的距离。客户端应该有一条距离短、容量高的网络路径到达CDN 节点。这样情形下才能做到快速下载。CDN 使用一张它们以前计算的地图，把客户端的IP 地址转换成它的网络位置。选定的CDN 节点可能就在作为直线的最短距离上，也有可能不在最短距离上。重要的是，要综合考虑网络路径长度和途中的任何容量限制。第二个因素是CDN 节点的当前负载。如果CDN 节点己经超载，它们的传送反应就会缓慢，就像Web 服务器超载一样，我们应该首先避免使用这样的服务器。
• 将DNS 用作内容分发技术率先由Akamai 在1998 年提出的，那时Web 在早期快速增长的负载下不堪重负。CDN 节点必须放置在具有良好连通性的网络位置，最初这意味着在ISP 网络内部。对于ISP来说，在它们的网络中放置一个CDN 节点是有好处的，即CDN 节点能削减它们所需要的上游网络带宽量（必须付费），就像设置代理缓存一样。此外， CDN 节点能提高ISP 客户的响应性，使得ISP 在客户们的眼里变得很好。这些好处（对ISP 来说没有任何成本）使得安装一个CDN 节点对ISP 来说是简直不费吹灰之力。现在CDN 是一个有多家提供商的竞争产业。
• 多数企业没有建立它们自己的CDN，它们使用CDN 提供商的服务来实际传送它们的内容。当CDN 与Web 网站所有者的代表签署内容分发的合同后，网站所有者便向CDN 提供自己网站的内容。这个内容被推送到CDN 节点。此外，网站所有者可以重写链接到内容的任何网页。注意，这里不是链接到其网站上的内容页面，而是通过CDN 与内容链接的页面。为了说明这项方案是如何工作的，请考虑蓬松视频（ Fluffy Video ）网页的源代码，如图(a）所示。在预处理后，被转化为图(b），并且作为 www.fluffy.video.com/index.html 被放置在蓬松视频服务器。
• 当用户在他的浏览器上输入URL为 www.fluffy.video.com 时， DNS 返回蓬松视频自己网站的IP 地址，从而允许用户以正常的方式提取主页（ HTML ）。当用户点击该主页上的任何超链，浏览器会请求DNS查询 www.cdn.com。这次查询联系的是CDN 的DNS 服务器，它返回的是附近CDN 节点的IP 地址。然后浏览器给CDN 节点发送一个常规HTTP请求，例如/fluffyvideo/koalas.mpg 。该URL 标识了要返回的页面，因此CDN 节点可以区分它为之服务的不同公司的请求。最后，所请求的视频被返回，用户可以看到可爱的毛绒绒动物了。
• 把托管给CDN 的内容和内容所有者主管的入口页面分开，隐藏在这背后的策略是让CDN 移动大量数据的同时给内容所有者以控制权。大多数入口网页微小，只是些HTML文本。这些网页通常链接到大文件，比如视频和图像。正是这些大文件由CDN 来提供服务，即使CDN 的使用对用户完全透明。网站看起来都一样，但执行得更快。
• 站点们使用共享CDN 还有另一个优势。潮水汹涌般的需求称为闪群（ flash crowd ）。当发布最新产品、有一场时装秀和发生其他事件时，这种激增的访问需求就可能发生。由于大多数网站没有准备好处理大量激增的流量，其结果就是其中的许多网站当流量激增时立即崩溃掉。通过使用CDN，一个网站能拥有提供超大内容服务的访问能力。最大的CDN 有数以万计的服务器部署在世界各地的不同国家。由于只有少数网站在任何一个时间（定义的）将会遇到闪群，这些网站可以使用CDN 的能力来处理负载，直到风暴过去。也就是说，CDN 可以迅速扩大网站的服务能力。
• 在我们例子中描给的CDN 节点通常是一堆集群的机器。DNS 的重定向体现在两个层次：一个将客户映射到一个附近的网络位置，另一个将负载遍布在该位置上的节点。可靠性和性能都需要关注的两个方面。为了能够将一个客户从集群中一台机器转移到另一台机器，第二个层次上的DNS 应答具有很短的TTL，因此客户端很快就能重复解析。最后，虽然我们将注意力集中在分发静态对象，比如图像和视频， CDN 同样可支持动态页面创建、流媒体以及其他更多的内容。