CDN架构详解:优化网站性能的技术基础与最佳实践

8月 11, 202436 mins read

CDN(内容分发网络)的架构,探索其如何提升网站性能和用户体验。本文涵盖CDN的核心组件、工作原理和部署最佳实践,帮助开发者和网站管理员有效优化网站速度和稳定性。

前言  

CDN(全称 Content Delivery Network),经常被我们使用在前端资源处理中,例如:图片、视频、音频、html等静态资源。当遇到加载性能问题的时候,需要提效,会优先想到使用CDN进行加速资源 处理。这篇主要带我们去了解一下CDN的原理,在了解原理前,带着下面几个问题去思考:

  1. 为什么要有网络加速?

  2. 什么是CDN?

  3. CDN是如何实现网络加速?

  4. CDN有那些安全隐患?

为什么有网络加速  

主要目的:  提升网络性能、提供更好的用户体验。避免用户丢失,达成业务目标。所以在了解为什么需要网络加速之前,需要先了解为什么网络会堵塞。用户在访问到真是的资源之前,需要经过运营商,如下图所示:

 

112.png

如图所示原因有以下几个导致了网络堵塞:

  • 不同地域用户通过 运营商,会跨越大海,飘洋过海的找到源服务

  • 互联网从逻辑上看是一张大网,但实际上是由许多小网络组成的,这其中就有小网络“互连互通”的问题,典型的就是各个电信运营商的网络。

  • 这些小网络内部的沟通很顺畅,但网络之间却只有很少的联通点。如果你在 A 网络,而网 站在 C 网络,那么就必须“**跨网”传输,和成千上万的其他用户一起去“挤”连接点 的“独木桥”[网络拥堵]**。而带宽终究是有限的,能抢到多少只能看你的运气。

  • 网络中还存在许多的路由器、网关,数据每经过一个节点,都要停顿一下,在二层、 三层解析转发,这也会消耗一定的时间,带来延迟。

  • 最终结果就是,如果仅用现有的 HTTP 传输方式,大多数网站都会访问速度缓慢、用户体 验糟糕。

  • 放到全球来看,物理距离非常大,你在北京,访问旧金山的网站,要跨越半个地球,地理位置距离远、运营商网络、路由转发的影响就会成倍增加

什么是CDN  

CDN (全称 Content Delivery Network),即内容分发网络。CDN是以全球分布式代理服务器网络(a globally distributed network of proxy servers)来实现的。通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络"边缘"。 通过部署CDN边缘服务,缩短访问路径,提升资源加载速度。如下图所示:

什么是CDN

目的: 使用户可就近取得所需内容,解决Internet网络拥挤的状况,提高用户访问网站的响应速度。

优势:

  1. CDN节点解决了跨运营商和跨地域访问的问题,访问延时大大降低;

  2. 大部分请求在CDN边缘节点完成,CDN起到了分流作用,减轻了源站的负载。

本质上讲CDN解决两个问题:

  1. 高延迟。如果您的服务部署在美国,那么亚洲地区的延迟将较高,这是由于与提供数据中心的物理距离造成的。

  2. 数据密集型应用程序:

    1. 它们传输大量数据。在较长距离上,由于路径中存在多个互联网服务提供商,可能会出现问题

    2. 其中一些可能具有较小的链路、拥塞、数据包丢失和其他问题。

    3. 距离越长,路径上的服务提供商就越多,其中一个出现问题的几率就越高

核心技术:

  • CDN构建在现有网络基础之上的智能虚拟网络,依靠部署在各地的边缘服务器,通过中心平台的负载均衡、内容分发、调度等功能模块,使用户就近获取所需内容,降低网络拥塞,提高用户访问响应速度和命中率

  • CDN 的关键技术主要有内容存储和分发技术

    • 简单来讲,CDN就是根据用户位置分配最近的资源,于是,用户在上网的时候不用直接访问源站,

    • 而是访问离他“最近的”一个 CDN 节点(也叫做“边缘节点”、edge node),其实就是缓存了源站内容的代理服务器

  • 简单理解 CDN是一组地理分布的代理服务器。代理服务器是客户端和源服务器之间的中间服务器。

CDN访问过程:

 

CDN访问过程:
  1. 用户输入访问的域名,操作系统向 LocalDns 查询域名的ip地址.

  2. LocalDns向 ROOT DNS 查询域名的授权服务器(这里假设LocalDns缓存过期)

  3. ROOT DNS将域名授权dns记录回应给 LocalDns

  4. LocalDns得到域名的授权dns记录后,继续向域名授权dns查询域名的ip地址

  5. 域名授权dns 查询域名记录后(一般是CNAME),回应给 LocalDns

  6. LocalDns 得到域名记录后,向智能调度DNS查询域名的ip地址

  7. 智能调度DNS 根据一定的算法和策略(比如静态拓扑,容量等),将最适合的CDN节点ip地址回应给 LocalDns

  8. LocalDns 将得到的域名ip地址,回应给 用户端

  9. 用户得到域名ip地址后,访问站点服务器

  10. CDN节点服务器应答请求,将内容返回给客户端.(缓存服务器一方面在本地进行保存,以备以后使用,二方面把获取的数据返回给客户端,完成数据服务过程)络加速

CDN系统架构  

 

CDN系统架构

工作流程

  1. 我们从源服务器为特定DNS域或特定DNS名称提供内容委托开始。它告诉CDN所有到特定URL的请求将被代理。

  2. 源服务器将内容发布到分发系统,负责在一组边缘代理服务器上分发内容。通常使用“推送”和“拉取”模型,通常两者都会被使用。

  3. 分发系统将合格的内容发送给代理服务器,同时跟踪哪些内容在哪个代理服务器上被缓存。它还了解哪些内容是静态的和动态的,需要刷新的数据的TTL、内容租约等等。

  4. 客户端向路由系统请求合适的代理服务器IP,或使用Anycast IP来路由到最近的位置。

  5. 客户端请求通过Scrubber服务器。

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

  7. 边缘代理服务器为客户端请求提供服务,并定期将其健康信息转发给数据控制系统。

  8. 如果代理中不可用的内容,则会路由到源服务器

各系统简单介绍

  • 路由系统

    • 将客户端引导到最近或最优的CDN位置。

    • 为了有效地执行这个功能,该组件接收来自各种系统的输入,以了解请求来自何处、内容位于何处、数据中心的繁忙程度等等。

    • 有两种最流行的路由系统:带有负载均衡的DNS和Anycast

  • Scrubber服务器

    • 用于分离良好的流量和恶意流量,以防范DDoS攻击。

    • Scrubber服务器通常仅在检测到攻击时使用。

    • 如今,Scrubber服务器非常复杂,允许客户端推送非常细粒度的防火墙规则,并在实时中在所有数据中心应用这些规则。

  • 代理或边缘代理服务器

    • 为终端用户提供内容。它们通常会将内容缓存,并从RAM中提供快速检索。

  • 内容分发系统

    • 负责将内容分发到不同CDN设施中的所有边缘代理服务器

    • 通常使用树状分发模型。

  • 源服务器

    • 托管在CDN上分发的原始内容的用户基础设施。

  • 数据控制系统

    • 用于观察资源使用情况和统计信息。

    • 该组件测量指标,如延迟、停机时间、数据包丢失、服务器负载等等。

    • 然后将其反馈给路由系统以进行最佳路由。

路由转发  

 

路由转发
 

内容分发  

主动推送

  • 主动推送就是服务器源站将内容分发到内容节点

  • 用户访问时就可以直接访问到节点上的副本

被动推送

  • 被动访问就是在用户访问时,向镜像服务器发送请求,如果镜像服务器上有内容,就直接返回给用户,如果没有,就到服务器源站获取后在返回给用户

117.png

 

 

调度  

CDN 中的重中之重,流量接入、流量牵引、选择合适的 CDN 节点服务器等工作,都是在调度环节完成的。CDN 调度是指通过各种策略将客户端请求调度到合理的目标机房。以达到成本、质量(可用性、平均速度)的最佳控制。

调度形式有以下几种:

  1. DNS 调度

  2. HTTP DNS 调度

  3. 302 调度

  4. 路由调度(Anycast)

DNS调度  

基于 local DNS 的出口 IP 归属地以及运营商的 DNS 调度。DNS 调度的问题:

  • DNS 缓存时间在 TTL 过期前是不会刷新的, 这样会导致节点异常的时候自动调度延时很大,会直接影响线上业务访问。

  • 大量的 local DNS 不支持 EDNS 协议,拿不到客户的真实IP,CDN 绝大多数时候只能通过local DNS IP来做决策,经常会出现跨区域调度的情况。

主域名最后是一个 CNAME 地址,最后又会再解析这个 CNAME 得到最后的结果。NS 记录 显示了这个域名的权威 DNS,一般由云厂商提供 。DNS 调度的问题:

  • DNS 缓存时间在 TTL 过期前是不会刷新的, 这样会导致节点异常的时候自动调度延时很大,会直接影响线上业务访问

  • 大量的 local DNS 不支持 EDNS 协议,拿不到客户的真实IP,CDN 绝大多数时候只能通过local DNS ip来做决策,经常会出现跨区域调度的情况。

HTTP DNS 调度  

客户端请求固定的 HTTP DNS 地址,根据返回获取解析结果。可以提高解析的准确性(不像DNS调度,只能通过local DNS IP来做决策),能很好的避免劫持等问题。当然这种模式也有一些问题,例如客户端每次加载URL都可能产生一次HTTP DNS查询,这就对性能和网络接入要求很高。

302 调度  

基于客户端 IP 和 302 调度集群进行实时的流量调度。我们来看一个例子:

  1. 访问 URL 链接后,此时请求到了调度群集上,我们能拿到的客户端信息有 客户端的出口IP(绝大多情况下是相同的),接下来算法和基于 DNS 的调度可以是一样的,只是判断依据由 local DNS 出口 ip 变成了客户端的出口IP。

  2. 浏览器收到302回应,跟随 Location 中的 URL,继续发起 http 请求,这次请求的目标 IP 是CDN 边缘节点,CDN节点会响应实际的文件内容。

302 调度的优势:

  • 实时调度,因为没有 local DNS 缓存的,适合 CDN 的削峰处理,对于成本控制意义重大;

  • 准确性高,直接获取客户端出口 IP 进行调度。

302 调度的劣势:

  • 每次都要跳转,对于延时敏感的业务不友好。一般只适用于大文件

路由调度(Anycast)  

基于 BGP AnyCast 路由策略,只提供极少的对外 IP,路由策略可以很快的调整。目前 AWS CloudFront、CloudFlare 都使用了这种方式,在路由层面进行调度。这种方式可以很好地抵御 DDOS 攻击,降低网络拥塞。当然这种方式的成本和方案设计都比较复杂,所以国内的 CDN 目前还都是用 UniCast 的方式。

总结  

通过我们了解CDN架构,可以方便我们更好的使用CDN,定位CDN相关的问题。CDN针对静态资源或GET类请求做到更好的支持。CDN的核心架构主要看调度系统如何运作。如果大家需要深入了解,CDN系统架构各模块的详细逻辑以及存储介质硬件部署相关的内容,可以通过其他文章去深入了解。

参考https://mp.weixin.qq.com/s/GOxaryftUxQUTNKCW0CR6Q

Image NewsLetter
Icon primary
Newsletter

私たちのニュースレターを購読する

ボタンをクリックすることで、私たちの利用規約に同意したことになります