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 值并认为这样会很好。
阅读更多：
5. 让连接永远存活
当 CDN 需要从您的源服务器中提取内容时，两个服务器之间必须存在 TCP 连接。
理想情况下，该连接已经存在并且可以重复使用，从而节省了建立新的连接时的往返时间和宝贵的毫秒值。
CDN 或源可能会终止连接，您无法控制 CDN 保持连接存活的时间，但是您可以控制源上的 keep-alive 行为。
永远不要在源端关闭连接 - 担心许多 CDN 服务器与您的源点建立 TCP 连接并且该源无法处理该问题？设置一个 Origin shield。
6. 减少 TLS 连接时间
您有安全的 HTTPS 来源吗？如果是，可以执行几种优化来提高 CDN 性能。
举个例子：TLS 错误启动，TLS 会话恢复和 TLS 记录大小优化。
在开始使用这些 TLS 优化之前，请检查您的 CDN 是否需要其他方面的帮助，才能使这些优化生效。
进一步阅读：
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）压缩内容的标头。
分享这篇文章的原因：我认为原作者是一位网络性能优化大师，他本人的博客优化的非常棒。
同系列文章：
参考链接：