不使用公共 CDN 加载 Javascript 库有什么好处吗?

发布于 2024-11-13 09:36:14 字数 452 浏览 8 评论 0原文

我听说过所有支持使用 CDN(例如 Google API)来托管 JavaScript 库的案例就像我的 Web 应用程序的 JQuery 和 Prototype 一样。它速度更快、节省带宽、允许并行加载脚本等等。但我最近在 Douglas Crockford 的 json2.js 脚本:

使用您自己的副本。从您无法控制的服务器加载代码是极其不明智的。

我很好奇他这一说法背后的论点是什么,以及它是否专门针对像 Google 这样的公共 CDN 用户,或者其他什么?

I've heard all the cases in favour of using a CDN like Google APIs to host JavaScript libraries like JQuery and Prototype for my web application. It's faster, saves bandwidth, permits parallel loading of scripts, and so on. But I recently came across the following comment in Douglas Crockford's json2.js script:

USE YOUR OWN COPY. IT IS EXTREMELY UNWISE TO LOAD CODE FROM SERVERS YOU DO NOT CONTROL.

I'm curious what his argument might be behind this assertion, and whether it's specifically targeted at users of public CDNs like Google's, or something else?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

空袭的梦i 2024-11-20 09:36:14

假设他谈论的是像 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 永远不会这样做。

Assuming he's talking about professionally hosted CDNs like Google, then the best bet is to do this:

<!-- 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>

(taken from http://html5boilerplate.com/)

That way, you get all the benefits, without the risk of your website breaking if Google's CDN goes down.

But, he said:

USE YOUR OWN COPY. IT IS EXTREMELY
UNWISE TO LOAD CODE FROM SERVERS YOU
DO NOT CONTROL.

I don't actually think he's talking about CDNs. I think he's just saying "don't hotlink scripts from random websites".

You wouldn't want to do this because the website might change where the script is located, or even change the script. A CDN would never do this.

梦毁影碎の 2024-11-20 09:36:14

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

Basically, it's a matter of trust. You need to trust the host to not change anything in the hosted file and you need to trust in the availability of the file. Can you be absolutely sure that the URL will not change? Are you comfortable with the fact that any downtime of their servers results in downtime of your application?

稍尽春風 2024-11-20 09:36:14

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

另一种不应该使用它的情况是在内联网应用场景中,带宽通常不是问题。

Jon Galloway 创建后备的方法: http://weblogs.asp.net/jgalloway/archive/2010/01/21/using-cdn-hosted-jquery-with-a-local-fall-back -复制.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>

The reason is, if the server you are dependent on goes down, and yours doesn't. The experience of your site suffers. There are ways to have a fallback in place so if jquery or some other script doesn't load, then you can use a copy you host as a backup.

The other time you shouldn't use it is in a Intranet application scenario, where the bandwidth is not typically an issue.

A way to create a fallback from 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>
百思不得你姐 2024-11-20 09:36:14

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

If a public server's js is compromised (availability, security or bug-wise), then the visitors to your site will be affected and likely blame you. On the other hand, what are the chances of Google's CDN being compromised over the chances of some smaller company's server? You also lose out on all the caching advantages that a CDN gives you when you host locally.

影子是时光的心 2024-11-20 09:36:14

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

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

jQuery is open source. If you've made a modification to the internals, then obviously you can't host off another person's server. In general, hosting other people's scripts is a security risk; they could change the script without ever telling you, and now you're linking it onto your pages.

It's a matter of trust; do you trust that whatever CDN will be secure to not host a malicious script in the location of the script you want?

后知后觉 2024-11-20 09:36:14

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

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

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

While some of these other answers are certainly valid, we have a slightly different/additional reason.

We have a process that determines, on first request, evaluates which static content is required for any given page. In the background, this static content (js, css) is merged and minified into a single file (1 for JS, 1 for CSS), and then all future requests are served with a single file, instead of multiple.

While we could, theoretically, exclude files that may be served on a CDN and use the CDN for those, it's actually easier (because we'd actually have to add code to handle exclusions) and in some cases, faster than using a CDN.

满天都是小星星 2024-11-20 09:36:14

除了所有其他答案之外:

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

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

In addition to all the other answers:

You want to worry about serving your pages over SSL (i.e. https) but your JS over straight http from a different source. Browsers can complain (sometimes in an alarming way) about secured and unsecured items.

In addition, people browsing with the noscript extension (or similar) need to allow JS to run from multiple different sources. Not that big a deal if you are using a major CDN (as chances are they'll have allowed it at some point in the past) but you then need to worry that they are allowing only SOME of your JS.

夏有森光若流苏 2024-11-20 09:36:14

现代答案:是的,可用性

其他人的服务器(无论是公共 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>

Modern answer: yes, availability

Other people's servers (regardless of a public CDN or some random nondescript site) might go down, breaking your app's availability.

The CDN might also be compromised, causing your app to execute harmful code, but this issue can be mitigated with Subresource Integrity (SRI).

If you host it on your own server that you control, it would become unavailable at the same time your entire app becomes unavailable, rather than at some arbitrary time under someone else's control.

Using a public CDN has tradeoffs and might be worth it in some cases (for example, to save bandwidth).

<!-- 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>
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文