高性能利器：CDN我建议你好好学一下！

硬核干货分享，欢迎关注【Java补习课】成长的路上，我们一起前行 ! 《高可用系列文章》 已收录在专栏，欢迎关注！

CDN 概述

CDN 全称 Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定

CDN 的工作原理 就是将源站的资源缓存CDN各个节点上，当请求命中了某个节点的资源缓存时，立即返回客户端，避免每个请求的资源都通过源站获取，避免网络拥塞、缓解源站压力，保证用户访问资源的速度和体验。

举一个生活中的例子，我们在某东上购买商品，快递能做到当日送达，其根本原理是通过在全国各地建设本地仓库。当用户购买商品时，通过智能仓配模式，为消费者选择就近仓库发货，从而缩短物流配送时间。

而商品库存的分配，流程可以参考下图，从 工厂（源站） -> 地域仓库(二级缓存) -> 本地仓库 (一级缓存)

内容分发网络 就像前面提到的 智能仓配网络 一样，解决了因分布、带宽、服务器性能带来的访问延迟问题，适用于站点加速、点播、直播等场景。使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度和成功率。

CDN的诞生

CDN 诞生于二十多年前，为解决内容源服务器和传输骨干网络压力过大的问题，在 1995 年，麻省理工学院教授，互联网发明者之一 Tom Leighton 带领着研究生 Danny Lewin 和其他几位顶级研究人员一起尝试用数学问题解决网络拥堵问题。

他们使用数学算法，处理内容的动态路由安排，并最终解决了困扰 Internet 使用者的难题。后来，史隆管理学院的 MBA 学生 Jonathan Seelig 加入了 Leighton 的队伍中，从那以后他们开始实施自己的商业计划，最终于 1998 年 8 月 20 日正式成立公司，命名为 Akamai。Akamai 公司通过智能化的互联网分发，结束了 “World Wide Wait” 的尴尬局面。

同年 1998 年，中国第一家 CDN 公司 ChinaCache 成立

CDN工作原理

接入CDN

在接入CDN前，当我们访问某个域名,直接拿到第一个真实服务器的IP地址，整个流程如下（图有点简陋）

当我们需要加速网站时，通过向运营商注册自己加速域名，源站域名，然后进入到自己域名的DNS配置信息，将 A 记录修改成 CNAME 记录即可。阿里云加速申请参考如下：

CDN访问过程

• 1、用户访问图片内容，先经过 本地DNS 解析，如果 LDNS 命中，直接返回给用户。
• 2、LDNS MISS，转发 授权DNS 查询
• 3、返回域名 CNAME picwebws.pstatp.com.wsglb0.com. 对应IP地址(实际就是DNS调度系统的ip地址)
• 4、域名解析请求发送至DNS调度系统，DNS调度系统为请求分配最佳节点IP地址。
• 5、返回的解析IP地址
• 6、用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容传送到用户终端。

图：华为云全站加速示意图

CDN解决了什么问题

骨干网压力过大

Tom Leighton在 1995 年， 带领团队尝试用数学问题解决网络拥堵问题，从而解决骨干网络压力过大的问题。由于上网冲浪 的少年越来越多，造成骨干网的核心节点流量吞吐不足以支撑互联网用户的增长，通过CDN可以避免用户流量流经骨干网。

骨干网是一个全球性的局域网,一级互联网服务提供商（ISP）将其高速光纤网络连接在一起，形成互联网的骨干网，实现在不同地理区域之间高效地传输流量。

1、局域网

局域网(Local Area Network，LAN)是指在某一区域内由多台计算机互联成的计算机组，比如：在大学时期，晚上12点后断网了，我们仍然能够通过路由器开黑打CS，魔兽。那就是基于局域网互联，实现资料共享与信息之间的通信。

2、骨干网

这里引用一下中国电信全网架构，骨干网可以理解成是一个全国性的局域网，通过核心节点的流量互通，实现全网网络的互通。这也是为什么我们称为互联网 的原因。

北京、上海、广州，是ChinaNet的超级核心。除了超级核心之外，ChinaNet还有天津、西安、南京、杭州、武汉、成都等普通核心。

三公里之 middlemile

通常网络访问中会有"三公里"路程

• 第一公里为:源站到ISP接入点
• 第二公里为:源站ISP接入点到访问用户的ISP接入点
• 第三公里(最后一公里)为:用户ISP接入点到用户客户端

CDN网络层主要用来加速第二公里(middlemile),

在 CDN 的基础架构中，通常使用两级 server 做加速：

• L1（下层）：距离用户（或俗称网民）越近越好，通常用于缓存那些可缓存的静态数据，称之为 lastmile（最后一公里）。
• L2（上层）：距离源站越近越好，称之为 firstmile（第一公里），当 L1 无法命中缓存，或内容不可缓存时，请求会通过 L1 透传给 L2，若 L2 仍然没有命中缓存或内容不可缓存，则会继续透传给 L2 的 upstream（有可能是源站，也有可能是 L3），同时 L2 还可以做流量、请求数的量级收敛，减少回源量（如果可缓存），降低源站压力。
• L1 和 L2 之间的部分，是 CDN 的 ”内部网络“，称之为 middlemile（中间一公里）。

CDN的组成

全局负载均衡系统 GLB（Global Load Balance）

• 当用户访问加入CDN服务的网站时，域名解析请求将最终由 “智能调度DNS”负责处理。
• 它通过一组预先定义好的策略，将当时最接近用户的节点地址提供给用户，使用户可以得到快速的服务。
• 同时它需要与分布在各地的CDN节点保持通信，跟踪各节点的健康状态、容量等信息，确保将用户的请求分配到就近可用的节点上.

缓存服务器

缓存服务器主要的功能就是缓存热点数据，数据类型包括：静态资源（html,js,css等），多媒体资源（img,mp3,mp4等），以及动态数据（边缘渲染）等。

众所周知耳熟能详的与 CDN 有关的开源软件有：

• Squid
• Varnish
• Nginx
• OpenResty
• ATS
• HAProxy

具体对比可参考：https://blog.csdn.net/joeyon1985/article/details/46573281

CDN的分层架构

源站

源站指发布内容的原始站点。添加、删除和更改网站的文件，都是在源站上进行的;另外缓存服务器所抓取的对象也全部来自于源站。

CDN 调度策略

DNS 调度

基于请求端 local DNS 的出口 IP 归属地以及运营商的 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路由调度

基于 BGP AnyCast 路由策略，只提供极少的对外 IP，路由策略可以很快的调整。

目前 AWS CloudFront、CloudFlare 都使用了这种方式，在路由层面进行调度。

这种方式可以很好地抵御 DDOS 攻击，降低网络拥塞。

当然这种方式的成本和方案设计都比较复杂，所以国内的 CDN 目前还都是用 UniCast 的方式。

一些概念

CDN运作原理

本地缓存的数据，通过key-value 的形式，将url 和本地缓存进行映射,存储结构与 Map相似，采用 hash+链表形式进行缓存。

CDN命中率

衡量我们CDN服务质量的一个核心标准，当用户访问的资源恰好在缓存系统里，可以直接返回给用户，说明CDN命中；如果CDN缓存中，没有命中资源，那么会触发回源动作。

CDN回源

当CDN本地缓存没有命中时，触发回源动作,

• 一级缓存 访问二级缓存是否有相关数据，如果有，返回一级缓存。
• 二级缓存 Miss，触发 二级缓存 回源请求，请求源站对应数据。获取结果后，缓存到本地缓存，返回数据到一级缓存。
• 一级缓存 获取数据，缓存本地后，返回给用户。

CDN预热数据

上面说的访问模式，都是基于Pull模式，由用户决策哪部分热点数据会最终存留在CDN缓存中；对于大促场景，我们往往需要预先将活动相关资源预热 到 边缘节点（L1）,避免大促开启后，大量用户访问，造成源站压力过大。这时候采用的是 Push模式。

CDN的特点总结

1、资源访问加速: 本地Cache加速，提高了企业站点（尤其含有大量图片和静态页面站点）的访问速度，并大大提高以上性质站点的稳定性

2、消除运营商间网络互联的瓶颈问题: 镜像服务消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量。

3、远程加速: 远程访问用户根据DNS负载均衡技术 智能自动选择Cache服务器，选择最快的Cache服务器，加快远程访问的速度

4、带宽优化: 自动生成服务器的远程Mirror（镜像）cache服务器，远程用户访问时从cache服务器上读取数据，减少远程访问的带宽、分担网络流量、减轻原站点WEB服务器负载等功能。

5、集群抗攻击: 广泛分布的CDN节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种D.D.o.S攻击对网站的影响，同时保证较好的服务质量 。

点关注，不迷路

好了各位，以上就是这篇文章的全部内容了，我后面会每周都更新几篇高质量的大厂面试和常用技术栈相关的文章。感谢大伙能看到这里，如果这个文章写得还不错， 求三连！！！ 感谢各位的支持和认可，我们下篇文章见！

我是 九灵 ,有需要交流的童鞋可以关注公众号：Java 补习课！ 如果本篇博客有任何错误，请批评指教，不胜感激 ！