コンテンツ配信ネットワーク

（左）単一サーバー配信
（右）CDN配信スキーム

コンテンツ配信ネットワーク（CDN）またはコンテンツ配信ネットワークは、プロキシサーバーと対応するデータセンターを地理的に分散させたネットワークです。CDNは、エンドユーザーに対する地理的な分散により、高い可用性とパフォーマンス（「速度」）を提供します。CDNは、インターネットが重要なメディアになりつつあった1990年代後半に、インターネットのパフォーマンスボトルネックを緩和するために誕生しました[1] [2]。それ以来、CDNは、テキスト、グラフィック、スクリプト、ダウンロード可能なオブジェクト（メディアファイル、ソフトウェア、ドキュメント）、アプリケーション（電子商取引、ポータル）、ライブストリーミングメディア、オンデマンドストリーミングメディア、ソーシャルメディアサービスなど、インターネットコンテンツの大部分を扱うようになりました[3] 。

CDNはインターネットエコシステムにおけるレイヤーです。メディア企業やeコマースベンダーなどのコンテンツ所有者は、エンドユーザーにコンテンツを配信するためにCDN事業者に料金を支払います。CDNは、インターネットサービスプロバイダー（ISP）、通信事業者、ネットワーク事業者に対し、自社のデータセンターでサーバーをホスティングするための料金を支払います。

CDNは、動画ストリーミング、ソフトウェアダウンロード、Webおよびモバイルコンテンツの高速化、ライセンス/マネージドCDN、透過キャッシュ、CDNパフォーマンス測定サービス、負荷分散、マルチCDNスイッチングと分析、クラウドインテリジェンスなど、さまざまな種類のコンテンツ配信サービスを包括する包括的な用語です。CDNベンダーは、セキュリティ、 DDoS防御、Webアプリケーションファイアウォール（WAF）、WAN最適化といった他の業界にも進出することがあります。

コンテンツ配信サービスプロバイダーには、Akamai Technologies、Cloudflare、Amazon CloudFront、Qwilt (Cisco)、 Fastly、Google Cloud CDNなどがあります。

テクノロジー

CDNノードは通常、複数の場所に、多くの場合複数のインターネットバックボーンを介して配置されます。その利点には、帯域幅コストの削減、ページの読み込み時間の短縮、コンテンツのグローバルな可用性の向上などがあります。CDNを構成するノードとサーバーの数は、アーキテクチャによって異なります。数千ノード、数万台のサーバーを多数のリモートPoP（ Point of Presence）に配置するCDNもあれば、グローバルネットワークを構築し、地理的に少数のPoPを持つCDNもあります。[4]

コンテンツへのリクエストは通常​​、アルゴリズムによって何らかの最適なノードに送られます。パフォーマンスを最適化する場合、ユーザーにコンテンツを提供するのに最適な場所が選択されます。これは、ローカルネットワークを介した配信を最適化するために、リクエスト元のクライアントまでのホップ数が最も少ない、または最短時間で到達できる場所、あるいはサーバーパフォーマンスが最も高い場所を選択することで測定できます。コストを最適化する場合、代わりに最も安価な場所が選択されます。最適なシナリオでは、これら2つの目標は一致する傾向があり、ネットワークのエッジにあるエンドユーザーに近いエッジサーバーは、パフォーマンスまたはコストの点で有利になる可能性があります。

ほとんどのCDNプロバイダーは、米国、国際またはグローバル、アジア太平洋など、希望するカバレッジに応じて、定義されたさまざまなPoPセットを介してサービスを提供します。これらのPoPセットは、エンドユーザーに最も近いCDN資産のエッジとなるため、「エッジ」、「エッジノード」、「エッジサーバー」、または「エッジネットワーク」と呼ばれることがあります。[5]

CDN の概念:

  • コンテンツプロバイダオリジンサーバー: ソースコンテンツを提供するWebサーバー
  • CDNエントリポイント: オリジンからコンテンツを取得するCDN内のサーバー
  • CDN Origin Shield: トラフィックが集中した場合にオリジンサーバーを保護するCDNサービス
  • CDNエッジサーバー: クライアントからのコンテンツ要求を処理するCDNサーバー
  • CDNフットプリント: CDNエッジサーバーがクライアントのリクエストを効果的に処理できる地理的領域
  • CDNセレクター：マルチCDNの文脈において、複数のCDNの中から選択するための意思決定サービス
  • CDNオフロード: ピアツーピアCDNのコンテキストでは、CDNエッジサーバー配信に加えて、コンテンツを消費するクライアント間でコンテンツを配信するのに役立つメカニズムです。

セキュリティとプライバシー

CDNプロバイダーは、コンテンツプロバイダーが自社のネットワークを利用する際に支払う直接的な料金から利益を得るか、あるいは、スクリプトが顧客のウェブサイトのブラウザオリジン内にロードされる際に収集されるユーザー分析データやトラッキングデータから利益を得ています。そのため、これらのサービスは行動ターゲティングを目的とした潜在的なプライバシー侵害として指摘されており[6]、シングルオリジンサービスとリソースのキャッシュを回復するための解決策が開発されています[7] 。

特に、CDNを使用しているウェブサイトは、EUの一般データ保護規則（GDPR）に違反する可能性があります。例えば、2021年にドイツの裁判所は、ユーザーのIPアドレスがCDNに送信され、GDPRに違反するとして、大学のウェブサイトでのCDNの使用を禁止しました。[8]

JavaScriptを提供するCDNも、それらを使用するページに悪意のあるコンテンツを挿入する手段として標的にされています。これに対し、サブリソース整合性メカニズムは、ページが読み込むスクリプトの内容が既知であり、ウェブサイト作成者が参照するハッシュに制限されていることを保証するために開発されました。[9]

コンテンツネットワーキング技術

インターネットはエンドツーエンド原則[10]に基づいて設計されました。この原則により、コアネットワークは比較的シンプルに保たれ、インテリジェンスは可能な限りネットワークのエンドポイント、つまりホストとクライアントに集中します。その結果、コアネットワークはデータパケットの転送のみに特化、簡素化、最適化されています。

コンテンツ配信ネットワークは、コンテンツ配信を最適化するために設計された技術を用いて、様々なインテリジェントアプリケーションを配信することで、エンドツーエンドのトランスポートネットワークを拡張します。その結果得られる緊密に統合されたオーバーレイは、Webキャッシュ、サーバー負荷分散、リクエストルーティング、コンテンツサービスなどを活用します。[11]

ウェブキャッシュは、人気のあるコンテンツを、そのコンテンツに対する需要が最も高いサーバーに保存します。これらの共有ネットワークアプライアンスは、帯域幅要件を削減し、サーバー負荷を軽減し、キャッシュに保存されたコンテンツに対するクライアントの応答時間を改善します。ウェブキャッシュは、ユーザーからのリクエストに基づいて（プルキャッシュ）、またはコンテンツサーバーから配信される事前ロードされたコンテンツに基づいて（プッシュキャッシュ）生成されます。[12]

サーバー負荷分散は、サービスベース（グローバル負荷分散）またはハードウェアベース（レイヤー4～7スイッチ、ウェブスイッチ、コンテンツスイッチ、マルチレイヤースイッチとも呼ばれる）を含む1つ以上の技術を用いて、複数のサーバーまたはウェブキャッシュ間でトラフィックを共有します。この場合、スイッチには単一の仮想IPアドレスが割り当てられます。スイッチに到着したトラフィックは、スイッチに接続された実際のウェブサーバーの1つに転送されます。これには、負荷分散、総容量の増加、スケーラビリティの向上、そして障害が発生したウェブサーバーの負荷再分配とサーバーのヘルスチェックの提供による信頼性の向上といった利点があります。

レイヤー 4 ～ 7 スイッチを使用してコンテンツ クラスターまたはサービス ノードを形成し、ネットワーク内の複数のサーバーまたは複数の Web キャッシュ間で負荷を分散できます。

リクエストルーティングは、クライアントからのリクエストを、そのリクエストを最も適切に処理できるコンテンツソースに誘導します。これには、クライアントに最も近いサービスノード、または最も容量の大きいサービスノードへのクライアントリクエストの誘導が含まれます。リクエストのルーティングには、様々なアルゴリズムが使用されます。これには、グローバルサーバー負荷分散、DNSベースのリクエストルーティング、動的メタファイル生成、HTML書き換え、[13] 、エニーキャスト[14 ]などが含まれます。近接性（最も近いサービスノードの選択）は、リアクティブプロービング、プロアクティブプロービング、接続監視など、様々な手法を用いて推定されます。[11]

CDN は、手動によるアセットのコピー、アクティブ Web キャッシュ、グローバル ハードウェア ロード バランサーなど、さまざまなコンテンツ配信方法を使用します。

コンテンツサービスプロトコル

コンテンツネットワーク全体に分散されたさまざまなコンテンツサービスにアクセスできるようにするために、いくつかのプロトコルスイートが設計されています。インターネットコンテンツ適応プロトコル(ICAP) は 1990 年代後半に開発され[15] [16]、アプリケーションサーバーを接続するためのオープンスタンダードを提供しました。最近定義された堅牢なソリューションは、Open Pluggable Edge Services (OPES) プロトコルによって提供されています。[17]このアーキテクチャは、OPES プロセッサ自体に常駐することも、コールアウトサーバーでリモートで実行することもできる OPES サービスアプリケーションを定義します。Edge Side Included (ESI) は、エッジレベルの動的 Web コンテンツをアセンブリするための小さなマークアップ言語です。Web サイトでコンテンツが生成されることはよくあります。カタログやフォーラムなどのコンテンツの変更やパーソナライゼーションが原因の場合があります。これにより、キャッシュシステムに問題が発生します。この問題を解決するために、企業グループが ESI を作成しました。

ピアツーピアCDN

ピアツーピア（P2P）コンテンツ配信ネットワークでは、クライアントはリソースを利用するだけでなく、提供することもあります。つまり、クライアントサーバーシステムとは異なり、コンテンツ中心型ネットワークは、より多くのユーザーがコンテンツにアクセスするほどパフォーマンスが向上する可能性があります（特に、Bittorrentのようなユーザーによる共有を必要とするプロトコルの場合）。この特性は、P2Pネットワークを使用する大きな利点の一つであり、元のコンテンツ配信者にとって、セットアップと運用コストが非常に低くなります。[18] [19]

P2P ネットワークに参加するピアを奨励するために、Web3およびブロックチェーン技術を使用できます。参加ノードは、関与と引き換えに暗号トークンを受け取ります。

プライベートCDN

コンテンツ所有者が商用CDNサービスのオプションやコストに満足できない場合、独自のCDNを構築することができます。これはプライベートCDNと呼ばれます。プライベートCDNは、所有者のコンテンツのみを提供するPoP（Point of Presence）で構成されます。これらのPoPには、キャッシュサーバー[20] 、 リバースプロキシ、アプリケーション配信コントローラー[21]などがあります。2台のキャッシュサーバー[20]のようなシンプルなものから、ペタバイト規模のコンテンツを提供できるほど大規模なものまであります。[22]プライベートCDNが企業ネットワーク内に導入される場合、エンタープライズCDNまたはeCDNとも呼ばれます。

大規模なコンテンツ配信ネットワークでは、コンテンツのコピーをキャッシュロケーションに配信するために、独自のプライベートネットワークを構築・構築することもあります。[23] [24]このようなプライベートネットワークは通常、プライベートネットワークの容量が不足している場合や、障害によって容量が減少した場合に備え、バックアップオプションとしてパブリックネットワークと組み合わせて使用​​されます。同じコンテンツを複数のロケーションに配信する必要があるため、帯域幅の消費量を削減するために、さまざまなマルチキャスト技術が使用されることがあります。プライベートネットワークでは、利用可能なネットワーク容量をより効率的に活用するために、ネットワーク負荷状況に応じてマルチキャストツリーを選択することも提案されています。[25] [26]

通信事業者向けCDNの出現

ストリーミングビデオトラフィック[27]の急速な増加により、ブロードバンドプロバイダーは、この需要を満たし、十分に良好な品質の体験を提供することで加入者を維持するために、多額の設備投資を必要としました[28]。

これに対処するため、通信サービスプロバイダーは、ネットワーク バックボーンへの要求を軽減し、インフラストラクチャへの投資を削減する手段として、独自のコンテンツ配信ネットワークを立ち上げ始めています。

通信事業者向けCDNの利点

通信事業者CDNは、動画コンテンツが伝送されるネットワークを自社で所有しているため、従来のCDNよりも優位性があります。ラストマイルを所有し、コンテンツを自社ネットワークの奥深くにキャッシュできるため、エンドユーザーにより近い場所で配信できます。このディープキャッシュにより、動画データが一般的なインターネット上で伝送される距離が最小限に抑えられ、より迅速かつ確実に配信されます。

通信事業者向けCDNには、従来のCDNが帯域をリースし、事業者のマージンを自社のコストモデルに組み込む必要があったため、コスト面での優位性も備わっています。さらに、通信事業者は独自のコンテンツ配信インフラを運用することで、リソースの利用状況をより適切に管理できます。CDNによるコンテンツ管理業務は、通常、通信事業者や取引関係のある通信事業者のネットワーク（トポロジー、利用状況など）に関する情報を一切利用しない（あるいは非常に限られた情報のみで）実施されます。そのため、CDN業務がリソース利用に与える影響の大きさから、活動範囲が限られている通信事業者にとって、多くの課題が生じます。

対照的に、通信事業者CDNの導入により、通信事業者は独自のコンテンツ管理業務を実装できるようになり、[29] [30]リソースの利用をより適切に制御できるようになり、エンドユーザーに優れたサービス品質とエクスペリエンスを提供できるようになります。

フェデレーテッドCDNとオープンキャッシュ

2011年6月、StreamingMedia.comは、TSPグループがOperator Carrier Exchange（OCX）[31]を設立し、ネットワークを相互接続することで、世界中に広範なPoPを持つAkamaiやLimelight Networksといった大手従来型CDNとより直接的に競合することを狙っていると報じました。このように、通信事業者はフェデレーテッドCDNサービスを構築しており、これは、このフェデレーションに集約された視聴者にコンテンツを配信したいコンテンツプロバイダーにとって、より魅力的な選択肢となります。

近い将来、他の通信事業者によるCDN連合が設立される可能性が高いでしょう。これらの連合は、新たな通信事業者が加盟し、既存の通信事業者にネットワークプレゼンスとインターネット加入者基盤をもたらすことで成長していくでしょう。[要出典]

Streaming Video Technology Alliance の Open Caching 仕様では、コンテンツ プロバイダーが複数の CDN を使用して一貫した方法でコンテンツを配信し、これらの API を通じて各 CDN プロバイダーを同じ方法で認識できるようにする一連のAPIが定義されています。

マルチCDNとCDNの選択

複数のCDNサービスを組み合わせることで、コンテンツプロバイダーは単一のCDNサービスに依存する必要がなくなります。特にライブイベント中のピーク時の視聴者数への対応が重要になります。特定のCDNにトラフィックを割り当てる方法はいくつかあり、クライアント側でCDNを選択する方法、サーバー側（コンテンツプロバイダーの配信元）で選択する方法、クラウド側（コンテンツの配信元と視聴者の中間）で選択する方法などがあります。CDNの選択基準としては、パフォーマンス、可用性、コストなどが挙げられます。

DNS の拡張メカニズムを使用した CDN パフォーマンスの向上

2014年4月にCDNがEDNS0拡張を導入した際に、非ローカルリゾルバを持つクライアントが経験するレイテンシ（RTT）（「高」）は大幅に減少しましたが、ローカルリゾルバを持つクライアントのレイテンシは変更による影響を受けませんでした（「低」）。[32]

伝統的に、CDN はクライアントの再帰 DNS リゾルバの IP を使用してクライアントの位置を特定してきました。これは多くの状況で適切な方法ですが、クライアントが遠く離れた非ローカルの再帰 DNS リゾルバを使用している場合、クライアントのパフォーマンスが低下します。たとえば、クライアントがシンガポールのパブリック DNS リゾルバを使用している場合、CDN はインドのクライアントからのリクエストをシンガポールのエッジサーバーにルーティングすることがあり、その結果、そのクライアントのパフォーマンスが低下します。実際、最近の調査[32]では、パブリック DNS リゾルバが広く使用されている多くの国では、クライアントと再帰 DNS リゾルバ間の距離の中央値は 1,000 マイルにも達することがあります。2011 年 8 月、Google が率いる大手インターネット サービス プロバイダーの世界的コンソーシアムは、DNS 解決の応答を正確にローカライズすることを目的とした edns-client-subnet IETF インターネット ドラフト[ 33]の公式実装を発表しました。この取り組みには、 Google Public DNS [ 34]などの少数の主要な DNS サービスプロバイダーと、CDN サービスプロバイダーも関与しています。edns-client-subnet EDNS0 オプションを使用すると、CDN は DNS 要求を解決するときに要求元クライアントのサブネットの IP アドレスを利用できるようになります。エンドユーザー マッピングと呼ばれるこのアプローチは[32] 、 CDN で採用されており、ラウンドトリップの遅延を大幅に削減し、パブリック DNS やその他の非ローカル リゾルバを使用するクライアントのパフォーマンスを向上させることが示されています。ただし、EDNS0 の使用には、再帰リゾルバでの解決のキャッシュの有効性が低下する、[32] DNS 解決のトラフィック全体が増加する、[32]クライアントのサブネットが公開されるというプライバシーの懸念が生じるなどの欠点もあります。

仮想CDN（vCDN）

仮想化技術は、コンテンツプロバイダーのコスト削減、弾力性の向上、サービス遅延の低減を目的として、仮想CDN（vCDN）（ソフトウェア定義CDNまたはSD-CDNとも呼ばれる）の導入に利用されています。vCDNでは、仮想キャッシュがプロバイダーの地理的範囲に分散された物理サーバーに（仮想マシンまたはコンテナとして）動的に展開されるため、パフォーマンス、信頼性、可用性といった従来のCDNの制限を回避することができます。仮想キャッシュの配置はコンテンツの種類とサーバーまたはエンドユーザーの地理的位置に基づいて行われるため、vCDNはサービス配信とネットワークの輻輳に大きな影響を与えます。[35] [36] [37] [38]

非HTTP配信を使用するCDN

パフォーマンスを向上させるために、サーバーからクライアントへの配信には、 WebRTCやWebSocketなどの HTTP 以外の代替プロトコルを使用できます。

画像の最適化と配信（画像 CDN）

2017年、GoogleのAddy Osmaniは、レスポンシブWebデザインパラダイム（特に<picture>要素）と自然に統合できるソフトウェアソリューションをイメージCDNと呼び始めました。[39]この表現は、Webアーキテクチャが、ブラウザまたはサーバー側のロジックによって決定される、リクエスト元のブラウザのプロパティに応じて、HTTP経由で同じ画像の複数のバージョンを提供する機能を指していました。Googleのビジョンでは、イメージCDNの目的は、ダウンロード速度を維持しながら高品質の画像（または、より正確には、人間の目で高品質と認識される画像）を提供し、優れたユーザーエクスペリエンス（UX）に貢献することでした。[要出典]

おそらく、イメージ CDN という用語はもともと誤った名称であった。CloudinaryもImgix (2017 年の Addy Osmani のガイドで Google が引用した例) も、当時の用語の古典的な意味での CDN ではなかった。[39]しかし、その後まもなく、いくつかの企業が、開発者がさまざまな戦略に従ってグラフィック アセットの異なるバージョンを提供できるソリューションを提供した。これらのソリューションの多くは、Akamai、CloudFront、Fastly、Edgecast、Cloudflareなどの従来の CDN 上に構築された。同時に、すでにイメージのマルチサービング サービスを提供していた他のソリューションが、ネイティブで CDN 機能を提供する (ImageEngine) [40]か、既存の CDN の 1 つと統合する (Cloudinary/Akamai、Imgix/Fastly) ことで、イメージ CDN の定義に加わった。

画像CDNとは何かという普遍的に合意された定義を提供することは不可能かもしれませんが、一般的に言えば、画像CDNは次の3つのコンポーネントをサポートしています。[41]

次の表は、この分野における主要なソフトウェアCDNの現状をまとめたものである。[42]

市場に出回っているメイン画像CDN
名前CDN画像の最適化デバイス検出
Akamai イメージマネージャーはいバッチモードHTTP Acceptヘッダーに基づく
Cloudflare ポーランド語はい全自動HTTP Acceptヘッダーに基づく
曇り空Akamaiを通じてバッチ、URLディレクティブAcceptヘッダー、クライアントヒント
ファストリーIOはいURLディレクティブHTTP Acceptヘッダーに基づく
イメージエンジンはい全自動WURFL、クライアントヒント、Acceptヘッダー
イムジックスFastlyを通じて全自動Acceptヘッダー/クライアントヒント
ページCDNはいURLディレクティブHTTP Acceptヘッダーに基づく
Tinify CDN複数全自動HTTP Acceptヘッダーに基づく

コンテンツ配信サービスおよびテクノロジープロバイダー

商用またはフリーソフトウェアベンダー（独自の CDN を構築）

無料サービス

商用サービス

その他

通信事業者向けCDN

P2Pを使った配送の商用利用

マルチ

  • ジェットストリーム
  • メタCDN
  • NPAW CDNバランサー
  • ベロシックス
  • ワープキャッシュ[47] [48]

社内

参照

参考文献

  1. ^ 「Globally Distributed Content Delivery、J. Dilley、B. Maggs、J. Parikh、H. Prokop、R. Sitaraman、B. Weihl著、IEEE Internet Computing、第6巻、第5号、2002年11月」(PDF) 。 2017年8月9日時点のオリジナルよりアーカイブ(PDF) 。 2019年10月25日閲覧。
  2. ^ Nygren., E.; Sitaraman RK; Sun, J. (2010). 「Akamaiネットワーク：高性能インターネットアプリケーションのためのプラットフォーム」（PDF） . ACM SIGOPS Operating Systems Review . 44 (3): 2– 19. doi :10.1145/1842733.1842736. S2CID 207181702. 2012年9月13日時点のオリジナルより アーカイブ（PDF） . 2012年11月19日閲覧。
  3. ^ Evi, Nemeth (2018). 「第19章 ウェブホスティング、コンテンツ配信ネットワーク」. UNIXおよびLinuxシステム管理ハンドブック（第5版）. ボストン: Pearson Education. p. 690. ISBN 978-0-13-427755-4. OCLC  1005898086.
  4. ^ 「コンテンツ配信ネットワークの仕組み」CDNetworks . 2015年9月5日時点のオリジナルよりアーカイブ。2015年9月22日閲覧。
  5. ^ 「コンテンツ配信ネットワーク（CDN）の仕組み」NCZOnline、2011年11月29日。2011年12月1日時点のオリジナルよりアーカイブ。 2015年9月22日閲覧。
  6. ^ セキュリティ、ヘルプネット (2014年8月27日). 「4億7000万サイトが24時間存在、そのうち22%は悪質」.ヘルプネット セキュリティ. 2019年7月1日時点のオリジナルよりアーカイブ。 2019年7月1日閲覧。
  7. ^ 「Decentraleyes: CDNトラッキングをブロックする」Collin M. Barrett . 2016年2月3日. 2019年7月1日時点のオリジナルよりアーカイブ。 2019年7月1日閲覧。
  8. ^ “VG Wiesbaden のコンテンツ配信ネットワークに関する詳細情報”. www.taylorwessing.com (ドイツ語)。 2021-12-14 . 2023-03-02に取得。
  9. ^ “サブリソースの整合性”. MDN Web Docs . 2019年6月26日時点のオリジナルよりアーカイブ。2019年7月1日閲覧。
  10. ^ JH Saltzer、DP Reed、DD Clark (1984年11月1日). 「システム設計におけるエンドツーエンドの議論」(PDF) . ACM Transactions on Computer Systems . 2 (4): 277– 288. doi :10.1145/357401.357402. ISSN  0734-2071. S2CID  215746877. Wikidata  Q56503280 . 2006年11月11日閲覧.
  11. ^ ab Hofmann, Markus; Beaumont, Leland R. (2005).コンテンツネットワーキング：アーキテクチャ、プロトコル、そして実践. Morgan Kaufmann Publisher. ISBN 1-55860-834-6。
  12. ^ Bestavros, Azer (1996年3月). 「分散情報システムのサーバー負荷、ネットワークトラフィック、サービス時間を削減するための投機的データ配布とサービス」(PDF) . Proceedings of ICDE'96: The 1996 International Conference on Data Engineering . 1996 : 180–189 . 2010年7月3日時点のオリジナルからアーカイブ(PDF) . 2017年5月28日閲覧.
  13. ^ RFC  3568 Barbir, A., Cain, B., Nair, R., Spatscheck, O.:「既知のコンテンツネットワーク（CN）リクエストルーティングメカニズム」、2003年7月
  14. ^ RFC  1546 Partridge, C.、Mendez, T.、Milliken, W.:「ホスト エニーキャスティング サービス」、1993 年 11 月。
  15. ^ RFC  3507 Elson, J.、Cerpa, A.：「インターネット コンテンツ適応プロトコル (ICAP)」、2003 年 4 月。
  16. ^ ICAPフォーラム
  17. ^ RFC  3835 Barbir, A.、Penno, R.、Chen, R.、Hofmann, M.、およびOrman, H.：「Open Pluggable Edge Services (OPES) のアーキテクチャ」、2004 年 8 月。
  18. ^ Li, Jin (2008). 「ピアツーピア（P2P）コンテンツ配信について」（PDF） .ピアツーピアネットワークとアプリケーション. 1 (1): 45– 63. doi :10.1007/s12083-007-0003-1. S2CID  16438304. 2013年10月4日時点のオリジナルよりアーカイブ（PDF） . 2013年8月11日閲覧。
  19. ^ Stutzbach, Daniel; et al. (2005). 「スワーミング型ピアツーピア・コンテンツ配信のスケーラビリティ」(PDF)。Boutaba, Raouf; et al. (編). NETWORKING 2005 -- ネットワーク技術、サービス、プロトコル; コンピュータおよび通信ネットワークのパフォーマンス; モバイルおよび無線通信システム. Springer. pp.  15– 26. ISBN 978-3-540-25809-4。
  20. ^ ab 「BIND、GeoIP、Nginx、Varnishを使って独自のCDNを構築する方法 - UNIXy」2010年7月18日。2010年7月21日時点のオリジナルよりアーカイブ。 2014年10月15日閲覧。
  21. ^ 「aiScalerでコンテンツ配信ネットワークを構築する方法」。2014年10月6日時点のオリジナルよりアーカイブ。2014年10月15日閲覧。
  22. ^ 「Netflixがトラフィックを自社CDNに移行、AkamaiとLimelightが打撃を受ける」Forbes、2012年6月5日。2017年10月19日時点のオリジナルよりアーカイブ。2017年8月26日閲覧。
  23. ^ Mikel Jimenez他 (2017年5月1日). 「Building Express Backbone: Facebook's new long-haul network」. 2017年10月24日時点のオリジナルよりアーカイブ。2017年10月27日閲覧。
  24. ^ 「SDNとOpenFlowを使用した集中型TEを備えたデータセンター間WAN」（PDF） 2012年。 2017年10月28日時点のオリジナルよりアーカイブ（PDF） 。 2017年10月27日閲覧。
  25. ^ M. Noormohammadpour他 (2017年7月10日). 「DCCast: データセンター間の効率的なポイントツーマルチポイント転送」 USENIX . 2017年7月26日閲覧。
  26. ^ M. Noormohammadpour他 (2018). 「QuickCast: 転送ツリーコホートを用いた高速かつ効率的なデータセンター間転送」2018年1月23日閲覧。
  27. ^ 「オンラインビデオが驚異的な成長を遂げ、大幅なアップデートが続く」SiliconANGLE 2011年3月3日。2011年8月30日時点のオリジナルよりアーカイブ。 2011年7月22日閲覧。
  28. ^ 「ビデオ、3G、LTE投資により、2011年の通信業界のCAPEXは全体的に上昇する見込み」cellular-news . 2011年3月25日時点のオリジナルよりアーカイブ。 2011年7月22日閲覧。
  29. ^ D. Tuncer、M. Charalambides、R. Landa、G. Pavlou、「ネットワーク リソースのより高度な制御: ISP キャッシュの観点」、IEEE/IFIP ネットワークおよびサービス管理会議 (CNSM) の議事録、スイス、チューリッヒ、2013 年 10 月。
  30. ^ M. Claeys、D. Tuncer、J. Famaey、M. Charalambides、S. Latre、F. De Turck、G. Pavlou、「仮想化 ISP ネットワーク向けのプロアクティブなマルチテナント キャッシュ管理」、IEEE/IFIP ネットワークおよびサービス管理会議 (CNSM) の議事録、ブラジル、リオデジャネイロ、2014 年 11 月。
  31. ^ 「通信事業者と通信事業者がOCX（Operator Carrier Exchange）と呼ばれる新たな連合型CDNグループを結成」Dan Rayburn – StreamingMediaBlog.com 2017年12月13日。2011年7月20日時点のオリジナルよりアーカイブ。 2011年7月22日閲覧。
  32. ^ abcde 「エンドユーザーマッピング：コンテンツ配信のための次世代リクエストルーティング、F. Chen、R. Sitaraman、M. Torres著、ACM SIGCOMMカンファレンス、2015年8月」（PDF） 。 2017年8月12日時点のオリジナルからアーカイブ（PDF） 。 2019年10月31日閲覧。
  33. ^ 「DNS 要求内のクライアント サブネット」。
  34. ^ 「現在、サーバーはどこにありますか？」2013年1月15日時点のオリジナルよりアーカイブ。
  35. ^ Filelis-Papadopoulos, Christos K.; Giannoutakis, Konstantinos M.; Gravvanis, George A.; Endo, Patricia Takako; Tzovaras, Dimitrios; Svorobej, Sergej; Lynn, Theo (2019-04-01). 「大規模vCDNネットワークのシミュレーション：並列アプローチ」.シミュレーションモデリングの実践と理論. 92 : 100– 114. doi :10.1016/j.simpat.2019.01.001. ISSN  1569-190X. S2CID  67752426.
  36. ^ Filelis-Papadopoulos, Christos K.; Endo, Patricia Takako; Bendechache, Malika; Svorobej, Sergej; Giannoutakis, Konstantinos M.; Gravvanis, George A.; Tzovaras, Dimitrios; Byrne, James; Lynn, Theo (2020-01-01). 「大規模仮想コンテンツ配信ネットワークにおけるキャッシュ配置のシミュレーションと最適化に向けて」. Journal of Computational Science . 39 101052. doi : 10.1016/j.jocs.2019.101052 . ISSN  1877-7503.
  37. ^ Ibn-Khedher, Hatem; Abd-Elrahman, Emad; Kamal, Ahmed E.; Afifi, Hossam (2017-06-19). 「OPAC: 仮想CDNのための最適配置アルゴリズム」. Computer Networks . 120 : 12–27 . doi :10.1016/j.comnet.2017.04.009. ISSN  1389-1286.
  38. ^ Khedher, Hatem; Abd-Elrahman, Emad; Afifi, Hossam; Marot, Michel (2017年10月). 「仮想CDNオーケストレーションのための最適かつコスト効率の高いアルゴリズム」. 2017 IEEE 42nd Conference on Local Computer Networks (LCN) . シンガポール: IEEE. pp.  61– 69. doi :10.1109/LCN.2017.115. ISBN 978-1-5090-6523-3. S2CID  44243386。
  39. ^ ab Osmani, Addy. 「Essential Image Optimization」 . 2020年5月13日閲覧。
  40. ^ Jon Arne Sæterås (2017年4月26日). 「コンテンツ配信ネットワークで画像を最適化しましょう」 . 2020年5月13日閲覧。
  41. ^ Katie Hempenius. 「画像CDNを使用して画像を最適化する」 . 2020年5月13日閲覧。
  42. ^ Maximiliano Firtman (2019年9月18日). 「レスポンシブ画像最適化CDNによるペイントメトリクスの高速化」 . 2020年5月13日閲覧。
  43. ^ “オープンソースライブラリをホスティングするためのトップ4 CDNサービス | opensource.com”. opensource.com. 2019年4月18日時点のオリジナルよりアーカイブ。 2019年4月18日閲覧。
  44. ^ 「ウェブサイト向けJavaScriptコンテンツ配信ネットワークの利用統計と市場シェア」W3Techs。2019年4月12日時点のオリジナルよりアーカイブ。2019年4月17日閲覧。
  45. ^ abcd 「CDNと国際サーバーネットワークがグローバル化を促進する仕組み」ハフィントン・ポスト、Delarno Delvix、2016年9月6日。2016年9月19日時点のオリジナルよりアーカイブ。 2016年9月9日閲覧。
  46. ^ 「クラウドコンテンツ配信ネットワーク（CDN）市場調査レポート」2019年10月5日。2019年10月7日時点のオリジナルよりアーカイブ。 2019年10月7日閲覧。
  47. ^ "CDN: コンテンツ デリバリー ネットワークは wissen müssen でした". www.computerwoche.de。 2019-03-21 のオリジナルからアーカイブ。2019年3月21日に取得。
  48. ^ Williams, Mike (2017年8月22日). 「Warpcacheレビュー」. TechRadar . 2019年3月21日時点のオリジナルよりアーカイブ。 2019年3月21日閲覧。
  49. ^ BIDI: BBCインターネット配信インフラストラクチャの説明
  50. ^ Netflixの仕組み：再生ボタンを押すたびに起こる複雑な動作（非常に簡略化）

さらに読む

  • Buyya, R.; Pathan, M.; Vakali, A. (2008). 「コンテンツ配信ネットワーク：最新技術、洞察、そして必須事項」. コンテンツ配信ネットワーク. 電気工学講義ノート. 第9巻. Springer. pp.  3– 32. doi :10.1007/978-3-540-77887-5_1. ISBN 978-3-540-77886-8. 2017年9月27日時点のオリジナルよりアーカイブ。2008年7月7日閲覧。
  • Hau, T.; Burghardt, D.; Brenner, W. (2011). 「マルチホーミング、コンテンツ配信ネットワーク、そしてインターネット接続市場」.電気通信政策. 35 (6): 532– 542. doi :10.1016/j.telpol.2011.04.002.
  • Majumdar, S.; Kulkarni, D.; Ravishankar, C. (2007). 「コンテンツ配信システムにおけるクリック詐欺への対処」(PDF) . Infocom . IEEE. doi :10.1109/INFCOM.2007.36.
  • Nygren., E.; Sitaraman RK; Sun, J. (2010). 「Akamai ネットワーク：高性能インターネットアプリケーションのためのプラットフォーム」（PDF） . ACM SIGOPS オペレーティングシステムレビュー. 44 (3): 2– 19. doi :10.1145/1842733.1842736. S2CID  207181702. 2012年11月19日閲覧.
  • Vakali, A. ; Pallis, G. (2003). 「コンテンツ配信ネットワーク：現状と動向」. IEEE Internet Computing . 7 (6): 68– 74. doi :10.1109/MIC.2003.1250586. S2CID  2861167.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Content_delivery_network&oldid=1314083185"