几乎每一篇用于优化网站速度的文章或工具都有一个温和的条款“使用 CDN”。 通俗地讲,CDN是内容分发网络或内容分发网络。 Method Lab 经常会遇到客户关于此主题的问题;其中一些客户启用了自己的 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 的有用性,需要对它们进行分类。 现在在实践中可以发现什么(当然,括号中的示例并不详尽):
- 用于分发 JS 库的免费 CDN(MaxCDN、Google.Yandex)。
- 用于客户端优化的服务 CDN(例如,用于字体的 Google Fonts、用于图像的 Cloudinary、Cloudimage)。
- 用于 CMS 中的静态和资源优化的 CDN(可在 Bitrix、WordPress 等中使用)。
- 通用 CDN(StackPath、CDNVideo、NGENIX、Megafon)。
- 用于网站加速的 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覆盖了所有站点流量(第三方服务除外),那么我们可以使用单个TCP连接,从而节省连接到其他主机的延迟。 当然,这适用于 HTTP/2 连接。
进一步的差异取决于特定 CDN 的功能 - 对于第一种类型,它仅托管静态文件,对于第五种类型,它会出于优化的目的更改几种类型的网站内容。
CDN 网站加速能力
让我们描述用于加速站点的全方位 CDN 功能,而不考虑各个类型 CDN 的功能,然后看看每种 CDN 中实现了什么。
1.文本资源的压缩
这是最基本、最容易理解的功能,但往往实施得不好。 所有 CDN 都声明压缩作为其加速功能。 但如果你仔细观察,缺点就会变得很明显:
- 可以使用动态压缩的低度数 - 5-6(例如,对于 gzip,最大值为 9);
- 静态压缩(缓存中的文件)不使用附加功能(例如,等级为 11 的 zopfi 或 brotli)
- 不支持高效的 brotli 压缩(与 gzip 相比节省约 20%)。
如果您使用 CDN,则值得检查以下几点:获取来自 CDN 的文件,记录其压缩大小并手动压缩以进行比较(您可以使用一些支持 brotli 的在线服务,例如
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 提供了哪些潜在的加速机会。
为了方便起见,我们重复一下分类。
- 用于分发 JS 库的免费 CDN(MaxCDN、Google.Yandex)。
- 用于客户端优化的服务 CDN(例如,用于字体的 Google Fonts、用于图像的 Cloudinary、Cloudimage)。
- 用于 CMS 中的静态和资源优化的 CDN(可在 Bitrix、WordPress 等中使用)。
- 通用 CDN(StackPath、CDNVideo、NGENIX、Megafon)。
- 用于网站加速的 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