DNS 和 CDN

DNS (Domain Name System)

域名服务器分为

• Root Name Servers 根域名服务器：保存顶级域名服务器的 ip 地址。
  • 当用户请求 google.com 时，返回保存 .com 域 IP 地址的顶级域 （TLD） 服务器列表。
• Top-level Domain (TLD) Name Servers 顶级域名服务器: 保存权威域名服务器的 ip 地址。
  • 当用户请求 google.com 时，返回保存了 google.com 的权威域名服务器列表。
• Authoritative Domain Name Servers 权威域名服务器：保存真正提供 Web 或应用程序服务器服务器 ip 地址。
  • 当用户请求 google.com 时，返回保存谷歌服务器的 ip 地址。

有 13 个逻辑根名称服务器（命名为字母 A 到 M），其中许多实例遍布全球。这些服务器由 12 个不同的组织管理。

迭代查询和递归查询

从本地/ISP 服务器的角度来看, 迭代查询和递归查询：

通常，首选迭代查询以减少 DNS 基础结构上的查询负载。

迭代查询

DNS 缓存

DNS 作为分布式系统

• 高可扩展性: 13 根级服务器的大约 1,000 个复制实例战略性地分布在世界各地，以处理用户查询。如上面的 DNS 层次结构树所示，不同的服务处理树的不同部分。
• 可靠:
  • 缓存: 缓存在浏览器、操作系统和本地名称服务器中的缓存，使某些 DNS 服务器暂时关闭，也可以提供缓存记录。
  • 服务器复制：分布在全球各地的每个逻辑服务器的副本，以低延迟处理用户请求。
  • 协议：UDP 虽不如 TCP 可靠，但更快。
• 一致性：因为高性能和缓存牺牲了强一致性。DNS 提供最终一致性，并延迟更新复制服务器上的记录。通常，通过 Internet 更新 DNS 服务器上的记录可能需要几秒钟到三天的时间。在不同 DNS 群集之间传播信息所需的时间取决于 DNS 基础结构、更新的大小以及要更新的 DNS 树的哪一部分。为了缓解此问题，每个缓存的记录都有一个称为生存时间 （TTL） 的过期时间。

为了保持高可用性，TTL 值应很小。这是因为如果任何服务器或集群发生故障，组织可以立即更新资源记录。用户仅在 TTL 未过期时才会遇到不可用的情况。但是，如果 TTL 很大，组织将更新其资源记录，而用户将继续 ping 很久以前就会崩溃的过时服务器。渴望高可用性的公司将 TTL 值保持在 120 秒以下。因此，即使在发生故障的情况下，最长停机时间也只有几分钟。

相关命令

1. nslookup www.google.com
   
2. dig www.google.com
   

DNS 解析器的 IP 地址：
Linux 中：/etc/resolv.conf

资源记录

CDN (Content Delivery Network)

功能要求

1. Retrieve 检索：CDN 应该能够从源站检索内容。
2. Request 请求：根据用户的请求, 从代理服务器进行内容传送。
3. Delivery 推送：源站能够将内容发送到 CDN 代理服务器。
4. Update 更新：在 CDN 中运行脚本，CDN 应该能够更新 PoP 中对等 CDN 代理服务器中的内容。
5. Delete 删除：根据内容类型（静态或动态），应该可以在一段时间后从 CDN 服务器中删除缓存的条目。

组件

1. 源站将 CDN 中缓存的所有对象的 URI 命名空间委托提供给请求路由系统。

2. 源站将内容发布到负责进行数据分发的分发系统。

3. 分发系统在代理服务器之间分发内容, 并向请求路由系统提供反馈。此反馈有助于优化为请求客户端选择最近的代理服务器, 包含有关哪些内容缓存在哪个代理服务器上,以将流量路由到相关代理服务器。

4. 客户端（如浏览器、智能手机和其他设备）向路由系统请求合适的(最近的)代理服务器。

5. 请求路由系统返回适当代理服务器的IP地址。

6. 出于安全原因，客户端请求通过清理服务器进行路由。(将良好流量与恶意流量分开，并防止众所周知的攻击，如DDoS。通常仅在检测到攻击时使用。在这种情况坏流量将被清理，好流量才路由到目标。)

7. 清理服务器将良好的流量转发到边缘代理服务器。

8. 边缘代理服务器服务于客户端请求，并定期将统计信息转发到管理系统:

   • 对特定内容发出的请求数
   • 服务器正在处理的负载

9. 管理系统更新源站并向路由系统发送有关内容的统计和详细信息的反馈。

   但是，如果内容在代理服务器中不可用，则请求将路由到源站。如果在边缘代理服务器中找不到内容，也可能有代理服务器的层次结构。对于这种情况，请求将转发到父代理服务器。

CDN 中的内容缓存策略-PUSH/PULL

PUSH CDN

分发由源站主动发起，将内容从源站或者其他资源库推送到用户边缘的各个 CDN 缓存节点上。

推送 CDN 适用于静态内容交付，其中源站决定使用 CDN 向用户交付哪些内容。根据内容的受欢迎程度，将内容推送到不同位置的代理服务器。

譬如双十一之前一段时间内，淘宝、京东等各个网络商城就会开始把未来活动中所需用到的资源推送到 CDN 缓存节点中，特别常用的资源甚至会直接缓存到你的手机 APP 的存储空间或者浏览器的localStorage上。

在 Web 内容不经常更改并长时间缓存在边缘代理服务器中的情况下使用推送 CDN。

PULL CDN

当某个资源首次被用户请求的时候，CDN 缓存节点发现自己没有该资源，就会实时从源站中获取，代理服务器将文件保留指定的时间，如果不再请求它们，则将其从缓存中删除，以平衡容量和成本。因此，被动回源的首次访问通常是比较慢的。

被动回源的优点是可以做到完全的双向透明，不需要源站在程序上做任何的配合。

在 Web 内容频繁更改的地方，如 NewsFeed, 更适合使用拉取 CDN。

动态内容缓存优化

为了减少源服务器和代理服务器之间的通信以及代理服务器的存储要求，采用压缩技术也很有用。例如，Cloudflare 使用 Railgun 来压缩动态内容。
另一种流行的动态数据压缩方法是 Edge Side Includes (ESI) 标记语言。通常，一小部分网页会在特定时间内发生变化。这意味着如果每次小更改，都重新获取完整的网页，会包含大量冗余数据。为了解决这种性能损失，ESI 指定了内容更改的位置，以便可以缓存网页内容的其余部分。它在 CDN 边缘服务器或客户端浏览器上组装动态内容。 ESI 尚未由万维网联盟 (W3C) 标准化，但许多 CDN 提供商都在使用它。

多层 CND

同时将数据分发到所有 CDN 代理服务器 会给源服务器带来沉重的负担。

数据分发的树状结构允许我们通过向树中添加更多服务器节点来扩展系统以增加用户数。同时，也减轻了源服务器进行数据分发的负担。

查到最近的代理服务器以获得数据

DNS 重定向

$ dig icyfenix.cn

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> icyfenix.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60630
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;icyfenix.cn.                   IN      A

;; ANSWER SECTION:
icyfenix.cn.            600     IN      CNAME   icyfenix.cn.cdn.dnsv1.com.
icyfenix.cn.cdn.dnsv1.com. 599  IN      CNAME   4yi4q4z6.dispatch.spcdntip.com.
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	101.71.72.192      #浙江宁波市
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	113.200.16.234     #陕西省榆林市
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	116.95.25.196      #内蒙古自治区呼和浩特市
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	116.178.66.65      #新疆维吾尔自治区乌鲁木齐市
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	118.212.234.144
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	211.91.160.228
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	211.97.73.224
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	218.11.8.232
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	221.204.166.70
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	14.204.74.140
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	43.242.166.88
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	59.80.39.110
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	59.83.204.12
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	59.83.204.14
4yi4q4z6.dispatch.spcdntip.com.	60 IN	A	59.83.218.235

;; Query time: 74 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Apr 11 22:33:56 CST 2020
;; MSG SIZE  rcvd: 152

能解析该 CNAME 的权威服务器只有 CDN 服务商所架设的权威 DNS，这个 DNS 服务将根据一定的均衡策略和参数，如拓扑结构、容量、时延等，在全国各地能提供服务的 CDN 缓存节点中挑选一个最适合的，将它的 IP 代替源站的 IP 地址，返回给本地 DNS。

有两个重要因素与查找离用户最近的代理服务器有关：

1. 用户和代理服务器之间的网络距离至关重要: 具有最高容量（带宽）的最短网络路径是离相关用户最近的代理服务器。
   • 网络路径的长度。
   • 网络路径上的容量（带宽）限制。
2. 请求负载是指代理服务器在任何时间点处理的负载。如果一组代理服务器过载，则请求路由系统应将请求转发到负载较小的位置。此操作可以平衡代理服务器负载，从而减少响应延迟。

其它重定向方法

1. AnyCast 任播：位于多个位置的所有边缘服务器共享相同的单个 IP 地址。它采用边界网关协议 （BGP） 根据 Internet 的自然网络流路由客户端。
2. Client multiplexing 客户端多路复用 ： 向客户端发送候选服务器列表。然后，客户端从列表中选择一个服务器以将请求发送到。这种方法效率低下，因为客户端缺乏整体信息来为他们的请求选择最合适的服务器。
3. HTTP redirection# HTTP 重定向 ： 源服务器使用 HTTP 协议进行响应，以通过内容的 URL 重定向用户。

CDN 中的内容一致性

代理服务器中的数据应与源服务器中的数据保持一致。如果代理服务器与源服务器不一致，则始终存在用户访问过时数据的风险。根据推送或拉取模型的不同，可以使用不同的一致性机制来保证数据的一致性。

定时轮询

适用于拉取模型，代理服务器定期向源服务器请求更新数据。当内容不经常更改时，轮询方法会消耗不必要的带宽。定期轮询间隔称为 刷新时间 time-to-refresh （TTR） 。

Time-to-live (TTL)

由于 TTR，代理服务器可能会无用地请求源服务器以获取更新的数据。在 TTL 方法中，每个对象都有一个由源服务器分配给它的 TTL 属性。TTL 定义内容的过期时间。过期后，代理服务器会检查源服务器的更新。如果数据发生更改，它将从源服务器获取更新的数据，然后使用更新的数据响应用户的请求。

Leases 租赁

源服务器向使用此技术对发送到代理服务器的数据授予租约。代理服务器必须在租约到期后发送一条消息，请求续订租约。
租用方法有助于减少代理和源服务器之间交换的消息数。此外，可以根据在代理服务器上观察到的负载动态优化租约持续时间。这种技术称为自适应租约。

CDN 代理服务器放置的位置

互联网交换点 IXP 是 IP 网络的常见基础，允许参与的互联网服务提供商 （ISP） 交换发往其各自网络的数据。

IXP的主要目的是允许 ISP 网络通过交换器直接互连，而不是通过一个或多个第三方 ISP 网络。直接互连的主要优点是成本、延迟和带宽。
IXP 的主要替代方案是私有对等互连: ISP 直接将其网络相互连接。

IXP 通常位于预先存在与多个不同网络（即数据中心）连接的地方，并运营物理基础设施（交换机）以连接其参与者。从组织上讲，大多数 IXP 都是其组成参与网络（即参与该 IXP 的一组 ISP）的独立非营利性协会。

图片来源

CDN 代理服务器必须放置在连接良好的网络位置：

• On-premises ：表示一个较小的数据中心，可以放置在主要 IXP 附近。
• Off-premises ：表示将 CDN 代理服务器放置在 ISP 的网络中。

如今，将电影的大部分数据保存在 ISP 内部的 CDN 基础设施中可能是可行的。尽管如此，对于像YouTube这样的服务来说，数据是如此之大且不断扩展，以至于决定我们应该在用户附近放置什么内容是具有挑战性的。

Google 使用拆分 TCP 法：在 IXP 级基础设施到其主要数据中心之间建立了————有巨大 TCP 窗口的持久连接：

• 持久连接：这些连接不会频繁地建立和关闭，从而避免了建立 TCP 连接的初始三次握手和到很远的主机的慢启动阶段（如果客户端想去 Google 的主要数据中心）。
• 巨大的 TCP 窗口：TCP 窗口大小决定了在等待确认之前可以发送的数据量。使用巨大的 TCP 窗口可以提高数据传输效率，减少等待时间，从而提高传输速度。

客户端到 IXP 的往返延迟通常非常低，客户端的 TCP 请求在 IXP 级别的基础结构处终止，然后在已建立的低延迟 TCP 连接上转发。这样做可以大大减少客户端感知到的延迟。

注意：Akamai 和 Netflix 推广了将其 CDN 代理服务器保留在客户端 ISP 内部的想法。对于 Akamai 的许多客户来说，内容只是一个网络跳跃之遥。另一方面，谷歌也拥有其私有 CDN 基础设施，但更依赖 IXP 附近的服务器。造成这种情况的一个原因可能是大量的数据和变化模式。

通过将 CDN 代理服务器放置在他们的网络中，ISP 可以获得什么好处？

• CDN 节点减少了 ISP 需要和付费的外部带宽量。（可以直接从本地 CDN 节点获取内容，减少了这些内容在 ISP 之间转发的跨网络中转流量）
• ISP 与代理服务器提供商定义的 SLA 可能会在经济上使 ISP 受益（???）。
• CDN 节点提高了 ISP 客户的响应能力，从而使 ISP 的客户更满意。这使它们比没有 CDN 节点的 ISP 更具竞争优势。
• 使内容更接近用户可以减少互联网核心上的数据。（减少转发）

作为公共服务的 CDN

大多数公司不构建自己的 CDN。相反，他们使用 CDN 提供商的服务，例如 Akamai、Cloudflare、Fastly 等，以提供他们的内容。同样，像 AWS 这样的参与者使任何人都可以使用全球 CDN 设施。

这些公司与 CDN 服务提供商签订合同，并将其内容交付给 CDN，从而允许 CDN 将内容分发给最终用户。公共 CDN 会给内容提供商带来以下问题：

• 如果公共 CDN 关闭，内容提供商将无能为力。

• 如果公共 CDN 在一些网站流量来自的地区或国家/地区没有任何代理服务器，那么这些特定客户就不走运了。在这种情况下，内容提供商必须从其他 CDN 提供商处购买 CDN 服务或部署和使用自己的私有 CDN。

• CDN 提供商的某些域或 IP 地址可能在某些国家/地区被阻止或限制，因为它们可能提供在这些国家/地区被禁止的内容。

专有 CDN

尽管专门的 CDN 在首次设置时成本很高，但成本最终会随着时间的推移而降低。从本质上讲，这是一个购买与构建的决策。

Netflix 的 Open Connect Appliance （OCA） 是专门用于视频传输的 CDN 的一个例子。

图片来源: Netflix Open Connect Overview

Netflix 的 OCA 服务器不存储用户数据(例如观看历史,数字版权管理DRM信息,成员数据)，相反，它们执行以下任务：

• 将其状态（运行状况、学习的路由和缓存内容的详细信息）报告给驻留在 AWS （Amazon Web Services） 中的 Open Connect 控制平面。
• 提供用户请求的文件内容。

Netflix IX 部署

        如果 OCA 托管在 IXP，Netflix 保留 OCA 的所有权，并负责支付自己的费用，例如电力消耗、托管费、交叉连接费和其他相关费用。Netflix 已在全球超过 52 个 IXP 中安装了 OCA，可实现与任何 ISP 的连接。

Netflix ISP 部署

        如果 OCA 直接安装在 ISP 网络中。虽然 Netflix 免费提供服务器硬件，但 ISP 负责提供空间、电力和连接。
        Netflix 于 2012 年推出了 Open Connect。从那时起，Netflix 已花费超过 10 亿美元开发和分发 8,000 多台 Open Connect 设备 （OCA）。该服务开始与ISP合作，致力于免费分发OCA。到目前为止，已有 1,000 多家 ISP 购买并安装了 OCA，这使他们能够在 2021 年之前节省 12.5 亿美元。

来源：Open Connect WikiPedia

Netflix 为什么要构建其 CDN

随着 Netflix 越来越受欢迎，它决定构建和管理自己的 CDN，原因如下：

• 随着流媒体视频量的增加，使用 CDN 服务的费用也在增加。

• 视频流媒体是Netflix的主要业务和主要收入来源。因此，保护平台上所有视频的数据至关重要。Netflix 的 OCA 以更好的方式管理潜在的数据泄露风险。

• 为了向客户提供最佳的流媒体交付，Netflix 需要最大限度地控制用户的视频播放器、用户之间的网络和 Netflix 服务器(???)。

• Netflix 的 OCA 可以使用自定义 HTTP 模块和 TCP 连接算法来快速检测网络问题并解决其 CDN 网络中的任何问题。

• Netflix希望长期保留热门内容。在使用公共 CDN 运行时，这并不完全可能，因为维护和维护它会产生高昂的成本。