我们应该为CDN做什么？

哈勃！ 在本文中，我们将构建自己的CDN。 为什么不使用现成的解决方案？ 由于作者的网站是完全静态的，因此是在Jekyll上制作的，需要尽快提供大图片。 该服务器不应缓存，它应该存储整个站点，支持HTTP / 2和Brotli，并且应在所有服务器上安装相同的证书。

我们还将在Windows Server 2019 Core上运行的IIS上完成所有操作。

简要介绍实施

在末端节点，我们将管理内置在操作系统中的方法，我们需要：

1. 活动目录
2. DFS
3. IIS
4. Winacme
5. RSAT

可选，但建议：

1. Windows管理中心

在具有站点的站点上，仅需要IIS和DFS，Active Directory是必需的，DFS是Active Directory所必需的，它将在服务器之间同步站点的内容。 需要RSAT来管理组件，并且需要Windows Admin Center来编辑注册表。 这也可以通过Powershell完成，我将对此进行讨论。

作者的域名为***。***。Wtf（请不要惊慌），服务器由数据中心命名，并以cache-zur1，cahe-ru等形式命名。 部署了AD，并将服务器连接到它。 现在按顺序。

点选择

RUVDS拥有8个数据中心 -欧洲的3个和俄罗斯的5个。 我的选择落在莫斯科的Rucloud和LD8（伦敦的LD8）上。 Rucloud因为它与M9几乎没有什么不同，并且通过伦敦有一条通往美国的跨大陆电缆，因此在欧洲这是必须的。 对于欧洲较密集的地区，您可以选择瑞士或德国-通常，您可以停下来。

选择DNS GeoIP

如果客户端要访问该站点，那么如何了解应该向哪个服务器传输数据？ 当然使用DNS。 也就是说，根据访问DNS的IP地址，将给出相关答案。

我们可以使用自己的DNS（BIND和Maxmind插件）或交钥匙解决方案（Route53）。 订阅Maxmind GeoIP数据库的费用为每月25美元，Route53的费用为每个域区域0.50美元，如果您要处理一百万个请求，则还需支付1美分。 此外，创建另一点来加强DDoS攻击是最后一件事，因此我的选择落在Route53上。

本文是关于欧洲的CDN。 如果您需要俄罗斯的CDN，那么针对您自己的DNS的选择就显而易见了，因为Route53提供了按国家（而非城市）进行的路由。
Microsoft具有类似的服务（Azure Traffic Manager）。

1.安装IIS

1.1。 IIS安装

我们安装IIS的基本组件，集中式证书的支持组件，并在主服务器上安装对远程管理的其他支持。 仅一台服务器需要此组件-启用共享配置后，即使已配置了远程管理，也将无法管理其他服务器。



通过Powershell：

Install-WindowsFeature Web-Server, Web-CertProvider 

在主服务器上，您必须另外安装：

 Install-WindowsFeature Web-Mgmt-Service 

1.1.1打开遥控器

为了能够远程管理IIS服务器，我们需要提高IIS远程管理服务。 在主服务器上，启动服务：

 start-service WMSVC set-service -Name WMSVC -StartupType Automatic 

现在，我们可以通过注册表进行管理。

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server 

当然，管理注册表的最简单方法是通过Windows Admin Center。



但这也可以通过Powershell完成：

 Set-Itemproperty -path "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server" -Name "EnableRemoteManagement" -value "1" 

在Windows Server 2012和2016中，防火墙规则本身不会上升；您需要编辑防火墙。

 Set-NetFirewallRule -Name IIS-WebServerRole-WMSVC-In-TCP -Enabled True 

检查它是否上升：

 Test-NetConnection 8.8.8.8 -port 8172 

在三个不同的地方进行了三个编辑，现在我们可以使用另一个带有桌面的服务器通过IIS管理器连接到我们的服务器。 这只是为了方便后续管理。

1.2我们削减了配置的集中化

在IIS管理器中没有用于安装集中式配置和证书的按钮，它们仅在本地服务器管理器中，因此对于Server Core，您将必须通过Powershell进行所有操作。

通过SMB进行配置和证书的集中化。 因此，我使两个被剥夺权利的用户（分别用于配置和证书）分别对其文件夹具有读取访问权限，并将其分别命名为certadmin和configadmin。

建议用户在主服务器上位于本地-如果您的域控制器死亡，那么代表域用户通过SMB坚持配置和证书的应用程序将死亡。 使用本地用户消除了这种情况。

1.2.1制作共享文件夹

两个公用文件夹应存储在其中一台服务器上，从中可以获取配置和证书。 作为共享文件夹的路径，我们采用IIS配置的默认路径：

 New-SmbShare -ReadAccess configadmin@**.**wtf -Path C:\windows\System32\Inetsrv\Config -Name sharedconfigs 

对于证书，我们可以选择任何一个。 我将它们放在带有IIS的文件夹中。

 New-SmbShare -Path C:\inetpub\centralizedcerts -Name sharedconfigs -ReadAccess configadmin 

1.2.2我们将节点连接到配置

只需为将读取此配置的那些服务器完成设置。 我的名称为cache-ru的主服务器将是head，因此我在其他两个服务器上进行了配置。
输入有权访问该文件夹的用户的密码：

 $pass = Read-Host -AsSecureString Enable-IISSharedConfig -PhysicalPath \\cache-ru.**.**wtf\SharedConfig -UserName configadmin@**.**wtf -Password $pass -DontCopyRemoteKeys 

进入新会话后应立即打开。 要验证一切正常，您可以打开RSAT→计算机管理→共享文件夹→会话。 我们将看到用户会话和服务器的IP地址，该用户在该用户下读取共享文件夹。 在客户端，它由cmdlet检查：

 Get-IISSharedConfig 

这对我来说是这样的：



1.2.2将节点连接到证书

下一行只能直接输入，并且直接通过GUI连接到运行Server的桌面，而不能在Server Core上运行。

 $pass = Read-Host -AsSecureString Enable-IISCentralCertProvider -CertStoreLocation \\cache-ru.**.**wtf\centralizedcerts -UserName certadmin@**.**wtf -Password $pass 

如果尝试通过Winrm输入它，则将看到以下输出：



要远程执行此操作，您需要编辑注册表。 多么方便！ 我们飞入：

 HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ 

使用参数“ 1”创建一个32位DWORD“ Enabled”：

 Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ -Name Enabled -Value 1 

然后，我们使用参数\\ cache-ru。**。** wtf \ centraledcerts创建字符串值CertStoreLocation：

 Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ -Name CertStoreLocation -Value <a href="about:blank">\\cache-ru.**.**wtf\centralizedcerts</a> 

要检查是否一切正常，我们使用：

 Get-IISCentralCertProvider 

输出应如下所示：



然后，我们才输入：

 $pass = Read-Host -AsSecureString Set-IISCentralCertProvider -UserName certadmin@**.**wtf -Password $pass 

再次检查：

 Get-IISCentralCertProvider 

开箱即用的所有内容都将被调用。 与常见配置不同，集中式证书不会创建活动的SMB会话。

1.2.3布罗特利

在每台服务器上，下载并运行IIS压缩文件

 Start-Process .\iiscompression_amd64.msi -ArgumentList /quiet 

我们已经共享了配置，因此您只需要在一个地方进行配置。 使用IIS管理器，我们转到主服务器上的配置编辑器。

 system.webServer/httpCompression 

并将Brotli的StaticCompressionLevel设置为11，将Gzip的StaticCompressionLevel设置为9，这是他们可以执行的最大操作。

1.2.4 MIME和标头

开箱即用，IIS不会传输编码标头，这就是为什么西里尔字母变成符文的原因。 同样在MIME中，不需要添加webp格式条目。

1.转到调度程序→MIME。 找到.HTML并将其类型修改为：text / html; 字符集= utf-8



2.不要忘记Webp-您需要手动添加此MIME。

2.我们颁发证书

使用Winacme 。 首先，您需要将域绑定到站点-这可以通过IIS管理器来完成。 构建CDN时，请勿选择主机验证，因为 问题首先从确认域名所有权开始，我们的选择是通过T​​XT记录进行验证。 您将必须手动将证书路径驱动到文件夹的路径，以及从挑战手动复制记录。 现在，让空气进入您的胸部。

为了不手动打印所有内容，请使用以下命令在服务器核心上启用RDP：

 cscript C:\Windows\System32\Scregedit.wsf /ar 0 

这是RDP在服务器核心上的样子：



挑战后，证书将落入Winacme中指定的文件夹中。 Winacme将任务放在计划程序中以续订证书。 安装并忘记了。



好了，完成后，我们可以关闭RDP-我们出于充分的理由安装了Server Core，发现了很多细微差别。

 cscript C:\Windows\System32\Scregedit.wsf /ar 1 

3. Bindim证书到节点

现在，您需要配置其他两个节点，以便HTTPS最终可以正常工作。 此时，在存储证书的服务器上，HTTPS已在运行。 为了使其余部分开始在HTTPS上工作，通常，这是通过netsh完成的。

就像我们习惯的那样，我们通过RDP连接到Windows Server Core来运行此管理单元。 不要在Microsoft网站上查看，尤其是在本指南中。 其中的步骤描述不正确。

使用netsh http show sslcert，需要在主节点上获取appid，如下所述，我们将其输入：

 netsh http add sslcert ccs=443 appid= '{4dc3e181-e14b-4a21-b022-59fc669b0914}' 

appid值必须用引号引起来，否则它将不起作用。

4.安装DFS

不要通过DFS同步证书和配置，是出于某种原因发明了专用工具。 我尝试了一下，结果变得很糟糕，由于某种未知的原因，采用config的服务器上的配置只是停止读取更改，尽管这是第一次成功。 我没有找出失败的原因，因此决定以其他方式进行处理。

进一步的配置仅通过RSAT完成，文档中指定的cmdlet仅在具有GUI的Windows Server下工作。 不能仅使用Server Core部署DFS复制。 您需要将另一台具有GUI的服务器或一台运行Windows 10 Pro（已安装RSAT）的计算机加入域。

2.1。 安装

在每台服务器上，您需要安装DFS复制：

 Install-WindowsFeature FS-DFS-Replication, FS-DFS-Namespace 

2.2。 制作一个新的复制组



首先，您需要致电我们的复制组。



选择您喜欢的拓扑。 就个人而言，将内容添加到一个地方会更方便，因此我选择了一颗星星。





其中一台服务器应该是主服务器，它是复制开始的地方。 如果将文件上传到侦听器，则不会复制上传的文件。



作为复制文件夹，我选择了包含站点的默认文件夹：

 C:\inetpub\wwwroot 

该文件夹是此特定第一台服务器目录的路径。 您可以在任何位置复制此文件夹的内容，而不管其路径如何。



在一个组中，我们可以复制几个文件夹，将来如果需要，我们可以扩展它们的列表。



完了

5.测试性能

要了解该网站真正赢得了多少访问者，您需要进行评估。 他们将从两点进行。 作者的电脑在莫斯科，在法兰克福的虚拟服务器。 这三点将分别进行测试。 这是一个摘要。



我们进入Devtools并观看瀑布。 平均而言，在医院中，在站点完全加载之前，CDN会减少大约200毫秒。 图片是页面上最大的对象，一旦进入视口即会加载，因此请注意蓝色垂直线。 CDN将纯HTML +样式和脚本加速了10到15毫秒，图片加载速度提高了220毫秒，这是一个非常明显的差异。




我还测量了本地主机上Jekyll的速度：



我们转到灯塔，看到奇怪的结果：





在这种合成中，远方服务器绕过本地主机。 但是为什么呢？
为了好玩，让我们摆脱Google字体并将其传输到我们的服务器。





数据中心之间的结果保持一致。 但这仍然无法解释任何事情。 我对测试进行了多次重试，结果绝对是铁的，并且可以随时重现。

现在，我们将使用位于法兰克福的具有两个内核和4 GB RAM的VPS，看看它怎么说。 瀑布：




在这里，如果正确的话，仅在样式和HTML上节省的时间就达200毫秒。 也就是说，对于来自法兰克福的客户，该站点将仅快200毫秒。 这也反映在灯塔上。 在这种情况下，CDN不仅会加快在线商店的速度，而且还会促进简单的博客。




现在打开Goog​​le字体，然后再次查看灯塔。




不幸的是，我不再需要进行任何测试，因此我将结束。

结论

• 用于输出所有静态数据的CDN是必需的，尤其是对于沉重的图片或较长的脚本而言。
• 使用Google字体是可能且必要的，在繁重的情况下，它确实可以加快网站速度。
• 主服务器，如果您决定在Windows上执行所有这些操作，建议您使用GUI。
• 从主服务器获取配置的用户最好是本地用户-如果域控制器发生故障，节点可能会失去与配置和证书的连接，并且应用程序池将停止，因为 将无法读取配置。