Javascriptファイルを自分が所有する別のメインドメインに移動する理由は何ですか?
-
03-07-2019 - |
質問
去年かそこらで、多くの主要なWebサイトがページの構造に同じ変更を加えたことに気付きました。それぞれがJavascriptファイルを、ページ自体と同じドメイン(またはそのサブドメイン)でホストされているものから、別の名前のドメインでホストされているものに移動しました。
単なる並列化ではありません
現在、ページのコンポーネントを複数のドメインに分散してダウンロードを並列化するよく知られた手法があります。 Yahooは、他の多くの人と同様にそれを推奨しています。たとえば、 www.example.com はHTMLがホストされている場所です。次に、 images.example.com に画像を置き、 scripts.example.comにJavaScriptを置きます。これは、ほとんどのブラウザが良きネット市民になるために、サーバーごとの同時接続の数を制限するという事実を回避します。
上記は、私が話していることではありません 。
コンテンツ配信ネットワークへの単なるリダイレクトではありません(または、そうである可能性があります-質問の下部を参照)
私が話しているのは、完全に異なるドメインでJavascriptをホストすることです。具体的にさせてください。ちょうど去年かそこらで私はそれに気づいた:
youtube.com は.JSファイルを ytimg.com
に移動しましたcnn.com は.JSファイルを cdn.turner.com
に移動しましたweather.com は.JSファイルを j.imwx.com
に移動しました今、 Akamai のような大規模なWebサイト向けのアウトソーシングを専門とするコンテンツ配信ネットワークについて知っています。 (ターナーの特別なドメインの「cdn」という名前は、ここでこの概念の重要性を示しています。)
ただし、これらの例では、各サイトにはこの目的のために専用に登録されたドメインがあり、コンテンツ配信ネットワークやその他のインフラストラクチャプロバイダーのドメインではありません。実際、これらのスクリプトドメインのほとんどからホームページをロードしようとすると、通常は会社のメインドメインにリダイレクトされます。また、関連するIPを逆引きすると、それらはCDN会社のサーバーを指しているように見える場合があります。
なぜ気にするのですか?
以前は2つの異なるセキュリティ会社で働いていたので、悪意のあるJavascriptに執着しました。
その結果、Javascript(およびJavaなどの他のアクティブコンテンツ)の実行を許可するサイトをホワイトリストに登録する慣習に従います。その結果、 cnn.com のようなサイトを適切に機能させるには、 cnn.com を手動でリストに追加する必要があります。背後にある苦痛ですが、私は他の方法よりもそれを好みます。
人々が scripts.cnn.com のようなものを使用して並列化した場合、適切なワイルドカードを使用して正常に機能しました。そして、人々がCDN企業ドメインのサブドメインを使用した場合、CDN企業のメインドメインの前にワイルドカードも許可し、1石で多くの鳥を殺すことができました(* .edgesuite.netや* .akamai.comなど)。
今(2008年現在)、これでは十分ではないことがわかりました。次に、ホワイトリストに登録するページのソースコードを調べて、「秘密」とは何かを把握する必要があります。サイトがJavascriptを保存するために使用しているドメイン。場合によっては、サイトを機能させるために3つの異なるドメインを許可する必要があります。
これらの主要なサイトすべてがこれを始めたのはなぜですか?
編集:OK 「onebyone」として指摘、それはコンテンツのCDN配信に関連しているようです。そこで、彼の研究に基づいて質問を少し修正してみましょう...
なぜ weather.coなのか
解決
フォローアップの質問は基本的に、人気のあるWebサイトがCDNを使用している場合、サブドメイン(static.weather.com)またはCDNのドメインの代わりにimwx.comのような独自のTLDを使用するのはなぜですか?
まあ、彼らがコントロールするドメインをCDNのドメインと比較して使用する理由は、彼らがコントロールを保持していることです-彼らは潜在的にCDNを完全に変更することさえでき、DNSレコードを変更するだけですアプリケーション。
では、なぜナンセンスなドメイン名を使用するのですか?さて、.jsや.cssのようなヘルパーファイルの大きな利点は、プロキシと人々のブラウザによって可能な限り下流にキャッシュされることです。ユーザーがgmail.comをヒットし、すべての.jsがブラウザーキャッシュからロードされると、サイトはそれらに非常にすばやく表示され、サーバー側の帯域幅も節約されます(全員が勝ちます)。問題は、非常に積極的なキャッシュのためにHTTPヘッダーを送信すると(つまり、1週間、1年、または永久にキャッシュする)、これらのファイルはサーバーから確実にロードされなくなり、変更や修正を行えなくなることです。人々のブラウザで物事が壊れるからです。
したがって、企業がしなければならないのは、これらの変更を段階的に行い、実際にこれらすべてのファイルのURLを変更して、人々のブラウザーに強制的にリロードさせることです。 「a.imwx.com」、「b.imwx.com」などのドメインを切り替えるなどがこれを行う方法です。
ナンセンスなドメイン名を使用することにより、Javascript開発者とそのJavascript sysadmin / CDNリエゾンの対応者は、これらの変更をプッシュし、説明責任/自律性を持つ独自のドメイン名/ DNSを持つことができます。
その後、TLDで何らかの種類のCookieブロッキングまたはスクリプトブロッキングが開始された場合、それらは1つのナンセンスTLDからkyxmlek.comなどに変更されます。彼らは、*。google.comのすべてに対抗措置の副作用をもたらす悪事を誤って実行することを心配する必要はありません。
他のヒント
Cookieトラフィックを制限しますか?
特定のドメインでCookieが設定されると、そのドメインへのすべてのリクエストでCookieがサーバーに返送されます。すべてのリクエスト!
それはすぐに追加できます。
多くの理由:
CDN-異なるDNS名により、静的アセットをコンテンツ配信ネットワークに簡単に移行できます
並列性-画像、スタイルシート、静的javascriptは、ajaxコールバックや動的画像など、他のリクエストをブロックしない他の2つの接続を使用しています
Cookieのトラフィック-正確に正しい-特にCookieに単純なセッションIDよりもはるかに多くを保存する習慣があるサイトの場合
負荷シェーピング-CDNがなくても、膨大な数のファイルURLリクエストに非常に迅速に応答するように最適化された少数のWebサーバーで静的アセットをホストする十分な理由があります。よりプロセッサを集中的に使用する動的リクエストに応答するサーバーの数
更新-CDNのDNS名を使用しない2つの理由。クライアントのDNS名は、適切な「ハイブ」のキーとして機能します。 CDNがキャッシュしているアセットの。また、CDNはコモディティサービスであるため、dnsレコードを変更することでプロバイダーを変更できます。したがって、サイトでのページの変更、再構成、または再デプロイメントを回避できます。
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で実行されます。基本的に、ステータスバーのNoScriptアイコンをクリックすると、「このページのすべて」など、一時的または永続的にホワイトリストに登録するオプションのあるドメインのリストが表示されます。
このソリューションを実装したのは、約2〜3年前、以前の雇用者で、WebサイトがレガシーWebサーバーの実装により過負荷になり始めたときです。 CSSとレイアウトの画像をApacheサーバーに移動することで、メインサーバーの負荷を減らし、終わりのない速度を向上させました。
ただし、Javascript関数にはページ自体と同じドメイン内からしかアクセスできないという印象を受けていました。新しいウェブサイトにはこの制限はないようです:言及したように、多くの場合、Javascriptファイルは別々のサブドメインまたは完全に切り離されたドメインにあります。
数年前ではなかったのに、なぜこれが可能になったのかについて、誰にも教えてもらえますか?
異なるドメインに移動できるのはjavascriptだけではなく、できるだけ多くのアセットでパフォーマンスが向上します。
ほとんどのブラウザでは、1つのドメインに同時接続できる数に制限があります(4前後だと思います)。したがって、多くの画像、js、cssなどがある場合、各ファイルのダウンロードに耐えることがよくあります。 。
YSlowやFireBugなどを使用して、各ファイルがサーバーからダウンロードされるタイミングを表示できます。
別々のドメインにアセットを配置することにより、プライマリの負荷を軽減し、より同時接続を確立し、いつでもより多くのファイルをダウンロードできます。
最近、この原則を画像に使用する(家の、Duh:P)多数の画像を含む不動産ウェブサイトを立ち上げました。そのため、データを一覧表示する方がはるかに高速です。
これは、資産の量が多い他の多くのWebサイトでも使用しています。
あなたはあなた自身の質問に答えたと思います。
あなたの問題は、なぜではなく、セキュリティに関連していると思います。
問題のページの有効なCDNを記述するための新しいMETAタグがおそらく必要な場合、必要なのはそれらを読み取り、それに応じて動作するブラウザーアドオンだけです。
スパムおよびコンテンツフィルターによるブロックが原因ですか?奇妙なドメインを使用している場合、把握するのが難しくなり、必要なものをブロックすることになります。
Dunno、ただの考え。
私が有名なマルチブランド企業であれば、JavaScriptコードをライブラリとして利用できるようにしたいので、このアプローチは理にかなっていると思います。アドレス、州名、郵便番号などの処理において、できるだけ多くのページの一貫性を保ちたいです。 AJAXはおそらくこの懸念を際立たせます。
現在のインターネットビジネスモデルでは、ドメインはブランドであり、ネットワーク名ではありません。ブランドを購入またはスピンオフすると、多くのドメインの変更が発生します。これは最も有名なサイトでさえ問題です。
*。netscape.comおよび* .mcom.comには、古くなった有用なドキュメントを指すリンクがまだあります。
&quot; 2004年10月12日、人気の開発者向けWebサイトNetscape DevEdgeがAOLによって閉鎖されました。 DevEdgeは、インターネット関連テクノロジーの重要なリソースであり、Netscapeブラウザーに関する明確なドキュメント、HTMLやJavaScriptなどの関連テクノロジーに関するドキュメント、および業界やDanny Goodmanなどのテクノロジーリーダーによって書かれた人気のある記事を管理しています。 DevEdgeの一部のコンテンツは、Mozilla Webサイトで再公開されました。&quot;
つまり、10年以内に:
- Mosaic Communications Corporation
- Netscape Communications Corporation
- AOL
- AOLタイムワーナー
- タイムワーナー
コードをブランド名ではないドメインに配置すると、柔軟性が非常に高くなり、Webサイトがリネームされるときにすべてのエントリポイント、アクセス制御、コード参照をリファクタリングする必要がなくなります。名前付き。
私はこれを行っている会社で働いています。彼らはかなり良いピアリングを備えたデータセンターにいるので、CDNの推論は彼らにとってそれほど大きくはありません(多分それは助けになるでしょうが、彼らはその理由でそれをしません)。その理由は、動的ページ(PHPスクリプト)をまとめて処理する複数のWebサーバーを並行して実行し、lighttpdやthttpdなどの高速で軽量なWebサーバーを使用してサービスを提供する別のドメインから画像とJavaScriptを提供するためです画像と静的JavaScript。
PHPにはPHPが必要です。静的Javascriptと画像はサポートしていません。必要なのが絶対的な最小要件である場合、フル機能のWebサーバーから多くの機能を削除できます。
もちろん、リクエストを特定のサブディレクトリに別のサーバーにリダイレクトするプロキシを使用できますが、すべての静的コンテンツを別のサーバーで処理する方が簡単です。