インタネットの構造と輻輳問題 - 理工学部

解説
インタネットの構造と輻輳問題
中 村 奉 夫
Tomoo NAKAMURA
理工学部電子情報学科
教授
Professor, Department of Electronics and Informatics
1.はじめに
2.インタネットの構造
いまや,インタネットは電話や郵便と同じ,ある
インタネットとは,ネットワークのネットワーク
いはしのぐほどの大規模のインフラとなり,インタ
を意味する.ネットワークはルータと呼ばれる特別
ネットなしの生活は考えられなくなってきている.
なコンピュータによって互いに接続される.
ここでは,これまでインタネットを円滑に働かせる
ために開発されてきた技術を解説する.
ルータの役割は,バケツリレーの例で説明され
る.バケツリレーでは水が運ばれるのに対して,イ
インタネットは,1960 年代に軍事開発として米
国国防総省によるネットワーク通信技術の研究から
ンタネットではパケットと呼ばれるデータの塊が運
ばれる.
始まった.ARPA(高等研究企画局)の計画とし
パケットには送るべきデータに加えて,送る宛先
て,四つの大学によるコンピュータ・ネットワーク
情報が入っている.郵便での手紙のようなものであ
が開発され,それが発展し,現在のインタネットと
る.ルータはその宛先情報をもとに,次に送り出す
なった.
べきネットワークを決めて,そのネットワークのル
そこでは,各々のコンピュータが,データを,最
ータへパケットを送りだす.
善を尽くして(ベストエフォート),ただし,保証
ルータは,パケットをリレーのように順々に手渡
はしない形で,ボランティア的に転送していく形態
すように送って最終的なアドレスまで届ける.ルー
をとった.
タはパケット交換機とも呼ばれる.電話の回線交換
以下,インタネットの構造,インタネット通信に
おける役割分担,ネットワークの性能と輻輳問題,
ネットワークの性能解析,ネットワークの輻輳と対
機のようにパケットを交換していくからである.
3.インタネット通信における役割分担
策,トランスポート層プロトコル TCP の輻輳制御
について説明していく.
インタネット通信では,基本的に,コンピュータ
内のプロセス(タスクとも呼ばれる.実行中のプロ
グラムをいう.)と別のコンピュータ内のプロセス
とが通信を行う,プロセス間通信と呼ばれる形態を
― 12 ―
る.
とる.
なかでも,サーバと呼ばれるサービスを提供する
TCP(Transmission Control Protocol)は,通信す
プロセスと,クライアントと呼ばれるサービスを受
るプロセスに代わって,上で述べた信頼性をもたら
けるプロセスの二種類のプロセス間通信の通信形態
すために非常に複雑な仕事を行う,この層の代表的
が主流を占めている.これはクライアントサーバ型
なプロトコルである.
一方,UDP(User Datagram Protocol)は信頼性を
通信と呼ばれる.
例えば,会社などのウェブページ(ふつう,ホー
要求されない通信(信頼性が必要なら自プロセスで
ムページと呼ばれる)情報を提供するサーバとウェ
信頼性を持つための処理を行う)で使用され,高速
ブブラウザ(マイクロソフト社のインタネット・エ
性の必要な,あるいは,同時に多方向に送信する場
クスプローラやファイアフォックスなど)を使って
合に当てはまる.
これらの処理は,プロセス間通信においては裏方
ページを見るクライアントからなる通信である.
これらのインタネット通信における役割分担は,
で表には出てこない.コンピュータでは,マイクロ
アプリケーション層,トランスポート層,インタネ
ソフト・ウィンドウズ(Windows)やリナックス
ット層の三つの階層に分けられる.以下,各々の層
(Linux)という,OS(オペレーティング・システ
ム)の機能として実装されている.
とその通信規約(プロトコル)を説明する.
3. 1
アプリケーション層プロトコル
3. 3
インタネット層プロトコル
アプリケーション層には,クライアントとサーバ
たとえ,トランスポート層が信頼性を持って通信
が通信を行うとき,二つのプロセスの通信に共通す
しても,宛先そのものが曖昧であるとか,正しくな
る取り決めを標準化したプロトコルがある.ホーム
い,どうやって配送していけば,宛先まで届くか分
ページを見るときのデータ転送のための,ハイパー
からないのでは困る.
テキスト転送プロトコル(HTTP)やメールの配送
まさに,この仕事を行うために,世界の各地で分
時の,シンプル・メール転送プロトコル(SMTP)
担して仕事をするのがこの層の役割である.このた
などが,標準としてある.
めのプロトコルが,インタネットプロトコル(IP)
である.現在,第 4 バージョン(IPv 4)と第 6 バ
3. 2
ージョン(IPv 6)がある.
トランスポート層プロトコル
インタネットの通信の基本は,前章で述べたよう
その役割には,まず,アドレス付けがある.同じ
に,ベストエフォートである.途中のルータなど
アドレスが複数個あったり,アドレスが不明では困
は,配送処理をネグレクトなどせず,最善は尽くす
るため,世界中で必ずわかるアドレス付けが必要と
が,データの配送が途中でうまく行かなくてもその
なる.このインタネットアドレス(IP アドレス)
責任はとらない.
というのは会員番号,電話番号のようなものであ
そのため,通信において,送信元と送信先(受信
る.ただ,個々に番号を付けるのではなく,分散し
側)は互いに協調して,信頼ある,データのやり取
て,ある団体などに塊で渡して,その団体の管理者
り(誤り制御)や,フロー(フロー制御)を考え
が割り振る形をとる.例えば,龍谷大学という団体
て,データの受信側でのあふれ,抜け落ちの無いよ
がアドレスの塊を割り当ててもらって,その中は,
うにしなくてはならない.
龍大の管理のもとで自由に割り振る.
これらの仕事のために送信側と受信側が行う取り
ただし,たとえ,アドレスが世界に 1 つしかない
決め(プロトコル)とその処理機能がこの層にあ
ものであっても,そこへ行く方法がわからないので
― 13 ―
は困ってしまう.電話に例えれば,電話番号があっ
ラフィック)の関係で,発生したり発生しなかった
ても,交換機をどのようにしてたどって接続してい
りすることがある.
けば宛先まで行くのがわからなければだめというこ
ネットワーク全体の性能というのは,理論的に
とである.
インタネット層の役割は,ルータの集まりで,世
は,全てのリンクの通信が最適な時に最適であると
界中に分散して,宛先まで配送するための努力をす
言えるのだが,インタネットのように,大きなネッ
るということである.世界中の全てのアドレスに対
トワークでは,その最適を求めるのは不可能に近
して,道筋を確定することは不可能なことである.
い.その上,インタネットのように分散化され流動
郵便で,日本からペルーのクスコへ手紙を送ると
すると,ペルーの中央郵便局,あるいは,そこまで
直結していなければ米国のどこかの郵便局,へ送っ
的な集合体では不可能であると言ってよい.
5.ネットワークの性能解析
ネットワークのデータ転送性能を解析する必要性
て,そこから先は任せることになる.
郵便と違うところは,ハイアラーキーになってい
は,ネットワークが大きければ大きいほど重要であ
ないことである.国内でいえば,郵便番号で,都道
る.ネットワークを設計して,ルータやケーブル,
府県が判ってそこへ行けば,その先で,他の都道府
スイッチなどを配置してみて動かしてみたところう
県に行くことは絶対ないのだが,インタネットの場
まく稼働しない,どこかに通信路の狭いところがあ
合はそうとは限らない.宛先の存在しないアドレス
って,ボトルネックが生じているのでは困るわけで
をめざすパケットが,いつまでもふらふらとさまよ
ある.
ネットワークを設計すると,そのネットワークを
うこともありうるわけである.
実際に稼働させる前に,大体の動きを見積もる必要
4.ネットワークの性能と輻輳
や,稼働してからも動的なトラフィックの変化に対
ネットワークの回線(リンク)には太いものもあ
れば細いものもある.太いということは,大量のデ
してネットワークの構成を変更する必要も出てく
る.
ータを送れるということである.1 秒間に送れるデ
ネットワーク解析手法は,数学的な理論解析とコ
ータ量を,メガビット/秒(Mbps)とか,ギガビッ
ンピュータ・シミュレーションに分類される.この
ト/秒(Gbps)という単位であらわすことが多い.
二つについて説明する.
1 Mbps は 1 秒間に 1 メガ(百万)ビット送れると
いうことである.1 ギガは 1000 メガである.
5. 1
ただ,ネットワークでのパケット通信の場合は,
みんながネットワークを共有して一時的に利用す
[15]
待ち行列理論[11]
待ち行列理論は,確率,確率過程の応用として扱
われる数学的な理論である.
る.その回線をすべてずっと使えるわけでもない.
パケットを処理して送り出すルータなどをサービ
ネットワークでは,データの流れ(トラフィクと
ス・システムと呼び,サービス・システムにランダ
いう)の混雑つまり渋滞が発生することがある.こ
ムに到着してサービス(処理)を受ける者を客と呼
の渋滞のことを,通信の世界では輻輳と呼んでい
ぶ.パケットが客に当たる.
る.高速道路を考えるとわかるように,インタチェ
客はサービスを受けるとそのシステムを退去し
ンジなどの合流点,太い道から狭い道にかわるとこ
て,場合によっては次のサービス・システムへ行
ろ,工事などで狭くなるところなどで渋滞は発生す
く.前の客がサービスを受けていると,待ち行列に
る.また,渋滞は道(リンク)の太さと車の量(ト
入って前の客のサービスが終わるのを待つ.待ち行
― 14 ―
列システムとはこれらのサービスと待ち行列を含め
たシステムを言う.
客の到着時間間隔の大きさ(平均),散らばり度
合い(ランダムさ:分散)サービス時間の大きさ
(平均)ばらつき(分散),サービスの規律(来たも
の順,優先度を付ける,など)によって,そのサー
ビス・システムの状態が計算できる.
その待ち行列システムの性能を表す評価指数とし
て,システムでの客の滞在時間や待ち時間の平均,
図1
ネットワークの例[13]より引用
待ち行列内の客数やシステム内の客数の平均などが
多くの場合使われる.
到着時間間隔やサービスの時間の分布を表す理論
分布に,ポアソン分布,指数分布などがある.
サービス規律にも,到着順(FIFO : First In First
Out)
,優先度によるものなどいくつかある.
また,待ち行列システムがネットワーク(網)状
に構成されたものを待ち行列網という.
5. 2
コンピュータ・シミュレーション
待ち行列理論の良いところは大まかな計算によ
図2
シミュレーション解析[13]より引用
り,少量のコスト(時間,計算のパワー)で行える
ことである.しかし,詳細なシステムの解析には向
NS-2 では,図 1 のようなネットワーク・トポロ
いていない.詳細なシステム解析に有効な手法が,
ジーで,ノード間の伝送速度や伝送遅延時間,待ち
コンピュータ・シミュレーションである.ただ,計
行列および TCP/UDP の処理を仮定したネットワー
算に時間がかかり,コストがかかるという難点があ
ク・シミュレーショが行える.そして,その結果を
る.
解析して,図 2 のような輻輳ウィンドウサイズの時
シミュレーション・プログラム(シミュレータ)
間的な変化(後述)を出すことが可能となる.
には有料のもの,フリーソフトなど,いろいろあ
現在,NS-2 の後続版 NS-3 も登場している[17].
る.
ネットワーク特定のシミュレータでは,ネットワ
ークのトポロジー(ノードのつながりの形状),
ネットワークの輻輳と対策
6
個々のノードとリンクの性能,サービス(処理)規
輻輳とは,多量のパケット(データ)が発生・転
律などを,通信のネットワークに合わせて,詳細に
送されたことによる,いわば,「交通」渋滞である
規定し実行できるものがある.
といった.
例えば,ネットワーク・シミュレータ(Network
それに対して,よく似ているが異なるものが,通
Simulator)NS-2 は,アメリカの DARPA の研究プ
信のエンドとエンドで行う流量(フロー)制御であ
ロジェクト VINT の研究成果の一つとして,開発
る.
[10]
[16]
されたフリーソフトである
これを,身近な例えで言うと,電話で,相手がメ
.
― 15 ―
モをとるような場合に必要となる,「ちょっと待っ
[9]
考案されている[8]
.
て,早すぎて書けない, , , ,,,,,, は い ,
OK,つぎ,どうぞ」と,送信側(話す人)と受信
側(メモを取る人)のスピードの調整のような制御
である.
6. 3 トランスポート層
トランスポート層は,インタネット層の途中のル
ータのことはわからないため,エンド・ツー・エン
どちらの場合も送信側が送信の速度を変えなけれ
ばならない.
ドの送受信の制御しかできないため,基本的に送信
側のコンピュータが自粛して送信量を減らすことに
よって.ネットワークの「渋滞」を避けなければな
6. 1
輻輳制御
らなくなる.次章では,トランスポート層の特に
輻輳制御とは,輻輳が発生した時の対策・処理と
輻輳発生の防止対策のための制御である.
インタネットのような大きなネットワークでは輻
輳がどこで発生したかを見つけるのは難しい.
TCP の輻輳制御について詳しく見ていく.
7.トランスポート層プロトコル TCP
の輻輳制御
もともとインタネットでは,ルータが受信したパ
インタネットでのパケット通信は,個別ごとに固
ケットすべてを処理・転送し,輻輳が起こっても,
定分の帯域の割り当てがあるわけではなく,TCP
パケットを廃棄しなかったと思われる.1986 年,
などの送受信処理の考え方は,通信路に空きがある
輻輳によるインタネットの停止(輻輳崩壊)が発生
ようであれば,通信路をできるだけ利用して効率を
[6]
上げることを目的とする.
した .
TCP の通信では,効率と信頼性を持つ通信を達
インタネットにおける輻輳制御には次のような制
限や問題がある[6],すなわち,
成するため,
a.ウンドウ・フロー制御による到着確認前のパ
a.全体的な管理機構の不在
ケットの信
b.プロトコル/アーキテクチャの問題
b.送信エラー時や未到着と考えられるとき(タ
c.トラフィック特性の問題
イムアウト時)のパケットの再送
インタネットの規模性,多様性
などを行う.詳細は,[6],[9]などを参照され
インタネットの成長,変化の予測
たい.
である.
そのため,インタネットでは,分散的に,ルータ
などで輻輳制御をせざるをえない.
7. 1
[9]
TCP の Tahoe と Reno や New Reno[6]
TCP/IP プロトコル体系が現在のように広がった
6. 2
のは,UNIX OS の BSD(Berkeley Software Distribu-
インタネット層における輻輳制御
ルータでは,多量のパケットが到着して,処理
(次のルータへの転送)に非常に時間がかかる時
tion)に組み込まれたためである.4.2 BSD で TCP/
IP が組み込まれた.
や,また,ルータのバッファ(有限量)に入りきれ
1986 年の輻輳崩壊を経て,1988 年,UNIX 4.3 BSD
ない時,到着パケットを廃棄してしまう.捨て方に
に,輻輳制御アルゴリズムが組み込まれた.これ
は,単純に,最後に到着したパケットを捨てる,
は,TCP Tahoe と呼ばれる.その特徴は,次のよう
Drop-Tail 呼ばれる手法,と RED
(Random Early Dis-
になる.
card)と呼ばれる,バッファがいっぱいになる前か
輻輳ウィンドウが導入された.送信側はネットワ
ら,少しずつ(つまり,確率的に)捨てる手法が,
ークの輻輳状態に応じて,送信量の上限を動的に調
― 16 ―
節する.次の四つのものがある.
a.スロースタート:スタートはゼロからはじめ
て,受信側の確認を得るごとに,送る量の上
限を倍々的に大きくしていく.
b.輻輳回避:途中で混雑の兆候がみられると,
それからは,倍々に大きくしていくのではな
く,緩やかに大きくしていく.
c.タイムアウト:輻輳によりタイムアウトが発
図4
TCP Reno の輻輳ウィンドウサイズの時
間変化[13]より引用
生すると,状態を元に戻して,スロースター
トを始める.
このように,輻輳ウィンドウにより,スロースタ
は,[6]に詳しい説明がある,ここでは割愛する.
ート状態と輻輳回避状態を交互に繰り返しながら,
その後,1996 年には,Reno の改良版として,Reno
送信を続ける.このため,輻輳ウィンドウはジグザ
の高速回復を修正した New Reno が提案されたが,
グの形で変化する.
Reno に比べて積極的に送信をすることにより転送
d.高速再送(Fast Retransmission)ア ル ゴ リ ズ
効率が上がることは見込まれたが,実際のネットワ
ム:パケットの欠落を素早く検出し,再送を
ークの輻輳時の影響が分からず,標準として採用に
促す.
はならなかった.
TCP Tahoe の欠点は,パケットの欠落の発生に対
して,スロースタート状態に入ることによる転送性
7. 2
能の低下が生じることにある.
[9]
TCP Vegas[6]
1994 年には,RTT(Round Trip Time:往復伝搬
このため,1990 年には,Tahoe の改良版として Reno
時間)を,高精度で正確に計測し,その値をもと
が開発された.
に,輻輳ウィンドウサイズを制御し,通信路の容量
高速回復(Fast Recovery)アルゴリズムが追加し
て組み込まれた.これは,1 個のパケット欠落時に
に見合った通信量の制御を試みる TCP Vegas が提
案された.
は,輻輳ウィンドウの値をゼロに戻すのではなく,
これ輻輳制御も,実際のネットワークでの輻輳時
途中の値(もとの 2 分の 1)から再スタートするこ
とにより,性能低下を防ごうとしたものである.い
まもこれが標準である.このアルゴリズムについて
図3
TCP Tahoe の輻輳ウィンドウサイズの時
間的変化[13]より引用
― 17 ―
図5
TCP Vegas の輻輳ウィンドウサイズの時
間的変化[13]より引用
の影響がはっきりとしないため,標準とはなってい
する.これらについては,現在も研究を継続してい
ない.このアルゴリズムについては,[13]に詳し
る.
く述べた.
最後に,この解説では,筆者が 2008 年度龍谷大
7. 3
学国内研究員として,筑波大学および龍谷大学で研
その他の高速 TCP の開発
その他,High Speed TCP,Scalable TCP,Fast TCP
究を行った成果の一部を報告した.この機会を与え
や TCP Westwood などの高速転送を目指す TCP の
てもらった,龍谷大学および電子情報学科の皆さん
改良が研究されている[9].
に感謝する次第である.
最近では,北九州市立大学の藤井らによる KTCP
参考文献
などがある[14].
[ 1 ]カマー著,村井・楠本訳:TCP/IP によるネットワー
ク構築,Vol.1. 原理・プロトコル・アーキテクチ
8.おわりに
ャ,第 4 版,共立出版,2002
インタネットの仕組みとその中で,輻輳という問
[ 2 ]タネンバウム著,水野他訳:コンピュータネットワ
ーク,日経 BP 社,2003
題を取り上げて,簡単に解説した.
輻輳制御方式の改良問題として,我々は,この
TCP Vegas の改良を試みた.TCP Vegas のどちらか
[ 3 ]小口:コンピュータネットワーク入門,サイエンス
社,2007
[ 4 ]村山:基礎からわかる TCP/IP ネットワーク・コン
といえば,「謙譲精神」的な送信方式をもう少し積
極的な送信方式にして,TCP Reno と TCP Vegas の
ピューティング入門,第 2 版,オーム社,2007
[ 5 ]竹下,村山,芝井,苅田:マスタリング TCP/IP,入
門編,第 4 版,オーム社,2007
送信量の不均衡を減らそうとした.ネットワーク・
シミュレータ NS 2 を用いて,いくつかのネットワ
[ 6 ]尾家・西尾他:岩波講座
巻,第 3 巻
ーク・トポロジーに対してトラフィック・シミュレ
インターネット
全6
トランスポートプロトコル,岩波書
店,2001
ーションを行い,その結果を解析した.その結果
[ 7 ]江崎:ネットワーク工学,数理工学社,2003
を,FIT 2008[13]で公表した.
[ 8 ]田坂:情報ネットワークの基礎,数理工学社,2007
この解析において,次のような問題点がまだ残っ
[ 9 ]阪田編:IT Text インターネットプロトコル
オー
ム社,2005
ていることが分かった.
[10]銭:NS 2 によるネットワークシミュレーション,森
北出版,2006
a.ネットワーク・トポロジーによる変化の解析
[11]吉岡:待ち行列と確率分布,森北出版,2004
[12]井上:輻輳制御アルゴリズムの提案と評価,平成 20
が不十分である.
年度龍谷大学大学院理工学研究科電子情報専攻修士
b.Vegas あるいは,井上の改良 Vegas における
論文,2009
パラメータ値の最適化をする必要がある.
[13]井上,木村,中村:帯域公平性を持つ輻輳制御,第
c.インタネット層での輻輳制御との関連を研究
7 回情報科学技術フォーラム( FIT 2008 ) 第 4 分
する必要がある.
冊,pp 129−130, 2008
[14]藤井他:高速 TCP に対する公平性改善手法 KTCP
の性能評価,電子情報通信学会技術報告,vol.109,
また,UDP では輻輳制御は行わないため,UDP
と TCP のトラフィックが重なっているときには,
no.448, NS 2009−178, pp.95−100, 2010
[15]中村:待ち行列入門,龍谷理工ジャーナル,Vol.9−
UDP トラフィックが TCP トラフィックを減少させ
2, pp 21−28, 1997
てしまう.しかし,UDP トラフィックどうしは,
[16]http : //www.isi.edu/nsnam/ns/
お互いに競合し輻輳が起こり得るという問題も存在
[17]http : //www.nsnam.org/
― 18 ―