让我们实际使用 CDN!介绍从DNS设置到缓存分发的一系列设置

让我们实际使用 CDN!介绍从DNS设置到缓存分发的一系列设置

作者:云资讯    浏览次数:175    2021-07-07 12:06:06

这次我们以Ogcloud的CDN网络加速器为例介绍,但流程与一般CDN类似。Web Accelerator 是一种设置项目简单的CDN,即使是初学者也相对容易使用。

设置方法的详细信息在Web Accelerator 的原始域使用设置手册中有所描述。在本文中,我们将介绍一个粗略的流程和注意事项,因此详细设置方法请参阅手册。

让我们实际使用 CDN!介绍从DNS设置到缓存分发的一系列设置-云资讯

非常重要的前期准备
在第 1 部分中,我介绍了更改 DNS 设置对于 CDN 设置至关重要。这次在介绍设置方法时假设将现有站点www.ogcloud.com更改为CDN分发,我想先从准备方面进行说明。

CDN端设置
当然,使用CDN时,需要在CDN端进行设置。必须指定源服务器的地址,但还有其他 CDN 允许您选择 http/https 进行源间通信以及使用的 HTTP 方法。Ogcloud的CDN网络加速器只能使用简单的设置项,所以只需要选择源站地址和http/https,如果使用https,则上传证书和私钥。启用设置时,您需要编辑 TXT 记录以验证域所有权。

Ogcloud 的云 DNS 中的资源记录编辑屏幕

DNS 设置更改
经常在更改DNS(权威DNS服务器)设置后使用“等待渗透”一词,这是不正确的。一般误解为更改权威DNS服务器的设置后需要几天到一周的时间才能渗透,但DNS服务器的实际行为对于每个资源记录称为TTL(Time To Live)缓存时间为设置,缓存DNS服务器缓存该TTL时间的资源记录设置值,当TTL超时后,再去权威DNS服务器获取设置值。换句话说,通过在缩短 TTL 的情况下重写设置值,可以最小化缓存清除所需的时间(称为错误渗透的事件所需的时间)。换句话说,说“等到缓存用完并反映设置”而不是“等待渗透”是正确的。考虑到这一点,让我们继续进行设置更改。

如果是正常运营的站点,我认为在DNS服务器中设置了A记录并描述了IP地址。如果你使用dig命令,它会一下子出来。

$ dig www.ogcloud.com a
<省略>
;; 回答部分:
www.ogcloud.com. 3600 IN A(IP地址)
<省略>
这意味着 www.ogcloud.com 的 TTL 为 3600 秒,并且对该域的请求应发送到具有指定 IP 地址的服务器。由于3600秒是1小时,所以缓存的有效期为1小时,也就是说如果修改www.ogcloud.com的资源记录值,最多需要1小时才能反映。

根据每个 DNS 服务器的规格,这个 TTL 可以缩短到大约 30 秒。这次,我将其设置为 60 秒。您可能会想,“如果是这样,您应该从一开始就将其设置为60秒!”,但是如果您一直将其设置为60秒,则缓存时间会更频繁地用完,并且会更频繁。由于要到权威的DNS服务器进行名称解析,查找DNS需要时间,导致站点显示速度变慢。TTL 越大,页面显示越快,因为名称可以由附近的缓存 DNS 服务器解析,而不是长时间由远处的权威 DNS 服务器解析。不断缩短缓存时间会减少站点显示时间,所以在没有任何内容的情况下让它更长。

因此,让我们更改设置值。在 DNS 服务器的管理屏幕上将 TTL 设置为 60。

如果原来的TTL为3600,大约1小时后再次尝试使用dig命令时会反映出来。

$ dig www.ogcloud.com a
<省略>
;; 回答部分:
www.ogcloud.com. 60 IN A(IP 地址)
<省略>
有一些站点对于查找 DNS 设置非常有用。您可以通过在whatsmydns.net 中输入要查找的 域和资源记录来查看世界各地 DNS 服务器的设置。这允许您检查设置值已被改写了多少。

这样就完成了准备工作。如上所述,缩短TTL解析名称需要更长的时间,因此如果设置为86400秒,请在设置前24小时或更长时间将其缩短为3600秒,再设置前1小时或更长时间。建议逐渐缩短它,例如 60 秒。默认值因 DNS 而异,因此如果需要更改设置,请提前检查 TTL。如果设置为 72 小时,则设置更改需要 3 天或更长时间才能反映,因此最好在至少 1 周前仅检查 TTL 值,并在必要时更改设置。

当然,TTL只是缓存时间,比较麻烦,所以改成86400的设置吧!尽管可以做出粗略的回应,但如上文所述,最多需要一天的时间来反映它。如果可以正常设置就好了(其实不是很好,不过过一会就完成了),但是如果要设置错误的值或者自己切换回设置,切换回来需要一天多的时间并且风险非常高。在编辑DNS服务器的资源记录时,缩短TTL→工作→观望→将TTL恢复到之前的状态是安全的。有很多关于 DNS 服务器初学者的书籍,所以我强烈推荐阅读它们。它不仅在使用 CDN 时非常有用,而且在移动租用服务器时也非常有用。

Web 服务器端设置
根据CDN运营商的规范,可能需要在源站端设置是否缓存。Ogcloud的CDN网页加速器在CDN端没有控制缓存设置与否的功能,所以需要在源站端添加“Cache-control: s-maxage = 600”等HTTP响应头…… Amazon CloudFront能够缓存通过服务器的所有流量,但也有可能缓存非预期文件,因此如果可能,最好明确选择要缓存的文件。在 Amazon CloudFront 中,您可以更改是缓存所有文件还是使用分配设置中的响应标头进行控制。

如果您可以编辑 .htaccess,则添加响应头很容易。详细的设置方法在Web Accelerator 手册页中介绍。一个常见的错误是忘记指定秒数为“Cache-Control: max-age”或者忘记添加响应头本身,使用缓存命中率为0%(只收钱)的CDN。有有些人(处于挂起负载未分配的状态),所以一定要检查响应头的正确操作和设置DNS后的操作。

显示前确认
CDN设置的很多部分在生产中是一次性的,但是我们先确认一下,可以提前确认。尤其是初学者,我们建议您创建一个不影响生产环境的合适的子域的站点,并练习,直到您习惯多次。完成所有设置后,首先检查 CNAME 设置目的地的显示。在CDN中设置源IP地址和源主机名后,会发出一个地址要求你CNAME这个域。Ogcloud 的 CDN Web Accelerator发布一个 URL(随机字母数字字符).user.webaccel.jp。

尝试访问此地址以查看该站点是否实际显示。如果是 WordPress 站点,如果站点 URL 不同,将无法转换,但您应该只能检查首页。如果不显示,可能是源站设置有问题或者CDN端的设置有问题。

接下来,检查预期文件是否被 Chrome 开发人员工具等缓存,并且响应头 X-Cache: HIT 已设置。如果这是 MISS,则不会缓存。如果多次重装后MISS仍然存在,则怀疑设置错误。让我们通过查看手册来查看设置。

换工作
现在,让我们实际设置网站的 CDN 分发。

我认为 TTL 是提前 60 秒。这里需要注意的一件重要事情是,如果您尝试设置 CNAME,则不能在同一个子域(本例中为 www.ogcloud.com)上设置 A 记录或 TXT 记录。换句话说,您不能添加带有 A 记录的 CNAME 记录,因此您必须在设置 CNAME 记录之前删除 A 记录。以网页加速器为例,我认为TXT记录是为域名所有权确认设置的,所以先删除这个(不影响操作)。

根据DNS服务器的规格,有的必须先删除再添加,有的则可以一次删除再添加。在前一种情况下,负缓存更有可能发生,因此快速执行此操作很重要。此外,可能无法看到该站点,因此最好在没有人观看的时间工作,例如午夜。

什么是负缓存?
我认为这是一个关于 DNS 负面缓存的陌生词,所以让我们暂时接触一下。至此,我们已经说明了在权威DNS服务器中设置的资源记录在TTL的时间由缓存DNS服务器解析,当TTL通过后,再次联系权威DNS服务器。当存在资源记录值时就是这种情况。

如果没有资源记录值,则将SOA记录的TTL,就像A记录的老大一样(对不起,很粗糙),缓存为“无资源记录值”。这是 DNS 中的负缓存。即使在负缓存保持期间向权威DNS服务器输入新的设置值,由于“没有资源记录值”被缓存在缓存DNS服务器中,所以不能用新的设置值解析名称。也就是说,如果A记录的删除被缓存了,就无法浏览该站点。当 SOA 记录的 TTL 到期时,将通过再次查询权威 DNS 服务器来反映新的设置值。

RFC2308 中将负缓存时间指定为 SOA 记录的 TTL 或 SOA 记录的 MINIMUM 值,以较小者为准。查看ns1.dns.ne.jp,它是运行在Ogcloud Internet 上的DNS 服务器,TTL 为900,MINIMUM 为3600,因此将应用900 秒。

$ dig ogcloud.com soa
<省略>
;; 权威部分:
ogcloud.com. 900 IN SOA master.dns.ne.jp. Tech.ogcloud.ad.jp. 2018111400 3600 900 3600000 3600
<省略>
负缓存时间因您使用的DNS服务器而异,因此如果您在工作前检查它,即使出现问题也可以从容应对。DNS是一个非常复杂的系统,但是对于运营一个网站来说是非常重要的知识,所以请借此机会和CDN的使用方法一起记住它。

让我们回到切换工作!
如果你写的看不到站点,可能有人会认为这是一个可怕的任务,但不要担心,记住TTL的解释。即使设置值不正确,也可以通过缩短TTL,即最大缓存时间,将损害降到最低。存在负缓存的可能性,但您工作得越快,发生的可能性就越小。

这就是为什么它是一个开关。将 CDN 运营商发布的 CNAME 目的地设置为现有域。通常,您将在 DNS 服务器设置更改屏幕上工作。删除或编辑 A 记录,使其成为 CNAME 记录,并将值设置为 CDN 发布的域。让我们将 TTL 保留为 60 秒。

设置好后,用dig命令检查。将 TTL 设置为 60 秒,直到完成操作检查。

$ dig www.ogcloud.com cname
<省略>
www.ogcloud.com. 60 IN CNAME(随机字母数字字符).user.webaccel.jp。
(随机字母数字字符) .user.webaccel.jp. 60 IN A (IP 地址)
<省略>
请注意,它会在一段时间后(理论上在这种情况下在 60 秒内)才会反映出来。在这种情况下,使用前面介绍的whatsmydns.net会很方便。看设置值,从目前A记录设置IP地址的简单状态来看,好像是在站点域设置了CNAME记录,重定向到了CDN,那个CDN的服务器IP地址是A 设置已更改,以便记录定向并绕过对缓存服务器(在本例中为 CDN,而不是 DNS)的访问。

由于DNS只将站点域从源头指向CDN,可见需要在CDN端设置源站的IP地址和FQDN。

操作检查
如果你设置了并且网站看起来正常,让我们检查一下操作。检查网站的整体显示。如果您有发帖功能或者如果您使用的是 WordPress,请检查实际发帖。

在本系列的第三部分中提到,关闭WordPress管理界面的缓存(在/wp-admin/下)操作起来很方便,所以如果你也设置了,我检查了操作。这样会更好. 特别是在使用Amazon CloudFront 时,除非您输入缓存排除设置、cookie 传输设置等,否则 WordPress 站点的管理屏幕将无法正常工作。有了 Ogcloud 的 CDN 网络加速器,设置很简单,但这里不需要复杂的设置。检查完所有步骤后,将 TTL 设置回原来的长 TTL。您还可以在手册站点上找到如何检查它是否被缓存。如果您可以使用 Chrome 开发人员工具确认预期的文件是 X-Cache: HIT 就可以了,如下图所示。

事实上,在设置CDN时,很大一部分查询是无法缓存的文件。在 Ogcloud 的 CDN web 加速器中,即使你设置了像 Cache-Control: s-maxage = 60 这样的响应头,如果你在其他地方添加 no-cache 或者有其他缓存无效的头,缓存是不会设置的。尤其是在使用 WordPress 时,请注意 no-cache 标头会自动添加到所有仪表板以及您在登录时浏览网站时。

切换回来
我将介绍由于网站不显示或由于设置不当而无法实现预期操作的切换时的步骤。基本上,您将不得不再次更改 DNS 设置。为此,即使在设置 CNAME 时,也将 TTL 设置为 60 秒,以便在紧急情况下可以立即返回。进入DNS设置更改界面,将CNAME改为A,删除CDN的域,使用原源IP地址。将 TTL 设置为 60 秒以防万一。

当设置更改生效时,网站投递将恢复为从源站通过 CDN 直接投递。如果您成功切换回来,请在必要时恢复 TTL。这样就完成了切回。

概括
什么是 CDN?我已经匆忙解释了实际设置,但是如何?正如你们许多人在这个设置中注意到的那样,设置 CDN 的大部分最困难的事情是理解 DNS 的机制和设置缓存。相反,其他部分非常简单,一旦学会了设置方法,就可以自由切换和切换ON/OFF。