CDN

Posted on Edited on In Views:

CDN 全称 Content Distribution Network，即内容分发网络。CDN 管理分布在多个地理位置上的服务器，在它的服务器中存储各种类型的 Web 内容（包括文档、图片、音频和视频等）的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的 CDN 位置。

CDN 可以是专用 CDN（private CDN），即它由内容提供商自己所拥有；例如，谷歌的 CDN 分发 YouTube 视频和其他类型的内容。也可以是第三方 CDN（third-party CDN），它代表多个内容提供商分发内容；Akamai、Limelight 和 Cloudflare CDN 都运行第三方 CDN。

相比于使用 CDN，建立单一的大规模数据中心存在以下三个问题：

  • 如果客户远离数据中心，服务器到客户的分组将跨越许多通信链路并很可能通过许多 ISP，其中某些 ISP 可能位于不同的大洲。如果这些链路之一提供的吞吐量小于内容消耗速率，端到端吞吐量也将小于该消耗速率，给用户带来恼人的停滞时延。出现这种事件的可能性随着端到端的路径中链路数量的增加而增加。
  • 流行的内容很可能经过相同的通信链路发送许多次。这不仅浪费了网络带宽，内容提供商自己也将为向因特网反复发送 相同 的字节而向其 ISP 运营商（连接到数据中心）支付费用。
  • 单个数据中心代表一个单点故障，如果数据中心或其通向因特网的链路崩溃，它将不能够分发 任何 内容了。

CDN 通常采用两种不同的服务器安置原则：

  • 深入：该原则是通过在遍及全球的接入 ISP 中部署服务器集群来深入到 ISP 的接入网中。由 Akamai 首创。其目标是靠近端用户，通过减少端用户和 CDN 集群之间（内容从这里收到）链路和路由器的数量，从而改善了用户感受的时延和吞吐量。因为这种高度分布式设计，维护和管理集群的任务成为挑战。
  • 邀请做客：该原则是通过在少量（例如 10 个）关键位置建造大集群来 邀请到 ISP 做客。该原则由 Limelight 和许多其他 CDN 公司所采用。不是将集群放在接入 ISP 中，这些 CDN 通常将它们的集群放置在因特网交换点（IXP）。与深入设计原则相比，邀请做客设计通常产生较低的维护和管理开销，可能以对端用户的较高时延和较低吞吐量为代价。

一旦 CDN 的集群准备就绪，它就可以跨集群复制内容。CDN 可能不希望将每个内容的副本放置在每个集群中，因为某些内容很少访问或仅在某些国家中流行。事实上，许多 CDN 没有将内容推入它们的集群，而是使用一种简单的拉策略：如果客户向一个未存储该内容的集群请求某内容，则该集群检索该内容（从某中心仓库或者从另一个集群），向客户传输内容时的同时在本地存储一个副本。类似于 Web 缓存器，当某集群存储器变满时，它删除不经常请求的内容。

当用户主机中的一个浏览器指令检索一个特定的视频（由 URL 标识）时，CDN 必须截获该请求，以便能够：

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

大多数 CDN 利用 DNS 来截获和重定向请求，其步骤如下：

  1. 用户访问目标网页；
  2. 当用户点击链接时，该用户主机发送了一个对于目标 URL 的 DNS 请求；
  3. 用户的本地 DNS 服务器（LDNS）将该 DNS 请求中继到 目标服务器的权威 DNS 服务器，目标服务器的权威 DNS 服务器 并不返回一个 IP 地址，而是向 LDNS 返回一个 第三方 CDN 的主机名；
  4. 从这时起，DNS 请求进入了 第三方 CDN 的专用 DNS 基础设施。用户的 LDNS 则发送第二个请求，此时是对 第三方 CDN 的主机名 的 DNS 请求，第三方 CDN 的 DNS 系统 最终向 LDNS 返回 第三方 CDN 服务器 的 IP 地址。所以正是在这里，在 第三方 CDN 的 DNS 系统 中，指定了 CDN 服务器，客户将能够从这台服务器接收到它的内容；
  5. LDNS 向用户主机转发 第三方 CDN 节点 的 IP 地址；
  6. 一旦客户收到 第三方 CDN 节点 的 IP 地址，它与具有该 IP 地址的服务器创建了一条直接的 TCP 连接，并且发出对该网页的 HTTP GET 请求。

任何 CDN 部署，其核心是集群选择策略（cluster selection strategy），即动态地将客户定向到 CDN 中的某个服务器集群或数据中心的机制。如上所述，经过客户的 DNS 查找，CDN 得知了该客户的 LDNS 服务器的 IP 地址。在得知该 IP 地址之后，CDN 需要基于该 IP 地址选择一个适当的集群。CDN 一般采用专用的集群选择策略。

一种简单的策略是指派客户到地理上最为临近（geographically closest）的集群。使用商用地理位置数据库，每个 LDNS IP 地址都映射到一个地理位置。当从一个特殊的 LDNS 接收到一个 DNS 请求时，CDN 选择地理上最为接近的集群，即离 LDNS 最少几千米远的集群。这样的解决方案对于众多用户来说能够工作得相当好。但对于某些客户，该解决方案可能执行的效果差，因为就网络路径的长度或跳数而言，地理最临近的集群可能并不是最近的集群。此外，一种所有基于 DNS 的方法都内在具有的问题是，某些端用户配置使用位于远地的 LDNS，在这种情况下，LDNS 位置可能远离客户的位置。此外，这种简单的策略忽略了时延和可用带宽随因特网路径时间而变化，总是为特定的客户指派相同的集群。

为了基于 当前 流量条件为客户决定最好的集群，CDN 能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量（real-time measurement）。例如，CDN 能够让它的每个集群周期性地向位于全世界的所有 LDNS 发送探测分组（例如，ping 报文或 DNS 请求）。这种方法的一个缺点是许多 LDNS 被配置为不会响应这些探测。