攻撃トラフィックが急増したとき、Webサイトに生じる障害は一様ではありません。まずネットワーク接続が帯域を使い切る場合があります。帯域には余裕があっても、接続テーブルが枯渇することもあります。また、ハンドシェイクを完了してHTTPSで到達したリクエストが、ログインAPIやデータベースのリソースを消費し続ける場合もあります。

こうした問題に対処するには、DDoS対策機能を備えたCDNが分散ネットワークでトラフィックを受け止め、複数の段階で攻撃を識別・フィルタリングし、通過を許可したアプリケーションリクエストをオリジンサーバーへ転送する必要があります。 Tbps級はトラフィック量、ミリ秒単位は特定の対応処理にかかる時間を表します。どちらも重要ですが、一方の数値だけで他方の性能を判断することはできません。

CDN07は、分散型のTbps級DDoS対策、インテリジェントルーティング、リアルタイム分析、多層フィルタリングをWebサイトの高速化とセキュリティに活用しています。その仕組みを、リクエストが防御ネットワークに入ってからオリジンに届くまでの流れに沿って見ていきます。

「ミリ秒単位」と「Tbps級」は何を測っているのか

分散型サービス拒否（DDoS）攻撃は、多数の送信元からトラフィックやリクエストを発生させ、標的のネットワークや計算リソースを枯渇させることで、正規ユーザーによるサービス利用を妨げます。

トラフィックスクラビングとは、防御ネットワークに入るトラフィックを識別し、破棄、レート制限、チャレンジ、許可などの処理を行うことです。全量を収集してからまとめて処理するのではなく、通信経路上で継続的に実施します。

10進表記では、1 Tbpsは1,000 Gbpsに相当します。ただし、ネットワーク全体のTbps級の総容量、特定地域で利用できるTbps級のスクラビングリソース、個々の顧客に保証されるTbps級の防御能力は、それぞれ異なる意味を持ちます。

応答時間にも複数の段階があります。攻撃の開始、異常の観測、ルールの生成、エッジ拠点での適用、アプリケーションの安定稼働への復帰は、同時に起こるわけではありません。

既存ルールに一致する後続のトラフィックは、直ちに処理できます。一方、新しい攻撃パターンには、サンプルの蓄積と特徴の評価を経て対処を決める時間が必要になる場合があります。

そのため、適用の速さと分類の正確さを両立させなければなりません。急いで正規ユーザーまで遮断してしまえば、Webサイトが復旧したとはいえません。

Tbps級のトラフィックに分散ネットワークが必要な理由

すべての攻撃パケットがスクラビングサーバーに届く前に容量不足の単一の上位回線を通過しなければならない場合、どれほど高速なフィルタリングでも、その回線の輻輳ですでに失われた正規リクエストは取り戻せません。

重要なのは処理を行う位置です。アプリケーションのボトルネックよりできるだけ手前でフィルタリングし、ネットワークの入口、転送経路、処理拠点に十分な容量を確保します。

分散ルーティングでトラフィックの集中を抑える

Anycastは、分散した入口を設ける代表的な手法です。複数の拠点が同じサービスアドレスを経路広告し、ルーティングによってトラフィックが対応する拠点へ送られます。 Anycastの運用を扱うRFC 4786 でも、ノードの自律性、経路の変化、トラフィックの分散が論じられています。

Anycastはトラフィックを分散できますが、各拠点への均等な配分や、地理的に最も近い拠点の選択を保証するものではありません。送信元ネットワーク、通信事業者の経路制御ポリシー、相互接続の容量によって、実際の到達先は変わります。

DNSベースのルーティングでも入口を分散できます。ただし、DNSレコードを変更しても既存の接続が即座に移動するわけではありません。キャッシュやクライアントの挙動も切り替えのタイミングに影響します。大規模な防御ネットワークでは、構成に応じて複数のルーティング手法を組み合わせることもあります。

したがって、Tbps級のアーキテクチャには、ネットワーク全体の総容量と各拠点の余裕の両方が必要です。全体に帯域の余力があっても、攻撃が集中した入口に十分な容量があるとは限りません。

同じ1 Tbpsでも処理負荷は大きく異なる

大きなパケットは帯域を消費します。一方、小さなパケットは1秒当たりのパケット数を急増させ、NICのキュー、CPU、転送装置を先に限界へ追い込むことがあります。

次の簡略化したPython 3の例は、平均パケットサイズがパケットレートに与える影響を示すものです。CDN07の実測値ではありません。

attack_bps = 1_000_000_000_000  # 假设攻击速率为1Tbpsfor packet_bytes in (1500, 100):    packets_per_second = attack_bps / (packet_bytes * 8)    print(f"平均每包{packet_bytes}字节：约{packets_per_second / 1_000_000:.2f} Mpps")

概算結果は次のとおりです。

平均每包1500字节：约83.33 Mpps
平均每包100字节：约1250.00 Mpps

この計算では、同じレイヤーで測定した平均パケットサイズを使い、追加のリンクオーバーヘッドは含めていません。同じ帯域幅でも、パケット数には大きな差が生じることが分かります。

実際の上限は、帯域幅、パケット処理速度、接続状態の保持容量、アプリケーションの処理能力のうち、どのリソースが最初にボトルネックになるかで決まります。

エッジ拠点で多層のトラフィックスクラビングを行う理由

すべてのパケットに負荷の高いアプリケーション分析を適用すると、計算資源を浪費します。一方、IPアドレスの単純な遮断だけでは、多数のアドレスに分散し、正規の通信に似せた攻撃に対応しにくくなります。

効率的なのは、判別しやすい異常を早い段階で除去し、追加の分析が必要な接続やリクエストに処理負荷の高い検査を絞ることです。

これらは論理的な処理段階です。実際のシステムでは、複数の処理を1台のエッジサーバーで行う場合も、コンポーネント間に分散する場合もあります。

明らかな悪意あるパケットは早期に破棄する

この段階の判断は、通常、パケットの属性や既知のトラフィック特性に基づきます。アプリケーションで使わないプロトコルの通信、不正な形式のパケット、確認済みの攻撃シグネチャなどは早期に除去できます。

XDPはLinuxネットワークで処理を早期に実行するための仕組みです。Cloudflareが公開した DDoS緩和に関する分析 では、XDPとeBPFでパケットをフィルタリングし、検知システムにサンプルを渡し、攻撃を特定した後にルールを配布する実装が紹介されています。

この業界事例が示すのは、早期フィルタリングの利点です。一部の破棄判断は、負荷の高いプロトコル処理に入る前に行えます。ただし、これはCloudflareの実装であり、ほかのネットワークでは異なる構成要素で同様の機能を実現する場合があります。

この段階では、HTTPS内の完全なURLパスや本文は見えません。ネットワーク層のフィルタリングは基本的なスクラビングの多くを担えますが、復号後のHTTPの挙動分析を代替することはできません。

接続状態のリソースが尽きる前に接続を検証する

TCP接続の確立にはハンドシェイクが必要です。未完了のハンドシェイクが大量に発生すると、バックログや関連する状態保持領域が消費され、正規ユーザーが新しい接続を開けなくなります。

SYNフラッドと一般的な緩和策を分析したRFC 4987 では、SYNキャッシュ、SYN Cookie、プロキシと、それぞれのトレードオフが扱われています。SYN Cookieは初回応答に必要な情報を埋め込み、検証可能な確認応答を受けてから対応する接続状態を作ることで、ハーフオープン状態によるリソース消費を抑えます。

接続検証を通過したことは、送信元が該当する通信手順を完了できることしか示しません。人間の利用者である証明にはなりません。ボットもハンドシェイクを完了でき、攻撃が確立済み接続やHTTPリクエストへ移ることもあります。

そのため、接続保護の後にもアプリケーション層での評価が必要です。

HTTP層でアプリケーション負荷を見極める

エッジでHTTPS通信を終端・復号した後は、URL、リクエストメソッド、ヘッダー、関連するセッション情報をアプリケーション保護に利用できます。

たとえば、キャッシュ可能な画像への反復リクエストと、データベース処理を伴う検索APIへの反復リクエストは、RPSが同じでもオリジンにかける負荷は大きく異なります。エンドポイントごとの処理コスト、キャッシュの挙動、アプリケーションの利用フローを踏まえて判断する必要があります。

AWSの DDoSに強いアーキテクチャに関するガイダンス でも、グローバルネットワークの処理容量とWebアプリケーション保護は分けて説明されています。前者は大規模トラフィックの吸収に、後者はWAF、アプリケーションの処理能力、異常検知に関係します。

実際には、ログイン、検索、ダウンロード、決済コールバックには異なるポリシーが必要です。ブラウザー向けチャレンジは一部のパスには適していても、モバイルAPIには適さない場合があります。IPアドレスだけを基準にしたレート制限は、共有された出口IPを使う正規ユーザーにも影響し得ます。

CDN07による WAF、ボット管理、DDoS対策の連携に関する解説 では、これらの制御をどう組み合わせるかを扱っています。ネットワークのスクラビング、ボット検知、アプリケーションルールにはそれぞれ役割があり、単独であらゆる問題を解決できるものではありません。

ミリ秒単位の対応を支える仕組み：分析とパケットごとのルール適用を分離する

重要な設計原則の一つは、何をすべきかの判断と、その判断を実際のトラフィックに適用する処理を分けることです。

トラフィックを受け取り、パケットを照合・破棄・転送する部分がデータプレーンです。サンプルを分析し、ポリシーを調整してルールを配布する部分がコントロールプレーンです。

データプレーンには、短く予測可能な処理経路が必要です。配布済みのルールはエッジでローカルに実行し、パケットごとに遠隔の分析システムの応答を待たない構成が求められます。

コントロールプレーンでは、短い時間幅でのパケットレートの変化、ハンドシェイクの完了状況、リクエストの集中度、通常のアプリケーション動作からの逸脱など、より多くのシグナルを評価できます。パターンを確認したら、実行可能なルールをデータプレーンへ送ります。

この分離によって、二つの時間軸が生まれます。既存ルールは継続的かつ迅速に適用できます。一方、新しい攻撃を認識するには観測と判断が必要です。前者にかかる時間は、後者を含む全体の対応時間ではありません。

AI分析は複数の異常を組み合わせた検知に役立つ

単一のしきい値には難しいトレードオフがあります。低すぎれば販促キャンペーンやゲームのサービス開始時に正規ユーザーを遮断しかねず、高すぎれば先にオリジンが過負荷になります。

複数のシグナルを組み合わせた分析なら、個々の指標では通常に見えても、全体として異常なトラフィックを見つけられます。ただし、分析結果は具体的な処理につなげる必要があります。負荷の高いリクエスト群のレート制限、特定パスの同時実行数の調整、リスク特性に応じたチャレンジなどです。

自動制御には解除条件も必要です。一時的なルールに有効期限やロールバック条件を設け、アプリケーションの回復後は制限を段階的に緩めます。攻撃が終わった後もユーザーへの影響が続く事態を避けるためです。

ミリ秒単位のルール適用、継続的な学習、元に戻せるポリシー変更がそろって初めて、防御の速さと安定性を両立できます。「AIスコア」だけでは、この一連の仕組みの代わりにはなりません。

スクラビング後もキャッシュとオリジンへのリクエストを制御する理由

ここまでの処理で攻撃トラフィックは減りますが、オリジンの容量にはなお負荷がかかる場合があります。正規ユーザーの急増、フィルタリングを通過した異常なトラフィック、大量のキャッシュミスが、バックエンドのリソースを使い続けるためです。

キャッシュ可能なコンテンツはエッジから配信し、オリジンへの反復アクセスを減らす

キャッシュに適した画像、スクリプト、公開ページはエッジキャッシュから返せます。これにより配信経路が短くなり、オリジンへの繰り返しの取得リクエストも減らせます。

ただし、キャッシュにはアプリケーションのアクセス権限を反映しなければなりません。 RFC 9111のHTTPキャッシュ規則 では、修飾子のない private というレスポンスディレクティブが、共有キャッシュによるレスポンスの保存を禁止します。ログイン後の個人情報や注文情報などには、アクセス権を考慮したキャッシュポリシーが必要です。負荷を下げるために、すべてを公開キャッシュの対象にしてはいけません。

キャッシュミスの原因も調べましょう。任意のクエリーパラメータによって、大量の異なるキャッシュオブジェクトが作られることがあります。一方、パラメータが商品、言語、ユーザーの権限を実際に決めているなら、無視すると誤ったコンテンツを返すおそれがあります。キャッシュキーはアプリケーション上の意味に合わせて設計します。

オリジンへのリクエスト制限を実際の処理能力に合わせる

スクラビング後のトラフィックがオリジンに届く前に、接続の再利用、同時実行数の制御、適切な場合のリクエスト集約を行えば、短時間の負荷急増を抑えられます。サービスがこれらに対応しているか、どのように有効化するかを確認してください。

オリジンでは、リクエスト数だけでは負荷を判断できません。各リクエストはCPU、データベース接続、外部サービスの処理時間も使います。処理コストの高いAPIには、静的ファイルから流用したしきい値ではなく、それぞれの容量上限に合った制御が必要です。

トラフィックは防御ネットワークの入口を通過させる必要があります。公開されたオリジンIPアドレスを攻撃者が直接狙う場合、その迂回経路にはCDNのルールを適用できません。過去のDNSレコード、見落としたサブドメイン、アクセス制限については、 露出したオリジンIPアドレスの保護に関するガイド も参照してください。

複合的な攻撃では各層がどう連携するのか

ゲームイベントのページが、ネットワーク層のパケットフラッド、異常な接続試行の反復、ログインAPIへの大量のHTTPリクエストを同時に受けたとします。これは仕組みを説明するための例であり、実際の攻撃記録ではありません。

まず、分散した入口が防御ネットワークへのトラフィックを受け止めます。パケットフィルターは確認済みの悪意あるパケットを破棄し、接続管理は不正なハンドシェイクによる状態保持リソースの消費を抑えます。HTTPSの通信手順を完了したリクエストは、さらにアプリケーション層で評価します。

イベントページの公開画像やスクリプトはキャッシュから配信し、ログインAPIには別のルールを適用します。攻撃の総帯域が下がっても、ログイン処理の待ち行列が増えているなら、インシデントは収束していません。エンドポイントの負荷と正規ユーザーの成功率を引き続き確認します。

反対に、遮断リクエスト数が増える一方で正規ユーザーのログイン失敗も増えているなら、ルールが広すぎないか確認が必要です。スクラビングしたトラフィック量だけで成果は測れません。

多層防御では、すべての負荷をアプリケーションサーバーに任せず、種類に応じて適切な段階で処理します。

CDN07は分散型の防御を実際のアプリケーションにどう適用するのか

CDN07のDDoS対策CDN は、Webサイトの高速化とDDoS対策を組み合わせ、エッジの対象範囲、帯域幅、セキュリティポリシーを構成できます。アプリケーションにとっての目的は一つです。攻撃中も正規ユーザーが閲覧、ログイン、取引を継続できるようにすることです。

中国本土のユーザーにサービスを提供する国際的なWebサイトでは、ユーザーからエッジまでと、エッジからオリジンまでの両方のネットワーク経路を考慮する必要があります。動的APIでは認証とエンドポイントの処理能力が特に重要です。長時間維持する接続については、継続性と再接続時の挙動も監視します。同じ防御帯域であっても、ワークロードによって適切なポリシーは異なります。

容量計画では、ネットワーク全体の防御リソースと、選択するプランに含まれる具体的な防御範囲を区別しなければなりません。合意した上限を超える攻撃を受けた場合の扱い、長時間の攻撃中に容量を拡張できるか、追加料金をどう算定するかを提案内容で明確にしてください。これらの違いについては、 DDoS対策CDNのプランと追加費用に関するガイド でも解説しています。

技術面の成果は、次の三つの観点から評価します。

P95とP99を見ると、遅延分布の遅い部分が分かります。平均応答時間の単一のスナップショットより、攻撃前・攻撃中・攻撃後の状態を比較するほうが有益です。

ミリ秒単位の動作を測るには、十分な精度を持ち、時刻が同期されたイベント記録が必要です。1分単位の監視グラフで分かるのは傾向であり、個々の応答時間ではありません。防御性能を検証する場合は、関係チームと調整したうえで許可されたテストを実施してください。本番サービスに対して予告のない攻撃トラフィックを送ってはいけません。

よくある質問

ミリ秒単位のDDoSスクラビングとは、攻撃全体が数ミリ秒で終わるという意味ですか？

いいえ。スクラビングは継続的な処理であり、攻撃が続く間は処理を続ける必要がある場合もあります。ミリ秒単位という説明には、検知、ルール適用、対応のどの段階の時間なのかを明示すべきです。それがインシデント全体の復旧時間を意味するわけではありません。

Tbps級の帯域があれば、あらゆるHTTPフラッドを止められますか？

いいえ。アプリケーション層のHTTPフラッドは帯域の消費が少なくても、データベース処理、ログイン、検索を繰り返し実行させることがあります。対処にはアプリケーション層での検知、エンドポイントごとのレート制限、オリジンの処理能力に合わせた制御が必要です。

トラフィックスクラビングでWebサイトは遅くなりますか？

処理のオーバーヘッドが増えることはあり、チャレンジによってユーザーの操作が必要になる場合もあります。適切に設計された構成では、早期フィルタリング、ローカルでのルール適用、キャッシュによって不要な負荷を抑えます。スクラビング拠点の稼働状況だけでなく、正規ユーザーの成功率とレイテンシーで影響を測ってください。

SYN Cookieで人間とボットを見分けられますか？

いいえ。SYN Cookieが主に緩和するのは、ハーフオープン接続による状態保持リソースの枯渇です。ハンドシェイクを完了するボットはアプリケーション層の攻撃を続けられるため、追加の検知が必要です。

DDoS対策CDNを導入した後も、DDoS対策サーバーは必要ですか？

オリジンの公開状況、ネットワーク層のリスク、アプリケーションで使うプロトコルによって異なります。CDNが主に保護するのは、そのプロキシの入口を通るトラフィックです。オリジンへの直接アクセス、別のゲーム用ポート、その他の入口が公開されている場合は、それぞれに適切な対策が必要です。

攻撃帯域が下がったのに、アプリケーションが復旧しないのはなぜですか？

アプリケーション層の攻撃が続いている場合や、データベース、スレッドプール、タスクキューに処理待ちがすでにたまっている場合があります。正規リクエストの成功率とオリジンの回復状況を併せて評価してください。流入する攻撃帯域の低下だけでは、インシデントの収束は判断できません。

DDoS対策CDNの技術的な価値は、一連の処理経路にあります。分散ネットワークがトラフィックを受け止め、迅速なルール適用で無駄な負荷を削減し、アプリケーション保護で重要なエンドポイントを守り、キャッシュとオリジンへの制御でバックエンドの処理能力を維持します。

Webサイト、API、イベント向けの防御を検討している場合は、対象ユーザーの地域、利用プロトコル、通常時のピーク、オリジンの処理能力、入手可能な攻撃記録を整理し、 CDN07の技術相談窓口 にお知らせください。実際のアプリケーション負荷に合わせて防御を設計することで、Tbps級の容量と迅速な対応を、ユーザーが実感できる可用性につなげられます。