浅谈网络 | 应用层之HTTPDNS协议与CDN

HTTPDNS

传统 DNS 存在的问题

• 域名缓存问题
  DNS 本地缓存虽然提高了查询速度，但如果缓存没有及时更新，可能会导致用户访问过时的地址或页面。例如，用户可能被导向已搬迁的饭店或过时的页面。另一方面，本地缓存还可能导致负载均衡失效，返回的地址可能不在用户最近的地理位置，从而增加响应时间。

• 域名转发问题
  在某些情况下，DNS 请求被转发到其他运营商的 DNS 服务器，这会导致访问速度变慢。例如，如果 A 运营商将请求转发给 B 运营商，权威 DNS 服务器会返回 B 运营商的地址，导致跨运营商访问，从而降低速度。

• 出口 NAT 问题
  出口 NAT 会改变请求的源 IP 地址，使得权威 DNS 服务器无法正确判断请求来源的运营商。由于误判，可能会导致跨运营商访问，从而影响访问速度和稳定性。

• 域名更新问题
  不同地区和运营商的 DNS 服务器可能会有不同的缓存策略。某些 DNS 服务器可能忽略 TTL 限制，导致域名解析更新较慢。这在需要快速切换 DNS 记录的情况下，可能会导致用户访问异常。

• 解析延迟问题
  DNS 查询需要递归遍历多个 DNS 服务器才能获得最终解析结果，这可能导致一定的延迟，甚至超时，影响用户体验。

HTTPDNS 的工作模式

在传统的 DNS 解析中，虽然我们通常依赖 DNS 服务器来获取域名对应的 IP 地址，但它也存在一些问题，如性能瓶颈、安全隐患以及对网络环境的依赖等。如果遇到无法访问 DNS 服务器或出现 DNS 污染等问题，是否就只能退回直接使用 IP 地址呢？显然，直接用 IP 地址并不是一个可行的解决方案。于是，HTTPDNS应运而生。

HTTPDNS的工作原理是：它绕过传统的 DNS 解析方式，利用基于 HTTP 协议的自建 DNS 服务器集群进行域名解析。这个服务器集群通常分布在多个地点、多个运营商网络上，能够根据客户端的请求动态返回最优的解析结果。简而言之，HTTPDNS 通过 HTTP 协议提供 DNS 服务，而不是依赖传统的 DNS 查询机制。

与传统的 DNS 解析不同，HTTPDNS 自建并管理域名解析服务，相当于每个服务商或应用根据自己的需求，搭建一个专属的 “地址簿”，不再依赖统一的 DNS 解析服务。由于默认的域名解析依然是走 DNS 的，因此，客户端必须绕过默认的 DNS 解析路径才能使用 HTTPDNS。这通常意味着，使用 HTTPDNS 的应用需要在客户端嵌入专门的 SDK 来支持 HTTP 协议的域名解析。

使用 HTTPDNS 就像是从依赖传统的 DNS “导游” 转向自主的自由行，客户端通过自己的 HTTPDNS 服务器直接查询域名信息，避免了传统 DNS 可能带来的瓶颈和不稳定性，提升了效率和灵活性。这样，用户就能实现更高效、更安全的上网体验，不必依赖那些有时不太专业的 DNS 服务。

HTTPDNS 的工作模式:

HTTPDNS 的工作方式通过客户端 SDK 动态请求服务器获取 HTTPDNS 服务器的 IP 列表，并将其缓存到本地。随着域名解析的不断进行，SDK 会在本地缓存 DNS 查询结果，优化后续请求的速度和稳定性。

当手机应用需要访问某个地址时，首先会检查本地是否有缓存。如果缓存存在，则直接返回解析结果。与传统 DNS 的缓存不同，这里的缓存是由手机应用自己管理的，而不是由运营商统一控制。缓存的更新和过期机制可以根据客户端与服务器的协商来决定，灵活性更高。

如果本地缓存没有目标域名的解析结果，客户端会请求 HTTPDNS 服务器。在请求时，SDK 会从本地缓存的 HTTPDNS 服务器 IP 列表中选择一个，发送 HTTP 请求获取目标域名的 IP 列表。请求格式类似于：

curl http://106.2.xxx.xxx/d?dn=c.m.163.com

返回结果通常包括如下信息：

{
  "dns": [{
    "host": "c.m.163.com",
    "ips": ["223.252.199.12"],
    "ttl": 300,
    "http2": 0
  }],
  "client": {
    "ip": "106.2.81.50",
    "line": 269692944
  }
}

通过 HTTP 通信，HTTPDNS 服务器能够准确获得客户端所在的运营商及其网络信息，从而实现精确的全局负载均衡。即使 HTTPDNS 服务器不可用，客户端也可以回退到传统的 LocalDNS 进行解析，保证即便在网络不稳定的情况下仍能提供服务。

HTTPDNS 主要解决了两个关键问题：

1. 解析速度与更新速度的平衡
   如何在保证较低延迟的同时，又能根据网络环境的变化及时更新解析结果？
   解决方案：通过智能缓存和 TTL（生存时间）机制，客户端可以平衡解析速度与更新频率。

2. 智能调度问题
   如何根据客户端的实际情况（如运营商、地理位置等）进行智能调度，确保解析结果的高效与准确？
   解决方案：通过基于 HTTP 协议的请求方式，HTTPDNS 服务器能够根据客户端的 IP 地址、运营商线路等信息进行精准的负载均衡和调度，确保返回最合适的解析结果。

HTTPDNS 的缓存设计

解析 DNS 过程复杂，通信次数多，对解析速度造成很大影响。为了加快解析，因而有了缓存，但这也带来了缓存更新速度不及时的问题。最关键的是，这两个方面都掌握在本地 DNS 服务器手中，客户端无法控制，只能干着急。

HTTPDNS 则将解析速度和更新速度完全掌控在自己手中。首先，解析过程无需通过本地 DNS 服务递归调用，而是通过一个 HTTP 请求直接完成，且当需要实时更新时，可以立刻生效；其次，为了提高解析速度，客户端也会维护本地缓存，缓存的过期时间和更新时间都可以自主控制。

缓存设计策略

HTTPDNS 的缓存设计策略类似于常见的应用架构中的缓存设计模式，分为客户端、缓存和数据源三层：

• 客户端：手机应用端。
• 缓存：本地 DNS 缓存。
• 数据源：HTTPDNS 服务器。

所有缓存模式都面临缓存过期、更新、不一致的问题，解决思路也相似。

缓存实现机制

1. 缓存持久化：

   • 例如，DNS 缓存在内存中，也可以持久化到存储上，这样当 APP 重启时，可以迅速从存储中加载之前常访问网站的解析结果，无需每次都重新解析。类似于 Redis 作为内存缓存，也提供持久化能力，确保在重启或主备切换时数据不会丢失。

2. 缓存过期与更新：

   • SDK 中的缓存会严格按照过期时间来更新，如果缓存未命中或已过期，且客户端不允许使用过期记录，则会发起一次解析，确保获取最新数据。
     

同步与异步更新

1. 同步更新：

   • 同步更新的优点是实时性好，但缺点是当多个请求同时发现缓存过期时，可能会多次请求 HTTPDNS，这会造成不必要的负担。
   • 同步更新对应的是应用架构中的 Cache-Aside 机制，即先读取缓存，若缓存未命中则查询数据库，并将结果写入缓存。

   

2. 异步更新：

   • 异步更新的优点在于能将多个请求的过期情况合并为一次 HTTPDNS 请求，减少 HTTPDNS 负载。同时，可以在缓存即将过期时提前加载数据，防止过期后再更新，这种机制称为 预加载。
   • 异步更新的缺点是当客户端请求过期数据时，如果允许使用过期数据，就会有一定风险。如果过期数据仍然可用，则没问题；如果不可用，则会失败，必须等到缓存更新后才能重新请求。
   • 异步更新对应的是应用架构中的 Refresh-Ahead 机制，即仅访问缓存，缓存过期后定期刷新。
     

应用实例

在著名的缓存系统 Guava Cache 中，存在一个 RefreshAfterWrite 机制，对于并发访问未命中的缓存，可以通过确保只有一个请求触发回源来减少压力。在应用缓存架构中，也常常使用数据预热或预加载机制来优化缓存管理。

HTTPDNS 的调度设计

由于客户端嵌入了 SDK，HTTPDNS 能够直接获取客户端的地理位置、运营商信息、网络环境等，避免了本地 DNS 解析过程中可能出现的缓存、转发和 NAT 等问题，从而保证了客户端的位置信息准确无误，能够获得权威的 DNS 解析结果。

客户端信息收集

客户端能够知道手机所在的国家、运营商、所在省份，甚至是具体的城市。通过这些信息，HTTPDNS 服务器可以根据地理位置及运营商等信息选择最优的服务节点。
综合调度与负载均衡

在有多个可用节点的情况下，HTTPDNS 不仅考虑地理位置，还会根据以下因素综合调度：

• 错误率
• 请求时间
• 服务器压力
• 网络状况

当某个节点宕机或其性能下降时，HTTPDNS 可以迅速切换到性能更好的节点，以确保稳定性和高效性。

网络请求质量数据采集

为了实现智能调度，客户端 SDK 会收集网络请求的质量数据，如错误率、请求响应时间等。这些数据会被发送到统计后台进行分析和聚合，以评估不同 IP 地址的服务质量。

服务质量优先级与调度策略

在服务端，应用可以通过 HTTPDNS 的管理接口来配置不同服务的质量优先级和权重。HTTPDNS 服务器会根据这些策略，结合客户端的地理位置和线路状况，计算出最优的 IP 排序。优先访问时延低、质量高的 IP 地址。

缓存与调度一致性

HTTPDNS 返回的解析结果会被缓存在客户端，然而，为了避免缓存导致调度失真，客户端会根据不同的网络环境（如不同的移动运营商或 Wi-Fi SSID）维度化缓存。不同的运营商或 Wi-Fi 网络下，客户端解析出的 DNS 结果可能不同，因此通过区分网络环境进行缓存，能够保持更精确的调度结果。

CDN

上文，我们看到了网站的一般访问模式。

当一个用户想访问一个网站时，首先输入该网站的域名，DNS 会将这个域名解析为对应的地址，然后用户请求该地址并返回网页。这就像你要购买商品时，首先需要查找商店位置，然后去商店挑选商品，最后带着商品回家。

是否可以优化这个过程？

例如，当你在电商网站下单购买商品时，这个商品一定要从电商总部的中心仓库发出吗？过去，通常每一单都由总部的中心仓库进行配送，可能会导致配送速度较慢，用户需要等待较长时间才能收到商品。但是，电商平台逐渐优化了物流系统，在全国范围内建立了多个仓库，而不仅仅依赖总部仓库。

电商网站根据统计分析，知道哪些商品在北京、上海、广州、深圳、杭州等大城市的销售量较高，因此会在这些城市的仓库中提前备货。客户下单时，就能从距离最近的仓库发货，从而缩短配送时间，提升用户体验。

当然，生鲜类商品由于保质期问题，电商网站需要进一步优化库存管理，避免库存积压。

CDN 的分发系统的架构

网站访问优化：就近访问

这一优化思路也同样适用于网站访问。全球有许多数据中心，无论你身处何地，几乎都可以找到靠近你的数据中心。那么，是否可以在这些数据中心部署缓存集群来存储常用数据，让用户能够从就近的数据中心获取信息呢？

答案是肯定的。这些分布在各地的数据中心节点，通常被称为边缘节点。由于边缘节点的规模较小，它们只能缓存部分常用数据，可能存在缓存不命中的情况。为了提高缓存命中率，系统会通过更大的区域节点来存储更多数据。

如果在区域节点仍然无法命中，系统会进一步向更大的中心节点请求数据，直到最终访问源站。

这种架构便是CDN-内容分发网络的工作原理。CDN 的缓存系统分为多个层级，层层递进，旨在减少对源站的访问，并提高数据访问速度和可靠性。

以电商物流为例

就像电商物流系统在不同区域设立多个仓库一样，CDN 通过多个节点层级优化用户访问路径，以最优的方式将数据交付给用户。每一层级的节点都承担不同的缓存任务，从边缘节点到中心节点，最终优化了整个数据获取的过程。

客户端与边缘节点访问

传统 DNS 解析流程

在没有 CDN 的情况下，客户端在浏览器中输入 www.web.com 这个域名时，流程如下：

1. 本地 DNS 解析：客户端向本地 DNS 服务器发送请求。

   • 如果本地 DNS 服务器有缓存，会直接返回网站的 IP 地址。
   • 如果没有缓存，DNS 服务器会递归查询到该网站的权威 DNS 服务器，权威 DNS 服务器会返回网站的 IP 地址。

2. 客户端访问：客户端接收到 IP 地址后，直接访问该 IP 地址，从而访问到网站。

CDN 介入后的变化

有了 CDN 后，流程发生了变化：

1. DNS 解析被重定向：在 web.com 的权威 DNS 服务器上，会设置一个 CNAME 别名，指向 CDN 的域名 www.web.cdn.com。这意味着用户访问的是 CDN 而非直接访问源站。

2. 本地 DNS 解析 CNAME：本地 DNS 服务器会收到 www.web.cdn.com 的 CNAME 记录，接着会解析这个新域名，去请求 CDN 的权威 DNS 服务器。

3. CDN 权威 DNS 服务器：CDN 的权威 DNS 服务器会返回指向 CDN 全局负载均衡器的 CNAME 记录。此时，DNS 请求已经指向了 CDN 的全局负载均衡器。

4. 全局负载均衡：本地 DNS 服务器会进一步请求 CDN 的全局负载均衡器，后者根据以下几个因素来选择最佳的边缘节点：

   • 用户 IP 地址：判断哪个服务器离用户最近。
   • 运营商信息：选择同一运营商的服务器，以减少跨运营商的网络延迟。
   • 内容名称：根据 URL 中携带的内容名称，判断哪些边缘服务器缓存了该内容。
   • 负载情况：查询各个服务器的负载情况，选择负载较低的服务器。

5. 返回缓存服务器 IP 地址：全局负载均衡器根据综合分析返回一个合适的边缘缓存服务器的 IP 地址。

6. 客户端访问边缘节点：本地 DNS 服务器缓存该 IP 地址，并将其返回给客户端，客户端访问该边缘节点。

7. 缓存响应用户请求：边缘缓存服务器检查是否包含用户请求的资源。如果缓存命中，直接响应用户请求；如果没有命中，边缘缓存服务器会向上级缓存请求数据，直到源服务器拉取数据。
   

CDN 缓存内容类型与优化策略

CDN 通过缓存和负载均衡机制有效提高了访问速度和用户体验。每个 CDN 节点都会根据内容的缓存策略和当前的网络状况，决定是否直接响应客户端的请求，或者向上级服务器请求数据。整个过程通过 DNS 和负载均衡的智能调度，使得客户端能够快速、稳定地获取所需内容。

CDN 能够缓存的内容有很多种，具体分为静态内容、流媒体、动态内容等。每种类型的内容都有不同的缓存策略和优化方法。

静态内容的缓存

• 长保质期的日用品：类似于电商中的静态页面、图片等，这些内容变化较少，因此适合长时间缓存。

  • 接入层缓存：在数据中心的接入层，我们希望通过外层缓存将大部分静态资源的请求拦截在边缘节点，以减少源站的负担。
  • CDN 缓存：CDN 将静态资源缓存到距离用户更近的数据中心，进一步优化了访问性能，降低了时延。

流媒体内容的缓存

流媒体内容的缓存具有一些特殊性，尤其是在视频和音频的处理上，CDN 采用了不同的策略。

• 流媒体协议支持：CDN 支持 RTMP 等流媒体协议，这通常涉及到 CDN 作为代理从上一级缓存读取内容并转发给用户。

  • 预先缓存与推送：流媒体数据量大，且具有连续性，因此 CDN 采用预缓存和主动推送策略。热点流媒体内容会预先推送到边缘节点，以减少回源带来的压力。

• 视频处理：CDN 不仅缓存视频内容，还可以对视频进行预处理，例如：

  • 码流转换：将视频转换为适应不同网络带宽的多个码率，以满足不同用户的需求。
  • 视频分片：对视频进行分片存储，降低存储压力并允许客户端根据网络状况选择不同质量的码流播放。

防盗链机制

流媒体内容的版权保护至关重要，特别是在视频网站和媒体平台中。为了防止内容被非法盗用，CDN 提供了以下防盗链策略：

• Referer 头检查：通过检查 HTTP 请求中的 Referer 字段，服务器可以判断请求是否来自合法来源。如果不合法，阻止访问或跳转到其他页面。

  • 时间戳防盗链：通过加密字符串和时间戳生成一个签名，生成带有签名的下载链接。该签名用于验证请求的合法性，防止盗链。

  • 签名验证：CDN 服务端会验证请求中的签名和时间戳，确保请求未过期且签名有效，只有合法请求才能获取内容。

动态内容的缓存策略

与静态内容不同，动态内容（如电商网站的实时数据、库存等）更难缓存。针对这种情况，CDN 提供了两种解决方案：

1. 生鲜超市模式（边缘计算）

   • 动态数据的计算和存储被分散到边缘节点，这样可以减少对源站的依赖。定期从源数据同步内容到边缘节点，并在边缘进行处理。
   • 类似生鲜食品的烹饪模式，边缘节点不仅存储数据，还能进行实时计算，提供动态响应。

2. 冷链运输模式（路径优化）

   • 数据依旧在源站生成，但通过 CDN 网络优化数据传输路径。通过选择离源站和用户都较近的边缘节点，确保数据传输更高效。

   • TCP 调优：在 CDN 网络中，可以通过调整 TCP 流量控制和拥塞控制参数，提高数据传输效率，减少数据丢包，保证更高的吞吐量。

   • 多请求复用连接：CDN 可以通过复用 TCP 连接，减少建立新连接的开销，从而降低延迟和服务器压力。

   • 数据压缩：通过压缩传输数据，提高传输效率，降低带宽消耗。

原文地址：https://blog.csdn.net/weixin_48711696/article/details/144253040

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！