在几乎所有用于优化网站速度的文章或工具中，都有一个适中的“使用CDN”项目。 通常，CDN是内容交付网络。 在Method Lab，我们经常会遇到有关此主题的客户问题，其中一些问题包括CDN本身。 本文的目的是弄清CDN在站点加载速度方面可以提供什么，可能出现什么问题，以及在哪种情况下使用CDN是合理的。
图片中的延迟是由于使用CDN引起的。
一点历史
像许多技术一样，CDN根据需要出现。 随着面向Web用户的Internet渠道的发展，在线视频服务已经出现。 自然，与常规网站内容（图片，文本以及CSS或JS代码）相比，视频内容需要更大数量级的带宽。
如果您尝试从一台服务器并行广播与多个客户端并行的视频流，则该服务器的Internet通道很可能会成为瓶颈。 通常，数千个流足以阻塞典型的服务器通道。 当然，可能还有其他资源限制，但是现在它们并不重要。 同样重要的是，扩展服务器通道过于昂贵（有时是不可能的），甚至是不切实际的。 广播期间频道上的负载将是周期性的。
CDN解决了单独服务器的通道限制问题。 客户端不直接连接到服务器，而是直接连接到CDN网络的节点。 在理想情况下，服务器将一个流提供给CDN，然后网络使用其自己的资源将该流传递给许多用户。 从经济角度来看，我们仅为实际消耗的资源（这可能是带宽或流量）付费，并且我们的服务具有出色的可扩展性。 使用CDN传递大量内容是完全合理和合乎逻辑的。 尽管值得注意的是，该领域的最大参与者（例如Netflix）会构建CDN，而不是使用大型商业CDN（Akamai，Cloudflare，Fastly等）。
随着Web的发展，Web应用程序本身变得更加复杂和沉重。 下载速度的问题日益突出。 网站速度爱好者很快发现了导致网站加载速度缓慢的几个主要问题。 其中之一是网络延迟（RTT-往返时间或ping时间）。 延迟会影响网站加载的许多过程：建立TCP连接，启动TLS会话，分别加载每个资源（图片，JS文件，HTML文档等）
当使用HTTP / 1.1穿孔（在SPDY，QUIC和HTTP / 2之前是唯一选择）时，浏览器打开到一个主机的TCP连接最多不超过6个，这一事实使问题更加严重。 所有这些导致简单的连接和对信道带宽的低效率使用。 域分片部分解决了该问题-创建额外的主机以克服连接数量的限制。
CDN的第二种功能-延迟减少（RTT），原因是点数众多且节点与用户接近。 这里的距离起着决定性的作用：光速受到限制（光纤中大约200,000 km / s）。 这意味着每1000 km的路径会增加5 ms的延迟或10 ms的RTT。 这是最短的传输时间，因为中间设备上仍然存在延迟。 由于CDN通常可以在其服务器上缓存对象，因此我们可以从通过CDN加载此类对象中受益。 这样做的先决条件：与Web应用程序服务器（原始服务器）相比，缓存中存在对象，CDN指向用户的距离。 重要的是要了解，CDN的地理位置并不保证低延迟。 客户端和CDN之间的路由可以设计成客户端可以连接到另一个国家（可能在另一个大陆）的主机。 在此，电信运营商与CDN服务之间的关系（对等，接口的存在，参与IX等）和CDN本身的业务路由策略生效。 例如，当使用两个初始计划（免费和廉价）时，Cloudflare不保证从最近的站点提供内容-将选择主机以实现最低成本。
许多领先的互联网公司在下载速度和网站性能方面引起了公众（网站开发人员和服务所有者）的兴趣。 这些公司包括Yahoo（工具Yslow），AOL（WebPageTest）和Google（服务Page Speed Insights），它们针对网站加速提出了建议（主要涉及客户端优化）。 后来，出现了用于测试站点速度的新工具，这些工具也为提高站点速度提供了提示。 在每个服务或插件中，都没有建议“使用CDN”。 作为对CDN效果的解释，通常表明减少了网络延迟。 不幸的是，并不是每个人都准备好理解如何实现CDN加速的效果以及如何对其进行衡量，因此该建议是基于信念并用作假设。 实际上，并非所有CDN都同样有用。
立即使用CDN
为了评估使用CDN的效用，需要对其进行分类。 现在可以在实践中找到（括号中的示例当然不是穷举的）：
- 用于分发JS库的免费CDN（MaxCDN，Google。Yandex）。
- 用于客户端优化的CDN服务（例如，用于字体的Google字体，用于图片的Cloudinary，Cloudimage）。
- CDN用于CMS中的静态和资源优化（在Bitrix，Wordpress和其他版本中可用）。
- 通用CDN（StackPath，CDNVideo，NGENIX，Megaphone）。
- DNS用于网站加速（Cloudflare，Imperva和Airi）。
这些类型之间的主要区别如下：流量的哪一部分通过CDN。 类型1-3仅交付部分内容：从一个请求到几十个请求（通常是图片）。 类型4和5是通过CDN的完整代理流量。
实际上，这意味着用于下载站点的连接数。 使用HTTP / 2时，我们使用一个与主机的TCP连接来处理任意数量的请求。 如果我们在主主机（源）和CDN上共享资源，则有必要在多个域中分配请求并创建多个TCP连接。 最坏的情况是：DNS（1 RTT）+ TCP（1 RTT）+ TLS（2-3 RTT）= 6-7 RTT。 该公式未考虑到移动网络在激活设备的无线电信道时的延迟（如果未激活）以及在蜂窝塔上的延迟。
这是网站瀑布式加载的样子（突出显示了延迟，用于通过RTT 150 ms连接到CDN）：
如果CDN涵盖了所有站点流量（第三方服务除外），那么我们可以使用单个TCP连接，从而节省了连接其他主机的时间。 当然，这适用于HTTP / 2连接。
进一步的差异取决于特定CDN的功能-对于第一种类型，它只是托管一个静态文件，对于第五种类型，它正在更改几种类型的站点内容以对其进行优化。
CDN网站加速功能
让我们描述CDN的全部网站加速功能，而不考虑各个类型的CDN的功能，然后看看在每种CDN中实现了什么。
1.压缩文本资源
但是，最基本的功能和可理解的功能通常执行不佳。 压缩的存在将所有CDN声明为它们的加速功能。 但是，如果您更详细地看，则会发现缺陷：
- 低度可用于动态压缩-5-6（例如，对于gzip最大-9）；
- 在静态压缩（缓存中的文件）中，未使用其他功能（例如，幂为11的zopfi或brotli）
- 不支持有效的brotli压缩（比gzip节省约20％）。
如果使用CDN，则应检查以下几点：取自CDN的文件，以压缩形式固定其大小，然后手动压缩以进行比较（可以使用带有brotli支持的某些在线服务，例如
compress.rf ）。
2.设置客户端缓存头
也是一个简单的加速功能：放置标头以供客户端（浏览器）缓存内容。 最新的高速缓存控制标头，expires已过期。 此外，可以使用Etag。 最主要的是，缓存控制的最大容量应该足够大（一个月或更长时间），如果您准备尽可能快地缓存资源，则可以添加不可变选项。
CDN可能会低估最大使用期限值，从而迫使用户更频繁地重新加载静态数据。 原因是什么：出于增加网络流量或与不知道如何刷新缓存的站点的兼容性的愿望，目前尚不清楚。 例如，Cloudflare标头的默认缓存时间为1小时，这对于不可变的静态变量而言非常短。
3.图像优化
由于CDN接管了缓存和上传图片的功能，因此在CDN一侧对其进行优化并以这种形式提供给用户是合乎逻辑的。 让我们立即进行预订，此功能仅适用于CDN类型2、3和5。
您可以通过多种方式优化图像：使用高级压缩格式（例如WebP），更高效的编码器（MozJPEG）或仅清除不必要的元数据。
通常，这种优化有两种类型：质量损失和质量损失。 CDN通常寻求使用无损优化，以避免潜在的客户抱怨图像质量变化。 在这种情况下，增益将很小。 实际上，JPEG的质量水平通常大大高于必要水平，您可以使用较低的质量指标安全地进行重新压缩，而不会影响用户的感知。 另一方面，很难为所有可能的Web应用程序通用地确定质量和设置的级别，因此与考虑到上下文（图像分配，Web应用程序的类型等）可以应用的设置相比，CDN使用的设置更加保守。
4. TLS连接的优化
如今，大多数流量都是通过TLS连接传输的，这意味着我们在TLS协商上花费了更多时间。 最近，已经开发了新技术来加速此过程。 例如，EC加密，TLS 1.3，会话缓存和票证（会话票证），硬件加密加速（AES-NI）等。正确的TLS设置可以将连接时间减少到0-1 RTT（不包括DNS和TCP） ）
在现代软件的存在下，在我们自己的设施中实施这种做法并不困难。
并非所有CDN都实现TLS最佳做法；可以通过测量TLS连接的时间来验证这一点（例如，在Webpagetest中）。 新连接的理想选择-1RTT，2RTT-中级，3RTT等-很差。
还应注意，即使在CDN级别使用TLS时，带有Web应用程序的服务器也必须处理TLS，但必须从CDN端进行处理，因为服务器和CDN之间的流量在公共网络上传递。 在最坏的情况下，TLS连接会延迟两次（第一个连接到CDN主机，第二个连接到我们的服务器）。
对于某些应用程序，您应注意安全性问题：通常，流量是在CDN节点上解密的，这是拦截流量的潜在机会。 高端收费计划中通常会提供不透露流量的工作选项，需要收费。
5.减少连接延迟
每个人都在谈论CDN的主要优点：CDN主机和用户之间的等待时间短（距离较短）。 这是通过创建一种地理上分散的网络体系结构来实现的，其中主机位于用户集中点（城市，业务交换点等）
实际上，不同网络的优先级可能位于特定区域中。 例如，俄罗斯的CDN将在俄罗斯拥有更多的服务点。 美国航空将主要在美国开发一个网络。 例如，最大的CDN Cloudflare之一在俄罗斯只有2分-莫斯科和圣彼得堡。 也就是说，与直接在莫斯科住宿相比，我们可以节省大约10毫秒的延迟。
大多数西方CDN在俄罗斯根本没有意义。 与他们建立联系只能增加俄罗斯观众的观看时间。
6.内容优化（最小化，结构更改）
最复杂和技术含量最高的项目。 更改交付内容可能会带来很大的风险。 即使我们采取了最小化措施：减少源代码（由于多余的空间，不重要的构造等）也会影响其性能。 如果我们谈论更严重的更改-将JS代码移动到HTML末尾，合并文件等，则破坏网站功能的风险甚至更高。
因此，只有某些5类CDN可以这样做。 当然，自动化加速所需的所有更改将不起作用-需要手动分析和优化。 例如，删除未使用或重复的代码特别是指手动任务。
通常，所有此类优化均由设置控制，最危险的优化默认情况下处于禁用状态。
CDN类型的加速支持
因此，让我们看一下各种类型的CDN提供哪些潜在的加速选项。
为方便起见，我们重复分类。
- 用于分发JS库的免费CDN（MaxCDN，Google。Yandex）。
- 用于客户端优化的CDN服务（例如，用于字体的Google字体，用于图片的Cloudinary，Cloudimage）。
- CDN用于CMS中的静态和资源优化（在Bitrix，Wordpress和其他版本中可用）。
- 通用CDN（StackPath，CDNVideo，NGENIX，Megaphone）。
- DNS用于网站加速（Cloudflare，Imperva和Airi）。
现在比较CDN的功能和类型。
在该表中，“ +”表示完全支持，“-”表示缺少，“ +-”表示部分支持。 当然，实际上可能会与该表产生偏差（例如，某些通用CDN会引入用于优化图像的功能），但这对于一般性想法很有用。
总结
我希望阅读本文后，您对“使用CDN”以加快网站访问速度的建议有更清晰的了解。
就像在任何行业中一样，人们无法相信任何服务的营销承诺。 必须在实际条件下对效果进行测量和验证。 如果您已经使用某种CDN，请根据本文中所述的标准检查其有效性。
也许使用CDN现在正在减慢您网站的加载速度。
作为一般建议，您可以专注于以下方面：研究您的受众，确定其地理范围。 如果您的主要受众集中在1-2 000公里的半径内，则不需要CDN来达到主要目的-减少延迟。 相反，您可以将服务器放置在离用户更近的地方，并对其进行正确配置，从而获得本文中所述的大多数优化（免费和永久）。
如果您的受众群体确实是地理分布的（半径超过3,000公里），那么使用高质量的CDN确实很有用。 但是，您需要事先了解CDN可以加快的速度（请参阅功能表及其说明）。 同时，网站加速仍然是一项复杂的任务，无法通过连接CDN来解决。 除了指示的优化之外，最有效的加速工具仍然是CDN之外的功能：服务器部件优化，高级客户端部件更改（删除未使用的代码，优化渲染过程，使用内容，字体，适应性等）。