优化CDN性能的10个技巧

在大多数情况下,您的CDN负责内容交付的性能。CDN控制其网络,负载平衡器,缓存服务器以及从边缘向用户交付内容所涉及的所有其他方面。

那么,您如何才能为出色的内容交付性能做出贡献呢?

阅读我们的10条技巧,以优化CDN性能。

1.使用高性能DNS
想象一下,您正在static.example.orgCDN上使用它origin.example.org作为您的来源。如果权威DNS的example.org可用性低且延迟高,那么这肯定会对CDN性能产生不良影响。

不要仅仅因为包含在交易中就使用托管服务提供商的DNS服务。使用来自AWS,NS1,Cloudflare,Google或Azure的提供商的高性能,全局选播DNS既容易又便宜。

另外,请确保在DNS记录上使用较高的TTL(生存时间),以便解析器可以长时间缓存记录。

2.将原点移到CDN附近
如果您的大多数用户都在亚洲,则不要将您的原籍放置在遥远的位置(如阿姆斯特丹或纽约),而应放置在...亚洲。

保持CDN与源之间的等待时间很短是优化CDN性能以应对缓存未命中响应的有效方法。
如果您无法将原点放在CDN附近,请考虑使用原点屏蔽。源防护是CDN边缘服务器和源之间的额外缓存层。防护罩有助于减轻您的来源负担,并加快缓存未命中响应的速度。阅读我们的CDN指南:起源屏蔽以了解更多信息,并找出哪些CDN提供起源屏蔽。

3.具有IPv6连接
Facebook已经对IPv6对性能的影响进行了大量研究,并得出了积极的效果:

我们已经观察到,与IPv6相比,访问Facebook的速度可以提高10-15%。
您的CDN可以通过IPv6连接到您的来源吗?如果是,请考虑将您的来源转移到启用IPv6的托管环境。
AWS S3支持IPv6。不幸的是,Google Compute Engine当前不支持IPv6。

进一步阅读:
IPv6:是时候入职了(Facebook)
Facebook新闻提要通过IPv6加载速度提高20-40%
4.调整您的initcwnd
原始服务器上的初始拥塞窗口参数(initcwnd)的值可能为10。这意味着服务器在第一次往返过程中通过新连接发送了10个数据包。

值10不错,但是更高的initcwnd可能会对TCP性能产生明显的积极影响,从而导致源和CDN之间的内容传输更快。

一些CDN的initcwnd为10,其他CDN的价值则高得多。阅读更多:主要CDN提供程序的Initcwnd设置。

使用我们的Initcwnd Checker工具检查您当前的initcwnd。

重要提示:请勿“简单地”增加服务器上的initcwnd并认为这样会很好。可能不会。一个很好的起点是博客文章Tuning initcwnd,以获得最佳性能。

5.让连接永远活着
当CDN需要从您的来源中提取内容时,两个服务器之间必须存在TCP连接。理想情况下,该连接已经存在并且可以重复使用,从而节省了往返时间和宝贵的毫秒,从而可以建立新的连接。

CDN或源可能会终止连接。您无法控制CDN保持连接存活的时间,但是您可以控制源上的keep-alive行为。

永远不要在源端关闭连接。
担心许多CDN服务器与您的来源建立TCP连接并且该来源无法处理该问题?设置一个Origin盾牌。

6.减少TLS连接时间
您有安全的HTTPS来源吗?如果是,可以执行几种优化来提高CDN性能。仅举几例:TLS错误启动,TLS会话恢复和TLS记录大小优化。

在开始使用这些TLS优化之前,请询问您的CDN是否需要任何方面的帮助才能使这些优化生效。

进一步阅读:
TLS快了吗?
针对TLS进行优化
7.最小化字节大小
减少内容的字节大小或“权重”对于提高内容交付性能非常有效。导线上的字节越少,内容到达用户的速度就越快。

您可以通过多种方法来最小化字节大小以增强CDN性能压缩是最有效且通常最容易实现的方法。阅读我们的CDN指南:压缩以了解有关Gzip,Brotli以及应压缩提供哪些内容类型的更多信息。Google Developers网站上有一篇很好的深度文章,介绍了使用GZIP进行文本压缩。

减小字节大小的另外两种技术是最小化和图像优化。

8.成为缓存控制大师
如何使CDN尽可能长时间地缓存对象并最大化缓存命中率?
开箱即用,大多数或所有CDN都将遵循源服务器通过Cache-Control标头发送的缓存指令。这是提高CDN性能的非常有效的工具。

一些例子:

Cache-Control: max-age=86400 告诉CDN和浏览器该对象可能被缓存86400秒。

Cache-Control: max-age=3600, s-maxage=86400通知CDN它可能将对象缓存24小时,而浏览器应将对象缓存不超过1小时。注意:s-maxage默认情况下,并非所有CDN都支持。

Cache-Control: max-age=86400, stale-while-revalidate=300 指示CDN和浏览器将对象缓存24小时,然后在这24小时结束时,当从原始位置获取新内容时,CDN可以提供陈旧的响应长达300秒。

了解有关缓存控制的更多信息:
HTTP缓存| 网页| Google开发人员
CDN基本指南:CDN缓存(封装)
CDN指南:过时
9.启用条件请求
当CDN收到对过期对象的请求(在高速缓存中,但已过期)时,CDN必须先联系来源,然后再向用户发送响应。如果缓存的对象具有Last-Modified和/或ETag标头,则CDN可以通过添加If-Modified-Since和/或If-None-Match标头使对源的请求有条件。源可以决定以轻量级304 Not Modified响应(仅标头)200 OK响应还是发送重度响应(标头和正文)。

显然,304 Not Modified响应的性能要优于200 OK响应,因为响应的大小要小得多,因此CDN与源之间的往返次数更少。

将原始服务器配置为始终发送Last-Modified和和/或ETag标头,因为这大大有助于提高缓存未命中的性能。

10.注意Vary标头
你的出身不应该成为对象的CDN一个头像Vary: Referer,Vary: User-Agent,Vary: Cookie或Vary: User-Agent, Cookie。这些Vary标头对缓存命中率和CDN性能有很大的负面影响。

您的来源是否无意发送了这些Vary标头?删除它们!

重要:
永远不要使用Vary: *。具有该标头的对象将永远不会存储在CDN缓存中
始终发送Vary: Accept-Encoding带有(Gzip)压缩内容的标头