CDN内容分发网络

Posted 2022-12-08 S4061222

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了CDN内容分发网络相关的知识，希望对你有一定的参考价值。

一、简介

1. CDN 是什么?

CDN 是 Content Delivery Network 的简称，即 "内容分发网络” 的意思。一般我们所说的 CDN 加速，一般是指网站加速或者用户下载资源加速。

CDN 基本思路就是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。

CDN加速有什么用？

——对访客用户的好处

对于用户来说，如果一个网站开启了CDN，用户访问速度或者下载速度会比没有开启时更快。一般目前只要好一些的网站，都会开启CDN功能，主要在于提升用户体验。

——对网站的好处

对于网站或者站长来自，开启了CDN不仅可以提升网站打开速度，提升用户体验。更重要的是开启CDN可以减少黑客工具和服务器宽带压力。

开启CDN后的网站，不同地区用户访问会是不同的服务器，而网站的真实服务器（源服务器）一般只有CDN节点回去访问获取，全国各地的用户访问的CDN节点服务器，并不直接访问源服务器，这样就可以介绍网站服务器宽带资源，降低服务器压力。

由于有CDN节点中间阻挡防护，可以更好的保护原服务器的安全。也就是说CDN为用户源站服务器在安全云中提供了一个替身，无论是渗透还是DDoS攻击，攻击的目标都将是CDN节点替身，进而保护了网站源站。

2. CDN 的工作原理

首先CDN是为了改善互联网的服务质量的。

假设百度网站只有一台服务器，如果该服务器也在北京，那么通常来说访问比较快，在北京的用户访问起来比在拉萨的用户访问起来要快。那么这个问题的根本原因是网络传输是依赖于网线的，网线越长，传输时间肯定就越久。

对于这个问题的解决，其实思路很简单，就是百度在全国各地都部署一模一样的服务器就行了，专业一点叫冗余。

虽然听起来很简单，但是实施起来还是比较麻烦的，服务器上的资源分为两种：静态资源与动态资源。

静态资源：这种资源通常是很少变动的，比如图片，视频，css，javascript等等

动态资源：这种资源不同用户不同时刻访问通常是不一样的，比如ftl，jsp等等。

（1）如果要在全国各地都部署服务器，每个服务器上都有相同的动态资源，那么就需要配置相应的数据库，因为动态资源所记录的信息通常会存储在数据库中，那么这就涉及到了数据同步等等问题。这会导致成本很高，这种做法专业一点其实就是集群，而目前来说集群架构最多是三到五中心，不是说全国多地集群不可能，主要是成本太高。

（2）成本比较低的方式就是在每个服务器上只部署静态资源，静态资源通常不涉及到数据库，所以成本也比较低，而且也能提高用户的访问速度。

现在如果要比较CDN系统，我们可以考虑两点：

CDN系统中存储静态资源服务器的性能以及网速怎么样。
CDN系统中全国甚至全球范围内服务器节点的数量以及部署情况。

如果静态资源的服务器节点很多，能够让每个用户在访问这些静态资源时都不用“跑很远的路程”才能获取到，那么自然这是CDN系统的优点。

有需求就有提供服务的人，所以有很多CDN供应商，比如阿里，腾讯等等都有自己的CDN服务。只要你自己的系统接入了这些CDN供应商提供的CDN服务，把自己的静态资源传给CDN服务，那么这些静态资源将自动的分布到全世界各地去。

用户在访问静态资源时通常是通过域名来访问的，域名会被解析成某一个IP地址，DNS系统怎么在做域名解析时，怎么解析出来一个离用户最近的一个IP地址。

普通的DNS系统是做不到的，需要一个特殊的DNS服务器，这个特殊DNS需要知道：

用户当前所在位置；
还需要知道用户现在访问的这个域名对应哪些IP地址，以及这个IP地址分别在哪。

对于第一个问题好解决，直接从用户请求里提取出用户的ip地址，比如这个ip地址被解析为北京电信、上海移动等等。

第二个问题由谁来解决，考虑CDN，CDN提供商知道公司在哪些地方部署了机器以及它们的IP地址，所以CDN提供商会提供这个特殊的DNS服务器，我们叫做
CDN专用DNS服务器。

这样的话，只要用户在使用某个域名访问静态资源时，如果用户直接配置自己电脑的DNS地址为CDN专用DNS服务器。那么自然解决了问题，但是我们不能要求世界上所有的用户都去修改自己电脑的DNS
地址。所以这个时候就要利用DNS中的CNAME了。

当我们使用域名访问某一个网站时，实际上就是将请求包（以Http请求为例）通过网络传输给某台服务器，比如访问“www.baidu.com”时：

首先解析出该域名所对应的IP地址(DNS域名解析)
域名解析, 解析域名分为两种：
将一个域名解析为一个IP地址; 将一个域名解析为另外一个域名

然后将Http请求包通过网络路由到IP地址所对应的服务器
我们通常说“服务器的IP地址”，这其实不太准确，IP地址是和网卡绑定的，一个服务器可以有多个网卡，也就是可能有多个IP地址。

在域名服务商购买了一个域名之后，需要去映射一个IP地址，可以用Map来表示这个关系：域名：IP。
同时也可以给某个域名取一个别名，比如“www.baidu.com”取一个别名“test.baidu.com”，这种关系也可以用Map来表示：域名：别名。这里的别名专业一点叫做CNAME。
而域名解析，实际上就是解析出指定域名所对应的IP地址，或者该域名的一个CNAME。
而域名解析是由DNS系统来负责的，DNS服务接受外部请求，从请求里提取域名，

如果这个域名对应的是IP地址，则返回这个IP地址;
如果这个域名对应的是CNAME，则继续查找CNAME域名的IP地址，然后将该地址返回给请求发送者。

请求发送者拿到IP地址之后，完成真正的请求调用。

没有CNAME的情况：

有CNAME的情况：

注： 在有CNAME的情况下，CNAME实际上在域名解析的过程中承担了中间人（或者说代理）的角色，这是CDN实现的关键。

用户使用某个域名来访问静态资源时（这个域名在阿里CDN服务中叫做“加速域名”），比如这个域名为“image.baidu.com”，它对应一个CNAME，叫做“cdn.ali.com”，那么普通 DNS服务器（区别CDN专用DNS服务器）在解析“image.baidu.com”时，会先解析成“cdn.ali.com”，普通DNS服务器发现该域名对应的也是一个DNS服务器，那么会将域名解析工作转交给该DNS服务器，该DNS服务器就是CDN专用DNS服务器。CDN专用DNS服务器对“cdn.ali.com”进行解析，然后依据服务器上记录的所有CDN服务器地址信息，选出一个离用户最近的一个CDN服务器地址，并返回给用户，用户即可访问离自己最近的一台CDN服务器了。

3. CDN组成

每个CDN节点由两部分组成：负载均衡设备和高速缓存服务器。

负载均衡设备负责每个节点中各个Cache的负载均衡，保证节点的工作效率；同时，负载均衡设备还负责收集节点与周围环境的信息，保持与全局负载DNS的通信，实现整个系统的负载均衡。CDN的管理系统是整个系统能够正常运转的保证。它不仅能对系统中的各个子系统和设备进行实时监控，对各种故障产生相应的告警，还可以实时监测到系统中总的流量和各节点的流量，并保存在系统的数据库中，使网管人员能够方便地进行进一步分析。通过完善的网管系统，用户可以对系统配置进行修改。

理论上，最简单的CDN网络有一个负责全局负载均衡的DNS和各节点一台Cache，即可运行。DNS支持根据用户源IP地址解析不同的IP，实现就近访问。为了保证高可用性等，需要监视各节点的流量、健康状况等。一个节点的单台Cache承载数量不够时，才需要多台Cache，多台Cache同时工作，才需要负载均衡器，使Cache群协同工作。

二、CDN 的部署

实验环境：三台虚拟机一台server1作为CDN服务的主机，其余两台server2、3为后端接收负载均衡的主机。

1.server1安装Varnish

2.编写 /etc/varnish/default.vcl 和 /etc/varnish/varnish.params 文件

[root@server1 varnish]# cd /etc/varnish/
[root@server1 varnish]# ls
default.vcl  secret  varnish.params
[root@server1 varnish]# vim default.vcl 
[root@server1 varnish]# vim varnish.params 
[root@server1 varnish]#  vim /etc/security/limits.conf

default.vcl文件中指定server2为CDN后端服务器

varnish.params 文件修改监听端口为80，当Varnish需要访问后端服务器时,就会访问自己的80端口

系统的内核参数也设置和varnish匹配，从而加快varnish缓存速度：
文件内核文件残参数查看sysctl -a|grep file

MEMLOCK=====存储锁定

3.重启服务，查看端口

httpd需要关闭，varnish使用的也是80端口

[root@server1 varnish]# systemctl stop httpd
[root@server1 varnish]# systemctl start varnish
[root@server1 varnish]# netstat -antlp

4.server2打开Apache

修改默认测试发布页的内容

5.测试

curl 172.25.28.1可以看到，实际上访问的是server2, 真机需要本地地址解析.

三、显示缓存是否命中

server2 和 server3 安装Apache
修改server2和server3的默认测试发布页的内容

编写 /etc/varnish/default.vcl 文件，重启服务

定义多个不同域名站点的后端服务器 ：
当访问www.westos.org 就会从web1（172.25.28.2）中取数据缓存到cdn中,
当访问bbs.westos.org 就会从web2（172.25.28.3）中取数据缓存到cdn中

当访问 www.westos.org 域名时从 web1 上取数据,访问 bbs.westos.org 域名时到 web2 取数据,访问其他页面报错。

req.：由客户发来的http请求相关
req.http.：拿到请求报文各个首部值
例如：req.http.Cookie 拿到请求报文中的Cookie首部的值

[root@server1 varnish]# vim /etc/varnish/default.vcl

vcl 4.0;
# Default backend definition. Set this to point to your content server.
% 配置两个后端服务器
backend web1 
    .host = "172.25.28.2";
    .port = "80";


backend web2 
    .host = "172.25.28.3";
    .port = "80";


%当访问 www.westos.org 域名时从 web1 上取数据,访问 bbs.westos.org 域名时到 web2 取数据,访问其他页面报错。
sub vcl_recv 
if (req.http.host ~ "^(www.)?westos.org") 
                set req.http.host = "www.westos.org";
                set req.backend_hint = web1;
                #return(pass); %让其缓存
                
                elseif (req.http.host ~ "^bbs.westos.org") 
                        set req.backend_hint = web2;
                        #return(pass);
                
                else 
                        return(synth(404,"Not in cache"));
                

    # Happens before we check if we have this in cache already.
    #
    # Typically you clean up the request here, removing cookies you don't need,
    # rewriting the request, etc.
    
 [root@server1 varnish]# systemctl restart varnish.service

缓存命中设定

resp.：由varnish响应给client的http响应报文
resp.http. ：响应报文的各个首部
例如：set resp.http.X-Cache = "HIT from " + server.hostname 给X-Cache首部赋值

查看端口

真实主机中添加解析

[root@foundation31 ~]# vim /etc/hosts #真实主机中添加解析

客户端测试：

当没有(req.http.host ~ “^(www.)?westos.org”)时在客户端访问westos.org时是不能识别和命中的
当添加(req.http.host ~ “^(www.)?westos.org”)时在客户端访问westos.com相当于访问www.westos.com

查看缓存命中情况,测试：

   curl -I www.westos.org
   X-Cache: HIT from westos cache #命中
   X-Cache: MISS from westos cache #未命中

第一次访问没有缓存

第一次访问直接加载缓存

四、CDN健康检查

打开一台虚拟机server4，安装httpd服务, 启动服务

修改server4和server2的默认发布页面

在server1上继续修改配置文件/etc/varnish/default.vcl

设定表示：

import directors;	%在4版本需要导入模块，
 %directors模块包含：round_robin，fallback，random，hash四个对象即四种负载均衡模式。
  sub vcl_init 
     new web_cluster = directors.round_robin();
 % 初始化时，初始化一个负载均衡器。

当访问域名为www.westos.org/westos.org时，由web_cluster模块中的web1（server2）和 web3（server4）提供服务，调度方式为rr轮叫；
当访问域名为bbs.westos.org时，由web2（server3提供服务）；
其余返回404 no cache。
并打开return(pass)参数，

http中pass生效表示不在cdn中取缓存数据,直接在后台取数据,这样的话,varnish没有起到任何作用相当于负载均衡,他只是为了在测试中更好的看到实验效果,实际中不需要添加.实验中当清空了缓存数据,有一端的后台服务器挂掉之后,另一个服务器会顶替他,如果挂掉的服务器数据还在有效期,还是可以在cdn中方问到

测试
可以看到web1和web3轮叫，负载均衡效果出来！！！

server4的httpd停止服务

再次测试：

server4会显示503报错，这说明CDN没有健康监测（否则如果后端服务器坏了就不会给他发请求了）。这在实际生产中是不允许的，因为客户端不可以访问到错误的页面

添加健康检测
修改server1的配置文件，注意安全监测的代码必须写在语句块最前面，不然会报错（因为需要先引入安全监测的模块，才能进行检测），每个服务下也要添加健康检测模块调用

 每隔三秒执行一次健康检测

再次测试，发现只有server2在提供服务

恢复server4的httpd 服务，并再次测试，又恢复负载均衡

五、CDN结合nginx进行调度（使服务端可以获取客户端的原始IP）

在生产环境中有时候会有这样的需求：
（1）如果按照这样操作,所有的请求都是CDN发往Server端的,也就是说对Server端来说看到的IP永远是CDN的IP；
（2）如果服务端需要根据访问量等信息做业务分析, 这时候如果不做设置, 则服务端获取到的永远都是CDN的IP, 无法满足业务需求。
（3）服务器可能需要根据访问量等信息做业务分析，这时候就需要获取到客户端的ip，但是正常情况下客户端访问到服务器会经过两次反向代理 cdn 和proxy，这时候如果不做设置，则原站获取到的都是离自己最近一级的proxy的ip，因此无法满足业务需求。通过CDN结合nginx进行调度，
现在访问路径为：
客户端->cdn->nginx->真正服务器

nginx 在做反向代理时，在拿后端的数据时，后端不可以拿到客户端的IP，用的cookie 来解决该问题； CDN 也是一个反向代理，CDN 如何拿到客户端的地址呢？

将server4的httpd服务停止，因为需要下载nginx服务，进行nginx的调度,nginx和鄂httpd服务都是用80端口，防止端口冲突

解压, 并安装依赖包

编译，安装，软连接，语法检测

[root@server4 nginx-1.20.1]# ./configure --with-http_ssl_module
[root@server4 nginx-1.20.1]# make
[root@server4 nginx-1.20.1]# make install
[root@server4 nginx-1.20.1]# ln -s /usr/local/nginx/sbin/nginx /usr/local/bin/
[root@server4 nginx-1.20.1]# nginx -t

修改nginx的配置文件/usr/local/nginx/conf/nginx.conf，完成负载均衡的调度：

在nginx中配置proxy_pass代理转发，反向代理proxy_pass的语法结构为proxy_pass
URL，其中，URL为要设置的被代理服务器的地址，如果被代理服务器是一组服务器的话，可以使用upstream指令配置后端服务器组（一图）；
此模块表示：如果客户端请求www.westos.org，请求被该location块处理，将转向地址http://westos，即由代理服务器server2和server3提供服务。（反向代理是作用在服务器端的，对于用户的一个请求，会转发到多个后端处理器中的一台来处理该具体请求。）

server4 定义负载均衡器

启动nginx服务：nginx

查看nginx的80端口：

server1中将cdn与nginx连接完成负载均衡
修改varnish配置文件 /etc/varnish/default.vcl
添加web3
为了避免影响，去掉负载均衡模块，健康监测模块

设定表明，当客户端访问域名为www.westos.org/westos.org ，则代理到web3，（由server4提供服务），此时server4上部署了nginx服务，它将会把用户的请求转发到server2和server3去处理

server1 CDN 代理到 server4，再由nginx 代理到 server2/server3

重启服务

真机进行测试：发现在server2和server3上实现负载均衡

在server2或者server3上查看日志，可以看到虽然是通过客户端172.25.36.250来访问的，但是日志却显示访问来自CDN调度器172.25.28.1

如何找到真正的客户端原始的ip呢？我们需要在server3上也安装nginx

测试nginx服务

在server4上的nginx配置文件修改一下：注释掉调度器server2，只观察server3

停止server3的httpd服务，重启nginx服务（端口冲突）

客户端curl测试之后，在server3上查看日志，但IP是调度器nginx所在server4的IP

在server3上修改nginx的配置文件，添加real ip模块

real_ip_header 是指从接收到报文的哪个http首部去获取前代理传送的用户ip
real_ip_recursive 是否递归地排除直至得到用户ip（默认为off）

重启nginx服务

客户端再次curl访问www.wesos.org

在server3上查看日志，此时得到了客户端的真实IP

[root@server3 nginx-1.20.1~]# cat /var/logs/httpd/access_log 
172.25.28.250 - - [08/Aug/2021:16:15:04 +0800] "GET / HTTP/1.0" 200 12 "-" "curl/7.61.1"