性能优化小册 - 提升网页响应速度：优化你的 CDN 性能

1.使用高性能 DNS

CDN 服务自己并不具有域名解析功能，而是依托于 DNS 智能解析功能，由 DNS 根据用户所在地、所用线路进行智能分配最合适的 CDN 服务节点，而后把缓存在该服务节点的静态缓存内容返回给用户。

若是域名转换为 IP 这一过程可用性低且延迟高，那么确定会对 CDN 性能产生不良影响。

另外，请确保在 DNS 记录上使用较高的 TTL（生存时间），以便解析器能够长时间缓存记录。

2.将源点移到 CDN 附近

保持 CDN 与源之间的等待时间短暂，是 CDN 应对缓存未命中响应的有效的优化方法。

若是没法将源站点放在 CDN 附近，请考虑使用源防御（origin shield）。

Origin shield 是 CDN 和源之间的额外缓存层。origin shield 有助于减轻源点负担，它会在在源级别未来自多个 edge CDN 的传入请求折叠成一个请求，以加快缓存未命中响应的速度。

一个好的 origin shield 能够减小 70% 到 80% 的源负载，即便它前面有一个性能良好的 edge CDN。

3.具备 IPv6 链接

IPv6 能提升「网速」一般是指新建的 IPv6 网络一般具备更大的带宽（好比中国正在新建的 CERNET2 骨干网动辄 10Gbps、100Gbps 的链接带宽）、更好的流量控制、更少的 NAT 从而实现更高效的网络拓扑结构（IP 地址资源多从而不须要对数据包进行屡次地址翻译和转发）。在这些方面 IPv6 确实是能提升「网速」的。

Facebook 已经对 IPv6 对性能的影响进行了大量研究，并得出了积极的效果：

咱们已经观察到，与 IPv6 相比，访问 Facebook 的速度能够提升 10-15％。

4.调整您的 initcwnd

原始服务器上的初始拥塞窗口参数（initcwnd）的值可能为 10。这意味着服务器在第一次往返过程当中经过新链接发送了 10 个数据包。

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

一些 CDN 的 initcwnd 为 10，其余 CDN 的值则高得多。

重要提示：请勿「简单的」的增长服务器上的 initcwnd 值并认为这样会很好。

阅读更多：

• Initcwnd settings of major CDN providers
• Tuning initcwnd for optimum performance.

5. 让链接永远存活

当 CDN 须要从您的源服务器中提取内容时，两个服务器之间必须存在 TCP 链接。

理想状况下，该链接已经存在而且能够重复使用，从而节省了创建新的链接时的往返时间和宝贵的毫秒值。

CDN 或源可能会终止链接，您没法控制 CDN 保持链接存活的时间，可是您能够控制源上的 keep-alive 行为。

永远不要在源端关闭链接 - 担忧许多 CDN 服务器与您的源点创建 TCP 链接而且该源没法处理该问题？设置一个 Origin shield。

6. 减小 TLS 链接时间

您有安全的 HTTPS 来源吗？若是是，能够执行几种优化来提升 CDN 性能。

举个例子：TLS 错误启动，TLS 会话恢复和 TLS 记录大小优化。

在开始使用这些 TLS 优化以前，请检查您的 CDN 是否须要其余方面的帮助，才能使这些优化生效。

进一步阅读：

• TLS 快了吗？
• 针对 TLS 进行优化

7. 最小化字节大小

减小内容的字节大小或「权重」对于加快 CDN 性能很是有效。传输的字节越少，内容到达用户的速度就越快。

您能够经过多种方法来最小化字节大小以加强 CDN 性能，压缩是最有效且一般最容易实现的方法。

延伸阅读两篇减小字节大小的文章 minification 和 图像优化。

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 Caching | Web | Google Developers
• The essential guide to CDN: CDN Caching (Incapsula)
• CDN Guide: Serve stale

9. 启用条件请求 - 协商缓存

当 CDN 收到对过时对象的请求（在高速缓存中，但已过时）时，CDN 必须先联系源站点，而后再向用户发送响应。

若是缓存的对象具备Last-Modified / ETag 标头，则 CDN 能够经过添加 If-Modified-Since / If-None-Match 标头来有条件地发起请求，源站点能够决定以轻量级 304 非修改响应（只有标头响应），仍是以 200 OK 从新返回响应（标头和正文）。

推荐看本专栏这篇文章： 完全理解浏览器缓存机制。

显然，304 非修改响应的性能要优于 200 OK 响应，由于响应的大小要小得多，所以 CDN 与源之间的往返次数更少。

将原始服务器配置为始终发送 Last-Modified / ETag 标头，由于这大大有助于提升缓存的性能。

10. 注意 Vary 标头

你的源不该该向 CDN 提供带有诸如 Vary: Referer、Vary: User-Agent，Vary: Cookie 或 Vary: User-Agent,Cookie 标头，这些 Vary 标头对缓存命中率和 CDN 性能有很大的负面影响。

重点：

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

进一步阅读：使用 Vary 标头的最佳作法

分享这篇文章的缘由：我认为原做者是一位网络性能优化大师，他本人的 博客优化的很是棒。

同系列文章：

• 性能优化小册 - 异步堆栈追踪：为何 await 赛过 Promise
• 性能优化小册 - 分类构建：利用好 webpack hash

参考连接：

• 10 Tips to Optimize CDN Performance （本文主要内容来自此文）
• DNS 域名解析过程
• ipv6有什么好处_ipv4和ipv6哪一个网速快