[不要]使用 CDN

几乎每一篇用于优化网站速度的文章或工具都有一个温和的条款“使用 CDN”。 通俗地讲,CDN是内容分发网络或内容分发网络。 Method Lab 经常会遇到客户关于此主题的问题;其中一些客户启用了自己的 CDN。 本文的目的是了解 CDN 在网站加载速度方面可以提供什么、可能会出现什么问题以及在哪些情况下使用 CDN 是合理的。

[不要]使用 CDN

图中圈出的延迟是由于使用CDN造成的。

有一点历史

与许多技术一样,CDN 的出现也是出于需要。 随着网民互联网渠道的发展,出现了在线视频服务。 当然,与常规网站内容(图片、文本和 CSS 或 JS 代码)相比,视频内容需要更多数量级的带宽。

当尝试从一台服务器向多个客户端并行广播视频流时,该服务器的 Internet 通道很可能成为瓶颈。 通常,几千个线程就足以堵塞典型的服务器通道。 当然,可能还有其他资源限制,但目前这些并不重要。 同样重要的是,扩展服务器渠道成本太高(有时是不可能的),而且也不切实际。 广播期间频道上的负载将是周期性的。

CDN完美解决了单个服务器的通道限制问题。 客户端不直接连接到服务器,而是连接到 CDN 网络中的节点。 在理想情况下,服务器将一个流发送到 CDN 节点,然后网络使用自己的资源将该流传送给许多用户。 从经济角度来看,我们只需为实际消耗的资源(可以是带宽或流量)付费,并获得服务的出色可扩展性。 使用 CDN 来传送大量内容是完全合理且合乎逻辑的。 尽管值得注意的是,该领域最大的参与者(例如 Netflix)构建自己的 CDN,而不是使用大型商业 CDN(Akamai、Cloudflare、Fastly 等)

随着网络的发展,网络应用程序本身也变得越来越复杂。 加载速度的问题就凸显出来了。 网站速度爱好者很快就发现了导致网站加载缓慢的几个主要问题。 其中之一是网络延迟(RTT - 往返时间或 ping 时间)。 延迟会影响网站加载的许多过程:建立 TCP 连接、启动 TLS 会话、加载每个单独的资源(图像、JS 文件、HTML 文档等)

当使用 HTTP/1.1 协议时(在 SPDY、QUIC 和 HTTP/2 出现之前,这是唯一的选择),浏览器对一台主机打开的 TCP 连接不超过 6 个,这一事实使问题变得更加严重。 所有这些都导致连接停机和通道带宽的低效使用。 这个问题通过域分片得到了部分解决——创建额外的主机来克服连接数量的限制。

这就是 CDN 的第二个能力出现的地方——减少由于点数量多且节点距离用户较近而导致的延迟 (RTT)。 距离在这里起着决定性的作用:光速是有限的(光纤中约为200公里/秒)。 这意味着每行驶 000 公里就会增加 1000 毫秒的延迟或 RTT 增加 5 毫秒。 这是传输所需的最短时间,因为中间设备也存在延迟。 由于 CDN 通常知道如何在其服务器上缓存对象,因此我们可以从通过 CDN 加载此类对象中受益。 其必要条件是:缓存中存在对象、与 Web 应用程序服务器(源服务器)相比,CDN 指向用户的距离较近。 重要的是要了解 CDN 节点的地理邻近性并不能保证低延迟。 客户端和 CDN 之间的路由可以这样构建,即客户端将连接到另一个国家/地区(甚至可能位于另一个大陆)的主机。 这就是电信运营商和 CDN 服务之间的关系(对等、连接、参与 IX 等)以及 CDN 本身的流量路由策略发挥作用的地方。 例如,Cloudflare 在使用两个初始计划(免费和廉价)时,不保证从最近的主机交付内容 - 将选择主机以实现最低成本。

许多领先的互联网公司吸引了公众(网络开发人员和服务所有者)对加载速度和网站性能主题的兴趣。 这些公司包括雅虎(Yslow 工具)、AOL(WebPageTest)和 Google(Page Speed Insights 服务),它们正在制定自己的网站加速建议(主要与客户端优化相关)。 后来,出现了新的网站速度测试工具,其中也提供了提高网站速度的技巧。 这些服务或插件都有一个一致的建议:“使用 CDN”。 网络延迟的减少通常被用来解释 CDN 的效果。 不幸的是,并不是每个人都准备好准确理解 CDN 的加速效果是如何实现的以及如何衡量它,因此该建议是出于信念并用作假设。 事实上,并非所有 CDN 都是一样的。

立即使用 CDN

为了评估使用 CDN 的有用性,需要对它们进行分类。 现在在实践中可以发现什么(当然,括号中的示例并不详尽):

  1. 用于分发 JS 库的免费 CDN(MaxCDN、Google.Yandex)。
  2. 用于客户端优化的服务 CDN(例如,用于字体的 Google Fonts、用于图像的 Cloudinary、Cloudimage)。
  3. 用于 CMS 中的静态和资源优化的 CDN(可在 Bitrix、WordPress 等中使用)。
  4. 通用 CDN(StackPath、CDNVideo、NGENIX、Megafon)。
  5. 用于网站加速的 CDN(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。 此公式不考虑移动网络中激活设备无线电通道(如果未激活)的延迟以及手机信号塔上的延迟。

以下是网站加载瀑布图的样子(连接到 CDN 的延迟以 RTT 150 毫秒突出显示):

[不要]使用 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 的在线服务,例如 vsszhat.rf).

2.设置客户端缓存头

还有一个简单的加速功能:添加客户端(浏览器)内容缓存的标头。 最新的标头是cache-control,过时的标头是expires。 此外,还可以使用 Etag。 最主要的是cache-control的max-age足够大(一个月或者更长),如果你准备尽可能地缓存资源,你可以添加immutable选项。

CDN 可以降低 max-age 值,迫使用户更频繁地重新加载静态内容。 目前尚不清楚这与什么有关:希望增加网络流量或增加与不知道如何重置缓存的网站的兼容性。 例如,默认的 Cloudflare 标头缓存时间为 1 小时,这对于不可变的静态数据来说非常低。

3、图像优化

由于CDN承担了缓存和服务图片的功能,因此在CDN侧进行优化并以这种形式将其服务给用户是合乎逻辑的。 我们马上预约一下,该功能仅适用于 CDN 类型 2、3 和 5。

您可以通过多种方式优化图像:使用高级压缩格式(例如 WebP)、更高效的编码器 (MozJPEG),或者只是清理不必要的元数据。

一般来说,此类优化有两种类型:有质量损失和无质量损失。 CDN 通常努力使用无损优化,以避免客户对图像质量变化可能发生的投诉。 在这种情况下,收益将是最小的。 实际上,JPEG 质量级别通常比必要的要高得多,您可以安全地以较低的质量级别重新压缩,而不会影响用户体验。 另一方面,很难确定所有可能的 Web 应用程序的质量水平和设置,因此与考虑上下文(图像的目的、Web 应用程序的类型)而应用的设置相比,CDN 使用更保守的设置, ETC。)

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 主机和我们的服务器之间)。

对于某些应用程序,值得关注安全问题:流量通常在 CDN 节点上解密,这是流量拦截的潜在机会。 顶级资费计划中通常提供不披露流量的工作选项,但需支付额外费用。

5. 减少连接延迟

大家都在谈论的 CDN 的主要好处是:CDN 主机和用户之间的低延迟(更短的距离)。 通过创建地理分布式网络架构来实现,其中主机位于用户集中点(城市、流量交换点等)

实际上,不同网络的优先级可能位于特定区域。 例如,俄罗斯 CDN 将在俄罗斯拥有更多存在点。 美国公司首先会在美国发展网络。 例如,最大的CDN之一Cloudflare在俄罗斯只有2个点——莫斯科和圣彼得堡。 也就是说,与直接放置在莫斯科相比,我们最多可以节省约10毫秒的延迟。

大多数西方 CDN 在俄罗斯根本没有站点。 通过连接到他们,您只会增加俄罗斯观众的延迟。

6.内容优化(缩小、结构变化)

最复杂、技术最先进的一点。 在交付过程中更改内容可能非常危险。 即使我们进行缩小:减少源代码(由于额外的空格、不重要的结构等)也会影响其性能。 如果我们谈论更严重的更改 - 将 JS 代码移至 HTML 末尾、合并文件等 - 破坏网站功能的风险甚至更高。

因此,只有某些类型 5 CDN 会这样做。 当然,不可能自动执行加快速度所需的所有更改,需要手动分析和优化。 例如,删除未使用或重复的代码是一项手动任务。

通常,所有此类优化均由设置控制,并且默认情况下禁用最危险的优化。

支持CDN类型的加速能力

那么让我们来看看不同类型的 CDN 提供了哪些潜在的加速机会。

为了方便起见,我们重复一下分类。

  1. 用于分发 JS 库的免费 CDN(MaxCDN、Google.Yandex)。
  2. 用于客户端优化的服务 CDN(例如,用于字体的 Google Fonts、用于图像的 Cloudinary、Cloudimage)。
  3. 用于 CMS 中的静态和资源优化的 CDN(可在 Bitrix、WordPress 等中使用)。
  4. 通用 CDN(StackPath、CDNVideo、NGENIX、Megafon)。
  5. 用于网站加速的 CDN(Cloudflare、Imperva、Airi)。

现在我们来比较一下CDN的特点和类型。

机会
1类型
2类型
3类型
4类型
5类型

文本压缩
+–

+–
+–
+

缓存标头
+
+
+
+
+

Картинки

+–
+–

+

TLS



+–
+

延迟



+
+

内容




+

本表中,“+”表示完全支持,“-”表示不支持,“+-”表示部分支持。 当然,现实中可能与此表存在偏差(例如,某些通用 CDN 会实现优化图像的功能),但对于一般想法来说它是有用的。

结果

希望读完本文后您能够更清楚地了解“使用 CDN”建议来加速您的网站。

与任何行业一样,您不能相信任何服务的营销承诺。 效果需要在真实条件下测量和测试。 如果您已经在使用 CDN,请使用本文中描述的标准检查其有效性。

现在使用 CDN 可能会减慢网站的加载时间。

作为一般建议,我们可以重点关注以下内容:研究您的受众,确定其地理范围。 如果您的主要受众集中在 1-2 公里的半径内,则不需要 CDN 来实现其主要目的 - 减少延迟。 相反,您可以将服务器放置在更靠近用户的位置并正确配置它,从而获得本文中描述的大部分优化(免费且永久)。

如果您的受众确实分布在不同的地理位置(半径超过 3000 公里),那么使用优质 CDN 确实会很有用。 但是,您需要提前了解您的 CDN 到底可以加速什么(请参阅功能表及其描述)。 然而,网站加速仍然是一项复杂的任务,无法通过连接 CDN 来解决。 除了上述优化之外,CDN背后最有效的加速手段是:服务器部分的优化、客户端部分的高级更改(删除未使用的代码、优化渲染过程、处理内容、字体、适应性等)。 )

来源: habr.com

添加评论