TCP/IP 通信の接続性と性能の監視手法に関する研究

(1)

TCP/IP 通信の接続性と性能の監視手法に関する研究

大岸智彦

電気通信大学大学院情報システム学研究科博士（工学）の学位申請論文

2008 年 3 月

(2)

TCP/IP 通信の接続性と性能の監視手法に関する研究

博士論文審査委員会

主査加藤聰彦教授

委員曽和将容教授

委員森田啓義教授

委員吉永努准教授

委員岡田和則客員教授

(3)

著作権所有者大岸智彦

2008

(4)

A Study on Monitoring Method for Connectivity and Performance of TCP/IP Communications

Tomohiko Ogishi

Abstract

Recently, since communication services based on the Internet technology, such as IP telephony, Video on demand (VoD) and electronic commerce, have been widely deployed, the user requirements for the quality of IP networks become higher. IP telephony service is expected to be provided with the same quality level as that of circuit switching technology, and the standardizations that aims at IP network performance objectives, All IP technology and NGN (Next Generation Network) are progressing. In these circumstances, the establishment of the technologies that captures customers’ communication qualities effectively using network and transport layers’ communication protocols is required by carriers and ISPs (Internet Service Providers).

However, a large number of communications is transferred on the provider’s network from various terminals such as mobile terminals and PCs of consumers and servers of contents providers. The individual customers and applications may require different quality levels, and their communication durations and traffic volume may be also different and various. It is not easy to investigate the link that includes the communication traffic for specified users, since the provider’s network is large and several network equipments and the links are interconnected complicatedly. Therefore, it is difficult for network operators to capture the states of individual communications in detail and appropriately.

In order to analyze communications on a large IP network, various tools and realization methods are proposed according to the unit of the communication and the purpose of the monitoring. The monitoring methods for the communication between a pair of users mainly aim at the analysis of network troubles on a single communication

(5)

flow and the inter-connectivity testing between communication systems. For these purposes, the format of each packet is analyzed using some protocol analyzers.

However, there were issues that these analyzers rely on the operator’s burden for the analysis related to the correspondences between several packets that are indispensable to the estimation of internal behaviors of the communication systems, and they cannot produce exceptional behaviors that do not conform to the specification.

And then, the monitoring methods for the traffic on a link mainly use tools that collect flow statistics related to IP layer traffic such as NetFlow collector. The issue is that the statistics do not include the statistics related to the IP quality. Moreover, as the monitoring methods for routing information that focuses on overall network, publicly available routing information provided by RouteViews and RIPE projects are used for research purposes. However, there are issues that the information is not provided in real time and it takes unignorable time to analyze routing information because it is not well-designed for later analysis.

From the above considerations, this paper proposes totally five realization methods according to the purposes and the application areas from three approaches. The first approach is to monitor communication between a pair of users. It includes two realization methods, which are the traffic analyzer that estimates TCP behaviors based on the analysis between the monitored packets and the TCP tester that tests exceptional TCP sequences using test scenarios. The second approach is to monitor the traffic on a link. It includes one realization method, which is the performance monitor that monitors statistics including user quality in real time. The third approach is to monitor the routing information on overall network. It includes two realization methods, which are the analysis method for BGP instability location using a single observation point and the high-performance BGP route search system based on an SQL database.

This paper clarifies the scope and targets of the proposed approaches and their realization methods. Besides, the detailed designs, the implementations and the experiments from practical point of view are also given in order to evaluate the effectiveness of proposed methods. Furthermore, it discusses the scope and role of the proposals considering the technical trends from the time when the research was done and to the current age.

(6)

TCP/IP 通信の接続性と性能の監視手法に関する研究

大岸智彦

概要

近年， IP 電話，ビデオオンデマンド，電子商取引など，インターネット技術を利用した通信サービスの普及により，IPネットワークの高品質化に対する利用者の要求が厳しくなってきている．IP電話については，これまでの回線交換と同等の音声品質水準が期待されており，IPネットワークの品質目標値や，ネットワーク全体のIP統合に基づくALL IP 化技術，電話網と次世代統合IPネットワークの実現を目指したNGN (Next Generation Network)などの標準化が進んでいる．このような中，電気通信サービスを提供する通信キャリアや，インターネット接続サービスを提供するインターネットサービスプロバイダが，

顧客の通信の品質に関する情報をネットワーク層およびトランスポート層での通信手順のレベルで，効率的に把握できる技術の確立が求められている．

これに対し，プロバイダのネットワーク上では，個人の PC・携帯電話端末やコンテンツ事業者が提供するサーバなど多種の端末により，夥しい数の通信が行われている．個々のユーザやアプリケーションが要求する品質のレベルや，通信時間，通信データ量もまちまちである．また，通信キャリアやプロバイダのネットワークは大規模かつ複雑であり，

ルータなどのネットワーク機器や物理回線が相互に接続されているため，どのルータや回線上を，監視対象とするユーザ間の通信が経由するかを調査するのは容易ではない．このため，ネットワークの管理者が，全ての通信の状態を，詳細かつ的確に把握することは困難である．

このような大規模ネットワークにおける通信を解析する手法として，扱う通信の単位・

規模や，監視目的に応じて，これまでにさまざまなツールや実現方法が提案されてきた．

ユーザ間の通信を対象とした監視は，主に，一つの通信フローにおけるネットワーク障害の解析，通信システム間の相互接続を目的とする．この場合，従来，プロトコルアナライザを用いたパケットフォーマットの解析が行われてきたが，通信システムの動作推定に必要なパケット間の対応付けを手作業で分析しないといけないこと，通信動作を監視するだ

(7)

けであるため異常な通信手順を動的に発生させることができないこと，が課題であった．

また，回線上のトラヒックを対象とした監視については，主に，トラヒック量に関して，

フロー単位の統計情報を収集するNetFlow等のツールが使用されてきたが，フローの品質に関わる情報を収集できないことが課題であった．さらに，ネットワーク全体での経路情報の監視については，RouteViews プロジェクト等が公開した経路情報が利用されてきたが，経路情報の公開にリアルタイム性がないこと，経路情報の解析に時間を要することが課題であった．

以上のような背景から，TCP/IP 通信を対象とし，ユーザ間の通信，回線上のトラヒック，ネットワーク全体での経路制御情報の3つのアプローチにおいて，その目的・適用領域に応じて，合計で5つの実現方法を提案する．

1. ユーザ間の通信の監視に対するアプローチ

【1】通信システムが入出力したパケット間の対応付けを推定することにより，TCP の内部状態の推定を行う高機能なトラヒックアナライザ

【2】仕様に従わない手順を行う条件・タイミングを試験シナリオに記述することにより，

TCPの異常手順を効率的に試験するTCPテスタ 2. 回線上のトラヒックに着目したアプローチ

【3】TCP コネクション・統計情報に関わるテーブルを高速に検索可能とすることにより，ユーザの品質を含めたトラヒック統計情報をリアルタイムに収集するパフォーマンスモニタ

3. ネットワーク全体での経路制御情報に着目したアプローチ

【4】1点で観測したBGP経路より経路変動の発生源を分析することにより，リアルタイムな障害箇所特定を可能とするBGP経路解析手法

【5】汎用SQLソフトによるBGP経路情報のデータベース化により，BGP経路の高速検索を可能とする手法

本論文では，上記3つのアプローチと，5つの実現手法について，その位置づけと適用領域を明確化し，それぞれの課題・要求条件に応じて，具体的なシステム設計・実装を行っている．また，機能・性能，ならびに，実用的な観点から，システムの評価を行い，提案手法の有効性を検証している．また，それぞれの研究を実施した当時の通信インフラの状況のみならず，現在に至るまでの技術の変遷を踏まえて，これらの提案の位置づけ・役割を分析している．

(8)

図目次

図 2-1 TCPの通信手順... 10

図 3-1 パケットダンプの出力... 16

図 3-2 通信システムのエミュレーション... 17

図 3-3 例外的な通信手順の実装... 18

図 3-4 TCPレイヤのフロー管理を行うパフォーマンスモニタ... 19

図 3-5 1点観測による経路変動の発生源特定... 20

図 3-6 BGP経路のデータベース化... 21

図 4-1 ネットワーク構成... 25

図 4-2 ソフトウェア構成... 26

図 4-3 イベントシーケンスの推定例... 28

図 4-4 TCPの状態遷移... 30

図 4-5 イベントシーケンスの推定誤り... 32

図 4-6 動作推定のアルゴリズム... 34

図 4-7 実験ネットワーク構成... 35

図 4-8 内部動作推定の結果... 36

図 4-9 イベントシーケンス図... 37

図 4-10 パラメータ値の時間的変化... 38

図 5-1 TCPテスタの構成・環境... 43

図 5-2 シナリオインタープリタの通信フロー... 45

図 5-3 試験シナリオ例... 49

図 5-4 試験シナリオ実行例... 50

図 5-5 通信結果ログの例... 51

図 5-6 TCP実装評価の環境... 52

図 5-7 輻輳制御アルゴリズムの試験シナリオの例... 54

図 5-8 SACK送信端末の実装評価の試験シナリオ... 55

図 5-9 duplicate SACKの実装評価の試験シナリオ... 56

図 5-10 TCPの通信手順を持たないテスタによる試験シナリオの例... 59

図 6-1 ソフトウェア構成... 65

図 6-2 テーブルの構成... 66

図 6-3 実験環境... 74

図 6-4 測定期間毎のトラヒック量... 76

図 6-5 IPアドレスの組毎のトラヒック量... 76

(12)

図 6-6 あるIPアドレスの組のトラヒック量... 77

図 6-7 再送バイト数の降順に並べたIPアドレス組毎のトラヒック量... 77

図 6-8 低品質な組... 78

図 6-9 高品質な組... 78

図 7-1 手法概要... 85

図 7-2 発生箇所候補削減の事例... 87

図 7-3 同時イベントのクラスタ化における課題... 88

図 7-4 トポロジー優先アルゴリズムの振舞い... 91

図 7-5 トポロジー優先アルゴリズムの適用例... 92

図 7-6 複数観測点結果を用いた検証方法... 94

図 7-7 時間優先アルゴリズムでの推定誤りの例... 96

図 8-1 MRTフォーマット... 102

図 8-2 既存手法 – BGP経路サーバ... 102

図 8-3 経路検索システムの構成... 103

図 8-4 BGPテーブルの更新... 105

図 8-5 BGPテーブルの構成... 106

図 8-6 SQL構文による検索例... 107

図 8-7 経路検索システムの応用例... 109

図 8-8 同時アクセス試験の環境... 112

図 8-9 同時アクセス時の検索時間 (単位：秒) ... 113

(13)

表目次

表 4-1 TCPの状態および内部変数... 29

表 5-1 内部変数 (一部抜粋)... 47

表 5-2 試験結果の要約... 57

表 6-1 アプリケーションの識別... 67

表 6-2 TCP状態遷移表... 69

表 6-3 片方向トラヒックを想定した状態遷移表 (一部抜粋)... 72

表 6-4 実験結果... 74

表 7-1 BGPビーコンの検証... 93

表 7-2 複数点観測と一点観測の比較結果... 95

表 7-3 最小AS長の分布... 98

表 7-4 複数経路を持つイベントの候補長の削減効果... 98

表 7-5 発生箇所候補の削減率... 99

表 8-1 RIB/UPDATEファイルの統計情報... 110

表 8-2 BGPデータベースの統計情報... 110

表 8-3 検索時間 (単位：ミリ秒) ... 111

表 8-4 登録・管理性能 (単位：秒)... 114

(14)

第 1 章はじめに

1.1 本研究の背景

近年， IP 電話，ビデオオンデマンド，電子商取引など，インターネット技術を利用した通信サービスの普及により，IPネットワークの高品質化に対する利用者の要求が厳しくなってきている．IP電話については，これまでの回線交換と同等の音声品質水準が期待されており，IP ネットワークの品質目標値[1][2]や，ネットワーク全体の IP 統合に基づく ALL IP化技術[3][4]，電話網と次世代統合IPネットワークの実現を目指したNGN (Next Generation Network)[5][6]などの標準化が進んでいる．このような中，電気通信サービスを提供する通信キャリアや，インターネット接続サービスを提供するインターネットサービスプロバイダが，顧客の通信の品質に関する情報をネットワーク層およびトランスポート層[7]での通信手順のレベルで，効率的に把握できる技術の確立が求められている．ネットワーク／トランスポート層での品質には，コネクション確立の可否を示す接続性と，再送率，スループットなどの性能が存在する．なお，本論文では，通信キャリアとインターネットサービスプロバイダを区別せず，プロバイダと総称する．

これに対し，プロバイダのネットワーク上では，個人の PC・携帯電話端末やコンテンツ事業者が提供するサーバなど多種の端末により，夥しい数の通信が行われている．個々のユーザやアプリケーションが要求する品質のレベルや，通信時間，通信データ量もまちまちである．また，通信キャリアやプロバイダのネットワークは大規模かつ複雑であり，

ルータなどのネットワーク機器や物理回線が相互に接続されているため，どのルータや回線上を，監視対象とするユーザ間の通信が経由するかを調査するのは容易ではない．このため，ネットワークの管理者が，全ての通信の状態を，詳細かつ的確に把握することは困難である．

例えば，プロバイダが顧客から，通信の障害に関する申告を受けた場合を想定する．このとき，プロバイダのネットワーク運用者は，顧客対応の担当者より得た，顧客の通信障害に関する情報をもとに，障害の原因を調査する．通信障害には，相手先との接続性が完全に途絶える場合と，通信できるもののスループットが出ないなど性能が向上しない場合の2通りが考えられる．接続性が途絶える場合の通信障害の原因には，プロバイダ内のルータなどのネットワーク機器の故障，他のプロバイダでのネットワーク機器の故障，回線

(15)

の切断・不良，顧客の通信相手先のサーバの停止，顧客のPCあるいは宅内ブロードバンドルータでの設定誤り，通信プログラムの手順に関する不具合などが考えられる．また，

性能が向上しない場合の通信障害の原因には，プロバイダ内のネットワークの輻輳，顧客の通信相手先のサーバの過負荷，顧客のPCおよびネットワークカードの性能の問題，宅内ブロードバンドルータでの過剰なフィルタの設定，電波の受信環境の問題(無線LANを使用している場合など)，通信プログラムとその使用環境における問題などが考えられる．

このうち，顧客の PC，宅内ブロードバンドルータ，サーバ，通信プログラムに関する問題は，顧客あるいはサーバなど，特定のアドレスにおける通信に特化した問題と考えられる．従って，そのアドレスを含む通信に着目した調査を行うこととなる．しかしながら，

プロバイダは，回線上を流れるパケットをキャプチャするなど，ネットワーク上で得られる情報しか持たないため，原因を調査するには，ネットワーク上で得た情報から顧客やサーバの通信状態を推測する必要がある．このためには，パケット毎の詳細な解析が必要である．

また，プロバイダのネットワーク内のルータ，回線に関する問題は，複数の顧客の通信に同時に関連する問題である．この場合，ボトルネックや障害の切り分けの単位となるのは，ルータ間を接続する回線である．従って，原因を調査するには，顧客の通信が経由する特定の回線の状態を把握することが必要となる．

一方，顧客の通信相手先のサーバが，顧客から見て複数の他のプロバイダを経由した先に存在する場合もありうる．この場合は，障害の原因として，他のプロバイダでの問題も視野に入れる必要がある．他のプロバイダでの障害は，上記の回線の状態を把握する方法では解決できない．そこで，自身のプロバイダが他のプロバイダから受信する経路情報に着目した解析を行う．これにより，自身のプロバイダと他のプロバイダの間の接続性に関する情報が分かるため，ネットワーク上の問題なのか，サーバの問題なのかを切り分けることができる．また，ネットワーク上の問題である場合には，どのプロバイダが原因であるかを切り分けることができる．

以上に述べた内容を整理すると，通信障害を解析するアプローチとしては，以下の3つの方法が考えられる．1 点目は，特定のユーザ・サーバ間の通信に着目し，個々のパケットの情報を詳細に解析する方法である．これについては，これまでパケットのヘッダ情報を詳細に表示するトラヒックアナライザなどが使用されてきた．Snifferなどの市販のプロトコルアナライザが先駆者であるが，近年では，tcpdump，etherealなどのフリーのソフトウェアが主流となってきている．これらのプロトコルアナライザは，一般に，多種のプロトコルに対応し，ヘッダフォーマットを解析する機能を持つ．このため，ネットワーク

(16)

の障害診断や，通信品質の解析などに幅広く利用できる．しかしながら，TCP (Transmission Control Protocol)[8]の輻輳制御アルゴリズム[9]などを解析するには，パケットヘッダには現れないシステム内部の状態を把握する必要があるが，上記の汎用ツールを用いた場合，各パケットを順に追いかけて手動で計算するといった，地道な作業が必要となる．そこで，このような内部状態を含めた通信システムの挙動の解析を行う，高機能なトラヒックアナライザが必要とされている．

また，通信システムが，TCPの輻輳制御アルゴリズムを正しく動作しているかどうかまでに踏み込んだ解析を行うには，単にパケットをパッシブに監視するだけでなく，能動的に試験パケットを送信することも必要とされる．これまで，通信システムの試験方式としては，OSIの適合性試験方式[10]，試験シナリオの記述方法に関しては，TTCN (Tree and Tabular Combined Notation)[11]などが提案されている．これらを用いた試験は，いかなる入出力パターンも制御でき，汎用的な試験が可能である．しかしながら，プロトコルの知識に熟練した試験運用者が，各入出力パターンを想定しながら，試験シナリオを記述することが要求されるため，試験シナリオの作成に多大な時間を要することが問題である．

そこで，TCPの輻輳制御アルゴリズムの試験など，特定の目的に対し，効率的に試験できる手法が必要とされている．

2 点目は，特定の回線に着目し，回線上を流れるユーザトラヒックをキャプチャし，解析する方法である．この方法の先駆者である MCI テレコミュニケーションズ社が開発したOCxMON[12]は，独自のハードウェアとデバイスドライバにより，OCx (x=3, 12, 48) 回線上で，パケットのヘッダ情報をリアルタイムにキャプチャする．この方法は，オフライン（非リアルタイム）での解析に時間を要すること，回線速度の増加につれヘッダ情報の蓄積に大規模なディスクスペースを必要とすることが課題である．また，Cisco システムズ社が開発したNetFlow[13]や，Auckland大学が開発したNetTraMet[14]は，IPアドレスとポート番号の組で識別されるユーザ毎の通信に関する統計情報をリアルタイムに収集する．この手法は，前者に比べてディスクスペースは消費しないものの，元の通信の情報を保持していないため，トラヒック量の変化を調べるなど，特定の目的にしか利用できない．また，ユーザトラヒックを監視する手法全般に言えることとして，一台の監視装置が監視するのは通常一回線であるため，回線数が多いキャリア・プロバイダのネットワーク全体を監視対象とするのは困難である．

3 点目は，ネットワーク全体への適用を想定した方法であり，ユーザトラヒックそのものは監視せず，その制御情報のみを監視する方法である．この制御情報は，ネットワーク内全体を行き渡るという特徴を持つため，一箇所で監視していてもネットワーク全体に関する情報が得られる．例えば，BGP (Border Gateway Protocol) [15]は，インタードメイ

(17)

ンの経路制御プロトコルであり，AS (Autonomous System) と呼ばれる論理的な組織間で，

UPDATE メッセージと呼ばれる経路制御情報を交換する．ユーザトラヒックの伝達経路

は，この経路情報をもとに決定されるため，この情報を監視することにより，ユーザ間の品質の劣化(接続不能も含む)を間接的に知ることができる．同様の制御情報として，イントラドメインの経路制御プロトコルであるOSPF (Open Shortest Path First) [16]のLSA (Link State Advertizement)や，ストリーミング通信やIP電話の通信をパケット化して運ぶRTP (Realtime Transfer Protocol)[17]の制御情報であるRTCP (RTP Control Protocol) などが存在する．

以上のような背景から，本論文では，TCP/IP 通信を対象とし，上記の通り，ユーザ・

サーバ間の通信，回線上のトラヒック，ネットワーク全体での経路制御情報の3つの観点から，その品質を把握する手法を提案する．それぞれの手法に関し，適用範囲や要求条件を明確化し，具体的なシステム設計，実装，機能・性能評価を行い，考案方式の有効性を検証する．最後に，研究成果をまとめ，将来的な展望について述べる．

1.2 本研究のアプローチ

前述した背景や要求条件を考慮し，本研究では，TCP/IP 通信の接続性と性能を把握する手法として，その目的，適用領域に応じて，以下の５つの実現手法に関する提案を行う．

1. ユーザ間の通信に着目したアプローチ

本アプローチに関しては，以下の2つの実現手法を提案する．

【1】TCPの内部状態の推定を行う高機能なトラヒックアナライザ[18][19][20]

本ツールは，従来のトラヒックアナライザがヘッダフォーマットの解析のみを行うのに対し，双方の通信システム内の TCP の状態や内部変数をエミュレートすることを特徴とする．これを実現するため，２つの擬似 TCP モジュールを内部で管理し，回線上でのパケットの方向に応じて，一方のモジュールには入力パケット，他方のモジュールには出力パケットとして，双方の擬似モジュールの内部の TCP 状態遷移表を更新する．複数の輻輳制御アルゴリズムの仕様をエミュレートする仕組み[21]や，キャプチャ時のパケット取りこぼしを想定した異常シーケンスを扱う仕組み[22]なども考慮している．

【2】TCPの異常手順を効率的に試験する手法（TCPテスタ）[23][24]

(18)

本ツールは，従来の試験方式で課題となっていた，特定の目的に対して効率的に試験する手法に関する提案である．TCPの輻輳制御アルゴリズムの試験では，ある程度，ウインドウが増大してからの通信シーケンスを確認する場合が多く，入出力パケット数が膨大になることが多い．そこで，上記アルゴリズムに適した試験手法として，まず例外的な動作を行う場合のみを試験シナリオに記述させることにより，試験運用者の負荷を軽減する手法を考案した．一つの通信シーケンスにおいて，大部分の入出力パケットは，通常のTCP の手順に従って動作する．従って，実装面においても，ソースが公開された TCP モジュール上で開発するように工夫している．

2. 回線上のトラヒックに着目したアプローチ

本アプローチに関しては，以下の1つの実現手法を提案する．

【3】ユーザの品質を含めたトラヒック統計情報をリアルタイムに収集する手法（パフォーマンスモニタ）[25][26]

本ツールは，従来のトラヒック監視ツールがトラヒック量（IP パケットのパケット数，

バイト数等）に関する統計情報のみを収集するのに対し，TCPスループットやTCP再送率など，ユーザの品質に関わる統計情報を収集する．特に，高速回線上でリアルタイムにキャプチャ・解析できることが必要不可欠であるため，ATM OC3（155Mbit/s）回線を対象とし，これを実現するための設計手法を考案した．全てのユーザ間の通信の品質に関する情報を収集するため，回線上を流れる全 TCP コネクションの状態管理を行っている．

【1】で述べたツールと同様，キャプチャ時の取りこぼしを想定した異常シーケンスを扱う．また，通信経路の非対称性を考慮し，片方向のトラヒックのみが観測された場合[27]

にも，統計情報を収集可能な仕組みを実現している．

3. ネットワーク全体での経路制御情報に着目したアプローチ本アプローチに関しては，以下の2つの実現手法を提案する．

【4】BGPの経路情報よりAS単位で障害箇所を特定する手法[28][29]

インターネット規模で，接続性紛失および品質劣化を検知する手法として，BGPの経路情報を監視する手法に着目した．BGPでは，経路収束の過程で，多数のUPDATEメッセージが複数のネットワークを経由して伝播される．このため，複数のUPDATEメッセージのグループ化（クラスタ化と呼ばれる）により，障害の発生源となるASや発生時刻などを特定する手法が必要とされている．従来の手法は，公開された BGP 経路情報の利用

(19)

を前提とした，複数点観測による手法[30][31]であるため，公開された情報のリアルタイム性が課題となる．そこで，実際のネットワーク運用への適用を考慮し，リアルタイム解析が可能な一点観測による手法を考案した．

【5】BGP経路情報のデータベース化手法[32][33]

現在，RouteViews[34]，RIPE[35]等のプロジェクトで提供されている公開BGP経路情報は，web上に汎用フォーマットで蓄積されたファイルを公開することにより，実現している．このため，ファイルがアップロードされるのに一定時間を要する上，ネットワーク運用者がファイルをダウンロードし，解析するのにも時間を要する．これに対し，汎用SQL データベースを用いて，公開 BGP 経路情報を格納することにより，多数のネットワーク運用者が，必要な情報のみをリアルタイムに検索可能な仕組みを考案した．

本論文では，上記5つの実現手法に関し，方式の提案のみならず，システム設計，簡便性・低コスト化を考慮したシステム実装，実用的な効果を踏まえたシステム評価を行い，

総合的に提案方式の有効性を検証する．

1.3 本論文の構成と内容

本論文の構成と内容は以下のとおりである．

第 2章では，TCP/IP通信の品質監視を目的とする関連技術について述べる．まず，ネットワークの品質監視の現状と，トランスポート層(TCP)の監視に基づく性能の把握，BGP のプロトコル監視に基づく接続性の把握の必要性について述べる．次に，ベースとなる基本技術として，TCPおよびBGPに関して，それぞれプロトコル，通信手順，ならびに，

監視技術の概要を示す．

第3章では，TCP/IP通信の接続性と性能の監視に関する5つの提案手法の位置付けとアプローチについて述べる．それぞれの提案手法について，ネットワークの運用・障害解析における対象・適用領域や，考慮すべき基本的な課題・要求条件を述べ，各提案手法の実現アプローチを示す．

第4章，第５章では，一対の通信システム間でのTCP 通信を対象とする2つの実現手法【1】「TCP の内部状態の推定を行う高機能なトラヒックアナライザ」，【2】「TCP

(20)

の異常手順を効率的に試験する手法（TCPテスタ）」に関する詳細を記述する．それぞれ，

実現手法の要求条件・設計方針を示した後，ツールの詳細設計・実装について述べる．さらに，実現手法の有効性を示すため，ツールの活用例や，ツールの活用により判明したTCP の実装における問題点について報告する．

第 6章では，回線上を流れるトラヒックよりTCP 通信の統計情報を収集する提案手法

【3】「ユーザの品質を含めたトラヒック統計情報をリアルタイムに収集する手法（パフォーマンスモニタ）」に関する詳細を記述する．実現手法の要求条件・設計方針を示した後，ツールの詳細設計・実装について述べる．さらに，実現手法の有効性を示すため，ツールの活用例として，インターネット上のトラヒックを解析した結果について報告する

第7章，第８章では，BGPの経路制御情報を監視する2つの実現手法【4】「BGPの経路情報よりAS単位で障害箇所を特定する手法」，【5】「BGP経路情報のデータベース化手法」に関する詳細を記述する．それぞれ，実現手法の要求条件・設計方針を示した後，

ツールの詳細設計・実装について述べる．さらに，実現手法の有効性を示すため，前者についてはインターネット上での正当性評価結果，後者についてはツールの性能評価結果について報告する．

最後に結論として，第９章において，論文全体を総括し，本研究の意義・成果をまとめるとともに，今後の課題についても言及する．

(21)

第 2 章 TCP/IP 通信の品質監視と関連技術

第1章で述べたように，TCP/IP通信の品質(性能および接続性)の監視をサポートする技術として，本研究では，IETFで規定されているTCP (Transmission Control Protocol)，

ならびに，BGP (Border Gateway Protocol)のプロトコル手順に着目する．本章では，第3 章以降において提案手法を記述する上で必要となるTCPおよびBGPの動作概要を示すとともに，従来行われてきたネットワークの品質の監視技術や関連研究について述べる．

2.1 TCP の概要

TCPは，IP (Internet Protocol)[36]上で，一対の通信システム間において信頼性のあるコネクション型の通信を提供するプロトコルである．TCPの通信手順は，図 2-1に示すように，コネクション確立フェーズ，データ転送フェーズ，コネクション解放フェーズで構成される．コネクション確立フェーズでは，CLOSEDからSYN-RCVDまでの 4つの状態を管理し，スリーウェイハンドシェイクと呼ばれる方法により，各通信システムが，SYN ビットがONであるTCPのパケットのパラメータを確認することにより，TCPコネクションを確立する．なお，TCPのパケットのことをTCPセグメント，SYNビットがONであるTCP セグメントのことを，SYNセグメントと呼ぶ．また，SYN+ACKは，SYNビットおよびACKビットが共にONであることを示す．

データ転送フェーズでは，ESTABLISHED の状態であり，双方向にデータ転送を可能とする．ユーザデータを含むTCPセグメント(DTセグメントと呼ぶ)を受信した通信システムは，その確認応答として，ACKセグメントを送信する．本フェーズでは，ネットワークの状態に応じて，高信頼かつ高速にデータ転送を行うため，さまざまな機能が仕様化されている．フロー制御は，ウインドウサイズにより通知されたデータ量に関して，確認応答を待たずに送信できる機能である．DTセグメントならびにACKセグメントは，それぞれシーケンス番号および確認応答(ACK)番号により管理されているため，ネットワーク上で分割されるパケットの順番や到達性が保証される．送信した DT セグメントに対する ACKセグメントを一定時間以内に受信しなかった場合，パケットが紛失したものと判断し，

タイムアウト再送を行う．輻輳制御は，ネットワークの状態・帯域に応じて，確認応答を待たずに送信するデータ量を，送信側システムにおいて調節する機能である．このデータ

(22)

量は，ネットワーク上に転送されない内部変数cwnd (congestion window)により管理される．タイムアウト再送が発生した場合，cwnd は1セグメント分に設定される．また，本機能では，タイムアウトよりも高速にネットワーク上でのパケット紛失を検知し再送を行う高速再転送(fast retransmit)という仕組みを具備している．このパケット紛失の検知は，

以下のように行う．

z 順番通りでない DTセグメントを受信したシステムは，前回送信したACKセグメントと同じACK番号を持つACKセグメント(duplicate ACKと呼ぶ)を送信する．

z duplicate ACKセグメントを3回受信したシステムは，ネットワーク上でパケットが

紛失したものと判断する．

また，高速再転送時にcwndの値を半分に設定する高速回復(fast recovery)と呼ばれる仕組みが提案されている．1990年代より輻輳制御に関するさまざまな仕様が提案されており，

さまざまなバージョンのTCPが存在する．代表的なものとして，Tahoeはfast retransmit を有しfast recoveryを持たないものである．RenoはTahoeにfast recoveryの機能を加えたものである．また，NewReno[37]はウインドウ内に複数のパケット紛失が発生する場合において，fast recoveryの性能を改善する提案である．さらに，パケット単位で個別に応答確認を行うSACK (Selective ACK)機能[38]も存在する．これらのバージョンのTCP は，現在でも混在してインターネット上で使用されている．

コネクション解放フェーズでは，FIN-SETN-1からTIME-WAIT までの6つの状態を管理している．方向別に独立にコネクションを解放する機能を有しており，最後のデータを転送するシステムはFINセグメントを送信する．双方向でFINセグメントを送信し，

その確認応答を行うことによりコネクションを解放する．

(23)

図 2-1 TCPの通信手順

2.2 BGP の概要

BGPは，パスベクトル型の経路制御プロトコルであり，自律システム(AS: Autonoumous System)とよばれる独立なポリシーを持つネットワーク管理主体を単位として経路制御を行うため，インターネット規模に適応できるスケーラビリティを有する．BGPのプロトコルは，各AS内のコアルータやボーダルータ上で動作する．ルータ間で，TCPコネクションを確立し，その上位プロトコルとしてBGPセッション(ピアリングと呼ぶ)を確立することにより，ルータ間での経路情報の転送を可能とする．大量の経路情報が流れることを防ぐため，変動した経路のみをUPDATEメッセージにより通知する仕組みや，前回の送信から MRAI (Minimum Route Advertisement Interval)で規定された一定時間を置いて

UPDATE メッセージを送信する仕組みが提供されている．経路情報の通知は，プレフィ

クスと呼ばれるアドレス空間(サブネット)を単位として行われる．UPDATEメッセージには，新しい経路あるいは既存の経路の変更を通知する ANNOUNCE メッセージと，経路の取り消し(不到達)を通知するWITHDRAW メッセージが存在する．ANNOUNCEメッセージでは，経由するAS の列を示すASパスや，経路選択やポリシーに関わるさまざまな属性が，ANNOUNCEメッセージのパラメータとして転送される．

(24)

UPDATE メッセージを受信したルータは，新たに受信した経路と，これまでに受信していた経路との間で優先度を比較し，最も良い経路をベスト経路として選択する．通常，

ASパスが最も短い経路がベスト経路となるが，同じ長さのものが複数存在する場合には，

MED (Multi Exit Discriminator)などの他の属性を元に優先度を決定する．UPDATEを受信したルータが，別の AS 上の他のルータにその経路を転送する場合には，自身の AS 番号を，ASパスの頭に追加する．なお，ASパス上に自身のASを含む経路を受信した場合は，その経路は破棄される．これらの仕組みにより，あるプレフィクスに到達する経路をAS単位で管理することが可能となる．

2.3 ネットワークの品質監視の現状

ネットワークの品質(接続性および性能)の監視は，さまざまな場面において必要となる．

例えば，プロバイダの用途としては，ネットワーク障害の解析，通信設備導入時の品質要件の検証，サービスレベル保証(SLA: Service Level Agreement)の監視，ネットワーク展開計画，トラヒックエンジニアリング，外部プロバイダとの接続指針などが挙げられる．

一方，ユーザは，自身が所有する通信端末を用いて，ping や traceroute による接続性確認，スループット測定サイトへのアクセスによる性能確認を行うとともに，PC上でのOS やソフトウェアの設定のチューニング等により，品質劣化に対する問題解決を図っている．

これまでに品質監視を目的としたさまざまなツールが提供され，研究が行われてきているが，これらは監視する対象や粒度ごとに整理可能である．

そこで本節では，監視対象を，

z パケット単位 z フロー単位 z ネットワーク全体

の3つに分類し，それぞれについて，技術動向の進展を整理することとする．

(1) パケット単位での監視

ネットワークの障害解析を目的とする場合には，通信システムの状態や，通信システムが入出力した情報を把握する必要があるため，障害に関連する一つのフローを対象とし，

パケット単位での監視を行うことが必要となる．パケット単位の監視を行うツールとしては，1990年代前半には，Snifferやカメレオンなどの市販プロトコルアナライザが用いら

(25)

れてきた．これらのツールは，回線上でキャプチャしたパケットをもとに，バイナリデータであるパケットの情報を，そのフォーマットに従い，テキスト情報に変換して，ユーザに分かりやすく表示することを目的としている．また，多数のプロトコルに対応していることが特徴である．1990年代後半には，ほぼ同等の機能を持つtcpdumpやetherealなどのパブリックドメインのソフトウェア[39]が登場し，容易に，パケット単位での監視ができるようになった．さらに近年では，これらのソフトウェアは，UNIX ベースの OS (Operating System)にも標準で搭載されるようになってきている．

上記のツールは，パケット毎に独立な解析を行う場合には優れているものの，パケット間を関連付けて解析する場合には不向きである．例えば，TCP の手順の解析では，どの DTセグメントとACKセグメントが対応しているかを正確に解析する必要があり，これまでは上記ツールの出力等を用いて手作業での解析が行われていた．特に，性能の劣化は，

TCP において輻輳制御アルゴリズムを動作させる際の設定上の問題に起因することが多いことが指摘されており[40]，このアルゴリズムの挙動を分析し，正常に動作しいるかを監視する手段が必要である．これに対し，TCPの輻輳制御手順のエミュレーションを行うことを目的とした研究ツールとして，1990年代後半にTCPAnaly[41]が提案されている．

一方，通信設備を導入したときの品質監視としては，ネットワークの状態だけでなく，

通信設備の実装を含めた試験が必要となる．このためには，単にパケットを監視するだけでなく，能動的に試験用のパケットを送出できることが重要である．通信システムの試験に関しては，1990年代前半頃，OSI参照モデル[7]に従った適合性試験方式[10]や，TTCN (Tree and Tabular Combined Notation)[11]と呼ばれる試験シナリオ記述方法が標準化されてきており，それに従うツールも開発されてきている．しかしながら，新しいプロトコルや実装を試験するツールは，システム開発者自身が作成するか，あるいは，システム同士を直接接続して試験する相互運用性試験の中で行われるのが一般的であった．

(2) フロー単位での監視

SLAの監視，ネットワーク展開計画，トラヒックエンジニアリングなどを目的とする場合には，一つの回線を対象とし，フロー単位で監視する方法が効果的である．1990年代後半に出現したNetFlowやNetTraMetは，ルータが転送処理したパケットをフロー別に集計し，外部の収集システムやMIB (Management Information Base)[42]を用いて，フロー単位の統計情報を収集することを可能としたツールである．統計情報として，一定時間毎に，発着IPアドレスと発着ポート番号の組で区別されるフロー別に，IPのパケット数，

バイト数などを収集する．

上記ツールは，通常，多数のユーザのトラヒックを収容する回線上で導入されるが，回

(26)

線速度の増大への対応が課題となる．ルータ上で動作するNetFlowは，ルータのCPUを使用して動作するため，ルータ自身の転送能力との兼ね合いを考慮した運用が行われている．また，フロー単位の集計を外部システムで行う方式も検討されている．この場合，トラヒックのキャプチャ部分の実現方法として，ルータが受信したトラヒックを特定ポートに転送するミラーリングや，Ethernetハブや光カプラなどを使用した回線タップが存在する．前者は，NetFlow と同様，ルータ自身の転送能力への影響が課題となるが，後者は，

ルータに負荷を与えない方式である．外部システムでは，高速回線上のトラヒックをリアルタイムに収集・解析することが課題となる．1990 年代後半に登場した OCxMON は，

当時主流であったOC3 (155Mbit/s)およびOC12 (622Mbit/s)回線への対応を段階的に行っており，パケットのヘッダ情報をリアルタイムにキャプチャする機能を提供していた．また，2000年代前半には，カーネルレベルでの格納処理の工夫により，1Gbit/sのEthernet 上でリアルタイムキャプチャを実現する研究[43]も行われている．近年では，ハードウェアレベルで，1Gbit/sや10Gbit/sのフルキャプチャを行う市販製品が登場し，DoS (Denial of Service)検知などを目的として活用されている．また，回線の高速化に追随できるように，キャプチャ・解析するパケット数を限定するサンプリング手法が提案され，IETF での標準化[44]も行われている．また，サンプリングデータと元データを比較した検証に関しても数多くの研究発表[45][46]が行われている．

(3) ネットワーク全体の監視

外部プロバイダも含めたネットワーク障害の解析や，外部プロバイダとの接続状況を監視するには，BGPのプロトコルに従う接続性の監視が効果的である．従来，接続性の監視を行う際には，ルータにログインし，showコマンドなどにより，BGPセッションの有無や経路情報の確認が行われてきた．また，ping や traceroute などの死活監視を行うツールや，外部のユーザが経路情報の確認を行うインターフェースであるルッキンググラスなどが提供されてきた．これらのツールはいずれも，現在のネットワークの状態を監視することを特徴としている．

これに対し，経路情報の長期的に蓄積するような仕組みが提案されており，最も初期のルーティングソフトウェアの一つである MRTD (Multi-threaded Routing Toolkit

Daemon)で採用されたMRTフォーマット[47]は，BGP経路情報を蓄積するフォーマット

を規定したものであり，zebra[48]や quagga[49]等のルーティングソフトウェアでも採用され，現在IETFでドラフト化されている．BGP経路情報は，ルータとBGPセッションを確立することにより，パッシブに収集・蓄積することが可能である．この仕組みを応用し，複数のASでの経路監視と経路情報の公開を実現したのが，Route ViewsやRIPE等のプロジェクトである．Route Viewsプロジェクトでは，2002年より経路情報の収集・公開を開始し，現在でも継続し，webサーバ上に複数の外部プロバイダが収集した経路情報

(27)

を公開している．これらのプロジェクトの貢献により，BGPの経路情報を用いた研究もさかんに行われるようになった．例えば，2003年頃から行われている経路変動の発生源の解析の研究[30][31]はその一例である．

(28)

第 3 章提案手法の位置付けとアプローチ

本章では，TCP/IP 通信の接続性と性能の監視手法に関して，具体的な提案手法の位置付けとアプローチについて述べる．第1章で述べたように，本研究においては，目的・適用領域に応じて，【1】パケット単位での監視，【2】フロー単位での監視，【3】ネットワーク全体での監視の3つのアプローチにおいて，合計で5つの実現手法を提案する．具体的には，【1】については，(1) TCPの内部状態の推定を行う高機能なトラヒックアナライザ，(2) TCPの異常手順を効率的に試験する方法(TCPテスタ)を提案する．【2】については，ユーザの品質を含めたトラヒック統計情報をリアルタイムに収集する手法(パフォーマンスモニタ)を提案する．【3】については，(1) BGPの経路情報よりAS単位で障害箇所を特定する手法，(2) BGP経路情報のデータベース化手法を検討・提案する．以下では，

それぞれの提案手法について，第2章で述べたネットワークの品質監視技術の現状を分析した上で，考慮すべき課題を述べ， TCP/IP 通信の接続性と性能の監視を実現するため，

それぞれの課題に対応した提案手法のアプローチを示す．

3.1 パケット単位での監視に対するアプローチ

2 章で述べたように，通信システムの状態や通信システムが入出力した情報の把握，通信システム間の相互接続試験において，パケットダンプを用いたパケット単位での監視が行われてきた．このツールは，一般にプロトコルアナライザと呼ばれ，回線上を流れるパケットの情報をもとに，複数のプロトコルのパケットのフォーマットに従って，パラメータ値を解析するものである．具体的には，

図 3-1に示すような情報が得られる．最初のメッセージ (図中の1～3行目)は，通信システムA が，15:02:44.240806 秒に，DTセグメントを送信し，そのパラメータのうち，例えばソースIPアドレス(SrcIP)がxx.xx.114.77であることを示している．

プロトコルアナライザは，多種のプロトコルに対応しており，パケットの情報を視覚的に分かりやすく表示してくれるものの，通信システムの障害解析時に必要となるパケット間の関連付けを手作業で行う必要がある．

図 3-1の情報は，ネットワーク上のある一点で得られたものであるため，通信システムが，

この順序でパケットを処理したかどうか，さらには，これらのパケットが通信システムに

(29)

届いているかどうかは分からない．プロトコルアナライザで表示される情報は，パケットに含まれる情報のみであるため，通信システム内で管理している状態・内部変数などの情報は直接収集できず，これらの情報を調査するには，パケット間の関連付けを手作業で追いかけるといった地道な解析が必要となる．さらに，相互接続試験においては，パケットの監視を行うだけでなく，能動的に試験用のパケットを送出することが求められるが，プロトコルアナライザはこのような機能を有していない．

図 3-1 パケットダンプの出力

そこで，パケット監視に関する上記の課題に対して，以下の実現アプローチを検討した．

(1) 回線上を流れるパケットとその方向の情報を元に，通信システムのプロトコル仕様に従い，通信システムでのパケット送受信時刻を推定する．この際，図 3-2のエミュレーションシステムは，キャプチャ時刻と通信システムで送受信した時刻のずれを，通信システムとモニタ地点間のネットワークの回線速度，物理的距離，送受信したパケットのサイズから計算する．また，通信システムは，通常パケットの受信や時間の経過を入力イベントとして，その応答としてパケットの送信(出力イベント)を行うため，これらの対応関係を把握しつつ，通信システム内の状態・内部変数をエミュレートする．この動作は，一つのフローに関わる一対の通信システムに対して行う．なお，通信システムの仕様に従わない入出力イベントが発生する可能性があるため，これらの場合には，イベントの発生時刻とその順序の推定を誤った可能性や，通信システムの実装の不備の可能性があるものと判断する．本研究では，プロトコル内部での状態・内部変数の管理が複雑な TCP を対象として，そのエミュレーションシステム(TCPアナライザ)について検討した．

(30)

図 3-2 通信システムのエミュレーション

(2) 相互接続試験では，通信システムの状態・内部変数を把握しつつ，プロトコルの通信手順に従わない動作を意図的に発生させることが重要となる．このような試験を行う場合，

試験システムをスクラッチから開発するのは非効率である．そこで，通信手順とその状態・

内部変数の管理については既存の通信システムを流用し，その一部を改修することにより，

試験運用者が任意に例外的な入出力シーケンスを発生させるテスタを考案した．具体的には，図 3-3に示すように，例外的な入出力シーケンスを行う部分だけを試験シナリオに記述する．テスタは，試験シナリオに記述された条件を含む入出力シーケンスを検知したときのみ試験シナリオに従った動作を実行し，他の場合には，通常の通信システムの手順に従った動作を行う．これにより，低コストかつ迅速に新しいプロトコルや仕様を試験するためのテスタを開発可能である．本研究では，輻輳制御アルゴリズムに関するプロトコル仕様の改良が繰り返されてきたTCPを対象として，その試験ツール(TCPテスタ)の設計・

実装に取り組んだ．

(31)

図 3-3 例外的な通信手順の実装

3.2 フロー単位での監視に対するアプローチ

SLAの監視，ネットワーク展開計画，トラヒックエンジニアリングなどを目的とする場合には，一つの回線を対象とし，フロー単位の粒度で集計して監視する方法を行われてきた．NetFlowやNetTraMetなどのフロー収集ツールは，一定時間毎に，発着のIPアドレスと発着のポート番号を組で識別されるフロー毎に，IPのパケット数，バイト数などの統計情報をリアルタイムに収集する．これらのツールの特徴および要求条件は，高速回線上を流れるパケットを解析できるだけの高速処理機能を備えていること，上記目的に必要となる情報を取捨選択し(ここではIPパケット数，バイト数)，これらをリアルタイムに蓄積することである．IPネットワークの利用の主目的がインターネット接続であった1990年代後半においては，通信の品質に対するユーザの要求がさほど高くなかったため，上記目的にはIPパケット数・バイト数レベルでの把握ができれば十分と考えられてきていた．

これに対し，本研究では，将来的に，ユーザ要求やサービスの多様化により，フロー単位での品質を把握することが重要になると考え，このために必要な要素として，従来のフロー収集ツールの機能に加えて，IP パケット・バイト数などのトラヒック量だけでなく，

品質を補完する統計情報を収集するツール(パフォーマンスモニタ)について検討した．フローの品質を把握するには，IP レイヤの情報だけではなく，TCP レイヤの情報も含めた解析が必要となる．具体的には，全DTセグメントのうち再送を示すDTセグメントの割合を示すTCP再送率や，再送を含まないDTセグメントにおける時間あたりのデータ転送量を示すTCPスループットなどが，品質を補完する統計情報となる．TCPレイヤまでの

(32)

リアルタイム解析を実現するにあたり，図 3-4に示すように，多数のTCPコネクションならびに統計情報のテーブルをそれぞれ管理し，リアルタイム性実現に向け，それぞれにおいてハッシュを用いてテーブル検索の高速化を図った．TCPアナライザにおける誤り推定などの時間を要する処理はできないものの，簡易な状態遷移表を用いて TCP の状態・

内部変数の管理を行っている．1990年代後半における主流なバックボーン回線がATMの OC3 回線(155Mbit/s)であったため，その回線上でトラヒックをキャプチャし，リアルタイムに解析し，TCP レイヤのフロー単位の統計情報をリアルタイムに蓄積するシステム (パフォーマンスモニタ)を設計・実装した．

回線 NIC

キャプチャ機能

リアルタイム解析機能蓄積機能

TCPコネクションテーブル

統計情報テーブルハッシュ

統計情報ログ

パフォーマンスモニタ

オフライン解析機能

解析結果

図 3-4 TCPレイヤのフロー管理を行うパフォーマンスモニタ

3.3 ネットワーク全体での監視に対するアプローチ

上記の一回線を対象としたフロー単位の監視では，多数の回線を持つプロバイダに流れる通信全体を管理するのに多数の監視装置を導入する必要がある．高速回線上のトラヒックを監視する装置は，ハードウェアで実現されているものが多く，一般的に高価であり，

プロバイダ全体の規模で導入するにはスケールしないという問題があった．一方，外部プロバイダも含め，ネットワーク障害解析やプロバイダ間の接続状況を監視するには，トラヒック情報ではなく，BGP のプロトコル情報を監視するのが効果的である．これまでに，

BGPのプロトコル情報を監視する仕組みとして，zebraやquaggaなどのルーティングソフトウェアが使用されてきた．また，これらのソフトと，複数プロバイダとの同時接続を組み合わせて，複数地点での接続性を監視し，その結果を蓄積し，web上に公開するプロ

(33)

ジェクトが2002年より開始され，BGPの解析に関わる研究の発展に大きく貢献している．

一方，インターネットの障害診断においては，迅速な障害復旧を目的として，2003年より BGP経路情報を用いて，経路変動の発生源をAS単位で特定する研究が行われてきた．

しかしながら，現状の監視ツール・プロジェクトは，データの公開，入手，解析という観点において，厳しい運用条件として求められる，数分というオーダーでのリアルタイム性がないことが課題である．このリアルタイム性を達成する手法として，以下の2つの実現アプローチを考案した．

(1) これまで，経路変動の発生源を特定する研究としては，特定精度の観点から，複数観測点の情報を用いた研究が行われてきた．このような監視の仕組みは，1 プロバイダとして実現するのは難しく，プロジェクトに参加する形で複数のプロバイダが連携して行ってきた．この際，プロジェクトが提供するデータを使用することになるが，経路変動を検知してから，web 上での公開までに数10 分の遅れがあることが実運用においては問題となる．そこで，1 点観測であれば，監視装置の設置はプロバイダ内で解決するため，リアルタイム性が確保できるという理由に基づき，1 点観測において発生源を特定する手法について検討した．複数点の場合に比べて，解析に使用可能な経路情報が限定されるため，より解析手法の工夫が必要となる．そこで，複数点観測を1点観測に適用した場合の推定誤りの事例を分析し，1点観測においても誤りが発生しない解析手法(トポロジー優先アルゴリズム)を考案した．

図 3-5 1点観測による経路変動の発生源特定

(34)

(2) 経路情報公開プロジェクトは，MRT フォーマットに従うファイルで経路情報を web 上に公開している．経路情報の解析は，個々のプロバイダの運用者やユーザに委ねられている．しかしながら，MRT ファイルは，特定の経路の検索に対して効率よくデータが格納されていないため，検索に時間を要するという問題があった．これに対し，SQLソフトを用いて，図 3-6 に示すように，BGP 経路情報をデータベース化して蓄積することにより，経路の検索の高速化を図る手法を考案した．時刻とアドレスをもとにASパスを検索するといった典型的な SQL 検索要求に対して，高速に応答できるようにデータベースの最適化を図った．

プロバイダネットワーク

運用者

経路検索システム

SQL要求

SQL応答

_{経路情報ログ}

SQLデータベース

観測点ルータ

経路情報

観測点ルータ

図 3-6 BGP経路のデータベース化

(35)

第 4 章通信システムの内部状態をエミュレートする TCP アナライザ

4.1 概要

本章では，パケット単位での監視に対するアプローチの1実現手法として，パケット間の対応づけを推定することにより，通信システムの内部状態をエミュレートする TCP アナライザについて述べる．2章および3章で述べたように，従来のプロトコルアナライザは，パケットのフォーマット解析を特徴としており，パケット間の対応づけを解析する機能を持たないため，通信システムが正しい手順で動作しているか否かを解析するのに手間がかかるという問題があった．特に，TCP は，Web サーバアクセスや電子メールなど多くのアプリケーションで使用されており，ネットワークの輻輳や伝送誤りによりパケット紛失が発生する場合や双方の通信システムにおいてソケットバッファサイズなどのパラメータ値が異なる場合のスループット低下の問題が指摘されているため，その通信手順を効果的に解析するツールが求められている．これに対して，本研究において試作した TCP アナライザは，キャプチャした TCP セグメントの情報をもとに，通信システムにおいて発生した送受信イベントを推定し，TCPの状態遷移表に従い，通信システムの動作をエミュレートする．

本章の構成を以下に示す．4.2 節では，提案手法を実現する上で考慮すべき要求条件を示す．4.3節では，要求条件をもとにした設計方針を示す．4.4節は，システムの個々の機能毎の詳細な設計について述べる．4.5節は，システムの中核的な機能であるTCPの内部動作の推定機能について述べる．4.6節は，システムの実装と動作解析例について述べる．

最後に，4.7節でシステム試作における成果とその後の展望を踏まえた結論を述べる．

4.2 要求条件

TCPアナライザの設計に当たって，以下のような要求条件を想定した．前述のように本アナライザは，スループットが低いなどの問題が生じた TCP 通信に対して，オペレータ

TCP/IP 通信の接続性と性能の監視手法 に関する研究

TCP/IP 通信の接続性と性能の監視手法 に関する研究

大岸 智彦

電気通信大学大学院 情報システム学研究科 博士（工学）の学位申請論文

2008 年 3 月

TCP/IP 通信の接続性と性能の監視手法 に関する研究

博 士 論 文 審 査 委 員 会

主査 加藤 聰彦 教授

委員 曽和 将容 教授

委員 森田 啓義 教授

委員 吉永 努 准教授

委員 岡田 和則 客員教授

著 作 権 所 有 者 大岸 智彦

2008

A Study on Monitoring Method for Connectivity and Performance of TCP/IP Communications

Tomohiko Ogishi

Abstract

TCP/IP 通信の接続性と性能の監視手法 に関する研究

大岸 智彦

概 要

目 次

図 目 次

表 目 次

第 1 章 はじめに

1.1 本研究の背景

1.2 本研究のアプローチ

1.3 本論文の構成と内容

第 2 章 TCP/IP 通信の品質監視と関連技術

2.1 TCP の概要

2.2 BGP の概要

2.3 ネットワークの品質監視の現状

第 3 章 提案手法の位置付けとアプローチ

3.1 パケット単位での監視に対するアプローチ

3.2 フロー単位での監視に対するアプローチ

3.3 ネットワーク全体での監視に対するアプローチ

プロバイダ ネットワーク

運用者

経路検索システム

SQL要求

SQL応答

観測点ルータ

経路情報

観測点ルータ

第 4 章 通信システムの内部状態をエミュレ ートする TCP アナライザ

4.1 概要

4.2 要求条件

TCP/IP 通信の接続性と性能の監視手法に関する研究

TCP/IP 通信の接続性と性能の監視手法に関する研究

大岸智彦

電気通信大学大学院情報システム学研究科博士（工学）の学位申請論文

TCP/IP 通信の接続性と性能の監視手法に関する研究

博士論文審査委員会

主査加藤聰彦教授

委員曽和将容教授

委員森田啓義教授

委員吉永努准教授

委員岡田和則客員教授

著作権所有者大岸智彦

TCP/IP 通信の接続性と性能の監視手法に関する研究

大岸智彦

概要

目次

図目次

表目次

第 1 章はじめに

第 3 章提案手法の位置付けとアプローチ

プロバイダネットワーク

第 4 章通信システムの内部状態をエミュレートする TCP アナライザ