为什么将Javascript文件移到我们拥有的其他主域中?

时间:2020-03-06 15:00:17  来源:igfitidea点击:

我注意到,仅在过去一年左右的时间里,许多主要网站对页面的结构进行了相同的更改。每个人都将其Javascript文件从与页面本身(或者页面的子域)托管在相同的域中迁移到了以不同名称命名的域中托管。

这不仅仅是并行化

现在,有一种众所周知的技术可以将页面的组件分布在多个域中,以并行下载。雅虎和其他许多公司一样推荐它。例如,www.example.com是托管HTML的位置,然后将图像放在images.example.com上,并将javascripts放在scripts.example.com上。这可以避免以下事实:大多数浏览器都限制每个服务器的同时连接数,以便成为良好的网络公民。

以上不是我在说什么。

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

我所说的是专门在完全不同的域上托管Java脚本。让我具体一点。就在去年左右,我注意到了:

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。在某些情况下,我发现我必须允许三个不同的域才能使站点正常工作。

为什么所有这些主要站点都开始这样做?

编辑:正如" onebyone"指出的那样,它似乎与CDN内容传递有关。因此,让我根据他的研究来稍微修改这个问题。

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

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

这背后必须有一个推理。

解决方案

限制Cookie流量?

在特定域上设置cookie后,对该域的每个请求都将把cookie发送回服务器。每一个要求!

那可以很快加起来。

我们不仅可以将JavaScript移到不同的域,还可以使用尽可能多的资产来提高性能。

大多数浏览器都限制了我们可以与单个域建立的同时连接的数量(我认为大约为4个),因此,当我们拥有大量图像,js,css等时,下载每个文件时经常会遇到麻烦。

我们可以使用YSlow和FireBug之类的东西查看从服务器下载每个文件的时间。

通过在单独的域上拥有资产,可以减轻主服务器上的负载,并可以在任何给定时间建立更多同时连接并下载更多文件。

我们最近启动了一个房地产网站,其中包含很多图像(房屋,duh:P),使用此原理来处理图像,因此列出数据的速度大大提高。

我们还在许多其他拥有大量资产的网站上使用了此功能。

我想你回答了自己的问题。

我相信问题与安全相关,而不是原因。

也许是为了描述问题页面的有效CDN而添加了一个新的META标签,然后我们所需要的只是一个浏览器插件来读取它们并相应地表现。

我认为CDN理论中有一些内容:

例如:

$ host j.imwx.com
j.imwx.com              CNAME   twc.vo.llnwd.net
twc.vo.llnwd.net        A       87.248.211.218
twc.vo.llnwd.net        A       87.248.211.219
$ whois llnwd.net
<snip ...>
Registrant:
  Limelight Networks Inc.
  2220 W. 14th Street
  Tempe, Arizona 85281-6945
  United States

Limelight是CDN。

同时:

$ host s.ytimg.com
s.ytimg.com             CNAME   static.cache.l.google.com
static.cache.l.google.com       A       74.125.100.97

我猜这是Google内部运行的静态内容的CDN。

$ host cdn.turner.com
cdn.turner.com A record currently not present

嗯,不能全部赢。

顺便说一句,如果我们将Firefox与NoScript加载项一起使用,则它将自动执行源搜索和GUI-fy白名单搜索过程。基本上,单击状态栏中的NoScript图标,将为我们提供一个域列表,其中包含临时或者永久列入白名单的选项,包括"此页面上的全部"。

是因为垃圾邮件和内容过滤器阻止了行为吗?如果他们使用怪异的域名,那么就很难弄清楚和/或者我们最终将阻止我们想要的东西。

邓诺,只是一个想法。

如果我是一家知名的多品牌公司,我认为这种方法很有意义,因为我们希望将javascript代码作为库使用。我希望在处理地址,州名,邮政编码等方面使尽可能多的页面保持一致。 AJAX可能使这种担忧突出。

在当前的互联网业务模型中,域名是品牌,而不是网络名称。如果我们购买或者剥离了一些品牌,最终将导致很多域名变更。即使是最著名的站点,这也是一个问题。

仍然有指向* .netscape.com和* .mcom.com中有用的文档的链接,这些文档早已不复存在。

Wikipedia for Netscape表示:

"On October 12, 2004, the popular developer website Netscape DevEdge was shut down by AOL. DevEdge was an important resource for Internet-related technologies, maintaining definitive documentation on the Netscape browser, documentation on associated technologies like HTML and JavaScript, and popular articles written by industry and technology leaders such as Danny Goodman. Some content from DevEdge has been republished at the Mozilla website."

因此,这将是在不到十年的时间内:

  • 马赛克通讯公司
  • 网景通讯公司
  • 美国在线
  • 美国在线时代华纳
  • 时代华纳

如果将代码放在不是商标名称的域中,则可以保留很大的灵活性,并且在重新命名网站时不必重构所有入口点,访问控制和代码引用。

原因很多:

CDN不同的dns名称使将静态资产转移到内容分发网络变得更加容易

并行图像,样式表和静态javascript正在使用其他两个连接,这些连接不会阻止其他请求,例如ajax回调或者动态图像

Cookie流量完全正确,特别是对于那些习惯在cookie中存储比简单会话ID还要多的网站的情况

即使没有CDN,也可以进行负载整形,仍然有充分的理由将静态资产托管在较少的经过优化的Web服务器上,以优化地对大量文件url请求进行快速响应,而站点的其余部分托管在大量响应更多处理器密集型动态请求

更新两个我们不使用CDN的dns名称的原因。客户端dns名称充当CDN正在缓存的资产的正确"配置单元"的密钥。另外,由于CDN是一项商品服务,因此我们可以通过更改dns记录来更改提供者,从而避免在站点上进行任何页面更改,重新配置或者重新部署。

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

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

那么,为什么要使用废话域名呢?好的,使用.js和.css这样的帮助程序文件的一件大事是,我们希望它们被代理和人们的浏览器尽可能多地缓存到下游。如果某个人访问了gmail.com,并且所有.js都从他们的浏览器缓存中加载出来,则该站点对他们而言似乎更加敏捷,并且还节省了服务器端的带宽(每个人都赢了)。问题是,一旦我们发送了HTTP标头进行真正的主动缓存(即,将我缓存了一周,一年或者永远),这些文件就再也无法从服务器可靠地加载了,并且我们无法对它进行更改/修复。它们,因为事情会在人们的浏览器中中断。

因此,公司要做的是进行这些更改,并实际上更改所有这些文件的URL,以迫使人们的浏览器重新加载它们。如何完成" a.imwx.com"," b.imwx.com"等域名的循环。

通过使用无意义的域名,Javascript开发人员及其Javascript sysadmin / CDN联络对等方可以拥有自己的域名/ DNS,以推动这些变更,并负责/自主。

然后,如果在该TLD上开始发生任何类型的cookie阻止或者脚本阻止,则它们将从一个无意义的TLD更改为kyxmlek.com或者其他。他们不必担心会意外地做一些对* .google.com都具有反措施副作用的邪恶行为。

我曾与一家从事此工作的公司合作。它们位于具有相当好的对等关系的数据中心中,因此CDN推理对他们而言并不那么重要(也许会有所帮助,但出于这个原因他们不这样做)。其原因是,它们并行运行多个Web服务器,共同处理其动态页面(PHP脚本),并且它们在单独的域之外提供图像和一些javascript,并在该域上使用例如lighttpd或者thttpd的快速,轻量级的web服务器来提供服务。图片和静态javascript。

PHP需要PHP。静态Javascript和图像则没有。当我们需要做的是绝对最低限度的工作时,可以从功能齐全的Web服务器上剥离很多东西。

当然,他们可能使用代理将请求重定向到特定子目录到另一台服务器,但是使用另一台服务器处理所有静态内容会更容易。

大约两到三年前,我在以前的雇主那里实施了该解决方案,当时由于旧版Web服务器的实施,网站开始变得超载。通过将CSS和布局图像移到Apache服务器上,我们减少了主服务器上的负载并提高了速度。

但是,我一直给人的印象是,只能从与页面本身相同的域中访问Javascript函数。较新的网站似乎没有此限制:正如我们提到的,许多网站在单独的子域上甚至完全完全分离的域中都有Javascript文件。

在几年前还没有人给我指出为什么现在有这种可能吗?