JP7336472B2 - 通信ネットワークを介したネットワークトラフィックのトレーサビリティの決定 - Google Patents

Description

（関連する米国のアプリケーションへの相互参照）
この出願は、２０１８年１２月１７日に提出された米国特許出願第１６／２２２，６８５号から優先権を主張する。これは、２０１８年３月６日に提出された米国特許出願第１５／９１３，５８０号の一部継続出願であり、現在係属中である。その内容全体は、それらへの明示的な参照により本明細書に組み込まれる。

（技術分野）
本発明は、コンピュータネットワークに関し、より詳細には、ネットワークトラフィックの監視に関する。

現在、大容量の通信ネットワーク環境でリアルタイムにトラフィックのトレーサビリティを決定することは困難である。個々のパケットは、パラメータとして埋め込まれた送信元アドレスを有する。しかし、これらのパラメータの信頼性を決定することは困難である。非認証の送信元アドレスパラメータを持つパケットは、そのパラメータへの唯一の参照によって「追跡可能ではない（not traceable）」と言われる。初期の頃に計算及びネットワーク容量の実際的な制限を反映したトランザクションネットワークプロトコル（ＤＮＳプロトコルなど）のステートレストランスポートは、ネットワーク要求（クエリなど）の負荷が増加し、アプリケーションのパフォーマンスに対する要求も高まっているため、今日でも重要である。さらに、計算及び接続のコストは、劇的に減少したため、トランザクションのレイテンシ及び非一貫性に対するトレランス（tolerance）を有する。通信ネットワークを介したステートレストランスポートは効率的であるが、ネットワークベースのトランザクションに対してクライアントの効果的なトレーサビリティを提供することができない。ＤＮＳプロトコルは、他の多くのトランザクションプロトコルと同様に、一般的に小さな要求及び大きな応答を伴うため、ペイロードの増幅が攻撃者によって悪用される可能性がある。たとえば、ステートレスなトランスポート及びクライアントのトレーサビリティの欠如とともに、グローバルに利用可能な多数のサーバは、ペイロードの増幅をネットワーク攻撃の一般的なメカニズムにする。たとえば、ＤＮＳ増幅攻撃はリフレクションベースの分散型サービス拒否（ＤＤｏｓ）攻撃であり、攻撃者はドメインネームシステム（ＤＮＳ）サーバへのルックアップ要求を偽装して、悪用のソースを隠し、応答を目標に向ける。様々な手法を通じて、攻撃者は小さなＤＮＳクエリをターゲットネットワークに向けられたはるかに大きなペイロードに変える。限られたクライアントのプールへの使用を制限することにより、利用可能な増幅器のプールからＤＮＳリゾルバを排除することにある程度の成功が見られた一方で、そのような制約は、例外なく通信ネットワーク全体にサービスを提供することを目的とした権限のあるサーバに対して妥当というわけではない。

ネットワークの輻輳の一例として、過去数年間で最も深刻な攻撃は、接続が良好で高度に分散された多数の攻撃トラフィックソースによって特徴付けられており、増幅器をさらに悪用して、一連の犠牲者に対して比較的短期間に調整されたペイロードを配信する。トラフィックソースは、一般に事前準備された消費者向けデバイスであり、コマンドおよび制御インフラストラクチャからの指示に応答する用意及び準備ができている。これらのデバイスが一般的に消費者向けネットワークにインストールされているということは、（ａ）高度に分散されている、（ｂ）接続性がますます向上している、（ｃ）パッチが入手可能であっても定期的にアップグレードされる可能性が非常に低い、及び（ｄ）人間のオペレータに連絡できるという実用的な期待がないことから、高い関連性を有する。これらのデバイスは、サイズ及び機能が増加し続けるボットネットを表し、この傾向が減少することになるとは実際には予想されていない。フォレンジック分析の一部として、アクセスプロバイダにリアルタイム及び事後の両方で攻撃の軽減を調整させるように多大な努力が払われているが、ボットネットをソースとする攻撃の観測された影響は依然として高いままである。そのようなデバイスがソーススプーフィングされたトラフィックを配信する機会を減らすための取り組みは、部分的に普遍的ではないため（及び部分的に住宅用ネットワークが境界でのネットワークアドレス変換の動作によって自己修復する傾向があるため）、ほとんど効果を奏さないが、主に、あなたのボットネットが十分に大きい場合、増幅器を使用する必要はあまりないからである。近年、サービス拒否ビジネスの共犯者から被害者へのＤＮＳサーバの昇格が見られる。

さらに、サービス拒否編成（orchestration）において繁栄している市場の存在（およびその市場の一部としての増幅器またはターゲットとして機能するＤＮＳサーバの使用）は、インターネットにアクセス可能なサービスに関して可用性及び性能の重要性をいくらか脱線した皮肉な例示であると認識される：皮肉なことに、攻撃が低下しようとする性能自体が、攻撃トラフィックを増幅する（または弱くする）ために使用されるネットワーク（ＤＮＳなど）インフラストラクチャの性能及び可用性によってフレーム化される。たとえば、権限のあるＤＮＳサービスのオペレータは、正当な要求トラフィックに対して応答性の高い高可用性ＤＮＳサービスを同時に提供すると同時に、どちらかを区別する明確な方法なしに不正なトラフィックに関するサービスを抑制し、競争が要求と応答の間のレイテンシを可能な限りゼロに近づけることを要求する環境でのリアルタイムの扱いにくい決定を実現するという不可解な仕事を有している。

本開示の１つの利点は、上記の欠点の少なくとも１つを未然に防ぐまたは軽減するためのトレーサビリティシステムまたは方法を提供することである。

現在、大容量の通信ネットワーク環境でリアルタイムにトラフィックのトレーサビリティを決定することは困難である。個々のパケットは、パラメータとして埋め込まれた送信元アドレスを有する。しかし、これらのパラメータの信頼性を判断することは困難である。非認証の送信元アドレスパラメータを持つパケットは、そのパラメータへの唯一の参照によって「追跡可能ではない（not traceable）」と言われる。これらの問題の１つの解決策は、サーバと事前に定められたソースとの間の通信ネットワーク上に直接的な相互接続をプロビジョニング（provisioning）するステップであって、直接的な相互接続は、事前に定められたソースと、事前に定められたソースからアドレス指定されたネットワーク要求トラフィックを受信するように構成されたサーバとの間のプライベートサービスインターフェースを提供し、直接的な相互接続を有する事前に定められたソースの定義されたペアリングデータは、ネットワークトラフィックのアルマナック（almanac）としてストレージに格納される、ステップと；事前に定められたソースおよび他のソースからアドレス指定されたネットワーク要求トラフィックを受信するように構成された通信ネットワーク上でパブリックサービスインターフェースをプロビジョニングするステップであって、パブリックサービスインターフェースは直接的な相互接続とは別個である（separate from）、ステップと；パブリックサービスインターフェースを介して事前に定められたソースのアドレスを有する要求トラフィックを受信するステップと；要求トラフィックが事前に定められたソースと一致するかどうかを決定するために、定められたペアリングデータをアドレスと照合（consult）するステップと；応答トラフィックを生成する前に優先順位付け基準を要求トラフィックに動的に適用することにより、直接的な相互接続ではなくパブリックサービスインターフェースで受信される要求トラフィックに基づいて、要求トラフィックの処理の優先順位を下げる（de-prioritizing）ステップと、によってトラフィック処理リソースの負担を軽減するために通信ネットワーク上のネットワーク要求トラフィックのトレーサビリティを決定することである。

提供される一態様は、トラフィック処理リソースの負担を軽減するために通信ネットワーク上のネットワーク要求トラフィックのトレーサビリティを決定するための方法であり、この方法は以下のステップ：サーバが：サーバと事前に定められたソースとの間の通信ネットワーク上に直接的な相互接続をプロビジョニングするステップであって、直接的な相互接続は、事前に定められたソースと事前に定められたソースからアドレス指定されたネットワーク要求トラフィックを受信するように構成されたサーバとの間のプライベートサービスインターフェースを提供し、直接的な相互接続を有する事前に定められたソースの定義されたペアリングデータは、ネットワークトラフィックのアルマナックとしてストレージに格納される、ステップと；事前に定められたソースおよび他のソースからアドレス指定されたネットワーク要求トラフィックを受信するように構成された通信ネットワーク上でパブリックサービスインターフェースをプロビジョニングするステップであって、パブリックサービスインターフェースは直接的な相互接続とは別個である、ステップと；直接的な相互接続を介して事前に定められたソースからアドレス指定された第１の要求トラフィックを受信するステップと；第１のクエリ応答を生成し、通信ネットワークを介して事前に定められたソースに通信するための直接およびパブリックサービスインターフェースの少なくとも１つを介して第１のクエリ応答を送信することによって、第１の要求トラフィックを処理するステップと；パブリックサービスインターフェースを介して、事前に定められたソースのアドレスを有する第２の要求トラフィックを受信するステップと；要求トラフィックが事前に定められたソースと一致するかどうかをするために、定められたペアリングデータをアドレスと照合するステップと；第２の応答トラフィックを生成する前に優先順位付け基準を第２の要求トラフィックに動的に適用することにより、直接的な相互接続ではなくパブリックサービスインターフェースで受信される第２の要求トラフィックに基づいて、第２の要求トラフィックの処理の優先順位を下げるステップと；を含む。

提供されるさらなる態様は、トラフィック処理リソースの負担を軽減するために通信ネットワークを介したネットワーク要求トラフィックのトレーサビリティを決定するためのサーバであって、システムは、サーバと事前に定められたソースとの間の通信ネットワーク上に直接的な相互接続をプロビジョニングし、直接的な相互接続は、事前に定められたソースと、事前に定められたソースからアドレス指定されたネットワーク要求トラフィックを受信するように構成されたサーバとの間でのプライベートサービスインターフェースを提供し、直接的な相互接続を有する事前に定められたソースの定義されたペアリングデータは、ネットワークトラフィックのアルマナックとしてストレージに格納され；事前に定められたソースおよび他のソースからアドレス指定されたネットワーク要求トラフィックを受信するように構成された通信ネットワーク上でパブリックサービスインターフェースをプロビジョニングし、パブリックサービスインターフェースは直接的な相互接続とは別個であり；直接的な相互接続を介して事前に定められたソースからアドレス指定された第１の要求トラフィックを受信することと；第１のクエリ応答を生成し、通信ネットワークを介して事前に定められたソースに通信するための直接およびパブリックサービスインターフェースの少なくとも１つを介して第１のクエリ応答を送信することによって、第１の要求トラフィックを処理し；パブリックサービスインターフェースを介して、事前に定められたソースのアドレスを有する第２の要求トラフィックを受信し；要求トラフィックが事前に定められたソースと一致するかどうかをするために、定められたペアリングデータをアドレスと照合し；第２の応答トラフィックを生成する前に優先順位付け基準を第２の要求トラフィックに動的に適用することにより、直接的な相互接続ではなくパブリックサービスインターフェースで受信される第２の要求トラフィックに基づいて、第２の要求トラフィックの処理の優先順位を下げる；ようにコンピュータプロセッサを構成するために、ストレージに格納された命令のセットを有するコンピュータプロセッサを備える。

次に、本発明の例示的な実施形態は、単なる例として、以下の図面と併せて説明されることとなる。

通信ネットワークシステムの構成要素のブロック図である。 図１のシステムのための例示的なトレーサビリティサービスのブロック図である。 図２のトレーサビリティサービスをホストするコンピュータデバイスの構成例である。 図２のトレーサビリティサービスをホストするコンピュータデバイスの別の構成例である。 図２のトレーサビリティサービスの実装例である。 要求側サーバが応答側サーバとは独立してネットワーク要求を処理する例示的な実施形態である。

図１を参照すると、ネットワーク１４、１６、１８（例えば、論理的または物理的なネットワーク構成であり得る１つ以上のネットワーク）に結合された一連のネットワークデバイス９間のネットワークトラフィック７の配信（例えばコンテンツ配信）を容易にするための通信ネットワークシステム６が示される。以下でさらに説明するようなネットワークインターフェース３４、３６を参照する、エニーキャストサービス配信（anycast service distribution）及びパートナー固有の相互接続のネットワーク１４、１６、１８（例えば、インターネット全体（Internet-wide））の組み合わせを使用して、クライアントネットワークトラフィック７（例えば、限定されないが、ＤＮＳリゾルバなどのネットワークデバイス９から受信または送信されるトラフィック７）を扱うための一般的なアプローチについて説明する。ネットワークデバイス９は、ソーストラフィック３０を生成するソースデバイス８を含むことができ、これは応答側サーバ１０に直接通信されることができ、および／またはソーストラフィック３０を応答側サーバ１２に通信するためにソースデバイス８に代わって動作する要求側サーバ１２を介して応答側サーバ１０に向けられることにより間接的に通信されることができる。一般に、ソーストラフィック３０は、ネットワーク要求トラフィック３０（例えば、クエリ）と呼ばれ、通信ネットワーク１４、１６、１８を介して応答側サーバ１０に到達し、最終的には、このサーバがネットワークトラフィック要求３０の処理及び適切なネットワークトラフィック応答３２（たとえば、クエリ応答）の生成を担当する。通信ネットワークシステム６は、さらに以下に説明するように、クライアントクエリ（例えば、ネットワークトラフィック７）およびデータ収集システム５０（図２を参照）を使用する関連付けられたデータ収集に応答する実用的な事項を容易にするサービスインフラストラクチャで構成されると認識される。特に、データ収集システム５０によって実行されるデータ分析は、データ収集システム５０のデータ収集機能によって供給されるトラフィックデータ３８（例えば、ペアリングデータ３８－図１を参照）で提供される。ペアリングデータ３８のデータ分析およびその後の動的生成は、以下にさらに説明するように、通信ネットワークシステム６（たとえば、データ管理システム５２－図２を参照）によって使用され、ペアリングデータ３８に関連付けられる１つまたは複数の優先順位付け基準３９を介してインバウンドネットワークトラフィック７（例えば、限定されないが、ＤＮＳクエリなどの要求）の自動／手動管理のための見識（insight）及び機会を提供する。システム５０、５２は、トレーサビリティシステム５３と呼ぶことができ、必要に応じて別個のサーバ５５および／または応答側サーバ１０でホストすることができると認識される。

要求側サーバ１２の例は、限定されないが：重要な依存するエンドユーザコミュニティを有するリゾルバトラフィックのソースであり得るパブリックＤＮＳリゾルバオペレータ（例えばGoogle（登録商標）のパブリックＤＮＳ）；ソーシャルメディアサービスを供給するアプリケーションサービスプロバイダ（例えばFacebook（登録商標））；ダウンストリームＷｅｂプロパティに関するＨＴＴＰ層セッション終了を提供するアプリケーションサービスプロバイダ（例えばCloudflare（登録商標））；およびＷｅｂベースのＡＰＩとユーザインターフェースとを利用するインターネットを介してエンドユーザにサービスを提供するアプリケーションサービスプロバイダ；などのサーバを含むことができる。要求側サーバ１２の他の例は、限定されないが、ＩｏＴデバイスなどのネットワークソースデバイス８に結合されるサーバ（例えばＤＮＳリゾルバ）を操作したアクセスプロバイダ（Comcast（登録商標）などのインターネットサービスプロバイダとも呼ばれる）によって操作されるこれら；およびその顧客によって操作されるコネクティドソースデバイス（connected source device）８を含むテナント環境などのネットワークソースデバイス８に結合されるサーバを操作したクラウドプロバイダ（例えば、Amazon（登録商標）、Digital Ocean（登録商標））；などのサーバを含むことができる。応答側サーバ１０および／または応答側ネットワーク１８の他の部分（例えば１つまたは複数のネットワークデバイス２２）のネットワークトラフィック７の受信および／または処理能力（例えばトラフィック対応および処理容量）は、経験するネットワークトラフィック７の量の予期しないおよび定期的な急増のため、負担になり得る。ネットワークトラフィック７の予期しない急増の一例は、一般に応答側ネットワーク１８および／または特定の応答側サーバ１０に向けられたサービス拒否攻撃が原因である可能性がある。予期しない急増は、適切なネットワーク応答トラフィック３２を受信、処理、および受信したネットワーク要求トラフィック３０に送信するためのサービス品質（例えば応答時間）に影響を与える可能性がある。これらの状況では、応答側機器の影響を受ける部分が、受信したネットワークトラフィック７に優先順位を付けることにより負荷リソース容量を軽減することができ、それによって応答側機器のリソース容量の最適化を促進することが好ましい。例えば、ＤＮＳ環境では、受信されたＤＮＳクエリ３０に対する応答３２の許容可能なタイミングは、約１５ミリ秒以下であり得る。

通信ネットワークシステム６の通信ネットワークは、１つのネットワークデバイス８から他にコンテンツデータ４１（すなわち、ネットワーク要求トラフィック３０、ネットワーク応答トラフィック３２－例えば、対応する応答データ３２に関連付けられ／組み合わせられたクエリ／要求データ３０を含む表形式データ４１として）を転送するのに適した１つまたは複数のネットワーク１４、１６、１８を含むことができる。また、サーバ１０、１２が最終的な顧客（例えば、ネットワークソースデバイス８）に関してコンテンツデータ４１を利用し、したがってサービスすることに関して使用される特定のネットワーク１４、１６、１８に関連するため、コンテンツデータ４１は、分析データ６０として提供されるペアリングデータ３８および優先順位付けデータ３９と関連付けられ得ることが認識される。応答側ネットワーク１８でホストされるペアリングデータ３８および優先順位付けデータ３９は、マスター分析データ６０と呼ばれ得る。要求側ネットワーク１４でホストされるペアリングデータ３８ａおよび優先順位付けデータ３９ａは、コピー分析データ６０ａがマスター分析データ６０ａのサブセットであり得ることを認識して、コピー分析データ６０ａと呼ばれ得る。

好ましくは、通信ネットワーク１１は、パブリックネットワーク１６（例えば、インターネット）などの広域ネットワークと、例えば要求側ネットワーク１４および応答側ネットワーク１８などの１つまたは複数のローカルエリアネットワークとを含む。ネットワーク１４、１６、１８は、ネットワークデバイス９の任意のペアの間に構成された所望の単一または複数のネットワークであり得ると認識される。例えば、要求側サーバ１２および応答側サーバ１０は、同じまたは異なるネットワーク１４、１６、１８（すなわち、１つまたは複数）上にあり得る。さらに、ネットワーク１４、１６、１８は、地上にある（land-based）ネットワークタイプである必要はないが、代わりに、通信の柔軟性を高めるために、無線ネットワークタイプおよび／または地上にあるネットワークタイプと無線ネットワークタイプとのハイブリッドを含むことができる。例えば、通信ネットワーク１４、１６、１８はまた、Ｂｌｕｅｔｏｏｔｈ（登録商標）関連要素を含むことができる。ネットワークデバイス９は、クライアント－サーバ関係でネットワーク１４、１６、１８を介して互いに通信できると認識される。例えば、要求側ネットワーク１４は、要求側サーバ１２を操作するエンティティによって所有され、コンピュータまたは他の電子デバイス（たとえば、デバイス８、１２）を一緒に接続するために使用されるネットワークコンポーネントとして機能する１つ又は複数のローカルネットワークデバイス２０（例えば、ルータ、ハブ、スイッチ）を含むことができる。その結果、それらは、ファイルまたはリソース（たとえば、ネットワークトラフィック要求３０および応答３２）を互いに交換することができる。例えば、応答側ネットワーク１８は、応答側サーバ１０を操作するエンティティによって所有され、コンピュータまたは他の電子デバイス（例えば、デバイス１０、データベースなどのストレージ２４）を一緒に接続するために使用されるネットワーク構成要素として機能する１つまたは複数のローカルネットワークデバイス２２（例えばルーター、ハブ、スイッチ）を含むことができる。その結果、それらは、互いにファイルまたはリソース（すなわち、ネットワークトラフィックの要求３０および応答３２）を交換することができる。例えば、パブリックネットワーク１６は、広域ネットワーク１６（例えばインターネット）を操作する１つまたは複数のエンティティによって所有され、コンピュータまたは他の電子デバイス（例えば、２０、２２）を一緒に接続するために使用されるネットワーク構成要素として機能する１つまたは複数のグローバルネットワークデバイス２０（例えばルーター、ハブ、スイッチ）を含むことができる。その結果、それらは、広域ネットワーク１６に結合される他のネットワーク１４、１８を用いてファイルまたはリソース（すなわち、ネットワークトラフィックの要求３０および応答３２）を交換することができる。したがって、１つまたは複数のローカルネットワークデバイス２０は、要求側ネットワーク１４の周辺／境界上にあることができ、ネットワーク１４、１６間のネットワークトラフィック７のためのブリッジとして使用されると認識される。したがって、ローカルネットワークデバイス２２のうちの１つまたは複数は、応答側ネットワーク１８の周辺／境界上にあることができ、ネットワーク１６、１８間のネットワークトラフィック７のためのブリッジとして使用され得ると認識される。

例えば、ネットワーク１６は、ネットワーク１６、１８間のブリッジデバイスとして機能するネットワークデバイス２１を含むサブネットワーク１６ａを有することができる。したがって、応答側サーバ１０に関連付けられたトレーサビリティシステム５１は、サブネットワーク１６ａ内のこれらのデバイス２１の動作を介して、あるレベルの制御／提案（たとえば、優先コマンド４０－図２を参照）を実装することができる。同様に、ネットワーク１８は、ネットワーク１６、１８間のブリッジデバイスとして機能するネットワークデバイス２２を含むサブネットワーク１８ａを有することができる。したがって、応答側サーバ１０に関連するトレーサビリティシステム５１は、サブネットワーク１８ａ内のこれらのデバイス２２の動作を介して、あるレベルの制御／提案（例えば、優先コマンド４０－図２を参照）を実装することができる。

ソース／要求トラフィック３０および応答トラフィック３２は、一般的なネットワークトラフィック７の形態であると認識されている。例えば、ソース／要求トラフィック３０は、ローカル要求側ネットワーク１４を介して送信されるネットワークトラフィックと呼ぶことができ、応答トラフィック３２は、ローカル要求側ネットワーク１４を介して受信されるネットワークトラフィックと呼ぶことができる。応答トラフィック３２は、ローカル応答側ネットワーク１８を介して送信されるネットワークトラフィックと呼ぶことができ、要求トラフィック３０は、ローカル応答側ネットワーク１８を介して受信されるネットワークトラフィックと呼ぶことができる。広域ネットワーク１６（例えば、パブリックネットワークまたはインターネット）を介して通信された（送信および受信の両方－事実上１つのネットワーク１４、１８から別のネットワークに転送する）要求／応答トラフィック３０、３２は、一般的なネットワークトラフィック７と呼ぶことができる。要求／応答トラフィック３０、３２のデータは、ネットワーク応答３２のトラフィックとしてソースデバイス８に後で送り返すための対応するネットワーク応答３０のデータをコンテンツデータ４１から検索するために受信したネットワーク要求３０のデータがコンテンツデータ４１（データベースなど）のイントロゲート（interrogate）／照合（consult）に使用されるように、関連する要求／応答コンテンツとしてコンテンツデータ４１に含まれると認識される。

通信ネットワークシステム６の一例は、コンテンツデータ４１から検索し、ネットワーク１４、１６、１８を介して適切な応答３２のデータを送信するためにクエリ３０のデータを用いてコンテンツデータ４１を照合すると、要求側サーバ１２がそれらのローカルネットワーク（たとえば、要求側ネットワーク１４）上の全てのクライアント（たとえば、ソースデバイス８などのエンドユーザ）のＤＮＳ要求３０を管理するためのローカルサーバとして機能するＤＮＳリゾルバサーバであるように、ドメインネームサーバ（ＤＮＳ）クエリ３０に応答３２を提供するための権限のあるネームサーバ（authoritative name server）１０として機能する応答側サーバ１０であり得る。この例では、権限のあるネームサーバ１０は、ＤＮＳデータレコード情報をコンテンツデータ４１に格納できると認識する－例えば、データベース２４内の電子メール配信用のＩＰアドレス及びメールエクスチェンジャ。再帰／リゾルバネームサーバ１２がＤＮＳツリーを再帰して要求されたドメインのレコードを格納する権限のあるネームサーバに到達するため、再帰／リゾルバネームサーバ１２は権限のあるサーバ１０とエンドユーザデバイス８（Ｗｅｂブラウザなど）との間の「仲介者（middlemen）」と呼ぶことができる。コンテンツデータ４１のドメインネーム空間は、ツリーの各ノードまたはリーフがドメインネームに関連付けられた情報を保持するラベルおよびゼロ以上のリソースレコード（ＲＲ）を有するように、ツリーデータ構造からなることができる。ドメインネーム自体は、多数の親子ラベルからなることができる。各子ラベルは、ドットで区切られた右側の親ノードのネームと連結される。

したがって、コンテンツデータ４１の一例は、関連付けられたインターネットプロトコル（ＩＰ）アドレス空間を備えたドメインネーム階層の形態の一連の対のクエリ３０データおよび応答３２のデータである。コンテンツデータ４１に／として格納されるドメインネームシステムは、ドメインネーム階層を維持し、それとアドレス空間との間の変換サービスを提供することを含むことができる。コンテンツデータ４１は、ドメインのＤＮＳレコードを格納することができる。これにより、コンテンツデータ４１を使用するネットワークサーバ（例えば応答側サーバ１０）が、そのコンテンツデータ４１（例えばデータベース）に対するクエリ３０のデータに回答／応答３２のデータを提供することが可能になる。

例えば、コンテンツデータ４１は、Start of Authority（ＳＯＡ）、ＩＰアドレス（AおよびAAAA）、ＳＭＴＰメールエクスチェンジャ（ＭＸ）、ネームサーバ（ＮＳ）、逆ＤＮＳルックアップ（ＰＴＲ）のポインタ、およびドメインネーム（例えばＤＮＳ）のデータベースに格納されたレコードエイリアス（ＣＮＡＭＥ）を含むことができる。コンテンツデータ４１はまた、ＤＮＳＳＥＣレコードなどの自動ルックアップ、または責任者（ＲＰ）レコードなどの人間のクエリのいずれかのための他のタイプのデータのレコードを格納するために使用され得る。コンテンツデータ４１はまた、リアルタイムブラックホールリスト（ＲＢＬ）を格納するために使用され得る。例えば、コンテンツデータ４１は、構造化テキストファイル、ゾーンファイルに格納され得るが、必要に応じて他のデータベースシステムは使用され得る。

ネットワークトラフィック７は、データ交換モデルまたはパケット交換モデルとして実装され得る。一般に、クエリ３０は、データベース２４からの情報の要求であり得る。クエリ３０を提示するためにソースデバイス８によって使用されるいくつかの異なる方法があり得る。例えば：ａ）システムが選択するパラメータのリストを表示するようにメニューからパラメータを選択すること；ｂ）システムが空のレコードを提示し、クエリを定義するフィールド及び値を指定させるような例示によるクエリ（query by example：ＱＢＥ）３０；および／またはシステムが特別なクエリ言語で書かれる必要がある様式化されたクエリの形式で情報を要求する必要があるようなクエリ言語。記載された要求応答、または要求応答、メッセージ交換は、デバイス８およびサーバ１０、１２によって使用され、第１のコンピュータが一部のデータに関して要求３０を送信し第２のコンピュータが要求３０に応答３２するネットワーク１４、１６、１８を介して相互に通信する。たとえばＷｅｂページの閲覧など、完全なメッセージが送信されるまで、一連のこのようなやりとりが存在する可能性がある。したがって、記載された要求３０－応答３２のメッセージ交換パターンは、要求側（たとえば、ソースデバイス８）が要求メッセージ３０を、要求を受信して処理し最終的に応答メッセージ３２を返す応答側システム（たとえば、応答側サーバ１０または協力して動作する要求側／応答側サーバ１２、１０）に送信する方法と呼ぶことができる。要求３０－応答３２のメッセージングは、クライアント及びサーバの関係として、２つのアプリケーション（必須のネットワークデバイス９で実行）がチャネルを介して（すなわち、１つまたは複数のネットワーク１４、１６、１８を介して）互いに双方向の会話を行えるようにするメッセージングパターンを提供する。

簡単にするために、このクライアント及びサーバの関係は、ＨＴＴＰ経由のＷｅｂサービス呼び出しなど、純粋に同期的な方法で典型的に実装され得る。これは、接続を開いたままにして、応答が配信されるか又はタイムアウト期間が経過するまで待機したままにする。しかし、要求３０－応答３２は、不明なときに返される応答を用いて、非同期で実装され得る。これは、遅い集計、時間のかかる機能、または応答が作成され得て配信され得る前に人間のワークフローが実行される必要があるエンタープライズアプリケーション統合（ＥＡＩ）実装において一般的である。

再帰的なＤＮＳクエリは、限定されないが、ドメインネームシステムの（ＤＮＳ）要求側サーバ１２が、可能であれば、キャッシュからのリソースレコード（例えば、ＩＰアドレス）で応答するユニフォームリソースロケータ（ＵＲＬ）をたどるプロセスを含む理由でアプリケーションによって使用されるＤＮＳリソースレコードの要求である。要求側サーバ１２のキャッシュが要求時に要求されたリソースレコードを含む場合、要求側サーバ１２は要求３２を１つまたは複数の応答側サーバ１０に送信する。各応答側サーバ１０は、肯定的または否定的な応答で応答することができ、または要求側が要求を送信すべき異なる応答側サーバ１０のネームを要求側サーバ１２に示す照会（referral）で応答することができる。このプロセスは、要求側サーバ１２が応答を取得するまで、または障害状態が明らかになるまで続く。要求側サーバ１２が応答側サーバ１０から受信した全ての応答は、概して、要求側サーバ１２によってローカルキャッシュに格納される。しかし、１つずつ応答を格納することは、応答側サーバ１０によって直接格納／アクセスされるコンテンツデータ４１の完全なコンテンツのサブセットを含むものとしてのみローカルキャッシュを提供できることが認識される。

ＤＮＳベースの例に関して、クエリ３０および応答３２は、両方とも同じフォーマットを有する２つのタイプのＤＮＳメッセージ、すなわちクエリ３０および応答３２を使用するＤＮＳプロトコルに従うパケットベースの通信であり得る。ＤＮＳメッセージの正確な形式は元々RFC 1035で指定され、メッセージ形式に対する明確化及び拡張は、インターネット技術特別調査委員会（P. Mockapetris、「DOMAIN NAMES-IMPLEMENTATION AND SPECIFICATION」、RFC 1035、1987年11月、https：//www.ietf.0rg/rfc/rfc1035.txt参照）によるRFCシリーズにおいて公開された後続の技術文書において指定されている。各メッセージは、ヘッダ及びセクション：質問、回答、権限、追加からなることができる。ヘッダは、それに続くメッセージのセクションに関連する様々なパラメータを含む。一般に、ヘッダセクションは、次のフィールド：クエリＩＤ、フラグ、質問セクションのエントリ数、回答セクションのエントリ数、権限セクションのエントリ数、追加セクションのエントリ数を含む。クエリＩＤフィールドは、要求側サーバ１２によって応答をクエリと調和するために使用され得る。フラグフィールドは、いくつかのサブフィールドからなることができる。第１は、メッセージがクエリ（０）であるか応答（１）であるかを示す単一ビット（「ＱＲ」）であり得る。第２のサブフィールドは４ビットからなることができる。これらのビットは、ＤＮＳメッセージ（「OPCODE」）の目的を説明する値を形成する。これは、一般に1で、要求側サーバ１２と応答側サーバ１０の間のクエリトラフィックの「クエリ」を意味するが、他の値は他の目的のために存在する。単一ビットのサブフィールド（「AA」）は、ＤＮＳサーバ１０からの応答の応答セクションのコンテンツが、応答を受信した要求側サーバ１２によって権限があるとみなされるべきかどうかを示すことができる。別の単一ビットのサブフィールドは、クライアント（デバイス８、１２）が再帰クエリ（「RD」）を送信するかどうかを示すことができる。次の単一ビットのサブフィールドは、全てのＤＮＳサーバがこのタスクを実行するように構成されるわけではないため、応答するＤＮＳサーバ１０が再帰（「RA」）をサポートするかどうかを示すことができる。別のサブフィールドは、要求３０が何らかの理由（「TC」）で切り捨てられたかどうかを示すことができ、４ビットのサブフィールドはステータスを示す。質問セクションは、ドメインネーム（「QNAME」）、レコードのタイプ（A、AAAA、MX、TXTなど）（「QTYPE」）、およびインターネット上での使用のために決定される（resolved）ネームが通常INであるネームのクラス（「QCLASS」）を含むことができる。ドメインネームは、連結された個別のラベルに分割され得る：各ラベルは、ラベル自体によって続くそのラベルの長さとして、または同じメッセージ内のドメインネームの別のエンコードへのポインタとして、ＤＮＳメッセージのワイヤー形式でエンコードされる。メカニズムは、ＤＮＳメッセージのサイズの削減に役立つラベル圧縮として知られる。回答セクションは、質問セクションで説明されているクエリに関連するリソースレコードを含むことができる。単一のドメインネームは、それに関連付けられた同じまたは異なるタイプの複数のリソースレコードを有することができる。権限および追加セクションは、応答側サーバ１０から要求側サーバ１２に返される応答のタイプに関連する追加情報を含む。ＤＮＳメッセージがＤＮＳプロトコルを使用して通信するサーバによって構築および解釈されるメカニズムは、元々RFC 1034で指定されていた（P. Mockapetris、「DOMAIN NAMES-CONCEPTS AND FACILITIES」、RFC 1034、1987年11月、https：// www.ietf.org/rfc/rfc1034.txt参照）。明確化および拡張は、インターネット技術特別調査委員会によってRFCシリーズで公開された後続の技術文書で指定されている。要求３０の一例は、要求側サーバ１２からの質問に対する回答を含む応答を供給することができるほど十分に信頼できるデータをローカルに含むわけではないサーバ１０から情報を返すために使用される再帰的要求であり得る。例えば、ＤＮＳサーバ１０は、照会を介してのローカル情報がないという反復クエリ３０に応答することができる。照会は、ドメインネーム空間に対して権限のある別のＤＮＳサーバ１０と、ドメイン空間のより低いレベルおよびより低いレベルのＤＮＳサーバとを指す。照会は、照会されたサイトに対して権限のある適切なＤＮＳサーバ１０が見つかるまで、またはエラーが返されるか若しくはタイムアウトに達するまで続行することができる。ルートＤＮＳのレベルでは、全ての権限のあるサーバ１０とその可用性は、インターネットの機能にとって重要である。要求サーバ１２は、要求３２を応答サーバ１０に送信するが、応答を受信しない。例えば、それらの間のネットワーク２２、２１、２０の容量制限のために要求または応答がドロップ（drop）されたため、異なるが同等の応答側サーバ１０を概して試すことができる。要求側サーバ１２と応答側サーバ１０の一般的なメカニズム。

再び図１を参照すると、応答側サーバ１０と要求側サーバ１２との間のマルチインターフェース構成が示され、その結果、プライベートサービスインターフェース３４および別個のパブリックサービスインターフェース３６が応答側サーバ１０と要求側サーバ１２との間に提供される。プライベートサービスインターフェース３４は、要求トラフィック３０の指定されたソース（例えば、ソースデバイス８）のための応答側サーバ１０と所定の要求側サーバ１０との間の通信ネットワーク１４、１６、１８上の直接的な相互接続としてプロビジョニングされる。直接的な相互接続は、事前に定められたソース（例えば、ソースデバイス８）からアドレス指定されたネットワーククエリ要求トラフィック３０を受信するためのプライベートサービスインターフェース３４を提供し、その結果、直接的な相互接続を有する事前に定められたソースの定義されたペアリングデータ３８は、ネットワークトラフィックアルマナックとも呼ばれる、ネットワークトラフィック７のソース接続関係を含むペアリングデータ３８を含むデータベース２４に格納される。例えば、ネットワークトラフィックアルマナックと総称されるペアリングデータ３８のセットは、事実上、ネットワークトラフィック７のネットワーク１４、１６、１８上の識別されたソースアドレスに関連する事前に定められたネットワークソースデバイス（例えば、ソースデバイス８、要求側サーバ１２）から（データ収集システム５０によって促進されるように）受信した過去のネットワークトラフィック７のデータの結果の信号分析（すなわち、ペアリングデータ３８）である。インターフェース３４、３６は、ネットワークトラフィック７及び必要に応じてネットワークトラフィック７の他の識別されたヘッダおよび／またはペイロードパラメータを応答側サーバ１０によって受信するために使用される。次に、ペアリングデータ３８は、ネットワークトラフィック７がどのようにパターン化するかの予測（例えば、要求タイプ、ソースアドレス、指定されたインターフェース３４、３６など）が、（ペアリングデータ３８の常駐として）過去に特定された動作に基づいて将来進むことになるように、後で受信されるネットワークトラフィック７の外挿ツールとしてのデータ管理システム５２（図２を参照）によって使用される。データ管理システム５２は、インターフェース３４、３６に到着するネットワークトラフィック７のうちのどれが正常または異常に分類され得るかを突き止める又はそうでなければ識別するために、ネットワークトラフィックアルマナックのペアリングデータ３８をリアルタイムで問い合わせるように構成される。ペアリングデータ３８は、本質的に、ネットワークトラフィック７の正常な分類が何であるかの予測、および／またはネットワークトラフィック７の正常な分類、すなわちネットワークトラフィック７の異常な分類からの逸脱の予測である。したがって、ペアリングデータ３８は、正常なネットワークトラフィック７（すなわち、指定された要求側サーバ１２のネットワークトラフィック７に割り当てられた指定されたプライベートネットワークインターフェース３４に到着する事前に定められた要求側サーバ１２からのネットワークトラフィック７などであるがこれに限定されない所望のネットワークトラフィック７）を定義するネットワークトラフィックパラメータを含むことができる。したがって、ペアリングデータ３８は、異常なネットワークトラフィック７（すなわち、指定された要求側サーバ１２のネットワークトラフィック７に割り当てられたプライベートネットワークインターフェース３４ではなく、指定されていないパブリックネットワークインターフェース３６に到着する事前に定められた要求側サーバ１２からのネットワークトラフィック７などであるがこれに限定されない望ましくないネットワークトラフィック７）を定義するネットワークトラフィックパラメータを含むことができる。したがって、ペアリングデータ３８は、正常なネットワークトラフィック７（すなわち、指定された要求側サーバ１２のネットワークトラフィック7に割り当てられた指定されたプライベートネットワークインターフェース３４に到着する事前に定められた要求側サーバ１２からのネットワークトラフィック７などであるがこれに限定されない望ましいネットワークトラフィック７）を定義するネットワークトラフィックパラメータと、異常なネットワークトラフィック７（すなわち、指定された要求側サーバ１２のネットワークトラフィック７に割り当てられたプライベートネットワークインターフェース３４ではなく、指定されていないパブリックネットワークインターフェース３６に到着する事前に定められた要求側サーバ１２からのネットワークトラフィック７などであるがこれに限定されない望ましくないネットワークトラフィック７）を定義するネットワークトラフィックパラメータと、を含むことができる。したがって、ネットワークトラフィックアルマナック内のペアリングデータ３８は、ネットワークトラフィックアルマナックとしてストレージ２４に格納されるペアリングデータ３８を有する選択されたインターフェース３４、３６上で受信したネットワークトラフィック７をリアルタイムで比較することによってデータ管理システム５２によって識別されるように、正常および／または異常なネットワークトラフィック７がどのように見えるかの予測とみなされ得る。記憶されたペアリングデータ３８をネットワークトラフィックベースラインとして使用して、データ管理システム５２は、異常を識別し、ネットワークトラフィック７に対して対象を絞ったフォレンジック分析（forensic analysis）を実行し、緩和を導き出すことができる。

パブリックサービスインターフェース３６は、事前に定められたソース８および他のソースからアドレス指定されたネットワーク要求トラフィック３０を受信するためにプロビジョニングされ、パブリックサービスインターフェース３６はプライベートサービスインターフェース３４とは別個である。定められたペアリングデータ３８のストレージは、ネットワークトラフィックアルマナックを提供する。これにより、事前に定められたソース８からプライベートサービスインターフェース３４を経由するネットワーク要求トラフィック３０は「クリーン（clean）」とみなされる一方で、事前に定められたソース８からのパブリックサービスインターフェース３６を経由するネットワーク要求トラフィック３０は、「疑わしい（suspect）」とみなされ得るか、または他の方法で危険にさらされているとみなされ得る。以下でさらに説明するように、応答側サーバ１０（または応答側サーバ１０によって参照されるように応答側サーバ１０に代わって動作するサービス）は、パブリックサービスインターフェース３６を介して受信した事前に定められたソースからの任意のネットワーク要求トラフィック３０上の優先順位付けの行動の基礎となる定義されたペアリングデータ３８の情報を利用／照合する。これにより、定義されたペアリングデータ３８のセットは、パートナー要求側サーバ１２／応答側サーバ１０のネットワーク１４に関するネットワークトラフィックのアルマナックと呼ばれ得る。

分離性に関して、プライベートサービスインターフェース３４は、パブリックサービスインターフェース３６と比較して、ネットワーク１４、１６、１８上の別個の専用パスとして定義され、これにより：（ａ）信頼できる既知の発信元（すなわち、プライベートサービスインターフェース３４に接続された要求側サーバ１２）からのネットワーク要求トラフィック３０のみなされたクリーンフローを識別する能力と、（ｂ）プライベートサービスインターフェース３４に起因する専用のネットワーク容量を有するネットワーク要求トラフィック３０のフローに対応する能力と、のいずれかまたは両方を容易にする。例えば、パートナーサーバ１２／ネットワーク１４との直接的な相互接続は、直接的な相互接続が要求側サーバ１２自体におよび／またはパートナーネットワーク１４内の指定された場所に結合される場合、（ａ）および（ｂ）の両方を達成することができる。これにより、応答側サーバ１０は、プライベートサービスインターフェース３４がクリーンなネットワークトラフィック７のみを伝送することを確信する（その場合、（ａ）は、専用サービスインターフェースが（ｂ）を実現したという事実を達成する）。代替的には、パートナーサーバ１２／ネットワーク１４と応答側サーバ１０の間に仮想相互接続（たとえば、ＶＰＮのようなトンネル）を構築することは、（ａ）を達成できるが、たとえば、（ＶＰＮ）トラフィックは、他のネットワークトラフィックに使用されるのと同じネットワーク回路で伝送される場合（他のトラフィックがＶＰＮトラフィックを圧倒する可能性がある場合）、（ｂ）に関して効果的ではない場合がある。代替的には、専用の応答側サーバ１０をパートナーのネットワーク１４に配備することは、クリーンな要求トラフィック３０のみを受信して（ａ）を達成する配備が与えられた場合に、（ａ）および（ｂ）を達成でき、この場合、応答側サーバ１０全体が（ｂ）を満足できるパートナーの使用に専念することになる。

プライベートネットワークインターフェース３４の１つの例示的なタイプは、応答側サーバ１０と要求側サーバ１２との間の物理的相互接続（例えば、直接層２または層３の相互接続）として構成された直接的な相互接続であり得る。プライベートネットワークインターフェース３４のさらなるタイプは、応答側サーバ１０と要求側サーバ１２との間のネットワーク１４、１６、１８上の論理ネットワーク接続として構成された直接的な相互接続であり得る。

したがって、応答側サーバ１０のデータストア２４から要求側サーバ１２のキャッシュに新しいデータレコードを移動する目的（例えば、権限データストア２４からＤＮＳリゾルバのキャッシュ１２に新しいリソースレコードセットを移動するＤＮＳ固有の目的）を考慮するとき、サーバ１０および１２の間のネットワークトラフィック７の転送メカニズム（たとえば、汎用（ＩＰ層）相互接続）をサーバ１０、１２間で割り当て／プロビジョニングされた事前に定められたプライベートネットワークインターフェース３４として実装するための代替／実施形態がいくつかあり得る。例えば、ネットワーク１４、１６、１８間の直接層２の相互接続３４は、ピアリング関係の一部、例えば、直接的な相互接続、ピアリングファブリック（peering fabrics）またはハイパーバイザーレベル（hypervisor-level）のインターフェースでの相互存在としてプロビジョニングされ得る。直接的な相互接続３４の一般的な性質は、結果として生じるチャネル（すなわち、プライベートネットワークインターフェース３４）が攻撃トラフィックソース１２からの汚染を受けないようにするために、いくつかのアーキテクチャの考慮を使用できることが認識される。

さらに、プライベートネットワークインターフェース３４に対するこの一般的な物理アプローチのＤＮＳ固有の改良は、権限のあるサービス（すなわち、応答側サーバ１０）のエニーキャスト展開（anycast deployment）に使用されるのと同じアプローチに従うことができる。単一の境界に対する接続、内部で接続されたサービス配信ネットワークを追加するのではなく、複数の切断されたサービス配信ノードに配信されているコンテンツを複製し、それぞれを個別に相互接続する。実際、他の誰かのネットワークでの新しいエニーキャストノードの全ての展開は、展開場所のプライベート相互接続と区別がつかず、内部ネットワークは、内部接続の代わりとしてデータ複製のために使用される。

プライベートネットワークインターフェース３４のさらなる例は、インフラストラクチャのコストなしで直接的な相互接続のいくつかの利点を提供する専用のＩＰ層のパスなしで、個別の識別可能なトランスポートを使用することができる。例えば、応答側サーバ１２に操作される応答者を対象とした全てのネットワークトラフィック７をトンネルにカプセル化するための特定の要求側サーバ１２のオペレータを有する配置は、応答側ネットワーク１８での仮想相互接続インターフェース３４を提供する。たとえば、ＤＮＳ層での類似の配置は、永続的なＴＣＰバンドルを使用して要求３０および応答３２のメッセージを転送し得る。これにより、相互接続３４が１つのシェルによってネームサーバのインフラストラクチャ（応答側サーバ１０など）の内部に事実上移動する。これらの場合、データ管理システム５２がトラフィックを分類し、予想されるネットワーク経路（割り当てられたインターフェース３４）をたどらないネットワークトラフィック７の異常を知らせる能力が保持される。

要求側－応答側のサーバ相互作用のアプリケーション固有の説明に従って、指定された要求側ネットワーク１４と応答側ネットワーク１８（すなわち、パートナー）間のエンゲージメント（engagement）は、一般的な相互運用性と公的基準への断固とした遵守の必要性によって制約されるわけではないパートナーおよびアプリケーション固有の配置を容易にするということが認識される。以下の２つの実施形態は、例えば攻撃トラフィック７の軽減の状況で有用なプライベートネットワークインターフェース３４の例である：

第１の実施形態は、ネットワークアドレス照会メカニズムの置換／修正であり、それにより、反復的なサーバ識別が親によって広められる。要求側サーバ１２と応答側サーバ１０との間の定められた通信プロトコル（例えばＤＮＳなど）の使用を維持し、パートナー固有（特定の要求側サーバ１２に割り当てられている）であり一般的に発表されていない（すなわち、ネットワーク１４、１６、１８のアドレスが特定の要求側サーバ１２以外に公開されていない）堅牢なセットを提供することにより、応答側インフラストラクチャの攻撃対象（例えば、デバイス２２、サーバ１０、および／またはネットワークの他の部分１８）は、部外者（すなわち、パートナーではない）にはわかりにくく、動的に変化する可能性がある。換言すれば、応答側サーバ１０のみなされたプライベートネットワーク１４、１６、１８のアドレス（すなわち、要求側１４と応答側１８ネットワーク間でのみ共有される）および要求ネットワークトラフィック３０を送信するためのその使用は、プライベートネットワークインターフェース３４の一例と呼ぶことができる。

代替的な第２の実施形態は、要求側サーバ１２によるキャッシュの作成に使用されるメカニズムを置き換えることであり、プロトコルの基本的な要件によって残されたアドミッションコントロールとシグナリングのギャップの一部を埋める汎用（例えば、ＤＮＳなど）プロトコルの代替を提供し、処理状態を把握しない（stateless）方法で未知のクライアントにサービスを供給する。コンテンツデータ４１（例えば、要求側ローカルに保存されたコピーコンテンツデータ４１ａと呼ばれる）によるキャッシュの事前入力（Pre-population）は、そのようなプロトコルの時間重要性を低減し、プライベートネットワークインターフェース３４のためのデータレベル構成の例としての分散ハッシュテーブルおよび／または分散（プライベート）公衆台帳（ブロックチェーン）の使用など、より従来の分散システムアプローチを可能にすることができる。コンテンツデータ４１ａは、ネットワークソースデバイス８からの任意の受信したネットワーク要求３０を独立して満たす（すなわち、適切なネットワーク応答３２を形成する）ために要求側サーバ１２によって要求されるように、コンテンツデータ４１の完全なセットのコピーであり得ることが認識される。

図１を参照すると、第２の実施形態は、ネットワーク１４、１６、１８を介して応答側サーバ１０によってリゾルバコンテンツデータ４１を要求側サーバ１２に提供することを含む。例えば、コンテンツデータ４１は、（ネットワーク１４、１６、１８を介して）パブリックネットワークインターフェース３６を使用してサーバ１０、１２の間で提供され得る。例えば、コンテンツデータ４１は、プライベートネットワークインターフェース３４を使用して（ネットワーク１４、１８間で直接）サーバ１０、１２間で提供され得る。また、コンテンツデータ４１は、応答側サーバ１０の１つによって送信されるのではなく、トレーサビリティサーバ５５と１つまたは複数の要求側サーバ１２との間で転送できることが認識される。要求側サーバ１２、またはそれらに代わって動作する調整要求側サーバ１２ａによって受信されると、サーバ１２、１２ａは、コンテンツデータ４１を要求側コンテンツデータ４１ａとして自身のローカルストレージ１２２’（例えば、キャッシュ）に格納することができる（図３ａを参照）。調整要求側サーバ１２ａ（例えば、コンテンツデータ４１ａの普及のために構成された要求側サーバ１２）に関して、この調整サーバ１２ａは、ネットワークソースデバイス8からネットワーク要求３０を受信するために、責任のある全ての要求側サーバ１２に要求側ネットワーク１４を介して広める（例えば送信する）責任がある。例えば、サーバ１２、１２ａは、コンテンツデータ４１ａを要求側ネットワーク１４内の他の全ての要求側サーバ１２にメタデータとしてプッシュすることができ、コンテンツデータ４１がサーバ１０、１２間で更新されると、サーバ１２、１２ａはまた、更新されたコンテンツデータ４１ａを定期的な更新ベース／スケジュールで他の要求側サーバ１２にプッシュすることができると認識する。

（要求３０のデータと対応する関連付けられた応答３２のデータの両方を含む）コンテンツデータ４１がサーバ１０、５５とサーバ１２、１２ａの間で（例えば、更新された方法で）共有されるこの更なる実施形態の利点として、要求側サーバ１２は、ネットワークソースデバイス８からの任意の受信したネットワーク要求３０を直接満たすために必要な全てのコンテンツデータ４１ａをローカルに格納する。換言すると、要求側サーバ１２がネットワークソースデバイス８からネットワーク要求３０を受信すると、要求側サーバ１２はローカルに格納されるコンテンツデータ４１ａを直接照合し、パブリックネットワークインターフェース３６またはプライベートネットワークインターフェース３４を使用する応答側サーバ１０に対する任意のクエリを送信する必要なしで適切なネットワーク応答３２を作成することができる。このようにして、応答側サーバ１０のネットワークリソースの利用はネットワーク要求３０を受信する必要も、必要なネットワーク応答３２を（独自のコンテンツデータ４１の照合を含む）要求側サーバ１２に供給する必要もないので、最小化されるか、そうでなければ有利に制限されることができる。明確にするために、応答側コンテンツデータ４１はマスターコンテンツデータ４１と呼ばれることがあり、要求側コンテンツデータ４１ａは複製またはコピーコンテンツデータ４１ａと呼ばれることがある。

しかしながら、上記の場合、応答側サーバ１０および／またはトレーサビリティサーバ５５は、要求側サーバ１２によって受信されたネットワーク要求３０に関連付けられ、要求側サーバ１２によって独立して（すなわち、それらのマスターコンテンツデータ４１と照合して応答側サーバ１０とのリアルタイムの関与なしに）満足されるペアリングデータ３８の知識から恩恵を受けることができる。換言すると、要求側ネットワーク１４を介した要求側サーバ１２による受信ネットワーク応答３０の受信および処理は、（プライベートネットワークインターフェース３４またはパブリックネットワークインターフェース３６を利用する）要求側ネットワーク１８を介して要求側サーバ１２と応答側サーバ１０との間で転送されるリアルタイムネットワークトラフィックを含むわけではない。

次に、コピーコンテンツデータ４１ａをローカルに格納する利点を実現するために、要求側サーバ１２はまた、受信したネットワーク要求３０に関連付けられたローカルペアリングデータ３８ａを記録および格納することができる。たとえば、要求側サーバ１２が要求側ネットワーク１４を介してネットワーク要求３０を直接受信した場合、要求側サーバ１２は、ネットワーク要求３０のデータのネットワーク１４、１６、１８上の識別されたソースアドレスに関連する事前に定められたネットワークソースデバイス（たとえば、ソースデバイス８、要求側サーバ１２）から受信したネットワーク要求３０のデータの結果の信号分析（すなわち、ペアリングデータ３８ａ）に帰することができ、インターフェース３４、３６は、応答側サーバ１０によってネットワーク要求３０のデータを受信するために使用されるとともに、所望のネットワーク要求３０のデータの他の識別されたヘッダおよび／またはペイロードパラメータを受信するために使用される。次いで、ペアリングデータ３８ａは、データ管理システム５２（図２を参照）によって使用されるペアリングデータ３８に対する記憶／更新のために、データ収集システム５０に転送され、ネットワークトラフィック７のパターン（たとえば、要求タイプ、送信元アドレス、指定されたインターフェース３４、３６など）が過去に特定された動作（ペアリングデータ３８に常駐している）に基づいて将来的にどのように使用されることになるかの予測として、後で受信されるネットワークトラフィック７ための外挿ツールとして使用される。明確にするために、応答側の格納されたペアリングデータ３８は、マスターペアリングデータ３８と呼ばれることがあり、要求側ペアリングデータ３８ａは、補助的ペアリングデータ３８ａと呼ばれることがある。

例えば、要求側ネットワーク１４を直接介して要求側サーバ１２により受信されるネットワーク要求３０は、（要求側サーバ１２がコピーコンテンツデータ４１ａの利点を有していなかった場合、ネットワーク要求３０を応答側サーバ１０に転送するために、要求側サーバ１２がプライベートネットワークインターフェース３４を使用することになるため）プライベートネットワークインターフェース３４により概念的に（たとえばシミュレーションされて）受信されるように割り当てられ得る。したがって、この例のネットワーク要求３０のデータペアリング３８ａは、プライベートネットワークインターフェース３４上で概念的に（たとえばシミュレーションされて）受信されたものとして、ネットワークソースデバイス８からのネットワーク要求３０のタイプ／データを含むことになる。

別の例では、要求側サーバ１２がパブリックネットワーク１６を直接介して受信したネットワーク要求３０は、（要求側サーバ１２がコピーコンテンツデータ４１ａの利点を有していなかった場合、応答側サーバ１０が要求側サーバ１２の関与なくパブリックネットワークインターフェース３６によってネットワーク要求３０を受信することができたため）パブリックネットワークインターフェース３６によって概念的に（たとえばシミュレーションされて）受信されるように割り当てられ得る。したがって、この例のネットワーク要求３０のデータペアリング３８ａは、パブリックネットワークインターフェース３６で概念的に（たとえばシミュレーションされて）受信されたものとして、ネットワークソースデバイス８からのネットワーク要求３０のタイプ／データを含むことになる。

別の例では、パブリックネットワーク１６を直接介して応答側サーバ１０によって受信され、プライベート／パブリックネットワークインターフェース３４、３６を介して－処理せずに要求側サーバ１２に転送されるネットワーク要求３０は、（要求側サーバ１２がコピーコンテンツデータ４１ａの利点を持たなかった場合、応答側サーバ１０が要求側サーバ１２の関与なしにネットワーク要求３０をパブリックネットワークインターフェース３６によって受信できたため）概念的に（例えば、シミュレーションされて）パブリックネットワークインターフェース３６によって受信されるように割り当てられ得る。したがって、この例のネットワーク要求３０のデータペアリング３８ａは、パブリックネットワークインターフェース３６で概念的に（たとえばシミュレーションされて）受信されたものとして、ネットワークソースデバイス８からのネットワーク要求３０のタイプ／データを含むことになる。

したがって、サーバ１０、５５によってコンテンツデータ４１をサーバ１２、１２ａと共有するとともに要求側サーバ１２によってローカルコピーコンテンツデータ４１ａとして格納する代わりに、サーバ１２、１２ａは、要求側サーバ１２によって受信され、独立して処理される各ネットワーク要求３０のためのペアリングデータ３８ａを収集する責任がある（すなわち、コピーコンテンツデータ４１ａとの照合により、応答側サーバ１０とのリアルタイムの対話を要せずに、必要なネットワーク応答３２を作成する）。個別に受信および処理されたネットワーク要求３０に関連付けられたペアリングデータ３８ａを収集すると、サーバ１２、１２ａは、応答側サーバ１０によってアクセス可能なストレージ１２２に格納されるペアリングデータ３８の更新に使用するためにペアリングデータ３８ａをサーバ１０、５５に戻すように提供することができる。要求側サーバ１２によって収集された（その後、サーバ１２、１２ａによってサーバ１０、５５に通信された）ペアリングデータ３８ａは、（コンテンツデータ４１ａに対する更新として格納するために）更新されたコンテンツデータ４１の受信に応答してサーバ１０、５５に送信できることが認識される。代替的に、要求側サーバ１２によって収集された（次いで、サーバ１２、１２ａによってサーバ１０、５５に通信された）ペアリングデータ３８ａは、（コンテンツデータ４１ａに対する更新として格納するために）定期的に、たとえば更新されたコンテンツデータ４１を受信する前または後に、サーバ１０、５５に提出され得ることが認識される。したがって、サーバ１０、５５は、ペアリングデータ３８を更新する際に使用するためのペアリングデータ３８ａを受信する。

さらに、オプションとして、トレーサビリティサーバ５５は、以下でさらに説明するように、要求側サーバ１２によって、コピー優先順位付けコマンド４０ａを含むコピー優先順位付け基準３９ａとして格納された優先順位付け基準３９（優先順位付けコマンド４０を含む）をサーバ１２、１２ａと共有できることが認識される。したがって、サーバ１２、１２ａは、要求側ネットワーク１４上に優先順位付け基準３９ａ（優先順位付けコマンド４０ａを含む）を実装することができ、例えば、優先順位付け基準３９ａを実装するか、又はそのような優先順位付け基準３９ａを要求側サーバ１２に提案する。さらに、サーバ１２、１２ａは、照合の結果として優先順位付けコマンド４０ａをネットワークデバイス２０、２１（および要求側サーバ１２）に送信するように構成され得る。したがって、要求側サーバ１２が受信したネットワーク要求３０を独立して受信および処理しているため（ネットワーク要求３０の処理において応答側サーバ１０との直接のリアルタイムの対話がない、またはそれによりバイパスする）、要求側サーバ１２自体は、ネットワーク要求３０のパラメータを優先順位付け基準３９ａ（優先順位付けコマンド４０ａを含む）に関連付けられたペアリングデータ３８ａと比較すると、サーバ１０、５５から取得した任意の優先順位付け基準３９ａ（優先順位付けコマンド４０ａを含む）を実装することができる。優先順位付け基準３９ａ（優先順位付けコマンド４０ａを含む）の実装例は、応答側サーバ１０、すなわち優先順位付け基準３９（優先順位付けコマンド４０を含む）に関して以下に提供される。しかし、要求側サーバ１２は、要求側ネットワーク１４に直接受信されたネットワーク要求３０の優先順位付けのための同じ優先順位付け基準３９ａ（優先順位付けコマンド４０ａを含む）を同様に直接的に実装できることが認識される。言い換えると、優先順位付け基準３９ａ（優先順位付けコマンド４０ａを含む）は、以下の例で詳細に記載するように、その応答側ネットワーク１８上の応答側サーバ１０によって実装される優先順位付け基準３９（優先順位付けコマンド４０を含む）と同様に、要求側ネットワーク１４上の要求側サーバ１２によって実装され得る。したがって、ペアリングデータ３８ａおよび／または（コマンド４０ａを有する）優先順位付け基準３９ａは、コピー分析データ６０ａと呼ばれ得る。

したがって、要求側サーバ１２の動作に関連して上記および以下に示すように、異常なネットワークトラフィック７を識別して優先順位を下げようとする任意の要求側サーバ１２は、異常を識別するために受信したネットワークトラフィック7を分析することによってなされ得る（または、そうでなければ、到着するネットワークトラフィック７が関連付けられた優先順位付け基準３９ａを有するペアリングデータ３８ａとの照合／比較を介して正常とみなされることを確認する）。トレーサビリティサーバ５５は、サーバ１２、１２ａから受信されたペアリングデータ３８ａを使用することによりアルマナックを生成および更新することを担当できることが認識される。トレーサビリティサーバ５５はまた、更新されたペアリングデータ３８ａを含むペアリングデータ３８の分析に基づいて、優先順位付け基準３９（優先順位付けコマンド４０を含む）を生成および更新することを担当できることが認識される。したがって、トレーサビリティサーバ５５は、サーバ１２、１２ａへの送信に使用するために、優先順位付け基準３９（優先順位付けコマンド４０を含む）から優先順位付け基準３９ａ（優先順位付けコマンド４０ａを含む）を生成することを担当できる。

さらに、サーバ１０、５５とサーバ１２、１２ａとの間のコンテンツデータ４１の共有は、コピーコンテンツデータ４１ａとしてのストレージのために、プライベート／パブリックネットワークインターフェース３４、３６の直接使用を介して、要求側サーバ１２と応答側サーバ１０の間のネットワーク要求３０によるネットワーク要求３０の対話による、要求側サーバ１２によって実行されるキャッシュメモリ内の従来のローカルストレージとは異なることが認識される。従来、要求側サーバ１２によって（応答側サーバ１０に）ネットワーク要求３０のそれぞれを送信した結果、要求側サーバ１２（応答側サーバ１０から）は、受信したネットワーク応答３２をローカルにストレージ１２２'に格納できた。次に、（要求ベースによる要求での）この格納されたネットワーク応答３２は、その後、応答側サーバ１０とは独立して別の同様のネットワーク要求３０を満たすように、要求側サーバ１２によって使用されることができる。しかしながら、この従来の場合では、要求側サーバ１２は、典型的には、最も一般的に要求されるネットワーク要求３０のために、ローカルキャッシュに完全なコンテンツデータ４１の一部のみを保持する。さらに、要求側サーバ１２のキャッシュの従来の使用では、受信されたネットワーク要求／応答３０、３２のケースバイケースのベースで、要求側サーバ１２によって識別／収集されたペアリングデータはない。さらに、要求側サーバ１２のキャッシュの従来の使用法では、受信したネットワーク要求／応答３０、３２のケースバイケースベースで、本明細書に記載されるようにサーバ１０、５５によって受信されるように、要求側サーバ１２によって使用される優先順位付け基準３９はない。

図５を参照すると、ローカルキャッシュの従来の使用とは区別されるように、要求側サーバ１２に応答側サーバ１０から独立して（すなわち、コピーコンテンツデータ４１ａを照合し、それによりネットワーク要求３０のベースによって必要なネットワーク応答３２をネットワーク要求３０上で作成するために、応答側サーバ１０とのリアルタイムの対話を含むわけではない）ネットワーク要求３０を処理させる際に、第２の実施形態を操作するための例示的な方法３００が示される。説明したように、ローカルに格納されたコピーコンテンツデータ４１ａを使用する要求側サーバ１２の利点は、要求側サーバ１２がネットワーク要求３０のベースによってネットワーク要求３０での応答側サーバ１０とのリアルタイム通信とは独立して、受信したネットワーク要求３０を満たすことができることである。さらに、応答側サーバ１０は、サーバ１２、１２ａから生成されたペアリングデータ３８ａ（および生成された優先順位付け基準３９）の利点をそこから取得して使用でき、上述のように、ペアリングデータ３８ａが、ローカルに格納されたコンテンツデータ４１を照合して、要求側サーバ１２によって独立して（応答側サーバ１０とのリアルタイムの対話ない）受信および処理される任意のネットワーク要求３０のためのプライベート／パブリックネットワークインターフェース３４、３６の概念的またはシミュレーションされた使用を表すことを認識する。ステップ３０２において、サーバ１０、５５は、要求側サーバ１２がそれらの受信したネットワーク要求３０を独立して処理するために使用するためのコンテンツデータ４１ａとして格納するためのコンテンツデータ４１を送信する。ステップ３０４で、サーバ１０、５５は、（個別に処理されたネットワーク要求３０のサーバ１２、１２ａによる分析の結果として）サーバ１２、１２ａによって生成されたペアリングデータ３８ａを受信し、ペアリングデータ３８ａは、プライベートネットワークインターフェース３４および／またはパブリックネットワークインターフェース３６の想定される使用法を含む。ステップ３０６で、サーバ５５は、ペアリングデータ３８をペアリングデータ３８ａを用いて更新する。ステップ３０８で、サーバ５５は、サーバ１２、１２ａから受け取ったペアリングデータ３８ａの結果を組み込んだ優先順位付け基準３９（および優先順位付けコマンド４０を含む）を更新または他の方法で生成する。必要に応じて、ステップ３１０で、サーバ５５は、（たとえば、応答側サーバ１０から独立して要求側サーバ１２が適切なネットワーク応答３２を生成するかどうかを決定する際）コピーコンテンツデータ４１ａとの照合を介した後続の処理を目的とした受信したネットワーク要求３０の優先順位付け（たとえば、非優先化）における要求側サーバ１２によるその後の使用のために、サーバ１２、１２ａによって優先順位付け基準３９ａ（および優先コマンド４０ａを含む）として格納するために、優先順位付け基準３９（および優先コマンド４０を含む）の一部および／または全てを通信／共有する。

上記を考慮して、再び図２を参照すると、プライベートネットワークインターフェース３４のプロビジョニングは、例えば、共通の応答側サーバ１０と割り当てられた要求側サーバ１２のそれぞれとの間にプロビジョニングされた別個の個々のプライベートネットワークインターフェース３４を有する複数の割り当てられた要求側サーバ１２への任意の指定された応答側サーバ１０によって達成でき得ることが認識される。プライベートネットワークインターフェース３４を使用して、要求側サーバ１２を応答側サーバ１０に、またはその逆に割り当てることができることが認識される。また、プロビジョニングされたプライベートネットワークインターフェース３４のそれぞれは、ストレージ２４に格納されたネットワークトラフィックのアルマナックにおいて、対応するペアリングデータ３８のセットを有することになる。このようにして、共通の応答側サーバ１０によって利用される複数の異なるプライベートネットワークインターフェース３４について、データ管理システム５２は、ペアリングデータの各セットを対応するプライベートネットワークインターフェース３４に編成するか、そうでなければ関連付けることができる。さらに、特定のプライベートネットワークインターフェース３４は、例えば、２つ以上の指定された個々の要求側サーバ１２（および／または要求側ネットワーク１４）に関連付けることができる。また、２つ以上の指定された個々の要求側サーバ１２（および／または要求側ネットワーク１４）が共通のプライベートネットワークインターフェース３４を共有する場合、個々の要求側サーバ１２（および／または要求側ネットワーク１４）のそれぞれに関するペアリングデータ３８は、２つ以上の指定された個々の要求側サーバ１２（および／または要求側ネットワーク１４）のそれぞれに対して異なる優先順位付け基準３９を使用することによって区別され得ると認識される。２つ以上の指定された個々の要求側サーバ１２（および／または要求側ネットワーク１４）に共有化されたプライベートネットワークインターフェース３４を利用する一例は、２つ以上の指定された個別の要求側サーバ１２（および／または要求側ネットワーク１４）に異なるタイムゾーン（time zone）が確立される場合である。したがって、２つ以上の指定された個々の要求側サーバ１２（および／または要求側ネットワーク１４）のそれぞれのネットワークトラフィック７は、応答側サーバ１０に到着すると、異なるピークのタイミングを有することが予想されるであろう。

以下に加えて、ネットワークトラフィックのアルマナック（すなわち、定められたペアリング３８のセットを生成および維持する）の目的のために重要であり、およびネットワーク要求トラフィック３０（すなわち、受信またはそうでなければパブリックネットワークインターフェース３６に向けられる）に適切な優先順位付けをすることは、ネットワーク要求トラフィックの送信元（すなわち、事前に定められたソース）の場合であることが認識される。したがって、プライベートネットワークインターフェース３４を介して到着するネットワーク要求トラフィック３０（および適切なネットワーク応答トラフィック３２を作成する際の処理におけるその優先度）は、ネットワーク応答トラフィック３２が送信される経路とは異なる重要性であると考えられることが認識される。例えば、ネットワーク要求トラフィック３０は、プライベートネットワークインターフェース３４で受信することができ、ネットワーク応答トラフィック３２は、同じプライベートネットワークインターフェース３４で送信することができる。代替的には、ネットワーク要求トラフィック３０は、プライベートネットワークインターフェース３４上で受信されることができ、ネットワーク応答トラフィック３２は、異なるパブリックネットワークインターフェース３６上で送信されることができる。しかしながら、一般に、応答は要求よりも通常大きくなる可能性があり、応答配信のサービス品質がまた重要である可能性があるため、好ましくは、プライベートネットワークインターフェース３４が受信したネットワーク要求のトラフィック３０に関連付けられたネットワーク応答トラフィック３２を送信するために使用されることになる。また、ネットワーク応答トラフィック３２に関する専用の経路の使用が、全ての状況、例えば、いくつかの予期しないハードルが原因でプライベートネットワークインターフェース３４のアップグレードが遅れ、応答をその方向に安全に送信するのに十分な容量がない場合において正しい選択ではない場合があることが認識される。したがって、一般に、運用上の理由により、ネットワーク要求トラフィック３０を受信するために使用されたものとは別のネットワーク１４、１６、１８のパスの方向において応答ネットワークトラフィック３２を送信する場合があると予想される。

ネットワークトラフィックのアルマナック（すなわち、定められたペアリング３８のセット）の生成および有用性に関して、一般に、パケットベースの通信（例えば、ネットワークトラフィック７）のためのネットワーク１４、１６、１８のフレームワークは、（たとえば、ＤＮＳクエリ３０のＵＤＰにわたって）受信したネットワーク要求トラフィック３０のトレーサビリティを確認することにおいて困難性を提供する。マルチインターフェース３４、３６構成のセットアップおよび実装の重要な動機は、パケットヘッダに「ソース」として表示されるネットワークアドレスから、受信したネットワーク要求トラフィック３０がいつ送信されなかったかをより正確に予測するために、みなされたダーティチャネルのパブリックサービスインターフェース３６と考慮されるクリーンチャネルのプライベートサービスインターフェース３４との間で観察された（生成され、その後に格納される事前に定められたペアリング３８に組み込まれるような）差異を使用することである。クリーンなプライベートサービスインターフェース３４のこのプロビジョニングおよびその後の使用は、合法的に送信されたパケットが現れるパスを予測する手段を提供する；同様に送信されたパケットがパブリックサービスインターフェース３６に予期せず到着した場合、すなわち、参照された事前に定められたペアリング３８のソースインターフェースの定義に従わなかった場合、応答側サーバ１０は、パブリックサービスインターフェース３６に到着した同様のソースパケットは追跡可能ではなく、それゆえ優先順位を下げる（例えば、落とす）必要があることを予測（すなわち決定）することができる。トラフィックはアプリケーション固有ではなく、一般に動機を推測するのが難しいため、単純なピアリング関係では、直接リンクを介して到着するトラフィックがクリーンであるという期待は得られないことが認識されている。通信ネットワークシステム６の場合、ネットワークトラフィックアルマナックと組み合わせてマルチインターフェース構成を利用して、応答側サーバ１０は、直接のプライベートネットワークインターフェース３４（事前に定められたペアリング３８によって定められるように）を介して指定された種類のネットワーク要求トラフィック３０のみを期待する。応答側サーバ１０は、パートナー要求側サーバ１２との注意深い取り決めによって、直接のプライベートネットワークインターフェース３４を介したネットワーク要求トラフィック３０がクリーンであることをさらに期待することができる。本明細書で説明するように、プライベートネットワークインターフェース３４によって定められたパスがクリーンに動作する限り、これは、応答側サーバ１０に、クリーンなネットワークトラフィック７が何であるかを学習する機会を与え、その結果、クリーンでないデータセットにおいて明らかな疑わしいまたはダーティとみなされるネットワークトラフィック７を識別する。したがって、本質的に、ネットワークトラフィックのアルマナックの構築および維持の重要な構成要素は、ペアリングデータ３８を生成および維持／更新することによって、選択されたネットワークインターフェース３４、３６に到着するネットワークトラフィック７の分類（すなわち、正常／異常）を可能にする。パブリックネットワークインターフェース３６は、異常なネットワークトラフィック７の可能性がより高いと考えられ、したがって、データ管理システム５２によって分析することが好ましいのは、パブリックネットワークインターフェース３６のネットワークトラフィック７であることが認識される。プライベートネットワークインターフェース３４は、通常のネットワークトラフィック７のより大きな可能性を有するとみなすことができ、したがって、データ管理システム５２によって典型的に無視されることができ、異常なネットワークトラフィック７を特定して優先順位を下げることを求めるパブリックネットワークインターフェース３６のネットワークトラフィック７であると認識される。しかしながら、データ管理システム５２はまた、異常を識別するために（またはそうでなければ、到着するネットワークトラフィック７がネットワークトラフィックのアルマナックのペアリングデータ３８との照合／比較を通じて正常であるとみなされることをチェックするために）、プライベートネットワークインターフェース３４上のネットワークトラフィック７を分析することができることが認識される。

したがって、（ペアリングデータ３８によって定められるように）パブリックネットワークインターフェース３６からプライベートネットワークインターフェース３４への予想される／事前に定められたネットワークトラフィック３０のシフトに加えて、プライベートネットワークインターフェース３４の存在は、パブリックネットワークインターフェース３６を介して受信されるトラフィックを管理する追加の機会を提供する。たとえば、ステートレストランスポート（stateless transport）を使用してインターネット１４、１６、１８から受信したクエリトラフィック３０は、要求側サーバ１２（たとえば、管理システム５２によって機能され／定められ／プロビジョニングされたプライベートネットワークインターフェース３４を有するリゾルバオペレータ）から表向きに偽装されている可能性がある。（攻撃ネットワークトラフィック７を見る可能性がはるかに低い）プライベートネットワークインターフェース３４で観測されたクエリトラフィック３０のパターン（例えば、コンテンツおよび／またはタイミングなど）は、プライベートネットワークインターフェース３４を用いる要求側サーバ１２の実際のエンドユーザの動作を示す可能性を高くし、ネットワーク１４、１６、１８から応答側サーバ１０によって一般的に（すなわち、全てのインターフェース３４、３６で）見られるネットワークトラフィック７をよりよく特徴付けるために、ペアリングデータ３８によって表されるトラフィックモデルの生成及び更新を容易にする。

ネットワークトラフィック７の優先順位付けは、応答側サーバ１０と応答側ネットワーク１８の関連付けられたネットワークデバイス２２とによるネットワークトラフィック７の受信を許可または無視する（したがって影響しない）こととして定められ得る。例えば、割り当てられたプライベートネットワークインターフェース３４上の事前に定められた要求側サーバ１２から到着するネットワーク要求トラフィック３０は、優先順位付けられ、すなわち望まれるので、適切なネットワーク応答トラフィック３２を作成および送出する際に応答側サーバ１０によって処理されるようにそのままにされる。逆に、優先順位の低いネットワークトラフィック７は、優先順位が低いと考えられるネットワークトラフィック７（例えばパケットなど）をドロップすることによって実現される（すなわち、ペアリングデータ３８との照合において、異常な、したがって望ましくないネットワークトラフィック７として分類またはそうでなければカテゴリー化されるとみなされるネットワークトラフィック７）。したがって、（優先順位付けの動作が実行されなかった）残存しているネットワークトラフィック７は、「優先順位付け」されているとみなされる。したがって、優先順位付けは、受動的行為と呼ぶことができる。データ管理システム５２によって無視されることで、応答側サーバ１２によって、残存とその後に作成された応答トラフィック３２が保証される。以下に説明する応答側サーバ１２、データ収集システム５０、およびデータ管理システム５２の構成および動作における優先順位付けとして好ましくは例として利用されるのは、所望のネットワークトラフィック７を無視することである。

以下でさらに説明する優先順位付け基準３９／コマンド４０の実装に関するデータ管理システム５２の機能性はまた、コンテンツデータ４１ａおよびコピー分析データ６０ａの格納された優先順位付け基準３９ａ／コマンド４０ａを照合して選択された要求側サーバ１２によって同様に実装できることが認識される。以下で説明する例示的な優先順位付け基準３９／コマンド４０の実装は、（上記で論じたように）応答側サーバ１０とは独立して受信および処理されるネットワーク要求３０に対して要求側サーバ１２によって同様に実装されることができる。したがって、例えば、優先順位付けは、アクティブな動作と呼ぶことができ、要求側サーバ１２が動作することで、要求側サーバ１２による作成された応答トラフィック３２のブロック／ドロップおよびその後の抑制（またはそうでなければ回避）を提供する。

さらに、要求側サーバ１２はまた、ネットワークトラフィック７を正常／異常として識別する（データペアリング３８ａと照合して、ならびに優先順位付け基準３９ａを実装する際に）使用するための構成／機能性を有し得る。さらに、要求側サーバ１２は、照合の結果として優先順位付けコマンド４０ａをネットワークデバイス２０、２１に送信するように構成されることができる。しかしながら、代替的に、ネットワークトラフィック７の優先順位付けは、要求側サーバ１２と要求側ネットワーク１４の関連付けられたネットワークデバイス２０とによるネットワークトラフィック７の受信を拒否するか、さもなければブロック／ドロップする（したがって影響を与える）と定められ得ることが認識される。例えば、パブリックネットワーク１６上の事前に定められたソースデバイス８から到着するネットワーク要求トラフィック３０は、優先され、すなわち望ましくなく、したがってドロップされるか、または適切なネットワーク応答トラフィック３２を作成および送信する際に要求側サーバ１２による処理から制限される。逆に、優先順位の低いネットワークトラフィック７は、優先度が高いとみなされるネットワークトラフィック７（パケットなど）を無視することで実現される（すなわち、ペアリングデータ３８ａとの照合で通常どおり、したがって望ましいネットワークトラフィック７として分類またはそうでなければカテゴリー化されるとみなされるこれらのネットワークトラフィック７）。したがって、（優先順位付けの動作が実行されなかった）残存しているネットワークトラフィック７は、「優先順位を下げられる」とみなされる。したがって、優先順位付けは、アクティブな動作と呼ぶことができる。要求側サーバ１２によって動作されると、要求側サーバ１２による作成された応答トラフィック３２のブロック／ドロップおよびその後の抑制（または回避）が提供される。以下で論じるように、他の記述された優先順位付けアクションの例は、ペアリングデータ３８ａおよび／または優先順位付け基準３９ａと照合して、受信したネットワーク要求３０で（応答側サーバ１０および／またはデータ管理システム５２ではなく）要求側サーバ１２によって直接実装され得る。

図２を参照すると、ペアリングデータ３８および／またはネットワークトラフィックアルマナックの優先順位付け基準３９を生成または更新するための、データ収集システム／モジュール５０によるネットワークトラフィック７の監視に使用するトレーサビリティサービス５３が示される。さらに、トレーサビリティサービス５３はまた、ネットワークトラフィック７を（ネットワークトラフィックのアルマナックのデータペアリング３８との照合において）正常／異常として識別する際、および優先順位付け基準３９の実装の際またはそのような優先順位付け基準３９を応答側サーバ１０への提案の際に使用するデータ管理システム５２を含むことができる。さらに、データ管理システム５２は、照合の結果として優先順位付けコマンド４０をネットワークデバイス２１、２２（および応答側サーバ１０）に送信するように構成されることができる。しかしながら、代替的に、ネットワークトラフィック７の優先順位付けは、応答側サーバ１０と応答側ネットワーク１８の関連付けられたネットワークデバイス２２とによるネットワークトラフィック７の受信を拒否するか、さもなければブロック／ドロップする（したがって影響を与える）ように定義されることができることが認識される。例えば、パブリックネットワークインターフェース３６上の事前に定められた要求側サーバ１２から到着するネットワーク要求トラフィック３０は優先され、すなわち望ましくないため、適切なネットワーク応答トラフィック３２を作成および送信する際に応答側サーバ１０によって処理されないようにドロップまたは制限される。逆に、優先順位の低いネットワークトラフィック７は、優先順位が高いと考えられるネットワークトラフィック７（例えばパケットなど）を無視することで実現される（すなわち、ペアリングデータ３８との照合において、正常、したがって望ましいネットワークトラフィック７として分類または分類されるとみなされるネットワークトラフィック７）。したがって、（優先順位付けの動作が取られなかった）残存しているネットワークトラフィック７は、「優先順位を下げられる」とみなされる。したがって、優先順位付けは、アクティブな動作と呼ぶことができり。データ管理システム５２が動作すると、応答側サーバ１０による作成された応答トラフィック３２のブロック／ドロップおよびその後の抑制（またはその他の回避）が提供される。

再び図１及び２を参照すると、データ管理システム５２は、事前に定められたペアリングデータ３８（および以下でさらに説明するペアリングデータ３８の更新）とともに実装できる動的ネットワークトラフィック７の分類の機会と、事前に定められたペアリングデータ３８で表される結果の派生データセットに基づいて、不要なネットワークトラフィック７を動的に識別して扱う機会とを提供する（またはそうでなければ制約付きネットワーク１４、１６、１８の容量シナリオでネットワークトラフィック７に優先順位を付ける）。したがって、データ管理システム５２は、データ収集システム５０による関連付けられたペアリングデータ３８の生成／更新を伴うマルチインターフェース３４、３６の利用と併せて、ペアリングデータ３８（例えば、ネットワークトラフィックのアルマナック）の使用により通知される決定により駆動される望ましくない／スプーフィングされた（spoofed）ネットワークトラフィック７とみなされた処理（例えば、ドロップ）のための汎用アプローチを提供する。

例えば、応答側サーバ１０は、プライベートネットワークインターフェース３４を介して事前に定められたソースデバイス８からアドレス指定された第１の要求トラフィック３０を受信し、ネットワーク１４、１６、１８を介して事前に定められたソースデバイス８に（例えば、要求側サーバ１２を介して）通信するために、第１の応答３２を生成し、ネットワーク１４、１６、１８を介して（例えば、プライベートネットワークインターフェース３４またはパブリックネットワークインターフェース３６を使用して）第１のレスポンス３２を送信することにより、第１の要求トラフィック３０を処理する。続いて、応答側サーバ１０は、パブリックサービスインターフェース３６を介して事前に定められたソースデバイス８のアドレスを有する第２の要求トラフィック３０を受信し、アドレスを用いてソース接続データベース２４を照合し、第２の要求トラフィック３０が事前に定められたペアリング３８において定義された事前に定められたソースと一致することを決定し、第２の応答３２の生成に関して第２の要求トラフィックに優先順位付け基準を動的に適用することにより、プライベートネットワークインターフェース３４の直接的な相互接続ではなくパブリックサービスインターフェース３６で受信されている第２の要求トラフィック３０に基づいて、第２の要求トラフィック３０の処理の優先順位を下げる（例えば、ドロップなど）。第２の応答３２はヌル応答（例えば、クエリを受信した応答を生成しないという決定）であり得ることが認識される。したがって、ヌル応答は優先順位の降下の１つの形式となる可能性がある。さらに、例えば、インバウンドネットワーク要求トラフィック３０の優先順位を下げる（例えば、ドロップする）複数の機会があり得る（例として、優先順位付けは、プライベートネットワークインターフェース３４を介して受信したトラフィックを「ドロップしない」ことを意味し、そのようなトラフィックをネットワークトラフィックの１つのクラスとしてより高い優先度と見なし、一方で、パブリックネットワークインターフェース３６で受信されたネットワーク要求トラフィック３０の従属クラスでドロップなどのアクションを実行することにより、ネットワークトラフィック処理の効率を達成することを認識する）。

１つまたは複数の優先順位付け基準に関して、ネットワーク要求トラフィック３０がプライベートネットワークインターフェース３４上で予期されたが、パブリックネットワークインターフェース３６上で受信されたという事実を利用するために使用できるいくつかの選択肢がある（データベース２４に格納されるネットワークトラフィックのアルマナックと照合して識別されるように）。応答側サーバ１０は、最も一般的には、共有／パブリックインターフェース３６上のトラフィックの優先順位を下げ、応答側サーバ１０は、みなされたダーティなトラフィックを受信すると予想する。トラフィックがクリーンである（または少なくともパブリックネットワークインターフェース３６よりもクリーンである）とみなされ、その容量が管理するのに容易であるとみなされるプライベートネットワークインターフェース３４の直接的な相互接続は、アクティブな優先順位を下げることを必要とする可能性が低い（たとえば、対応する応答を提供することに失敗することによる要求のドロップ）。例えば、１つの優先順位付け基準は、サブネットワーク１６ａ内のデバイス２１を使用するなどのネットワーク１６において、応答側ネットワーク１８の外部の動作を実装することであろう。これは、要求トラフィック３０がまだ他の誰かのネットワークにあるため、この時点で要求トラフィック３０が応答側ネットワーク１８のネットワーク容量（たとえば、応答側サーバ１０の処理リソース）を全く消費していないため、インバウンド要求トラフィック３０をドロップするのに最も効率的な場所である。要求側ネットワーク１４で要求トラフィック３０をドロップする機能は、優先順位付けコマンド／提案４０としてサブネットワーク１６ａのネットワークデバイス２１に送信される（たとえば、「送信元アドレスＸからのものであると主張する全てのトラフィックをドロップする」または「ネームサーバドレスＹに向けられた全てのトラフィックをドロップする」またはそれらのいくつかの組み合わせの形式の）基準を有し得る。サブネットワーク１６ａのネットワークデバイス２１は、識別されたソースデバイス８から受信したネットワーク要求トラフィック３０をドロップすることにより、優先順位付けコマンド／提案４０を受信し、格納し、その後利用することになり、応答側サーバ１０、またはそれらの任意の組み合わせに向けられる。代替的には、優先順位付けコマンド／提案４０は、応答側サブネットワーク１８ａのネットワークデバイス２２に提供され得る。応答側サブネットワーク１８ａのネットワークデバイス２２は、識別されたソースデバイス８から受信された任意のネットワーク要求トラフィック３０をドロップすることにより、優先順位付けコマンド／提案４０を受信し、保存し、その後利用することになり、応答側サーバ１０、またはそれらの任意の組み合わせに向けられる。

さらなる例の優先順位付けアクションは、応答側ネットワーク１８内でさらに、すなわち、サブネットワーク１８ａによって表されるネットワークエッジを越えて、応答側ネットワーク１８内のネットワークデバイス２２（たとえば、ルータ、スイッチ）を適切に使用して実装され得る。この時点で、ネットワーク要求トラフィック３０は、応答側サーバ１０と要求側サーバ１２との間のネットワーク容量を既に消費しているが、ネットワーク要求トラフィック３０は、応答側サーバ１０自体または我々のプロバイダエッジ（例えば、ネットワーク１６、１８と応答側サーバ１０自体の間のインターフェース）間の完全な内部ネットワーク１８のパス上のリソースをまだ消費していない。このように構成されたネットワークデバイス２２を利用して、応答側ネットワーク１８内の適切な場所でクエリをドロップすることは、上流でドロップするほど効果的ではないかもしれないが、ネットワーク要求トラフィック３０を応答側サーバ１０自体に流すよりは良いと考えられる。この例では、応答側ネットワーク１８のルーター２２を最適化して、サーバよりも大きなトラフィックのフラッド（flood）を処理できるため、サーバをルーターで保護することは有益である。したがって、ネットワークデバイス２２（例えば、ルータ）は、受信したような優先順位付けコマンド／提案４０によって構成して、要求側ネットワーク１４に対して上流に送信できるよりも豊富な語彙でドロップするためのネットワーク要求トラフィック３０を識別することができる。したがって、より細かい粒度で応答側ネットワーク１８のネットワーク要求トラフィック３０をドロップする見込みがある。たとえば、優先順位を下げる基準は、これらに限定されないが、例えば、ＵＤＰソース、宛先ポート、プロトコル、および／またはレート制限基準、ならびに単純な破棄動作などのソースおよび宛先アドレス以外のネットワークトラフィック７（たとえば、パケットなど）において伝送されるパラメータに基づくドロップするネットワークトラフィック７を含むことができる。

更なる例の優先順位付けアクションは、応答側サーバ１０自体に実装されることができる。この時点で、ネットワーク要求トラフィック３０は消費する可能性のある全てのリソースを消費しているが、応答側サーバ１０は、パブリックネットワークインターフェース３６で受信したネットワーク要求トラフィック３０をドロップする可能性があり、そのため、応答側ネットワーク１８での送信時により多くのリソースを消費することになる実質的なネットワーク応答トラフィック３０の生成を回避する。応答側サーバ１０では、以前の全ての基準と、追加のＤＮＳ固有の基準、たとえば、再構築されたＤＮＳネットワーク要求トラフィック３０のメッセージ（たとえばパケットなど）内にあるＤＮＳ固有のパラメータを使用してドロップすることができる。優先順位付けアクションの１つの選択肢は、マルウェアに関連付けられた特定の不快なドメインネームのクエリと、同一のクライアントから無害な別のクエリとを区別することである。悪意のあるクエリ（すなわち、そのソースアドレスがサードパーティの攻撃対象システムのアドレスに設定されている）への応答の生成を回避することはまた、応答が攻撃トラフィックとして意図されていた可能性があるネットワーク１４、１６、１８上の他の潜在的な被害者を保護することができる（これは「リフレクション攻撃」の本質である）。たとえば、もっともらしい例は、DNSクエリ名（「QNAME」）やクエリタイプ（「QTYPE」）などのＤＮＳパラメータを、ドロップするトラフィックと照合するために使用される基準のセットにおいて使用することである。たとえば、単一の要求側サーバ１２は、エンドユーザによる現実のアクティビティに関連する多くのクエリを応答側サーバ１０に送信する場合があるが、技術的に有効な値であるQTYPE = NULLを使用してクエリを我々に送信することもあるが、エンドユーザのアクティビティの結果としてほとんど見られない。別の例は、常にマルウェアに直接関連付けられているＤＧＡ（生成されたドメインネーム）に一致するQNAMEを使用したクエリである。

クリーントラフィックがどのように見えるかを理解することで、これら３つの異なる領域のそれぞれでドロップの決定を行うことの影響をよりよく理解し、特定の方法でトラフィックをドロップする決定が他の正当なトラフィックに付随的な影響を与えるリスクを減らすことができる。正味の効果は、正当なトラフィックの品質を向上させることである。

図２を参照すると、一定期間にわたる応答側サーバ１２（権限のあるネームサーバなど）に対するデータ収集システム５０によるインバウンドネットワークトラフィック７の収集および分析は、（例えばネットワークトラフィック７を応答側サーバ１０に転送するデータソースとして動作する要求サーバ１０など）少数の非常にアクティブなネットワークソースを公開することができる。ネットワーク要求トラフィック３０の分析は、ネットワークトラフィック７のタイプ、ソース／宛先アドレス、およびネットワークトラフィック７を配信するために使用される特定のインターフェース３４、３６の分布を示す。さらに、特定のネットワーク１４、１６、１８の部分および／または一連のネットワークデバイス９（ネットワーク経路または経路部分を定義する）もまた、ネットワークトラフィック７の分析において識別され得る。

データ管理システム５２が（ネットワークトラフィック７のパケットパラメータと、ストレージ２４に格納された事前に定められたペアリングデータ３８との比較によって識別されるような）プライベートネットワークインターフェース３４を介して期待するパブリックネットワークインターフェース３６を介してネットワークトラフィック７が到着する原理は無効である可能性が高い（たとえば、ソーススプーフィング）。そのため、サーバ１０、１２間の直接的な相互接続としてのプライベートネットワークインターフェース３４の存在は、ネットワーク１４、１６、１８から受信した一般的なネットワークトラフィック７の正常性／異常性の評価を容易にする。これは、そのように識別されたとき、無効化された（例えば、ソーススプーフィングされた）ネットワークトラフィック７に関連付けられた優先順位付け基準３９と共に、データ管理システム５２によるトラフィックの優先順位付けの基礎として使用され得る。

例えば、ネットワークトラフィック７は、パケット化されたデータとして構造化された考慮されたステートレスデータから構成される。ネットワークトラフィック７のパケットは、デジタル通信ネットワーク１４、１６、１８上の通信の基本単位として定義されることができる。パケットは、通信ネットワーク１４、１６、１８を介したデータの送信に使用されるプロトコルに応じて、データグラム、セグメント、ブロック、セル、またはフレームと呼ばれることもある。データを送信する必要がある場合、データは送信前に同様のデータ構造に分解され、パケットと呼ばれ、宛先に到達すると元のデータチャンクに再構成される。データパケットの構造は、パケットのタイプと転送に使用されるプロトコルとによって異なるが、各データパケットはヘッダとペイロードとを有することができる。ヘッダは、パケット、サービス、およびその他の伝送関連データに関するオーバーヘッド情報を維持するために使用され得る。たとえば、インターネット経由のデータ転送は、データをＩＰ（インターネットプロトコル）で定義されているＩＰパケットに分解することを要求する。ＩＰパケットは、データを送信するマシンのＩＰアドレスであるソースＩＰアドレス；データの送信先のマシンまたはデバイスである宛先ＩＰアドレス；パケットを順番に並べ、元のデータを送信前の状態に正確に戻す方法で再構成するパケットのシーケンス番号；サービスのタイプ；関連するフラグ；パケットの大部分を表し、実際に運ばれるデータであるペイロード自体を含むことができる。たとえば、上記のペイロード自体以外の全てのデータは、オーバーヘッド情報とみなすことができる。

ネットワークトラフィック７の例として、ＤＮＳ要求３０は、名前（またはおそらくいくらか任意のテキストフィールド）とレコードタイプとを指定する質問を含むことができる。応答の内容はタイプによって異なることになる。ＤＮＳプロトコルは、クエリ３０と返信３２との２種類のＤＮＳメッセージを使用するため、どちらも同じ形式にすることができる。各メッセージは、ヘッダと４つのセクション：質問、回答、権限、および追加のスペースとからなることができる。ヘッダフィールド（フラグ）は、これらの４つのセクションの内容を制御する。要求３０は、応答に（タイプＡ）おいてＩＰアドレスを探す、並びにネームサーバ自体（タイプＮＳ）、メールレコード（タイプＭＸ）、およびその他のサービス（ネーム、ポート、重み、優先度を返すことになるタイプＳＲＶ）に関する詳細情報を探す、サーバネームの単一の直接的なルックアップであり得る。ＤＮＳ応答３２は、ＤＮＳ要求３０のこれらの質問に対する回答を含むことができ、ＤＮＳ要求３０がそれを必要とし、常に単なるＩＰアドレスであるとは限らない場合は、複数回答することができる。

たとえば、ＤＮＳメッセージのヘッダセクションは、クエリＩＤ、フラグ、質問セクションのエントリ数、回答セクションのエントリ数、機関セクションのエントリ数、および追加のセクションのエントリ数を含むことができる。クエリＩＤフィールドは、応答をクエリと突き合わせて照合するために要求側サーバ１２によって使用されることができる。フラグフィールドは、いくつかのサブフィールドからなることができる。第１は、メッセージがクエリ（0）であるか応答（1）であるかを示す単一ビット（「QR」）であり得る。第２のサブフィールドは４ビットからなることができる。これらのビットは、ＤＮＳメッセージ（"OPCODE"）の目的を記述する値を一緒に形成する。これは、一般に１で、要求側サーバ１２と応答側サーバ１０との間のクエリトラフィックの「クエリ」を意味するが、他の値は他の目的のために存在する。単一のビットサブフィールド（「AA」）は、ＤＮＳサーバ１０からの応答の応答セクションの内容が、応答を受信した要求側サーバ１２によって信頼できるとみなされるべきかどうかを示すことができる。別の単一のビットサブフィールドは、クライアント（デバイス８、１２）が再帰クエリ（「RD」）を送信するかどうかを示すことができる。次の単一のビットサブフィールドは、全てのＤＮＳサーバがこのタスクを実行するように構成されているわけではないため、応答するＤＮＳサーバ１０が再帰（「RA」）をサポートするかどうかを示すことができる。別のサブフィールドは、要求３０が何らかの理由（「TC」）で切り捨てられたかどうかを示すことができ、４ビットのサブフィールドはステータスを示す。質問セクションは、ドメインネーム（「QNAME」）、レコード（A、AAAA、MX、TXTなど）のタイプ（「QTYPE」）、およびインターネット上での使用のために決定されるネームが通常INであるネームのクラス（「QCLASS」）を含むことができる。ドメインネームは、連結された個別のラベルに分解されることができる。各ラベルは、ラベル自体によって続くそのラベルの長さとして、または同じメッセージ内のドメインネームの別のエンコードへのポインタとして、ＤＮＳメッセージのワイヤー形式でエンコードされる。メカニズムは、ＤＮＳメッセージのサイズの削減に役立つラベル圧縮と呼ばれる。回答セクションは、質問セクションで記述されるクエリに関連するリソースレコードを含むことができる。単一のドメインネームは、それに関連付けられた同じまたは異なるタイプの複数のリソースレコードを有することができる。権限および追加のセクションは、応答側サーバ１０から要求側サーバ１２に返される応答のタイプに関連する追加情報を含む。

パケットベースのネットワークトラフィック７の上記の構造からわかるように、ペアリングデータ３８を生成して、インターフェース３４、３６のそれぞれの起点（origin）によってネットワークトラフィック７を事前にソートするためにプロトコルスタックの層がデータ収集システム５０によって識別される場合、応答側サーバ１０がリアルタイムで様々なトラフィックソースのトレーサビリティを決定することの困難さが回避され得る（すなわち、ネットワークトラフィック７の起点ならびにネットワークトラフィック７を配信するために使用される特定のインターフェース３４、３６がペアリングデータ３８に含まれる（例えば、ネットワークトラフィックＸに関するデータペアリングは、ネットワークソースＹが配信のためにインターフェースＺを使用することである））。したがって、応答側サーバ１０は、主にインターフェースＺ上でネットワークトラフィックＸ（ネットワークソースＹによってアドレス指定される）を受信することを期待するであろう。換言すると、トラフィック管理システム５２がインターフェースＺＺ（すなわちインターフェースＺ以外）を介してネットワークトラフィックＺを受信する例では、管理システム５２はデータベース２４に格納されたペアリングデータ３８を照合し、受信したネットワークトラフィックＸが誤ったインターフェース、すなわちインターフェースＺではなくインターフェースＺＺで受信されたことに注目するであろう。この識別に基づいて、データ管理システム５２は、インターフェースＺＺで受信されるネットワークトラフィックＸにどの優先順位付け基準３９を適用するかを決定することができ、それにより、インターフェースＺで受信される適切なネットワークトラフィックＸを実際に優先順位付けする。上述のように、それら自身の定義されたプライベートネットワークインターフェース３４へのアクセスを与えられた重要なトラフィックソース１２の数は、インターフェース３４、３６のマルチインターフェースモデルのプロビジョニングとして、データ管理システム５２によって管理可能であることが認識される。このインターフェース３４、３６のマルチインターフェースモデルは、互いに独立して（そして、より重要なことには、パブリックネットワークインターフェース３６を通して独立して入来する攻撃トラフィック）配信される方法において、各トラフィックソース（要求側サーバ１２など）の分離を提供する。複数の個別に定義されたインターフェース３４、３６を介して到着するネットワークトラフィック７と組み合わせてデータベース２４に格納されたペアリングデータ３８の単純な適用は、スクラビングサービス（scrubbing service）などの「リゾルバサービス」または計算コストが高くしたがって非効率的であるとみなされる機器の従来のデータ管理技術に依存する必要性を低減する。たとえば、スクラビング方法は、ネットワークメッセージが受信されるときにリアルタイムで実行される必要があり、パケット化されたネットワークトラフィックに関してパケットの様々な層が開かれる必要があり、コンテンツは誤ったメッセージについて分析される。これらは、サードパーティのスクラビング供給者によって典型的に管理される望ましくないブルートフォース手法とみなされる。リアルタイムのスクラブ方法を使用することは、要求の応答タイミングに悪影響を与える可能性があると認識される。

したがって、データ管理システム５２は、指定されたプライベートネットワークインターフェース（S）３４を介して比較的少数の識別された要求側ネットワーク１４からの要求ネットワークトラフィック３０の処理をもたらすために、要求側サーバトラフィック３０と、各要求側サーバ１２が機能するエンドユーザ集団（すなわち、ネットワークソース８）のサイズとの間に存在する（ペアリングデータ３８の）相関に依存する。ペアリングデータ３８の生成および実装は、パブリックネットワークインターフェース３６を共有する大部分のエンドユーザ（たとえば、ソースデバイス８など）の体験に影響を与える可能性がある。パブリックネットワークインターフェース３６を不適切に使用する任意に識別されたネットワークトラフィック７は、優先順位付け基準を介してそれに応じて（たとえば、ドロップして）対処されることができるため、パブリックネットワークインターフェース３６を適切に利用しているエンドユーザ（たとえば、ソースデバイス８）の大部分のために、パブリックネットワークインターフェース３６の残りの帯域幅／容量を解放するためである。たとえば、ＤＮＳネームサーバ１０のインフラストラクチャを使用したネットワークトラフィック７の分析では、30,000を超える１１のリゾルバサーバ１２が、ＤＮＳネームサーバ１２が受信したクエリトラフィックのほぼ半分を占めていた。この情報は、１１の識別されたリゾルバサーバ１２に対するプライベートネットワークインターフェース３４のプロビジョニングとともに適切な最初のペアリングデータ３８を生成するためにデータ収集システム５０によって使用された。したがって、この例では、我々のクエリトラフィック３０の半分は、その特性はよく理解されている専用の内部接続（すなわち、プライベートネットワークインターフェース３４）経由で到達させることができる。その結果、それらによって利用されるパブリックネットワークインターフェース３６で同様に半分になり、不要なまたは処理が難しいトラフィックがエンドユーザに影響を与える可能性がある。したがって、これらのエンドユーザは、応答側サーバ１０によってネットワークインターフェース３６上で受信されるようなネットワークパスのそれらのクエリトラフィックに関わらず、不明なネットワークトラフィック７による中断のリスクを低減することができる。

上記は、プライベートネットワークインターフェース３４を使用して識別された要求側サーバ１２と、パブリックネットワークインターフェース３６を使用して分散されたソースデバイス８との両方にとって、攻撃トラフィックをソースおよび配信する機能としての主な利点である。規模が大きくなると、事前に定められたペアリングデータ３８でマルチインターフェース３４、３６のアーキテクチャを使用しないと、権限のあるサーバ側で対応する容量を提供するコストと複雑さが増す。簡単に言うと、単純に非インテリジェントにネットワーク１４、１６、１８の容量を増やして、予想されるピークトラフィックに先んじて構築するだけで、高度に分散したボットネットインフラストラクチャと競合することは、もはや不可能であり、費用対効果または実用性を気にすることはない。したがって、専用の要求側サーバ１２の相互接続３４の成長特性は、ネットワークトラフィック７の容量がパブリックネットワークインターフェース３６に到達することを予測するのをはるかに容易にし、両側（要求側サーバ１２と応答側サーバ１０のオペレータ間）でのオペレータの対話の可能性、および（事前に定められたペアリングデータ３８によって例示されるように）関連するネットワークトラフィック７の総合的な理解に対して少なからず感謝する。ネットワークトラフィックパラメータ（パケットヘッダの送信元アドレスなど）の照合／比較によって識別されるように、「不要な」ネットワークトラフィック7が専用の要求側サーバ１２の相互接続３４上で機能／存在する場合、その根本的な原因を理解して軽減することは実用的なアプローチであり、一般的なサービスをインターネット全体に配信するのとは対照的である。ここで説明したように、特定のトラフィックを担当する事業者を識別することさえ難しい場合がある。

ペアリングデータ３８は、指定されたネットワークソースアドレス（例えば、要求側サーバ１２のネットワークアドレス）からのそのようなネットワークトラフィック７を期待するプライベートネットワークインターフェース３４のインターフェース識別子に関連付けられたネットワークソースアドレスを含むことができる。さらに、オプションとして、ペアリングデータ３８はまた、通信プロトコル固有のパラメータ（要求タイプなど）を含めることができる。たとえば、ＤＮＳプロトコルの場合、ペアリングデータ３８は、ＤＮＳ固有のパラメータ（QNAME、QTYPE、RCODEなど）を含むことができる。このようにして、ペアリングデータ３８は、ＤＮＳ固有のパラメータ（たとえばQNAME、QTYPE、RCODEなど）及びエニーキャスト配信パラメータ（たとえば、要求側サーバ１２のネットワークアドレスの場所固有のパラメータ）の（インターフェース３４の）特定の相互接続識別子を有する集約ＤＮＳデータを含むために、次元的に拡張される。

したがって、ペアリングデータ３８と共に使用されるマルチインターフェース構成の利点は、個々の要求ソースのみなされた正常性がネットワークトラフィック要求３０によってとられる経路に依存することである；たとえば、ネットワーク要求トラフィック３０の指定された要求側サーバ１２（たとえば、Google（登録商標） Public DNS）に関連付けられたソースネットワークアドレスは、そのようなネットワーク要求トラフィック３０が指定された要求側サーバ１２を使用して直接的な相互接続（すなわち、割り当てられたプライベートネットワークインターフェース３４）経由で到着した場合には、そのようなネットワーク要求トラフィック３０が他のインターフェース（たとえば、パブリックネットワークインターフェース３６）を介して到着した場合よりも、より良い正規スコアを合理的に享受する。データ管理システムは、スプーフィングされる（すなわち、異常とみなされる）と、そのようなネットワーク要求トラフィック３０に合理的にアクセスする可能性がある。正規性の識別プロセスに追加されるのは、プロトコルパラメータの追加または置換であり得る。たとえば、要求側サーバ１２から不適切に（すなわち、指定された（すなわち、割り当てられた）プライベートネットワークインターフェース３４ではなくパブリックネットワークインターフェース３６に）到着するネットワーク要求メッセージ３０は、ネットワーク要求メッセージ３０の関連するプロトコルパラメータ（例えば、要求タイプ）に応じて、異なる方法で処理される／優先順位を下げられることになる。

図２を参照すると、データ管理システム５２およびデータ収集システム５０は、例えば、専用の受動測定サービス（すなわち、サーバ１０、１２の間を流れるネットワークトラフィック７を妨害することなくネットワーク要求トラフィック３０およびネットワーク応答トラフィック３２を聴取するサービス）を有するように構成されたサーバ（図４を参照）上でホストされ得る。たとえば、ネットワーク要求トラフィック３０およびネットワーク応答トラフィック３２は、ストレージ２５に格納されているデータ収集システム５０によって定期的（たとえば５分）のデータサンプルウィンドウでキャプチャされる。次に、定期的なウィンドウのこれらのデータサンプルは、データ収集システム５０によって、ネットワークトラフィック７の各メッセージをその構成パラメータ（例えば、メッセージソースアドレス、メッセージ宛先アドレス、メッセージタイプ、受信されるインターフェース３４、３６など）に分解するバッチ処理を行われる。考慮される各パラメータは、パラメータの観測値に従って増加する対応するパラメータカウンタを有する。これらのパラメータカウンタは、定期的に（たとえば、各定期的なウィンドウの後に）フラッシュされ、ストレージ２５に集中する。各パラメータカウンタは、各パラメータカウンタが対応する期間を示す正確なタイムスタンプを有する。パラメータの例は、メッセージを運ぶ（例えばＤＮＳなどの）トランスポートプロトコル（現在はＤＮＳプロトコルのＵＤＰまたはＴＣＰ）、その下で使用されている（例えばＩＰなどの）ネットワーク１４、１６、１８のプロトコル（現在はIPv4またはIPv6）、メッセージタイプ（例えばQNAMEなど）、ソースネットワーク１４（ソースアドレスから導出された一般化された値）、クエリが受信された応答側サーバ１０、およびメッセージが受け取られたインターフェース３４、３６に割り当てられた相互接続識別子である。受信された全ての要求トラフィック３０および送信された応答トラフィック３２の集合的なカウントが維持されることが認識されている。このようにして、パラメータカウントは、メッセージを分類するために使用されるパラメータに応じて、応答側サーバ１２およびメッセージを期待するインターフェース３４、３６に関して到着／送信される特定のメッセージの予想される量を識別する。このようにして、ペアリングデータ３８は、時間の経過に伴うネットワークトラフィック７の流れなどを予測するために、パラメータカウント、パラメータ自体、メッセージの期間などを含むことができ、それにより、ネットワークトラフィックのアルマナックをストレージ２４に確立する（例えば、データ収集システム５０により転送され、データ管理システム５２により使用されるように）。データ収集システム５０および／またはデータ管理システム５２は、応答側サーバ１０および／または応答側サーバ１０と通信する別個のサーバ上でホストされ得ることが認識される。例えば、別個のサーバ実装の場合、応答側サーバ１０は、リアルタイムで識別されたネットワークトラフィック７のパラメータを使用して別個のサーバに問い合わせ、その結果、データ管理システム５２は、リアルタイムのネットワークトラフィック７のパラメータと特定のインターフェース３４、３６に関連付けられたペアリングデータ３８との比較の結果として、ネットワークトラフィック７が正常または異常に分類されるかどうかを識別することができる。

パラメータカウンタの比較は、データ管理システム５２がネットワークトラフィック７の特性を推測することを容易にすることが認識される。たとえば、特定のサンプル期間のウィンドウの場合、直接的なインターフェース３４のリンクＡを介して到着する全てのネットワーク要求トラフィック３０のパラメータカウンタが１０００であり、ＵＤＰトランスポートを使用するそのような全てのネットワーク要求トラフィック３０のパラメータカウンタが９８０であり、そのような全てのネットワーク要求トラフィック３０およびＴＣＰトランスポートが２０である場合、我々は、そのサンプル期間のウィンドウの間に、ネットワーク要求トラフィック３０の特定の割合（たとえば９８％）があるトランスポート（たとえばＵＤＰ）を用いて到着し、別の割合（たとえば２％）が別のトランスポート（たとえばＴＣＰ）を使用して到着したとみなすことができる。我々は、他のパラメータを使用して、ネットワークトラフィック７をさらに特徴付けることができる。我々は、特定の応答側サーバ１０で、受信した全てのネットワーク要求トラフィック３０の決定された割合（４０％など）が、それぞれのＴＬＤ（たとえばＣＯＭなど）で指定されたドメインネームに対するものであることを決定することができるか、またはドメインを要求したランク付けされた順序（例えば、トップテンなど）がドメインの特定のセットであると決定することができる。

さらに、ペアリングデータ３８は、経時的に追跡された相関の分析を含み、信号分析を使用してそれらが変化する方法を理解するためにデータ管理システム５２によって使用され得る。たとえば、他の規則的な振動がなく、時間とともに徐々に増加する関係は、将来の通常の動作が続くことを予測するために使用され得る。実際には、データ管理システム５２は、ネットワークトラフィック７の将来の動作を予測するネットワークトラフィックのアルマナックを構築するのに十分長い時間ベースで観測された信号特性を使用している。信号分析の技術は、例えば、クラスター分析、予測機械学習、単純なフーリエ分析などを含むことができる。

例えば、データ管理システム５２は、優先順位付けコマンド４０（例えば、ＲＴＢＨのようなシグナリングのためのＢＧＰへの抽出された軽減データセット）を、例えば、ＩＰ層の上流プロバイダに送信することができる。ネットワークデバイス２０、２１、およびネットワークデバイス２１、２２へのフロースペックのようなシグナリングは、応答側ネットワーク１８と連携して動作する。これらの優先順位付けコマンド４０を使用すると、（ペアリングデータ３８に含まれるパラメータによって提供されるような）拡張ボキャブラリで上流プロバイダと連携して、単純なＲＴＢＨ処理で許可されるよりも豊富なパターンマッチングが可能になる。

図１、２、および４を参照すると、１または複数のサーバ装置１００（図３参照）で実行されるとき、トレーサビリティシステム５３によって実装されるような、トラフィック処理リソースの負担を軽減するために通信ネットワーク１４、１６、１８を介してネットワーク要求トラフィック３０のトレーサビリティを決定する方法２００が示される。方法２００は、１つまたは複数のサーバデバイス１００のコンピュータプロセッサ１０８によって実行されるように、ストレージ２４に格納されたアプリケーション１０７として実装することができる。ステップ２０２で、サーバ１０と事前に定められたソース１２との間の通信ネットワーク１４、１６、１８上に直接的な相互接続３４がプロビジョニングされ、直接的な相互接続３４は、事前に定められたソース１２と事前に定められたソース１２からアドレス指定されたネットワーク要求トラフィック３０を受信するように構成されたサーバ１０との間にプライベートサービスインターフェースを提供する。事前に定められたソース１２の定義されたペアリングデータ３８、直接的な相互接続３４は、ネットワークトラフィックアルマナックとしてストレージ２４に格納される。ステップ２０４で、事前に定められたソース１２および他のソース（例えば８）からアドレス指定されたネットワーク要求トラフィック３０を受信するように構成された、通信ネットワーク１４、１６、１８上のパブリックサービスインターフェース３６がプロビジョニングされ、パブリックサービスインターフェース３６は、直接的な相互接続３４とは別個である。ステップ２０６で、直接的な相互接続３４を介して事前に定められたソース１２からアドレス指定された第１の要求トラフィック３０が受信され、ステップ２０８で、応答側サーバ１０は、第１のクエリ応答３２を生成し、通信ネットワーク１４、１６、１８を介して事前に定められたソース１２と通信するためのダイレクト３４およびパブリックサービスインターフェース３６の少なくとも１つを介して第１のクエリ応答３２を送信することによって第１の要求トラフィック３０を処理する。ステップ２１０で、パブリックサービスインターフェース３６を介して事前に定められたソース１２のアドレスを有する第２の要求トラフィック３０が受信される。ステップ２１２で、データ管理システム５２は、定められたペアリングデータ３８をアドレスと比較して、第２の要求トラフィック３０が事前に定められたソース１２と一致することを決定するために照合され、その結果、事前に定められたソース１２は、事前に定められたソース１２に関連するペアリングデータ３８のインターフェースＩＤを介してペアリングデータ３８によって識別されるように、直接的な相互接続３４に関連付けられる。ステップ２１４で、データ管理システム５２および／または応答側サーバ１０は、比較の結果を利用して、第２の応答トラフィック３２を生成する前に第２の要求トラフィック３０に優先順位付け基準３９を動的に適用することにより、直接的な相互接続３４ではなくパブリックサービスインターフェース３６で受信される第２の要求トラフィック３０に基づく要求トラフィック３０の第２のサーバ１０による処理の優先順位を下げることにより、ペアリングデータ３８に関連付けられた優先順位付け基準（ｉａ）３９を実装する。優先順位付け基準（ｉａ）３９の実装は、ステップ２１６で、ネットワーク１８、サブネットワーク１８ａ、及びサブネットワーク１６ａのうちの少なくとも１つにおける１つまたは複数のネットワークデバイス２１、２２に優先順位付けコマンド４０を送信することを含み得ることが認識される。

また、上記でより詳細に説明したように、データ収集システム５０によってカウントデータに追加するためにネットワークトラフィック７を分析し、次にストレージ２４に格納されたカウントデータを使用してネットワークトラフィックのアルマナック内のペアリングデータ３８を更新するステップ２１８および２２０が示される。ステップ２２２は、ネットワークトラフィック７を動的に監視し、監視の分析結果に基づいて優先順位付け基準３９を調整することを含むことができる。

上記を考慮して、最初に説明した実施形態は、物理的な相互接続として構成された、および／またはネットワーク１４、１８に関して仮想的な（すなわち論理的な）相互接続インターフェース３４を提供する１つまたは複数の論理トンネルにおける、直接的な相互接続としてのプライベートネットワークインターフェース３４の例であることが認識される。したがって、応答側ネットワーク１８（例えば、権限のあるＤＮＳサーバ１０を含み、ＤＮＳ要求／応答データ３０、３２を発行するもの）とパートナー要求側ネットワーク１４（例えば、ネットワークソースデバイス８としてエンドユーザに代わってサーバ１０にＤＮＳ応答３２のデータを要求するＤＮＳリゾルバサーバ１２を含む）との間のプライベート直接ネットワーク相互接続３４。この直接的な相互接続３４なしでは、サーバ１２は要求３０をサーバ１０に送信し、サーバ１０は対応する応答３２を公衆インターネット（例えばパブリックネットワークインターフェース３６）を介してサーバ１２に送信することが認識される。インターネット（例えば、ネットワーク１６など）は、悪意のある無害な望ましくないランダムな混乱で満たされる可能性があることが認識されるため、パブリックネットワークインターフェース３６のインフラストラクチャ（例えば、デバイス２１など）に関連するこれらの要求３０および応答３２は、ネットワークリソースのための多くの他のトラフィック７のジャンク（junk）と競合する必要がある。たとえば、現在のＤＮＳプロトコルの性質は、正当なトラフィック７と区別してトラフィックをジャンクと区別することを難しくする可能性があるため、潜在的に正当なトラフィック７に優先順位を付けることは困難である。定められた直接的な相互接続３４を用いて、この問題を最小限に抑えることができるように、トラフィック７のジャンクがまったくないか、ほとんどない（たとえば、減少する）ことが予想される。インターネット１６からのトラフィック７のジャンクがネットワーク７のジャンクの津波になる場合、定められた直接的なパス（たとえば、プライベートネットワークインターフェース３４）は影響を受けず、サーバ１２を使用するエンドユーザは停止を認識できない場合がある。サーバ１０は、たとえネットワーク１６を介して他のサーバ１２のシステムが利用できても、サーバ１２を利用できないためである。

したがって、最初に説明した実施形態の実装は、以下に限定されないが、（ａ）サーバ１２がエンドユーザネットワークソースデバイス８にサービスを提供するために必要な応答３２のデータをサーバ１２に提供する能力、および（ｂ）様々な理由（たとえば、データ３８、３９および／またはドメインネーム業界に関する従来のビジネスインテリジェンスの生成および利用）のために応答側サーバ１０（および一般的に応答側ネットワーク１４のサーバ）に役立つ、サーバ１２が要求している要求３０に関する統計など、いくつかの利点を提供することができる。

説明した第２の実施形態に関して、データレベルの相互接続として提供されるプライベートネットワークインターフェース３４に関して、サーバ１０、５５がサーバ１２、１２ａに全てのデータ（例えば、応答側サーバ１０に利用可能なコンテンツデータ４１）の完全なセットを事前に提供できる場合、それを最新の状態に保ち、サーバ１２は要求ごとにリアルタイムでクエリをサーバ１０に送信する必要はない。サーバ１２は受信したネットワーク要求３０を個別に満たすために必要なコンテンツデータ４１ａへのローカルアクセスを既に持っているためである。また、サーバ１２、１２ａがサーバ１０、５５にプライベートネットワークインターフェース３４を介して送信することになるクエリ３０の統計（例えば、ペアリングデータ３８ａ）を供給することができるが、コンテンツデータ４１ａとの照合により独立して処理された場合、サーバ１０、５５は依然として、サーバ１０、５５がプライベートネットワークインターフェース３４上で通常受信することになるトラフィック７の統計についての有利な知識を有することになる。これは、共有コンテンツデータ４１ａによって例示されるデータレベルの相互接続によって定義され得るものである。

第２の実施形態を実装することのさらなる利点は、要求側ネットワーク１４が、その顧客（ネットワークソースデバイス８）に代わってパブリック要求側（例えばリゾルバ）サービスを操作する複数の場所（すなわちサーバ１２）を有することができることである。これらの様々なロケーションは、限られたローカルリソース（ラックスペース、電源など）を有し、多くのロケーションはローカル（人間）のエンジニアリングキャパシティに制限される（したがって、それら全てを同一にするために本当に一生懸命に努力している）。ロケーションの数は動的に変化する可能性がある。さらに、複数のロケーションは、プライベートネットワークで直接接続されない場合がある。したがって、プロビジョニングおよびコンテンツデータ（たとえば、メタデータ）は、調整サーバ１２ａによって、ネットワークを介して各ロケーション（すなわち、サーバ１２またはサーバ１２の集合）にプッシュされ得る。ロケーションの数が応答側ネットワーク１８のサーバ１０のロケーションの数よりも実質的に多い状況では、第１の実施形態の直接的なネットワーク相互接続３４の実装は、実用的／効率的でない可能性がある（たとえば、制限により、全てのサーバ１２のロケーション毎にサーバ１０のマイクロノードをインストールすることは、コストおよび／またはサーバ５５の管理のための運用ロジスティックスの観点から実用的ではない可能性がある）。

したがって、データレベルの相互接続３４がより適切に思われる状況では、要求側ネットワーク１４のインフラストラクチャは、独自のプロビジョニングシステムを使用する全てのサーバ１２の場所にメタデータ（たとえば、コンテンツデータ４１ａおよび／または優先順位付けデータ３９ａ）をプッシュし、サーバ５５での中央分析のために豊富なテレメトリ（すなわち、データのペアリング３８ａ）を復元するために利用され得る。原則として、データ４１、３９はサーバ１２、１２ａのメタデータとみなすことができ、ネットワーク要求３０ｙの独立した処理に消費及び使用され、プライベートネットワーク相互接続３４を介した応答側ネットワーク１８のサーバ１２、５５を用いて要求３０毎にリアルタイムのインタラクションをバイパスする。さらに、ネットワーク要求３０の独立した処理から受信された統計３８ａのサブセットは、上述のように、サーバ１０、５５が利用するデータ３８と一致することができる。

上記に鑑みて、第２の実施形態は、プライベートネットワークインターフェース３４の第２の実施形態を表す上記のデータレベルの相互接続のように、コンテンツデータ４１ａ（要求／応答３０、３２関連データを含む）をそれらのキャッシュに事前に入力することにより、要求側サーバ１２のキャッシュにクリアチャネルを実装する方法と呼ぶことができる。説明したように、要求側ネットワーク１４と応答側ネットワーク１８のサーバがどのようにインタラクションして、ゾーン全体のデータ（たとえば、要求側ネットワーク１４にコンテンツデータ４１ａとして格納されている応答側ネットワーク１８のコンテンツデータ４１）をシフトできるかが示される。コンテンツデータ４１、４１ａは、要求／応答３０、３２の関連データを含むことができるが、分析データ６０ａは、必要に応じて、ペアリングデータ３８、３８ａおよび／または優先順位付けデータ３９、３９ａを含むことができることが認識される。

したがって、データ収集モジュール５０は、アルマナック（たとえば、分析データ６０）を構築するために、（説明された第１および第２の有効な実施形態が両方とも同じサーバ５５および／または組み合わされたデータベース２４に関して実行される状況において）データ３８、３８ａの多様なソースを利用することができ、その一部は、トラフィック７の優先順位付けにデータを適用できるインフラストラクチャに関連することになるが、必ずしも全てではないことが認識される。例えば、（例えば、コンテンツデータ４１ａを利用する独立した要求側サーバ１２の動作からの、および／またはコンテンツデータ４１と照合して応答側サーバ１０の動作からの）多種多様なデータソースを使用する分析データ６０の構築は、ネットワーク１４、１６、１８で観測されたトラフィック７に関連する。組み込むことができる信頼性の高いデータペアリング３８、３８ａの数に制限はない。その結果、データペアリング３８、３８ａは、応答側サーバ１０及び関連付けられたサーバ５５によって実行されるインフラストラクチャ（例えば、応答側ネットワーク１８など）だけに制限されない。我々は、得られた他のデータペアリング３８、３８ａを有用に組み込むことができる。さらに、分析データ６０は、使用して、分析データ６０が異なるインフラストラクチャ（例えば、要求側ネットワーク１４）から得られたデータのペアリング３８ａを含むことができたとしても、（例えば、応答側ネットワーク１８における）独自のインフラストラクチャにおけるトラフィック７の優先順位付けを導くために使用され得る。他の用途があり得る：たとえば、我々は、分析データ６０を使用して、特定のタイプのＤＮＳクエリ３０または異なるＴＬＤでのアクティビティを予測することができる；我々は、他のサードパーティのサーバ（図示せず）に分析データ６０へのアクセスを有料で提供し、その結果、彼らは他のサードパーティのデータセットを構築することができる。そのため、分析データ６０（特に、要求／応答３０、３２のデータと一緒に、または独立した、ペアリングデータ３８及び優先順位付けデータ３９の一方）は、特定のネットワーク１４、１８でのトラフィック７の優先順位付け以外の他の潜在的な使用を有することができる。

図３を参照すると、サーバデバイス１００（例えば、応答側サーバ１０およびトレーサビリティサーバ５５、ならびにストレージ２４（メモリ１２２））の例が示される。図３ａに関して、サーバデバイス（例えば、要求側サーバ１２および／または調整サーバ１２ａ）について、ストレージ２４は、メモリ１２２’を表すことができる。

要求側サーバ１２、応答側サーバ１０、および任意選択でのトレーサビリティサーバ５５のコンピュータデバイス１００のためのストレージ２４の上記の説明を考慮して、ストレージ２４は、格納されたデータ（例えば、ネットワークトラフィックのアルマナックに関連付けられたペアリングデータ３８及び優先順位付け基準３９）を順に保持するように構成され得る。格納されたデータに対する主要な（または唯一の）操作は、ストレージ２４（たとえばＦＩＦＯ、ＦＩＡＯなど）からの格納されたデータの追加／修正または削除である。例えば、ストレージ２４は、格納されたデータの格納およびその後のアクセスのための線形データ構造であることができ、および／または格納されたデータの格納およびその後のアクセスのための非線形データ構造であることができる。

さらに、ストレージ２４は、後で処理するために格納され保持されるデータなどの様々なエンティティを受け取る。これらのコンテキストでは、ストレージ２４は、あるロケーションから別のロケーション（すなわち、コンピュータデバイス１００の間）にデータが移動している間、データ（たとえば、カテゴリカウント）を一時的に保持するために使用されるメモリ領域である、バッファの機能を実行することができる。典型的には、１又は複数のコンピュータ内／コンピュータ間でのプロセス間でデータを移動すると、データはメモリに格納される。ストレージ２４は、ハードウェア、ソフトウェア、またはそれらの組み合わせで実装できることが認識される。ストレージ２４は、データが受信される速度／時間とデータが（例えば、最終的にデバイス１００によって）処理されることができる速度／時間との間に差があるとき、ネットワークシステム６において使用される。

さらに、本明細書に記載のメモリ／ストレージ２４は、コンピュータプロセッサ／モジュールによるアクセスのためにデータを電磁的または光学的形式で保持できる物理的なロケーションであることは、当業者には理解されよう。一般的な使用法は２つある：第１に、メモリは、ハードディスク及びテープシステムなどの入出力操作を通じてコンピュータに接続されたデバイス及びデータ、並びにコンピュータメモリ及び他のコンピュータ内ストレージを含まない他の形式のストレージを意味するために頻繁に使用される。第二に、より正式な使用法では、メモリ／ストレージ２４は：（１）データをメモリ（ランダムアクセスメモリまたはＲＡＭと呼ばれることもある）及びプロセッサのＬ１などの他の「組み込み」デバイスキャッシュに保持するプライマリストレージと、および（２）ハードディスク、テープ、および入出力操作を必要とするその他のデバイス上のデータを保持するセカンダリストレージと、に分割され得る。プライマリストレージは、ストレージがプロセッサに近いため、またはストレージデバイスの性質のため、セカンダリストレージよりも高速にアクセスできる。一方、セカンダリストレージは、プライマリストレージよりもはるかに多くのデータを保持することができる。プライマリストレージは、ＲＡＭに加えて、読み取り専用メモリ（ＲＯＭ）とＬ１およびＬ２キャッシュメモリを含む。セカンダリストレージは、ハードディスクに加えて、ディスケット、Ｚｉｐドライブ、独立ディスクの冗長アレイ（ＲＡＩＤ）システム、ホログラフィックストレージなど、様々なデバイスタイプ及び技術を含む。ストレージを保持するデバイスは、まとめてストレージメディアと呼ばれる。したがって、カウントデータを保持するために使用されるストレージは、セカンダリストレージであることができ、ペアリングデータ３８および／または優先順位付け基準３９を保持するために使用されるストレージは、プライマリストレージであり得る。

データベースは、容易にアクセス、管理、および更新できるように編成された情報の集合としてのメモリ２４の一実施形態である。あるビューでは、データベースはコンテンツのタイプ（書誌、フルテキスト、数値、画像）に従って分類されることができる。コンピューティングでは、データベースは組織的なアプローチに従って分類されることがある。最も普及しているアプローチは、リレーショナルデータベースである。リレーショナルデータベースでは、表形式のデータベースにデータが定義されており、様々な方法で再編成およびアクセスされることができる。分散データベースは、ネットワーク内の様々なポイント間で分散または複製できるデータベースの１つである。オブジェクト指向プログラミングデータベースは、オブジェクトクラスとサブクラスで定義されたデータと一致するデータベースの１つである。コンピュータデータベースは、典型的に、販売トランザクション、製品カタログ及び在庫、並びに顧客プロファイルなどのデータレコードまたはファイルのアグリゲーションを含む。典型的に、データベースマネージャは、読み取り／書き込みアクセスの制御、レポート生成の指定、使用状況の分析などの機能をユーザに提供する。データベース及びデータベースマネージャは、大規模なメインフレームシステムで広く使用されているが、小規模な分散型ワークステーションやＡＳ／４００などの中規模システムやパーソナルコンピュータにも存在する。ＳＱＬ（構造化照会言語）は、IBM（登録商標）のDB2、Microsoft（登録商標）のAccess、Oracle（登録商標）、Sybase（登録商標）、およびComputer Associates（登録商標）からのデータベース製品などのデータベースからインタラクティブな照会を行ったり、データベースを更新したりするための標準言語である。

メモリ／ストレージ２４は、コンピュータのマイクロプロセッサが迅速に到達できる命令およびデータのための物理的な電子的保持場所として定義することもできる。コンピュータが正常に動作している場合、そのメモリは通常、オペレーティングシステムの主要部分と、使用されているアプリケーションプログラムと関連データの一部または全てを含む。メモリは、ランダムアクセスメモリ（ＲＡＭ）の短い同義語としてよく使用される。この種類のメモリは、コンピュータのマイクロプロセッサに物理的に近い１つ又は複数のマイクロチップに配置される。

サーバに関して、コンピュータデバイス１００は、ハードウェア、ソフトウェア、または典型的にはハードウェアとソフトウェアの両方の組み合わせとして構成され、ソケットリスナーとして動作するネットワークエンティティを提供できることが認識される。リソース（たとえばデータ）を１つ又は複数のクライアントプロセスと共有する任意のコンピュータ化されたプロセスは、ネットワークシステム６でサーバとして分類できることが認識される。サーバという用語は、ホストがネットワーク１４、１６、１８を介して他のコンピュータまたは電子デバイスをリンクする１つ又は複数の構成済みコンピュータとなるように、１つ又は複数のそのようなプログラムを実行するために展開されるホストを記述するために一般化することもできる。要求側サーバ１２、応答側サーバ１０、および任意選択でトレーサビリティサーバ５５の機能を実装するコンピュータデバイス１００は、ネットワーク１４、１６、１８全体で特殊なサービスを提供することができる。ネットワークシステム６では、サーバ１２、１０、５５は、専用の機能を有することができ、および／または説明したように機能を共有することができる。エンタープライズサーバは、ビジネスコンテキストで使用されるサーバであり、あらゆる機能のあるコンピュータハードウェア上で実行できる。ハードウェアの意味では、サーバという単語は、典型的には、ネットワーク１４、１６、１８環境の厳しい要求の下でソフトウェアアプリケーションを実行するためのコンピュータモデルを指す。このクライアント／サーバ構成では、１つ又は複数のマシン（コンピュータまたはコンピュータプライアンス）が互いに情報を共有し、一方が他方のホストとして機能する。ほぼ全てのパーソナルコンピュータはネットワークサーバとして機能することができるが、専用サーバはプロダクション環境により適した特徴を含むことになる。これらの特徴は、より高速なＣＰＵ、向上した高性能ＲＡＭ、および典型的には複数の大容量ハードドライブを含み得る。より明白な特質は、電源、ネットワーク接続、さらにはサーバ自体のマークされた冗長性を含む。

図３を参照すると、要求側サーバ１２、応答側サーバ１０、および／またはトレーサビリティサーバ５５のトレーサビリティサービス５３の機能を実装するコンピューティングデバイス１００は、接続１１８を介してデバイスインフラストラクチャ１０４に結合されているネットワークインターフェースカードまたはモデムなどのネットワーク接続インターフェース１０１を含むことができる。接続インターフェース１０１は、デバイスの動作中にネットワーク１４、１６、１８（例えば、イントラネットおよび／またはインターネットなどのエクストラネット）に接続可能であり、これにより、デバイスが互いに適切に通信することが可能になる。ネットワーク１４、１６、１８は、通信７、３０、３２、４０および関連コンテンツの通信をサポートすることができる。

再び図３を参照すると、デバイス１００は、接続１２２によってデバイスインフラストラクチャ１０４に結合された、ユーザ（例えば、サーバアドミニストレータ（図示せず））と対話するためのユーザインターフェース１０２も有することができる。ユーザインターフェース１０２は、これらに限定されないが、ＱＷＥＲＴＹキーボード、キーパッド、スタイラス、マウス、マイク、およびＬＣＤ画面ディスプレイおよび／またはスピーカーなどのユーザ出力デバイスなどの１つまたは複数のユーザ入力デバイスを含むことができる。画面がタッチセンシティブである場合、ディスプレイは、デバイスインフラストラクチャ１０４によって制御されるユーザ入力デバイスとしても使用され得る。

再び図３を参照すると、デバイス１００の動作は、デバイスインフラストラクチャ１０４によって促進される。デバイスインフラストラクチャ１０４は、１つまたは複数のコンピュータプロセッサ１０８を含み、関連するメモリ１２２（例えば、メモリ２４）を含むことができる。コンピュータプロセッサ１０８は、ネットワークインターフェース１０１、ユーザインターフェース１０２およびタスク関連の命令を実行することによるデバイス１００の他のアプリケーションプログラム／ハードウェアの動作を通じて、意図されたタスク（例えば、トレーサビリティサービス５３のそれぞれのモジュール５０、５２）用に構成されたデバイス１００のパフォーマンスを促進する。これらのタスク関連の命令は、オペレーティングシステム、及び／又はメモリ１２２にあるソフトウェアアプリケーション、及び／又は特定のタスクを実行するように設計されたプロセッサ１０８の電子／デジタル回路に構成された操作性によって提供されることができる。さらに、デバイスインフラストラクチャ１０４は、プロセッサ１０８に結合されたコンピュータ可読記憶媒体を含み、プロセッサ１０８に命令を提供し、および／または命令１０７をロード／更新することができる（たとえば、モジュール５０、５２および／またはペアリングデータ３８および／または優先順位付け基準３９に対する追加／削除／修正）。コンピュータ可読媒体は、単なる例として、磁気ディスク、磁気テープ、ＣＤ／ＤＶＤ ＲＯＭなどの光学的に読み取り可能な媒体、およびメモリカードなどのハードウェアおよび／またはソフトウェアを含むことができる。いずれの場合にも、コンピュータ可読媒体は、メモリモジュールに提供される小さなディスク、フロッピー（登録商標）ディスケット、カセット、ハードディスクドライブ、ソリッドステートメモリカード、またはＲＡＭの形をとることができる。上記の例示的なコンピュータ可読媒体は、単独でまたは組み合わせて使用できることに留意されたい。

さらに、コンピューティングデバイス１００は、例えば、オペレーティングシステムおよびモジュール５０、５２の機能／動作を含む所定の機能／動作を実装するためのコードまたは機械可読命令を含む実行可能なアプリケーションを含み得ることが認識される。本明細書で使用されるプロセッサ１０８は、モジュール５０、５２のいずれかまたは全てによって実行される動作を含む、上記の例によって説明される動作を実行するための構成済みデバイスおよび／または機械可読命令のセットである。本明細書で使用されるように、プロセッサ１０８は、ハードウェア、ファームウェア、および／またはソフトウェアのいずれか１つまたはそれらの組み合わせを含むことができる。プロセッサ１０８は、実行可能な手順または情報デバイスによる使用のために情報を操作、分析、修正、変換または送信することにより、および／または出力デバイスに対して情報をルーティングすることにより、情報に作用する。プロセッサ１０８は、例えば、コントローラまたはマイクロプロセッサの機能を使用または備えることができる。したがって、モジュールの機能のいずれも、ハードウェア、ソフトウェア、または両方の組み合わせで実装することができる。したがって、デバイスとしての、および／または機械可読命令のセットとしてのプロセッサ１０８の使用は、以後、簡略化のためにプロセッサ／モジュールと総称される。さらに、トレーサビリティサービス５３は、必要に応じて、モジュールを実装するための１つまたは複数のコンピューティングデバイス１００（ハードウェアおよび／またはソフトウェアを含む）を含むことができることが認識される。

図３ａを参照すると、要求側サーバ１２および／または調整サーバ１２ａの機能を実装するコンピューティングデバイス１００は、デバイスインフラストラクチャ１０４’に対する接続１１８’を介して結合されたネットワークインターフェースカードまたはモデムなどのネットワーク接続インターフェース１０１’を含むことができる。接続インターフェース１０１’は、デバイスの動作中に、ネットワーク１４、１６、１８（例えば、イントラネットおよび／またはインターネットなどのエクストラネット）に接続可能であり、これにより、デバイスが互いに適切に通信することが可能になる。ネットワーク１４、１６、１８は、通信７、３０、３２、４０および関連コンテンツの通信をサポートすることができる。

再び図３ａを参照すると、デバイス１００はまた、ユーザ（例えば、図示されていないサーバ管理者）と対話するために、接続によってデバイスインフラストラクチャ１０４’に結合されたユーザインターフェース１０２’を有することができる。ユーザインターフェース１０２’は、限定されないが、ＱＷＥＲＴＹキーボード、キーパッド、スタイラス、マウス、マイク、およびＬＣＤ画面ディスプレイおよび／またはスピーカーなどのユーザ出力デバイスなどの１つまたは複数のユーザ入力デバイスを含むことができる。画面がタッチセンシティブの場合、デバイスインフラストラクチャ１０４’によって制御されるように、ディスプレイをユーザ入力デバイスとして使用することもできる。

再び図３ａを参照すると、デバイス１００の動作は、デバイスインフラストラクチャ１０４’によって促進される。デバイスインフラストラクチャ１０４’は、１つまたは複数のコンピュータプロセッサ１０８’を含み、関連するメモリ１２２’（例えば、メモリ２４）を含むことができる。コンピュータプロセッサ１０８’は、ネットワークインターフェース１０１’、ユーザインターフェース１０２’、およびタスク関連の命令を実行することによるデバイス１００の他のアプリケーションプログラム／ハードウェアの動作を通じて、意図されたタスク（例えば、それぞれのモジュール）のために構成されたデバイス１００のパフォーマンスを促進する。これらのタスク関連の命令は、オペレーティングシステム、および／またはメモリ１２２’にあるソフトウェアアプリケーション、および／または特定のタスクを実行するように設計されたプロセッサ１０８’の電子/デジタル回路に構成された操作性によって提供され得る。さらに、デバイスインフラストラクチャ１０４’は、プロセッサ１０８’に結合されたコンピュータ可読記憶媒体を含み、プロセッサ１０８’に命令を提供し、および／または命令１０７をロード／更新することができる（たとえば、モジュールおよび／またはペアリングデータ３８ａおよび／または優先順位付け基準３９ａに対する追加／削除／修正）。コンピュータ可読媒体は、単なる例として、磁気ディスク、磁気テープ、ＣＤ／ＤＶＤ ＲＯＭなどの光学的に読み取り可能な媒体、およびメモリカードなどのハードウェアおよび/またはソフトウェアを含むことができる。いずれの場合にも、コンピュータ可読媒体は、メモリモジュールに提供される小さなディスク、フロッピー（登録商標）ディスケット、カセット、ハードディスクドライブ、ソリッドステートメモリカード、またはＲＡＭの形をとることができる。上記の例示的なコンピュータ可読媒体は、単独でまたは組み合わせて使用できることに留意されたい。

さらに、コンピューティングデバイス１００は、例えば、オペレーティングシステムおよびモジュールのものを含む所定の機能／動作を実装するためのコードまたは機械可読命令を含む実行可能なアプリケーションを含み得ることが認識される。本明細書で使用されるプロセッサ１０８’は、モジュールのいずれかまたは全てによって実行される動作を含む、上記の例によって説明される動作を実行するための構成済みデバイスおよび／または機械可読命令のセットである。本明細書で使用する場合、プロセッサ１０８’は、ハードウェア、ファームウェア、および／またはソフトウェアのいずれか１つまたはそれらの組み合わせを含むことができる。プロセッサ１０８’は、実行可能な手順または情報デバイスによる使用のために情報を操作、分析、修正、変換または送信することにより、および／または出力デバイスに関して情報をルーティングすることにより、情報に作用する。プロセッサ１０８’は、例えば、コントローラまたはマイクロプロセッサの機能を使用または備えることができる。したがって、モジュールの機能のいずれも、ハードウェア、ソフトウェア、または両方の組み合わせで実装することができる。したがって、デバイスとしての、および／または機械可読命令のセットとしてのプロセッサ１０８’の使用は、以後、簡単にするために一般的にプロセッサ／モジュールと呼ばれる。

上記を考慮して、コンピューティングデバイス１００は、単一のコンピュータシステムとして示されるが、必要に応じて、コンピュータプロセッサのネットワークとして実装され得ることが理解されよう。

Claims (19)

1. トラフィック処理リソースにおける負担を軽減するためにネットワークを介してネットワーク要求トラフィックのトレーサビリティを決定する方法であって、前記方法は、サーバによって、
   前記サーバと事前に定められたソースに関連付けられた事前に定められた要求側サーバとの間の前記ネットワーク上に直接的な相互接続をプロビジョニングするステップであって、前記直接的な相互接続は、前記事前に定められた要求側サーバと前記事前に定められたソースからアドレス指定された前記ネットワーク要求トラフィックを受信するサーバとの間の第１のインターフェースを提供し、直接的な相互接続を有する前記事前に定められたソースの定められたペアリングデータは、ネットワークトラフィックのアルマナックとしてストレージに格納され、前記定められたペアリングデータは、ソース接続関係を含む、ステップと、
   前記サーバと前記事前に定められたソースおよび他のソースの少なくとも１つに関連付けられた１つまたは複数の他のサーバとの間のネットワーク通信を容易にするために前記ネットワークを用いる第２のインターフェースを利用するステップであって、前記第２のインターフェースは、前記１つまたは複数のサーバを用いて前記事前に定められたソースおよび前記他のソースからアドレス指定された前記ネットワーク要求トラフィックを受信し、前記第２のインターフェースは、前記第１のインターフェースとは別個である、ステップと、
   前記第１のインターフェースを介して、前記事前に定められたソースからアドレス指定された第１の要求トラフィックを受信するステップであって、前記第１の要求トラフィックは、前記第１の要求トラフィックの第１のパケットヘッダにおいて前記事前に定められたソースに関連付けられたアドレスを有する、ステップと、
   第１のクエリ応答を生成することにより前記第１の要求トラフィックを処理し、前記ネットワークを介して前記事前に定められた要求側サーバに通信するために前記第１のインターフェースおよび前記第２のインターフェースの少なくとも１つを介して前記第１のクエリ応答を送信するステップと、
   前記第２のインターフェースを介して、前記事前に定められたソースに関連付けられた前記アドレスを有する第２の要求トラフィックを受信するステップであって、前記アドレスは、前記第２の要求トラフィックの第２のパケットヘッダに含まれる、ステップと、
   前記第２の要求トラフィックが前記事前に定められたソースの前記アドレスと一致するかどうかを決定するために、前記定められたペアリングデータをアドレスと照合するステップと、
   前記照合に基づいて、第２の応答トラフィックを生成する前に前記第２の要求トラフィックに優先順位基準の優先コマンドを動的に適用することにより、前記第１のインターフェースではなく前記第２のインターフェースで受信される前記第２の要求トラフィックに基づいて前記第２の要求トラフィックの処理の優先順位を下げるステップであって、前記優先コマンドを前記適用することはパケットの様々な層を開くことおよび誤った内容のために前記様々な層の内容を分析することによらずに実行される、ステップと、
   を含み、
   前記第２の応答トラフィックの内容は、前記優先コマンドを前記適用することに基づく、方法。
2. プライベートサービスインターフェースとして動作する前記直接的な相互接続は、前記サーバと前記事前に定められた要求側サーバとの間の直接層２または層３の相互接続としての物理的な相互接続である、請求項１に記載の方法。
3. プライベートサービスインターフェースとして動作する前記直接的な相互接続は、前記事前に定められた要求側サーバのプライベートネットワーク上の論理的なネットワーク接続であり、前記プライベートネットワークは前記ネットワークに結合される、請求項１に記載の方法。
4. プライベートサービスインターフェースとして動作する前記直接的な相互接続は、前記ネットワーク上の論理的なネットワーク接続である、請求項１に記載の方法。
5. ＤＮＳプロトコルは、前記第１の要求トラフィック、前記第２の要求トラフィック、前記第２の応答トラフィックを構成するために利用される、請求項１に記載の方法。
6. 応答側サーバは、権限のあるＤＮＳサーバであり、前記事前に定められた要求側サーバと他の前記要求側サーバは、前記ネットワークに結合されたリゾルバＤＮＳサーバである、請求項２に記載の方法。
7. 前記優先順位を下げる処理の一部として、前記事前に定められたソースに関連付けられたネットワークデバイスに優先順位付け通知を送信するステップをさらに含み、前記優先順位付け通知は、前記第２の要求トラフィックと同じ識別されたパケットヘッダ情報を有するそのようなネットワーク要求について、前記サーバからの前記ネットワークデバイスによる前記ネットワーク要求トラフィックの優先順位を下げることを指示する、請求項１に記載の方法。
8. 前記優先順位を下げる処理の一部として、前記サーバに関連付けられたネットワークデバイスに優先順位付け通知を送信するステップをさらに含み、前記優先順位付け通知は、前記第２の要求トラフィックと同じ識別されたパケットヘッダ情報を有するそのようなネットワーク要求トラフィックについて、前記サーバからの前記ネットワークデバイスによる前記ネットワーク要求トラフィックの優先順位を下げることを指示する、請求項１に記載の方法。
9. 少なくとも１つのＤＮＳ固有のパラメータが前記定められたペアリングデータに含まれるように、前記優先順位を下げる処理の一部として少なくとも１つのＤＮＳ固有のパラメータを使用するステップをさらに含む、請求項１に記載の方法。
10. 前記優先順位を下げる処理は、前記第２の要求トラフィックをドロップし、それにより前記第２の応答トラフィックをヌル応答にすることを含む、請求項７に記載の方法。
11. 前記優先順位を下げる処理は、前記第２の要求トラフィックをドロップし、それにより前記第２の応答トラフィックをヌル応答にすることを含む、請求項８に記載の方法。
12. 前記優先順位を下げる処理は、前記第２の要求トラフィックをドロップし、それにより前記第２の応答トラフィックをヌル応答にすることを含む、請求項９に記載の方法。
13. 第２の事前に定められたソースに関連付けられた第２の事前に定められた要求側サーバと、前記第２の事前に定められたソースからアドレス指定された前記ネットワーク要求トラフィックを受信する前記サーバとの間の前記第１のインターフェースを提供するために前記直接的な相互接続をプロビジョニングするステップをさらに含み、前記直接的な相互接続を有する前記第２の事前に定められたソースの定められたペアリングデータは、前記ネットワークトラフィックのアルマナックの一部として前記ストレージに格納され、前記事前に定められたソースと前記第２の事前に定められたソースとの両方からの前記ネットワーク要求トラフィックは、前記第１のインターフェースを用いて通信される、請求項１に記載の方法。
14. 前記直接的な相互接続は、前記事前に定められたソースと前記第２の事前に定められたソースのタイムゾーンの差に基づくピークのタイミングの差異を利用することにより、前記事前に定められたソースと前記第２の事前に定められたソースとの両方からアドレス指定される前記ネットワーク要求トラフィックに関連付けられた帯域幅の容量管理を容易にする、請求項１３に記載の方法。
15. 第２の事前に定められたソースに関連付けられた第２の事前に定められた要求側サーバと、前記第２の事前に定められたソースからアドレス指定された前記ネットワーク要求トラフィックを受信する前記サーバとの間に第３のインターフェースを提供するために第２の直接的な相互接続をプロビジョニングするステップをさらに含み、前記第２の直接的な相互接続を有する前記事前に定められたソースの定められたペアリングデータは、前記ネットワークトラフィックのアルマナックの一部としてストレージに格納され、前記第２の事前に定められたソースからの前記ネットワーク要求トラフィック及び前記事前に定められたソースとは、前記第１のインターフェース及び前記第３のインターフェースのいずれかの使用に基づいて前記サーバによって分離される、請求項１に記載の方法。
16. ネットワークトラフィックを動的に監視し、前記監視の分析結果に基づいて優先順位付け基準を調整するステップをさらに含む、請求項１に記載の方法。
17. トラフィック処理リソースの負担を軽減するためにネットワークを介してネットワーク要求トラフィックのトレーサビリティを決定するサーバであって、前記サーバは、
    前記サーバと事前に定められたソースに関連付けられた事前に定められた要求側サーバとの間の前記ネットワーク上に直接的な相互接続をプロビジョニングし、前記直接的な相互接続は、前記事前に定められた要求側サーバと前記事前に定められたソースからアドレス指定された前記ネットワーク要求トラフィックを受信する前記サーバとの間の第１のインターフェースを提供し、直接的な相互接続を有する前記事前に定められたソースの定められたペアリングデータは、ネットワークトラフィックのアルマナックとしてストレージに格納され、前記定められたペアリングデータは、ソース接続関係を含み、
    前記サーバと前記事前に定められたソースおよび他のソースの少なくとも１つに関連付けられた１つまたは複数の他のサーバとの間のネットワーク通信を容易にするために前記ネットワークを用いる第２のインターフェースを利用し、前記第２のインターフェースは、前記１つまたは複数のサーバを用いて前記事前に定められたソースおよび前記他のソースからアドレス指定された前記ネットワーク要求トラフィックを受信し、前記第２のインターフェースは、前記第１のインターフェースとは別個であり、
    前記第１のインターフェースを介して、前記事前に定められたソースからアドレス指定された第１の要求トラフィックを受信し、前記第１の要求トラフィックは、前記第１の要求トラフィックの第１のパケットヘッダにおいて前記事前に定められたソースに関連付けられたアドレスを有し、
    第１のクエリ応答を生成することにより前記第１の要求トラフィックを処理し、前記ネットワークを介して前記事前に定められた要求側サーバに通信するために前記第１のインターフェースおよび前記第２のインターフェースの少なくとも１つを介して前記第１のクエリ応答を送信し、
    前記第２のインターフェースを介して、前記事前に定められたソースに関連付けられた前記アドレスを有する第２の要求トラフィックを受信し、前記アドレスは、前記第２の要求トラフィックの第２のパケットヘッダに含まれ、
    前記第２の要求トラフィックが前記事前に定められたソースの前記アドレスと一致するかどうかを決定するために、前記定められたペアリングデータをアドレスと照合し、
    前記照合に基づいて、第２の応答トラフィックを生成する前に前記第２の要求トラフィックに優先順位基準の優先コマンドを動的に適用することにより、前記第１のインターフェースではなく前記第２のインターフェースで受信される前記第２の要求トラフィックに基づいて前記第２の要求トラフィックの処理の優先順位を下げ、前記優先コマンドを前記適用することはパケットの様々な層を開くことおよび誤った内容のために前記様々な層の内容を分析することによらずに実行され、前記第２の応答トラフィックの内容は、前記優先コマンドを前記適用することに基づく、
    ようにコンピュータプロセッサを構成するために、ストレージに格納された命令のセットを有するコンピュータプロセッサを備える、サーバ。
18. 前記第２のインターフェースは、パブリックサービスインターフェースとして動作する、請求項１７に記載のサーバ。
19. 前記第２のインターフェースは、パブリックサービスインターフェースとして動作する、請求項１に記載の方法。

Images