ロキ・ジョーゲンソンのネットワーク論
「帯域幅」という用語は正しくない
「帯域幅はどうやって測定すればいいのか?」――その答えは“帯域幅”という言葉で何を意味しているのか、そして何を求めているかによって異なる。
人々はよく、ネットワークに関する文脈において、帯域幅という言葉をあたかも正確な定義が存在するかのように使っている。だが、「帯域幅」は元々、電磁気学における周波数または波長の範囲を表す用語であり、ネットワークとは本質的な関係はなかった。長年にわたる誤用と意味上の変化の結果、今では帯域幅という言葉は、ネットワークパス(経路)に沿ってデータを送信する速度を指すことが多くなった。
「帯域幅は重要である」という点については、ほとんどの人は異論がないだろう。この場合の帯域幅は通常、ネットワークの一部の生のキャパシティーを意味する。しかし、帯域幅だけに注目して問題が解決することはまれだ。その理由の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
-
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は? 先行企業の導入事例3選 -
技術文書・技術解説
[日本オラクル株式会社] 無自覚なリスク 秘伝Excelファイルが監査の壁、不正・ミスの温床となる理由 -
製品資料
[日本オラクル株式会社] 戦略的経理の第一歩 失敗のない「脱Excel」を実現する秘訣とは? -
技術文書・技術解説
[日本オラクル株式会社] いまさら聞けないオンプレERPとクラウドERPの違い 最適な製品をどう見極める? -
事例
[株式会社ビザスク] 連結売上高が約2倍に成長、富士フイルムが実践した新規事業創出の戦略とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
-
4
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
5
エンジニアの生産性はどう測る? マネジメントに不可欠な可視化の実現方法とは
-
6
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
7
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
8
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
9
「また同じ説明か」 消費者の半数が離脱するAIチャットbotの“記憶喪失”
-
10
IT製品の導入に関するアンケート「PC&デバイス」編
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー