【问题标题】:Is there a benefit to NOT using a public CDN to load Javascript libraries?不使用公共 CDN 加载 Javascript 库有什么好处吗?
【发布时间】:2011-09-07 21:42:12
【问题描述】:

我听说过所有支持使用像 Google APIs 这样的 CDN 来为我的 Web 应用程序托管 JQuery 和 Prototype 等 JavaScript 库的案例。它更快、节省带宽、允许并行加载脚本等等。但我最近在 Douglas Crockford 的 json2.js 脚本中看到了以下评论:

使用您自己的副本。从不受您控制的服务器上加载代码是非常不明智的。

我很好奇他的论点可能在这个断言背后,以及它是否专门针对像谷歌这样的公共 CDN 的用户,还是其他什么?

【问题讨论】:

  • 谷歌宕机了。 jQuery 打破了一半的网络。最好的一天。单点故障越多,失败的可能性就越大。
  • 使用像 Google API 这样的 CDN 和来自不可靠来源的东西有很大的不同。该 JavaScript 的宿主可以随时更改脚本的内容,例如开始向您的网站用户传播恶意软件。当然,这种事情不会(希望)发生在更受信任和可靠的服务(如 Google API)上。此外,如果由于某种原因远程托管脚本不可用,它可能会破坏您网站上的整个功能。您确实需要小心链接脚本的位置。

标签: javascript cdn google-cdn


【解决方案1】:

假设他说的是像 Google 这样的专业托管 CDN,那么最好的选择是这样做:

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if necessary -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>
<script>window.jQuery || document.write("<script src='js/libs/jquery-1.5.1.min.js'>\x3C/script>")</script>

(取自http://html5boilerplate.com/

这样,您就可以获得所有好处,而且如果 Google 的 CDN 出现故障,您的网站也不会有崩溃的风险。

但是,他说:

使用您自己的副本。这是非常 不明智地从您的服务器加载代码 不要控制。

我实际上并不认为他在谈论 CDN。我认为他只是在说“不要从随机网站盗链脚本”。

您不希望这样做,因为网站可能会更改脚本所在的位置,甚至更改脚本。 CDN 永远不会这样做。

【讨论】:

  • 回退是一种很好的技术,但只能保护您免受使用您无法控制的服务器的危险之一。您仍然有可能会提供受损或损坏的脚本。
【解决方案2】:

基本上,这是一个信任问题。您需要信任主机不会更改托管文件中的任何内容,并且您需要信任文件的可用性。你能绝对确定 URL 不会改变吗?您对他们的服务器的任何停机都会导致您的应用程序停机这一事实感到满意吗?

【讨论】:

    【解决方案3】:

    原因是,如果您所依赖的服务器出现故障,而您的服务器却没有。您的网站体验会受到影响。有一些方法可以设置回退,因此如果 jquery 或其他脚本没有加载,那么您可以使用您托管的副本作为备份。

    您不应该使用它的其他时间是在 Intranet 应用程序场景中,带宽通常不是问题。

    一种从 Jon Galloway 创建后备的方法:http://weblogs.asp.net/jgalloway/archive/2010/01/21/using-cdn-hosted-jquery-with-a-local-fall-back-copy.aspx

    <script type="text/javascript" src="http://ajax.microsoft.com/ajax/jquery/jquery-1.3.2.min.js"></script>
    <script type="text/javascript">
    if (typeof jQuery == 'undefined')
    {
        document.write(unescape("%3Cscript src='/Scripts/jquery-1.3.2.min.js' type='text/javascript'%3E%3C/script%3E"));
    }
    </script>
    

    【讨论】:

      【解决方案4】:

      如果公共服务器的 js 受到威胁(可用性、安全性或错误),那么您网站的访问者将受到影响并可能会责怪您。另一方面,谷歌的 CDN 被一些小公司的服务器入侵的可能性有多大?当您在本地托管时,您也会失去 CDN 为您提供的所有缓存优势。

      【讨论】:

        【解决方案5】:

        jQuery 是开源的。如果您对内部进行了修改,那么显然您无法托管其他人的服务器。一般来说,托管其他人的脚本是一种安全风险;他们可以在不告诉您的情况下更改脚本,现在您将其链接到您的页面上。

        这是一个信任问题;您是否相信任何 CDN 都不会在您想要的脚本位置托管恶意脚本?

        【讨论】:

          【解决方案6】:

          虽然其中一些其他答案肯定是有效的,但我们有一个稍微不同/额外的原因。

          我们有一个流程,可根据第一次请求确定任何给定页面需要哪些静态内容。在后台,此静态内容(js、css)被合并并缩小为单个文件(JS 为 1 个,CSS 为 1 个),然后所有未来的请求都使用单个文件而不是多个文件提供服务。

          虽然理论上我们可以排除可能在 CDN 上提供的文件并将 CDN 用于这些文件,但实际上它更容易(因为我们实际上必须添加代码来处理排除)和在某些情况下,比使用 CDN 更快。

          【讨论】:

            【解决方案7】:

            除了所有其他答案:

            您想担心通过 SSL(即 https)提供您的页面,但您的 JS 通过来自不同来源的直接 http 提供服务。浏览器可能会抱怨(有时以令人震惊的方式)关于安全和不安全的项目。

            此外,使用 noscript 扩展(或类似扩展)浏览的人需要允许 JS 从多个不同的源运行。如果您使用主要的 CDN,这没什么大不了的(因为他们可能在过去的某个时候允许这样做),但是您需要担心他们只允许您的部分 JS。

            【讨论】:

            • 我之前肯定遇到过那个烦人的 SSL 问题。幸运的是,谷歌现在在他们的 CDN 上使用了 https。
            • 我见过的所有公共CDN(bootcdn.cn除外)都支持https。
            【解决方案8】:

            现代答案:是的,可用性

            其他人的服务器(无论是公共 CDN 还是一些随机的不起眼的网站)可能会出现故障,从而破坏您应用的可用性。

            CDN 也可能受到威胁,导致您的应用执行有害代码,但可以通过子资源完整性 (SRI) 缓解此问题。

            如果您将它托管在您自己控制的服务器上,它会在您的整个应用程序变得不可用的同时变得不可用,而不是在其他人控制的某个任意时间。

            使用公共 CDN 需要权衡取舍,在某些情况下可能值得(例如,节省带宽)。

            <!-- best -->
            <script src="your_own_server/framework.js"></script>
            
            <!-- second-best (using public CDN) -->
            <script src="https://public-cdn.example/framework.js">
                    integrity="sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
                    crossorigin="anonymous"></script>
            
            <!-- do not use -->
            <script src="https://random-server-without-cors.example/framework.js"></script>
            

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 1970-01-01
              • 2015-07-07
              • 2012-02-15
              • 1970-01-01
              • 2011-04-24
              • 2011-10-29
              • 1970-01-01
              • 2014-10-26
              相关资源
              最近更新 更多