ロキ・ジョーゲンソンのネットワーク論
「帯域幅」という用語は正しくない
「帯域幅はどうやって測定すればいいのか?」――その答えは“帯域幅”という言葉で何を意味しているのか、そして何を求めているかによって異なる。
人々はよく、ネットワークに関する文脈において、帯域幅という言葉をあたかも正確な定義が存在するかのように使っている。だが、「帯域幅」は元々、電磁気学における周波数または波長の範囲を表す用語であり、ネットワークとは本質的な関係はなかった。長年にわたる誤用と意味上の変化の結果、今では帯域幅という言葉は、ネットワークパス(経路)に沿ってデータを送信する速度を指すことが多くなった。
「帯域幅は重要である」という点については、ほとんどの人は異論がないだろう。この場合の帯域幅は通常、ネットワークの一部の生のキャパシティーを意味する。しかし、帯域幅だけに注目して問題が解決することはまれだ。その理由の1つとして、パフォーマンスは鎖の最も弱い部分によって決定され、その部分が壊れることが一般的な問題の原因であるということが挙げられる。このため、別の部分に強い鎖の輪を追加する(例えば帯域幅を増やす)ことによって、エンド・ツー・エンドのパフォーマンスが改善されることはめったにない。
それでも次のように尋ねる人は多い――「帯域幅はどうやって測定すればいいのか?」、あるいは「(トラフィックを差し引いた)利用可能な帯域幅はどう測定するのか?」、「自社のネットワークのパイプの太さはどのくらいか?」と。こういった質問に対する短い答えは、「あなたが“帯域幅”という言葉で何を意味しているのか、そして何を求めているかによって異なる」ということだ。そして答えは……かなり長い説明になる。
仮に、帯域幅が重要であり、それが何を意味するのか、そして自社ネットワークの帯域幅を測定する方法を知りたいとしよう。まず、関連する用語を定義した上で、この目標にどれだけ近づけるか見ることにしよう。
現在、一般的に用いられている用語を断片的にリストアップしてみた。
- 帯域幅
- 容量
- ストリーミング速度
- ビットレート
- スループット
- グッドプット
- 転送速度
これらの用語の修飾語のリストには、「リンク」「エンド・ツー・エンド」「最大達成可能」「ピーク」「バルク転送」「定常」などが含まれるだろう。例えば、人々は「最大達成可能なエンド・ツー・エンド帯域幅」と「バルク転送容量」をどれほど厳密に区別しているだろうか。
ここで、CAIDA(Cooperative Association for Internet Data Analysis)が提供している有用な定義を幾つか紹介しよう。これは、2003年のBandwidth Estimation Workshop(帯域幅推定ワークショップ)の資料として準備されたものである。
- 容量:特定のリンクメディア上で物理的に可能な最大スループット
- エンド・ツー・エンド容量:エンド・ツー・エンドパス上の最小容量。「ナローリンク」の容量に対応
- 利用可能な帯域幅:クロストラフィックが存在する状態でのエンド・ツー・エンドパス上で未使用の最大スループット。「タイトリンク」の容量に対応
- バルク転送容量:エンド・ツー・エンドネットワークが単一の混雑認識型トランスポート層コネクションに提供できる最大スループット
- 達成可能スループット:転送メカニズム(TCPなど)に応じてアプリケーションが達成可能な最大スループット
上記の定義の大半で「スループット」という用語が用いられているため、スループット、そしてこれとやや関連した「グッドプット」という用語も定義しておこう。
- スループット:送信元ホストが送信する単位時間当たりのビット数
- グッドプット:送信先ホストが受信する単位時間当たりのビット数から重複分を差し引いたもの(例えば、グッドプットはスループットの利用可能部分、すなわち送信データからデータの損失・重複・再送信ビットを差し引いた分を表す)
これらの定義に関しては延々とした議論があり得るだろうが、その性質に関してはさまざまな観測が可能だ。特に以下については、その意味をさらに明確化することが重要である。
- エンド・ツー・エンド(リンク・バイ・リンクとの比較において)
- クロストラフィックの影響(空いているネットワークパスとの比較において)
- アプリケーション層やトランスポート層の影響(下位層との関係において)
- 異なるレイヤーでの各プロトコルのオーバーヘッド
- トラフィック渋滞や機能不全によるデータ損失の影響(「クリーン」な送信に対して)
- ピーク/最大データ転送速度(持続/平均データ転送速度に対して)
- 実効データ転送速度(潜在転送速度との関係において)
さらに厳密な区別を行うことができる。
- エンド・ツー・エンドネットワークの最初と最後はどこか(例えば、NICやエンドホストのドライバを含むのか)
- アプリケーション、OSの影響には、ヘッダのコスト(処理オーバーヘッドあるいはデータ転送オーバーヘッド)という意味においてパケットのサイズも含まれるのか
- 各種の影響(損失やクロストラフィックなど)の過渡的性質は平均化されるのか、何らかの変化として持続するのか、それとも最大値または最小値以外は無視されるのか
- 二重通信の影響――測定の際の、両方向における対称性、ならびに片方向通信と双方向通信容量の意味
- QoSや帯域制御装置といった意図的なメカニズムの影響
以上で各用語およびその重要性の条件はほぼ定義された。次に、どれがあなたのネットワークの条件に当てはまるのか考える必要がある。焦点を絞り込むことにより、「帯域幅」(あるいは、ほかの呼び方でもいいが)の独自の定義に迫ることができそうだ。これは、帯域幅を測定するための指標と方法を選択するための準備にもなるかもしれない。では、あなたにとって重要な価値を決定するためのさまざまな方法を検討してみよう。
1. 理論的推定値
言い換えれば、ネットワーク図に記載された内容を信じ、任意の個所における(あるいは2カ所間の)容量を論理的に予測するということである。
2. ポイント測定
MRTGなどのツールを使ってルータあるいはスイッチのインタフェースでのパケット数を計測することにより、これらのデバイスを通過するビットの転送速度を決定する。
3. エンド・ツー・エンド測定
さまざまな方法を用いて、特定のエンド・ツー・エンドパスの容量を測定する。
- バルクファイル転送:標準的なTCPアプリケーション(最適化されたFTPクライアントなど)を使い、一定量のデータを1台のホストから別のホストに転送する
- フラッディング:iPerfなどのソフトウェア(またはハードウェア)ツールを使用して、2台のホスト間で定常ストリームを作成する。
- アクティブプロービング:PathRateなどのソフトウェアツールを使用して、送信したプローブパケットの挙動からエンド・ツー・エンドネットワークのパフォーマンスを推定する。
- パッシブインファレンス(推定):Wrenなどのソフトウェアツールを使用して、受動的に監視したパケット挙動からエンド・ツー・エンド帯域幅を推定する。
ご想像の通り、「帯域幅」にどのような定義を当てはめるかによって、それぞれの方法には長所と短所がある。例えば、特定のデバイスのインタフェースにおけるレイヤー2の最大送信/受信フレームレートを重視しているのであれば、送信/受信速度を経時的に測定する(ネットワークをフラッディングしながら行う方法もある)だけでも、特定個所の容量を把握することができる。特定のアプリケーションが特定のエンド・ツー・エンドパスで維持することができる平均持続速度を重視しているのであれば、平均測定値、クロストラフィック、NIC、損失などが重要な要因となる。あるいは、ISPが提供するWANリンクや、料金に見合ったものを得ているのかどうかに関心がある人もいるかもしれない。
CAIDAの定義の中で際立って有用なものが2つある。「エンド・ツー・エンド容量」と「利用可能な帯域幅」である。後者におけるクロストラフィック(計測トラフィックに対して影響を与えるトラフィック)の影響を除けば、どちらも以下に示すような「典型的な」制約の共通セットに分類できるかもしれない。
- エンド・ツー・エンド
- レイヤ1~3の影響(アプリケーション層やトランスポート層による影響がない場合など)
- クリーンなネットワークパスに適用される(損失やネットワーク機能不全によるパフォーマンス低下を含めない)
- プロトコル、フレーム/パケットサイズなどの制約要因を含めない
- 片方向
- 瞬間(ピーク)値
iPerfやNetPerfのようなソフトウェアが、あなたにとって最も有用性が高いと言えそうだ。これらは各エンドにクライアントを必要とするが、パケットレベルのパフォーマンスを明確に示してくれる。
だが結局のところ、帯域幅というのはやはり、見る人によって異なるものである。そして帯域幅を正しく測定するためには、何を見ているのかを知る必要があるのだ。
注記:さらに正確な帯域幅の定義を知りたい人は、「Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, ANSI/IEEE Std. 100」を参照していただきたい。そこに示された17項目の定義の中には、パケットネットワーク上での最大データ転送速度に直接関連したものは1つもない。帯域幅という用語はやはり正しくないのである(助言を与えてくれたロジャー・フリーマン氏に感謝する)。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー