1

大学院輪講資料 2010 年12月10日 A survey on Overlay Networks behind Akamai

AkamaiのOverlay Networksに関する研究動向 浅見・川原研究室 電子情報学専攻 博士1年 宋泰永(ソン テヨン)

Abstract

Global-scale HD video streaming service is a key product for Content Distribution Networks (CDNs), such as Akamai, distribute thousands of servers worldwide providing a highly reliable service to their customers. But it is not easy to make scalable and reliable streaming service, because (i) link failure and flash crowd are a commonplace occurrence in today’s Internet (ii) applications are constrained by the network layer routing and peering policies of the ISPs (iii) network layer support (e.g. multicast) requires a large-scale infrastructure change in all ISPs.

In this paper, we focus on Akamai’s (audio and video) streaming service and demonstrate that the distributed approach is the best solution for above obstacles using public knowledge about CDN’s architecture. And we introduce some studies that assume operation algorithms of Akamai using inferring and exploiting network measurements performed on Akamai Edge servers. Keywords: Akamai, Overlay network, CDN 1. Introduction

Ciscoによると、インターネットの総トラフィックの内ビデオストリーミング占める割合が、2009年で3分の１、2010年の末までは40％になり、2014年には91％まで伸びる見込みだそうだ。3DやHDなど高画質になっていくコンテンツとYouTubeやIPTVの普及によりユーザがインターネットを介しての動画視聴に慣れていることにより、動画のストリーミングが増える傾向は加速する[1]と考えられる[1]。 しかし、今日のインターネットの環境では高画質動

画のストリミンスサービスをグローバル規模で展開するに適しているとは言えない。そと理由は、(1) link failureやflash crowdの問題がいつでも起こりうる構造であり、BGPだけではダイナミックに対処できない（2）アプリケションはISPのnetwork layerのルーティングやpeering policyにより制約され、ノード間でネットワーク的に近いルートではなく、安くて遠いルートを選択されることが起こりうる（3）Network layerでのサポート（例：IP multicastなど）のためには大規模の

ISPのインフラの変更を必要とするが考えられるからである。 このような問題に対して、信頼性と拡張性を持つストリーミングサービスを提供するためには次の課題をクリアする必要がある。 【課題１】信頼性：いつでも起こりうるネットワークの不具合に対し、ダイナミックに対応するには？ 【課題２】拡張性：大容量のトラフィックを処理するには？例えば100Tbpsのトラフィックに対応できるのか？ 【課題３】Network Economics：ISPからの制約から自由にできるのか？（Peering policy,大規模のインフラの変更など） 以上の課題に対する既存のアプローチは大きく三つ

で分類できる。

1. The Centralized Approach 2. Peer-to-Peer(P2P) Systems 3. The Distributed Approach

まず、Centralized Approachは、次のような特徴を持

っている。 • 一つから数十箇所のデータセンターを持っている • 各データセンターにはCacheやproxyサーバの設備を整えている

• 各データセンターとの転送はPeering関係に依存し、Backboneネットワークにつながっているデータセンターを持っている

一部のWeb Hosting会社の場合、数百から数千台のサ

ーバを幾つかのデータセンターで運営している。しかし、このような構造でも前の課題を解決することばできない。一番の問題は、データセンターの制約的位置や数にある。例えば、あるWeb Hosting会社が30個のデータセンターを持っていて、それぞれが10Gbpsを持つoutboundを30個もっているとしよう。多めに設定した

2

この例でも、この会社が対応できるトラヒックは9Tbpsに過ぎない［10］。 また、コンテンツの転送にEnd userとデータセンタ

ーでのpeering関係に依存しているため、地震や深海光ケーブルの切断のような突発的な事故にダイナミックに対応することば期待できない。そして、Network Economicsにより、ISP達が他社との接点であるPeering pointでの帯域を絞っている場合があるため、データセンターとEnd userが違うISPの位置する場合最適なルートでストリーミングサービスを提供できるとは言えない。 次にP2P Systemsを検討する。P2Pとは、計算能力や

帯域をEnd hostに依存するコンピュータネットワークを称す。各Hostが‘サーバ’と‘クライアント’の役割を一緒に行う特徴を持つ。よって、理論的には無限大の拡張性を持つ。しかし、 これは実世界の状況を反映しているとは言えない。一般的なブロードバンドサービスはDownlinkよりUplinkの速度が遅い(Imbalance)ことや、Uploadできる一日のトラヒックが限られている(Saturation)などの制限があるからだ。 最後にAkamai[2]やLimelight networks[3]社のような

CDN(Content delivery network) 業 者 が 取 っ て い る Distributed Approach方式は、数万台のサーバを全世界のISPのネットワークに置き、Overlay networkを構成することにより、前の課題を信頼性と拡張性があるクリアしストリーミングサービスを提供している。 本稿では、Akamaiの構造や関連研究を説明すること

で、Distributed Approachが問題を解決する方法を説明する。そして、Akamaiの関連研究で、Akamaiの運営アルゴリズムについての推測や現在のアーキテクチャの問題について紹介する。 2. Overlay networkとは

Akamaiの話の前に、基本知識としてOverlay networkとCDNの構造を説明する。まず、Overlay networkとは、物理的コンピュータネットワーク(Underlay network)上に構成された論理ネットワークを称す。OSIモデルからはLayer 7のアプリケション層に値し、Underlay network上のノードに作られたトンネルとして見ることもできる。同一Underlay network上に多数のOverlay networkを構成することができるが、一般的には各Overlay network同士はお互いの存在をしらない。しかし、Overlay networkの中にはルーティングを効率的にするためやUnderlay networkのトポロジや混雑状況を把握するためにUnderlay networkへの測定を行なっている場合がある。しかし、複数のOverlay networkが一つの

Underlay networkに測定を行うことでOverheadを発生することで、測定情報をOverlay network間で共有するための研究[4]も行われている。

Overlay networkのメリットを下記にまとめた • Incremental deployment : Overlay networkの設置には既存のネットワークの変更が不要で、既存の標準API(例：TCP/IP基盤のSocket APIなど)で構成できるため、設置が容易である

• Adaptable : ルーティングのための多様なmetric (bandwidth, latency, and security)を使えるため、現在のインターネット構成では対応できないアプリケションに合ったルーティングが可能になる

• Robust : 同じく多様なmetricが使えることで、ネットワークの不具合にダイナミックに対応できる他、十分なノードを持っている場合、多数のPathを提供できるためトラブルが発生したpathを回避できる十分なリダンダンシーが確保できる

図１ではOverlay networkの分類を示した。ルータの支援やEnd-Systemがあるかにより分類され、次の章ではこの中でCDNの仕組みについて説明する［18］。

Figure1. Taxonomy of overlay networks [4].

3.CDNの基本

Figure 2. Content distribution networks [4].

3

CDN(Content delivery network)とは、Overlay networkの一種で,Overlay上にコンテンツをキャッシュすることにより、大規模なコンテンツを効率よく配信することを目的とする。CDNはP2Pと違ってEnd Hostの変更を必要としないため、End Hostはクライアントとしのみ動作する。１世代のCDNでの主なコンテンツはWeb Pageだったが、２世代からはVoDやライブTVなどストリーミングサービスが中心になっている［18］。

CDNのアーキテクチャに登場する主な役者のデバイスは［図2］、コンテンツを提供するコンテンツプロバイダのOrigin Server、CDN業者のOverlay network上のSurrogate（代理）Server、そして、コンテンツを消費するユーザのClientがある。 次は、CDNのサービス分類についてである。図3で

示しているように、CDNは大きくHosting CDNとRelaying CDNに分けられる。Hosting CDNは1世代のWeb Hostingサービスのことで一般的にCDN内にOrigin Serverを持っている。Relaying CDNは外部にOrigin Serverが位置し、Origin Serverからコンテンツを全部または一分キャッシュし、配信するサービスを提供する。

Origin Serverからキャッシュされるコンテンツの範囲によって、Partial-siteとfull-site content deliveryに分類される。また、ユーザのコンテンツ要求を、適切なSurrogate Serverに分散させる技術として、DNS基盤とURL rewritingがある。

Origin ServerからCDNのOverlay上のサーバへのコンテンツキャッシュ方法として次の技術が使われている。

• Cooperative push-based • Noncooperative pull-based • Cooperative pull-based

Figure 3. CDN taxonomy [4].

まず、Cooperative push-basedは、Origin Serverが変更があったコンテンツをSurrogate Serverに転送すると、Surrogate Server同士が協力してコンテンツを更新する技術である。次に、Noncooperative pull-based方式は、まず、Clientから、あるSurrogate ServerにOrigin Server上の動画の再生要求があったが、キャッシュされていない場合(Cache miss)、該当のSurrogate Serverが直

接Origin Serverからそのコンテンツを持ってきてClientに提供する方法である。この方法の問題は、最初にコンテンツを要求するユーザはキャッシュによるメリットをもらえないことであるが、CDNの業界ではNoncooperative pull-basedを一般的なキャッシュ方法として使っている。最後にCooperative pull-based方式は、Cache missに対し、Surrogate ServerがOrigin Serverではなく、他のSurrogate Serverからコンテンツをもらうことで Noncooperative pull-basedとの違いがある。

4. How Does Akamai Work? それではAkamaiについて説明する。Akamai[2]は世

界最大のCDNサービス業者であり、アメリカのMassachusetts州のCambridgeに本社を持つ。Akamaiはハワイ語で‘賢い’、‘格好いい’の意味である。Akamaiは70カ国の 1300個の ISPと契約（ Akamai Accelerated Network program［6］と呼ぶ）をむすび、2010年末の時点で 7万 5千台以上のサーバを利用してOverlay Network(Edge Platform［12］と呼ぶ)を構築することで、Yahoo, Amazon, New York Timesなどの大手コンテンツプロバイダの数十 Gbpsに及ぶイメージや Flash Animation、Videoなどのコンテンツを全世界のインターネット利用者の90％以上へ配信している。 本章ではIntroductionで挙げられた課題をAkamaiが如

何にクリアしてグローバルレベルで動画のストリミンスサービスを提供できるかを、AkamaiのOverlay networkの構造や仕組みを基に説明する。

AkamaiのOverlay Networkの説明をするためには、Overlay Networkの各ノードであるサーバをAkamaiがISPへどんな形で提供しているかを見る必要がある。Akamai Accelerated Network programの特徴をまとめると以下になる。

• AkamaiからISPに送るサーバは無料である • ISPがネットワークにAkamaiのサーバを設置する際に、ISP側はそのサーバをネットワークにつなぎ、IP addressやDefault Gateway設定だけで設置は終わる

• AkamaiサーバはIntel基盤、Rack-mounted box型で、サーバのベンダから直接 ISPに配達される。Akamai社はこのサーバに一部のカーネル変更とキャッシュソフトを追加しただけである

• AkamaiのサーバはISPのFirewallの中では作動したい

• 各 ISPネットワーク上のAkamaiサーバは、 IP Addressで判断し、そのISPのClientにだけキャッシュを提供する

• Akamaiサーバによる発生するトラフィックに対してはAkamai側は費用を負担する

• 93～97％のcache hit rationを保つ

4

Akamai Accelerated Network programにより、ISPは自社のネットワークにAkamaiのサーバを置くことで、全世界のコンテンツプロバイダのコンテンツを自社のユーザに高いネットワーク品質で提供できるだけではなく、他社のISPへのトラフィックによる経済的負担も軽くなるメリットがある。AkamaiにとってもOverlay networkで発生するトラフィックについてはAkamaiが費用を負担するため、［課題３］を解決し高品質のサービスが提供できる。 また、AkamaiがこのISPのネットワークに設置され

た7万5千台のサーバで構成されたOverlay Network(以下Edge Platform)をどう運営しているか、つまり、Underlay networkの測定方法、キャッシュの分散アルゴリズム、Routing Path設定方法などは公開されていない。しかし、Akamaiが利用するサーバの分散に関してはよく知られている知識（ public knowledge ）に値するため、AkamaiのEdge Platformの構成や動作は推定が可能である。次の章では Edge Platformの構造や動作により、如何に［課題１］と［課題２］をクリアしているのかを説明する［7-11］。

4.1. Edge Platform

Figure 4. Akamai’s Distribution Infrastructure for Streaming [13].

図４は動画のストリーミング・スサービスのための

Akamaiの分散式キャッシュシステムの構造を示している。Entry PointやReflectorはAkamaiが管理するネットワーク上にあり、Edge ServerはAkamai Accelerated Network programによりAkamaiが管理しないISP業者のネットワーク上にある。コンテンツプロバイダがコンテンツをEncodeして、Akamaiのネットワーク上のEntry Pointに転送すると、そのストリームは複数のReflectorにより複製された後、Edge Serverに転送される［11］。 このような分散式アプローチは優れた拡張性で［課

題２］に対応している。例えば、2,500箇所に40台ずつのサーバを設置し、個々のサーバが1Gbpsの配信能力を持っていることにより100Tbps級の需要に対する配信が可能になる。 しかし、コンテンツプロバイダからのすべてのスト

リームを複製しReflectorとEdge Serverへ送るのは非効

率てきである。すべてのコンテンツが人気がある訳ではないからだ。 この問題を解決するために、AkamaiはReflector

Subscription Systemを採用している可能性がある［11］。これは、Reflectorが複製するストリームはEdge Serverから要請があったものに制限することでReflectorとEdge Serverのキャッシュの効率をあげる方法である。しかし、この技術を使っても、特定の地域の急な需要の増加や事故によるネットワークの不具合へのダイナミックな対応は依存として難しい問題である。 4.2. DNS-based load balancing ［課題１］に対応するため、Akamaiは様々なロケーションからの各サーバへのPingテスト、Traceroute、BGPルーティング情報、Akamaiサーバの配信状況の分析など、色んな角度からネットワークの状況を把握するGlobal Monitoring Infrastructureを構築している［13］。そして、AkamaiはDNS-based load balancingでネットワーク状況に合わせたサービスを提供している。［図5］Monitoring InfrastructureはEdge Serverのネットワークやサーバロードの状況をモニターしてDNSに登録する。もし、Edge Server（E1）の状況が悪化している場合、クライアント（C2）からのアクセスはEdge Server（E2）へフォワーディングされる。

Figure 5. Akamai’s Request routing Infrastructure [13].

例えば、図６で示しているように、128.4.30.15のIP

のユーザが、www.cnn.comへアクセスを試みている。www.cnn.comはAkamaiのクライアントで、この例ではすべてのコンテンツの配信をAkamaiに依頼している。www.cnn.comは自社のDNSサーバのCNAME(Canonical name)のエントリへ Akamaiのドメインネーム (例 a1685.g.akamai.net)を登録する。CNAMEは一種のエイリアスで、DNSサーバに新しいドメインネームへのredirectを可能にする。ユーザがwww.cnn.comをブラウザへ入力すると、DNS queryがユーザの近いLocal DNSサーバ（以下LDNS）へ送られ、Akamai DNSまで届く。Akamai DNSはLDNSのIP addressを見て、LDNSから近

5

いEdge ServerのIP address(145.155.10.15)をレスポンスする。

Figure 6. Example of DNS-based load balancing [17].

しかし、問題はAkamai DNSがLDNSからネットワー

ク的に近いEdge Serverをどうやって決めるかである。答えは、先程の Global Monitoring Infrastructureにより、LDNSと各Edge Serverまでのネットワーク的距離が常に測定されることにより、Akamai DNSはLDNSからのDNS queryに対してその時点で一番近いEdge ServerのIP Addressをレスポンスできることだ。 このような仕組により、Akamaiは常に変化するインターネットの状況に対応し、適切なサービスを提供することで［課題１］をクリアしている。 5. Akamai関連研究 前章ではCDNに関する公共の知識やAkamaiから公開

された情報を基にAkamai Overlay networkのアーキテクチャや動作について説明した。しかし、実際のサーバの配置や運営、キャッシュの分散アルゴリズムなどは公開されていない。そのため、Akamaiに関する研究ではAkamaiのEdge Serverに対し色んな測定を行い、その結果を分析することでAkamaiの内部の秘密に迫ろうとしている。

Ao-Jan SuとAleksanar KuzmanovicはAkamaiのDNS-based load balancingがストリーミングサービスを提供するために必要な信頼性を持っているかを実証した［13］。実験の方法としては、幾つかのAkamaiのクライアントであるコンテンツプロバイダに対して、研究用のPCからストリーミングを要請して、Akamaiからサービスを提供されるEdge ServerのIP Addressを把握する。そして多数のPCを利用してそのEdge Serverに負荷を掛ける場合、どのぐらいの時間でAkamaiのDNSにより他のEdge Serverへリダイレクトされるのかを1000箇所のEdge Serverに対して測定した。 図７にその結果を示している。最低20秒でリダイレ

クションが起こることが確認される。20秒のリダイレクションはWeb Pageの場合は十分な数値であるが、動画の再生中に20秒の再生中止は決して短いとは言えない時間である。また、Ao-Jan SuらはDNS queryに対し、

Edge ServerのIPがGlobal IP addressであることを挙げて、DoS攻撃などに対し信頼性を高めるためには、Edge ServerのIPを仮想化するなど、システムをもっと不透明することを進めている。

Figure 7. Inter-redirection time of streaming edge servers [13]. また、Ao-Jan SuとDavid R等［14］は、Planetlab

［16］上の140個のノードを利用し、AkamaiのEdge Serverへ測定を行い、Edge Serverの分散状況やDNS-Based負荷分散の効果を実証した。まず、Edge Serverの分散状況に関する実験では2ヶ月間140個のPlanetlabのノードを利用し、Yahoo, CNN, Fox News, NY TimesなどのサイトのCNAMEをLDNSへ20秒に一度の間隔でDNS queryの要求を送った。そのレスポンスとして送られるEdge ServerのIP addressを記録した。140個のノードの内、2つのノードの結果をまとめて示しているのが図8である。 図8(上)はBerkeleyにあるノードでの結果で図8(下)は

Purdueでの結果である。Berkeleyの場合、昼時間の混雑によるリダイレクションを除くと2つのIPが一貫して記録されているが、Purdueの場合、Berkeleyの様な一貫性は見当たらない。また、BerkeleyではレスポンスされるIPの総数が20個くらいだが、Purdueの場合、200個を超えている。この結果から推測できるのは、ノードとAkamaiのOverlay networkとのネットワーク的な距離である。つまり、Berkeleyのノードの近くにはAkamaiのネットワークがあるため、混雑な時間以外は同じEdge ServerへアクセスするがPurdueでは特に近いServerがないため、一貫性を持たない結果になったのだ。 そして、彼らはAkamaiのDNSリダイレクションが本

当にネットワークの状態を反映しているのかも調査した。実験方法としては、前の実験と同じく、140個Planetlab上のノードを利用して、20秒の間隔でAkamaiのクライアント社の内一つを選びDNS queryを要請して、それぞれのノードから近いEdge ServerのIP Addressを収集した。また、ノードからこのIPに対しpingを送り、RTTを測定した。この内、RTT値が小さい順で順位(rank)を与えた。（10個の内RTTが一番小さいIPにはr=0,一番大きIPにはr=9）AkamaiのDNSはDNS queryに対し2つのEdge ServerのIP Addressをレスポンスするため、各queryに対する結果は次の式に従い計算した。

6

Figure 8. Server diversity from two characteristic PL nodes [14].

r=r1+r2-1

彼らはこのような実験を140個のPlanetlabノードに対

して7日間行い、その結果を図10で示している。

Figure 9. Does Akamai reveal quality internet paths?[14]

図10の結果で分かるポイントは、リダイレクション

とネットワークの状況は決定的な関連性を示していることである。彼らがDNS query後、各サーバでのストリーミングやコンテンツ再生ではなく、pingを行い、RTTを測定した理由は、Serverのoverloadによる影響を除くためだった。そして、一番いい結果を示しているFox Newsの場合、Akamaiにより選択されるpathの内、97％が平均のrankを上回し、70%以上が上位の10％に値することで、AkamaiのDNSが最適なPathを教えていることが分かる。

Figure 10. Averaged rank for all PL nodes [14].

前の 2つの研究がAkamaiの外からの実験による

Akamaiネットワークの推測であることに対し、Alex Shermanらの研究は［15］Akamaiの研究者による実際のAkamaiネットワークに関する研究である。この研究で問題として挙げているのは、本稿のIntroductionでも［課題１］と［課題２］として提案した、システムの信頼性と拡張性の問題である。

7万台にも及ぶサーバに設定を行うのは簡単ではない。例えばコンテンツプロバイダから、あるコンテンツに対する更新の依頼があった場合、どうすればすべてのサーバのキャッシュを効率よく更新できるのか？また、Akamaiのサーバが10万台20万台に増えても設定への拡張性と信頼性を保つために必要な構造のあるべき姿はなんなのかをAlex Shermanらは悩んでいた。 この問題に対しての彼らの提案はベクター交換によ

るquorum based agreement schemeである。Quorumとは過半数の意味で、設定の更新に対し、過半数のStorage Pointが設定ファイルの受信を確認できると、すべてのEdge Serverへの設定ファイルの転送を行う仕組みである。 図 11は Alex Shermanらの提案システムである

ACMS(Akamai Configuration Management System)の構成を示している。Publisherはコンテンツプロバイダからの要求により設定ファイルを作成し、Storage Point（以下SP）へ転送する。設定ファイルを受信したSPは次の形式でベクター交換メッセージ（以下VMメッセージ）を作成して設定ファイルと共に他のSPにブロードキャストする。

7

Figure 11. ACMS: Publishers, Storage Points, and Receivers

(Subscribers) [15].

foo.A.1234 A:1 B:0 C:0 D:0 E:0

fooはフアイル名、Aは設定ファイルを受信したSPのID、1234は時刻である。そして、各SPは設定ファイルをブロードキャストする際に自分のIDに値するVMを「１」に設定する。例えばA,B,C,D,Eの５台のSPがあり、A,B,Eの順で設定ファイルがもらえる場合、最後のEによるVMメッセイジは次のようになる。

foo.A.1234 A:1 B:1 C:0 D:0 E:1

このVMメッセージを見るだけで過半数のSPがこの

設定ファイルを受け取ったことが確認でき、SPからEdge Serverへの設定ファイルの転送が始まる。この様な quorum based agreement schemeのメリットは接続できないSPを考えると、はっきり見えてくる。例えば前の例でDのIDを持つSPが不具合によりネットワークから離れていたとしても、残りのSPで設定の更新への決定やEdge Serverへの転送が可能であるため、信頼性の問題に対応できる。そして、ACMSも同じくAkamaiの分散式構造を使うため拡張性にも問題がない。

6. Future work 以上で説明したAkamaiの他、現在の商用CDNはほと

んどが B2B(Business-to-business)であるため、一般ユーザが使うには敷居が高い。例えば、ユーザが自分で撮影したホームネットワーク上の高画質の動画を地球の裏側に住んでいるFacebookの友達と共有する場合、選択できる方法は動画をFacebookやYouTubeの様なWebサービスのサーバへ登録し、リンクを送るのが一般的であろう。しかし、このようなWebサービスは、共有できるコンテンツの長さや画質へ制限を設けている場合もあるし、共有するコンテンツの数が多い場合、サ

ーバへの転送や登録に相当な時間を費やすことになる。ホームネットワーク上のサーバに保存されている高画質の動画をそのまま友達にストリーミングするには何が必要だろうかと言う疑問からAkamaiの調査は始まった。 現時点でのこれからの研究へのアイデアは、SNS上

のSocial Graph[18]を利用してAkamaiのEdge Platformの様 な キ ャ ッ シ ュ の Overlay network 構 築 し 、B2C(business-to-consumer)型のCDNを提案することである。Social Graphを利用することで、Cacheの効率を上げ、Akamaiより少ないEdge Serverでユーザが満足できる品質のユーザ間のストリーミングサービスが提案できると期待している。

Figure 12. Social Graphs [19].

7. 結論 本稿ではグローバルレベルでの高画質コンテンツの

ストリーミングサービスを提供する為に解決が必要な三つの課題（信頼性、拡張性、Network Economicsの観点から）を現在のインターネットの状況を基に抽出し、CDNが取っている分散式アプローチの優位性をAkamaiの構造がこの課題をクリアしていることで示した。Akamaiは、全世界の1300社以上のISPと契約をむすび、ISPのネットワークに設置したEdge Serverを利用しOverlay networkを構成する。このOverlay networkを利用して、インターネットの状況を把握することでFlash crowdやlink failureにダイナミックに対応できる。また、7万5千台以上のEdge Serverは集中式アプローチでは対応できない大規模のトラフィックにも対応できる。 そして、外部のノードを利用してAkamaiのEdge

Serverに測定を行うことで、公開されていないAkamaiの運営に関するアルゴリズムを推測できる研究を紹介した。Edge Serverの分散の把握やDNS-Basedによるリダイレクションがネットワークの状況を反映しているのかを確認した。 最後に、Akamaiの分散式アプローチとSocial Graphを

融合したキャッシュに関するFuture workを紹介した。

8

参考文献 [1] “Cisco Visual Networking Index: Forecast and

Methodology,” 2009–2014, [Online]. Available: http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360_ns827_Networking_Solutions_White_Paper.html.

[2] Akamai. http://www.akamai.com. [3] Limelight Networks CDN,

http://www.limelightnetworks. Com. [4] Sasu Tarkoma, “Overlay Networks Toward

Information Networking, “ CRC Press, 2010. [5] “Akamai and Loral Cyberstar Alliance,”

http://www.akamai.com/html/about/press/releases/2000/press_052300b.html.

[6] “Akamai Accelerated Network Program,” http://www.akamai.com/sitecomparison/

[7] C. Bornstein, T. Canfield, G. Miller, and S. Rao, “Optimal route selection in a content delivery network,” US Patent Application 20020163882.

[8] J. Dilley, B. Maggs, J. Parikh, H. Prokop, and R. Sitaraman, “Globally distributed content delivery,” IEEE Internet Comput., vol. 6, no. 5, pp. 50–58, Sep. 2002.

[9] F. Leighton and D. Lewin, “Global Hosting System,” US Patent 6,108,703.

[10] R. Mahajan, “How Akamai works?,” http:// www.cs.washington.edu/homes/ratul/akamai.html

[11] L. Kontothanassis, R. Sitaraman, J. Wein, D. Hong, R. Kleinberg, B. Mancuso, D. Shaw, and D. Stodolsky. “A Transport Layer for Live Streaming in a Content Delivery Network.” Proceedings of the IEEE, 92(9):1408–1419, 2004.

[12] “EdgePlatform,” http://www.akamai.com/html/technology/edgeplatform.html.

[13] A.-J. Su, A. Kuzmanovic. “Thinning Akamai.” In ACM IMC, pp. 29–42, 2008.

[14] A.-J. Su, D. Choffnes, A. Kuzmanovic, and F. Bustamante. “Drafting behind akamai (travelocity-based detouring).” In Proceedings of ACM SIGCOMM ’06, Pisa, Italy, Sept. 2006.

[15] A. Sherman, P. Lisiecki, A. Berkheimer, and J. Wein. “ACMS: The Akamai configuration management system.” In Proceedings of the 2nd USENIX Symposium on Networked Systems Design and Implementation (NSDI), Boston, MA, USA, May 2005.

[16] Planetlab.http://www.planet-lab.org/. [17] C. Bornstein, T. Canfield, and G. Miller. “Overlay

routing networks (Akarouting),” 2002. http://www-math.mit.edu/steng/18.996/lecture9.ps.

[18] Brad Fitzpatrick, “Thoughts on the Social Graph,” http://bradfitz.com/social-graph-problem/.

[19] “Owning Your Social Graph,” http://www.serendipity35.net/index.php?/archives/2044-Owning-Your-Social-Graph.html.