专利摘要:
LDNSリゾルバの背後に存在するクライアントを特定するための技術について説明する。ウェブビーコンがクライアントに、一意のホストネームにおけるゼロコンテンツ画像を取り出すように指示する。クライアントによりLDNSリゾルバに対してホストネームへの要求が行われる。LDNSは、ホストネームに対する要求を情報提供サーバ/ビーコンリゾルバへ送信する。ビーコンリゾルバは、LDNSリゾルバのIPアドレスとともにホストネームを記録し、LDNSによりクライアントへ転送されたビーコンコレクションサーバのIPアドレスで応答する。クライアントは、一意のホストネームを含む要求をビーコンコレクションサーバへ送信する。ビーコンコレクションサーバは、クライアントのIPアドレス及びホストネームを記録する。集約サーバが、ビーコンリゾルバ及びビーコンコレクションサーバからデータを収集する。ホストネームをキーとして使用して、クライアントのIPアドレスがLDNSリゾルバのIPアドレスにマッピングされる。マッピングされたデータをロードバランシングサーバにエクスポートしてルーティングを決定する。
公开号:JP2011508525A
申请号:JP2010539662
申请日:2008-12-12
公开日:2011-03-10
发明作者:ディヴィッド アップガー;マイケル クリスチャン
申请人:ヤフー! インコーポレイテッド;
IPC主号:H04L12-56
专利说明:

[0001] 本発明は、ネットワークにおけるグローバルトラフィックロードバランシングに関する。]
背景技術

[0002] この項で説明するアプローチは追求できるアプローチではあるが、必ずしも以前から想到又は追求されていたアプローチではない。従って、他に指示がない限り、この項で説明するアプローチのいずれかを、単にこの項に含まれているという理由で従来技術として見なすべきではない。]
[0003] 本明細書で使用する場合、「データセンタ」という用語は、関連するサーバのコロケーションを意味する。特定のデータセンタに属するサーバは同じ建物又は複合施設内に存在するが、データセンタは、通常互いに地理的に離れて位置する。自然災害によって引き起こされた一方のデータセンタにおける突発的故障が他方のデータセンタにおいても故障を引き起こさないように、この地理的な距離により保護が加えられる。例えば、1つのデータセンタがニューヨークのイーストコーストに位置し、別のデータセンタがサンフランシスコのウエストコーストに位置する場合がある。]
[0004] グローバルロードバランシングすなわち「GLB」は、特定のサービスへのクライアントアクセスを複数のサーバに分散させるためのメカニズムである。例えば、特定のサービスがニューヨークのデータセンタに属するサーバとサンフランシスコのデータセンタに属するサーバとによって提供される状況では、GLBは、ニューヨークのデータセンタに接続されるクライアントの数が、サンフランシスコのデータセンタに接続されるクライアントの数とほぼ同じになるようにクライアントアクセスを分散させることができる。]
[0005] インターネットとの関連において使用する場合、GLBは、様々な能動的及び受動的モニタリング技術を使用してインターネットの複雑なマップを生成することができる。このマップに基づき、GLBは、トラフィックルーティングを決定してクライアントを「最も近い」サーバに接続する。本明細書で使用する場合、「近い」とは、必ずしも決定の基礎を地理的な近さのみに置くことを意味するものではない。本明細書で使用する場合、「近い」サーバとは、クライアントへの接続が最も速いサーバのことである。従って、混雑により、クライアントが200マイル離れたところにあるサーバに到達するよりも100マイル離れたところにあるサーバに到達する方が遅い場合、GLBは、クライアントを200マイル離れたところにある「より近い」サーバへルーティングする。]
[0006] ユーザがウェブアプリケーション又はウェブページに接続したいと望む場合、DNS要求が行われる。DNS要求は、ユーザがクライアントの機械を介して要求を行うことにより、多くの場合はウェブブラウザに(「www.sampledomain.com」などの)ドメインをタイピングすることにより開始する。要求は、クライアントからサービスプロバイダのローカルDNSリゾルバ(「LDNS」)へ送信される。LDNSリゾルバは、クライアントからの要求を受け付け、LDNSリゾルバが要求に対する回答をキャッシュに記憶している場合にはドメインのIPアドレスで要求に応答する。LDNSが回答を記憶していない場合には、LDNSは要求を情報提供(authoritative)DNSリゾルバへ転送する。情報提供DNSリゾルバとは、ドメインのネットワークのためのデータを保持するサーバのことである。情報提供DNSリゾルバは、LDNSリゾルバから要求を受信し、ドメインに接続するための特定のサーバのIPアドレスでLDNSリゾルバに応答する。本明細書で使用する場合、GLBリゾルバは情報提供DNSリゾルバの一部であってもよい。GLBリゾルバはまた、情報提供ネームサーバとは別個のものであってもよく、或いは離れて位置していてもよい。これは実施構成ごとに異なることができる。]
発明が解決しようとする課題

[0007] 残念ながら、GLBの決定が不十分なデータに基づく場合がある。例えば、LDNSリゾルバからGLBに要求が行われた場合、この要求はLDNSに関する情報しか含んでおらず、要求を発信したクライアントに関する情報は含んでいない。従って、GLBは、クライアントよりもむしろLDNSリゾルバの場所及び混み具合に基づいて決定を行うことを強要される。]
[0008] ルーティング情報の基礎をクライアントではなくLDNSリゾルバに置くことにより、2つの主な問題が生じる可能性がある。第1に、クライアントが、地理上及びネットワーク上でLDNSリゾルバとは全く異なる場所に位置する可能性がある。この結果、多くの場合GLBによる近接性マッピングが不正確になる。第2に、LDNSリゾルバが応答をキャッシュするので、GLBは、LDNSリゾルバの背後に存在するクライアントにより生成された要求の量を特定することができない。DNSルックアップを行う1人のユーザ及び100万人の異なるユーザが、GLBにおいて同じ量のトラフィックを生成することができる。これにより、ロードバランシングの決定が非常に不正確になる。]
[0009] DNSに基づくGLBの例を図1に示す。図1では、2つのデータセンタ又はコロケーションが、地理的に異なるエリアに位置する。一方のデータセンタはニューヨーク103に位置し、他方のデータセンタはサンフランシスコ101に位置する。ニューヨーク103のデータセンタは1.2.3.4というIPアドレスを有し、サンフランシスコ101のデータセンタは2.2.2.2というIPアドレスを有する。] 図1
[0010] クライアント105が、この2つのデータセンタによりホストされるウェブページ「www.sampleconnection.com」に接続したいと望む。ACMEインターネットサービスプロバイダを使用するクライアント105は、ドメインに接続する要求を行う。クライアント105からの要求は、まずACMELDNSリゾルバ107へ送信される111。この要求に基づいて、LDNSはキャッシュに回答を記憶しておくことができ、或いはドメインのIPアドレスを提供するドメインの情報提供サーバへ要求を転送することができる。]
[0011] ACMELDNSリゾルバ107は、ドメインのIPアドレスがLDNSリゾルバのキャッシュに記憶されているかどうかをチェックする。IPアドレスがキャッシュに記憶されている場合、記憶されているIPアドレスが要求に応じてクライアントへ送信される。ドメインへのIPアドレスがキャッシュ内で見つからなかった場合、LDNSリゾルバは、ドメイン「www.sampleconnection.com」に対する要求を情報提供DNSリゾルバへ送信してIPアドレスを取得する。これを、GLB及び情報提供DNSリゾルバ109に対して行われるドメイン「www.sampleconnection.com」のための要求115の形で示している。]
[0012] 次に、(情報提供DNSリゾルバを含む)GLB109は、ウェブページに対する要求に基づいて、ニューヨークの1.2.3.4というIPアドレス、又はサンフランシスコの2.2.2.2というIPアドレスのどちらを戻すかを決定する。GLB内の論理が、要求が発信された場所を含む要求、及びサーバの利用可能性及び負荷を分析して、特定のクライアントにとっていずれの特定のサーバが最適であるかを決定する。]
[0013] 残念ながら、情報提供DNSサーバ109は、この要求がノースカロライナにあるACMELDNSリゾルバ107の場所から発信されたものであると見なし、アリゾナのクライアント105の場所から発信されたものであるとは見なさない。LDNSリゾルバ107からの情報に基づいて、情報提供DNSサーバ109は、ノースカロライナからの要求に基づいて接続サーバを選択することができ、クライアント105からサンフランシスコへのより短い経路117ではなく、より地理的に長いニューヨークへの経路119が選択される。]
[0014] 情報提供DNSリゾルバ109は、LDNSリゾルバの背後に存在する可能性があるクライアントの数を特定することができない。情報提供リゾルバへの1つの要求は、実際にはLDNSリゾルバの背後の多くのクライアントのためのものである可能性がある。例えば、ACME LDNS107が、クライアント105のドメインに対する1つの要求を行う場合がある。最初の要求後に、ACME LDNS107はドメインのIPアドレスをキャッシュに記憶する。1秒後に、1万件のさらなる要求が同じドメインに対して行われる。LDNSリゾルバのキャッシュにはIPアドレスが記憶されているので、このIPアドレスが自動的にクライアントへ戻され、応答内の有効期間設定により指定された期間の間、情報提供DNSリゾルバへさらなる要求が送信されることはない。従って、サーバが過負荷又は故障状態になり、情報提供DNSサーバ及びGLB109が過負荷又は故障状態のサーバから健全なサーバにクライアントを移行させる必要が生じた場合、情報提供DNSサーバ109は、LDNSリゾルバ107の背後に存在するクライアントの数を特定することができず、適切なロードバランシングを維持することができない。]
[0015] 本発明を、同じ参照数字が類似の要素を示す添付図面の図に限定としてではなく例示として示す。]
図面の簡単な説明

[0016] クライアントがウェブアプリケーションに接続し、DNSベースのGLBを介して様々なデータセンタ内にあるサーバに接続することを示す図である。
本発明の実施形態による、集約サーバが、ウェブビーコンに基づいてクライアントのIPアドレスをLDNSリゾルバのIPアドレスにどのようにマッピングするかを示す図である。
本発明の実施形態による、クライアントのIPアドレス及び特定のコロケーションに基づく接続時間計算テーブルを示す図である。
本発明の実施形態を実施できるコンピュータシステムを示すブロック図である。]
実施例

[0017] LDNSリゾルバの背後に存在するクライアントの数及び場所を特定し、この情報をトラフィックルーティング決定に使用するための技術について説明する。以下の説明では、説明を目的として、本発明の完全な理解をもたらすために数多くの特定の詳細について記載する。しかしながら、これらの特定の詳細を伴わずに本発明を実施できることが明らかであろう。その他の場合、本発明を不必要に曖昧にしないために、周知の構造及び装置についてはブロック図形式で示す。]
[0018] 全体の概要
ある実施形態では、特定のLDNSリゾルバの背後に存在するクライアントの数及び場所を特定するためのデータを生成するために、DNSワイルドカードビーコニングが使用される。次に、このデータを使用して、特定のLDNSリゾルバにより生み出されている負荷及びこの特定のLDNSリゾルバのクライアントがネットワーク内のどこに位置するかを推定する。この情報により、GLBサーバがより賢く正確なルーティング決定を行えるようになる。]
[0019] DNSワイルドカードビーコニング
ある実施形態では、DNSワイルドカードビーコンが既存のウェブアプリケーションから起動される。本明細書で使用する場合、ウェブビーコンは、ピクセルタグ、クリアGIF、又はゼロコンテンツ画像としても知られている透明な又は目に見えないグラフィック画像であり、通常は1x1ピクセル以下である。ある実施形態では、作成ウェブページ内に少量のコード又はビーコンコードを配置することによりウェブビーコンが生成される。クライアントは、作成ウェブページを要求し、データセンタ内のウェブサーバからこれを供給される。作成ウェブページがクライアントにより処理されると、ビーコンコードがクライアントブラウザに、ビーコンコード内で指定されたビーコンサーバからウェブビーコンを取り出させる。要求はクライアントのバックグラウンドで行われるので、ウェブサーバからの現在のウェブページのロードと干渉が起きることはない。]
[0020] ある実施形態では、ウェブビーコンのダウンロードのためのグローバルに一意のワイルドカードホストネームが生成され、このビーコンURLが既存のウェブ結果に埋め込まれ、この画像のダウンロードを進めるクライアントへ送信される。別の実施形態では、HTTP204(すなわち、「ノーコンテンツ」)のダウンロードのためのグローバルに一意のワイルドカードホストネームが生成され、ウェブ結果に配置される。例えば、次のグローバルに一意のワイルドカードホストネームが生成される。
「http://12093898978.dnsb.company.com/onepixel.gif」。
グローバルに一意のワイルドカードホストネームは、(1)一意の英数字の並び(「12093898978」)、(2)ドメインネーム(「*.dnsb.company.com」)、及び(3)取り出されるウェブビーコンオブジェクトの名前(「onepixel.gif」)を含む。]
[0021] クライアントがビーコン画像をダウンロードするための処理を開始した場合、クライアントはまず、一意のホストネームからIPアドレスを導出する必要がある。クライアントが、クライアントのLDNSリゾルバへ要求を送信する。LDNSリゾルバはLDNSリゾルバのキャッシュを調べ、要求内で要求されるホストネームにIPアドレスが利用可能かどうかを判定する。IPアドレスが利用可能な場合、LDNSリゾルバは、ホストネームのIPアドレスで要求に応答することになる。しかしながら、ウェブビーコンのためのホストネームはグローバルに一意であるため、IPアドレスはLDNSリゾルバのキャッシュ内では利用可能でないはずである。]
[0022] ホストネームのIPアドレスがキャッシュから利用できないという理由で、LDNSリゾルバは要求を情報提供DNSリゾルバへ送信する。ある実施形態では、情報提供DNSリゾルバが、要求されたドメイン(この場合は、「dnsb.company.com」)のためのビーコンリゾルバでもある。本明細書で使用する場合、「ビーコンリゾルバ」とは、情報提供DNSリゾルバにおいて受信された要求に基づいて統計値を測定し、ログに記録するサーバのことである。このビーコンリゾルバが、クライアントがウェブビーコンを取り出すことができるIPアドレスも戻す。]
[0023] ある実施形態では、情報提供DNSリゾルバ/ビーコンリゾルバが、ドメイン(「*.dnsb.company.com」)に対する要求にビーコンコレクションサーバのIPアドレスで応答するように構成される。これが行われると、ビーコンリゾルバは、全てのこのような要求に関して(「12093898978.dnsb.company.com」などの)一意のワイルドカードホストネーム及びLDNSリゾルバのIPアドレスをログに記録する。別の実施形態では、ビーコンリゾルバが、ホストネーム内にある一意の英数字の並び(「12093898978」)及びLDNSリゾルバのIPアドレスを記録する。その後、LDNSリゾルバ/ビーコンリゾルバは、ビーコンコレクションサーバのIPアドレスをクライアントへ送信する。]
[0024] この結果、クライアントは、グローバルに一意のホストネームを含む要求を、要求されるURLのためのビーコンコレクションサーバに提出する。クライアントによる要求は、以下に限定されるわけではないが、HTTP、FTP、又はTCPに基づく他のあらゆる通信プロトコルを含むいずれの伝送制御プロトコル(「TCP」)ベースのプロトコルであってもよい。ある実施形態では、クライアントが、同じグローバルに一意のホストネーム(すなわち、「12093898978.dnsb.company.com」)をHTTPホストヘッダに挿入したHTTP要求を、要求されるURLのためのビーコンコレクションサーバに提出する。ビーコンコレクションサーバは、クライアントからHTTP要求を受信する。ビーコンコレクションサーバは、クライアントの一意のワイルドカードホストネーム及びIPアドレスをログに記録する。別の実施形態では、ビーコンコレクションサーバが、クライアントのホストネーム及びIPアドレス内の一意の英数字の並びをログに記録する。ビーコンサーバは、要求の性質に応じて、単一ピクセル、ゼロコンテンツ画像、又はHTTP204をクライアントへ送信することにより要求に応答する。ビーコンリゾルバ内のカーネルモジュールにより、追加の接続品質統計値をログに記録し、測定することができる。]
[0025] ある実施形態による、ウェブビーコン及びこのウェブビーコンを使用してクライアントを特定のLDNSリゾルバにどのようにマッピングするかを示す図を図2に示す。クライアント200がウェブページを要求し、ウェブサーバ202からウェブページを供給されたときに処理が開始する。ウェブページ内にはビーコンコードが存在し、これがクライアント200に、ビーコンコード内で指定された場所からウェブビーコン又はゼロコンテンツ画像を取り出すように指示する。ウェブページがクライアント200によって処理されると、ウェブビーコンの取り出しが開始する。] 図2
[0026] (「12345.dnsb.company.com」などの)グローバルに一意のホストネームがウェブビーコンの場所として使用される。クライアント200は、ホストネームからIPアドレスを導出するために、クライアント200のISPが所有するLDNSリゾルバ204へウェブビーコンに対する要求を送信する。LDNSリゾルバは、まずLDNSキャッシュ内でIPアドレスが利用可能かどうかをチェックする。ホストネームは一意であるので、LDNSリゾルバは、ホストネームに対する要求を情報提供DNSリゾルバへ転送する。情報提供DNSリゾルバは、ホストネーム(すなわち、「*.dnsb.company.com」)のためのビーコンリゾルバ206でもある。ビーコンリゾルバ206は、LDNSリゾルバ204のIPアドレス及びホストネームの一意のワイルドカード(すなわち、「12345」)をログに記録する。次に、ビーコンリゾルバ206は、クライアントがウェブビーコンを要求できるビーコンコレクションサーバ208のIPアドレスをLDNSリゾルバ204へ戻す。LDNSリゾルバ204は、ビーコンコレクションサーバ208のIPアドレスをクライアント200へ転送する。次に、クライアント200は、HTTP要求(「12345.dnsb.company.com」)をビーコンコレクションサーバ208へ送信する。ビーコンコレクションサーバ208は、クライアントから要求を受信し、クライアント200のIPアドレス及びホストネームの一意のワイルドカード(すなわち、「12345」)をログに記録する。ビーコンコレクションサーバ208は、ゼロコンテンツ画像又はHTTP204(ノーダウンロード)ステータスでクライアント200に応答する。]
[0027] データの集約及び処理
ある実施形態では、集約サーバが、ビーコンリゾルバ及びビーコンコレクションサーバからデータを収集する。ビーコンリゾルバからのデータは、LDNSのグローバルに一意のホストネーム及びIPアドレスを含む。ビーコンコレクションサーバからのデータは、クライアントのグローバルに一意のホストネーム及びIPアドレスを含む。このグローバルに一意のホストネームをキーとして使用して、集約サーバは、クライアントのIPアドレスを特定のLDNSのIPアドレスにマッピングすることができる。このようにして、時間をかけてデータを集約することにより、特定のLDNSの背後に存在するクライアントの数及びIPアドレスが特定される。記憶したクライアントのIPアドレスに基づいて、ネットワーク内のクライアントの近接性を特定することもできる。その後、より正確なルーティングを行うために、このデータを集約サーバからGLBサーバにエクスポートすることができる。]
[0028] この処理の図を図2に示す。図2では、ビーコンリゾルバ206が、要求からLDNSリゾルバ204のIPアドレス及びホストネーム内の一意の並び(「12345」)をログに記録している。ビーコンコレクションサーバは、要求からクライアント200のIPアドレス及びホストネーム内の一意の並び(「12345」)をログに記録している。集約サーバ210は、ログに記録されたデータをビーコンリゾルバ206及びビーコンコレクションサーバ208から収集する。集約サーバ210において、一意のホストネームのシーケンスをキーとして使用して、クライアント200のIPアドレスがLDNSリゾルバ204のIPアドレスにマッピングされる。従って、この例では、LDNSリゾルバ204が一意のホストネーム「12345」に関連付けられ、クライアント200が一意のホストネーム「12345」に関連付けられる。ホストネーム(「12345」)がマッチすることにより、クライアント200のIPアドレスがLDNSリゾルバ204のIPアドレスにマッピングされる。GLBサーバがクライアントの近接性及び負荷に基づいて以降の要求をより良好にルーティングするために、LDNSリゾルバ204の背後にクライアント200が存在するという情報が集約サーバ210からGLBサーバ212へ送信される。] 図2
[0029] ある実施形態では、所与のLDNSリゾルバに関連するクライアントIPアドレスの数を求めることにより、特定のLDNSにおける負荷が正確に判断される。例えば、集約されたデータは、1つの特定のLDNSリゾルバが20の異なるクライアントIPアドレスに関連付けられており、別の特定のLDNSリゾルバが5万の異なるクライアントIPアドレスに関連付けられていることを示すことができる。この技術は、LDNSリゾルバから見た要求の種類及び幅に基づいて、負荷に関する推測を強いられるのではなく、LDNSリゾルバからの負荷の正確な判定を可能にする。]
[0030] ある実施形態では、特定のLDNSリゾルバの背後にあるクライアントのIPアドレスを分析することにより、クライアントの近接性マッピングが向上する。クライアントのIPアドレスに基づいて、地理的な及びネットワーク内のクライアントの場所の近似値が求められる。従って、LDNSリゾルバから要求を受信すると、GLBは、ルーティング決定の基礎をLDNSの場所ではなくクライアントの場所に置くことができる。LDNSリゾルバが、LDNSリゾルバの関連するクライアントの場所から離れて位置する場合、ルーティングの向上は最も大きくなる。]
[0031] 集約サーバデータを使用するロードバランシングサーバ
続いて、グローバルロードバランサが集約サーバからのデータをどのように使用できるかの例を説明する。クライアントが特定のウェブページへの訪問を要求したときにグローバルロードバランシングが行われる。DNSルックアップを行って、クライアントにより入力された(「www.yahoo.com」などの)ウェブサイトURLを(「209.131.36.158」などの)IPアドレスに変換する。ルックアップは、まずLDNSリゾルバを対象に行われ、LDNSリゾルバが情報を所有していなければ、(ロードバランシングサーバでもある)情報提供ネームサーバを対象に行われる。ロードバランシングサーバが、LDNSリゾルバの要求側IPアドレスを調べる。次に、要求側IPアドレスが、この特定のネットブロック又はIPアドレスの範囲に関する情報と比較される。ロードバランシングサーバが、近接性及び負荷などの様々な統計値によってソートされたリスト上の第1の利用可能なウェブサーバを選択し、ウェブサーバのIPアドレスをLDNSリゾルバへ戻す。ロードバランシングサーバは、LDNSリゾルバの背後のクライアントに関する追加情報を有することにより、発信元クライアントを接続性が最もよいウェブサーバへより良好にルーティングする。]
[0032] 本発明の実施形態による、集約サーバからのデータをどのように使用するかを示す図を図3に示す。データは、「IPアドレス」列300、「コロケーションA」列302、「コロケーションB」列304、及び「コロケーションC」列306を有する。「IPアドレス」列300は、コロケーションの各々が接続する先のIPアドレスをリストしている。行308において、IPアドレス「1.1.1.0」は、xを0〜255の間のいずれかの数とし得る場合にIPアドレス「1.1.1.x」における機械がコロケーションAに10ミリ秒で、コロケーションBに20ミリ秒で、コロケーションCに40ミリ秒で接続できることを示している。] 図3
[0033] 行310において、IPアドレス「2.2.2.0」は、xを0〜255の間のいずれかの数とし得る場合にIPアドレス「2.2.2.x」における機械がコロケーションAに50ミリ秒で、コロケーションBに80ミリ秒で、コロケーションCに30ミリ秒で接続できることを示している。]
[0034] 集約サーバからのデータは、IPアドレス「5.5.5.5」のLDNSリゾルバが、半分はIPアドレス「1.1.1.x」の、もう半分はIPアドレス「2.2.2.x」のクライアントを含むことを示すことができる。この状況下では、接続時間の平均値を求めることにより、3つの異なるコロケーションセンタへの接続時間を求めることができる。]
[0035] 例えば、行312はIPアドレス「5.5.5.0」を示している。この行はLDNSリゾルバの接続時間を示す。従って、LDNSリゾルバからコロケーションAへの接続時間は、(「1.1.1.0」からの)10ミリ秒と(「2.2.2.0」からの)50ミリ秒との平均値の30ミリ秒となる。LDNSリゾルバからコロケーションBへの接続時間は、(「1.1.1.0」からの)20ミリ秒と(「2.2.2.0」からの)80ミリ秒との平均値の50ミリ秒となる。LDNSリゾルバからコロケーションCへの接続時間は、(「1.1.1.0」からの)40ミリ秒と(「2.2.2.0」からの)30ミリ秒との平均値の35ミリ秒となる。LDNSリゾルバから個々のコロケーションセンタへの接続時間は正確なものではないが、IPアドレスに基づくクライアントの接続時間を考慮に入れることにより正確な推定を行うことができる。]
[0036] ハードウェアの概要
図4は、本発明の実施形態を実施できるコンピュータシステム400を示すブロック図である。コンピュータシステム400は、情報を通信するためのバス402又はその他の通信機構、及び情報を処理するための、バス402に結合されたプロセッサ404を含む。コンピュータシステム400はまた、プロセッサ404により実行される情報及び命令を記憶するための、バス402に結合されたランダムアクセスメモリ(RAM)又はその他の動的記憶装置などのメインメモリ406も含む。メインメモリ406を使用して、プロセッサ404により実行される命令の実行中に一時的変数又はその他の中間情報を記憶することもできる。コンピュータシステム400は、プロセッサ404のための静的情報及び命令を記憶するための、バス402に結合された読出し専用メモリ(ROM)408又はその他の静的記憶装置をさらに含む。情報及び命令を記憶するための磁気ディスク又は光ディスクなどの記憶装置410が提供され、バス402に結合される。] 図4
[0037] コンピュータシステム400を、バス402を介して、コンピュータユーザに情報を表示するためのブラウン管(CRT)などのディスプレイ412に結合することができる。情報及びコマンド選択をプロセッサ404に通信するための英数字及びその他のキーを含む入力装置414がバス402に結合される。別の種類のユーザ入力装置には、方向情報及びコマンド選択をプロセッサ404に通信するとともにディスプレイ412上のカーソルの動きを制御するためのマウス、トラックボール、又はカーソル方向キーなどのカーソル制御416がある。通常、この入力装置は、装置が平面内で位置を特定できるようにする、(xなどの)第1軸及び(yなどの)第2軸の2つの軸の形の2つの自由度を有する。]
[0038] 本発明は、本明細書で説明する技術を実施するためのコンピュータシステム400の使用に関する。本発明の1つの実施形態によれば、これらの技術は、メインメモリ406に含まれる1又はそれ以上の命令の1又はそれ以上の連続をプロセッサ404が実行することに応答してコンピュータシステム400により実行される。このような命令を、記憶装置410などの別の機械可読媒体からメインメモリ406に読み込むことができる。メインメモリ406に含まれる一連の命令を実行することにより、本明細書で説明する処理ステップをプロセッサ404が実行するようになる。代替の実施形態では、ソフトウェア命令の代わりに、又はソフトウェア命令と組み合わせて配線回路を使用して本発明を実施することができる。従って、本発明の実施形態は、ハードウェア回路とソフトウェアとのいずれの特定の組み合わせにも限定されるものではない。]
[0039] 本明細書で使用する「機械可読媒体」という用語は、特定の様式で機械を動作させるデータを提供することに関与するあらゆる媒体のことを意味する。コンピュータシステム400を使用して実施される実施形態では、例えば、実行用のプロセッサ404に命令を提供することに様々な機械可読媒体が関与する。このような媒体は、以下に限定されるわけではないが、記憶媒体及び送信媒体を含む多くの形を取ることができる。記憶媒体として、不揮発性媒体及び揮発性媒体の両方が挙げられる。不揮発性媒体としては、例えば記憶装置410などの光又は磁気ディスクが挙げられる。揮発性媒体としてはは、メインメモリ406などの動的メモリが挙げられる。送信媒体として、バス402を含むワイヤを含む、同軸ケーブル、銅線及び光ファイバーが挙げられる。送信媒体はまた、電波及び赤外線データ通信中に生成されるような音波又は光波の形を取ることもできる。このような媒体は全て、媒体によって運ばれた命令を、機械に命令を読み込む物理機構により検出できるようにするために有形のものでなければならない。]
[0040] 機械可読媒体の共通形式として、例えば、フロッピー(登録商標)ディスク、フレキシブルディスク、ハードディスク、磁気テープ、又は他のあらゆる磁気媒体、CD−ROM、他のあらゆる光媒体、パンチカード、紙テープ、穴のパターンを含む他のあらゆる物理媒体、RAM、PROM、及びEPROM、FLASH−EPROM、他のあらゆるメモリチップ又はカートリッジ、以下で説明するような搬送波、又はコンピュータが読み込むことのできる他のあらゆる媒体が挙げられる。]
[0041] 実行用のプロセッサ404に1又はそれ以上の命令の1又はそれ以上のシーケンスを搬送する際に、様々な形の機械可読媒体を関与させることができる。例えば、最初に命令を遠隔コンピュータの磁気ディスクに記憶して搬送することができる。遠隔コンピュータは、命令を自身の動的メモリにロードし、モデムを使用して電話回線を介して命令を送信することができる。コンピュータシステム400に対してローカルなモデムが、データを電話回線上で受信し、赤外線送信器を使用してこのデータを赤外線信号に変換することができる。赤外線検出器が、赤外線信号の形で搬送されたデータを受信することができ、また適切な回路がこのデータをバス402上に配置することができる。バス402がデータをメインメモリ306に搬送し、ここからプロセッサ304が命令を取り出して実行する。プロセッサ404による実行の前又は後のいずれかに、メインメモリ406により受信された命令を任意に記憶装置410に記憶することができる。]
[0042] コンピュータシステム400は、バス402に結合された通信インターフェイス418を含む。通信インターフェイス418は、ローカルネットワーク422に接続されたネットワークリンク420に結合する双方向データ通信を提供する。例えば、通信インターフェイス418は、対応する種類の電話回線へのデータ通信接続を提供するための統合デジタル通信サービス網(ISDN)カード又はモデムであってもよい。別の例として、通信インターフェイス418は、互換性のあるLANにデータ通信接続を提供するためのローカルエリアネットワーク(LAN)カードであってもよい。無線リンクを実現することもできる。あらゆるこのような実施構成において、通信インターフェイス418は、様々な種類の情報を表すデジタルデータストリームを搬送する電気、電磁又は光信号を送受信する。]
[0043] 通常、ネットワークリンク420は、1又はそれ以上のネットワークを介して他のデータ装置にデータ通信を提供する。例えば、ネットワークリンク420は、ローカルネットワーク422を介してホストコンピュータ424に又はインターネットサービスプロバイダ(ISP)426により動作されるデータ装置に接続を提供することができる。さらにISP426は、現在では一般に「インターネット」428と呼ばれるワールドワイドパケットデータ通信ネットワークを介してデータ通信サービスを提供する。ローカルネットワーク422及びインターネット428はともに、デジタルデータストリームを搬送する電気、電磁又は光信号を使用する。コンピュータシステム400との間でデジタルデータを搬送する、様々なネットワークを介する信号、及び通信インターフェイス418を介するネットワークリンク420上の信号は、情報を伝送する搬送波の例示的な形である。]
[0044] コンピュータシステム400は、(単複の)ネットワーク、ネットワークリンク420及び通信インターフェイス418を介してメッセージを送信するとともに、プログラムコードを含むデータを受信することができる。インターネットの例では、サーバ430が、アプリケーションプログラムに求められるコードをインターネット428、ISP426、ローカルネットワーク422及び通信インターフェイス418を介して送信することができる。]
[0045] プロセッサ404は、受信したコードを受信時に実行することができ、及び/又は後で実行するために記憶装置410、又はその他の不揮発性記憶装置に記憶することができる。このようにして、コンピュータシステム400は、搬送波の形のアプリケーションコードを取得することができる。]
[0046] 上述の明細書では、実施構成に応じて異なり得る数多くの特定の詳細を参照しながら本発明の実施形態について説明した。従って、本発明が何であるか、及び出願人が何を発明として意図しているかを示す唯一かつ排他的なものが、本出願に由来する特許請求の範囲の組であり、このような特許請求の範囲が発行される特定の形には今後のあらゆる補正が含まれる。本明細書に明確に示す、このような特許請求の範囲に含まれる用語のあらゆる定義が、特許請求の範囲で使用するこのような用語の意味を規定するものとする。従って、特許請求の範囲に明確に記載していない限定事項、要素、特性、特徴、利点又は属性により、決してこのような特許請求の範囲を限定すべきではない。従って、明細書及び図面については限定的な意味ではなく例示的な意味でとらえるべきである。]
[0047] 101サンフランシスコのコロケーション
103ニューヨークのコロケーション
105クライアント
107ACMELDNSリゾルバ
109情報提供DNSリゾルバ
111 要求
115 要求
117 サンフランシスコへの経路
119 ニューヨークへの経路]
权利要求:

請求項1
コンピュータにより実行される方法であって、複数のクライアントの個々のクライアントに関して、(a)識別値及び(b)特定のLDNSサーバを識別するデータを含む第1の接続データを第1のサーバから受信することと、(c)前記識別値及び(d)複数のLDNSサーバのうちの特定のLDNSサーバの背後に存在する特定のクライアントを識別するデータを含む第2の接続データを第2のサーバから受信することと、前記第2の接続データの前記特定のクライアントの識別値を前記第1の接続データの前記特定のLDNSサーバの識別値とマッチさせることにより、前記特定のクライアントを識別する前記データを、前記特定のLDNSサーバを識別する前記データにマッピングすることと、を実行するステップと、前記特定のLDNSサーバを識別する前記データにマッピングされた前記特定のクライアントを識別する前記データを集約することにより、前記クライアントと、該クライアントを背後に有する前記LDNSサーバとの間のマッピングを作成するステップと、前記マッピングをコンピュータ可読媒体に記憶するステップと、を含むことを特徴とする方法。
請求項2
前記マッピングをコンピュータ可読媒体に記憶する際に前記マッピングをロードバランシングサーバに出力して、該ロードバランシングサーバが前記複数のLDNSサーバからの後続のメッセージをどのようにルーティングするかを決定する際に使用するようにするステップをさらに含む、ことを特徴とする請求項1に記載の方法。
請求項3
特定のLDNSサーバを識別するデータがIPアドレスを含む、ことを特徴とする請求項1に記載の方法。
請求項4
特定のクライアントを識別するデータがIPアドレスを含む、ことを特徴とする請求項1に記載の方法。
請求項5
第1の接続データが、前記特定のLDNSサーバから前記第1のサーバへのDNS要求に基づく、ことを特徴とする請求項1に記載の方法。
請求項6
前記DNS要求が、前記クライアントに供給されるウェブビーコンコードから生じる、ことを特徴とする請求項5に記載の方法。
請求項7
第2の接続データが、前記特定のクライアントから前記第2のサーバへのHTTP要求に基づく、ことを特徴とする請求項1に記載の方法。
請求項8
前記HTTP要求が、前記クライアントに供給されるウェブビーコンコードから生じる、ことを特徴とする請求項7に記載の方法。
請求項9
後続のメッセージをどのようにルーティングするかを決定するステップが、LDNSサーバの背後に存在するクライアントの近接性に基づく、ことを特徴とする請求項2に記載の方法。
請求項10
後続のメッセージをどのようにルーティングするかを決定するステップが、特定のLDNSサーバの背後に存在するクライアントの数に基づく、ことを特徴とする請求項2に記載の方法。
請求項11
前記HTTP要求が、クライアントが一意のホストネームにおけるゼロコンテンツ画像を取り出すことに基づく、ことを特徴とする請求項7に記載の方法。
請求項12
1又はそれ以上の一連の命令を保持するコンピュータ可読媒体であって、前記1又はそれ以上の一連の命令が、1又はそれ以上のプロセッサにより実行された場合、該1又はそれ以上のプロセッサに、複数のクライアントの個々のクライアントに関して、(a)識別値及び(b)特定のLDNSサーバを識別するデータを含む第1の接続データを第1のサーバから受信することと、(c)前記識別値及び(d)複数のLDNSサーバのうちの特定のLDNSサーバの背後に存在する特定のクライアントを識別するデータを含む第2の接続データを第2のサーバから受信することと、前記第2の接続データの前記特定のクライアントの識別値を前記第1の接続データの前記特定のLDNSサーバの識別値とマッチさせることにより、前記特定のクライアントを識別する前記データを、前記特定のLDNSサーバを識別する前記データにマッピングすることと、を実行するステップと、前記特定のLDNSサーバを識別する前記データにマッピングされた前記特定のクライアントを識別する前記データを集約することにより、前記クライアントと、該クライアントを背後に有する前記LDNSサーバとの間のマッピングを作成するステップと、前記マッピングをコンピュータ可読媒体に記憶するステップと、を実行させることを特徴とするコンピュータ可読媒体。
請求項13
前記マッピングをコンピュータ可読媒体に記憶する際に前記マッピングをロードバランシングサーバに出力して、該ロードバランシングサーバが前記複数のLDNSサーバからの後続のメッセージをどのようにルーティングするかを決定する際に使用するようにするステップをさらに含む、ことを特徴とする請求項12に記載のコンピュータ可読媒体。
請求項14
特定のLDNSサーバを識別するデータがIPアドレスを含む、ことを特徴とする請求項12に記載のコンピュータ可読媒体。
請求項15
特定のクライアントを識別するデータがIPアドレスを含む、ことを特徴とする請求項12に記載のコンピュータ可読媒体。
請求項16
第1の接続データが、前記特定のLDNSサーバから前記第1のサーバへのDNS要求に基づく、ことを特徴とする請求項12に記載のコンピュータ可読媒体。
請求項17
前記DNS要求が、前記クライアントに供給されるウェブビーコンコードから生じる、ことを特徴とする請求項16に記載のコンピュータ可読媒体。
請求項18
第2の接続データが、前記特定のクライアントから前記第2のサーバへのHTTP要求に基づく、ことを特徴とする請求項12に記載のコンピュータ可読媒体。
請求項19
前記HTTP要求が、前記クライアントに供給されるウェブビーコンコードから生じる、ことを特徴とする請求項18に記載のコンピュータ可読媒体。
請求項20
後続のメッセージをどのようにルーティングするかを決定するステップが、LDNSサーバの背後に存在するクライアントの近接性に基づく、ことを特徴とする請求項13に記載のコンピュータ可読媒体。
請求項21
後続のメッセージをどのようにルーティングするかを決定するステップが、特定のLDNSサーバの背後に存在するクライアントの数に基づく、ことを特徴とする請求項13に記載のコンピュータ可読媒体。
請求項22
前記HTTP要求が、クライアントが一意のホストネームにおけるゼロコンテンツ画像を取り出すことに基づく、ことを特徴とする請求項18に記載のコンピュータ可読媒体。
类似技术:
公开号 | 公开日 | 专利标题
US9887915B2|2018-02-06|Request routing based on class
US10523783B2|2019-12-31|Request routing utilizing client location information
US9800539B2|2017-10-24|Request routing management based on network components
US10230819B2|2019-03-12|Translation of resource identifiers using popularity information upon client request
US10264062B2|2019-04-16|Request routing using a popularity identifier to identify a cache component
US20190297137A1|2019-09-26|Point of presence management in request routing
US9160703B2|2015-10-13|Request routing management based on network components
US20180302465A1|2018-10-18|Point of presence management in request routing
US9026661B2|2015-05-05|Systems and methods for traffic management using load metrics reflective of a requested service
EP2852125B1|2018-05-30|Server selection for content distribution
US20190044787A1|2019-02-07|Point of presence management in request routing
US9734472B2|2017-08-15|Request routing utilizing cost information
US8495220B2|2013-07-23|Managing CDN registration by a storage provider
US10706029B2|2020-07-07|Content name resolution for information centric networking
US9906436B2|2018-02-27|Scalable name-based centralized content routing
US8612564B2|2013-12-17|Method and system for handling computer network attacks
US8805965B2|2014-08-12|Methods and apparatus for image delivery
US8825849B2|2014-09-02|Distributed data collection and aggregation
US10742550B2|2020-08-11|Updating routing information based on client location
US9553930B2|2017-01-24|DNS overriding-based methods of accelerating content delivery
US7996533B2|2011-08-09|HTML delivery from edge-of-network servers in a content delivery network |
EP2708013B1|2015-07-22|A method for DNS resolution of content requests in a CDN service
US7904345B2|2011-03-08|Providing website hosting overage protection by transference to an overflow server
US7653700B1|2010-01-26|System and method for performing client-centric load balancing of multiple globally-dispersed servers
US7143184B1|2006-11-28|System and method for measuring round trip times in a network using a TCP packet
同族专利:
公开号 | 公开日
US20140181287A1|2014-06-26|
EP2223470B1|2019-02-20|
JP2012257338A|2012-12-27|
WO2009085670A1|2009-07-09|
AU2008343434A1|2009-07-09|
TW200943878A|2009-10-16|
US8756340B2|2014-06-17|
TWI392316B|2013-04-01|
CN101904135B|2015-06-03|
HK1151398A1|2012-01-27|
US20090164614A1|2009-06-25|
AU2008343434B2|2012-02-23|
KR101154799B1|2012-06-18|
EP2223470A1|2010-09-01|
EP2223470A4|2016-04-27|
KR20100103619A|2010-09-27|
US9577919B2|2017-02-21|
JP5103530B2|2012-12-19|
JP5438811B2|2014-03-12|
CN101904135A|2010-12-01|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题
法律状态:
2012-02-03| A977| Report on retrieval|Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20120203 |
2012-04-06| A131| Notification of reasons for refusal|Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120405 |
2012-07-06| A601| Written request for extension of time|Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20120705 |
2012-07-13| A602| Written permission of extension of time|Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20120712 |
2012-08-07| A521| Written amendment|Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120806 |
2012-08-22| TRDD| Decision of grant or rejection written|
2012-08-31| A01| Written decision to grant a patent or to grant a registration (utility model)|Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120830 |
2012-09-06| A01| Written decision to grant a patent or to grant a registration (utility model)|Free format text: JAPANESE INTERMEDIATE CODE: A01 |
2012-10-04| A61| First payment of annual fees (during grant procedure)|Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20121001 |
2012-10-05| R150| Certificate of patent or registration of utility model|Ref document number: 5103530 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
2012-10-05| FPAY| Renewal fee payment (event date is renewal date of database)|Free format text: PAYMENT UNTIL: 20151005 Year of fee payment: 3 |
2015-05-08| S111| Request for change of ownership or part of ownership|Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
2015-05-18| R350| Written notification of registration of transfer|Free format text: JAPANESE INTERMEDIATE CODE: R350 |
2015-08-25| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2016-08-16| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2016-11-21| S531| Written request for registration of change of domicile|Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
2016-11-30| R350| Written notification of registration of transfer|Free format text: JAPANESE INTERMEDIATE CODE: R350 |
2017-08-15| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2018-08-14| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2019-09-24| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2019-10-29| S533| Written request for registration of change of name|Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
2019-12-25| R350| Written notification of registration of transfer|Free format text: JAPANESE INTERMEDIATE CODE: R350 |
2020-03-03| S111| Request for change of ownership or part of ownership|Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
2020-03-11| R350| Written notification of registration of transfer|Free format text: JAPANESE INTERMEDIATE CODE: R350 |
2020-03-19| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2020-12-17| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
优先权:
申请号 | 申请日 | 专利标题
[返回顶部]