帯域幅の基礎から実務まで徹底解説：測定方法・BDPとQoS・体感の関係
エバープレイ編集部ネットワークの帯域幅とは何か
「帯域幅（bandwidth）」は、ネットワークにおいてある時間当たりに送受信できるデータ量の上限を表す概念で、通常はビット毎秒（bps, kbps, Mbps, Gbps など）で表記されます。物理的な回線（例えば光ファイバーやイーサネット）の能力値、ISP が提供する回線スペック、ルーターやスイッチのインターフェース仕様などが帯域幅に相当します。
重要な点は「帯域幅＝速度（体感の速さ）」ではないことです。帯域幅は「最大理論容量」であり、実際に利用者が得られるデータ転送量（スループット）や利用体験（ユーザー体感）は、遅延（レイテンシ）、パケットロス、プロトコルの実装、同時利用者数、トラフィック制御など多くの要因で左右されます。
帯域幅と関連する用語の整理
- スループット（throughput）: 実際に観測される転送率。帯域幅の下限ではない。
- グッドプット（goodput）: ユーザーに有効なデータの転送速度（プロトコルオーバーヘッドや再送を除いた値）。
- レイテンシ（latency）: 送信から受信までの遅延。往復時間（RTT）が重要。
- 帯域幅−遅延積（Bandwidth–Delay Product, BDP）: ネットワーク上に同時に存在できるビット数の目安。TCPウィンドウ設計に影響する。
- オーバーサブスクリプション: 実際に提供する帯域幅を利用者の理論合計より小さくする設計。データセンターやISPで一般的。
帯域幅とTCP（およびBPD）の関係
TCP の場合、スループットは帯域幅だけでなく、RTT（往復遅延）とウィンドウサイズに強く依存します。BDP は次の式で求めます。
BDP = 帯域幅（bps） × RTT（秒）
例: 100 Mbps の回線で RTT が 50 ms (0.05 s) の場合、BDP = 100,000,000 × 0.05 = 5,000,000 bits ≒ 625,000 bytes（約610 KiB）。つまり TCP がリンクを飽和させるためには、この程度の送受信ウィンドウが必要になります。ウィンドウが小さいとリンク能力をフルに使えず、逆に受信バッファが足りないと頻繁に窓閉塞やスループット低下が起きます。
帯域幅の計測と監視方法
帯域幅や実効スループットを把握するには、アクティブ測定とパッシブ監視の両方が有用です。
- アクティブ測定: iperf/iperf3、netperf、speedtest（Ookla）などでエンドツーエンドの最大スループットを測定します。指定した時間にフローを流すため、実際の混雑状態とは別に理論上の性能を掴めます。
- パッシブ監視: SNMP、NetFlow、sFlow、IPFIX、フロー収集器などでトラフィック量やフロー特性を継続的に観測します。実運用でのピーク、平均、トラフィックパターンやホットスポット特定に有効です。
- エンドユーザーの体感測定: レイテンシ、ジッタ、パケットロスを測ることで帯域幅だけでは見えない品質問題を発見できます。
帯域幅がユーザー体感に与える主な影響要因
- 遅延（RTT）: リアルタイム系（音声・映像会議、ゲーム）で特に重要。遅延が大きいと、応答が遅く感じられる。
- パケットロス: 再送が発生するとスループットが低下するとともに、VoIP の品質悪化やビデオのバッファリングが起きる。
- ジッタ: パケット到着間隔のばらつき。音声・映像で悪影響。
- MTU とフラグメンテーション: MTU が小さかったり経路で断片化が発生すると効率が落ちる。
- 暗号化とCPU負荷: TLS/VPN の暗号処理は CPU を消費し、実効スループットを制限することがある。
- アプリケーション特性: 小さなメッセージを大量に送るアプリは帯域幅より遅延に弱い。大容量転送は純粋な帯域幅が重要。
帯域幅の制御：QoS、シェーピング、ポリシング
帯域幅は単に「多ければ良い」だけでなく、重要トラフィックを保証するための制御が必要になることが多いです。
- QoS（DiffServ）: トラフィックに優先度を付け、キューイングや優先送出で重要な通信の遅延や損失を低減します。RFC 2474 / RFC 2475 による差別化サービスアーキテクチャが代表。
- シェーピング（Shaping）: 出力レートを滑らかにしてピークを抑える。バーストを許容しつつ平均を制御する。
- ポリシング（Policing）: ある上限を超えるトラフィックを即時破棄またはマークダウンする。帯域違反の即時対処向け。
- スケジューリング: FIFO、WFQ、DRR、CoDel 等のキュー管理で遅延と公平性を制御。バッファブロートル（bufferbloat）対策として CoDel などが広まっている。
設計上の考え方と実践的な計算例
帯域幅を設計・調達する際は、ピーク需要、同時接続数、利用用途（ストリーミング、Web、ファイル転送、バックアップ）、将来の成長、冗長性を考慮します。以下は簡単な計算例です。
例: 社員 100 人が同時に 2 Mbps のビデオ会議を行う想定
- 必要理論帯域幅 = 100 × 2 Mbps = 200 Mbps
- 運用上は余裕（20〜50%）を持たせ、QoS を設定して重要トラフィックを優先するのが現実的。
例: 大容量バックアップ（1 TB）を 10 時間で送りたい場合
- 1 TB = 約8,000 Gb。10 時間 = 36,000 秒。
- 必要平均帯域 = 8,000 Gb / 36,000 s ≒ 222 Mbps（+プロトコルオーバーヘッドや再送を考慮）
測定上の落とし穴とよくある誤解
- ISP が広告する「最大速度」は理想環境下のピーク値であり、常時保障されるものではない。
- ピーク帯域と平均帯域を混同しない。常時のキャパシティ計画はピークではなく「同時最大」や「99パーセンタイル」のデータで行うべき。
- 単一ツールだけで判断しない。iperf は強力だが、実運用の混雑や多様なフロー状況を再現できない場合がある。
- 帯域幅が足りない原因は必ずしも回線だけではない。スイッチ/ルーターの性能、NIC ドライバ、CPU ボトルネック、フロー制御、QoS 設定の誤りなどを点検する必要がある。
最新技術とトレンド
- TCP BBRなどの新しい輻輳制御アルゴリズムは、従来の損失検出ベースのアルゴリズム（Reno/Cubic）とは異なる方法で帯域を有効利用し、低遅延化を目指しています（Google の研究）。
- クラウドや CDN の普及により、エンドツーエンドの帯域幅要件は分散配置やエッジでの最適化で緩和できるケースが多くなっています。
- 高精度のパッシブ監視（フロー解析）と機械学習を組み合わせたトラフィック予測・自動スケーリングが実運用で浸透しつつあります。
運用担当者への実務的アドバイス
- まずは継続的な監視を導入し、ピーク時間帯・主要アプリケーションのトラフィック分布を把握する。
- BDP を理解し、TCP ウィンドウ設定やバッファサイズを適切に調整する（特に長距離・高帯域のリンク）。
- ユーザー体感を改善したい場合、単に帯域を増やすだけでなく QoS、遅延対策（CoDel 等）、パケット損失削減に取り組む。
- 定期的にアクティブテスト（iperf 等）とパッシブ分析（NetFlow/SNMP）を組み合わせて現状ギャップを特定する。
- 冗長化・フェイルオーバ設計では帯域の合算だけでなく、切替時の挙動（セッション維持、再送の影響）も検証する。
まとめ
帯域幅はネットワーク性能の重要な指標ですが、それ単体でネットワーク品質を決定するものではありません。遅延、パケットロス、トラフィックの性質、プロトコル挙動、機器の性能など多くの要素が絡み合います。実務では継続的な監視、適切な QoS 設計、BDP を踏まえたチューニング、そして必要に応じた容量拡張が重要です。技術の進展（BBR、CoDel、CDN 等）を取り入れつつ、観測に基づく設計と運用を心がけてください。
参考文献
- Cisco: What is bandwidth?（日本語解説）
- Wikipedia: Bandwidth (computing)
- Wikipedia: Bandwidth–delay product
- iperf (iperf3) — ネットワーク性能測定ツール
- Google Research: BBR: Congestion-Based Congestion Control
- RFC 2474: Definition of the Differentiated Services Field (DS Field)
- RFC 2475: An Architecture for Differentiated Services
- Bufferbloat Project — バッファブロートルと CoDel 等の情報
- sFlow.org — フロー監視のリソース
- Ookla Speedtest — 一般的な回線速度測定サービス
投稿者プロフィール
