javascript - 为什么要将您的 Javascript 文件移至您也拥有的另一个主域？

Question

我注意到，就在去年左右，许多主要网站都对其页面结构方式进行了相同的更改。每个人都将其 Javascript 文件从托管在与页面本身相同的域(或其子域)上，转移到托管在不同名称的域上。

这不仅仅是并行化

现在，有一种众所周知的技术可以将页面的组件分布到多个域以并行下载。 Yahoo recommends it和其他许多人一样。例如，www.example.com 是 HTML 的托管位置，然后您将图像放在 images.example.com 上，将 javascript 放在 scripts.example.com 上。这回避了这样一个事实:大多数浏览器为了成为良好的网络公民而限制每台服务器的同时连接数。

以上内容不是我正在谈论的内容。

这不仅仅是重定向到内容交付网络(或者也许是 - 请参阅问题底部)

我所说的是在一个完全不同的域上专门托管 Javascript。让我具体说一下。就在过去一年左右的时间里，我注意到:

youtube.com 已将其 .JS 文件移至 ytimg.com

cnn.com 已将其 .JS 文件移至 cdn.turner.com

weather.com 已将其 .JS 文件移至 j.imwx.com

现在，我了解了内容交付网络，例如 Akamai他们专门为大型网站外包此服务。 (特纳特殊领域中的名称“cdn”让我们了解了这个概念的重要性)。

但请注意这些示例，每个站点都有自己专门为此目的注册的域，而不是内容交付网络或其他基础设施提供商的域。事实上，如果您尝试从大多数这些脚本域加载主页，它们通常会重定向回公司的主域。如果您反向查找所涉及的 IP，它们有时会指向 CDN 公司的服务器，有时则不会。

我为什么关心？

我以前曾在两家不同的安全公司工作过，因此对恶意 Javascript 产生了偏执。

因此，我遵循将网站列入白名单的做法，允许 Javascript(以及其他事件内容，例如 Java)在其上运行。因此，为了使像 cnn.com 这样的网站正常工作，我必须手动将 cnn.com 放入列表中。这是一种背后的痛苦，但我更喜欢它而不是其他选择。

当人们使用诸如 scripts.cnn.com 之类的东西来并行化时，通过适当的通配符可以很好地工作。当人们使用 CDN 公司域名之外的子域名时，我可以只允许 CDN 公司的主域名前面加上通配符，一箭多雕(例如 *.edgesuite.net 和 *.akamai.com)。

现在我发现(截至 2008 年)这还不够。现在我必须浏览我想要列入白名单的页面的源代码，并找出该网站用于存储其 Javascript 的“ secret ”域(或多个域)。在某些情况下，我发现我必须允许三个不同的域才能使网站正常运行。

为什么所有这些主要网站都开始这样做？

编辑:好的as "onebyone" pointed out ，它似乎确实与内容的 CDN 交付有关。所以让我根据他的研究稍微修改一下问题......

为什么weather.com使用j.imwx.com而不是twc.vo.llnwd.net？

为什么 youtube.com 使用 s.ytimg.com 而不是 static.cache.l.google.com？

这背后一定有一个理由。

Answer 1

您的后续问题本质上是:假设一个受欢迎的网站正在使用 CDN，为什么他们会使用自己的 TLD(例如 imwx.com)而不是子域 (static.weather.com) 或 CDN 的域？

嗯，使用他们控制的域而不是 CDN 域的原因是他们保留了控制权 - 他们甚至有可能完全更改 CDN，并且只需要更改 DNS 记录，而不是必须更新数千个页面中的链接/应用程序。

那么，为什么要使用无意义的域名呢？嗯，像 .js 和 .css 这样的帮助文件的一个大问题是，您希望代理和人们的浏览器尽可能地将它们缓存在下游。如果一个人访问 gmail.com 并且所有 .js 都从浏览器缓存中加载出来，那么该网站对他们来说显得更加快捷，并且还节省了服务器端的带宽(每个人都赢了)。问题是，一旦您发送 HTTP header 进行真正积极的缓存(即将我缓存一周、一年或永远)，这些文件就不再可靠地从服务器加载，并且您无法对其进行更改/修复因为人们的浏览器会出现问题。

因此，公司要做的就是分阶段进行这些更改，并实际更改所有这些文件的 URL，以迫使人们的浏览器重新加载它们。循环浏览“a.imwx.com”、“b.imwx.com”等域名就是实现这一点的方法。

通过使用无意义的域名，Javascript 开发人员及其 Javascript 系统管理员/CDN 联络人员可以拥有自己的域名/DNS，他们可以通过这些域名/DNS 来插入这些更改，并对其负责/自治。

然后，如果 TLD 上开始发生任何类型的 cookie 阻止或脚本阻止，它们只会从一个无意义的 TLD 更改为 kyxmlek.com 或其他内容。他们不必担心不小心做了一些邪恶的事情，从而对整个 *.google.com 产生反制副作用。