为什么 CDN 使用不同的域名而不是子域？

Question

许多在线服务将其网络配置为使用 CDN（内容交付网络），以通过允许从地理位置相近的位置提供内容来提高性能。我注意到，CDN 通常是从与实际服务不同的域名提供的。

例如，访问www.amazon.com将涉及从 media-amazon.com 提取内容。

www.facebook.com从 fbcdn.com 获取内容，等等。

我的问题是，为什么这些服务不为其 CDN 使用子域而不是完全不同的域名？

例如，为什么不使用 cdn.facebook.com 而不是 fbcdn.com？我很少看到这样做。它几乎总是一个不同的域名，通常是添加了一些内容或缩写的基本域名。

我唯一能想到的是，拥有不同的域名允许使用不同的 DNS 提供商来分散 DNS 负载，但情况并非总是如此。

这种做法是否有特定的技术原因？如果是这样，那是什么？

澄清：我不关心域名注册的成本。我假设任何广泛使用 CDN 的公司都能负担得起一些额外的域名。我的问题是，从技术角度来看，为什么使用子域不如使用单独的域。这种做法如此普遍的事实表明，这是有充分理由的。

Answer 1

虽然每个提供商都不同，并且做出相同选择的原因可能不同，但这样做的一个常见原因是Cookies。

如果您的网站使用 cookie，并且您的 cookie 可能需要用于多个子域，那么您最终将随每个 CDN 请求一起发送 cookie。这会导致两个问题：

1. 如果您有很多 cookie 和/或非常大的 cookie，您将显着扩大对 CDN 的每个请求，无缘无故地消耗宝贵的带宽（因为 CDN 为每个人提供相同的内容）。在 Google、Facebook、Amazon 等规模下，请求中的每个字节都很重要，因为数百万（甚至数十亿）个请求加起来很快。
2. 如果您的 cookie 包含用户数据，您可能不希望 CDN 能够看到该数据。如果您的 CDN 实际上完全或部分由第三方服务提供商托管，则尤其如此。不向 CDN 发送 cookie 可以消除一种可能的攻击用户数据的途径。

另一个常见原因是用户生成的内容。很好的例子是托管在 GitHub 存储库中的 Gmail 附件和代码。如果用户生成的内容托管在子域上，它可能能够保留来自 Cookie、LocalStorage 等的用户信息并将其发送给第三方。托管在不同的域上可以减轻这种形式的攻击。