博士論文 - 倉敷芸術科学大学yukio-m/papers/dthesis.pdfshow measurement results of the...

NAIST-IS-DT9661028

博士論文

TCPの性能改善に関する研究— 性能評価システムの構築と短期デッドロック問題の解決 —

村山公保

1998年 2月 9日

奈良先端科学技術大学院大学

情報科学研究科情報システム学専攻

本論文は奈良先端科学技術大学院大学情報科学研究科に博士 (工学)授与の要件として提出した博士論文である．

3

提出者: 村山公保

審査委員: 尾家祐二教授高橋　豊教授福田　晃教授山口　英助教授

TCPの性能改善に関する研究— 性能評価システムの構築と短期デッドロック問題の解決 — ∗

村山公保

内容梗概

TCP (Transmission Control Protocol) は，インターネットでもっとも重要なトランスポート・プロトコルに位置づけられている．しかし，TCPは完全なプロトコルではなく，あらゆるネットワーク環境に適応できるわけではない．このため，TCPに関する数多くの研究が行われ，TCPプロトコルとその実装の修正と拡張が行われてきた．本論文は，現在の TCPプロトコルに残されている重大な問題である TCP短期デッド

ロック問題を中心に，TCPの性能改善に関する議論を行う．このTCP短期デッドロック問題は，TCPの確認応答機構に不備があるために発生する問題である．この問題が連続的に発生すると，セグメントが間欠的にしか転送されなくなり，スループットが極端に悪化する．しかし，現在までに副作用のない効果的な解決策は提案されておらず，早急な解決が望まれている．初期の TCPの実装にはこの問題は存在しなかった．しかし，現在使われているほとん

どすべての実装で発生する可能性のある問題である．TCPには，誕生してから今日までの間に，データ転送の効率を向上させるために様々な工夫が加えられてきた．これらの工夫によって TCPの性能は大きく向上したが，逆にこれらの工夫の副作用により，環境によっては性能が著しく低下するという問題が生じるようになった．デッドロックが発生しない場合には，TCPに加えられた工夫の効果により，ネットワー

クやホストの負荷が軽減され，スループットが向上する．これは，今日の巨大なインターネットや高速 LAN環境で，TCPによる高速なデータ転送を実現するための原動力になっていると考えられる．そこで本論文では，TCPがデータ転送の効率を向上させている工夫について細かい分析を行う．アプリケーションの視点から，TCPによる通信を 3つのモデルに分類し，どの通信モデルにおいても TCPの機構がネットワークやホストの負荷を低減させるように働いていることを明らかにする．そして，アプリケーションの作成時や，TCPの拡張や改善を行う場合に，これらのモデルを考慮することが重要であることを示す．

TCP短期デッドロック問題のように，たとえ性能改善が目的であったとしても，TCPの仕様や実装に変更を加えることは，新たな問題を発生させる可能性がある．また，シミュ

∗奈良先端科学技術大学院大学情報科学研究科情報システム学専攻博士論文, NAIST-IS-DT9661028,1998年 2月 9日.

i

レーションで検討された性能改善の場合には，実装した時に本当に性能が向上するかどうかの検証が必要である．実装がなければ，結果を十分に信頼することはできない．実装を拡張・修正するときに，新たな不具合 (バグ) が入り込む可能性もある．実際にインターネットに接続されているTCPの実装を検査してみると，不具合のある実装は少なくない．本論文では，これらの問題点に着目し，TCPの性能や実装の検査に関する議論を行う．実際に，TCPの実装の不具合に関する具体的な測定例を示し，実装検査ツールの必要性と必要な機能に関する議論を行う．また，TCP性能評価ツール DBS (Distributed Benchmark

System) の提案と実装を行う．さらに，様々なネットワーク環境で行った DBSによる性能測定実験の結果を示すと共に，DBSによって得られる効果について議論を行う．以上をふまえ，本論文では，TCPの短期デッドロック問題の解決策を提案する．従来の

改善策とは異なり，TCPのデータ転送モデルを重視することで，副作用のない解決策を提案する．また，送信ホストが受信ホストの遅延確認応答処理を完全に制御することで，デッドロック問題を根本的に解決できる方法を提案する．本提案を実装すれば，TCPやTCPの下位層や上位層に新たな変更が加えられたとしても，デッドロック問題が発生することはない．さらに，本提案を実装し，検証実験を行った結果について述べ，本研究の提案の有効性を証明する．

キーワード

TCP, トランスポート層, デッドロック, インターネット, 性能評価, 性能改善

ii

Studies on TCP Performance Improvement:

Design and Implementation of a Performance Evaluation Tool

and a Solution to the Short-Term Deadlock Problem ∗

Yukio Murayama

Abstract

TCP (Transmission Control Protocol) is one of the most important protocols in the In-

ternet. However, it is not a perfect and all-purpose protocol. Therefore, many researches

are conducted so far to improve the performance and usability of TCP.

In this thesis, we discuss one of the major drawbacks in current TCP implementa-

tions called “TCP short-term deadlock problem”. This problem is due to inadequate

delayed acknowledgment handling in TCP. Under some condition, short-term deadlocks

where data are transferred intermittently occur repeatedly. As its result, the end-to-end

throughput in TCP connection is extremely decreased. Some solutions have been pro-

posed for this problem. It required turning off delayed acknowledgment mechanism of

TCP in order to eliminate short-term deadlocks. However, this will double the acknowl-

edgments transferred, thereby decrease the throughput of transmission.

These types of problems did not exist in earlier implementation of TCP. However,

these problems occur in almost all TCP implementation today. Some improvements

have been done on TCP to achieve efficient data transmission up to present. However, it

also produced the side effects of TCP deadlock problems. If deadlock would not occur,

the functions of TCP that are to improve data transmission efficiency would decrease

the load of networks and hosts, and throughput would be increased. This function can

be considered as the driving force in running the huge Internet and high speed LANs

today. In this thesis, we will analyze the mechanism in detail. We will classify TCP

data communication into three models from the viewpoint of application. Also, we will

see that the mechanism is effective in decreasing the loads of networks and hosts in

these three models. These models are considered to be important in the process of

implementing application program. It is important also to consider these models while

expanding and improving TCP.

Changing the specifications or the implementation of TCP in order to improve its

performance may generate new problems. Short-term deadlock problem is one of these∗Doctor’s Thesis, Department of Information Systems, Graduate School of Information Science, Nara

Institute of Science and Technology, NAIST-IS-DT9661028, February 9, 1998.

iii

examples. A performance improvement proposal based only on simulation is unpracti-

cal. Without the process of implementation and experiments in actual network envi-

ronment, performance improvement would be unrealizable. Furthermore, errors or bugs

could be produced in the process of extending or modifying existing implementation. In

this thesis, we examine performance evaluation tool for TCP and implementation test

tool in order to provide a better solution to the problems we have discussed. We will

show measurement results of the problems arising in TCP implementation, and discuss

the necessity of the implementation test tool and the necessary functions of this tool.

Moreover, we propose and implement DBS (Distributed Benchmark System) which is a

performance evaluation tool for TCP. We will also describe the result of the experiments

and discuss the effects provided by the DBS.

In this thesis, we also propose another solution to the TCP short-term deadlock prob-

lem base on what we have mentioned above. Since TCP sender can control the receiver’s

processing of delayed ACK perfectly, TCP deadlock can be eliminated with our proposed

method. As a result, deadlock will not occur in our implementation even if new modifica-

tion is done on TCP or the layer above or under it. Finally, we will show the effectiveness

of our proposal by analyzing the results of our implementation.

Keywords:

TCP, transport layer, deadlock, the Internet, performance evaluation, performance im-

provement

iv

目次p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

PART I 研究の背景 1

第1章序論 3

1.1 インターネットの普及と現状 . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 インターネットを支えるプロトコルとその問題点 . . . . . . . . . . . . . . 6

1.3 本論文で取り扱う題目 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1 TCPのデータ転送モデルと実装モデル . . . . . . . . . . . . . . . . 10

1.3.2 TCPの実装検査と性能評価 . . . . . . . . . . . . . . . . . . . . . . 11

1.3.3 TCP短期デッドロック問題 . . . . . . . . . . . . . . . . . . . . . . 12

1.4 本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

第2章TCPの性能に関する研究とTCPの拡張 15

2.1 データ転送の効率を向上させる研究 . . . . . . . . . . . . . . . . . . . . . . 16

2.1.1 Nagleアルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.2 遅延確認応答 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.3 受信可能なウィンドウの通知 . . . . . . . . . . . . . . . . . . . . . 18

2.2 TCPの実装の問題と改善に関する研究 . . . . . . . . . . . . . . . . . . . . 18

2.2.1 データ転送の効率を向上させる仕組みの問題 . . . . . . . . . . . . . 18

2.2.2 メモリ管理機構，コンピュータ・アーキテクチャの問題 . . . . . . . 20

2.2.3 ネットワーク・モジュールの階層化の問題 . . . . . . . . . . . . . . 24

2.3 高速ネットワークへの適用 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.1 ウィンドウ・サイズの制限の問題 . . . . . . . . . . . . . . . . . . . 26

2.3.2 TCPゲートウェイによる解決 . . . . . . . . . . . . . . . . . . . . . 28

2.4 輻輳制御・再送制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4.1 スロー・スタート . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4.2 再送タイムアウトの見積もり . . . . . . . . . . . . . . . . . . . . . 30

2.4.3 選択確認応答 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.4 再送アルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.5 ルータによる制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.5 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

v

vi 目次

PART II TCPのデータ転送モデルと実装モデル 37

第3章TCPのデータ転送モデル 39

3.1 データ転送のモデル化の意義 . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 セグメントと PUSH機構 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.1 セグメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.2 PUSH機構 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 バルク・データ転送モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4 インタラクティブ・データ転送モデル . . . . . . . . . . . . . . . . . . . . . 43

3.5 即時性を必要とするインタラクティブ・データ転送モデル . . . . . . . . . 45

3.6 データ転送モデルとセッション層 . . . . . . . . . . . . . . . . . . . . . . . 46

3.7 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

第4章TCPの実装モデルとその問題 49

4.1 TCPの実装モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 TCPの上位層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.1 セッション層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3 TCPの下位層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.1 経路MTU探索 (Path MTU Discovery) . . . . . . . . . . . . . . . . 56

4.3.2 経路MTU探索の実装の問題 . . . . . . . . . . . . . . . . . . . . . 57

4.3.3 経路MTU探索の実験のまとめ . . . . . . . . . . . . . . . . . . . . 68

4.4 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

PART III TCPの実装検査と性能評価 71

第5章TCPの実装と性能の評価 73

5.1 インターネットにおける実装の意味 . . . . . . . . . . . . . . . . . . . . . . 73

5.2 実装評価と性能評価の必要性 . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3 TCPの実装検査に関する考察 . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.3.1 経路MTU探索による TCPの動作の検査システムの提案 . . . . . . 75

5.3.2 TCP実装検査ツールに求められる機能 . . . . . . . . . . . . . . . . 78

5.4 TCPの性能評価に関する考察 . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.4.1 TCP性能測定ツールに求められる機能 . . . . . . . . . . . . . . . . 79

5.4.2 既存の性能測定ツールとその問題点 . . . . . . . . . . . . . . . . . . 80

5.5 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

目次 vii

第6章TCPの性能評価システムの提案・実装・評価 83

6.1 DBSの提案と実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.1.1 DBSの提案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.1.2 DBSの実装モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.1.3 DBSのシステムの実装 . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.1.4 トラヒック・パターン . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.1.5 DBSの測定結果の処理 . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.1.6 セキュリティに対する配慮 . . . . . . . . . . . . . . . . . . . . . . . 89

6.2 DBSの評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.2.1 機能面の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.2.2 測定結果の妥当性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.3 DBSによる性能測定実験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.3.1 衛星回線 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.3.2 ATMとRouterが混在する環境 . . . . . . . . . . . . . . . . . . . . 100

6.3.3 FDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.3.4 HIPPI over ATM Network . . . . . . . . . . . . . . . . . . . . . . . 106

6.4 WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.5 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

6.6 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

PART IV TCP短期デッドロック問題の解決 121

第7章TCP短期デッドロック問題と既存の解決案 123

7.1 TCP短期デッドロック問題 . . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.1.1 送信バッファがMSSに比べて十分大きくない場合 . . . . . . . . . . 123

7.1.2 ネットワーク・モジュールの階層化の問題 . . . . . . . . . . . . . . 124

7.1.3 スロー・スタートの問題 . . . . . . . . . . . . . . . . . . . . . . . . 125

7.1.4 経路MTU探索の問題 . . . . . . . . . . . . . . . . . . . . . . . . . 126

7.2 今までに提案された TCPデッドロック問題の解決案 . . . . . . . . . . . . 128

7.3 今までに提案されたデッドロック解決案の問題点 . . . . . . . . . . . . . . 129

7.4 TCPデッドロック問題とその解決方法に関する考察 . . . . . . . . . . . . . 132

7.5 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

第8章TCPデッドロック問題の解決策の提案・実装・評価 133

8.1 デッドロック問題の解決策の提案 . . . . . . . . . . . . . . . . . . . . . . . 133

8.1.1 NDAフラグ (Never Delay ACK flag) . . . . . . . . . . . . . . . . . 134

viii 目次

8.1.2 FDAフラグ (Force Delay ACK flag) . . . . . . . . . . . . . . . . . 134

8.1.3 NDAフラグと FDAフラグの設定に関する補足事項 . . . . . . . . . 135

8.2 本提案と TCPデータ転送モデル . . . . . . . . . . . . . . . . . . . . . . . 137

8.3 実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

8.4 検証実験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

8.5 実験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

8.5.1 実験 1: 送信バッファがMSSに比べて十分大きくない場合 . . . . . 146

8.5.2 実験 2: ネットワーク・モジュールの階層化の問題 . . . . . . . . . . 151

8.5.3 実験 3: スロー・スタートの問題 . . . . . . . . . . . . . . . . . . . . 154

8.5.4 実験 4: 経路MTU探索の問題 . . . . . . . . . . . . . . . . . . . . . 156

8.5.5 トラヒック量の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . 159

8.6 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

8.6.1 実験結果への他のトラヒックの影響 . . . . . . . . . . . . . . . . . . 163

8.6.2 他のトラヒックがある環境での本提案の効果 . . . . . . . . . . . . . 163

8.6.3 TCPデッドロック問題の解決の重要性 . . . . . . . . . . . . . . . . 165

8.6.4 デッドロック問題の解決に関する考察 . . . . . . . . . . . . . . . . 166

8.6.5 インターネットへの適用について . . . . . . . . . . . . . . . . . . . 166

8.6.6 実装に関する考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

8.7 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

PART V 研究の総括 169

第9章結論 171

9.1 本研究の成果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

9.1.1 TCPデータ転送モデルの明確化 . . . . . . . . . . . . . . . . . . . . 171

9.1.2 TCP実装検査ツールの提案 . . . . . . . . . . . . . . . . . . . . . . 172

9.1.3 TCP性能評価ツールDBSの構築 . . . . . . . . . . . . . . . . . . . 172

9.1.4 TCP短期デッドロック問題の解決 . . . . . . . . . . . . . . . . . . 173

9.2 今後の予定と課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

9.2.1 実装をベースとした TCPの性能評価 . . . . . . . . . . . . . . . . . 173

9.2.2 TCP実装検査システムの実装 . . . . . . . . . . . . . . . . . . . . . 173

9.2.3 TCP短期デッドロック問題の解決の標準化 . . . . . . . . . . . . . 174

9.2.4 TCP短期デッドロック問題の実装検査システムの構築 . . . . . . . 174

9.2.5 次世代 TCPの提案 . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

謝辞 175

目次 ix

参考文献 177

研究業績 183

図目次p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

1.1 TCP/IPとOSIのプロトコル階層の比較 . . . . . . . . . . . . . . . . . . . 7

1.2 TCP/IPの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 シリー・ウィンドウ・シンドローム . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Comerらの実験の測定環境 . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Luckenbachらの実験の再実験に使用した環境 . . . . . . . . . . . . . . . . 22

2.4 送信メッセージサイズとスループットの関係 . . . . . . . . . . . . . . . . . 22

2.5 送信メッセージサイズとスループットの関係 (拡大図その 1) . . . . . . . . 23

2.6 送信メッセージサイズとスループットの関係 (拡大図その 2) . . . . . . . . 23

2.7 2点間の Ethernet実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.8 送信メッセージ・サイズとスループットの関係 . . . . . . . . . . . . . . . . 25

2.9 ラウンド・トリップ時間とスループットの関係 . . . . . . . . . . . . . . . . 27

2.10 TCPの自己同期 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.11 通常の確認応答と選択確認応答の違い . . . . . . . . . . . . . . . . . . . . . 31

3.1 TCPのデータ転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2 バルク・データ転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3 インタラクティブ・データ転送 . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4 遅延確認応答の果たす役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.5 即時性を必要とするインタラクティブ・データ転送 . . . . . . . . . . . . . 45

4.1 OSI参照モデルと TCP/IP階層モデル . . . . . . . . . . . . . . . . . . . . 50

4.2 フラグメント処理をする場合 (上)と経路MTU探索をする場合 (下)のTCP

データセグメントの流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.3 実験 1の環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.4 シーケンス番号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.5 スループット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.6 実験 2の環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.7 シーケンス番号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.8 スループット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.9 実験 3の環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

xi

xii 図目次

4.10 実験 3の測定結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.11 実験 4の環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.12 実験 4の測定結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.13 実験 5の環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.14 実験 5の測定結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.1 経路MTU探索の実装検査ツールのシステム構成と動作概要 . . . . . . . . 76

6.1 DBSのシステム構成図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.2 DBSの処理の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.3 DBSのトラヒック・パターン . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.4 2点間の Ethernet実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.5 それぞれのツールでの測定結果 (時間変化) . . . . . . . . . . . . . . . . . . 92

6.6 ウィンドウ・サイズ拡張オプションの評価 . . . . . . . . . . . . . . . . . . 94

6.7 ウィンドウ・サイズの拡張オプションの評価 (シーケンス番号の推移) . . . 95

6.8 ウィンドウ・サイズの拡張オプションの評価 (スループットの変化) . . . . 95

6.9 ウィンドウ・サイズの拡張オプションの評価 (輻輳ウィンドウの変化．バッファ・サイズが 32768byteと 65535byteの場合は，7秒目までバッファ・サイズが 131072byteの場合と重なるように変化している) . . . . . . . . . . . 96

6.10 衛星回線での測定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.11 衛星回線での測定結果 (シーケンス番号の推移) . . . . . . . . . . . . . . . . 98

6.12 衛星回線での測定結果 (スループットの変化) . . . . . . . . . . . . . . . . . 98

6.13 衛星回線での測定結果 (輻輳ウィンドウ (cwnd)とスロー・スタート閾値(ssthresh)の変化) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.14 ATMとルータが混在する環境での測定 . . . . . . . . . . . . . . . . . . . . 101

6.15 ATMとルータが混在する環境での測定結果 (シーケンス番号の推移) . . . . 102

6.16 ATMとルータが混在する環境での測定結果 (スループットの変化) . . . . . 102

6.17 FDDIでの測定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.18 FDDIでの測定結果 (シーケンス番号の推移) . . . . . . . . . . . . . . . . . 105

6.19 FDDIでの測定結果 (スループットの変化) . . . . . . . . . . . . . . . . . . 105

6.20 測定環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.21 実験 1:シーケンス番号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.22 実験 1:スループット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.23 実験 2:シーケンス番号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.24 実験 2:スループット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.25 実験 3:シーケンス番号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

図目次 xiii

6.26 実験 3:スループット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

6.27 実験 4:シーケンス番号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6.28 実験 4:スループット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6.29 実験 5:シーケンス番号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.30 実験 5:スループット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.31 WANでの測定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.32 WAN実験 1の測定結果 (シーケンス番号の推移と喪失セグメント) . . . . . 115

6.33 WAN実験 1の測定結果 (スループットの変化) . . . . . . . . . . . . . . . . 115

6.34 WAN実験 1の測定結果 (輻輳ウィンドウ (cwnd)とスロー・スタート閾値(ssthresh)の変化) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6.35 WAN実験 2の測定結果 (シーケンス番号の推移と喪失セグメント) . . . . . 116

6.36 WAN実験 2の測定結果 (スループットの時間変化) . . . . . . . . . . . . . 117

6.37 WAN実験 2の測定結果 (輻輳ウィンドウ (cwnd)とスロー・スタート閾値(ssthresh)の変化) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

7.1 送信バッファが小さい場合のデッドロック . . . . . . . . . . . . . . . . . . 124

7.2 ネットワーク・モジュールの階層モデル . . . . . . . . . . . . . . . . . . . 125

7.3 スロー・スタートおよび，経路MTU探索によるデッドロック . . . . . . . 127

7.4 インタラクティブ・データ転送で確認応答を遅延させない場合 . . . . . . . 130

7.5 即時性を必要とするインタラクティブ・データ転送で確認応答を遅延させない場合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

8.1 提案する TCPのヘッダ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

8.2 バルク・データ転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

8.3 インタラクティブ・データ転送 . . . . . . . . . . . . . . . . . . . . . . . . 138

8.4 即時性を必要とするインタラクティブ・データ転送 . . . . . . . . . . . . . 139

8.5 ソケットと TCPのモジュール間通信の強化 . . . . . . . . . . . . . . . . . 142

8.6 実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

8.7 経路MTU探索の実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

8.8 実装 1: メッセージ・サイズとスループットの関係 . . . . . . . . . . . . . . 152




8.12 各実装における通信開始時の受信データの時間推移 . . . . . . . . . . . . . 155

8.13 経路MTU探索に関する実験 . . . . . . . . . . . . . . . . . . . . . . . . . . 157

8.14 輻輳ウィンドウ (cwnd)とスロー・スタート閾値 (ssthresh)の変化 . . . . . 157

xiv 図目次

8.15 経路MTU探索に関する実験 (経路MTUがキャッシュされている場合) . . 158

8.16 バッファ・サイズとスループット (Nagle有効) . . . . . . . . . . . . . . . . 160

8.17 バッファ・サイズと送信データ 1MSSあたりの送信パケット数 (Nagle 有効) 160

8.18 バッファ・サイズと送信データ 1MSSあたりの確認応答パケット数 (Nagle

有効) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

8.19 バッファ・サイズとスループット (Nagle無効) . . . . . . . . . . . . . . . . 161

8.20 バッファ・サイズと送信データ 1MSSあたりの送信パケット数 (Nagle 無効) 162

8.21 バッファ・サイズと送信データ 1MSSあたりの確認応答パケット数 (Nagle

無効) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

8.22 ウィンドウの途中のデータが喪失した場合 . . . . . . . . . . . . . . . . . . 164

8.23 ウィンドウの最後のデータが喪失した場合 (ウィンドウが小さい場合) . . . 164

表目次p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

2.1 TCPバッファ・サイズに対する平均スループット . . . . . . . . . . . . . . 20

2.2 測定機材と設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 評価に使用した機材と設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1 DBSの動作が確認されているシステム . . . . . . . . . . . . . . . . . . . . 85

6.2 性能測定ツールの機能の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.3 評価に使用した機材と設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.4 それぞれのツールでの測定結果 (平均) . . . . . . . . . . . . . . . . . . . . . 92

6.5 ウィンドウ・サイズ拡張オプションの評価に使用した機材と設定 . . . . . . 94

6.6 衛星回線での測定環境と設定 . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.7 ATMとルータが混在する環境の設定 . . . . . . . . . . . . . . . . . . . . . 101

6.8 FDDIの測定環境と設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.9 測定環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.10 WANの測定環境と設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

8.1 実験のパラメータ (図，表または本文中に記載されている場合を除く) . . . 145

8.2 実装 1: TCPバッファサイズとスループット・転送効率の関係 (Nagleアルゴリズムが有効のとき) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147




8.6 実装 1: TCPバッファサイズとスループット・転送効率の関係 (Nagleアルゴリズムが無効のとき) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149



xv

xvi 表目次


8.10 本提案の実装プログラムの規模 . . . . . . . . . . . . . . . . . . . . . . . . 168

PART I

研究の背景

第 1 章序論p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

この章では本論文の位置づけと意義を明らかにする．まず，近年の社会の流れとインターネットの関係について論じ，本論文の主題である TCPプロトコルの役割や位置づけについて論じる．次に，本論文で取り扱う題目について説明する．最後に，本論文の構成を述べる．

1.1 インターネットの普及と現状現在の社会は情報化社会と呼ばれている．大量の情報がコンピュータに入力され，コン

ピュータの外部記憶装置にデジタル情報として記録・蓄積される．記録・蓄積された情報は，人々の要求に応じて，検索されたり，加工されたり，表示されるなど様々な処理が行われる．もともとコンピュータは数値計算をするために誕生した．その後，数値計算だけではな

く，様々な情報を処理する処理装置としてコンピュータは進化した．太古の昔から，情報は紙などに文字や絵として記録・管理されてきた．フィルムやレコード，磁気テープなどの記録媒体が発明されてからは，これらの記録媒体にも情報が記録されるようになった．そして現代の社会では，多くの情報がデジタル化・電子化され，コンピュータで処理できる形式で記録されることが多くなった．情報をデジタル化して記録すると，複製したり長期間保存しても情報の品質が劣化しないという特長を持つ．また，コンピュータで加工や検索などの処理が簡単に行えるという利点もある．現代の社会では，コンピュータで処理しやすくするために，情報をデジタル化して記録することが増えてきている．情報がコンピュータに大量に入力されるようになると，今度は蓄積だけではなく，入力

した情報を遠く離れた場所に輸送することが求められるようになった．遠隔地間で情報の収集や交換をしたり，情報を発信したり，コミュニケーションの手段として情報のやり取りをしたいという要求が発生したのである．このような情報に対する社会的な要求の影響を受け，通信技術とコンピュータ技術は融合し，コンピュータ・ネットワークが誕生した．コンピュータ・ネットワークの登場により，たとえ遠距離間であったとしても，大量の

デジタル情報を短時間で転送したり流通させたりすることが可能になった．コンピュータのハードウェアやソフトウェア，ネットワーク機器や通信網の発達により，文字や，音声，画像，動画，そして，アプリケーション・プログラムなど，様々なデータが国境を越えて高速に転送できるようになった．このコンピュータ・ネットワークの登場により，世の中

3

4 第 1章序論

の情報はますますデジタル化され，コンピュータに入力・蓄積されるようになった．そして，コンピュータ・ネットワークの普及により，情報の多様化，複雑化，巨大化，広域化，即時化，短寿命化が進んだ．情報に対する広域化，即時化，短寿命化によって，大量の情報をコンピュータとコンピュータの間で高速に移動させることが求められるようになった．このように，コンピュータ・ネットワークは，情報化社会に大きな影響を与えるように

なった．さらにコンピュータは，ネットワークによって他のコンピュータと接続できなければ，その能力を十分に発揮することができないようになった．それだけ，コンピュータ・ネットワークは，コンピュータの能力や可能性を大きく広げる環境なのである．このような環境を提供してくれるコンピュータ・ネットワークは，高度情報化社会を支え，発展させるためのもっとも重要な基盤環境の 1つに考えられるようになった．コンピュータ・ネットワークの中でも，特にインターネットに対する社会的な感心は非

常に大きなものとなった．現在では，インターネットというと，世界中のネットワークやコンピュータを接続している単一の巨大なネットワークという意味になる．しかし，その語源は，ネットワークとネットワークを接続して，相互に通信できる環境を構築することである．現在のインターネットの起源となったARPANETは，実験・研究活動を目的として誕生した．それは，1970年ごろにパケット交換による相互接続通信を実現するために，アメリカで構築されたネットワークである [1]．しかし，1990年ごろに，インターネットの商用利用が認められるようになると，ISP (Internet Service Provider) と呼ばれるインターネット接続業者が乱立し，インターネットに接続するユーザの数が爆発的に急増するようになった．研究ネットワークと商用ネットワークは IX (Internet Exchange)によって互いに接続され，相互に自由な通信ができる環境が作られた．その結果，だれでも ISPと契約すれば，インターネットに接続している世界中の人々とコミュニケーションをすることが可能になった．商用化が進むまでは，インターネットは研究目的でありボランティア的に運用され，発展してきた．しかし現在では，商用を目的とする企業やユーザの急増により，商用ネットワークとして急成長するようになった．現在のインターネットの最大の特徴は，世界中の政府，研究機関，教育機関，非営利団

体，営利を目的とした企業や団体，そして，一般市民が自由に参加していることである．また，接続されているコンピュータやオペレーティング・システム，アプリケーション，利用目的も多種多様である．インターネット自体には，ネットワークの利用目的や使用するプロトコルに関する管理や規制をする機関や組織はなく，インターネット全体で共通となる規制事項はない．インターネットに接続する機器や，オペレーティング・システム，アプリケーションに対する制限や検定などは行われておらず，接続したい機器を自由に接続して通信や実験を行うことができる．このインターネットでは，ほとんどすべての通信でTCP/IPプロトコル群が利用されて

いる1)．TCP/IPは，インターネットのプロトコルに関する研究機関である IETF (Inter-1)TCP/IP は狭義には，TCP と IP の 2 つのプロトコルをさすが，一般的には，ARP や ICMP，UDP，

1.1 インターネットの普及と現状 5

net Engineering Task Force)によって提案され，IETFの議長らからなる IESG (Internet

Engineering Steering Group)によって標準化されたプロトコルである．インターネットでは，歴史的にTCP/IPが最も広く使われてきた．これは，そもそも，TCP/IPのようなプロトコルを研究・開発するために，インターネットが作られたことに原因がある．そして実際に，研究・開発されたTCP/IPを利用してインターネットが運用された．インターネットの多くのコンピュータとの相互通信を実現するためには，TCP/IPに対応したオペレーティング・システムとアプリケーション・ソフトウェアが必要である．それさえあれば，希望する人はだれでも，世界中の情報にアクセスすることができ，世界中へ向けて情報を発信することができるのである．今後のインターネットでもTCP/IPプロトコルが中心的に使われると見込まれている．現在では，TCP/IPやインターネット環境に対応していることを宣伝文句に掲げるパー

ソナル・コンピュータや，オペレーティングシステム，周辺機器，アプリケーション・ソフトウェアが一般家庭向けに発売されている．現在のコンピュータやネットワークの技術は，このインターネットの存在抜きには考えることはできない．現在では，ネットワーク関連製品や，汎用的なオペレーティング・システムのほとんどが，インターネットのプロトコルであるTCP/IPに対応している．次世代通信の代表といわれるATM技術 [2]やGigabit

Ethernet[3]は，TCP/IPでの利用を想定した技術開発が最も盛んに行われている．そして，実際の LANでの利用や公衆サービスでの利用も，TCP/IPの割合がほとんどを占めていると考えられる．また，パーソナルコンピュータ向けのワードプロセッサや，データベースの中には，HTML (Hypertext Markup Language) [4]に対応するものが増加している．HTMLとはインターネットでWWW (World Wide Web) による情報発信をするためのデータ形式である．インターネットが普及するまでは，ワードプロセッサというと紙に印刷するために，文書の入力と整形をするためのツールであった．それが，インターネットの爆発的な普及により，インターネットを通して情報を電子的に発信するためのツールとしても利用されるようになった．さらに，コンピュータ・メーカの間では，TCP/IPによる通信を前提とする安価なネットワーク・コンピュータ (NC: Network Computer)の開発が進められている．現在も進行しているインターネットの爆発的な普及と発展は，コンピュータのソフトウェアやハードウェアに大きな影響を与え続けている．さらに，閉じたネットワークであるはずの日本の銀行を結ぶ全銀連プロトコルも，イン

ターネットのプロトコルを利用できるようになった [5]．これは，銀行のネットワークをインターネットに接続することを意識したというよりも，安価なネットワーク機器の利用によるコストの削減や，高速ネットワークへの適用のためである．TCP/IP関連の製品は，特定のメーカや地域に限定されるような閉じた世界ではなく，広く開かれた世界で利用されている．そのため，他のネットワーク製品に比べて需要が多い．また，研究や開発も活

TELNET，FTP，HTTPなどの，インターネットで通信を行うために必要な主要なプロトコル群を意味する．

6 第 1章序論

発に行われている．その結果，性能や，品質，価格，メンテナンスなどが優れているものが多い．このように，現在では，データリンク技術も，アプリケーション・ソフトウェアも，また，コンピュータ・システムも，インターネットによる通信を意識した製品開発が数多く行われている．このような社会の流れと共に，世界中を結ぶオープンなネットワークとして，インター

ネットは世界中の人々に受け入れられていった．今では，世界中の企業や組織，家庭のコンピュータがインターネットに接続されるようになった．そして，現在のインターネットは，他に比較できるものがないほど，巨大なコンピュータ・ネットワークへと成長した．インターネットの発達により，常時，または間欠的に，世界中の多くのコンピュータがインターネットに接続されるようになった．もはや，コンピュータとネットワークは別のものだと切り離して考えることはできない時代になったといえる．コンピュータにはネットワークが必要であり，ネットワークにはコンピュータが必要なのである．現在では，インターネットは，テレビや電話のように情報をやり取りする環境として市

民権が得られたといえる．実際にインターネットのWWWや電子メールは，電話やFAX，郵便のように情報をやり取りする道具や環境として多くの人に利用されている．名刺にはインターネットの電子メールのアドレスが記載され，新聞やテレビ，雑誌などの広告にはWWWのホームページの URLが掲載されるようになった．もともとは，研究目的で始まったインターネットであるが，現在では，商業目的の利用が盛んに行われている．インターネットによる通信販売や，有料情報サービス，広告によって運営されるサービスなどが，全世界へ向けて 1日 24時間，休むことなく行われている．そして，産業や教育活動を中心として，現在の社会全体がインターネットに対して大きな需要や依存，期待をしている．もはや，インターネットは，研究ネットワークではなく，全世界を結ぶ公共の通信網としての役割を背負うようになった．情報化，国際化が進む現代社会にとって，インターネットがより便利でより使いやすくなることは，産業や，教育，一般市民の生活にとって非常に重要な意味を持つようになったのである．

1.2 インターネットを支えるプロトコルとその問題点インターネットによるデータ通信を支えている基盤技術が，TCP/IPプロトコル群であ

る．その代表が IP(Internet Protocol)[6]とTCP(Transmission Control Protocol)[7]である．IPは終点ホストまでパケットを配送する役割があり，TCPは終点アプリケーション間でデータを効率よく確実に届ける役割がある．TCP/IPの階層モデルをOSI参照モデルに対比させると，おおよそ図 1.1のようになる [8]．厳密には一致しないが，IPはネットワーク層の機能に相当し，TCPはトランスポート層の機能に相当する．この IPと TCP

という 2つのプロトコルが協力することで，相手まで届けたいデータを正しく届けることが可能になる．IPはパケットを受信ホストに届けるためにできる限りの努力をするが，届

1.2 インターネットを支えるプロトコルとその問題点 7

アプリケーション層

トランスポート層

インターネット層

ネットワークインターフェース層

�ハードウェア

TCP/UDP

IP


プレゼンテーション層

セッション層


ネットワーク層

データリンク層

物理層

ＯＳＩ��ＴＣＰ／ＩＰ

図 1.1: TCP/IPとOSIのプロトコル階層の比較

くかどうかは保証されない．これは，最善努力 (Best Effort)型のデータ配送といわれる．途中でパケットが喪失したり，順序が入れ替わったり，1つのパケットが 2つ以上に増えることも起こりうる．このような性質の IPの機能を利用して，送信したデータを終点ホストまで確実に届けるのがTCPの役割である．図 1.2のように，TCPと IPの 2つのプロトコルによって，世界中を結ぶ終点ホスト間で信頼性のある通信が可能になるのである．

TCPは，コネクション指向で，信頼性のあるストリーム型の通信を提供するトランスポート・プロトコルである．他にインターネットには，コネクションレスで，信頼性のないデータグラム型のUDP (User Datagram Protocol)[9]というトランスポート・プロトコルもある．現在のインターネットの主要なアプリケーションであるWWWや電子メール，ファイル転送プロトコルでは TCPが利用されている．そのため，インターネットを流れるトラヒックの大部分を TCPが占めている．また，インターネットは，様々な性能や特性を持つデータリンクで構成される．そのため，インターネットを使いこなすためには，どのような環境であったとしても，アプリケーションにとって必要とされる性能を TCP

が提供できなければならない．終点ホスト間でネットワークの性能を使いこなせるかどうかは，このTCPの性能にかかっている．TCPをよりよくすることが，インターネットの有効利用や，インターネットの利用の可能性を広げる鍵の 1つになっている．しかし，現在のインターネットは，TCP/IPプロトコルが作られたときに想定されてい

た環境とは大きく異なっている．急激なホスト数の増大，ネットワークの広帯域化や高速化，多様なデータリンクの登場，そして，アプリケーションのインタラクティブ化や扱われるデータのマルチメディア化が進んだ．その結果，現在のインターネットは，TCP/IP

プロトコルが設計された時に想定されていたプロトコルの適応範囲から逸脱しつつある．1980年代前半に標準化された IPは，実験ネットワークを結ぶプロトコルとして開発さ

れたものである．そのとき IPは，全世界を結ぶ巨大な単一のネットワークを動かすプロ

8 第 1章序論

TCP

IP IP IP

Router RouterHost Host

Application

TCP

IP

Application

Interface InterfaceInterface Interface

図 1.2: TCP/IPの機能

トコルとして設計されたわけではなかった．現在のような巨大なインターネットではなく，もっと小さなネットワークで運用することを想定して設計されたのである．ところが社会の流れは，コンピュータ・ネットワークによって全世界を早急に結ぶ方向に動き，実験ネットワーク用の IPを運用ネットワーク用のプロトコルに修正する暇を与えてはくれなかった．そして，インターネットに接続される組織やホスト数が急速に増加し，IPアドレスが足

りなくなるという大きな問題が発生した．インターネットに接続するコンピュータには，他と重複しない IPアドレスを必ず設定しなければならなない．IPアドレスが不足すると，それ以上の数のコンピュータをインターネットに接続できないことになる．この問題の原因は，IPアドレスの利用効率が悪いことと，IPアドレスそのものの物理的な数が足りないという 2つの側面があった．この問題を根本から解決するためには，現在や将来のインターネットに適すように IPプロトコルを作り直さなければならない．しかし，新たなIPプロトコルの標準化作業と実装，そしてそれをインターネット全体へ普及させるためには長い時間がかかると予想された．このため，次世代の IPプロトコル (IPng: IP Next

Generation)の標準化作業と共に，標準化され普及するまでの間，現在の IPの寿命を延ばすための短期的な解決策が提案された．限られた IPアドレスをできるだけ有効に使うために，CIDR (Classless interdomain routing) [10]が提案され，施行された．また，LAN

内の IPアドレスとグローバル・インターネットの IPアドレスを別々に管理し，動的に変換することで，少ないグローバル IPアドレスでたくさんのホストをLAN内に収容できるNAT (Network Address Translator) [11] という技術が提案され実用化された．このように，運用や新しい技術によって，現在の IPの寿命を長くする研究が行われ実現されてきた．そして，実際に，これらの技術により，IPの寿命は大幅に延びるようになった．

IPの問題を根本的に解決するための次世代 IP(IPng: IP Next Generation)の標準化活動も活発に行われている．1995年には次世代の IPとして，IPv6(IP version 6)のプロト

1.2 インターネットを支えるプロトコルとその問題点 9

コルの仕様が提案標準 (Proposed Standard)として決定された [12]．さらに，実際に IPv6

を利用して実験を行う実験ネットワークが構築され，現在，徐々に接続されるホストの台数を増加させている [13]．しかし，運用上の問題をよりよく解決するため，IPv6の最初の提案標準は廃案 (Historic)となった．そして，IPv6の新しい仕様である IPv6 spec 2が策定され，まもなく提案標準になる見込みである．今後は，IPv6の実験ネットワークを拡大しながら，IPv6の仕様や運用上の問題点を解決し，現在の IPv4から IPv6への移行作業が本格化する日がくると期待されている．インターネットの運用を通して，TCPにも問題があることが明らかになった．実際に

TCPを利用してデータ転送を行うと，ネットワークの資源を有効に利用できない場合があるという問題が発見された．また，ネットワークの広域化，広帯域化が進むにつれて，TCPでは高スループットが得られないという制限が問題視されるようになった．このため，TCPにはいくつかの仕様の追加や，オプション機能によるプロトコルの拡張が行われた．また，TCPの問題を根本的に解決するために，次世代の TCP (TCPng: TCP Next

Generation) に関する標準化活動をスタートさせるべきだという意見もある [14][15]．しかしまだ，IETFではこのような活動は行われていない．それは，TCPには IPのような致命的な欠点がないことと，TCPをどのように作り直したら欠点がないプロトコルになるか，という問いに対する決定的な解が得られていないからである．また，TCPの拡張機能の中には，ウィンドウ・サイズを拡大するオプション [16]や，選択確認応答 (SACK:

Selective Acknowledgment) [17]など，インターネット上で十分にテストされていない機能がある．これらの機能の有効な利用法が明らかになっていないにもかかわらず，次世代のTCPを標準化しても意味がない．これらの機能を有効に生かすように次世代のTCPを設計しなければ，結局その次世代の TCPを再び作り直さなければならなくなる可能性がある．TCPに加えられた拡張機能を実際にインターネットで利用し，実験と運用を繰り返しながら経験を積み，TCPをどのように改善して行くべきか追究する必要がある．この過程を踏まずに次世代の TCPを提案することはできない．また，提案されている機能拡張だけではなく，現在の TCPで改善できるところまで改

善することも必要である．インターネット全体に新しい TCPプロトコルを普及させることは非常に難しく，普及させるためには，現在の TCPでは絶対にだめだという決定的な証拠が必要である．そして，その問題点を明らかに解決できるプロトコルでなければインターネットに受け入れられるものではない．もともとインターネットでは，動くプロトコルを目指して研究・開発が行われてきた．プロトコルの実装と実験，運用が重視され，これらを通してプロトコルが開発されてきた．このようなプロトコルの実装と実験，運用活動なしに TCPを改善することはできない．現在の TCPを改善する努力を行い，実際に提案を実装してデータ転送実験を行い，知識や経験を得ることが大切なのである．このような理由により，利用者によりよいインターネット環境を提供できる次世代の TCPを作るためには，現在の TCPからより多くの事を学び取る必要がある．

10 第 1章序論

本研究では，TCPのプロトコルや実装の問題点や意義を重要視し，現在のTCPからより多くを学び，TCPを改善することで，インターネットをよりよい環境にするために次の研究を行う．アプリケーションの通信をモデル化し，それぞれの通信モデルでの TCP

の挙動を明らかにする．また，TCPの実装の検査や，性能を測定するツールの必要性について考察する．そして，TCP性能評価ツールDBSの提案と実装，評価を行う．さらに，現在の TCPに残されている大きな問題である TCP短期デッドロック問題について議論し，その解決法の提案と実装，評価を行う．

1.3 本論文で取り扱う題目1.3.1 TCPのデータ転送モデルと実装モデル

現在のインターネットで使われているTCPは，TCPのプロトコルの仕様が決められたときと全く同じものが使われているわけではない．実際に，様々な環境で様々なデータ転送が行われるようになると，TCPには問題があることが明らかになった．この問題を改善するために，TCPの仕様や実装には追加や変更が行われた．具体的には，Nagleアルゴリズム [18]や遅延確認応答 [19]，スロー・スタート [20]などである．これらの仕様の追加・変更によって，TCPには，低遅延データ転送と，高スループット・データ転送に対応しながら，ネットワークとホストの負荷を減らしたり，トラヒック量を調整したりする機構が備えられるようになった．この機能は，TCPの上位層や下位層の設計や実装，および，今後の TCPの拡張を考える上で基本となる性質を形作っている．現在の TCPについてより細かく知るには，この TCPの性質を細かく分析しモデル化

して考えることが大切である．そして，TCPに変更を加える場合には，TCPのデータ転送モデルの特徴と性質について十分に理解し，このモデルを改悪しないように考慮する必要がある．また，次世代の TCPを設計するときには，この TCPの特徴を生かすように設計しなければ意味がない．このように，TCPの機構の分析は，現在のTCPの問題点の解決や，次世代 TCPの設計をするときに重要な情報となる．また，TCPの問題点に関する改善を試みる場合には，ネットワーク・プロトコルの階

層化について考慮すべきである．すべての機能を TCPに実装することは間違っている．TCPで解決すべきことと，下位層で解決すべきこと，上位層で解決すべきことを分離して考える必要がある．実際に現在の TCPの実装は，下位層や上位層にいくつかの仮定をしている．このため，現在のTCPの問題点を分類して，TCP自体に残された課題と，TCP

で処理するのではなく，TCPの上位層や下位層で実装されることが想定されている課題について分けて考える必要がある．本論文では，アプリケーションのデータ転送をモデル化し，それぞれのモデルで TCP

がどのような挙動をするかを示す．そして，TCPはスループットや応答性を犠牲にする

1.3 本論文で取り扱う題目 11

ことなく，ネットワークやホストの負荷を低減する仕組みを持っていることを明確にする．また，ネットワーク階層モデルにおける TCPの実装モデルについて分析する．そして，TCPで解決しなければならない問題点と，上位層で解決しなければならない点，下位層で解決しなければならない点を明確にする．TCPの拡張や改善を行う場合には，これらのデータ転送モデルと実装モデルを重視して設計する必要がある．

1.3.2 TCPの実装検査と性能評価

インターネットには実装を検査する組織や機関は存在しない．そのため，インターネットには不具合 (バグ)のある機器や実装が接続されていることが少なくない．インターネットにはプロトコルの実装に関する検定制度はなく，利用者はメーカが内部で行っているテストを信用するしかない．しかし，インターネットのプロトコルの中でも特に TCPの実装は複雑であり，TCPのすべての機能を実装者が各自でテストすることは非常に難しいことである．このため，TCP/IPの実装者やネットワークの構築・運用者は，TCP/IPの評価を十分に行っていないのが実情である．また，ネットワークのプロトコルは，OSI参照モデルに象徴されるように階層化されて

仕様が決められる．実装はそれぞれの階層単位で行われたり，さらにそれらを細分する形で実装されることが多い．しかし，このような階層化を行うと，あるプロトコル階層の仕様や実装の変更が，別の階層のプロトコルに悪影響を及ぼすことがある．

TCPや IPのプロトコルスタックは階層化されて仕様が決定され，ほとんどの実装でTCPと IPを実現するモジュールは分離されて実装されている．例えば，現在，IP Version

6に関する仕様の決定と実装作業が行われているが，基本的には TCPの仕様は変更されない予定である．TCPと IPの実装が分離されていれば，IPv6の実装が多少なりとも楽になる効果があると考えられる．しかし，IPの変更はTCPへの新たな問題を発生させる危険性がある．実際に，TCPの上位層や下位層のプロトコルや実装がTCPの挙動に影響し，データ転送の性能を悪化させる場合が知られている．このことから，TCPを改善したり，TCPの下位層や上位層に変更が加えられた場合には，階層モデル全体を通して問題が発生しないかどうかを検証する必要がある．本研究では，これらの問題を解決する手段として，TCPの実装の検証や認定を行うシ

ステムの必要性について論じる．また，IPの機能拡張であり，IPv6では多くの実装で取り入れられる見込みである経路MTU探索 (Path MTU Discovery)が，TCPによるデータ転送を悪化させる場合があることを明らかにする．さらに，経路MTU探索を実装したことが原因とみられるTCPの実装の不具合に関する測定データを示し，TCPの実装検査システムの必要性を明らかにする．そして，経路MTU探索を中心とした TCPの実装検査システムを提案する．また，通信の性能は，通信方式やアルゴリズムだけで決まるものではない．現在のTCP

12 第 1章序論

はソフトウェアで実現されており，TCPの実装方式やオペレーティング・システムの実装が TCPの性能に深く関係している．また，ネットワークを中継するルータなどの機器の性能も大きく影響を及ぼす．このため，TCPの性能改善を提案する場合には，シミュレーションによる結果だけでは不十分であり，実際に実装して評価することが必要である．しかし，実装ベースで TCPの性能を総合的に評価できるシステムが存在しなかった．そこで，本研究では，TCPの性能評価ツールに求められる機能の分析を行う．そして，

ネットワーク・システムやTCPの性能を総合的に評価するためのシステムとして，DBS

(Distributed Benchmark System)を提案する．さらに，DBSの実装と評価，DBSによる性能測定実験の結果を示し，DBSの有効性を明らかにする．

1.3.3 TCP短期デッドロック問題

TCPには，Nagleアルゴリズムやスロー・スタートというデータの送信を抑制する機構と，遅延確認応答 (Delayed ACK)という確認応答を遅延させる機構が備えられている．これらの処理がうまくかみ合わなくなると，ある期間，データの転送が停止することがある．具体的には次の状態になる．本論文ではこの状態になることを，TCPデッドロックと呼ぶ．

• 送信ホスト

続けて送信すべきデータがあるが，前に送信したセグメントに対する確認応答を受信するまで，データを送信しない

• 受信ホスト

確認応答していない受信セグメントがあるが，さらにデータを受信しないと確認応答しない

この状態は，遅延確認応答処理で確認応答が遅延される期間続く．この上限は 0.5秒に決められている [21]．BSDの実装を基にした多くの実装では，確認応答の遅延時間は最大0.2秒間であり，デッドロックは最大 0.2秒続く．そのため，この問題が発生すると，データ転送に 0.2秒程度の遅延時間が加えられる．環境によっては，この現象が繰り返し発生する場合がある．そうなると，データが約 0.2秒間隔で転送されることになり，100Mbps

以上の帯域をもつネットワークでデータを転送しても，1Mbps以下のスループットしか得られなくなる．つまり，広帯域・高速ネットワーク環境を構築したとしても，このデッドロック問題が発生すると，期待される性能が得られなくなる．また，この問題は一般にはあまり広く知られておらず，この問題が起きていても分からない場合がある．TCP短期デッドロック問題を理解している人が，ネットワーク中を流れるパケットを測定した結果を分析しなければ，この問題が発生しているかどうかを判断するのは難しい．ユーザに

1.4 本論文の構成 13

とっては，ネットワークが遅く感じるだけであり，TCPの不具合なのか，ネットワークの性能なのか，ネットワークの混雑なのかを区別することはほとんど無理である．結果として，データリンクの性能に見合う効果が得られないため，広帯域性を必要とするアプリケーションが動作しなかったり，利用者の間にネットワークに対する不信感が募ったり，応答性の低下により生産性が落ちたり，パフォーマンスの改善のために無駄な時間を浪費したりする原因になりかねない．

TCP短期デッドロック問題の一部の問題については，ある程度までなら運用ベースで解決することができる．つまり，ネットワークの設計者や管理者が，TCPの動作の細かい点まで考慮してネットワークを設計したり，それぞれのホストの TCPの設定を変更すれば，TCP短期デッドロック問題による性能低下が起こりにくい環境を構築することは不可能ではない．しかし，TCPの細かい特性を考慮しなければ，よりよいネットワークを構築できないならば，それは，ネットワーク構築者への大きな負担となる．また，ネットワークの設計ミスの原因にもなりやすい．しかも，ネットワークは部分的に発展や拡張が行われるため，TCPの特性にあった設計をネットワーク全体で統一的な行うことはかなり難しい．インターネット全体となれば不可能なことである．インターネットは，利用者にとっても，管理者にとっても，できるだけ自動的に動作す

るネットワークになることが望まれている [22][23]．そのため，IPv6ではプラグ＆プレイの機能が実装される見込みである [24]．TCPも同様にプラグ＆プレイの機能が実現されることが望まれる．つまり，TCPのパラメータを熟練者が調整しなくても，いつでも高性能に動作することが望まれる．そのために，TCP短期デッドロック問題は，運用ベースではなく，TCPプロトコルとして解決しなければならない問題といえる．このような理由から，この TCP短期デッドロック問題は解決しなければならない重要

な課題といえる．しかし，現在までに，副作用のない効果的な解決策は提案されていない．本論文では，副作用がなく，デッドロック問題を根本的に解決できる方法を提案する．本提案を，実装し，実験した結果について報告し，本提案の有効性を証明する．

1.4 本論文の構成本論文では，TCPの性能を改善するために，プロトコルの仕様や実装について焦点を当

て，次の議論を行う．まず，今までに行われてきたTCPの仕様の変更と，その結果形成されたデータ転送モデルについて説明する．次に，TCP自体に残されている課題と，TCP

の上位層や下位層で解決されることが想定される課題について論じる．さらに，TCPの上位層や下位層のプロトコルや実装によっては，TCPの動作に悪影響を与えることを例を挙げて説明する．そして，これらのことから，TCPの性能評価の重要性と，TCPの実装を検証するツールの必要性について論じる．さらに，理想的な TCPの性能評価手法について論じ，多点間による通信性能の評価を可能にする TCP性能評価ツール DBSを提

14 第 1章序論

案する．そして，評価とDBSによる実験結果を示し，DBSの能力と得られる効果を示す．さらに，TCP短期デッドロック問題の解決策を提案する．提案する解決策を実装し，検証実験を行った結果について述べ，本論文の提案の有効性を証明する．

第 2 章 TCPの性能に関する研究とTCPの拡張p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

インターネットでは，TCPとUDPという 2つのトランスポート・プロトコルが利用されている．TCPはコネクション指向で信頼性のあるストリーム型の通信を提供し，UDP

はコネクションレスで信頼性のないデータグラム型の通信を提供する．TCP/IPプロトコルは，この 2つのトランスポート層を提供するという設計思想に基づいて研究・開発が行われた [25]．現在のインターネットのトラヒックのほとんどすべてが，この 2つのプロトコルで占められている．このため，この 2つのプロトコルは，インターネットにとって必要最小限のトランスポート・プロトコルということができる．現在のインターネットの成功を考えれば，TCPとUDPという性質の異なる 2つのトランスポート・プロトコルを提供した思想には大きな誤りはなかったといえる．

TCPは，データ転送に信頼性が必要となるアプリケーションで利用される場合が多い．特に，データの転送量の多い場合に TCPが利用される．このため，インターネットのトラヒックの大部分は TCPによって占められている．今後のインターネットでは，データリンクの高速化や，広帯域化，多様化，ホスト数の増加によるさらなる巨大化や複雑化が進むことが考えられる．インターネットを有効に利用できるかどうかは，TCPがこれらのネットワークに適応できるかどうかにかかっているといえる．だから，将来のインターネットの可能性を広げたり，ネットワークを有効に利用するためには，TCPをよりよくする必要がある．このような理由により，TCPに関する研究が数多く行われている．インターネットで現在運用されている TCPは，RFC793 [7]で定義されている初期の

TCPの仕様をいくつか変更している．変更された機能のうち，標準 (Standard)になっている機能はRFC1122 [21]で定義されている．RFC1122で定義された機能には，Nagleアルゴリズム [18]やスロー・スタート [20]，遅延確認応答 (Delayed Acknowledgment)[19]などの処理がある．これらの機能は，実際のネットワーク環境でRFC793のTCPを運用した結果，問題があることが分かったために追加された機能である．また，TCPを広帯域ネットワークへ対応するための機能として，現在，標準提案になっている機能がいくつか存在する．具体的には，ウィンドウ・サイズの拡張オプションとタイムスタンプ・オプション [16]，高速再送制御 (Fast Retransmission)と高速回復制御 (Fast Recovery)[20]，選択確認応答 (SACK: Selective Acknowledgment)[17]がある．この章では，TCPの性能を改善するために標準に加えられた機能や，TCPの性能改善に関する研究を中心にまとめる．

15

16 第 2章 TCPの性能に関する研究と TCPの拡張

送信データ

ACK

送信ホスト受信ホスト

送信バッファ受信バッファ

ヘッダデータ

ヘッダ

図 2.1: シリー・ウィンドウ・シンドローム

2.1 データ転送の効率を向上させる研究初期のTCPは，信頼性を提供するための機構を備えるだけで，ネットワークを共有した

ときに問題となる輻輳の回避や，データ転送の効率を向上させる仕組みが十分ではなかった．実際のネットワークでTCPを運用したところ，初期のTCPの単純なウィンドウ・フロー制御には問題があることが判明した．図 2.1のように，1つのパケットに含まれるデータの割合が極端に小さなパケットが，大量にネットワークに送信され，ネットワークの利用効率を極端に低下させるという問題が発生したのである．極端にいうと，ネットワークの帯域がデータではなく，プロトコル・ヘッダによって埋め尽くされるという現象である．こうなると，ネットワークの負荷は異常なほど高くなるが，ネットワークの利用効率が極端に悪化するため，スループットは極端に低下する．この問題は，ウィンドウ・フロー制御特有の問題であり，シリー・ウィンドウ・シンド

ローム (SWS: Silly Window Syndrome)と呼ばれる．シリー・ウィンドウ・シンドロームとは，受信ホストが，受信可能なウィンドウが大きくなるのを待たずに確認応答を送信し，送信ホストがその小さなウィンドウに合わせて小さなデータ・パケットを送信した場合に発生する．この現象がいったん発生すると，データ転送が終了するまで続く可能性がある．そうなると，長時間にわたってネットワークの利用効率が極端に低下することになる．しかもこの問題は，シリー・ウィンドウ・シンドロームを発生させているホスト間の通信性能の低下だけではなく，同じネットワークを共有する他の通信にも悪影響を及ぼす．そのため，解決しなければならない大きな問題であった．シリー・ウィンドウ・シンドロームの発生を防ぐため，TCPには細かい制御機構が組み

込まれることになった．

• 送信時に，小さなパケットの送信を抑制する．(Nagleアルゴリズム)

• データセグメントを受信しても，すぐには確認応答をせず，遅延させる．(遅延確認

2.1 データ転送の効率を向上させる研究 17

応答)

• 受信可能なウィンドウの大きさが小さい場合には，確認応答パケットによって通知するウィンドウの大きさを 0にする．

これを順番に説明する．

2.1.1 Nagleアルゴリズム

TCPは通信開始時に最大セグメント長 (MSS: Maximum Segment Size)を決定する．LANの場合には，データリンクの最大転送単位 (MTU: Maximum Transmission Unit)から，IPやTCPのヘッダの大きさを引いた値を，最大セグメント長と定義する．送信するデータの量がMSSを超える場合には，データの送信時にMSS単位に分割されて送信される．WANの場合，TCPでは 536または 512byteを最大セグメント長と定義する [26] 1)．

Nagleアルゴリズムでは，1つのパケットに含まれるデータの量が，1MSS未満のパケットを小さなパケットと定義する．そして，確認応答されていない送信済セグメントがある場合には，小さなパケットを送信しないように制御する．このため，パケットが往復する間に，最大 1つしか小さなパケットを送信しなくなる．その結果，ネットワークの利用効率を向上させることができる．ただし，Nagleアルゴリズムを利用すると，小さなデータは集められてから送信されるため，遅延時間が発生する可能性がある．これを避けるため，ウィンドウ・システムや機械制御など，即時性が求められるアプリケーションではNagle

アルゴリズムは無効に設定される．

2.1.2 遅延確認応答

遅延確認応答は，データを受信してからすぐに確認応答をせず，ある一定の条件の下で確認応答を遅らせる仕組みである．これは，シリー・ウィンドウ・シンドロームを解決するためにTCPに取り入れられた．データを受信した後ですぐに確認応答すると，シリー・ウィンドウ・シンドロームが発生する可能性がある．だから，確認応答を遅延させれば，シリー・ウィンドウ・シンドロームの発生を防ぐことができる．データを受信すると受信した分のデータがバッファに格納される．このため，受信バッ

ファにデータが格納された直後に確認応答をすると，通知するウィンドウは受信したデータの分だけ小さくなる．現在の多くの TCPの実装では，データがいったん TCPの受信バッファに格納されると，そのデータがアプリケーションに渡されるまでTCPのバッファは解放されない．そのため，受信したデータがアプリケーションに渡される前に確認応答を送信すると，そのデータのサイズ分だけウィンドウが小さくなる．しかも，確認応答の

1)IPに経路MTU探索が実装されていない場合．経路MTU探索が実装されている場合は 4.3.1節を参照．


処理が終わるまで，受信バッファに格納されたデータをアプリケーションに渡すための処理ができなくなる．さらに，送信ホストからは，ウィンドウの最大サイズまでパケットが送信されてくる可能性がある．受信バッファに格納されているデータを速やかにアプリケーションに渡さなければ，送信されたデータで受信バッファがすべて埋まってしまい，新たなデータを受信できなくなり，スループットが低下することになる．このような理由で，確認応答を遅延させない場合には，シリー・ウィンドウ・シンドロームが発生する可能性が高くなる．発生しなかったとしても，確認応答処理のためにホストのCPU負荷が高くなり，スループットの低下をもたらす原因になる．受信バッファのデータをアプリケーションに渡し受信バッファが大きくなってから確認

応答すれば，シリー・ウィンドウ・シンドロームは発生しない．これを実現する機能として，遅延確認応答 (Delayed Acknowledgment)が提案された．現在では，この機能は実装することが強く奨励されており，ほとんどすべてのシステムで実装されている．

RFC1122では遅延時間を 0.5秒以内にしなければならないことと，2つのフルサイズのセグメント (2MSS) を受信したときに遅延なく確認応答を返送しなければならないことが決められている．遅延時間の上限が決められているのは，遅延時間を長くすると，送信したデータが受信ホストに到達しているにもかかわらず，送信ホストがデータを再送する危険があるからである．この遅延確認応答は確認応答パケットの数を減らす役割も持っている．その結果，ネットワークやホストの負荷を軽減する性質がある [19]．

2.1.3 受信可能なウィンドウの通知

受信可能なウィンドウの大きさが 0になった場合にはウィンドウ・サイズを 0と通知する．ただし，その後，受信可能なウィンドウが少しできてもウィンドウ・サイズの通知はしない．確認応答を通知しなければならない場合には，ウィンドウの大きさを 0と通知する．そして，受信バッファに格納されていたデータがアプリケーションに渡され，受信バッファの 25%～50%，または，1MSS～2MSS以上のデータが受信可能になった場合に，そのとき受信可能なウィンドウを通知する．この仕組みにより，受信ホストは送信ホストに小さなウィンドウを通知することがなくなり，シリー・ウィンドウ・シンドロームを避けることができる．

2.2 TCPの実装の問題と改善に関する研究2.2.1 データ転送の効率を向上させる仕組みの問題

Comerらの研究により，Nagleアルゴリズムや遅延確認応答の機能には，副作用があることが明らかになった [27]．Comerらは，図 2.2に示すようなにATMスイッチに接続された 2つのホスト間で，バッファ・サイズに着目しながらデータ転送を行い，そのときの

2.2 TCPの実装の問題と改善に関する研究 19

ATM SwitchASX-100(Fore Systems)

Host A Host B

SPARCstation IPC SPARCstation IPC(Sun Microsystems)(Sun Microsystems)

10Mb/s Ethernet

100Mb/s100Mb/s

SBA-200Adapter

SBA-200Adapter

図 2.2: Comerらの実験の測定環境

スループットを測定した．データ転送および，スループットの測定には ttcpを利用した．Comerらによって得られた結果を表 2.1に示す．この結果から，送受信のバッファ・サイズの組み合わせによっては 20Mbps前後のスループットが得られていることが分かる．しかし，スループットが 0.3～1Mbps程度という小さな値の領域が存在する．傾向としては，送信バッファが小さく，受信バッファが大きい部分でのみこの現象がみられる．これはTCP

の送受信のバッファの大きさが最大転送単位 (MTU: Maximum Transmission Unit)の 3

倍以下の場合に，次のような状態になることがあるからである．

送信ホスト · · · 確認応答パケットが到着するまでデータを送信しない受信ホスト · · · データが到着するまで確認応答パケットを送信しない

(遅延確認応答をする)

この状態になると，受信ホストの遅延確認応答の制限時間が解除されるまでデータは送信されなくなる．Commerらが実験に使用したオペレーティング・システムである Sun

OS 4の実装では，遅延確認応答は 0.2秒間隔のファスト・タイマで解除される．このため，確認応答は 0.2秒間遅れることになる．その結果，約 0.2秒ごとに，2MSS未満のデータしか送信されなくなり，スループットが極端に低下する．このようなことが起きるため，100MbpsのATMリンク間でも 1Mbps以下のスループットしか出ない場合がある．この副作用は，特に ATMなどの大きな最大転送単位 (MTU:Maximum Transmission

Unit)を持つデータリンクで問題になる．Ethernetでも特殊な設定をするとこの副作用が起きるが，TCPのバッファの大きさは Ethernetなどのデータリンクを基準にして値が決定されていたためこの問題が明らかになっていなかった．しかし，Ethernet用に設定されているバッファの大きさのままATMを利用するとこの副作用が発生する可能性がある．なお，この問題に関しては，Moldeklevらによって細かい調査が行われた [28]．そして，

Moldeklevらは，このデータ送信が停止する状態のことを論文の中でデッドロックと呼んだ．本論文ではMoldeklevらの用語に従い，この状態のことをデッドロックと呼ぶことに


表 2.1: TCPバッファ・サイズに対する平均スループット受信バッファサイズ (octet)

16K 20K 24K 28K 32K 36K 40K 44K 48K 51K送 16K 15.05 13.60 0.322 0.319 0.319 0.467 0.469 0.466 0.469 0.469信 20K 15.99 14.60 15.07 14.87 15.40 14.24 1.095 1.095 0.548 0.549バ 24K 17.71 16.79 16.74 16.32 17.40 17.31 17.42 17.12 0.760 0.740ッ 28K 16.57 17.69 17.93 18.13 18.36 19.20 19.74 19.78 18.38 18.20フ 32K 14.63 18.96 18.42 19.23 19.14 19.74 19.96 20.31 19.69 19.17ァ 36K 14.33 19.22 18.12 19.82 19.77 19.92 20.56 20.49 20.13 20.20サ 40K 15.16 19.34 18.85 19.73 20.11 20.41 20.81 20.74 20.69 20.57イ 44K 14.80 19.40 18.27 20.39 20.16 20.74 20.99 20.87 20.89 20.70ズ 48K 14.62 19.46 18.34 20.48 20.26 20.41 20.85 20.83 20.93 20.83

(octet) 51K 13.92 19.41 18.26 20.50 20.06 20.21 20.88 20.91 21.21 21.06

する．ただし，デッドロックという用語を使うと，データの送信が完全に停止するうというニュアンスが含まれる．しかし，TCPのこの現象は永久に続くわけではなく，微少時間経過すると解除される．そのため，微少時間で解決されることを強調するときには，短期デッドロックと呼ぶことにする．

2.2.2 メモリ管理機構，コンピュータ・アーキテクチャの問題

Luckenbachらは送信メッセージの大きさに着目してデータ転送のスループットを測定し，オペレーティング・システムのメモリ管理機構や，コンピュータのハードウェア・アーキテクチャの特性がスループットに大きな影響を与えることを明らかにした [29]．送信メッセージのサイズとは，1回のwriteシステムコールでカーネルへ渡すデータの byte数を意味している．本研究ではLuckenbachらが行った実験を再実験した．測定に使用した環境を図 2.3に示

す．使用した装置を表 2.2に示す．実験はNetperfを利用し，メッセージ・サイズを 4byte

から 9188byteまで 1byte単位で変化させ，10秒間データを転送したときのスループットを測定した．結果を図 2.4，図 2.5，図 2.6に示す．結果は 1回の測定結果をそのままプロットしたものであり，特別な統計処理は何もしていない．まず図 2.4を見ると，メッセージ・サイズが 0に近い時はスループットが極端に小さい

が，メッセージ・サイズが大きくなるにしたがってスループットが大きくなる傾向がみられる．これはメッセージを送信するためのシステムコールの回数が関係している．同じ大きさのデータを送信する場合，メッセージ・サイズが小さければ小さいほどシステムコールの回数は多くなる．逆に，メッセージ・サイズが大きくなればなるほどシステムコールの回数は減る．システムコールの回数が多くなると，カーネルモードとユーザーモードの切


り替え回数が多くなり，これがオーバーヘッドとなる．そのためスループットが低下する．また，図 2.4のスループットの値には，メッセージ・サイズの大きさで512byte～1024byte

ごとの不連続性がみられる．これはオペレーティング・システムのメモリ管理が関係している．BSD系のUNIXでは，ネットワークによる通信ではmbufとよばれるメモリバッファが利用される [30]．mbufには 2種類ある．1つは cluster mbufと呼ばれるもので 1kbyte2)の大きさをもつ．もう 1つは small mbufと呼ばれるもので 112byteの大きさをもつ．small

mbufの領域の取得と解放にはかなりのオーバーヘッドが必要である．そのため，small

mbufを使う数が多くなればなるほどオーバーヘッドが大きくなる．図 2.5のスループットの値には，112byteごとの不連続性がみられる．これは small mbuf

の大きさと一致する．112byte増えるたびにスループットが段階的に低下している．これは，small mbufの操作に必要となる処理のオーバーヘッドに深く関係している．アプリケーションのメッセージ・サイズが 512byte 3)以下の場合には，1つまたは複数の small

mbufに送信データが格納される．この small mbufの利用数が多ければ多いほど，mbuf

の操作に必要となる処理のオーバーヘッドが大きくなりスループットが低下する．また，アプリケーションのメッセージが 512byteを超えると cluster mbufが利用される．cluster

mbufはオペレーティングシステムのメモリ管理機構で利用されるページ単位で処理されるため，cluster mbufの操作に必要となる処理は軽い．このため，small mbufを利用する場合に比べて，cluster mbufを使った方がスループットが向上する．また，図 2.6をみると，メッセージ・サイズが 4で割り切れるバイト数の時にはスルー

プットが大きく，4で割り切れないバイト数の時にはスループットが小さくなっていることが分かる．これはCPUのメモリアクセスのアーキテクチャが関係している．CPUがメモリ・セルへアクセスする時，32bit RISCコンピュータでは 32bitごとのアクセスは高速に行えるが，32bit単位でアクセスできないバイト数の場合には余分な処理をしなければならない．そのため，メッセージ・サイズがメモリ・セルの境界単位か，そうでないかによってスループットが大きくなったり小さくなったりするのである．以上のことから，TCPを利用したアプリケーションを作成する場合には，オペレーティ

ング・システムのメモリ管理機構や，コンピュータのアーキテクチャを考慮したプログラムを作らなければ，高いスループットが得られないことがわかる．これは，プロトコルの階層化やオペレーティング・システムの目的である「利用者やプログラマからハードウェアやネットワークの特性を隠す」ことができていない例だといえる．なおこのような特性は，TCPだけではなくUDPもmbufを利用するため同じような特性がある [31]．

IPv6では，このようなコンピュータの特性を考慮して，IPヘッダの構造や，IPオプションを 8byte単位で処理できる構造に決められた．これは，レジスタやデータバスが 64bit

の CPUを考慮したためである．

2)SunOS4.1.3の場合．BSD/OS 2.0.1の場合は 2kbyte．3)この値は SunOS4.1.3の場合である．BSD/OS2.0.1の場合は 209byteである．OSによって値は異なる．


100Mbps100Mbps

ATM Switch Host2Host1

図 2.3: Luckenbachらの実験の再実験に使用した環境

表 2.2: 測定機材と設定CPU SPARCstation10(Sun Microsystems)OS SunOS 4.1.3ATM Switch ASX-100 (Fore Systems)AAL Type AAL5MTU 9188octetバッファ・サイズ 52428byte測定ツール Netperf

0

10

20

30

40

50

60

70

0 1024 2048 3072 4096 5120 6144 7168 8192

Thr

ough

put [

Mbp

s]

Message Size [byte]

図 2.4: 送信メッセージサイズとスループットの関係


40

45

50

55

60

3072 3184 3296 3408 3520

Thr

ough

put [

Mbp

s]

Message Size [byte]

図 2.5 送信メッセージサイズとスループットの関係 (拡大図その 1)

45

50

55

60

65

4032 4036 4040 4044 4048 4052 4056 4060 4064

Thr

ough

put [

Mbp

s]

Message Size [byte]

図 2.6 送信メッセージサイズとスループットの関係 (拡大図その 2)


2.2.3 ネットワーク・モジュールの階層化の問題

Jon Crowcroftらは，データ転送の実験から送信するメッセージ・サイズの大きさによっては，データ転送が著しく低下する場合があることを発見し，調査を行った．そしてTCP

のバッファ管理とソケットのバッファ管理の間に，矛盾する部分があることが原因になっていることを明らかにした [32]．本研究で，同じ現象に関する測定を行った．図 2.7に示すような環境で，表 2.3に示す機材と設定で測定した．測定は，メッセージ・サイズを 4byte

から 2000byteまで 1byte単位に変化させ，10秒間データを転送したときのスループットを計測した．結果を図 2.8に示す．なお，結果は 1回の測定結果をそのままプロットしてあり，統計処理は何もしていない．図 2.8をみると，メッセージ・サイズが約 200～600byteの時に極端にスループットが小

さいことがわかる．この原因は，TCPのバッファ管理機構とソケットのメモリ管理機構の間の処理に矛盾する部分があるためである．ソケットとは，アプリケーションプログラムと TCPの間でデータの橋渡しをする役目を担っている．アプリケーションはソケットと通信をすることにより，TCPの機能を利用することができる．ソケットはアプリケーションから TCPへの要求を受け付けたり，バッファなどのメモリ管理を行う．ソケットとTCPは同じmbufにデータを格納し制御している．しかし，mbufに格納さ

れているデータの数え方が異なっている．

ソケット · · · データが入っているmbufの大きさの総量TCP · · · mbufに入っているデータの総量

このため，ソケットはmbufの中に 1byteしかデータが入っていなかったとしても，small

mbufの場合は 112byte，cluster mbufの場合は 2kbyte 4)と計算する．TCPではmbufの中に 1byteのデータが入っていれば 1byteと計算する．表 2.3のようにバッファ・サイズが8196byteの場合は，ソケットは 2kbyteの cluster mbufを 4個使用した時にバッファが一杯になったと判断する．しかし，TCPではmbufには 8196byteのデータを入れることができると判断する．また，ソケットではメッセージ・サイズが 209byte5)未満の場合には 1

つまたは複数の small mbufにデータが格納される．メッセージ・サイズが 209～2048byte

の場合は 1つの cluster mbufにデータが格納される．メッセージ・サイズが 512byteの場合を例にとって考える．メッセージ・サイズが 209byte

以上になると，データの格納には cluster mbufが使われる．バッファの大きさが 8196byte

なので 4つの cluster mbufが利用されるとソケットのバッファが一杯になる．バッファに実際に格納されているデータは 512byte × 4 = 2048byteである．TCPはこのデータを送信する．受信ホストでは最大でも 2048byteのデータしか受信しない．しかし，このデータ

4)BSD/OS 2.0.1の場合．SunOS 4.1.3の場合は 1kbyte．5)BSD/OS 2.0.1 の場合である．SunOS4.1.3 の場合は 512byte である．オペレーティング・システムに

よって値は異なる．


Ethernet 10Mbps

Host1 Host2

図 2.7: 2点間の Ethernet実験環境

表 2.3: 評価に使用した機材と設定CPU Twinhead Subnote (486 33MHz)OS BSD/OS V2.1MSS 1448octetTCPバッファ・サイズ 8196byte送信時間 (Netperf) 10秒

0

1

2

3

4

5

6

7

0 500 1000 1500 2000

Thr

ough

put(

Mbi

t/s)

Message Size(byte)

図 2.8: 送信メッセージ・サイズとスループットの関係


は受信ホストの遅延確認応答が解除される 2MSS=2896bypteに達しない．このため，受信ホストでは，さらなるデータが送られて来ることを期待して確認応答の送信を遅らせることになる．しかし，送信ホストはデータを送ることはできない．このため，デッドロック状態になり，受信ホストの遅延確認応答の制限時間が解除されるまで確認応答は送信されない．遅延確認応答の制限時間はTCPのファスト・タイマの時間の 0.2秒程度である．このため 0.2秒ごとにしかデータが送信されなくなり，極端にスループットが低下することになる．

2.3 高速ネットワークへの適用TCPは，ウィンドウ制御によって，データの送信と確認応答を並列化して行えるよう

になっている．このため，遅延がある程度大きくなっても，ネットワークの帯域を埋め尽くすようなデータ転送が可能である．しかし，RFC793で定義されている TCPのウィンドウ・サイズのフィールド長では，広帯域，高遅延ネットワークでデータ転送をしたときに，帯域のすべてを埋め尽くすことはできない．この問題を解決するために，TCPのウィンドウを拡大するオプションが追加された．

2.3.1 ウィンドウ・サイズの制限の問題

送信ホストが一度に大量のデータを送信すると，受信ホストがすべての送信データを受信しきれなくなる可能性がある．これは，受信ホストの処理能力が送信ホストに比べて劣っている場合や，受信ホストの負荷が高い場合に起こりやすい．また，遠隔ログインなどでユーザが画面の表示を一時停止した場合など，アプリケーションの受信処理がしばらく停止する場合にも発生する可能性がある．このときに，データの送信量を調整したり，送信の停止，再開をする仕組みがフロー制御である．

TCPのフロー制御は，受信ホストから受信可能なオクテット数を送信ホストに伝えることで実現されている．このオクテット数がウィンドウと呼ばれる．送信ホストはこのウィンドウの大きさを超えるデータを送信することはできない．よって，このウィンドウの大きさとラウンド・トリップ時間によって，TCPによるデータ転送の最大スループットが決まる．ウィンドウの大きさをwin，ラウンド・トリップ時間をRTT とすると，得られる最大のスループット Tmaxは，

Tmax =win

RTT(2.1)

で求められる．TCPのヘッダには，受信ホストから送信ホストへ受信可能なウィンドウの大きさを伝

えるフィールドがある．この大きさは 16ビット長であるである．つまり，ウィンドウの最

2.3 高速ネットワークへの適用 27

0.1

1

10

100

1000

10000

100000

1e+06

1e+07

0.001 0.01 0.1 1 10

Thr

ough

put (

M b

ps)

Round Trip Time (Second)

Window Size = 64 K octetsWindow Size = 1 G octets

図 2.9: ラウンド・トリップ時間とスループットの関係

大値は 64Koctetになる．このウィンドウの大きさでは，遅延の大きな広帯域ネットワーク (LFN6): long, fat pipe)の帯域を使い切るような，高スループットを達成できないという問題がある．この問題を解決するために，ウィンドウの最大値を拡張するオプションが提案がされた

[16]．TCPのオプション・フィールドを使用し，ウィンドウの値をビット・シフトする値を通知する．TCPヘッダのウィンドウ・フィールドの値をwinadv，ウィンドウ拡大オプションの値を aとすると，このオプションによって決められるウィンドウの値は winmax

は，

winmax = winadv × 2a (0 ≤ a ≤ 14) (2.2)

になる．ウィンドウ拡大オプション aの最大値は 14に決められている．このため，ウィンドウの最大値は 1Goctetになる．この制限は，TCPのヘッダのシーケンス番号を表すフィールドが 32ビット幅であるために決められた．32ビット幅のシーケンス番号は 4Goctetで巡回する．このため，シーケンス番号が重ならず，また巡回しても 2の補数演算でウィンドウ制御を可能にするためには，4Goctetの半分の 2Goctet未満でなければならない．よって，aの値は 15未満でなければならず，最大の 14と決められた．なお，シーケンス番号が巡回しなくても，TCPには再送制御があるため，1巡回また

はそれ以前の同じシーケンス番号のデータを後から受信する可能性がある．TCPでは受信したシーケンスのデータを捨てることは許されない．このため，古いシーケンス番号の

6)elephan(t)”と発音する [16]．


データを誤って受信した場合にはデータの信頼性が確保されなくなる．この問題を防ぐために，タイムスタンプ・オプションが定義された．このタイムスタンプ・オプションは，すべてのTCPセグメントに付けられる．そして，タイムスタンプが示す時刻は，TCPのシーケンス番号が 1周する前に増加するが，TCPで転送されるデータの生存時間であるMSL(Maximum Segment Life time)以内には巡回しないように制御される．これにより，古いシーケンス番号のデータと新しいシーケンス番号のデータを区別することができるようになり，古いデータを誤って受信することによるデータの破壊を防ぐ．ウィンドウが 64Koctetの場合と 1Goctetの場合の，ラウンド・トリップ時間とスルー

プットの関係を図 2.9に示す．現在の高速ネットワークは 100Mbps～1Gbps程度であり，さらに向上することが期待されている．ラウンド・トリップ時間は，LANでは，0.01～0.1秒程度，WANでは，0.1～1秒程度である．ただし，光の速度は超えられないという制限から，この値は改善されたとしても限界がある．そのため，ウィンドウが 64Koctet

の場合にはネットワークを使い切るようなスループットは達成できないが，ウィンドウを1Goctetにすれば十分にネットワークの帯域を使い切ることができると考えられる．しかし，まだすべての TCPの実装でこの機能が採用されているわけではない．ウィン

ドウの最大値が 64Koctet以下に制限されているコンピュータは依然として数多く存在している．しかも，ウィンドウの最大値を拡張するオプションが実装されている TCPでもこの機能は有効に利用されていない．現在，TCPのウィンドウ拡張オプションを有効に利用するためのアルゴリズムに関する標準化作業は行われていない．このオプションは，システム管理者が静的に値を設定するのみで，管理者が何もしない場合には，ほとんどの場合このオプションは利用されない．実際にオプションを利用したい場合には，アプリケーション・プログラムでこのオプションを使用するように設定しなければならない．しかし，一般的なアプリケーションではこのオプションを設定するようには作られておらず，現在のインターネットではウィンドウの拡大オプションは有効に利用されていない．

2.3.2 TCPゲートウェイによる解決

終点ホストには，ウィンドウの拡大オプションが実装されていない場合や，適切な値に設定されていない場合が多い．そこで，途中にTCPゲートウェイを置き，TCPゲートウェイ間でこのオプションを利用する方法の試作が行われた [33]．これにより，終点ホストにウィンドウの拡張オプションが実装されていなくても，また，そのオプションを利用できるような設定がなされていなかったとしても，大きなスループットを得ることができる．しかし，このゲートウェイを公共のバックボーンとして利用できる可能性は低い．なぜ

ならば，TCPのコネクションが大量にこのゲートウェイを利用しようとするならば，非常に大きな負荷がこのゲートウェイにかかることになり，スループットの低下をまねくおそれがある．また，終点ホスト間に複数の経路がある場合は，行きと帰りの経路が同じと

2.4 輻輳制御・再送制御 29

は限らない．また，通信の途中で経路が変わることもある．そのため，単純な仕組みでは，この提案をインターネットのバックボーンに適用する事はできないと考えられる．ただし，現在のインターネットでは，WWWや FTPでは，代理サーバ (proxy server)

が利用されるケースが多くなっている．これは，トラヒックの軽減や，セキュリティの向上のために行われることが多い．これは，一種のアプリケーション・ゲートウェイであり，この地点で完全に TCPのコネクションが分断される．そのため，代理サーバに TCPのウィンドウの拡張オプションを活用できるような機能を組み込むことができれば，スループットを向上させることができる可能性がある．

2.4 輻輳制御・再送制御TCPの性能を決める項目の中で最も複雑で，最も研究が活発に行われているのが，輻

輳制御と再送制御である．代表的な研究と，TCPに新たに加えられることになった機能について説明する．

2.4.1 スロー・スタート

Jacobsonは，TCPによるデータ転送開始時に，バースト的なトラヒックがネットワークに送信されることによる弊害を防ぐため，スロー・スタートを提案した [34]．スロー・スタートは，新たなデータ転送の開始がネットワークへの急激な負荷とならないように，データの送信量を調節するとともに，送信セグメントと確認応答パケットによる自己同期(Self Clocking)を実現するための機能である．スロースタートでは，送信側の送信データ量を制限する輻輳ウィンドウ (cwnd: Congestion Window) を定義する．そして，データ送信開始時，および，タイムアウトによる再送の場合は輻輳ウィンドウを 1MSSに設定する．そして，確認応答パケットを 1つ受信するたびに輻輳ウィンドウを 1MSSずつ増やしていく．その結果，スロー・スタート時のスループットは指数関数的に増加する．実際にデータ転送に使用されるウィンドウの大きさは，受信ホストから通知されるウィンドウと輻輳ウィンドウの小さい方の値になる．自己同期 (Self Clocking)とは，確認応答によって送信レートがコントロールされること

を意味する．送信開始時にバースト的にデータを送信すると，データは固まって送信されることになる．その結果，ネットワークの帯域に与える負荷も，時間的に一定ではなく，ラウンド・トリップ時間内で，大きく揺らぐことになる．自己同期をした場合には，ネットワークにの帯域に与える負荷は，時間的に一定に近くなる．そのため，他のトラヒックがネットワークの帯域に割り込んだとしても，ネットワークの急激な負荷となることを緩和することができる．


送信データ

確認応答

送信ホスト受信ホスト送信バッファ受信バッファ

図 2.10: TCPの自己同期

2.4.2 再送タイムアウトの見積もり

TCPでは，データセグメントの送信と，それに対する確認応答の受信で，信頼性のある通信を実現している．ある時間経過しても確認応答が到着しない場合は，セグメントまたは確認応答のパケットが喪失した可能性がある．そこで，TCPではパケットの往復にかかるラウンド・トリップ時間 (RTT: Round Trip Time)を計測し，再送処理をする．計測の誤差を少なくするため，新しく求めたラウンド・トリップ時間に重みをおいた平滑化を行う．初期の TCPでは，見積もられたラウンド・トリップ時間にある定数を掛け合わせた値

を再送タイムアウト時間 (RTO: Retransmission Time Out)と定義し，その時間経過しても確認応答が到着しない場合にセグメントを再送していた．しかし，単純なこの仕組みには問題があることが分かった．他のトラヒックの影響によって，各セグメントのラウンド・トリップ時間に大きな揺らぎが現れたのである．ネットワークの負荷が小さい場合にはこの揺らぎは小さいが，負荷が大きくなるとこの揺らぎも大きくなる．また，再送したセグメントに対するラウンド・トリップ時間の見積もりには，あいまい

性があるという問題が指摘された．到着した確認応答が再送する前のセグメントに対するものなのか，再送後のセグメントに対するものなのか区別できないのである．これらの問題を解決する方法がKarnらによって提案された [35]．

• 再送したセグメントに対するラウンド・トリップ時間の見積もりは行わない．

• ラウンド・トリップ時間とその分散を見積もり，それぞれを足した時間を再送タイムアウト時間と定義して再送処理を行う．

これは，現在の多くの TCPの実装で採用されている方法であり，現在のインターネットでもそれなりの効果が得られていると見込まれる．また，実際にネットワークを流れるトラヒックは，正規分布やポアソン分布でモデル化

できるようなものではなく，自己相似性を持つといわれている [36]．これらを利用した再


TCPの確認応答

TCPの確認応答選択確認応答

受信したデータ

受信したデータ

確認応答をする範囲

選択確認応答選択確認応答

TCPの選択確認応答オプションを利用する場合

TCPの通常の確認応答の場合送信パケットの流れ

送信パケットの流れ

確認応答をする範囲

図 2.11: 通常の確認応答と選択確認応答の違い

送制御に関する研究も行われているが，まだ，はっきりとした有効性を証明するまでにはいたっていない．

2.4.3 選択確認応答

TCPの確認応答は，パケット単位ではなく，ストリーム上の位置で示す．そのため，間欠的にセグメントが到着した場合 (いわゆる歯抜け状態)でも，到着したセグメントのすべてを確認応答することはできない．そのため，無駄な再送が行われる可能性がある．この問題を解決するために，選択確認応答 (SACK: Selective Acknowledgment)に関す

る研究が行われた [37]．そして，現在では TCPの提案標準となっている [17]．具体的には，TCPのオプション・フィールドを利用し，受信したシーケンス番号の始まりと終わりを示すことで確認応答をする．図 2.11に示す様に，TCPのオプションフィールドは最大で 40オクテット長であるため，確認応答できる歯抜けセグメントの領域は最大で 4つまでに限定される．これにより，選択確認応答されたセグメントは再送されなくなり，無駄なセグメントの

送信を防ぐことができる．しかし，再送のタイミングや，輻輳ウィンドウの変更アルゴリズムについては明確な定義はされていない．その理由は，輻輳ウィンドウをどのように制御すれば，選択確認応答を最大限に有効に利用でき，また，無駄のない，素早い再送を実現できるかが明らかではないからである．選択確認応答を効率よく行うために，FACK(Forward

Acknowledgment)というアルゴリズムが提案されている [38]．しかし，まだ，実装による評価は不十分であり，インターネットで運用実験をする必要がある．


2.4.4 再送アルゴリズム

TCPの再送処理のアルゴリズムは，実装先行型で進められた．その代表がTCP Tahoe

バージョンと TCP Renoバージョンである [39]．また，LawrenceらによってVegasという TCPのバージョンが提案された [40]．

Tahoe

Tahoeは，輻輳ウィンドウ (cwnd: congestion window)とスロー・スタート閾値 (ssthresh:

slow start threshhold)を定義して次の制御を行う．

• スロー・スタート

再送タイムアウトが発生した場合には，輻輳ウィンドウ cwndを 1MSSにしてセグメントを再送する．確認応答パケットを受信するたびに輻輳ウィンドウ cwndを 1MSS

ずつ増加させる．すなわち，新しい輻輳ウィンドウ cwndnewは次の式で計算される．

cwndnew = cwnd + MSS (2.3)

• 輻輳回避制御

ウィンドウが急激に拡大しすぎることにより輻輳状態になることを防ぐため，輻輳ウィンドウ cwndがスロー・スタート閾値 ssthreshを超えた場合には，1つの確認応答パケットを受信するたびに輻輳ウィンドウを (MSS/cwnd) MSSずつ増加させる．すなわち，新しい輻輳ウィンドウ cwndnewは次の式で計算される．

cwndnew = cwnd +MSS

cwnd× MSS = cwnd +

MSS2

cwnd(2.4)

タイムアウトによりセグメントの再送をするときには，スロー・スタート閾値ssthresh

をそのときの輻輳ウィンドウ cwndの半分に設定する．すなわち，新しいスロー・スタート閾値 ssthreshは次の式で計算される．

ssthresh =cwnd

2(2.5)

なお，スロー・スタート閾値の初期値は，最大ウィンドウ・サイズに設定される．


Reno

Renoでは，これらのアルゴリズムに加え，高速な再送制御を行うように次のアルゴリズムが追加された．

• 高速再送制御 (Fast Retransmission)

重複確認応答 (Duplicate Acknowledgment)を 3つ受信した場合に，その確認応答が示しているセグメント以降を再送する．

• 高速回復制御 (Fast Recovery)

タイムアウトが発生するときに比べると，重複確認応答を受信する場合はネットワークが混雑していないと考えられる．よって，輻輳ウィンドウを 1MSSに設定してスロー・スタートを行うのではなく，もう少し大きな値にしてもよいと考えられる．高速回復制御は，高速再送制御が行われるときには，輻輳ウィンドウ・サイズを次の式で計算された値に更新する．その時点の輻輳ウィンドウを cwndとすると，新しい輻輳ウィンドウ cwndnewは次の式で表される値になる．

cwndnew =cwnd

2+ 3MSS (2.6)

また，高速回復制御中に別の重複確認応答を受信した場合には，輻輳ウィンドウを1MSS拡大する．

Renoの高速再送制御や高速回復制御などの機能は，BSDの実装があるだけで，長い間TCPのプロトコルの仕様にはなっていなかった．しかしそれがRFC2001でようやく明文化され TCPのプロトコルとして提案標準となった．

Vegas

Lawrenceらによって提案されたVegasには次のような特徴がある．

• より正確なラウンド・トリップ時間を計測する．

従来のTCPの実装では，0.5秒単位でラウンド・トリップ時間を計測していた．Vegas

ではシステム・クロックから時間を読み込むことにより，0.001秒単位でラウンド・トリップ時間を計測する．これにより，従来のTCPよりもラウンド・トリップ時間の計測の制度が向上する．

• 多くのイベントで再送タイム・アウトの評価を行う

従来のTCPの実装では，0.5秒単位で再送タイムアウトの評価が行われていた．Vegas

では，セグメントを受信した時や writeシステムコールが呼ばれた時など，多くの


イベントで再送タイムアウトの評価を行う．これにより，従来のTCPよりも素早い再送処理を実現する．

• ラウンド・トリップ時間の長さの変化に応じて，輻輳ウィンドウを増減させる．

従来のTCPでは，セグメントが喪失したとき以外には，輻輳ウィンドウは増加させるだけで減少させる処理は行われていなかった．Vegasでは，計測されたラウンドトリップ時間と送信したデータ量から，スループットを評価して輻輳ウィンドウを増減させる．これにより，ウィンドウが増加しすぎることによる自己輻輳を回避することができる．

TCPのTahoeやReno，Vegasに関してはシミュレーションによる研究が行われている[41]．そしてシミュレーションのレベルでは，Vegasが良いという結論が語られている．しかし，運用実績があまりなく，十分な信頼性を得るまでには至っていない．

2.4.5 ルータによる制御

ルータによって TCPの通信性能を向上させる研究も行われている [42]．例えば，ルータのパケット破棄の方法によって，そのルータを通る TCPのデータ転送のスループットの大きさが同期することを避けることができ，ある程度輻輳を抑えられることが示されている [43]．

WFQ(Waited Fair Queuing)や RED(Random Early Detection) に関する研究や実装も行われている．しかし，インターネットで運用した結果，良い効果が得られたという報告はまだ聞かれない．これらのアルゴリズムを利用すると，パケット転送の処理速度が遅くなり，結果としてこれらのアルゴリズムの効果が得られない可能性がある．今後，実装して性能評価を行ったり，実際に運用することにより経験を積みながら評価を行う必要がある．

2.5 まとめTCPの性能改善の目的は，終点アプリケーション間で十分なスループットが得られる

ようにすることである．得られるスループットは大きければ大きいほど良いわけであるが，必要とされるスループットは用途によって異なる．また，パケット・ネットワークの特徴として，ネットワークは多くの通信で共有される．そのため，TCPは共有する通信の間でできるだけ平等で，無駄のない通信を実現する必要がある．

TCPの研究は，大きく 2つに分類できるといえる．1つは，TCPのプロトコルや実装には制限や問題があり，ネットワークの帯域をどんなに大きくしても，また，ルータやブリッジの性能をどんなに向上させても，解決できな課題である．もう 1つは，ネットワー

2.5 まとめ 35

クの帯域や，ルータなどのネットワークの中継装置の性能が改善されると，TCPの問題自体は小さくなる課題である．前者は，シリー・ウィンドウ・シンドロームの回避策や，ウィンドウの拡張オプションなどが含まれる．後者には，輻輳制御や，再送制御が含まれる．例えば，パケットが喪失しなければ，再送処理は必要なくなる．これは，ルータなどの中

継機器の性能を向上させたり，通信量に対してネットワークの帯域を十分に大きくしたり，ノイズによる影響をなくしビットエラーがほとんど発生しないようにすればよい．現在，ATM OC12(622Mbps)やGigabit Ethernet(1Gbps)などの製品が出荷されており，LAN

での利用は始まっている．また，高速で広帯域の公衆ATM網の整備も進められ，135Mbps

の専用回線がインターネットのバックボーンに利用されている．このように，ネットワークの帯域を拡大することは技術的な問題ではなくなってきている．どちらかといえば経済的な問題である場合が多い．ネットワーク機器や公衆網サービスの価格は，需要の拡大などによって年々低下する傾向がある．そのため，経済的な問題は時間とともに解決する可能性がある．ただし，現在のインターネットを考えるならば，トラヒック量に応じてネットワークの

帯域を拡大させるという方法はいたちごっこだといえる．しかし，要求される通信量に比べてネットワークの帯域が著しく小さいならば，TCPをどんなに改良しても，また，ネットワークに帯域制御などの機能を付加したとしても，利用者にとって必要なスループットを提供することはできない．ただし，ネットワークの帯域を大きくすることは，物理的に不可能な場合もある．例え

ば，電波を利用した無線通信の場合には，物理的な周波数の資源が限られているため，ネットワークの帯域を拡大するにも限界がある．また，電波の場合は外界の影響を防ぐことができないため，ビットエラーの発生を小さくする工夫にも限界がある．このように考えると，ただやみくもにTCPの性能を向上させることが重要なのではなくて，TCPが不得意とする領域の性能を向上させることが急務となっていることが分かる．インターネットで信頼性のある通信を提供するトランスポート・プロトコルは TCPし

かない．そのため，TCPはインターネットで構築されうるどのような環境においても，性能を発揮できる万能なプロトコルであることが望まれている．このように考えると，TCP

はどのようなネットワークでも，最善の環境を提供してくれることが望まれる．今後は，TCPの設計時に想定されていなかった環境に，TCPを対応させる研究が重要になってくると考えられる．また，そのためには，現在分かっている TCPの大きな問題点をすべて改善する必要がある．特に，TCPのデータ転送が短期間停止するという，TCP短期デッドロック問題を解決しなければ，今後の TCPの改善に大きな問題となる可能性がある．

PART II

TCPのデータ転送モデルと実装モデル

第 3 章 TCPのデータ転送モデルp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

インターネットで現在使われているTCPは，TCPのプロトコルの仕様が決められたときと全く同じものが使われているわけではない．2.1節で説明したように，様々なネットワーク環境が構築され，実際にデータ転送が行われるようになると，シリー・ウィンドウ・シンドロームという現象が発生し，ネットワークの転送効率が著しく低下するという問題があることが明らかになった．この問題を改善するために，Nagleアルゴリズム [18]や遅延確認応答 [19]といった機能が追加された．これらの仕様の追加・変更によって，TCPには，低遅延データ転送と，高スループット・データ転送に対応しながら，ネットワークとホストの負荷を低減する機構が備えられるようになった．この章では，アプリケーションのデータ転送モデルを 3つに分類し，それぞれのモデルで TCPがどのような挙動をするかを示す．

3.1 データ転送のモデル化の意義TCPの機構を細かく分析することは，現在のTCPについてより細かく知る上で重要な

ことである．TCPに変更を加える場合には，このTCPのデータ転送モデルの特徴と性質について理解し，このモデルを改悪しないように十分に考慮する必要がある．また，次世代のTCPを設計するときには，このTCPの特徴を生かすように設計する必要がある．このように，TCPの機構の分析は，現在のTCPの問題点の解決や，次世代TCPの設計をするときに重要な情報となる．

TCPは，バルク・データ転送と，インタラクティブ・データ転送を扱えるといわれている [39]．本論文では，これに，即時性のあるインタラクティブ・データ転送を加えた 3つのデータ転送について考える．それぞれのデータ転送をモデル化し，TCPの挙動について細かく考察する。

3.2 セグメントとPUSH機構TCPのデータ転送モデルを考える前に，TCPの基本的な概念であるセグメントとPUSH

機構について説明する．

39

40 第 3章 TCPのデータ転送モデル

データの最後ではPUSHフラグが設定される

アプリケーションが送信するデータ

1MSS 1MSS

ヘッダが付けられ送信される

1MSS単位に区切られる

パケットの流れ

図 3.1: TCPのデータ転送

3.2.1 セグメント

TCPでは，1つの IPデータグラムに格納されるデータは，セグメントと呼ばれる．TCP

はストリーム型の通信であり，データはすべて連続的なつながりを持っている．セグメントという言葉は，パケットに格納するために，連続的なデータを区切った一部分であることを意識的に表している．

TCPでは，データの送信を制御するための単位として，最大セグメント長 (MSS: Maxi-

mum Segment Size)の値が決定される．多くの場合，この最大セグメント長単位で，データ転送や再送の処理，輻輳制御，確認応答処理が行われる．この最大セグメント長は，理想的には，IPフラグメントが発生しない最大の大きさである．LANでは，データを送受信するデータリンクの最大転送単位 (MTU: Maximum Transmission Unit)から，IPやTCPのヘッダを引いた値が利用される．つまり，データリンクの最大転送単位をMTU，IPヘッダの長さを IPheader，TCPヘッダの長さを TCPheader，とすると，最大セグメント長MSSは次の式で求められる．ただし，IPheaderや TCPheaderには，データ転送時に利用されるオプションの長さが含まれる．

MSS = MTU − (IPheader + TCPheader) (3.1)

送信するデータの量が最大セグメント長の値よりも大きい場合は，データは最大セグメント長単位に分割されて送信される．この最大セグメント長は，TCPのコネクションの確立時に TCPオプションを利用して決定される．

3.2.2 PUSH機構

TCPには PUSH機構が備えられている．これは，送信ホストから受信ホストへ，受信したデータをバッファリングせずに遅延なくアプリケーションに渡すための機構である．このPUSH機構を実現するために，TCPヘッダの中にはPUSHフラグが用意されている

3.2 セグメントと PUSH機構 41

[7]．このPUSH機構は，特に受信したデータをバッファリングするOSで必要となる機能である．受信アプリケーションは，TCPが受信したセグメント単位でデータを受信しても処理

できないかもしれない．アプリケーションにはアプリケーションのデータの切れ目があり，その切れ目以下の単位でデータを受信しても，アプリケーションは処理をすることはできない．オペレーティング・システムにとっては，アプリケーションのデータの切れ目未満の単位で受信したデータをアプリケーションに渡すよりは，アプリケーションのデータの切れ目単位でデータを渡した方がコンテキスト切り替えの回数が少なくなるなど効率がよい．このアプリケーションのデータの切れ目を表すのが PUSHフラグである．送信ホストでは，受信アプリケーションがデータを処理する単位で，PUSHフラグを設定してからデータを送信しなければならない．しかし，BSDなどの多くの実装では，アプリケーションから明示的に PUSHフラグを

設定することはできない．これらの実装では，オペレーティング・システムによって自動的にPUSHフラグが設定される．具体的には，セグメントの送信時に，送信バッファに未送信データが残らない場合にPUSHフラグが設定され，バッファに未送信データが残る場合には PUSHフラグは設定されない．つまり，セグメントの送信時に，TCPの送信バッファの待ち行列の長さが 0になる場合に PUSHフラグが設定される．この PUSHフラグの設定アルゴリズムはRFC1122で定義されており，アプリケーションからPUSHフラグの設定をできない実装の場合には，必ずこのアルゴリズムを実装しなければならない [21]．この PUSHフラグの設定アルゴリズムでは，必ずしもアプリケーションで処理される

データ単位でPUSHフラグが設定されるとは限らない．Nagleアルゴリズムにより，送信済みのデータがない場合には，システムコールによって送信要求されたデータはそのまま送信される．そのデータ量が 1MSSに満たない場合にはPUSHフラグが設定されるが，これは，受信ホストのアプリケーションが処理するデータ単位とは限らない．また，受信ホストのアプリケーションが処理する単位のデータが，バッファに複数個格納され，合計が1MSSを超えた場合には，途中の単位は無視され，データの最後のみでPUSHフラグが設定される．このアルゴリズムは，送信処理が一段落したら PUSHフラグが設定されると解釈して

よい．このアルゴリズムの場合は，少なくとも受信ホストのアプリケーションが処理するデータの単位の最後ではPUSHフラグが設定されることになる．受信ホストは，受信したデータを途中でデータを処理する必要はなく，通信終了後にすべてのデータを一括して処理してかまわない．このような機構により，途中でPUSHフラグが設定されなくても処理の効率が低下しないようになっている．

TCP/IPプロトコルの実装の代表であるBSDの実装では，このPUSH機構には何の意味も持っていなかった．BSDの実装では，受信したデータをバッファリングしておらず，PUSHフラグの値に関係なく，すべての受信データをバッファリングせずにすぐにアプリ


HOST A

ACK

PUSH

ACK

ACK

HOST B1MSS

図 3.2: バルク・データ転送

ケーションに渡すからである．そのため，この PUSH機構は全く意味のない機構であるという意見もある [44]．しかし，Windows NT 4.0ではこの PUSHフラグによる受信バッファの制御機構が実装されている [45]．この PUSHフラグの評価は行われていないため，その効果については明らかではない

が，PUSH機構を正しく使えば，コンピュータの負荷を減らすことができるはずである．つまり，適切に PUSHが設定されている場合には，入力データをある程度まとめて一括してアプリケーションに渡すことができる．その結果，カーネルからアプリケーションへコンテキスト切り替えが発生する回数を減らすことができ，負荷を軽減できると見込まれる．今までの実装ではPUSHフラグはあまり重視されていなかったが，今後の高速ネットワーク環境に対応するために，PUSHフラグを活用して，カーネル内部のバッファ管理やスレッド管理を行う必要があると考えられる．

3.3 バルク・データ転送モデルバルク・データ転送とは，FTP(File Transfer Protocol)[46] によるファイル転送や，

HTTP(Hypertext Transfer Protocol)[47] による画像データの転送など，比較的大きなデータを連続的に転送することを意味する．バルク・データ転送では，図 3.2に示すように片方向に大量のデータが転送される．Nagle

アルゴリズムによりデータは 1MSS単位で送信される．また，遅延確認応答により，2MSS

のデータを受信するたびに 1つの確認応答パケットが送信される．このとき送信されるアプリケーションのデータは，最大セグメント長 (MSS: Maximum

Segment Size) 単位に分割され，それぞれ 1つの IPデータグラムとして送信される．このモデルでは，送信される一連のデータの内容は，送信ホストによってあらかじめ決められ

3.4 インタラクティブ・データ転送モデル 43

PUSH

PUSH

PUSH

PUSH

HOST A

ACK

ACK

ACK

HOST B

図 3.3: インタラクティブ・データ転送

ている場合が多い．このモデルでは，個々のデータセグメントの遅延時間はあまり問われない．トータルの

スループットが重要視される．トータルのスループットを向上させるためには，できるだけ大きなパケット単位でデータを転送した方がよい．そのため，いかにして送信データを1MSS単位で送信するかが重要になってくる．このモデルでは，PUSHフラグはデータの最後に付けられる．受信した途中のデータは

カーネル内部にバッファリングされ，データがある程度の量まとめられてからアプリケーションに渡される．この処理がカーネルによって適切に行われるならば，ユーザー・モードとカーネル・モードの切り替えを減らすことができる．その結果，切り替えのオーバーヘッドが減り，処理の効率を向上させることができる．なお，TCPでコネクションを確立した直後は，Nagleアルゴリズムが有効であったとし

ても，1MSS以下の任意の大きさでセグメントを送信することができる．コネクション確立直後には送信済のデータは存在しないため，1MSS以下のセグメントを送信してもNagle

アルゴリズムに違反しない．よって，たとえバルク・データ転送であったとしても，通信開始時の 1番最初データなど，確認応答されていない送信済みセグメントがない場合は，送信セグメントのデータ長は 1MSSになるとは限らない．

3.4 インタラクティブ・データ転送モデルインタラクティブ・データ転送とは，終点ホスト間で，互いに命令や応答のやりとりを

しながら通信が行われるときのモデルである．具体的には，SMTP (Simple Mail Trans-

fer Protocol)[48]や，NNTP (Network News Transfer Protocol)[49]，POP (Post Office

Protocol)[50]などのプロトコルによる通信が，このインタラクティブデータ転送に分類される．文献 [39]では，インタラクティブ転送として，TELNETの例が示されている．こ


のTELNET[51]や rloginなどの遠隔ログインによるトラヒックも，インタラクティブ・モデルの変形として考えることができる．インタラクティブ・データ転送では，図 3.3に示すように，データを送信するアプリケー

ションは，比較的小さなデータを送信したら処理を停止して相手のホストからの応答を待つ．この小さなデータを含むセグメントでは PUSHフラグが設定される．

PUSHフラグが設定されたセグメントを受信した場合には，そのデータはバッファリングされず，すぐにアプリケーションに送られる．バッファに他の受信データがある場合には，そのデータを含むすべてのデータがアプリケーションに渡される．オペレーティング・システムからデータを渡されたアプリケーションは，そのデータを処理して返事となるデータを作成して返送する．インタラクティブ・データ転送では，2つのホスト間でこのようなデータのやり取りが

繰り返される．なお，送信するデータがMSSより大きい場合は，バルク・データ転送と全く同じになり，データはMSS単位に分割されて転送される．この場合は，データの最後のセグメントでのみ PUSHフラグが設定される．インタラクティブ・データ転送では，1つのパケットでデータの送信処理と確認応答処

理の両方が一辺に行われる．これはピギーバックと呼ばる．TCPは 1つのヘッダで，データの送信と確認応答を同時に行えるように設計されている．つまり，送信されるすべてのTCPセグメントには確認応答のフィールドが含まれいる．このため，ピギーバック処理をする事ができる [7]．確認応答のピギーバックが行われると送受信するパケットの数が減る．このためネットワークの負荷を低下させることができる．また，パケットの送受信回数が少なくなるため，データを送受信する両方のホストのプロトコル処理が少なくなり，CPU処理などの負荷を下げることができる．なお，遅延確認応答が行われなければピギーバックは起こらない．図 3.4に示すように，

受信したデータをアプリケーションが処理して返事を送信するまで確認応答が遅延されなければ，ピギーバックされることはない．確認応答の遅延時間が長くなれば長くなるほどピギーバックされる可能性は大きくなる．しかし，遅延時間が長くなりすぎるとセグメントが再送される可能性がある．このような理由から，確認応答の遅延時間は最大で 0.5秒以内にしなければならないことが決められている．確認応答の遅延時間を短くしても，TCPのスループットを向上させることはできない．

バルク・データ転送では大量にセグメントが到達するため，確認応答の遅延時間に関係なくデータ量に応じて確認応答が行われる．また，確認応答の遅延時間が短くなると，インタラクティブ・データ転送の場合にはピギーバックされる確率が低下する．こうなると，ネットワークや CPUの負荷が上昇しスループットが低下することになる．インタラクティブ・データ転送モデルでは，個々のセグメントのスループットが全体の

性能を決めることになる．そのため，おのおののセグメントの送信処理や受信処理に遅延時間が加わるとスループットが低下することになる．このモデルでデータ転送の速度を向

3.5 即時性を必要とするインタラクティブ・データ転送モデル 45

命令を処理して返事を送信

遅延確認応答をする場合のパケットの流れ遅延確認応答をしない場合のパケットの流れ

結果を処理して次の命令を送信

命令を送信



結果を処理して次の命令を送信

命令を送信

クライアントの処理サーバの処理クライアントの処理サーバの処理


ACK

アプリケーションのデータ

アプリケーションデータ＋確認応答確認応答のみ

結果を処理してしばらく待機

結果を処理してしばらく待機

図 3.4: 遅延確認応答の果たす役割

PUSH

PUSH

PUSH

PUSH

HOST A

PUSHACK

PUSH

PUSH

ACK

PUSH

ACKPUSH

HOST B

図 3.5: 即時性を必要とするインタラクティブ・データ転送

上させるには，いかにして確認応答をピギーバックさせ，ネットワークやホストの負荷を低減させるかが重要な鍵となる．

3.5 即時性を必要とするインタラクティブ・データ転送モデルX11[52]などのウィンドウ・システムや機械制御など，即時性が求められるインタラク

ティブ・データ転送では，図 3.5に示すようなデータ転送が行われる．このモデルは，TCP

の Nagleアルゴリズムを無効にすることで実現される．図の場合，HOST Aではクライ


アント・プログラムが動作し，HOST Bではサーバ・プログラムが動作している1)．クライアントでイベントが発生するたびに，PUSHフラグが設定された小さなイベン

ト・メッセージがサーバへ送信される．サーバはそのメッセージを受信してイベントの内容を調べる．クライアントへ返事を送信する必要がある場合はメッセージを送信するが，必要のない場合は送信しない．クライアントからサーバへ送信されるメッセージの確認応答は，理想的な場合にはピギーバックされる．また，サーバからクライアントへ送信されるメッセージの確認応答も，ピギーバックされる可能性がある．このように，TCPでは遅延確認応答処理により，応答の即時性を犠牲にすることなく，無駄な確認応答パケットを減らせる設計になっている．

3.6 データ転送モデルとセッション層この章で説明した 3つのモデルは，TCPの改善や，TCPを利用するセッション層を作成

する際の指標となる考え方である．しかし，インターネットではセッション層の役割に関して軽んじられてきたという歴史がある．ネットワークを有効に利用し，アプリケーションにとって適切なスループットを得られるようにするためには，セッション層が重要な役割を果たす．

TCPの場合，アプリケーション中で，TCPを使ってコネクションの確立・切断，データの送受信を行う部分がセッション層だと考えられる．TCP/IPの場合は，データの送受信時に，ライブラリ関数ではなく，システムコールが使われることが多い．このため，実装上は，システムコールを呼び出すモジュールがセッション層だということができる．TCP

のサービスを呼び出す部分を設計・実装するときには，TCPの動作モデルを考慮する必要がある．そうしなければ，不必要にPUSHフラグが設定されたり，Nagleアルゴリズムの影響により，スループットに悪影響が及ぼされることがある．アプリケーション・プロトコルによっては，通信開始から終了まで同じデータ転送モデ

ルのままであるとは限らない．例えばHTTPは，はじめにクライアントからサーバへ要求が行われ，サーバから大量のデータが送信される．クライアントからの要求時はインタラクティブ・データ転送である．しかし，サーバからクライアントへのデータ転送は，データの量によって異なる．1MSSを超えればバルクデータ転送になり，1MSS未満であればインタラクティブ・データ転送になる．また，バルクデータ転送であったとしても，最後のセグメントは，インタラクティブ・データ転送になる．つまり，最後のセグメントを受け取った後で，クライアントが次の要求メッセージを送信するか，コネクションを切断するかを判断するからである．

1)X Window Systemの場合は用語が混乱するが，図の HOST Aでは Xサーバが動作しており，HOSTBでは Xクライアントが動作していると考える．

3.7 まとめ 47

即時性を必要とするデータ転送の場合は，本来ならばデータ転送モードが変更される度に，Nagleアルゴリズムを有効にしたり無効にしたり変更する必要がある．しかし，現実にはそのようなことは行われていない．これも，セッション層が軽んじられてきたからだといえる．今後は，TCPを利用するアプリケーション・プログラムの開発時には，本論文で示したデータ転送モデルをもとに，セッション層についてきちんと考える必要がある．

3.7 まとめこの章では，アプリケーションのデータ転送を 3つのモデルに分類し，それらのデータ

転送時のTCPの振る舞いについて分析した．そして，TCPのPUSH機構と遅延確認応答は，3つのデータ転送モデルのすべてで，ネットワークやホストの負荷を低減する役割を果たしていることを示した．TCPの改善や，TCPのセッション層を作成する際には，このデータ転送モデルと PUSH機構や遅延確認応答の関係を理解する必要がある．そうしなければ，トラヒックの増加や，ホストの負荷の増加につながる．そのため，この章で述べたデータ転送モデルと，TCPの機構は，TCPの改善や TCPのセッション層を作成する際の，指標となる考え方だといえる．

第 4 章 TCPの実装モデルとその問題p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

ネットワーク・プロトコルは階層化されている．そのため，すべての機能を TCPに実装することは間違っている．TCPによるデータ転送に何らかの問題があった場合，そのすべてを TCPで解決するのではなく，TCPで解決すべきことと，TCPの上位層で解決すべきこと，TCPの下位層で解決すべきことを分離して考える必要がある．実際に現在の TCPの実装は，下位層や上位層にいくつかの仮定をしている．この仮定

は，初期のインターネットには十分に適合していたが，インターネットのデータリンク環境の変化やアプリケーション環境の変化によって，必ずしもこの仮定は正しくなくなってきた．そして，TCPの仮定により，特定の環境の基では，大きな性能の低下をもたらすようになった．この章では，現在の TCPの問題点を分類して，TCP自体に残された課題と，TCPで

処理するのではなく，TCPの上位層や下位層で実装されることが想定されている課題について分類する．

4.1 TCPの実装モデルTCPは，BSDによってUNIX上に実装され，それが世界中の実装の手本とされてきた

という歴史がある．そのため，UNIXに実装することが念頭におかれた実装モデルが作られた．OSIの参照モデルとTCP/IPの階層モデルを図 4.1に示す．現在では，UNIXに限らず，大抵のオペレーティング・システムで，TCP/IPを利用することができる．どのオペレーティング・システムでもほぼこのモデルに従う形で実装されている．アプリケーション層はアプリケーション・プログラムのことである．トランスポート層は

TCPやUDPであり，インターネット層は IPや ICMPなどのプロトコルである．ネットワーク・インターフェース層は，ネットワーク・インターフェース・カード (NIC: Network

Interface Card)をオペレーティング・システムで利用できるようにするためのデバイス・ドライバのことである．この TCP/IPのモデルでは，アプリケーションの内部に OSI参照モデルのアプリケー

ション層，プレゼンテーション層，セッション層の 3つの層がすべて含まれると考えてよい．また，TCPと IPというインターネットの基本的なプロトコルは，オペレーティング・システムの内部に埋め込むように設計されている．

49

50 第 4章 TCPの実装モデルとその問題



インターネット層

ネットワークインターフェース層


ＴＣＰ／ＩＰ階層モデル

オペレーティングシステム

ネットワークインターフェースカード

(カーネル)

�アプリケーションプログラム

デバイスドライバ

TCP / UDP

IP / ARP

アプリケーションプログラミングインターフェース

ＴＣＰ／ＩＰ実装

アプリケーション


図 4.1: OSI参照モデルと TCP/IP階層モデル

このため，新しい機能を提案したとき，ネットワーク層やトランスポート層で実現するときには，カーネルに実装することになる．また，セッション層やアプリケーション層で実現するときには，アプリケーション・プログラムに実装することになる．カーネルで実現する場合，アプリケーションで実現する場合に比べて，実装は大変な作

業になり，また，他のオペレーティング・システムへの移植作業も難しくなる．このため，インターネット全体へ普及させることが難しくなる．また，アプリケーションに実装する場合は，動作時にカーネル・モードとユーザ・モードのコンテキスト・スイッチが必要となるため，カーネルに実装する場合に比べて処理速度が低下するおそれがある．TCPを改善しようとする場合には，これらのことを含めて，適した実装について考えなければならない．

4.2 TCPの上位層現在の TCPでは，上位層が管理しなければならないパラメータがいくつかある．主な

ものには次のものがある．

• Nagleアルゴリズムの有効化，無効化

• ウィンドウ・サイズの最大値の設定 (送受信バッファ・サイズ)

ウィンドウ・サイズは TCPによるデータ転送の最大スループットを決めるパラメータである．そのため，本来は TCPが適切な値に設定することが望ましい．しかし，現在のTCPの実装では，アプリケーションが動的に設定するしかない．TCPが動的に管理する

4.2 TCPの上位層 51

には，いくつかの問題がある．まず，最適なウィンドウ・サイズを決定するアルゴリズムを，TCPのプロトコルとして決定しなければならない．しかしまだ，現在の多彩なインターネット環境に適合する万能な方法は提案されていない．また，ウィンドウ・サイズの大きさはバッファ・サイズの大きさと深く関係するため，メモリ管理についても考えなければならない．メモリが少ない場合には，大量のバッファを TCPのコネクションに割り当てることはできない．メモリ資源の小さなシステムの場合，TCPが要求する通りにウィンドウ・サイズを大きくすると，システムの他の部分でメモリが足りなくなるなど別の問題を生じさせる可能性がある．このようなことから，現在の TCPの実装では，ウィンドウ・サイズの最大値や Nagle

アルゴリズムの設定等は，アプリケーション・プログラムによって設定されることが想定されているといえる．アプリケーション中で TCPの設定を操作する部分はセッション層と考えることができることから，実装モデルでは明確に定義されていないが，TCP/IPの場合でもセッション層について考慮する必要がある．

4.2.1 セッション層

セッション層とは，トランスポート層を利用してコネクションの確立や切断を管理する層である．回線の異常などで，途中でコネクションを維持できなくなった場合にはコネクションがいったん切断されることになるが，再びコネクションを確立できたときには，その前の通信と矛盾が発生しないように通信の同期を取る役目もある．また，アプリケーションの要求にあったトランスポート層の選択や，コネクションを確立するタイミング，1つのコネクションを順次的に利用するか複数のコネクションを並列的に利用するかなどの処理も行う．トランスポート層の性能を生かし切れるかどうかは，セッション層の作り方に依存しているといえる．

TCP/IPの世界では，その実装モデルから，セッション層やプレゼンテーション層に関してあまり真剣に考えられてこなかった [53]．TCP/IPのプロトコル・スタックのモデルの場合，セッション層やプレゼンテーション層はアプリケーション層と同時に定義されたからである．つまり，TCP/IPでは，アプリケーションごとに，アプリケーション固有のセッション層が考案されたといってもよい．しかし，アプリケーションごとに提案されたセッション層は，多くの場合あやふやで明確な定義がされておらず，汎用性をもっていなかったため，他のアプリケーション層プロトコルで利用されることはほとんどなかった．近年，インターネットのプレゼンテーション層として，MIMEの標準化作業が本格的に

行われている．もともとMIMEは電子メールで配送できるデータ形式を拡張するために提案されたデータ形式である．しかし現在では，WWWやネットワーク・ニュースなどでも利用されており，インターネットの標準的なプレゼンテーション層として，様々なアプリケーションで利用されている．


しかし，セッション層に関しては，いまだにそのような標準は存在せず，提案も行われていない．唯一，RPC (Remote Procedure Call)がセッション層として利用されているが，NFSなどの一部の用途に限定された利用にとどまっており，汎用的なセッション層とは呼べない．また，このRPCは LAN環境での利用がほとんどであり，WAN環境で利用されることは少ない．これは，通常のネットワーク・アプリケーションを開発するときに，ソケットや XTIなどのインターフェースを直接利用しても，プログラムの開発が複雑にはならないため，プログラマがセッション層を意識することなく安易に通信アプリケーションを実装しているとも考えられる．現在のTCPのモデルを考慮すると，TCPのセッション層には次のような機能が必要だ

と考えられる．

1. アプリケーションのデータ転送の性質に対応するようにデータの送受信を制御する．

2. TCPのウィンドウ・サイズの最大値を適切な値に設定する．

3. 複数のコネクションを管理して効率よくデータ転送を行う．

1.は TCPのデータ転送モデルを考慮してデータ転送を行うことを意味する．第 3章で示したように，TCPはバルクデータ転送モデル，インタラクティブデータ転送モデル，即時性を必要とするインタラクティブ・データ転送モデルに対応するような設計になっている．セッション層は，アプリケーションがどのデータ転送モデルに適合するかを理解して，TCPの性質を生かすように処理しなければならない．具体的には，応答性を犠牲にせず，なおかつ，システムコールのオーバーヘッドを減らすように，メッセージ・サイズや送受信のシステムコールを制御する．

2.は本来ならば，TCPモジュール内部で解決しなければならない問題だと考えられる．しかし，現在のTCPの実装では，TCPはウィンドウ・サイズの最大値を動的に変更することはなく，アプリケーションが必要に応じて設定を変更することになっている．つまり，現在の実装モデルではセッション層がコントロールしなければならないことになる．しかし，アプリケーション・レベルでは，ラウンド・トリップ時間の測定等，最適なバッファ・サイズを決定するときに必要になると考えられるパラメータのいくつかが分からない．このような情報が必要な場合には，アプリケーションが TCPから得られるようにするインターフェースを作る必要がある．

3.は，例えば FTPのように，制御用のコネクションとデータ転送用のコネクションを別々に確立し，制御する方式が含まれる．また，1つのコネクションでデータを送信するのではなく，複数のコネクションを確立して 1つのデータを送信する方法も考えられる．これらの場合には，TCPのコネクションの管理をセッション層がする必要がある．ただし，大量にコネクションを確立すると，利用できるネットワークの帯域が不公平になる可能性がある．この点も含めた検討が必要である．

4.3 TCPの下位層 53

今まで述べたように，現在のTCP/IP環境には，共通のセッション層はないがセッション層自体は存在している．セッション層の役割をもつ部分はアプリケーション・プログラムごとに作られており，いわば，各アプリケーション・プログラムごとにそれぞれの実装者が考えたセッション層が実装されているといえる．そのため，TCPの挙動を理解していない者がセッション層を実装した場合には，必ずしも TCPを有効利用していない可能性がある．今後は，アプリケーションから TCPを効率よく利用するために，セッション層に関する研究が必要になってくると考えられる．

4.3 TCPの下位層現在の TCPは下位層に対して次のような仮定をしている．

1. 下位層 (IP)は，TCPのヘッダとデータの合計の長さを知っている．

2. TCPは，下位層 (IP)が使用する送受信のネットワーク・アドレス (IPアドレス)と，TCPのプロトコル番号を知っている．

3. ラウンド・トリップ時間がしきい値を超えて長くなった場合は，セグメントは喪失している．

4. セグメントが喪失するのは，ネットワークが混雑しているからである．

1.と 2.はTCPのプロトコル上の仕様である．TCPヘッダにはデータの長さを示すフィールドはない．そのため，TCPセグメントの全長を下位層が知っていなければならない．このため，TCPの下位層がTCPのセグメントを送信するときに，パディングをする事は許されない．また，パディングをする場合には，下位層のデータ長とは別に，TCPセグメント長がわかるようにしなければならない．

TCPのチェックサムを計算するときには，TCPのヘッダとデータ以外に，送受信ホストのネットワーク・アドレス (IPアドレス)やTCPのプロトコル番号を含むTCP疑似ヘッダを作らなければならない．このため，TCPはデータの送受信時に，下位層から送受信ホストの IPアドレスやTCPのプロトコル番号を教えてもらう必要がある．そのため，TCP

は下位層と密接な関係にあるといえる．チェックサムを計算するときの疑似ヘッダは，IP

アドレスを入れることを前提に設計されており，かなり IPを意識してTCPプロトコルは設計されている．

3.はTCPが信頼性を提供する上での最も重要な役割である．TCPでは，TCPの下位層で，セグメントの喪失や順序の入れ替わり，重複が発生することを想定した設計がされている．それぞれ，次のように実装することでこれらの性質に対応できるようになっている．


• セグメントの喪失

セグメントが喪失したと判断されるときにはそのセグメントを再送する．

• 順序の入れ替わり

到着したセグメントのシーケンス番号が受信可能なウィンドウ内であれば，受信したデータ破棄しないでバッファに格納する．

• 重複

先に到着したセグメントを優先し，後から到着したセグメントは破棄する．

下位層が輻輳制御や再送制御，誤り制御などをして，ネットワークの利用効率を向上させようとしたとしても，その結果，確認応答が到着する時間が TCPの再送タイムアウトの時間を超えると，逆にネットワークの利用効率は悪くなる．このため，TCPの場合には下位層がきめ細かな制御をすると逆に問題となる可能性がある．このことは，TCPの再送アルゴリズムにより，下位層に許される処理時間や，処理時間の揺らぎの限界を規定しているといえる．つまり，輻輳状態になった場合，ルータ内でのセグメントの滞在時間が長くなるが，この時間が TCPの再送タイムアウトの時間を超えるほど長くなる場合には，パケットをすみやかに廃棄してネットワークの混雑を緩和するように処理をした方がよい．つまり，ルータが極端に巨大なバッファを持っていても，TCPによる性能が向上するとは限らないのである．

4.はTCPの輻輳制御である．TCPの仕様では，一定時間たっても確認応答されないというタイムアウトが発生した場合には，セグメントが輻輳によって喪失したと判断し，再送処理をするとともにスロー・スタート制御をしなければならない [21]．現在のほとんどすべての TCPの実装では，確認応答のタイムアウトは輻輳が原因でセグメントが喪失したと決めつけ，スロー・スタートする．これは，ビット誤りによるセグメントの喪失時にもスロー・スタートすることを意味する．現在のネットワークは，品質が向上しビット誤り率は低下する傾向にある．しかし，近年，性能の向上と普及が急速に進んでいる無線通信の場合には，ビット誤りが発生する可能性が高い．また，有線による通信と比べると，無線による通信はビット誤り率を低下させる工夫にも限界があると考えられる．こう考えると，今後，インターネットで無線ネットワークが広く使われるようになると，TCPの輻輳制御は必ずしも正しく機能するとは限らない．

TCPにはチェックサムによりデータの信頼性を確保する仕組みが備えられている．そして，受信ホストでチェックサムの計算が合わない場合には，ICMPエラーメッセージで，送信ホストにチェックサムエラーが発生したことを通知する．この ICMPエラーメッセージは，セグメントが喪失したのは輻輳が原因ではないことを意味している．この ICMPエラーメッセージを送信ホストが受け取ったときには，スロー・スタートせずにエラーのセ


Router

Host Host

分割される

MTUが大きなネットワーク MTUが小さなネットワーク

分割される

Router

Host Host

MTUが大きなネットワーク MTUが小さなネットワーク

そのまま転送される

パケットは捨てられ，ICMP Unreachableメッセージが返される。同時に，次のデータリンクのMTUが伝えられる。

再構成される

再構成される

X全ての送信パケットに分割禁止フラグをセット

1MTU

1MTU 1MTU

1MTU

通知されたMTUを基に送信

図 4.2 フラグメント処理をする場合 (上)と経路MTU探索をする場合(下)の TCPデータセグメントの流れ

グメントを再送するように実装することは可能である．しかし，これでもデータリンクのビット誤りには対応できない．データリンクの誤りの場合には，データリンクのFCSのチェックでフレームが廃棄され

るため，TCP層にはデータが喪失されたことは伝えられないからである．そのため，TCP

がビット誤りでデータが喪失したのか，輻輳でデータが喪失したのかを知る手段はない．TCPのチェックサムは，データリンクのビット誤りの検査というよりは，ルータなどのソフトウェアのバグによって，データが書き換えられたことを検出するのが目的になっていると考えられる．


4.3.1 経路MTU探索 (Path MTU Discovery)

MTUの大きなネットワークからMTUが小さなネットワークへデータが送信されるときには，IPフラグメントの処理が行われる場合がある．IPフラグメント処理の例を図 4.2

の上の図で説明する．MTUが大きな左のネットワークから，MTUの小さな右のネットワークへ，右のネットワークのMTUを超える大きさの IPデータグラムが送信されると，ルータでフラグメント処理が行われる．フラグメント化された IPデータグラムは，受信ホストで集められ再構成され，元の IPデータグラムへ復元される．経路MTU探索 (PMTUD: Path MTU Discovery)[54]とは，終点ホスト間の最小のMTU

を求める機構である．通常，TCPではコネクション確立時のMSSオプションによってMSS

の値を決定するが，経路MTU探索を使用する場合には，経路MTU探索によって求まった経路MTUをもとにして TCPのMSSの値が再設定される [26]．図 4.2に，経路MTU

探索が行われる場合 (下)の動作について図示した．この場合は，ルータは分割処理を行わず，ICMP到達不能メッセージのコード 4，分割要求を返送する．この ICMPには，通常は次のデータリンクのMTUの値が書き込まれている．この ICMPを受信した送信ホストは，この経路MTUの値をもとにしてMSS(最大セグメント長)の値を変更し，IPフラグメントが発生しない最大のセグメント長でデータを送信する．近年，IPプロトコルに経路MTU探索が実装されるようになってきた．経路MTU探索

が実装されていない場合には，512octetや 536octetなど，フラグメントが起きる可能性の小さいな値を TCPの最大セグメント長に決定していた．しかし，実際にインターネットで行われる通信では，経路MTUの大きさは 1500octet前後が大半を占めることが知られている [55]．このような小さな値をMSSとして利用するとデータの転送効率が低くなる．しかし，経路MTU探索の実装により，512や 536octetよりも大きなセグメント長でデータ転送をすることができるようになった．その結果，ネットワークの利用効率が向上するとともに，スループットが向上すると見込まれる．

IPv6では，ルータは IPデータグラムのフラグメント処理を行わない．ルータが次の経路のMTUよりも大きな IPデータグラムを受信した場合には，その IPデータグラムを破棄し，ICMP到達不能メッセージを返送する．ルータが IPフラグメント処理をしなくなるのは，ルータの負荷を低減するのが目的である．近年のルータは，莫大な量の経路制御表を検索しなければならず，また，フィルタリングなどのセキュリティ機能を処理しなければならない．このように，インターネットの発達によって，ルータがやらなければならない処理は増える一方である．このため，ルータの性能を向上させることが強く望まれているが，ルータがありとあらゆる処理をしなければならないのであったら，ルータの処理能力を向上させることはできない．つまり，ルータがしなくてもかまわない処理は，ルータではなく別の機器がやるべきである．ネットワークを高速化するためには，ルータの処理の負荷を下げ，パケット転送能力を向上させなければならない．このために，IPv6のルー


タは，IPのフラグメント処理や，IPチェックサムの処理を行わないことが決められた．経路MTU探索では，データの送信後に経路MTUが決定される．つまり，TCPの最

大セグメント長は，TCPのコネクション確立時にMSSオプションを利用して決定されるが，そのときには経路MTUの値は分からない．経路MTU探索をする場合には，MSSオプションで決定された値で通信が行われるとは限らない．経路MTUを基にしたMSSの値で通信が行われるからである．もともとの TCPは，プロトコルの仕様上，終点ホスト間の最大セグメント長は同一になるはずであった．ところが，経路MTU探索を行う場合には，終点ホスト間の最大セグメント長は異なることが起こりうる．これは TCPの挙動に不具合を発生させる可能性がある．TCPの遅延確認応答処理では，データを 2MSS受信するたびに確認応答する事が決められている．このMSSの値は，経路MTU探索によって変更される可能性がある．しかし，現在のTCPの実装では，MSSの値が変更されても相手のホストには伝えられない．その結果，環境によっては，今までの通常の TCPとは確認応答の挙動が変化する可能性がある．本研究では，実際の実装とネットワーク環境を利用して経路MTU探索の実験を行った．

この実験の結果，経路MTU探索は，TCPの性能を低下させる新たな問題となることが明らかになった [57]．さらに，実際にインターネットで利用されている複数の実装に，この経路MTU探索の影響と思われる不具合 (バグ)があることが明らかになった．

4.3.2 経路MTU探索の実装の問題

経路MTU探索が必要となる LAN環境においてデータ転送を行いデータ転送の挙動を測定した．実験 1と 2は，本研究で提案する DBS (Distributed Benchmark System)[61]

を利用して測定実験を行った．実験 3，4，5は，FTP (File Transfer Protocol)[46]を利用してファイル転送を行い，そのときのパケットの流れを tcpdumpコマンドを利用してモニタした．

実験 1

実験 1は，図 4.3のような環境で実験を行った．DBSでデータ転送を行い，シーケンス番号の推移とスループットを測定した結果を図 4.4と図 4.5に示す．図を見ると分かるように，データ送信開始後，約 0.9秒間はデータが間欠的にしか送信

されておらず，スループットが極端に小さいことがわかる．この原因は次のように考えると説明できる．コネクション確立時には，最大セグメント長は次の値に決定される．

MSSsender = MSSreceiver = 4312(octet) (4.1)


MTU=1500

Sender

Router

MTU=9180

ATM

NEWS 5000NEWS-OS 6.1

Ethernet FDDI LAN

Router

MTU=4352

CiscoAGS+Cisco7000

CHALLENGE XLIRIX 5.3

Receiver

図 4.3: 実験 1の環境

しかし，経路MTU探索により送信ホストの最大転送単位がMTUsender = 1500octetになる．その結果，送信ホストの最大セグメント長はMSSsender = 1460octetになり，このMSS

単位でスロー・スタートを行う．受信ホストはデータを 2MSS，すなわち 2MSSreceiver =

8624octet受信するまで遅延確認応答をする．その結果，送信ホストの輻輳ウィンドウwin

が次の式を満たすまで，確認応答が遅延されることになる．

win × MSSsender > 2 × MSSreceiver = 8624(octet) (4.2)

この式はwin = 6になるまで成立しない．輻輳ウィンドウは 1つの確認応答ごとに 1つ大きくなるため，最初の 6パケットは確認応答が遅延されることになる．遅延確認応答が0.2秒の場合には，この期間は 0.8秒～1.0秒になる．その結果，通信開始時からこの期間はスループットが極端に低下する．スループットが極端に小さい期間は，MSSオプションで決定した最大セグメント長と，経路MTUの値の差が大きければ大きいほど長くなる．遅延確認応答の遅延時間を Tdelayとすると，スループットが極端に小さくなる期間 T はおおよそ次の式で表される．

T = 2 × Tdelay ×MSSreceiver

MSSsender(4.3)


0

20000

40000

60000

80000

100000

0 0.2 0.4 0.6 0.8 1 1.2

Tot

al D

ata

Time (s)

図 4.4: シーケンス番号

0

2

4

6

8

10

0 0.2 0.4 0.6 0.8 1 1.2

Thr

ough

put (

Mbp

s)

Time (s)

図 4.5: スループット


MTU=1500

Sender

Router

MTU=9180

ATM


Ethernet FDDI LAN

Router

MTU=4352

CiscoAGS+Cisco7000

ReceiverDEC5900

ULTRIX 4.4


実験 2

実験 2は，図 4.6のような環境で実験を行った．これは実験 1とほぼ同じ環境であるが，データを受信するホストのハードウェアとオペレーティング・システムが異なる．DBSでデータ転送を行い，シーケンス番号の推移とスループットを測定した結果を図 4.7と図 4.8

に示す．図を見ると，実験 1とは異なり，データ送信開始後，約 0.4秒間だけデータが間欠的に

送信されいる．これは，2MSS受信するたびに確認応答をするのではなく，2つのセグメントを受信すると確認応答をするように受信ホストの遅延確認応答が実装されているからだと予想できる．


0

20000

40000

60000

80000

100000

0 0.2 0.4 0.6 0.8 1 1.2

Tot

al D

ata

Time (s)

図 4.7: シーケンス番号

0

2

4

6

8

10

0 0.2 0.4 0.6 0.8 1 1.2

Thr

ough

put (

Mbp

s)

Time (s)

図 4.8: スループット


Router

Ethernet LANMTU=1500

Sender

ATM LAN

RouterCisco7000

MTU=9188

ATM


Receiver

SPARCstatopmIPXSunOS 5.4

MTU=9188

SPARCstation 20


実験 3

実験 3は，図 4.9のような環境でFTPによりデータ転送を行った．SenderからReceiver

へ FTPでファイル転送を行い，途中の Ethernetで tcpdumpコマンドによりパケットをモニタした．結果を図 4.10に示す．結果を見ると，セグメントが喪失していないにもかかわらず，タイムアウトをするとい

う現象がみられる．1セグメント送るごとに，1秒，2秒，4秒，8秒，16秒と 5セグメント送るまでタイムアウトが続いた．その後は少なくとも 0.1秒を超えるような間隔があいたデータ転送は観測されなかった．合計 30秒以上にわたりデータ転送が間欠的に行われており，その間のスループットは極端に低下している．0～30秒までのスループットは約3kbpsである．その後は 3Mbps以上のスループットになっている．この実験環境の場合には，最初の 30秒間は通信性能が 1000分の 1以下に低下している．この実験から，送信ホストの実装には明らかに不具合がある．経路MTU探索を実装し

たときにこの不具合が発生することになったが，十分なテストが行われていなかったため不具合が含まれたまま出荷されたと予想できる．


¶ ³00.889855 sparc.20 > news.44475: S (0) win 27420 <mss 9140> (DF)

00.893807 news.44475 > sparc.20: S (0) ack win 54840 <mss 9140> (DF)

00.895199 sparc.20 > news.44475: . ack 1 win 27420 (DF)

01.415856 sparc.20 > news.44475: . 1:1449(1448) ack 1 win 27512 (DF)

01.482157 news.44475 > sparc.20: . ack 1449 win 54840 (DF)













...........µ ´図 4.10: 実験 3の測定結果


Router

EthernetFDDI LAN

MTU=1500MTU=4352

Sender

Cisco7000

MTU=9188ATM

RouterAlpha Station

DEC OSF/1 V3.2A

ReceiverUltra Enterprise 3000server

SunOS 5.5.1

SPARCstatopmIPXSunOS 5.4


実験 4

実験 4は，図 4.11のような環境で実験を行った．Senderから Receiverへ FTPでファイル転送を行い，途中のEthernetで tcpdumpコマンドによりパケットをモニタした．結果を図 4.12に示す．結果を見ると，3つ目のデータパケットが送信されていないことが分かる．これだけで

も異常であるが，再送が行われるのは 20秒後である．通常，TCPは再送タイマの最小値を 1秒に設定する．今回の LANのような環境では，通常，タイムアウトによる再送は 1

秒後に行われる．しかし，20秒間も再送が停止している．これは，この実装の不具合だといえる．この現象も実験 3と同様に，TCP/IPの実装に経路MTU探索を加えられたことにより，

TCPの実装に不具合が発生したと考えられる．しかし，十分なテストが行われておらず，この不具合を発見できないまま出荷されたと考えられる．


¶ ³00.092628 sun4.20 > ultra.59704: S (0) win 24576 <mss 9148>

00.093642 ultra.59704 > sun4m.20: S (0) ack win 17248 <mss 4312> (DF)

00.094461 sun4.20 > ultra.59704: . ack 1 win 24576

03.065254 ultra.59704 > sun4.20: . 1:1461(1460) ack 1 win 26280 (DF)

03.068063 sun4.20 > ultra.59704: . ack 1461 win 24576


08.870476 sun4.20 > ultra.59704: . ack 2921 win 24576


09.070543 sun4.20 > ultra.59704: . ack 2921 win 24576


20.075180 sun4.20 > ultra.59704: . ack 5773 win 24576


20.078917 ultra.59704 > sun4.20: P 7233:8193(960) ack 1 win 26280 (DF)

20.275262 sun4.20 > ultra.59704: . ack 8193 win 24576



20.475343 sun4.20 > ultra.59704: . ack 11113 win 24576




20.675443 sun4.20 > ultra.59704: . ack 15493 win 24576

...........µ ´図 4.12: 実験 4の測定結果


MTU=1500

Sender

Router

MTU=9180

ATM


Ethernet FDDI LAN

Router

MTU=4352

CiscoAGS+Cisco7000

CHALLENGE XLIRIX 5.3

Receiver


実験 5

実験 5は，図 4.13のような環境で実験を行った．途中のEthernetで tcpdumpコマンドによりパケットをモニタした結果を図 4.14に示す．

0.874041秒，0.874248秒，0.874456秒のパケットは確認応答パケットである．しかしこれは，データを受信しているホストではなく，データを送信しているホストが送信している．データを送信しているホストは，コネクション確立時の SYNパケットに対する確認応答以外に確認応答を送信する必要はない．しかし，実験 5では，送信側が複数の確認応答パケットを送信することが観測された．これは，明らかにデータを送信しているホストの実装の不具合である．しかもこの後，データ転送が終了するまで，たくさんの確認応答パケットが送信される現象が観測された．コネクション確立時の SYNパケットに対する確認応答はすでに送信済みであり，新たに

送信するのは TCPのプロトコルに違反している．ただし，大きな問題とはならないと予想されるが，トラヒックが増加されネットワークの帯域を無駄に利用していることになる．


¶ ³00.086404 news.20 > sgi.3871: S (0) win 0 <mss 9140,wscale 0,eol> (DF)

00.088218 sgi.3871 > news.20: S (0) ack 1 win 61440 <mss 4312,nop,wscale 0>

00.089362 news.20 > sgi.3871: . ack 1 win 56056 (DF)

00.098010 news.20 > sgi.3871: . 1:1449(1448) ack 1 win 56472 (DF)

00.269968 sgi.3871 > news.20: . ack 1449 win 61440



00.470188 sgi.3871 > news.20: . ack 4345 win 61440




00.670320 sgi.3871 > news.20: . ack 8193 win 61440





00.870186 sgi.3871 > news.20: . ack 13985 win 61440






01.070212 sgi.3871 > news.20: . ack 16385 win 61440

...........µ ´図 4.14: 実験 5の測定結果


4.3.3 経路MTU探索の実験のまとめ

1～5の実験から，IPに経路MTU探索が追加されたことにより，TCPに新たな問題を生じさせていることが明らかになった．

1，2の実験から，IPに経路MTU探索機構が追加されると，TCPによるデータ転送開始時に短期的なデッドロックが発生することが明らかになった．これを修正するためには，TCPプロトコルのアルゴリズムに修正を加えなければならない．

3，4，5の実験から，IPの実装に経路MTU探索機能が追加されると，TCPが異常動作する場合があることが明らかになった．今回利用したオペレーティング・システムは，正規製品版として販売されているものであり，テスト用のバージョンではない．製品版はかなりのテストがされていると予想されるが，TCPの細かい不具合まではきちんと検査し切れていないことが明らかになった．今後は，TCPを改善すると共に，経路MTU探索を実装したオペレーティング・システ

ムの動作を検査する必要がある．

4.4 まとめTCP/IPの実装モデルでは，TCPや IPなどのインターネットの基盤となるプロトコル

を，オペレーティングシステムの内部に実装するモデルになっている．このため，TCPやIPのプロトコルの変更作業は簡単ではない．このことから，TCPの性能改善のためには次の 2つの点を考慮することが大切である．

• TCPで改善することと，TCPの下位層および上位層で解決することを明確に分離する．

• TCPの実装の検査，性能の評価をするツールが必要である．

ネットワークのプロトコルは，OSI参照モデルに象徴されるように，階層化されて仕様が決められる．そして，それぞれの階層単位や，それらをさらに細分する形で実装されることが多い．しかし，この様な階層化を行うと，特定のプロトコルの仕様や実装の変更が，別の層に悪影響を及ぼすことがある．この章では，IPに経路MTU探索が実装された結果，TCPによるデータ転送に新たな問題が発生していることを示した．この問題には，TCP

のプロトコルへの問題点と，TCPの実装の不具合という 2つの側面をもっている．TCPや IPのプロトコル・スタックは，階層化されて仕様が決定され，ほとんどの実装

でTCPと IPは分離されて実装されている．現在，IPの version 6に関する仕様の決定と実装作業が行われているが，TCPの仕様は変更されない見込みである．これは，TCPとIPの実装が分離されていることにより，IPv6の実装を楽にする効果があると考えられる．しかしこのことは，TCPへの新たな問題を発生させる危険性がある．実際に，この章の

4.4 まとめ 69

示した実験の結果，問題が生じていることは明らかである．これ以外にも，TCPの上位層や下位層のプロトコルや実装が，TCPの挙動に影響し，データ転送の性能を悪化させることも十分に考えられる．このことから，TCPを改善したり，TCPの下位層や上位層に変更が加えられた場合に，階層モデル全体を通して問題が発生しないかどうか検証する必要がある．

PART III

TCPの実装検査と性能評価

第 5 章 TCPの実装と性能の評価p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

この章では，インターネットにおける TCPプロトコルの実装の意味と，プロトコルの実装の評価や性能の評価の意味について考察する．

5.1 インターネットにおける実装の意味インターネットでプロトコルが開発される時には，実装が重視され，実際に実装して動

作するかどうかが問われる．これは，提案されたプロトコルがどんなにすばらしく思えても，実現不可能なものであれば意味がないからである．現実のインターネットでは，莫大な数のコンピュータが接続され，これらのコンピュー

タの間で自由な通信が行われている．現在のインターネットでは，WWWなどのインタラクティブな要求に対するデータ配送という，オン・デマンド的なネットワーク・アプリケーションの普及により，ユーザの要求によって必要なときに必要な量の通信が行われる傾向が強くなってきた．個々の通信に対する通信量の制限は行われないため，ユーザの活動パターンに応じてトラヒック量が変動したり，突発事項などが発生したときにはユーザからの要求が集中することがある．インターネットでは，網側にはトラヒックの管理や制御機構はなく，ユーザ指向で通信サービスが行われる．このため，莫大な数の通信が不定期的に行われる可能性があり，インターネットのプロトコルにはスケーラビリティが要求される．インターネットで利用するプロトコルは，実際のインターネットの環境を考慮したプロトコルでなければならず，インターネットで実際に動作するプロトコルでなければ意味がない．また，TCPのプロトコルをどんなに素晴らしいものに改良したとしても，実際に使わ

れているコンピュータの能力や資源では実装不可能であったり，実装が非常に困難で，現実的とは考えられるような莫大な人員や時間を必要とするものであったとしたらインターネットでは受け入れられない．インターネットでは，現実的な時間内に実装が可能で，しかも現実的な計算機資源で動作し，実用的な範囲で運用が可能なプロトコルが求められているのである．つまりインターネットのプロトコルは，実際に利用できるプロトコルでなければならず，それを無視した提案は無意味である．このような理由から，TCPを議論するときには，実装して評価することが非常に重要である．このように，インターネットでプロトコルを提案する場合には，実装にかかる期間や工

数，実装したソフトウェアの品質も考慮しなければならない．実装が極端に複雑にならざ

73

74 第 5章 TCPの実装と性能の評価

るを得ないプロトコルは，あまりよいプロトコルとはいえない．このようなプロトコルの場合には，実装に莫大な時間がかかり，また不具合が解消されるまでに長い年月がかかる可能性がある．その結果，プロトコルの仕様自体は素晴らしいものに思えても，実際にそのプロトコルを利用できない可能性がある．思想や仕組み，機能がどんなに優れたプロトコルを提案したとしても，それを実装するのに数 10年もかかるのであれば，そのプロトコルは必ずしもよいプロトコルとはいえない．特にトランスポート・プロトコルの性能は，そのプロトコルだけではなく，データリンクの性能や帯域，終点ホストのCPUやメモリ，バス，オペレーティング・システムの性能が大きく関係している．トランスポート・プロトコルの改善に数 10年もかかった場合，データリンクの性能の著しい改善により，変更前のトランスポート・プロトコルでも問題が全く発生しないという可能性がないとはいえない．逆に，プロトコル自体に幾つかの微細な問題があったとしても，実装が簡単ですぐにインターネットで利用可能になるプロトコルの方が効果的で実用性が高く，インターネットに受け入れられる可能性が高い．現在のインターネットは，実験ネットワークではなく運用ネットワークであり，すべて

のプロトコルの実装を短期間で変更することは不可能である．また，メンテナンスが行われなくなった古いシステムも存在する．インターネットではシステムによらずに通信できることが望まれ，プロトコルの互換性や相互接続性が非常に重視される．新しいプロトコルが従来のプロトコルに悪影響を与えたり，従来のプロトコルとの相互接続が不可能であるならば，インターネットの世界にはなかなか受け入れられない．このように，インターネットでは動く実装が重視され，動くプロトコルが使われてきた．

その結果，巨大なインターネットを構築でき，商用ネットワークとして実務に耐えうるプロトコルを開発できたと考えられる．

5.2 実装評価と性能評価の必要性インターネットにはプロトコルを検査する機関は存在しない．インターネットのプロト

コルの標準化では，実装を重視しながらも，各々の実装は，相互接続性に関するテストが行われるだけで，それ以上のテストはほとんど行われない．このため，パーソナル・コンピュータのアプリケーション・プログラムと同じように，その品質は開発や製造した会社を信頼するしかない．通常のソフトウェアの場合は，そのソフトウェアを開発する会社がソフトウェアに不具合がないかを検査する．しかし，インターネットの場合には，各ソフトウェア会社内のテストに頼るだけでは，問題が発生する可能性がある．これは，プロトコルの仕様を各ソフトウェア会社が決めたのではなく，IETFでの標準

化活動を通して決定されたものだからである．各ソフトウェア会社がソフトウェアを開発する場合には，開発する会社が仕様を決定しその通りにソフトウェアが作成される．仕様に曖昧性がある場合には仕様が見直されることもある．テストもその会社の内部で仕様を

5.3 TCPの実装検査に関する考察 75

熟知したものが行う．これらの行程のすべてはその企業の内部の活動として閉じており，互換性の問題などもすべて自社内で解決することができる．しかし，ネットワーク・プロトコルの場合には，一企業の内部の活動だけでは解決でき

ない問題がある．たとえ，プロトコルの実装がそのソフトウェア会社の内部のテストに合格したとしても，実際のインターネットで利用されたときに問題が起こらないことを保証するのは困難である．例えば，インターネットのプロトコルに関して次のような問題が実際に発生している．

• プロトコルの仕様を各ソフトウェア会社が完全に理解しておらず，間違った実装をすることがある．

• プロトコルの仕様に曖昧性がある場合，各ソフトウェア会社が独自の判断でソフトウェアを開発する可能性がある．

• 実装者がプロトコルをよりよく改善しようと考え，RFCに記述されているプロトコルの仕様とは異なる動作をするように実装することがある．

これらの例は実際のインターネット上で数多く観測される問題であり，これらの誤った実装によってトラブルが発生している．そして，問題が解決するまで，管理者や利用者に多大な労力や時間を浪費させ，大きな不利益をもたらすことがある．問題に度々直面する人々にとっては，インターネットがもたらす利益を大きく損なってあまりある大きな問題となっている．インターネットがますます巨大化し，ネットワーク管理やプロトコルの実装に関して十分に熟練した人以外の人々がインターネットにかかわってくると考えるならば，インターネットのプロトコルに潜在する問題を早急に解決することは急務である．

5.3 TCPの実装検査に関する考察TCPの内部の実装の一部の機能に関して検査する方法が提案されいる [56]．しかし，物

理的にネットワークを変えながら測定する方法であり，測定には多くの時間や手間がかかる．この章では，実装の内部の機能を調査する方法を拡張し，TCPの実装が正しく動作す

るかテストするツールの必要性と有効性に関して考察する．例として，経路MTU探索の実装に含まれる不具合と，それをテストするためのツールについて論じる．

5.3.1 経路MTU探索によるTCPの動作の検査システムの提案

7.1.4節で示したように，経路MTU探索が実装されているオペレーティング・システムには，不具合が含まれている場合がある．今回調査したオペレーティング・システムは，


経路MTU検査システム被検査システム

FTPやHTTPのコマンドを送信

ICMP到達不能メッセージを送信し経路MTUを疑似的に変更

要求に応じてデータを送信

新しいMTUをもとにMSSを変更してデータを送信

任意のネットワーク

図 5.1 経路MTU探索の実装検査ツールのシステム構成と動作概要

インターネットで利用されているオペレーティング・システムのごく一部であり，他の実装にも問題がある可能性がある．しかしこの不具合は，TCPプロトコルに精通しているものが，実験環境を構築して実験をしなければ明らかにすることができないような現象である．そのため，一般の利用者には，問題が発生していることが分からず，単にネットワークが遅く感じるだけである．このネットワークの遅さは，データ転送の時間を増加させ，作業の効率を低下させ，結果的に，社会的・経済的な損失をもたらすものである．しかも，TCPの問題なので，データリンクを高性能なものにアップグレードしたとしても，解決されるとは限らない．ユーザからみえにくい部分の問題であるため，問題が発生しているか，また，問題が発生する可能性のある実装なのかを事前にチェックする必要がある．

TCPや IPの実装の問題を調査するツールがあれば，TCPや IPの実装評価が楽になり，不具合が含まれる実装を減らすことができる．そして，多くのネットワークで期待される性能が得られるようになると考えられる．理想的には，TCPのすべての機能を評価するツールを作成する必要があるが，この章では，不具合が含まれる可能性が非常に大きいと考えられる経路MTU探索に関する評価ツールについて議論する．経路MTU探索の実装を検査するツールを作成し，インターネットに接続されているホ

ストの実装を調査することは，TCPの検査ツールの有効性を示す上で非常に有益なことであると考える．経路MTU探索のツールとして，図 5.1に示すようなシステムを提案する．システムは，検査をするプローブ・システムと，検査を受ける被検査システム，そしてそれらを接続するネットワークから構成される．この検査システムの動作の概要を説明する．

1. 検査システムから被検査システムへ，コネクションの確立を要求する．

2. TCPのスリー・ウェイ・ハンドシェークによりコネクションが確立される．このときMSSオプションにより，MSSの値が決定される．

5.3 TCPの実装検査に関する考察 77

3. 検査システムから，被検査システムへデータ送信を要求する命令を送信する．

4. 被検査システムから送信されたデータを破棄し，ICMP 到達不能メッセージを送信する．

このシステムにより，疑似的に，経路MTUが異なるネットワークが接続されたトポロジーを作成することができ，そのときの TCPの挙動を検査することが可能になる．この TCP実装検査システムでは，独自に開発したTCP検査プログラムを利用するが，

被検査システムはメーカから提供されているシステムをそのまま利用する．検査システムと被検査システムの間の通信はHTTPや FTPを利用することを考えている．本システムを利用して経路MTU探索の検査をする場合には，被検査システムにHTTPや FTPが実装されていることが要求される．逆にいえば被検査システムにHTTPや FTPが実装されていれば，経路MTU探索に関する検査を行うことができる．アプリケーション・プロトコルにHTTPや FTPを想定したのには理由がある．被検査

システムには，パーソナル・コンピュータやワークステーション，スーパーコンピュータなどのソフトウェア開発が可能なコンピュータだけではなく，ソフトウェア開発が困難なPDAなどの携帯型の端末類も含まれる．また，今後，各メーカから登場することが予想されるネットワーク・コンピュータ (NC)も対象にしている．TCPの検査システムは，対象とするホストの実装によらずに利用できることが必要である．そのため，ソフトウェア開発環境が提供されていないシステムや，ソフトウェア開発環境が高価なシステムの場合は，検査ツールを作成できない可能性が大きくなる．また，検査ツールをC言語などの非常に移植性の優れた言語で記述してあったとしても，システムが異なれば全く同一のソフトウェアが動作しないことは多い．そうなると，移植の作業にも多くの時間や工数が必要になる．検査ツールの移植に時間をとられれば，TCPを検査すること自体が困難になる．検査ツールの作成をそれぞれの企業に義務づけることができれば解決できるが，これは，現在の自由でプロトコル検査機構のないインターネットでは実現不可能なことだといわざるを得ない．これらのことを総合的に考えると，最も一般的なアプリケーション・プロトコルを利用して，可能な限りの TCPの検査をするツールを開発することが，現実のインターネットの TCPプロトコルの検査にとってもっとも実用的な方法だと考えられる．また，このシステムでは，本当の経路MTU以下にしか経路MTUを変化させることが

できないが，中間のネットワークの形態によらずに，疑似的に経路MTUを変化させることができる．このツールを使えば，インターネットで実際に運用されているるWWWサーバや匿名 FTPサーバを検査することができる．つまり，世界中のWWWサーバや FTP

サーバの実装を検査することで，インターネットで稼働している大部分のオペレーティング・システムの実装検査が可能になる．


5.3.2 TCP実装検査ツールに求められる機能

経路MTUの検査以外にも TCPの様々な検査ができる必要がある．検査できる項目は多ければ多い方がよいが，必要なのはそれだけではない．検査はできるだけ自動的に行われ，検査の結果はどのような問題が発生しているか具体的に分かることが望ましい．検査の設定が非常に複雑であれば，検査自体が困難になる．また，結果をみても，TCPプロトコルを知りつくした人でなければ不具合があるかどうかを判断できないのであれば，それは，役に立つ検査ツールとはいえない．TCPの実装検査ツールは，簡単な設定で動作し，不具合箇所を具体的に示してくれる必要がある．

5.4 TCPの性能評価に関する考察 79

5.4 TCPの性能評価に関する考察TCPの性能改善に関する研究が数多く行われている．この節では，TCPの性能改善の

評価手法について議論する．TCPの性能評価手法には，シミュレーションによる方法と，実際のデータ転送を観測

する方法の 2つがある．実在しないネットワークの評価ならば，シミュレーションは非常に有効な手法だといえるが，広く利用されるようになった TCPの場合には，特に優れた手法とはいえない．また，TCPの性能は，TCPのプロトコルやアルゴリズムだけで決まるのではなく，その実装や，OSでのメモリ管理，コンピュータ・アーキテクチャ，データリンクの特性などが関係することが，最近の研究から明らかになっている [29]．しかし，既存の ns[58]やREAL[59]などの TCPのシミュレータでは，データリンクの特性やコンピュータ・アーキテクチャなど，実装面の細かい部分まではシミュレートできていない．これらのことから，今後の TCPの性能評価では，実際にデータ転送を行って測定する評価手法が重要になってくると考えられる．

5.4.1 TCP性能測定ツールに求められる機能

現在のインターネットの利用形態を考慮すると，TCPの性能測定ツールには次の機能が求められる．

1. アプリケーション・レベルのスループットを測定できる．

TCPの性能改善の目標は，終点アプリケーション間で通信性能を向上させることである．ネットワーク中をどのようにデータが流れようとも，通信を行う終点アプリケーションにとって十分なスループットが得られればよい．そのため，TCP性能測定ツールは，アプリケーション・レベルのスループットを測定できる必要がある．

2. 通信経路のデータリンクの種類によらずに利用できる．

インターネットでは，Ethernetや FDDI，ATM，X.25，専用回線，ISDN，Frame

Relay，Fiber Channelなど，さまざまなデータリンクが利用される．TCPは IPの上位層のプロトコルであり，IPデータグラムを転送できるあらゆるデータリンクで利用される可能性がある．そのため，TCP性能測定ツールは，通信路上のデータリンクの種類によらずに利用できる必要がある．

3. 複数のコネクションを同時に確立し，同時にデータ転送を行うことができる．

パケット・ネットワークのもっとも重要な役割は，ネットワークを構成するハードウェアの共有である．実際に，インターネットでは，たくさんのコネクションが確立され，複数のデータ転送が同時に行われている．TCP性能測定ツールでは，これを模倣できる必要がある．


4. ネットワークの負荷を変化させることができる．

ネットワークの負荷は一定ではない．負荷の小さい状態や，負荷の高い状態，輻輳の状態など，トラヒック量は動的に変化する．このため，TCPの性能測定ツールは，負荷の低い状態や負荷の高い状態を作り出せる必要がある．

5. ネットワークの負荷の変動が，データ転送に与える影響を測定できる．

ネットワークの負荷の変動は，データ転送に影響を与える．そのため，TCP性能測定ツールは，その影響を測定できる必要がある．具体的には，各々のデータ転送のシーケンス番号の時間推移やスループットの時間変化などを測定できる必要がある．また，マルチメディア通信の評価にとっては，遅延時間の時間変化や遅延時間の揺らぎの時間変化等を測定できる必要がある．

6. TCPの制御機構の評価ができる．

TCPにはフロー制御，再送制御，そして輻輳回避制御の 3つの制御機構がある．これらはTCPの性能を決定する大きな要素となっている．フロー制御は，受信ホストが受信可能な最大のスループットに制御する機構である．再送制御は，セグメントが喪失したかどうかを予測して，再送処理をするための機構である．そして輻輳回避制御は，ネットワークの混み具合に合わせてセグメントの送信量を制御し，セグメントの喪失を防ぐ機構である．これらの 3つの制御機構が協調して動作しなければ，ネットワークを有効に利用し，かつ，最大限のスループットを得ることはできない．そのため，TCP性能測定ツールは，TCPの制御機構の評価ができなければならない．

5.4.2 既存の性能測定ツールとその問題点

これまで，TCPの性能評価を目的として，ttcp，Netperf[64]，nettest，NetSpec[65] といった性能測定ツールが開発されている．

ttcp，Netperf，nettestでは，2点間のホストでデータ転送をしたときに，最大どれぐらいのスループットになるかを測定できる．得られる結果は，アプリケーションレベルのスループットの平均値である．2点間のホストでデータ転送をしただけでは，通常はネットワークの負荷は変化せず，セグメントの喪失も起こらない．これらのツールでは，5.4.1

節の 1と 2の機能は備えられているが，3，4，5，および 6の機能が欠けている．NetSpecは，2点間のデータ転送だけでは高速ネットワークの帯域のすべてを使い切る

ことはできないということに着目し，複数のホストが同じデータリンクで同時にデータ転送をしたときに，データリンクの帯域のすべてを使い切れるかどうかを測定する目的で作られた．しかし，このNetspecでは，すべてのコネクションのデータ転送が同時に行われ

5.5 まとめ 81

るため，通常，ネットワークの負荷は変化しない．また，変化したとしても，得られる結果は他のツールと同様にスループットの平均値である．このため，ネットワークの負荷の変化が，データ転送に与える影響を調査することはできない．このツールでは，5.4.1節の 1，2，3の機能は備えられているが，4，5および 6の機能が欠けている．これらの性能測定ツールは，スループットは変化せず，セグメントの喪失もないといっ

た仮定のもとで，特定のデータリンク上でTCP/IPプロトコル・スタックを使用したときの，平均スループットを測定しているに過ぎない．TCPの性能改善を目指した設計がされておらず，TCPに潜在している問題点を明らかにするためには機能が不足している．ただし，手作業などで，時間間隔を空けてこれらのツールを複数起動させれば，ネット

ワークの負荷を変化させることができる．また，ネットワーク・アナライザによるパケットのモニタリングや，tcpdumpコマンドによるパケットの収集を行えば，ネットワーク中を流れるパケットの挙動の変化を測定することもできる．しかし，手作業による実験では，測定結果の再現性を調べるための再実験や，設定変更前後の比較のための実験が困難になる可能性がある．複雑な実験になればなるほど，手作業で同一の実験を精度よく複数回繰り返して行うことは困難である．また，パケットのモニタリングや，パケットの収集による解析手法では，TCP/IPが利

用されるあらゆるデータリンクに対応できる統一的なシステムを構築するのは困難である．通常，アナライザは特定のデータリンクにしか対応しておらず，また，tcpdumpコマンドはブロードキャスト型のネットワーク以外では利用できない．利用できたとしても，データの送受信を行うホストで別のプロセスとして実行しなければならないため，大きな負荷となり測定結果に影響することになる．しかも，これらの手法では，アプリケーションレベルのデータ転送の挙動の変化を測定していることにはならない．モニタリングやパケットの収集は，ネットワークを流れるトラヒックの挙動を分析するためには優れた手法といえるが，オペレーティング・システムのメモリ管理や，コンピュータ・アーキテクチャの評価を含めた，TCPによるデータ転送の性能を総合的に評価していることにはならない．以上のことから，異なる環境下でも同じ実験・測定ができる単一のシステムが必要だと

いえる．

5.5 まとめTCPは様々なOSで利用されている．それぞれのOSでTCPの実装には若干の違いが

ある．さらに，実装に不具合がある TCPもインターネットでは利用されている．不具合が含まれるTCPが利用されているのは，TCPの実装の検証方法が確立されていないためだと考えられる．現在，IPv6の実装が様々なところで行われている．この IPv6の実装の検査は，いくつ

かのツールを作成してそれを使う場合もあるが，多くの場合は手作業でコマンドを入力す


るという原始的な方法で，動作チェックが行われている．TCPに限らず，TCP/IPプロトコル・スタック全体において，実装の検査や評価は十

分には行われていない．オプションが設定された IPパケットや巨大な ICMPエコーメッセージなど，特定のパケットを受信すると，システムが異常終了するというオペレーティングシステムが発見されて話題になったことがある．通常のソフトウェアの開発と異なり，ネットワークのプロトコルの場合は，同じ仕様の

ソフトウェアが様々なソフトウェア・メーカや，研究機関などで開発されている．このため，不具合を調査する共通のソフトウェアを作れば，ソフトウェアの開発にかかる期間の短縮や，隠れた不具合の除去が可能になると考えられる．また，TCPの送信アルゴリズムによっては，ネットワークの利用帯域の公平性を崩すような実装も可能である．今後，TCPの内部の実装を調査することが，より重要なことになってくると考えられる．そして，検査するツールを作成し，インターネットに接続される実装を監視し，実装に問題がないかどうかを監視することが必要である．

第 6 章 TCPの性能評価システムの提案・実装・評価p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

この章では，5.4節で述べた，TCPの性能評価を実現するためのシステムとして，DBS

(Distributed Benchmark System)を提案する [60][62][61][63]．このシステムは，TCPの性能や，ネットワーク・システムの性能を評価するシステムである．多点間のホストで，同時に複数のコネクションを確立し，同時にデータ転送を行い，そのときのスループットの時間変化を測定することができる．この章では，DBSシステムの提案と実装，評価について述べる．さらに，実際のネット

ワーク環境で測定した結果について報告し，DBSによって得られる効果を明らかにする．

6.1 DBSの提案と実装6.1.1 DBSの提案

TCPとネットワークの性能評価を実現するための TCP性能評価システム DBS (Dis-

tributed Benchmark System)を提案する．このシステムの目的は，任意の TCP/IPネットワーク環境下で，任意のデータ転送トラヒックを生成・測定することで，TCPが備えている機能のすべてを評価できる基盤を提供することである．そのためには，5.4.1節で述べた機能のすべてを単一のシステムで実現することが必要である．これらの機能を実装面からまとめると，すべての機能は次の機能モデルで実現できる．

i. 複数のホスト間で複数のTCPコネクションを確立し，アプリケーション・レベルのデータ転送を行う．

ii. 各々のコネクションのデータ転送に関して，データ転送開始時刻や転送するデータの量を設定できる．

iii. 1つ 1つのデータの送受信時刻を記録する．

iと iiにより，複数のコネクションを確立し，それぞれのデータ転送の開始時刻やデータの転送量を操作することで，ネットワークの負荷を変動させることができる．また，iii

で記録されたデータから，シーケンス番号の時間推移やスループットの時間変化，遅延時間の時間変化，遅延時間の揺らぎの時間変化を計算することができる．これにより，5.4.1

節の要求をすべて実現することができる．具体的には，5.4.1節の 1と 2と 5は iと iiiの

83

84 第 6章 TCPの性能評価システムの提案・実装・評価

機能で，3は iの機能で，4は iと iiの機能で，6は iと iiと iiiの機能でそれぞれ実現することができる．

6.1.2 DBSの実装モデル

DBSは，測定に関係するすべてのホストの時刻が同期していることを前提として，に動作するように設計と開発を行った．時刻を同期させるプロトコルとしては，NTP [66]

(Network Time Protocol)を対象にした．DBSには次の機能を実装した．

1. TCPおよびUDPでデータの送受信ができる．

2. 複数のホストの間で複数のデータ転送および測定ができる．

3. 1つ 1つのデータの送受信時刻を記録し，アプリケーション・レベルでスループットの時間変化を測定できる．

4. データの転送開始時刻や，トラヒック・パターンなど，データ転送に関する細かい設定ができる．

5. TCPのバッファ・サイズの指定や，Nagleアルゴリズム [18]の解除などの，ソケットのオプションを指定できる．

6. オペレーティング・システムにTCP DEBUG機能 [67]が備えられている場合には，TCPコントロール・ブロックの値を記録することができる．これにより，喪失セグメントの特定や輻輳ウィンドウの大きさの変化，ラウンド・トリップ時間の変化など，TCPモジュールの処理に関するきめ細かな情報を得ることができる．

6.1.3 DBSのシステムの実装

DBS自体は dbscと dbsdという 2つのソフトウェアから構成されるように実装を行った．この 2つのソフトウェアの開発は C言語 [68]を使用した．DBSの動作が確認されているシステムを表 6.1に示す．以降，dbscを DBSコントローラ，dbsdを DBSデーモンと呼ぶ．

DBSのシステムの構成と，処理の流れをそれぞれ図 6.1と図 6.2に示す．DBSは大きく2種類の構成要素に分けられる．1つは実際に性能測定を行う実験ネットワークと実験ホスト群で，もう 1つは測定の制御や測定結果のデータ収集を行う情報収集ホストである．情報収集ホスト上では DBSコントローラを動作させ，実験ホスト群の各々のホスト上ではDBSデーモンを動作させる．情報収集ホストは必ず 1つで，実験ホストは通常複数台存在する．なお，実験ホストが情報収集ホストを兼ねることも可能である．

6.1 DBSの提案と実装 85

表 6.1: DBSの動作が確認されているシステムSun Microsystems SunOS V4.1.3，V4.1.4

SunOS V5.4，V5.5.1 (Solaris)BSDI BSD/OS V2.0，V2.1，V3.0，V3.1Silicon Graphics IRIX R5.3，R6.3Digital Equipment Digital UNIX V3.0

ULTRIX 4.4SONY NEWS-OS V6.1Tenon Intersystems MachTen V4.0.3FreeBSD FreeBSD V2.0NetBSD NetBSD V1.1，V1.2Linux Linux V2

情報収集ホストのDBSコントローラは，DBSデーモンへの実験内容の指示や，結果を受信してファイルに出力する機能を持つ．実験ホストのDBSデーモンは，DBSコントローラの指示により実験のトラヒックを生成し測定を行う．なお，1つの実験ホストで複数のコネクションを確立してデータ転送を行う場合は，その数だけ DBSデーモンが別のプロセスとして実行される1)．

DBSの動作の概要について説明する．

(1) 情報収集ホストから各実験ホストへ，実験の内容を指示する命令が送信される．

(2) DBSデーモンが命令を受信し，データの送受信時刻を記録するためのメモリ空間などの資源を用意する．実験の準備が完了したらOKの返事をする．何か問題があったら Failの返事とエラー番号を返送する．

(3) すべての実験ホストから情報収集ホストにOKの返事が送られてきた場合は，実験開始時刻を知らせる命令を送信する．その時刻になると実験ホスト群の間でデータ転送・測定が行われる．実験ホストから Failの返事がきた場合には実験中止の命令を送信する．

(4) 実験終了時刻になると，情報収集ホストから結果を要求する命令が送信される．

(5) 実験ホスト群から情報収集ホストへ測定結果が転送され，ファイルに格納される．

実験ホストがネットワークのインターフェースを 1つしか備えていない場合は，命令と結果のトラヒックが実験ネットワークを通ることになる．このことが結果に影響するのを防ぐため，実験のトラヒックと制御のトラヒックが同時に流れないようにDBSを実装した．

1)forkシステムコールを使用した．


Measurement Network

Controling HostMeasurement Hosts

sending Commands

receiving Results

Configuration File

files of the Results

図 6.1: DBSのシステム構成図

DBSデーモン(複数存在する)DBSコントローラ

コマンド送信

実験準備完了合図 (OK or Fail)

実験開始時刻通達 or 実験中止

結果データの送信

コマンドファイルの読み込み

結果の書き込み

データの送受信が行なわれる

実験開始時刻まで待つ

結果の送信要求

データを送受信する数分のプロセスが起動する

(1)

(2)

(3)

(4)

(5)

図 6.2: DBSの処理の流れ

6.1 DBSの提案と実装 87

また，実験ホストが情報収集ホストを兼ねる場合は，DBSコントローラの処理がDBS

デーモンの処理に影響を与える可能性がある．このことが結果に影響するのを防ぐため，実験中はDBSコントローラは sleep状態となり，できるだけCPU時間を消費しないように実装した．


一つのデータの大きさ

一回のシステムコールで送信するデータ

送信開始時刻の間隔

送信の時間間隔

時間の経過

送信するデータ

(1)

(2)

(3)

(4)

図 6.3: DBSのトラヒック・パターン

6.1.4 トラヒック・パターン

telnetなどの遠隔端末や，UDPのデータをネットワークに流して，それを測定しようと考えた場合には，トラヒック・パターンの指定が必要である．特にUDPはフロー制御がなく，トラヒックの制御をアプリケーションに任せている．UDPではネットワークの帯域を超えるようなトラヒックを流すことも可能である．しかし，現実のネットワークではそのようなことは行われない．ビデオや音声などのマルチメディア情報をリアルタイムに流す場合には，送信レートや，トラヒックのパターンが大体決まっている．そこで，DBS

では図 6.3に示すようなトラヒック・パターンを，任意の回数繰り返して送信できるように実装した．この機能により，MPEGなどのデータ転送を模倣することや，送信間隔やパケット長が乱数的に変動するデータ転送を作り出すことができる．ただし，DBS自体には，トラヒック・パターンを生成する機能を実装しなかった．そのため，利用者が必要に応じてトラヒックのパターンを作成しなければならない．図 6.3の (1)～(4)は，それぞれ次のような意味をもっている．

(1) 1つのデータの大きさ (byte)．アプリケーションでのデータの単位．

(2) 1回の sendシステムコールで送信するデータの大きさ．メッセージ・サイズ (byte)．

(3) 送受信開始時刻の間隔，送信レートの調節に利用する (精度は 0.01秒程度)．

(4) 送受信の時間間隔，システムや入出力のオーバーヘッドの指定に利用する (精度は0.01秒程度)．

6.1.5 DBSの測定結果の処理

DBSは他の性能測定ツールと比べ，大量の測定結果を出力する．そのデータを処理してグラフ化する dbs viewというツールを作成した．ツールの本体は perl [69] で記述した

6.2 DBSの評価 89

が，グラフの描画にはGnuplot V3.5 [70] を利用する．dbs viewではシーケンス番号の時間推移や，スループットの時間変化，遅延時間の時間変化，遅延時間の揺らぎの時間変化などのグラフを描くことができる．TCP DEBUGを利用する場合には，喪失セグメントや輻輳ウィンドウの時間変化などのグラフを描くことができる．

6.1.6 セキュリティに対する配慮

近年，LANとインターネットの間に，防火壁 (Fire Wall)を置くところが多くなってきた．このような環境でも，防火壁を通過する通信の性能を測定したいという要求がある．防火壁にはいろいろな形式があるが，DBSでは，外向きへのコネクションは許すが，内向きへのコネクションは許さないという，フィルタリング型の防火壁に対応させた．このような防火壁では，TCPのコネクションの確立時に，必ず防火壁の内側から外側に向けて接続要求をしなければならない．しかしデータ転送は外側から内側へも，内側から外側へも行われる．そこで，コネクションの接続要求の向きとデータ転送の向きを別々に指定できるように実装した．これにより，TCPのコネクションの向きに関する制御をしている防火壁に対応することができる．また，DBSデーモンは，inetdスーパーデーモンから自動的に起動できるように作成し

た．しかし，自動的に起動できるように設定すると，悪意を持った者が，不正にDBSデーモンにアクセスし，ネットワークに大量のトラヒックを長時間流すことで，業務や研究活動の妨害を企てる可能性がある．この問題に対応するため，DBSデーモンは，特定の情報収集ホスト以外からはコマンドを受け付けないように，アクセスに制限を設けられるように実装した．しかし，ユーザの制限や，IPアドレスのなりすましには対応していない．これらへの対策が必要な場合には，DBSデーモンを自動的に起動せず，測定実験のたびにDBSデーモンを起動・終了させてほしいと考えている．

6.2 DBSの評価DBSの機能面の評価と，測定結果の妥当性について検討する．

6.2.1 機能面の評価

DBSと他の性能測定ツールを，トラヒックの生成，測定実験の設定，測定結果の解析について，機能面で比較した結果を表 6.2に示す．ネットワークの負荷を変動させるためには，複数のデータ転送を行えることや，各々の転送開始時刻を指定できること，各々の転送データの総量を設定できることが必要である．また，TCPによるデータ転送にネットワークの負荷の変動が与える影響を調査するためには，シーケンス番号の時間推移を測定できる必要がある．以上，ここで述べたこれらの機能は，既存の測定ツール単体では実現


表 6.2: 性能測定ツールの機能の比較トラヒックの生成

DBS Netperf ttcp nettest NetSpecTCPおよび UDPによるデータ・トラヒックの生成 O O O O O2点間のホストで複数のデータ転送 O X X O O多点間のホストでのデータ転送 O X X X Oデータリンクを直接使った転送 (IPを使わない) X O X X X送信データをリダイレクションで入力できる X X O X Xトラヒック・パターンの設定 O X X X O

測定実験の設定DBS Netperf ttcp nettest NetSpec

各々のデータ転送の開始時刻の設定 O X X X Xメッセージ・サイズの設定 O O O O O送信データ量の設定 O O O O Oソケットのバッファ・サイズの設定 O O O O ONagleアルゴリズムの解除の設定 O O O O O防火壁への対応，セキュリティへの配慮 O X X X X

測定結果の解析DBS Netperf ttcp nettest NetSpec

シーケンス番号の時間推移の測定 O X X X X平均スループットの測定 O O O O Oスループットの時間変化の測定 O X X X X遅延時間の時間変化の測定 O X X X X遅延時間の揺らぎの時間変化の測定 O X X X Xコネクション確立のオーバーヘッドの測定 O O X X XTCP コントロール・ブロックの値を記録 O X X X Xスロー・スタートの挙動の測定 O X X X Xラウンド・トリップ時間の測定 O X X X X輻輳ウィンドウの変動の測定 O X X X X

されていないが，DBSではすべての機能が実現されている．また，DBSには TCPコントロール・ブロックの値を記録できる機能が備えられている．これは他の性能測定ツールにはない特長といえる．この機能を利用すれば，TCPの挙動のより精密な調査や解析をすることが可能になる．

DBSは他のツールと比較して高機能であるが，不足している機能が 2つある．それは，データリンクを直接使った転送と，送信データをリダイレクションで入力できる機能である．しかし，IPを使わないデータ転送はTCPの性能評価にとっては必要ない．また，送受信データをリダイレクションで入出力できる機能は，複雑なトラヒック・パターンを設定する機能である程度模倣することができる．TCPの性能測定という視点から総合的に判断すると，DBSは既存の測定ツールよりも明らかに高機能だといえる．

6.2 DBSの評価 91

6.2.2 測定結果の妥当性

DBSは，データを送受信するたびに，その時刻をメモリに記録している．この処理はCPUの負荷となり，測定結果に影響する可能性がある．この影響の度合いを調査するため，DBS，Netperf，ttcpの測定結果を比較した．図 6.4に示すような Ethernetで接続された 2つのホスト間で，表 6.3に示す設定でデータ転送を行った．結果を表 6.4と図 6.5に示す．この結果をみると，DBSと各ツールとの差は 1～2%程度であり，時刻をメモリに記録す

る処理の影響は，無視できないほど大きなものではないといえる．また，図 6.5のDBSの測定結果をみると，約 0.2秒まではスループットが極端に小さくなっていることがわかる．この現象はTCPのスロー・スタート [20]と，遅延確認応答 [19]による副作用で，TCPの短期デッドロックが発生しているためである [61]．送信ホストは通信開始直後，スロー・スタートにより輻輳ウィンドウを 1セグメントに設定し，1セグメントだけデータを送信する．しかし，受信側は 1セグメントのデータを受信しても，更なるデータの到着を待ち，確認応答を送信しない．その結果，最初のセグメントはかならず遅延確認応答となる．この状態は，送信ホストの輻輳ウィンドウが，受信ホストのウィンドウを更新させる大きさより大きくなるまで続く2)．この間スループットは極端に小さくなる．この実験から，Ethernetで接続された 2点間のホストという平凡なトポロジであったと

しても，TCPの制御機構のために，スループットが極端に変化する場合があることが明らかになった．また，このことから，スループットの時間変化を測定できる機能は，TCP

の性能評価にとってなくてはならない機能だといえる．さらに，スループットの時間変化を測定できないツールの測定結果を，盲目的に無条件で信用することは危険だといえる．

2)BSD/OS(4.4BSD Lite)では 2セグメントである．


Ethernet 10Mbps

Host1 Host2

図 6.4: 2点間の Ethernet実験環境

表 6.3: 評価に使用した機材と設定CPU Twinhead Subnote (486 33MHz)OS BSD/OS V2.1MSS 1448octetTCPバッファ・サイズ 8196byteメッセージ・サイズ 2048byte送信回数 (DBS，ttcp) 2048回送信時間 (Netperf) 10秒

表 6.4: それぞれのツールでの測定結果 (平均)

平均スループット DBSを 100としたときの比率DBS 6223Kbps 100.0

Netperf 6357Kbps 102.1ttcp 6172Kbps 99.1

0

1000

2000

3000

4000

5000

6000

7000

8000

0 1 2 3 4 5 6

Thr

ough

put(

Kbp

s)

Time(s)

DBSNetperf

ttcp

図 6.5: それぞれのツールでの測定結果 (時間変化)

6.3 DBSによる性能測定実験 93

6.3 DBSによる性能測定実験DBSの効果を調査するため，静止衛星で構築された衛星回線，ATMネットワーク，FDDI

ネットワーク，HIPPI over ATMネットワーク，専用線で構築されたWAN環境で測定実験を行った．

6.3.1 衛星回線

BSD/OS(4.4BSD Lite)には，TCPのウィンドウ・サイズの制限を拡張するオプション[16]が実装されている．この機能を利用して，約 0.5秒のラウンド・トリップ時間で 2Mbps

の帯域を持つ，静止衛星で構築された衛星回線でデータ転送実験を行った．測定環境を図6.6と表 6.5に，結果を図 6.7，図 6.8，図 6.9に示す．結果をみると，最大ウィンドウ・サイズに関係なく，データ転送開始から約 3秒間は，

TCPのスロー・スタート処理のため，輻輳ウィンドウがなかなか大きくならず，転送されるデータがごくわずかであることがわかる．約 3秒経過すると，スロー・スタートによる輻輳ウィンドウの拡大効果が表れ，スループットが急激に増加する．しかし，最大ウィンドウ・サイズがウィンドウの制限サイズである 64Koctet以下の場合は，スループットが振動して帯域を使い切っていない．拡張オプションを使用して，ウィンドウ・サイズを128Koctet以上に設定した場合は，2Mbpsの帯域をほぼ使い切っている．また，この 1つの衛星回線を利用して，複数のホスト間でデータを転送する実験も行っ

た．測定環境を図 6.10と表 6.6に，結果を図 6.11，図 6.12，図 6.13に示す．データ転送をしているコネクションが 1つの場合は，セグメントは喪失せず順調にデータ転送が行われる．しかし，データ転送をするコネクションが複数になるとセグメントが喪失するようになり，スループットが悪化する．そのコネクションのセグメントが喪失しない場合は，高スループットのまま通信を終えることができる (HOST4-HOST5)．しかし，セグメントが喪失する場合は，しばらくの間スループットが向上しない．特に連続的にセグメントが喪失する場合など，ウィンドウ・サイズが小さいときにセグメントが喪失すると，長時間にわたって小さなスループットが続く．これは，スロー・スタート閾値が小さな値に設定されると，スロー・スタートがほとんど行われなくなり，すぐに輻輳回避段階に入るために発生する現象である (HOST2-HOST5，HOST3-HOST5)．


2Mbps

DCE

HOST1 HOST2

DCE

Ethernet 10Mbps Ethernet 10Mbps

2Mbps (RTT ~0.5s)Satellite Channel

JCSAT-1(JSAT)

図 6.6: ウィンドウ・サイズ拡張オプションの評価

表 6.5 ウィンドウ・サイズ拡張オプションの評価に使用した機材と設定

CPU Twinhead Subnote (486 33MHz)OS BSD/OS V2.0.1Router SPARCstation10 (SunOS4.1.4)MSS 512octetTCPバッファ・サイズ 8196byte (8196octet)(最大ウィンドウ・サイズ) 32768byte (32768octet)

65535byte (66535octet)131072byte (131072octet)

メッセージ・サイズ 1024byteデータ転送時刻 0.00秒送信回数 1000回その他 TCP DEBUG機能を利用


0

200000

400000

600000

800000

1e+06

1.2e+06

0 5 10 15 20 25 30

Seq

uenc

e N

umbe

r

Time (s)

8192 recv32768 recv65535 recv

131072 recv

図 6.7 ウィンドウ・サイズの拡張オプションの評価 (シーケンス番号の推移)

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

0 5 10 15 20 25 30

Thr

ough

put (

Mbp

s)

Time (s)

8192 recv32768 recv65535 recv

131072 recv

図 6.8 ウィンドウ・サイズの拡張オプションの評価 (スループットの変化)


0

50000

100000

150000

200000

250000

300000

0 5 10 15 20 25 30

Win

dow

Siz

e (b

yte)

Time (s)

8192 cwnd32768 cwnd65535 cwnd

131072 cwnd

図 6.9 ウィンドウ・サイズの拡張オプションの評価 (輻輳ウィンドウの変化．バッファ・サイズが 32768byteと 65535byteの場合は，7秒目までバッファ・サイズが 131072byteの場合と重なるように変化している)


2Mbps (RTT ~0.5s)2Mbps

DCE

HOST1 HOST2 HOST3 HOST4

DCE

Satellite Channel

Ethernet10Mbps10MbpsEthernet

HOST5

JCSAT-1

(JSAT)

図 6.10: 衛星回線での測定

表 6.6: 衛星回線での測定環境と設定CPU(HOST1,2,3,4) Twinhead Subnote(486 33MHz)CPU(HOST5) GATEWAY2000(486 66MHz)OS BSD/OS V2.1Router SPARCstation10(SunOS4.1.4)MSS 512octetTCPバッファ・サイズ 65535byteメッセージ・サイズ 2048byteデータ転送時刻 HOST1–HOST5: 0.00秒

HOST2–HOST5: 2.00秒HOST3–HOST5: 4.00秒HOST4–HOST5: 6.00秒

送信回数 300回その他 TCP DEBUG機能を利用


0

200000

400000

600000

800000

1e+06

1.2e+06

0 10 20 30 40 50 60

Seq

uenc

e N

umbe

r

Time (s)

host1-host5 sendhost2-host5 sendhost3-host5 sendhost4-host5 sendhost1-host5 recvhost2-host5 recvhost3-host5 recvhost4-host5 recv

host1-host5 lost/rexmthost2-host5 lost/rexmthost3-host5 lost/rexmthost4-host5 lost/rexmt

図 6.11: 衛星回線での測定結果 (シーケンス番号の推移)

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

0 10 20 30 40 50 60

Thr

ough

put (

Mbp

s)

Time (s)

host1-host5 recvhost2-host5 recvhost3-host5 recvhost4-host5 recv

total

図 6.12: 衛星回線での測定結果 (スループットの変化)


0

10000

20000

30000

40000

50000

60000

70000

0 10 20 30 40 50 60

Siz

e (b

yte)

Time (s)

host1-host5 cwndhost2-host5 cwndhost3-host5 cwndhost4-host5 cwnd

host1-host5 ssthreshhost2-host5 ssthreshhost3-host5 ssthreshhost4-host5 ssthresh

図 6.13 衛星回線での測定結果 (輻輳ウィンドウ (cwnd)とスロー・スタート閾値 (ssthresh)の変化)


6.3.2 ATMとRouterが混在する環境

図 6.14のようにATMとルータが接続された環境で，表 6.7に示す設定でデータ転送実験を行った．なお，HOST1，HOST2と，HOST3の間の通信では，送信されるデータは，Routerで一旦 IPレベルの経路制御がされてから終点ホストへ届けられる．結果を図 6.15，図 6.16に示す．結果をみると，データを転送しているコネクションが 1つしかなく，輻輳しない場合に

は，連続的で円滑なデータ転送が行われる．しかし 2秒後，データを転送するコネクションが 2つに増えると，輻輳状態になり，スループットが極端に悪化する．2つのデータ転送のスループットが同期し，1秒おきにバースト的なデータ転送と転送停止を繰り返している．この結果から，ATMのように送信権の制御がなく，セルレベルでデータが喪失するネットワークでは，TCPのセグメントレベルでの輻輳回避制御や再送制御がうまく機能しない場合があると考えられる．


ATM Switch

155Mbps

100Mbps ATM Switch

100Mbps

32Mbps

Router

155Mbps

Host2

Host1

Host3Public ATM Network

Osaka UniversityToyonaka Campus

Nara Institute of Scienceand Technorogy

図 6.14: ATMとルータが混在する環境での測定

表 6.7: ATMとルータが混在する環境の設定CPU Sun SPARCstation10OS SunOS 4.1.3ATM Switch NEC ATOMIS5ATM Card Fore SBA-200Router NEC IP 45/650 (Cisco7000)AAL Type AAL 5MTU 9188octetMSS 9148octetTCPバッファ・サイズ 52428byteメッセージ・サイズ 8196byteデータ転送時刻 HOST1–HOST3: 0.00秒

HOST2–HOST3: 2.00秒送信回数 HOST1–HOST3: 2000回

HOST2–HOST3: 500回


0

2e+06

4e+06

6e+06

8e+06

1e+07

1.2e+07

1.4e+07

1.6e+07

1.8e+07

0 2 4 6 8 10 12 14 16

Seq

uenc

e N

umbe

r

Time (s)

host1-host3 recvhost2-host3 recv

図 6.15 ATMとルータが混在する環境での測定結果 (シーケンス番号の推移)

0

5

10

15

20

25

30

35

0 2 4 6 8 10 12 14 16 18

Thr

ough

put (

Mbp

s)

Time (s)

host1-host3 recvhost2-host3 recv

図 6.16 ATMとルータが混在する環境での測定結果 (スループットの変化)


6.3.3 FDDI

図 6.17のような，論理的に同一のFDDIリング上にあるホスト間で，表 6.8に示す設定でデータ転送実験を行った．その結果を図 6.18と図 6.19に示す．結果から，データ転送をしているコネクションがN本存在する場合，各々のスループッ

トはデータリンクの伝送速度の 1/Nに近い値になることがわかる．また，データ転送をしているコネクションの数が増えたり減ったりすると，それぞれのコネクションに割り当てられる帯域が，素早く 1/Nに変化することもわかる．この実験から，FDDI上でTCPを利用すると，スループットが平等に割り当てられることが明らかになった．また，このことから，FDDIは TCPと親和性が高いと考えられる．


FDDI100Mbps

HOST6HOST5

HOST3

HOST7

HOST1 HOST2

HOST4HOST8

HOST10

HOST9

図 6.17: FDDIでの測定

表 6.8: FDDIの測定環境と設定CPU SGI INDY (R4600 100MHz)OS IRIX R 5.3MSS 4312octetTCPバッファ・サイズ 65535byteメッセージ・サイズ 8192byteデータ転送時刻 HOST1–HOST6: 0.00秒

HOST2–HOST7: 0.50秒HOST3–HOST8: 1.00秒HOST4–HOST9: 1.00秒HOST5–HOST10: 1.50秒

送信回数 1000回


0

1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

8e+06

9e+06

0 0.5 1 1.5 2 2.5 3 3.5 4

Seq

uenc

e N

umbe

r

Time (s)


host5-host10 recv

図 6.18: FDDIでの測定結果 (シーケンス番号の推移)

0

10

20

30

40

50

60

70

80

90

0 0.5 1 1.5 2 2.5 3 3.5 4

Thr

ough

put (

Mbp

s)

Time (s)


host5-host10 recv

図 6.19: FDDIでの測定結果 (スループットの変化)


6.3.4 HIPPI over ATM Network

本学に導入されている HIPPI over ATM Network環境の性能を評価するために，DBS

で実験を行った．HIPPI (High-Performance Parallel Interface) は，800Mbpsの帯域をもつ高速パラレル・ネットワークである．ただし，ポイント・ツー・ポイントの接続で，最大 25mまでの距離しか接続できないという欠点がある．この HIPPIを HIPPI-ATM TA

で接続すると，マルチポイントの接続が実現でき，なおかつ，到達距離を無制限に延長することができる．図 6.20，表 6.9に示すような環境で実験を行った．全部で 5回の測定結果を示す．実験 1では，2つのコネクションを確立し 2つのデータ転送を行った．この実験ではデー

タ転送は順調に行われており，特に問題はみられない．実験 2では，計 4つのコネクションを確立し 4つのデータ転送を行った．この実験の場

合は，データ転送が増えると問題が発生している．3～8秒，9～13秒，14～19秒，では 4

～5秒間にわたりデータ転送が停止している．このデータをNECのHIPPI-ATM TAの開発スタッフに提供し，性能の改善を依頼し

た．HIPPIはコネクション指向であるが，それは，送信するデータ単位で行われる．これを ATMで転送できるようにするため，TAの内部にコネクションの管理をするためのHIPPIの Iフレームを保持し，データをバッファリングさせながら高速にデータを転送する．実験 2でデータ転送が悪化したのは，この Iフレームを管理するコントローラのバッファの設計に問題があったためである．実験 3と実験 4は，HIPPI-ATM TAのコントローラを NECによって設計が見直され

たものに交換して行った実験である．実験 3は，実験 2とほぼ同じ設定で行った．結果をみると性能が大幅に改善されている．ところが，実験 4をみると，スループットがかなり不公平になっていることが分かる．再設計されたコントローラでもまだ Iフレームのバッファ管理に不備があるためであった．再び NECに改善を依頼し，改善されたコントローラで再実験を行った．それが実験 5

である．実験 5の結果をみると，公平に通信が行われており，通信が改善されていることがわかる．このHIPPI-ATM TAは出荷されていた製品である．しかし，DBSのようなテストツー

ルが無かったために，性能の評価ができなかったのである．そのため，不具合が含まれているにもかかわらず，開発側も利用者側もこの問題に気が付かなかったのである．


ONYX(12CPU)

CHALLENGE (36CPU)

ONYX(20CPU)

HIPPI 800Mbps

ATM Switch ATM Switch

HIPPI-ATM TA

HIPPI-ATM TA

ATM (OC12) 622Mbps

HIPPI-ATM TA

図 6.20: 測定環境

表 6.9: 測定環境CPU SGI ONYX RE2, CHALLENGE XLOS IRIX 5.3ATM Switch NEC ATOMIS7HIPPI-ATM TA NEC ATOMIS2HATCP バッファ・サイズ 256000byteメッセージ・サイズ 8192byteデータ転送開始時刻 ONYX(20)→CHALLENGE(36): 0.0s

ONYX(12)→CHALLENGE(36): 1.0sONYX(20)→CHALLENGE(36): 2.0sONYX(12)→CHALLENGE(36): 3.0s


0

1e+07

2e+07

3e+07

4e+07

5e+07

6e+07

7e+07

8e+07

9e+07

0 1 2 3 4 5 6

Seq

uenc

e N

umbe

r

Time (s)

20-36 send12-36 send20-36 recv12-36 recv

図 6.21: 実験 1:シーケンス番号

0

50

100

150

200

250

300

350

0 1 2 3 4 5 6

Thr

ough

put (

Mbp

s)

Time (s)

20-36 recv12-36 recv

total

図 6.22: 実験 1:スループット


0

1e+07

2e+07

3e+07

4e+07

5e+07

6e+07

7e+07

8e+07

9e+07

0 5 10 15 20 25

Seq

uenc

e N

umbe

r

Time (s)

20-36-1 recv12-36-1 recv20-36-2 recv12-36-2 recv


0

100

200

300

400

500

600

700

0 5 10 15 20 25

Thr

ough

put (

Mbp

s)

Time (s)


total



0

5e+07

1e+08

1.5e+08

2e+08

2.5e+08

0 2 4 6 8 10 12 14

Seq

uenc

e N

umbe

r

Time (s)



0

50

100

150

200

250

300

350

400

450

500

0 2 4 6 8 10 12 14

Thr

ough

put (

Mbp

s)

Time (s)


total



0

2e+07

4e+07

6e+07

8e+07

1e+08

1.2e+08

1.4e+08

1.6e+08

1.8e+08

2e+08

0 2 4 6 8 10 12 14 16 18

Seq

uenc

e N

umbe

r

Time (s)

4-20-36-1 recv4-12-36-1 recv4-20-36-2 recv4-12-36-2 recv4-20-36-3 recv4-12-36-3 recv4-20-36-4 recv4-12-36-4 recv


0

100

200

300

400

500

600

700

0 2 4 6 8 10 12 14 16 18

Thr

ough

put (

Mbp

s)

Time (s)


total



0

2e+07

4e+07

6e+07

8e+07

1e+08

1.2e+08

1.4e+08

1.6e+08

1.8e+08

2e+08

0 2 4 6 8 10 12 14 16

Seq

uenc

e N

umbe

r

Time (s)



0

50

100

150

200

250

0 2 4 6 8 10 12 14 16

Thr

ough

put (

Mbp

s)

Time (s)



6.4 WAN 113

6.4 WAN

実際に運用している図 6.31のように専用線で接続されたWAN環境で，表 6.10に示す設定でデータ転送実験を行った．実験 1の結果を図 6.32，図 6.33，図 6.34に，実験 2の結果を図 6.35，図 6.36，図 6.37に示す．なお，実験 1はセグメント喪失率が 1%で，実験2はセグメント喪失率が 30%であった．それぞれの結果から，TCPは輻輳状態になると，バースト的なデータ転送と再送タイム

アウトを繰り返すことがわかる．それぞれバースト時のスループットは，実験 1(図 6.33)

では 100～150Kbps，実験 2(図 6.36)では 20～30Kbpsと読みとれる．また，図 6.32をみると，周期的にセグメントが複数個喪失していることがわかる．実験 1の図 6.33と図 6.34では，ウィンドウ・サイズが大きくなるに従ってスループッ

トが増加する傾向がみられる．ウィンドウ拡大による送信量の制御はある程度うまく働いていると考えられる．しかし，実験 2の図 6.36と図 6.37からは，ウィンドウ・サイズによるスループットの変化はほとんどわからない．


Keio UniversityShonan Fujisawa Campus

1.5Mbps

1.5MbpsTokyo NOC Nara NOC

Fujisawa NOC

HOST2

HOST1

Nara Institute of Scienceand Technology

Part of WIDE Internet Backbone

図 6.31: WANでの測定

表 6.10: WANの測定環境と設定CPU SPARCstation(SUN)OS SunOS 4.1.3MSS 536octetTCPバッファ・サイズ実験 1:8196byte

実験 2:16384byteコネクションの向き実験 1:HOST1(奈良)→HOST2(藤沢)

実験 2:HOST2(藤沢)→HOST1(奈良)測定日時実験 1:1996年 2月 9日 16時 10分頃

実験 2:1996年 2月 3日 19時 40分頃メッセージ・サイズ 1024byteその他 TCP DEBUG機能を利用

6.4 WAN 115

0

50000

100000

150000

200000

250000

300000

0 5 10 15 20 25 30

Seq

uenc

e N

umbe

r

Time (s)

send recv

lost/rexmt

図 6.32 WAN実験 1の測定結果 (シーケンス番号の推移と喪失セグメント)

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0 5 10 15 20 25 30

Thr

ough

put (

Mbp

s)

Time (s)

recv

図 6.33: WAN実験 1の測定結果 (スループットの変化)


0

2000

4000

6000

8000

10000

0 5 10 15 20 25 30

Siz

e (b

yte)

Time (s)

cwnd ssthresh

図 6.34 WAN実験 1の測定結果 (輻輳ウィンドウ (cwnd)とスロー・スタート閾値 (ssthresh)の変化)

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

0 20 40 60 80 100 120

Seq

uenc

e N

umbe

r

Time (s)

send recv

lost/rexmt

図 6.35 WAN実験 2の測定結果 (シーケンス番号の推移と喪失セグメント)

6.4 WAN 117

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.1

0 20 40 60 80 100 120

Thr

ough

put (

Mbp

s)

Time (s)

recv

図 6.36: WAN実験 2の測定結果 (スループットの時間変化)

0

1000

2000

3000

4000

5000

6000

7000

8000

0 20 40 60 80 100 120

Siz

e (b

yte)

Time (s)

cwnd ssthresh

図 6.37 WAN実験 2の測定結果 (輻輳ウィンドウ (cwnd)とスロー・スタート閾値 (ssthresh)の変化)


6.5 考察静止衛星による衛星回線では，ラウンド・トリップ時間が長いため，TCPのスロー・ス

タート処理の影響で，スループットが向上するまでにかなり時間がかかることがわかった．また，輻輳時には輻輳ウィンドウがうまくコントロールされず，利用されないむだな帯域が多くなったり，セグメントが喪失するタイミングによっては，スループットが著しく不平等になることが明らかになった．今後は，衛星回線の帯域を有効に利用し，かつ輻輳をうまく抑制するための，効果的な輻輳ウィンドウ変更アルゴリズムの検討や，選択確認応答 (SACK: Selective Acknowledgment)[37]の有効性の調査，両方を考慮した制御について検討を行う必要がある．

ATMとルータが混在する環境では，TCPの輻輳回避機構がうまく動作せず，スループットが極端に悪かった．ただし，今回の測定ではATMの特徴である帯域制御をしていない．ATMではABR (Available Bit Rate)などの帯域制御機構が提案されている．今後は TCPとABRの相性について測定する必要がある．

FDDIはセグメントが喪失せず，TCPとの親和性が高いという結果が得られた．しかし，FDDIネットワークをコンセントレータで多段に構築すると，トークンが複数巡回してセグメントが喪失する場合がある．今後はFDDIでセグメントが喪失するような環境で測定をする必要がある．

WANの測定では，輻輳時にバースト的なデータ転送と，再送タイムアウトを繰り返すこと，セグメントが周期的に複数個喪失することが観測された．また，喪失率 30%の環境下では，TCPのウィンドウ制御はあまり意味をなさないことも明らかになった．これらは，TCPにレート・フロー制御などの機能を組み込むことによって，改善できる可能性がある．今後はレート・フロー制御などを TCPに実装して実験する必要がある．

HIPPI over ATMの実験は，TCPの実装の改善ではなく，ネットワークの中継機器の性能改善をするために効果的な実験であった．スイッチやルータの性能評価では，コネクションを 1つだけ確立してデータ転送が行われることが多い．しかしこの方法は，現実のインターネットの利用形態とはかけ離れている．現実に近い性能評価を行うためには，DBSのようなツールが必要である．このHIPPI over ATMの実験は，DBSによる性能評価の効果の一端がみえるよい例だといえる．今後，多くのネットワーク機器をDBSで検査することにより，その機器の問題点が明らかになり，性能の改善が行われることが期待される．

6.6 まとめこの章では，複数のホストが接続された分散環境下で，TCPの性能を評価するための，

TCP性能評価システムDBSの提案・構築について報告した．

6.6 まとめ 119

DBSの能力を確認するため，既存の性能測定ツールと機能や測定結果の比較を行った．この結果から，DBSは既存のツールと比べて機能の面で優れていることを明らかにした．また，セグメントを送受信するたびに時刻を記録する処理が結果へ与える影響は小さく，DBSによる測定結果はほぼ妥当なものであることを示した．さらに，Ethernetで接続された 2点間のホストという単純なネットワーク上のデータ転送で，スループットが変化していることがDBSによって明らかになり，スループットの時間変化を測定する機能は，TCP

の性能評価にとって重要な機能であることを示した．またDBSを使って，静止衛星で構築された衛星回線，ATMネットワーク，FDDIネッ

トワーク，HIPPI over ATMネットワーク，専用線で構築されたWAN環境で測定実験を行った．その結果，TCPの挙動に関して，既存の性能測定ツールでは明らかにできなかったより細かい評価や分析ができることを示した．また，ネットワークの機器の性能改善にとっても有用な情報が得られることを示した．このDBSの登場により，TCPの問題点が次々に明らかになることが期待される．また，この DBSを利用して，ネットワーク機器の性能改善が行われることが期待される．

PART IV

TCP短期デッドロック問題の解決

第 7 章 TCP短期デッドロック問題と既存の解決案p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

TCPを実際のネットワークで運用した結果，問題があることが発見され，第 2章で述べたような改善がされてきた。これらの改善の中には，TCPの動作機構に副作用を生じさせるものがあることが分かってきた．この章では，これらの問題点の原因について説明するとともに，提案されている解決案とその問題点を説明する．また，この問題によって引き起こされる影響について説明し，解決することの重要性を示す．

7.1 TCP短期デッドロック問題TCPには，Nagleアルゴリズム [18]やスロー・スタート [20]というデータの送信を抑

制する機構と，遅延確認応答 (Delayed Acknowledgment)[19]という確認応答を遅延させる機構が備えられている．これらの処理がうまく噛み合わなくなると，ある期間，データの転送が停止することがある．具体的には次の状態になる．本論文ではこの状態になることを TCPデッドロックと呼ぶ．

送信ホスト: 続けて送信すべきデータがあるが，前に送信したセグメントに対する確認応答を受信するまで，データを送信しない

受信ホスト: 確認応答していない受信セグメントがあるが，さらにデータを受信しないと確認応答しない

この状態は，遅延確認応答処理で確認応答が遅延される期間続く．この上限は 0.5秒に決められている [21]．BSDの実装を基にした多くの実装では，確認応答の遅延時間は最大0.2秒間であり，デッドロックは最大 0.2秒続く．このデッドロックは繰り返し発生することがある．この場合，セグメントが 0.2秒間隔でしか送信されなくなるため，極端にスループットが悪化する．次に，TCPデッドロックの詳細について説明する．

7.1.1 送信バッファがMSSに比べて十分大きくない場合

これは 2.2.1節で取り上げた問題である．Comerらや，Moldekvらは SunOS 4に特化したかたちでこの問題を分析している．本論文では，この問題を TCPの一般的な問題として，OSに依存しない形で取り扱う．

123

124 第 7章 TCP短期デッドロック問題と既存の解決案

HOST A HOST B

Nagleアルゴリズム有効時

Nagleアルゴリズム無効時

2MSS未満 1MSS未満 2MSS未満

2MSS未満2MSS未満


2MSS未満

3MSS未満

未送信データ（Nagleアルゴリズムにより送信を抑制されている）受信したデータ（到着したデータが少なく遅延確認応答状態）

送信済だが確認応答を受けていないデータ

図 7.1: 送信バッファが小さい場合のデッドロック

TCPでは，セグメントの喪失に備えて，確認応答されていないデータを送信バッファに保存しておかなければならない．そのため，送信バッファが最大セグメント長 (MSS:

Maximum Segment Size)の 3倍より小さいと，図 7.1に示すようにデッドロックが発生する可能性がある [27]．このデッドロックは，データ転送が終了するまで繰り返し起こる可能性があり，スルー

プットを著しく低下させる恐れがある．

7.1.2 ネットワーク・モジュールの階層化の問題

アプリケーションが，システムコールでデータを送信するときのメッセージの大きさによっては，TCPデッドロックが起きることがある．これは，ネットワーク・モジュールの階層化の問題として知られている [32]．これは，2.2.2節で取り上げた問題である．Luckenbach

らは，この問題をBSD系の SunOSのTCPとソケットの間の実装の問題として取り上げ，ソースコードを示して細かく分析している．しかし，この問題は，BSDのソケットだけではなく，SYSTEM-V系の STREAMSでも発生することが知られている [71]．本論文では，この問題をネットワークの階層化による一般的な問題として取り上げる．多くのオペレーティング・システムでは，図 7.2に示すように，アプリケーション・プロ

グラムとTCPモジュールの間に，TCPとアプリケーションを結ぶインターフェース1)が存在する．このインターフェースはオペレーティング・システムの内部に含まれ，アプリケーションからオペレーティング・システムへ渡される送信データをメモリ・バッファに

1)例えば，BSD系ではソケット，System V系では STREAMSと呼ばれる．

7.1 TCP短期デッドロック問題 125

アプリケーションが送信するデータ

3MSS

メモリ・バッファ

TCPモジュールが管理するバッファ

IPデータグラムに入れられるデータ

1MSS

ユーザ・プログラム

オペレーティング・システム論理的なデ｜タの流れ

(メモリ・バッファへのポインタ)

(メモリ・バッファへのポインタ)

図 7.2: ネットワーク・モジュールの階層モデル

格納したり，受信したデータをメモリ・バッファからアプリケーションへ渡す働きがある．メモリ・コピーによるオーバーヘッドを避けるため，ネットワーク・モジュールの各層は，メモリ・バッファに格納された同一のデータをポインタで参照する．多くの実装では，アプリケーションからシステムコールによってオペレーティング・システムへ渡されるデータは，データが全く格納されていない未使用の固定長バッファに格納される．使用されるメモリバッファの大きさに比べて，アプリケーションのメッセージ・サイズが小さい場合，メモリ・バッファの利用効率が悪くなる．メモリ・バッファの合計が 3MSS以上あったとしても，合計 3MSS未満のデータしか格

納できないことが起こりうる．そうなると，7.1.1節と同じ状態になり，デッドロックが発生する．また，このインターフェースが管理しているメモリ・バッファの空き領域が少なくなっ

た場合，TCPへの送信処理が行われずに，バッファが大きくなるまで処理が中断されるように実装されている場合がある．これは一種のフロー制御といえるが，このフロー制御が TCPのフロー制御と独立に行われると，デッドロックが起きる可能性がある．

7.1.3 スロー・スタートの問題

送信ホストは，通信開始時にスロー・スタートの機構により，1MSSのセグメントを 1

つしか送信しない．しかし，受信ホストは，更なるセグメントの到着を待ち，すぐに確認応答をしない．そのため，最初の 1パケット目は図 7.3の上段に示すようなデッドロックが発生する．これは，スロー・スタートが設計されたとき [34]，すべての送信セグメントに対して確認応答パケットが返ってくることを前提にしていたことに原因がある．なお，このデッドロックは，ウィンドウをよりゆっくりと拡大させるため，スロー・ス


タートによる混雑の回避によい影響を与えるのではないかと考えられるかもしれない．しかし，TCPでは，混雑の回避は輻輳ウィンドウがスロー・スタート閾値を超えた後の，輻輳回避段階で行われるように設計されている [34]．そのため，最初の 1パケットだけ遅延させても，輻輳回避段階へ到達する時間が遅くなるだけで，混雑の回避によい影響を与えるわけではない．スロー・スタートの役割は，ラウンド・トリップ時間内の送信パケット数を，1パケッ

トから始めて指数関数的に増加させることで，急速に帯域を広げながらネットワークの帯域に割り込んでいき，確認応答パケットによる自己同期 (self clocking)を実現するための機構である．スロー・スタートの最初のデッドロックは，スロー・スタートの正常な処理とはいえない．

LAN環境ではラウンド・トリップ時間は数ミリ秒であるため，最初の 1パケットが 200

ミリ秒遅れるということは，ユーザへの応答性の限界を作ることになる。しかも，この遅延は，TCPコネクションを確立した直後にバルク・データ転送をする場合には，必ず発生するという問題がある．つまり，日常的に発生している問題である．現在のインターネットの利用形態では，それほど大きな問題にはなっていないが，より広帯域な LAN環境で，より敏速な応答性が必要で，なおかつ大量にデータを送信する場合には，大きな問題となる可能性がある．たとえば，NFS (Network File System)では通常は UDPが利用されている．かりに，

NFSをTCPで動かした場合には，このデッドロックによってパフォーマンスが大きく低下すると考えられる．他にも，敏速な応答性を必要とするアプリケーションを作成したときに，TCPのスロー・スタートのデッドロック問題による性能低下の影響を避けるために，わざわざUDPを使わなければならない可能性がある．UDPはトラヒックの制御がないため，ネットワークを共有利用する場合には TCPを利用することが好ましい．こう考えると，微細な性能の低下ではあるが，解決しなければならない非常に重要な問題であることが分かる．

7.1.4 経路MTU探索の問題

経路MTU探索 (Path MTU Discovery)[54] は，IPv4ではオプションの機能であり，あまり実装されていなかった．しかし，IPv6では，ルータがMTU(Maximum Transmission

Unit)を超えるデータグラムのフラグメント処理をしなくなるため，経路MTU探索の実装が強く求められるようになる．しかしながら，この経路MTU探索の機構は，TCPデッドロックを引き起こす新たな原因となる．一般的な TCPの実装では，コネクションの確立時に，通信するホスト間で互いに最適

だと判断されるMSSの値が交換される．そして小さい方の値が実際のデータ転送に使用されるMSSと決められる．このようにして決定されたMSSは，両ホストで同じ値になり，

7.1 TCP短期デッドロック問題 127

HOST A HOST B

1MSS 2MSS未満

2MSS未満3MSS


未送信データ（スロー・スタートにより送信を抑制されている）受信したデータ（到着したデータが少なく遅延確認応答状態）

送信済だが確認応答を受けていないデータ

経路MTU探索によってMSSが半分になった場合

MSSが変化しない場合

輻輳ウィンドウ

輻輳ウィンドウ

図 7.3 スロー・スタートおよび，経路MTU探索によるデッドロック

通常はコネクションが切断されるまで変化しない．しかし，コネクションの確立時に決定されたMSSの値は，経路MTUから求めたMSS

の値とは必ずしも一致しない．送信ホストに経路MTU探索が実装されている場合は，データ転送を開始したあとで正しい経路MTUの値が求まり，その値を基にMSSの値が再設定されることになる．現在のTCPの実装では，コネクション確立後にMSSの値が変更されたとしても，その値が受信ホストに通知されることはない．仮に通知されたとしても受信時に無視される．そのため，受信ホストは，送信ホストのMSSの値とは無関係に，コネクションの確立時に交換されたMSSの値を使って遅延確認応答を制御することになる．送信ホストのMSSが，コネクション確立時に決定された値よりも小さく変化する場合

は，図 7.3の下段に示すようなデッドロックが発生する可能性がある．大きく変化する場合は，遅延確認応答が行われなくなり，確認応答パケットが増加し，ネットワークやCPU

の負荷が増加する可能性がある．なお，MSSの値が変更されるたびに，MSSオプションでMSSの値を伝えるようにTCP

を変更すれば，デッドロック問題を解決できるように思われるかもしれない．しかし実際には，デッドロック問題を完全に解決することはできない．MSSを通知するためにはTCP

のオプションを使わなければならず，送信するパケットにはその分のヘッダ・オーバーヘッドが付く．そのため，MSSを通知するパケットでは，新しく求まった 1MSS分のデータを運ぶことができず，結局，ウィンドウが 2MSS以下の場合にデッドロックが起きることになる．ただし，すべての TCPセグメントでMSSオプションを付けるか，MSSの値からMSSオプションの大きさをあらかじめ引いておけば問題を解決できる．しかし，MSSは頻繁に変更されるものではなく，ヘッダのオーバーヘッドが大きくなることのほうが，より大きな問題である．


7.2 今までに提案されたTCPデッドロック問題の解決案今までに，TCPデッドロック問題の解決方法がいくつか提案されている．それらの解

決案と，その問題点について述べる．

i. 送信バッファを大きくする解決案

Comerらは，送信バッファを常にMSSの 3倍以上に設定すれば，7.1.1節の「送信バッファがMSSに比べて十分大きくない場合」のデッドロックを解決できると主張した [27]．TCPのプロトコル仕様や，実装を変更する必要がなく，TCPの内部パラメータの変更や，アプリケーション・プログラムの修正だけで，デッドロックを回避できるという利点がある．

ii. 遅延確認応答を止める解決案

Moldeklevらは，遅延確認応答処理を止めることで，デッドロック問題を解決できると主張した [28]．デッドロックの原因は，すべて遅延確認応答が関係している．そのため，確認応答を遅延させなければ，デッドロックは発生しない．

iii. PUSHフラグで遅延確認応答を制御する解決案

NetBSD 1.1では，PUSHフラグが設定されたセグメントを受信した場合に，遅延なく確認応答するように実装されている2)．その結果，PUSHフラグが設定されるときにはデッドロックは発生しない．

iv. PUSHフラグの拡張によるデッドロック問題の解決

筆者らは PUSHフラグを利用して確認応答を完全に制御すれば，デッドロック問題を解決できると主張した [74]．送信データがそれ以上来ないことを受信ホストが知っていれば，確認応答をすぐに送信することでデッドロックを避けることができる．これは送信ホストが送信を停止することを受信ホストに通知してから停止すれば実現できる．この通知に PUSHフラグを利用する．具体的には次のように処理することでデッドロックを回避する．

• 送信ホスト

そのセグメント以後の送信を停止するとき，PUSHフラグを 1にする．

• 受信ホスト

PUSHフラグが 1になっている場合，遅延なく確認応答を送る．2)FreeBSD 2.1や，FTP社の FTPなどオプションで同様の処理ができる実装がいくつか存在する．

7.3 今までに提案されたデッドロック解決案の問題点 129

7.3 今までに提案されたデッドロック解決案の問題点i. 送信バッファを大きくする解決案

iの解決案は，7.1.1節のデッドロック以外は解決できないという欠点がある．さらに，バッファ・サイズの大きさを規定すること自体に問題がある．既存のデータリンクの中には，IPv4の最大パケット長である 64koctetを超える巨大なMTUのネットワークが存在する．また，近い将来，腕時計や ICカードなど，少量のメモリしか搭載できない超小型の機器が TCP/IPを利用して通信するようになる可能性がある．また，IPv6ではアドレス空間が莫大な数に増加するとともに，4Goctetまでの巨大なMTUのデータリンクが利用可能になる．そのため，ありとあらゆる物をインターネットに接続しようと試みられるに違いない．TCPのアルゴリズムで，MTUやバッファ・サイズを規定することは，ネットワークやホストの仕様を制限する特別な条件になりかねない．このことから，MTUやバッファ・サイズとは無関係にデッドロックの問題が解決することが望ましい．パーソナル・コンピュータ用のオペレーティング・システムや PDAなどの携帯型の端

末，組み込みシステムのように，TCPのパラメータを変更できなかったり，アプリケーションのソースプログラムが付属しない場合もある．また，ネットワークを移り変わるような移動コンピュータの場合には適用できない．しかも，このチューニングは TCPの動作を理解した熟練者以外の一般ユーザに簡単にできるものではなく，設定を誤れば新たな問題を引き起こす可能性がある．

MSSの値を推測してバッファ・サイズを決定する方法も考えられるが根本的な解決にはならない．MSSの値は増加傾向にあり，HIPPIや Fiber ChannelではMTUを 64koctet

以上に設定可能である．また，IPv4では仕様上最大データグラム長が 64koctetであったが，IPv6では 64koctetを超えるデータグラムを扱えるように拡張される．そのためMTU

を仮定することはネットワークの多様化を限定することにもなり許されることではない．IPv6では経路MTU探索が実装されることになっており，できるだけ大きななパケットでデータを送信するが望まれているのである．TCPはどのようなMTUにも対応できるアルゴリズムを備えなければならないのである．また，半導体メモリーの低価格化やコンピュータのメモリー容量の増大が急速に進んで

おり，バッファ・サイズを大きく設定することはたやすいことに思われるかもしれない．しかし，インターネットに接続される機器や，TCP/IPを利用する機器が小型化，多様化することを考えると全く解決策になっていないことがわかる．例えば，IPカードや腕時計など，非常に小型な物をインターネットに接続しようと考えたとき，バッファ・サイズをMSSに比べて十分に大きくとるということは現実的な解ではないことがわかる．半導体の高集積化が進めば進むほど，より小型で省電力型の機器をインターネットに接続できるのであり，バッファ・サイズを大きくできるのは一部の機器に限定されると考えるべきである．


PUSH

PUSH

PUSH

PUSH

HOST A

ACK

ACK

ACK

HOST B

図 7.4 インタラクティブ・データ転送で確認応答を遅延させない場合

また，インターネットは今後使いやすくなることが望まれている．そのためにはプラグ&プレイが実現する必要がある．ユーザにはコンピュータを物理的にネットワークに接続すれば，論理的な設定がすべて自動的に行われることが望まれている．しかし，今のTCP

では，これらのデッドロックが起こる可能性があり，ネットワークの利用効率が著しく悪くなり，ユーザの使い勝手を阻害する可能性がある．今後，インターネットがプラグ&プレイを実現し，ユーザにとって使いやすいネットワー

クになるためにも，デッドロックが起こらないように TCPを改善する必要がある．

ii. 遅延確認応答を止める解決案

iiの解決案を実装すれば，すべてのデッドロック問題を解決できると期待できる．デッドロックの原因のすべてに，遅延確認応答が関係している．そのため，確認応答を遅延させなければ，デッドロックは発生しなくなると考えられる．しかし，遅延確認応答を止めるという方法自体に問題がある．遅延確認応答は，シリー・ウィンドウ・シンドローム (SWS:

Silly Window Syndrome) と呼ばれるネットワークの帯域の利用効率を悪化させる現象を回避するために提案された [19]．現在のインターネットでは多彩なデータリンクが用いられており，また，ネットワークには莫大な数のホストが接続されている．これらのことを考えると，ネットワークの利用効率を著しく悪化させるシリー・ウィンドウ・シンドロームを防止することは，必須事項であり，iiの解決案は受け入れられるものではない．また，遅延確認応答を無効にすると，図 7.4に示すようにインタラクティブ・データ転

送時にピギーバック処理が行われなくなる．特に即時性を必要とするインタラクティブ・データ転送では，図 7.5に示すように確認応答の数が莫大な数に増加することになる．その結果，無駄なトラヒックが増えホストの負荷が増加する．その結果，スループットの低下を招くという問題が発生する．

7.3 今までに提案されたデッドロック解決案の問題点 131

PUSH

PUSH

PUSH

PUSH

HOST A

ACK

ACK

ACK

HOST B

図 7.5 即時性を必要とするインタラクティブ・データ転送で確認応答を遅延させない場合

iii. PUSHフラグで遅延確認応答を制御する解決案

iiiの解決案は，デッドロックの根本的な解決にはなっていない．PUSHフラグが設定されずにデッドロックが起きる場合には，デッドロックが起きることになる．実際，PUSHフラグとデッドロックの間には完全な相関関係はなく，デッドロックが発生するときにPUSH

フラグが設定されるとは限らない．そのため，デッドロック問題のすべてを解決することはできない．インタラクティブ・データ転送では PUSHフラグが設定されたセグメントに対してピ

ギーバックが行われる可能性がある．しかし，iiiの実装をすると iiのときと同じように，インタラクティブ・データ転送時にほとんどすべてのセグメントに対して遅延なく確認応答が行われることになり，ピギーバックが行われなくなる．このため，iiの提案と同様に，ネットワークや CPUの負荷が増加することになり，結果としてスループットを低下させる原因になる．この iiiの実装は根本的に間違っている．これは，TCPのデータ転送モデルにおける遅

延確認応答とPUSHフラグの役割をきちんと考慮していないためである．よって，受け入れることはできない提案である．

iv. PUSHフラグの拡張によるデッドロック問題の解決

データ転送モデルの性質から，PUSHフラグが設定されたセグメントは，ピギーバックされる可能性が強い．したがって，PUSHフラグが設定されたセグメントは遅延させるべきである．ivの提案を実装すると，TCPに備えられているトラヒックを軽減するための仕組みが動作しなくなる．


この提案も iiiの提案と同様に，アプリケーションのデータ転送モデルにおけるTCPの挙動を無視した考え方であり，受け入れることはできない．

7.4 TCPデッドロック問題とその解決方法に関する考察この TCP短期デッドロック問題を分析すると，TCPの問題点を解決する目的で TCP

に追加された機能や，TCPの下位層である IPへの新たな機能の追加，オペレーティング・システム内部のメモリ管理機構の効率化などが原因になっていることが分る．つまり，デッドロック問題は，TCPや別の層を改善した結果の副作用として発生する

ようになったのである．このことから，今後，TCPやTCPの下位層や上位層に変更が加えられたとしても，この問題が発生しないような根本的な解決法が必要である．また，現在のインターネット上の TCPの実装のすべてを瞬時に取り替えることは不可

能である．解決策が提案され証明されたとしても，メーカからサポートされなくなった古い実装の場合は，そのまま運用を続けなければならない．そのため，この問題の解決案は，現在のインターネット上でそのまま運用でき，なおかつ，新たな問題を生じさせてはならない．以上をまとめると，TCP短期デッドロック問題の解決策は，次の 3つの事項を満たす

必要がある．

1. 現在の TCPと互換性があり，相互に通信できなければならない．

2. 新たな問題が発生してはならない．

3. TCPやその他の層の機能拡張や変更によって，再び別のTCPデッドロックが発生することがないような，根本的な解決策でなければならない．

7.5 まとめTCPのデッドロックの問題は，ATMなど大きなMTUのデータリンクの出現により明

らかになった．そして，大きなMTUのネットワークにコンピュータをつなぐときには，コンピュータごとに送受信バッファの初期値が異なっており，デッドロックが起きる危険性がある．しかし，逆に腕時計や ICカードなど小型の機器をインターネットに接続することを考

えると，バッファ・サイズが小さくなりEthernetでもデッドロックの問題が起こる可能性がある．将来，インターネットに多種多様な機器が接続されると考えるならば，TCPデッドロック問題を根本的に解決することが重要な課題であることがわかる．

第 8 章 TCPデッドロック問題の解決策の提案・実装・評価p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

第 7章で，TCP短期デッドロック問題が発生する仕組みと，この問題の重要性，そして，既存の解決策の問題点について説明した．この章では，TCPデッドロック問題を解決する方法を提案する [72][73]．さらに，実装して，実験した結果について報告し，本提案の有効性を示す．

8.1 デッドロック問題の解決策の提案デッドロックが起きる根本的な原因は，受信ホストが送信ホストの状態を知ることなく，

独立して遅延確認応答処理をしていることにある．送信ホストでは，送信バッファの残りサイズ，MSSの大きさ，送信処理が停止するかどうかなど，遅延確認応答処理をする上で必要な情報が変化する．それにもかかわらず，これらの情報は受信ホストには伝えられない．例えば，経路MTU探索の問題の場合，MSSオプションを利用してつねにMSSの値を通知し続ければ，MSSが変化してもデッドロックが起きない可能性がある．しかし，このようにして個々の問題を別々に解決するのはあまり望ましいことではない．なぜならば，問題を個別に解決した場合には，IPやTCPの機能に変更が加えられた時に，別のデッドロック問題が発生する危険性があるからである．こうなると，問題が発生するたびにTCP

の仕様にさらなる修正を加えなければならなくなる．本論文では，TCPの仕様を 1回修正すれば 2度とデッドロック問題が発生しないよう

に，個々のデッドロック問題の原因によらずに，TCPデッドロック問題のすべてを統一的な方法で解決することを目指す．また，7.2節の iiや iiiの解決策は，7.3節で述べたようにTCPのデータ転送モデルを考

慮していないため，デッドロックが起きないときでもトラヒックが増加するという問題がある．本論文では，第 3章で述べた TCPのトラヒックを軽減するための仕組みに影響することなく，デッドロック問題の解決を目指す．以上のことを実現するため，本論文では，送信ホストが受信ホストの確認応答を制御す

ることで，デッドロックを解決する方法を提案する．図 8.1に示すように，TCPヘッダの予約ビット [7]に，NDAフラグ (Never Delay ACK flag)と FDAフラグ (Force Delay

ACK flag)という 2つの制御フラグを追加する．

133

134 第 8章 TCPデッドロック問題の解決策の提案・実装・評価

FIN

Source Port Destination Port

Sequence Number

Acknowledgment Number

DataOffset Window

Checksum Urgent Pointer

NDA

FDA

URG

ACK

PSH

RST

SYN

将来のために予約されているbit

図 8.1: 提案する TCPのヘッダ

8.1.1 NDAフラグ (Never Delay ACK flag)

NDAフラグは遅延確認応答をせずに，すぐに確認応答を返送させるためのものである．このフラグを利用して，データを 2MSS送信するたびに確認応答するように制御したり，デッドロック状態になることを防いだりする．

送信ホスト

• 2MSSのデータを送信するたびに 1にする．(既存のTCPと挙動を同じにするため)

• 確認応答を受信しない限り送信処理が停止する場合に 1にする．(TCPデッドロックを回避するため)

受信ホスト

• 1のときには，遅延なくそのセグメントに対する確認応答をする．

8.1.2 FDAフラグ (Force Delay ACK flag)

FDAフラグは，受信ホストがどんなにたくさんのセグメントを受信したとしても，すぐに確認応答をせずに遅延させるように制御するためのフラグである．このフラグにより，不必要な確認応答パケットの送信を防ぐ．ただし，確認応答が遅延しすぎることによるセグメントの再送を防ぐため，従来のTCPの仕様 [21]と同様に，確認応答の遅延時間の上限は 0.5秒とする．

送信ホスト

• データ・セグメントのすべてで FDAフラグを 1にする．ただし，FDAフラグを 1

にした場合は，NDAフラグで確認応答を正しく制御しなければならない．

8.1 デッドロック問題の解決策の提案 135

受信ホスト

• 1のときには，そのデータ・セグメントに対する確認応答を遅延させる．ただし，従来のTCPの遅延確認応答処理と同様に，遅延時間の最大値は 0.5秒以内でなければならない．

• NDAフラグが 1のときは NDAフラグの処理が優先され，FDAフラグの値は無効となる．

ただし，受信すべきシーケンス番号を持つデータセグメントではなくそれ以降のデータセグメントを受信した場合には，TCPの仕様と全く同じように，遅延無く受信すべきシーケンス番号の確認応答パケットを送信する．この確認応答はセグメントの喪失を意味し，TCPの高速再送制御 (Fast Retransmit)をうながす働きを持つ．このように，セグメントの喪失が発生していると考えられるときには，FDAフラグは無視される．なお，この FDAフラグは受信処理に対して状態を持たせないという役割を持つ．NDA

フラグやFDAフラグを配置するTCPヘッダの予約ビットは，経路の途中にTCP/IPヘッダ圧縮機能 [75]を使うネットワークがあると 0にクリアされる．インターネットでは経路が変動する可能性があるため，FDAフラグが受信ホストまで伝わったり伝わらなかったりする可能性がある．このこのことが新たなデッドロックとなることを防ぐため，送信セグメントの FDAフラグをすべて 1にする．本提案により，予約ビットが 0にクリアされる場合は従来のTCPと同じ遅延確認応答処理を行い，0にクリアされない場合はNDAフラグを基に確認応答処理を制御することになる．このように，NDAと FDAの 2つのビットを利用することにより，経路の変動などの結果，2つのビットが受信ホストに伝わったり伝わらなかったり変化した場合でも，従来と同じ性能を維持できる．

8.1.3 NDAフラグとFDAフラグの設定に関する補足事項

TCPには，データの送受信時以外に確認応答のやりとりする特別な処理がある．この処理とは，コネクションの確立と切断，ウィンドウ・プローブ，キープアライブである．通常の TCPの実装では，これらのときには確認応答を遅延させないため，デッドロックは発生しない．このため，NDAフラグやFDAフラグを設定しなくても問題は発生しないはずである．しかし，プロトコルの仕様の曖昧さをなくすためには，NDAと FDAを設定すべきか設定すべきでないかを明確にする必要がある．

コネクション確立時，切断時

通常の TCPの実装では，コネクションの確立時や切断時の SYNセグメントや FINセグメントを受信した場合には，遅延せずにすぐに確認応答するように実装されている．コ


ネクション確立直後にクライアントから要求を送る場合や，TCPのハーフ・クローズ後にデータを送信するアプリケーションの場合は，遅延させた方がトラヒックを軽減できる場合もある．しかし，アプリケーションがすぐにデータを送信するかどうかはアプリケーションにしか分からず，TCPには判断できない．

SYNセグメントや，FINセグメントは，明示的にコードビットが設定されている．そのため，受信ホストでは，SYNセグメントや FINセグメント固有の処理をすることができる．だから，送信側が NDAフラグと FDAフラグで確認応答の処理を決定する必要はないと考えられる．そのため，NDAフラグも，FDAフラグも共に 0にするべきだと考える．

ウィンドウ・プローブ

受信ホストの負荷が高くなったり，アプリケーションがデータの送信を一時停止した場合，受信ホストの受信バッファの空きが無くなる場合がある．こうなった場合には，受信ホストは送信ホストに受信可能なウィンドウの大きさが 0 octetであると通知する．これを受信した送信ホストは，データの送信を一時的に停止させる．

TCPがバッファに格納されていた受信データをアプリケーションに渡し，受信バッファの空きが大きくなると，ウィンドウの値を通知して，受信可能になったことを送信ホストに通知する．この通知を送信ホストが受信したら，データの送信が再開される．しかし，このウィンドウを通知するパケットが喪失する可能性がある．喪失した場合に，送信ホストはいつまでも受信ホストのバッファが受信可能になったことを知ることができなくなり，データ転送が完全に停止する．このような問題を避けるため，送信ホストが 0 octetのウィンドウ通知を受けた場合には，時々(例えば 1分間隔で)ウィンドウ・プローブ・パケットを送信しなければならないことになっている．ウィンドウ・プローブ・パケットは，送信データが 1バイトだけ含まれるパケットであ

る．このパケットを受信した場合には，現在のウィンドウを遅延無く通知しなければならない．ただし，シリー・ウィンドウ・シンドローム回避策により，2MSS以下や，バッファ・サイズの 50%未満しか空きが無い場合には，ウィンドウの値は 0octetとして通知される．ウィンドウ・プローブ・パケットは，必ず確認応答を受信することを期待しており，FDA

フラグを付けるべきである．そうすれば，受信ホストにとっても，曖昧さが無くなる．

キープ・アライブ

TCPには，コネクションが継続しているかどうかを確認するための機能が備えられている．これは，キープ・アライブ機能と呼ばれる．これは，次のような問題を解決するために用意されている．例えば，WWWサーバにコネクションを確立した直後に，クライアントのコンピュー

タで不具合が発生し，パケットを何も送信できないままコンピュータが再起動されたとす

8.2 本提案と TCPデータ転送モデル 137

る．そうすると，通常の実装ではTCP/IPのコネクションに関する情報はすべて失われてしまう．その結果，サーバはコネクションの情報を持っているため，クライアントからの要求を待つがクライアントからは要求は来ないという状態になる．サーバが永久に要求を待った場合，サーバには永久にコネクション情報を記憶することになり，サーバの資源を浪費することになる．このような問題の発生を避けるため，誰でもアクセスできるように設定されるインターネットのサーバでは TCPのキープアライブ機能が利用される．なお，BGPでは，アプリケーションレベルでキープ・アライブ機能を実現している．こ

のように，TCPではなく，アプリケーション層やセッション層でもキープアライブの機能は実現できる．しかし，現在インターネットで利用されているほとんどのアプリケーションには，キープ・アライブ機能は実装されていない．そのため，必要に応じてTCPのキープアライブ機能を利用することになる．データ通信がしばらく行われていない場合 (例えば 2時間程度)に，0バイトのパケット

を送信する．これがキープ・アライブパケットと呼ばれる．このパケットは，最後に相手に送信した確認応答パケットとほぼ同じものになる．このキープ・アライブ・パケットを受信した場合には，遅延無く確認応答を送信しなければならない．ただし，このキープ・アライブ・パケットは，見かけ上は確認応答パケットと何も変わ

らない．そのため，パケットのフォーマットだけからは，単なる確認応答なのか，キープ・アライブ・パケットなのか判断ができない．キープ・アライブ・パケットは，確認応答されることを期待して送信されるパケットで

ある．よって，FDAフラグを付けるべきである．そうすれば，受信ホストにとっても，そのパケットが単なる確認応答パケットではなく，キープ・アライブ・パケットであることがわかり，曖昧さがなくなる．

8.2 本提案とTCPデータ転送モデルTCPの改良をする場合には，TCPが対応しているデータ転送モデルに悪影響があって

はならない．本論文で提案する 3つのデータ転送モデルのときにの挙動について考える．

バルク・データ転送モデル

まず，バルクデータ転送モデルのときの TCPの挙動を図 8.2に示す．このモデルの場合，データを送信するホストが，データを 2MSS送信するたびにNDAフラグを設定することになる．このため，2MSS受信するたびに，データを受信したホストが確認応答をすることになる．このため，現在の TCPと全く同じ挙動をする．


HOST A

ACK

PUSH

ACK

ACK

HOST B1MSS

NDA

NDA

NDA

図 8.2: バルク・データ転送

PUSH

PUSH

PUSH

PUSH

HOST A

ACK

ACK

ACK

HOST B

FDA

FDA

FDA

FDA

図 8.3: インタラクティブ・データ転送

インタラクティブ・データ転送モデル

インタラクティブ・データ転送モデルのときのTCPの挙動を図 8.3に示す．このモデルの場合，送信するデータは 1MSS未満である．このため，NDAフラグは設定されない．その結果，確認応答は遅延されることになる．データを受信したホストは，返事となるデータを作成し，送信することになる．この返事となるデータが送信されるタイミングが，遅延確認応答を送信するタイマのタイミングよりも早かった場合には，確認応答はデータ・セグメントにピギーバックされる形で送信される．このため，現在の TCPと全く同じ挙動をする．

8.3 実装 139

PUSH

PUSH

PUSH

PUSH

HOST A

PUSHACK

PUSH

PUSH

ACK

PUSH

ACKPUSH

HOST B

FDA

FDA

FDA

FDA

FDA

FDA

FDAFDA

FDA

図 8.4: 即時性を必要とするインタラクティブ・データ転送

即時性を必要とするインタラクティブ・データ転送モデル

即時性を必要とするインタラクティブ・データ転送モデルのときのTCPの挙動を図 8.4

に示す．送信するデータの多くが 1MSS未満である．そのため，NDAフラグは設定されない．その結果，確認応答は遅延されることになる．データを受信したホストは，返事となるデータを作成しすることもあれば，しないこともある．このため，現在の TCPと全く同じ挙動をする．

8.3 実装本提案の有効性を評価・検証するため，実装と実験を行った．インターネットのプロト

コルでは，実装して動作させることが非常に重要視される．実装しなければ，実際に動作するのか，また，効果があるのかが分からないからである．TCP短期デッドロックに関する研究論文 [27] [32] [28] では，特定のオペレーティング・システムを対象にして深く追究されてきたという歴史がある．このことを考えても，特定のオペレーティング・システム固有の問題を含んでいたとしても，実装して評価することは十分に意義のあることだといえる．実装は BSDI社の Internet Server V3.0 (BSD/OS 3.0)をベースとして利用した．この

オペレーティング・システムは 4.4BSD Lite2に基づいており，BSDのTCP/IPプロトコルスタックのソースコードを基に，BSDI社が改変したものが使われている．また，経路MTU探索が実装されているため，それが原因で発生するデッドロックに関する評価を行うことができる．多くの TCP/IPプロトコル・スタックは，BSDの実装を手本にして発展してきたという歴史があり，本オペレーティング・システムへの実装は，他のオペレーティング・システムへの実装の場合にも参考になると考えられる．


データ送信処理時

送信処理は，次のように実装した．

(1) すべてのデータ・セグメントで FDAフラグを 1にする

(2) データを 2MSS送信するたびにNDAフラグを 1にする

(3) デッドロックの回避のためにNDAフラグを 1にする

(1)は受信したセグメントに対する確認応答を遅延させることを意味する．そして，FDA

フラグを 1にするということは，NDAフラグを利用して送信ホストが受信ホストの遅延確認応答を操作することも意味している．TCP/IPのヘッダ圧縮機能 [75]を利用するネットワークを TCPパケットが通過すると，TCPの予約ビットが 0に初期化される．このTCP/IPのヘッダ圧縮機能は，64kbps以下のモデムや ISDNを使ったネットワークで利用されることがある．インターネットでは経路が変更される可能性があるため，通信開始時には予約ビットが 0にクリアされなくても，通信途中で予約ビットが 0にクリアされるようになったり，その逆のことも起こりうる．このことによるデッドロック問題の発生を防ぐため，FDAフラグは常に 1になるように設定した．

(2)は現在の TCPで使われている遅延確認応答と互換性を持たせるためである．遅延確認応答では，2MSS受信する度に確認応答をすることになっている．本提案の場合は，これを送信ホストが制御しなければならない．そこで，受信ホストが 2MSS受信する度に確認応答するように，送信ホストが 2MSS送信する度にNDAフラグを 1に設定する設定する．最後に NDA を設定して送信したセグメントの，先頭データのシーケンス番号を

SEQNDA，送信済みのデータの最後のシーケンス番号を SEQ，最大セグメント長をt maxseg，次に送信するセグメントの大きさを lenとすると，次の論理式で表される状態のときにNDAフラグを 1に設定する．

(SEQNDA − SEQ) + len ≥ t maxseg × 2 (8.1)

送信済みのシーケンス番号を SEQ，確認応答されているシーケンス番号を ACK とすると，次の式が成り立つ場合には，最後にNDAを設定して送信したセグメントのシーケンス番号 SEQNDA，を SEQに設定する．

SEQ = ACK (8.2)

(3)の処理は，データ送信を停止する直前のセグメントで行わなければならない．セグメントの送信時に，次のセグメントの送信が停止するかどうか，分かる場合と，分からない場合がある．それぞれの実装について詳しく説明する．

8.3 実装 141

まず，送信停止が分かる場合について述べる．送信可能なセグメントが 1つあるとき，そのセグメントの送信後に次の状態になると，それ以降のセグメントの送信が停止する．

1. 送信可能なウィンドウの大きさが，1MSS未満 (Nagleアルゴリズム有効時)または，0 (Nagleアルゴリズム無効時) になる場合．

2. 送信ソケット・バッファの残りの大きさが，1MSS未満 (Nagleアルゴリズム有効時)

または，0 (Nagleアルゴリズム無効時)になる場合．

これらの時にNDAフラグを設定する．最大セグメント長を t maxseg，送信済で確認応答待ちのデータの大きさを off，次に送

信するセグメントの大きさを len，ソケットバッファの残りの大きさを sb hiwat，送信可能なウィンドウの大きさをwin とする．1.の条件を満たす論理式は次のように表される．

( (Nagle = ON) ∧ (win − len < t maxseg))∨ ((Nagle = OFF) ∧ (win − len = 0))

(8.3)

そして，2.の条件を満たす論理式は次のように表される．

( (Nagle = ON) ∧ (sb hiwat − off − len < t maxseg))∨ ((Nagle = OFF) ∧ (sb hiwat − off − len = 0))

(8.4)

ただし，NDAフラグを 1に設定したセグメントが既に送信されている場合は，確認応答パケットが来ることが期待される．そうなれば，デッドロックは発生しなくなると考えられる．不必要な確認応答が増加することを防ぐため，既にNDAフラグを 1に設定したセグメントが送信済である場合は，NDAフラグを 0に設定することにした．すなわち，最後に NDAを設定して送信したセグメントのシーケンス番号を SEQNDA，確認応答されているシーケンス番号をACKとすると，次の式が真となるときには，確認応答パケットが到着する可能性が強いため，NDAフラグを 1には設定しない．

ACK < SEQNDA (8.5)

(8.3)～(8.5)式より，送信停止が分かる場合の条件をまとめると次の論理式で表される．

(ACK ≥ SEQNDA)∧( (Nagle = ON)∨( (win − len < t maxseg)∧(sb hiwat − off − len < t maxseg)))

( (Nagle = OFF)∨( (win − len = 0)∧(sb hiwat − off − len = 0))))

(8.6)


SOCKET

T C P

I P

Application

SOCKET

T C P

I P

Application

PRU_SENDPRU_SENDNOW

BSDのTCP/IPスタックモデルデッドロック問題を解決するためのスタックモデル

PRU_SEND

sendsend

TCPが送信を制御強制的に送信

ip_outputip_output

(*ifp->if_output)() (*ifp->if_output)()

図 8.5: ソケットと TCPのモジュール間通信の強化

次に，送信停止が分からない場合について述べる．7.1.2節で述べた，ソケットのバッファが足りなくなり，処理が停止するタイミングは事前にはわからない．アプリケーションのメッセージ・サイズによって，停止するかしないか変わるからである．そこで，ソケットが sbwait()を呼び出して処理を停止するときに，NDAフラグを 1に設定してセグメントを強制的に送信するように実装した．この処理を実現するため，図 8.5に示すようにPRU SENDNOWメッセージを追加した．ソケットは，ソケット・バッファが足りなくなり処理を停止するときに，TCPに PRU SENDNOWメッセージを送る．このメッセージを TCPが受信した場合，NDAフラグを 1に設定して，TCPのバッファに格納されている未送信データを強制的に送信する．ただし，この処理はNagleアルゴリズムに違反するため，小さなセグメントが送出され

やすくなる．また，このセグメントに対する確認応答は遅延されないため，シリー・ウィンドウ・シンドロームを発生させる危険性がある．これを避けるため，送信停止が分かる場合と同様に，PRU SENDNOWメッセージをTCPモジュールが受けたとしても，既にNDAフラグを 1に設定したセグメントが送信されている場合は，セグメントを送信しないことにする．既にNDAフラグを 1に設定したセグメントが送信されている場合は，確認応答が来ることが期待される．確認応答が来れば，ソケットのバッファが解放され，より多くのデータを送信できるようになる．そうなれば，デッドロックが発生しない可能性がある．そこで，NDAフラグを 1に設定したセグメントが送信中の場合は，PRU SENDNOW

メッセージは PRU SENDメッセージと同じ意味に解釈され，強制的な送信処理は行われないように実装した．

8.3 実装 143

最後に NDAを設定して送信したセグメントのシーケンス番号を SEQNDA，確認応答されているシーケンス番号をACK，ソケットからPRU SENDNOWメッセージで送信要求されていることを pru sendnow = YES とすると，次の式が真となるときのみ，NDA

フラグを 1に設定して強制的に送信する．

(ACK ≥ SEQNDA) ∧ (pru sendnow = YES) (8.7)

式 (8.1)，(8.5)，(8.7) をまとめると，次の式を満たすときにNDAフラグを 1に設定することにした．

((SEQNDA − SEQ) + len ≥ t maxseg × 2)∨( (ACK ≥ SEQNDA)

∧( (pru sendnow = YES)∨( (Nagle = ON)∨( (win − len < t maxseg)∧(sb hiwat − off − len < t maxseg)))

∨( (Nagle = OFF)∨( (win − len = 0)∧(sb hiwat − off − len = 0)))))

(8.8)

データ受信処理時 (確認応答処理時)

BSD/OS 3.0の実装では，通常のデータセグメントを受信中は，次の場合に確認応答が送信される．

1. 2MSS以上のデータを受信したとき

2. 受信バッファ(so rcv.sb hiwat)の 50%以上のデータを受信したとき

3. 0.2秒間隔のファスト・タイマが実行されたときに，未送信の確認応答がある場合

本提案の実装では，不要な確認応答の増加を減らすため，FDAフラグが 1の場合は次の場合にのみ確認応答を送信するように実装した．

1. NDAフラグが 1のとき


また，FDAフラグが 0の場合は次の場合にのみ確認応答を送信するように実装した．

1. 2MSS以上のデータを受信したとき


2. 受信バッファ(so rcv.sb hiwat)の 50%以上のデータを受信したとき


4. NDAフラグが 1のとき

8.4 検証実験本論文の提案が，実際のネットワーク・システム上で，有効に働くかどうかを検証する

ために実験を行った．本提案の効果の程度を比較するために，他の 3つのアルゴリズムでも同じ実験を行った．使用したアルゴリズムは次の 4種類である．

実装 1 BSD/OS 3.0の実装のままで無変更実装 2 常に確認応答を遅延させない実装 3 PUSHフラグが 1のときには確認応答を遅延させない実装 4 本論文の提案

検証実験では，デッドロックが起こりうる環境で，バルク・データ転送のデータ・トラヒックを転送し，スループットや受信データ量の時間推移を測定した．また，カーネル内部の統計情報から，送信セグメントや確認応答の数を求めた．このとき，測定しているデータ以外のトラヒック (測定ツールの制御トラヒックなど)が，含まれないように処理した．測定は，送受信の両方のホストを同じ実装にして，その実装ごとに行った．なお，測定結果は 1回の実験結果の値である．ただし，示した結果以外にも，予備実験を複数回行っており，再現性に関しては確認済である．また，予備実験との比較から，スループットの精度は 0.1Mbps程度以上，測定時間の精度は 0.01秒程度以上はあると思われる．実験環境は，図 8.6または，図 8.7である．実験時の設定は図または表，本文中に記載

されている場合を除き表 8.1に示したとおりである．図 8.6の環境は，2つのコンピュータのみで FDDIリングを構成している．そのため本

実験に関係しない他のトラヒックは流れていない．図 8.7の FDDI LANの部分は曼陀羅環境の一部であり，他のトラヒックが流れている可能性がある．詳しくは 8.6.1節で論じるが，他のトラヒックは本実験にはほとんど影響しない．また，若干の影響があったとしても本実験の目的や結論には影響しないものである．なお，BSDの実装では，送信バッファと受信バッファの内の，大きさが小さい方の値が

ウィンドウの最大値を決める．そのため，この節ではバッファ・サイズとウィンドウ・サイズという用語を特に区別せずに使用する．

1)http://www.cup.hp.com/netperf/NetperfPage.htmlから入手できる

8.4 検証実験 145

FDDI ReceiverSender

NIC: DEC DEFPA-DA(PCI)

CPU:Intel Pentium/100MHz CPU:Intel Pentium/160HMz

NIC: DEC DEFPA-AA(PCI)

OS: BSDI Internet Server 3.0 OS: BSDI Internet Server 3.0

100MbpsMTU=4470octets

図 8.6: 実験環境

Router

Ethernet FDDI LAN

Router

MTU=1500 MTU=4352

ReceiverSender

FDDIMTU=4470

CiscoAGS+Cisco7000

図 8.7: 経路MTU探索の実験環境

表 8.1 実験のパラメータ (図，表または本文中に記載されている場合を除く)

OS BSDI Internet Server 3.0 (BSD/OS 3.0)(K300-001 patch apply)

メッセージ・サイズ 8192byte固定または，2048byte固定バッファ・サイズ 65535byteMTU 4470octet (*BSD/OS 3.0のデフォルト)MSS 4352octet (*BSD/OS 3.0のデフォルト)ヘッダの長さ IP:20 octet, TCP: 20 + 12 octet

(TCPタイムスタンプ・オプション付き)Nagleアルゴリズム有効測定ツール Netperf1)

DBS (Distributed Benchmark System)


8.5 実験結果8.5.1 実験 1: 送信バッファがMSSに比べて十分大きくない場合

図 8.6に示す環境で，バッファ・サイズを変えてスループットを計測した．Nagleアルゴリズム有効時の結果を表 8.5.1～8.5に，Nagleアルゴリズム無効時の結果を表 8.6～8.9

に示す．なおメッセージ・サイズは 8192byteで，データ転送時間は 10秒間である．表 8.5.1で，送信バッファ・サイズが 3MSS未満の領域，すなわち送信バッファ・サイズ

が 12888byte以下の領域では，スループットが 1Mbps未満になっている部分がある．これらの領域ではデッドロックが発生している．なお，送信バッファ・サイズが 12888byte以下の領域でもも，受信バッファが小さい場合

にはデッドロックは起こっていない．BSD/OS 3.0では，受信したデータが受信バッファの50%に達した場合には確認応答される．そのため，受信バッファが小さいときには，2MSS

未満のデータしか受信していなくても確認応答が遅延されなくなりデッドロックが発生しない場合がある．なお，図 8.5.1をみると，送信バッファが 16384byteのときのスループットは，受信バッ

ファが 12288byteのときである．これよりもバッファが大きい場合には，スループットが若干小さくなっている．これは，デッドロックが発生しているのではない．受信バッファが 12288byteのときには，バッファの 50%である 6144byte受信したときに確認応答される．受信バッファがこれよりも大きい場合に比べて，早く確認応答されるためスループットが向上している．表 8.5.1～8.5をみると，実装 4以外ではデッドロックが発生していることが分かる．デッ

ドロックが起きないはずの実装 2でも，スループットが 0.01Mbpsという極端に小さな領域がある．これは，BSD/OS 3.0では送信バッファがメッセージ・サイズに比べて極端に小さい場合は，すべての確認応答が来ていたとしても，すぐには送信処理が行われないような実装になっているからである．これは，BSD/OS 3.0のバグだとも考えられる．BSD/OS

3.0のアプリケーションでは，このような小さな値にバッファ・サイズを設定するものがないため，明らかになっていなかったと思われる．表 8.5.1～8.5をみると，実装 1，3，4では確認応答の割合が 1MSSあたり 0.5であるが，

実装 2では 1MSSあたり約 1であり約 2倍の割合になっている．また，表 8.5.1～8.5をみると，実装 1と 4では確認応答の割合が 1MSSあたり約 0.5であるが，実装 2では 1MSS

あたり約 2という具合に 4倍の割合になっている．このことから，実装 2と 3は，現在のTCPと比べて確認応答トラヒックが 2倍以上に増加しており，異なる挙動を示すものであることが明白である．これに対して，実装 4は，現在の TCPと同程度のトラヒック量であり，現在の TCPの挙動とほぼ同じでありながら，デッドロックを解決するという結果が得られた．

8.5 実験結果 147

表 8.2 実装 1: TCPバッファサイズとスループット・転送効率の関係(Nagleアルゴリズムが有効のとき)

受信バッファサイズ (byte)4096 8192 12288 16384 32768 65535

4096 28.34 0.01 0.01 0.01 0.01 0.012.13 2.00 2.00 2.00 2.00 2.29

送 2.13 2.25 2.25 2.25 2.25 2.62信 8192 24.81 14.53 12.99 0.33 0.33 0.33バ 1.07 1.06 1.06 1.10 1.10 1.10ッ 1.07 0.54 0.54 0.58 0.58 0.58フ 12288 24.39 23.85 22.68 0.34 0.34 0.34ァ 1.09 1.06 1.06 1.10 1.10 1.10サ 1.09 0.53 0.53 0.58 0.58 0.58イ 16384 24.22 35.94 41.32 37.94 38.73 38.54ズ 1.07 1.00 1.00 1.03 1.02 1.02_ 1.07 0.50 0.50 0.44 0.46 0.47b 32768 24.41 36.05 42.81 55.79 55.26 54.74y 1.06 1.00 1.00 1.00 1.00 1.00t 1.06 0.50 0.46 0.50 0.50 0.50e 65535 24.09 36.12 42.61 55.54 54.80 54.56^ 1.07 1.00 1.00 1.00 1.00 1.00

1.07 0.50 0.46 0.50 0.50 0.50上段: スループット (M bps)中段: 送信データ 1MSSあたりの送信パケット数の割合下段: 送信データ 1MSSあたりの確認応答パケット数の割合


受信バッファサイズ (byte)4096 8192 12288 16384 32768 65535

4096 28.51 0.02 0.02 0.02 0.02 0.022.13 1.82 1.82 1.82 1.82 1.82

送 2.13 2.02 2.02 2.02 2.02 2.02信 8192 24.63 33.33 32.52 33.54 33.22 33.57バ 1.10 1.06 1.06 1.06 1.06 1.06ッ 1.10 1.06 1.06 1.06 1.06 1.06フ 12288 24.64 37.92 37.61 37.72 37.18 37.86ァ 1.08 1.01 1.02 1.05 1.01 1.02サ 1.08 1.00 0.99 0.96 0.99 0.98イ 16384 24.35 43.54 47.60 48.75 48.22 47.61ズ 1.09 1.00 1.00 1.00 1.00 1.00_ 1.09 1.00 1.00 1.00 1.00 1.00b 32768 24.70 42.56 51.51 52.17 51.22 51.69y 1.12 1.00 1.00 1.00 1.00 1.00t 1.12 1.00 1.00 1.00 1.00 1.00e 65535 24.39 42.06 50.99 50.69 51.11 49.72^ 1.11 1.00 1.00 1.00 1.00 1.00




受信バッファサイズ (byte)4096 8192 12288 16384 32768 65535

4096 28.02 0.02 0.02 0.02 0.02 0.022.13 1.82 1.82 1.82 1.82 1.82

送 2.13 2.02 2.02 2.02 2.02 2.02信 8192 24.60 21.05 25.28 23.05 22.42 19.56バ 1.10 1.06 1.06 1.06 1.06 1.06ッ 1.10 0.54 0.54 0.54 0.54 0.54フ 12288 24.46 25.59 25.84 24.56 21.04 20.12ァ 1.08 1.06 1.06 1.06 1.06 1.06サ 1.08 0.54 0.54 0.54 0.54 0.54イ 16384 24.49 36.34 41.05 37.19 37.12 38.45ズ 1.10 1.00 1.00 1.00 1.00 1.00_ 1.10 0.50 0.50 0.50 0.50 0.50b 32768 24.51 36.82 42.81 55.88 56.42 55.46y 1.07 1.00 1.00 1.00 1.00 1.00t 1.07 0.50 0.46 0.50 0.50 0.50e 65535 24.34 37.01 42.19 56.19 55.21 56.17^ 1.11 1.00 1.00 1.00 1.00 1.00



受信バッファサイズ (byte)4096 8192 12288 16384 32768 65535

4096 18.87 20.98 21.06 20.92 20.86 21.172.13 1.06 1.06 1.06 1.06 1.06

送 2.13 1.06 1.06 1.06 1.06 1.06信 8192 24.27 28.39 30.66 29.42 28.91 30.52バ 1.06 1.06 1.06 1.06 1.06 1.06ッ 1.06 0.53 0.53 0.53 0.54 0.53フ 12288 24.42 19.76 33.78 30.71 30.88 33.43ァ 1.06 1.32 1.06 1.06 1.06 1.06サ 1.06 0.53 0.36 0.36 0.36 0.36イ 16384 24.07 35.95 41.48 41.17 41.92 41.30ズ 1.06 1.00 1.00 1.00 1.00 1.00_ 1.06 0.50 0.50 0.50 0.50 0.50b 32768 24.31 29.65 41.92 56.94 55.67 55.49y 1.06 1.00 1.00 1.00 1.00 1.00t 1.06 0.50 0.50 0.50 0.50 0.50e 65535 24.01 35.06 41.89 54.41 54.17 56.35^ 1.06 1.00 1.00 1.00 1.00 1.00


8.5 実験結果 149

表 8.6 実装 1: TCPバッファサイズとスループット・転送効率の関係(Nagleアルゴリズムが無効のとき)

受信バッファサイズ (byte)4096 8192 12288 16384 32768 65535

4096 28.88 0.17 0.16 0.17 0.17 0.172.13 2.20 2.20 2.20 2.20 2.20

送 2.13 1.16 1.16 1.16 1.16 1.16信 8192 24.84 35.76 33.56 0.33 0.33 0.33バ 1.11 2.13 2.13 2.16 2.16 2.16ッ 1.11 0.71 0.53 0.58 0.58 0.58フ 12288 24.74 37.73 43.58 40.64 40.14 40.07ァ 1.08 1.58 2.13 2.13 2.13 2.13サ 1.08 0.55 0.53 0.43 0.43 0.43イ 16384 24.84 36.85 47.95 47.84 47.42 47.55ズ 1.09 1.06 2.12 2.13 2.13 2.13_ 1.09 0.53 0.53 0.43 0.43 0.43b 32768 24.30 35.36 45.22 48.22 47.98 47.96y 1.08 1.00 1.56 2.12 2.12 2.12t 1.08 0.50 0.49 0.43 0.43 0.43e 65535 24.30 34.60 43.21 48.02 47.29 47.45^ 1.10 1.00 1.19 2.12 2.12 2.12



受信バッファサイズ (byte)4096 8192 12288 16384 32768 65535

4096 28.56 28.60 28.77 28.03 28.71 28.272.13 2.13 2.13 2.13 2.13 2.13

送 2.12 2.13 2.13 2.13 2.13 2.12信 8192 24.94 39.12 39.56 39.56 39.36 39.12バ 1.13 2.13 2.13 2.13 2.13 2.13ッ 1.13 2.13 2.12 2.12 2.12 2.12フ 12288 24.74 39.45 39.10 39.58 39.17 38.58ァ 1.07 2.13 2.13 2.13 2.13 2.13サ 1.07 2.12 2.12 2.12 2.12 2.12イ 16384 24.81 39.90 39.34 39.44 39.60 39.35ズ 1.10 2.13 2.13 2.13 2.13 2.13_ 1.10 2.13 2.13 2.12 2.12 2.12b 32768 24.76 39.20 39.05 38.66 38.90 38.76y 1.12 2.13 2.13 2.13 2.13 2.13t 1.12 2.12 2.12 2.12 2.12 2.12e 65535 24.86 38.55 38.27 38.60 38.40 38.81^ 1.20 2.13 2.13 2.13 2.13 2.13




受信バッファサイズ (byte)4096 8192 12288 16384 32768 65535

4096 28.87 28.14 28.61 28.11 28.29 28.302.13 2.13 2.13 2.13 2.13 2.13

送 2.13 2.13 2.13 2.13 2.13 2.13信 8192 24.74 39.07 39.43 39.01 39.14 39.83バ 1.09 2.13 2.13 2.13 2.13 2.13ッ 1.09 2.13 2.12 2.12 2.12 2.12フ 12288 24.99 39.22 39.03 39.97 39.29 38.72ァ 1.11 2.13 2.13 2.13 2.13 2.13サ 1.11 2.12 2.13 2.13 2.12 2.12イ 16384 24.82 38.63 38.65 39.52 39.02 39.32ズ 1.08 2.13 2.13 2.13 2.13 2.13_ 1.08 2.13 2.12 2.13 2.13 2.12b 32768 24.32 38.59 38.74 38.99 38.43 38.25y 1.08 2.13 2.13 2.13 2.13 2.13t 1.08 2.12 2.13 2.12 2.12 2.12e 65535 24.55 38.34 38.90 38.78 38.80 38.36^ 1.10 2.13 2.13 2.13 2.13 2.13



受信バッファサイズ (byte)4096 8192 12288 16384 32768 65535

4096 24.69 24.27 24.59 24.71 24.60 24.842.13 2.13 2.13 2.13 2.13 2.13

送 1.07 1.07 1.06 1.07 1.06 1.06信 8192 24.11 33.48 33.25 33.52 33.02 32.99バ 1.06 2.13 2.13 2.13 2.13 2.13ッ 1.06 0.53 0.53 0.53 0.53 0.53フ 12288 24.10 35.53 37.45 37.24 37.76 37.95ァ 1.06 2.09 2.12 2.12 2.12 2.12サ 1.06 0.50 0.43 0.44 0.43 0.45イ 16384 23.67 3.48 43.20 47.51 46.98 48.23ズ 1.06 1.48 2.04 2.12 2.13 2.12_ 1.06 0.51 0.51 0.53 0.53 0.53b 32768 24.04 30.91 42.41 47.49 48.48 48.50y 1.06 1.00 1.00 2.12 2.12 2.12t 1.06 0.50 0.50 0.43 0.43 0.43e 65535 23.93 31.03 42.33 48.22 48.56 47.44^ 1.06 1.00 1.00 2.12 2.12 2.12


8.5 実験結果 151

8.5.2 実験 2: ネットワーク・モジュールの階層化の問題

図 8.6に示す環境で，メッセージ・サイズを 64byteから 64byte単位で，約 9000byteまで設定し，10秒間データ転送を行った時のスループットを測定した．なお，各実装ごとに，送受信のバッファ・サイズを 4096byte，8192byte，12288byte，16384byte，32768byte，65535byteに設定してスループットを測定した．結果を図 8.8～図 8.11に示す．それぞれプロットした点は，1回の測定結果であり，統計的な処理は何もしていない．ただし，予備実験を行っており，再現性に関しては確認済みである．実装 1は計測したすべてのバッファ・サイズで，スループットが極端に小さくなってい

る領域がある．実装 3はバッファ・サイズが 8192byteのときに，メッセージ・サイズによってはスループットが極端に小さくなっている．これは，7.1.2節で述べたデッドロックが起きているためである．実装 2と実装 3は，このように極端にスループットが低下している領域はみられない．なお，すべての実装で，メッセージ・サイズが 0byteに近くなるにしたがって，スルー

プットが小さくなる傾向がみられる．これはシステムコールのオーバーヘッドによるものであり，デッドロックが起きているわけではない．


0

10

20

30

40

50

60

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

Thr

ough

put (

Mbp

s)

Message Size (byte)

buffer= 4096bytebuffer= 8192bytebuffer=12288bytebuffer=16384bytebuffer=32768bytebuffer=65535byte

図 8.8: 実装 1: メッセージ・サイズとスループットの関係

0

10

20

30

40

50

60

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

Thr

ough

put (

Mbp

s)

Message Size (byte)



8.5 実験結果 153

0

10

20

30

40

50

60

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

Thr

ough

put (

Mbp

s)

Message Size (byte)



0

10

20

30

40

50

60

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

Thr

ough

put (

Mbp

s)

Message Size (byte)




8.5.3 実験 3: スロー・スタートの問題

図 8.6に示す環境で，メッセージ・サイズを 2048byteに設定してデータ転送を行い，データ送信開始直後の受信データ量の時間推移を測定した．結果を図 8.12に示す．この図の約0.0秒のときにコネクション確立のための SYNパケットが送信されている．図をみると，実装 1では 0.15秒近くまでデータ転送が停止しており，デッドロックが発生していることが分かる．デッドロックの期間は，実際にはデータ送信時のタイミングにより 0.0秒から0.2秒の間の値になる．デッドロックが発生する場合は，発生しない場合に比べて，平均約 0.1秒の遅延時間が加えられる事になる．高速な LAN環境では，ラウンド・トリップ時間は数ミリ秒であるため，このデッドロックによる約 0.1秒の遅延は大きな遅延といえる．この遅延時間は LANの性能に関係なく加えられるため，人間が対話的に操作するネットワーク・アプリケーションの応答性の限界を，TCPが決めることになりかねない．なお，BSD/OS 3.0の実装では，SYNパケットに対する確認応答も輻輳ウィンドウを増

加させる．そのため，通常のスロー・スタートと異なり，輻輳ウィンドウは 2MSSから始まる．このように実装すれば，デッドロックが起こらなくなるように思われるかもしれないが，測定結果をみるとデッドロックが発生しているのは明白である．データの送信開始時に，アプリケーションが 1MSS未満のメッセージ・サイズでデータ

を送信すると，Nagleアルゴリズムの送信条件を満たすため，データはそのメッセージ・サイズのまま送信される．次のデータ以降は送信中のデータがあるため，Nagleアルゴリズムにより，セグメントは 1MSS単位で送信される．輻輳ウィンドウが 2MSSの場合は，最初に 1MSS未満のセグメントと 1MSSのセグメントの 2つパケットが送信される．しかし，その結果，合計 2MSS未満のデータしか受信ホストに届けられず，デッドロックが発生することになる．

BSD/OS 3.0のスロー・スタートの実装でも，アプリケーションのメッセージ・サイズをMSSよりも大きくすればデッドロックは発生しない．しかし，アプリケーションはMSS

を気にせずに作成されることが普通である．MSSの値はデータリンクのMTUに深く関係するため，結果として，データリンクのMTUを考慮したアプリケーション作りをすることになる．これは，ネットワーク・プロトコルの階層化モデルを考慮すると望ましいことではない．以上のことから，スロー・スタート開始時に，ウィンドウを 2MSSから開始してもデッドロックの解決策になっていないことは明らかである．

8.5 実験結果 155

0

10000

20000

30000

40000

50000

60000

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35

Tot

al D

ata

Time (s)

1 2 3 4

図 8.12: 各実装における通信開始時の受信データの時間推移


8.5.4 実験 4: 経路MTU探索の問題

図 8.6に示す環境でデータ転送を行い，データ送信開始直後の受信データ量の時間推移を測定した．結果を図 8.13に示す．すべての実装で最初の 1秒間はデータの転送が行われていない．また，実装 1と実装 3は 1～6秒までデータが間欠的にしか転送されていない．コネクションの確立時には，FDDIのMTUを基にしたMSSの値がホスト間で交換され

る．しかし，最初のデータ・パケットはEthernetのMTUよりも大きいためルータを通過できない．ルータから ICMP到達不能メッセージ (要フラグメント)で EthernetのMTU

を通達され，次の送信以降はそのMTUを基にしたMSSで送信が行われる．BSD/OS 3.0

の実装では，ICMPによって経路MTUが変更されても，TCPモジュールには通知されない．そのため，TCPモジュールはタイム・アウトによる再送で，はじめてMTUが変更されていることを知る．最初の約 1秒間のデータ転送の停止は，この TCPの再送待ちの時間である．実装 1と実装 3は 1～6秒までデータが間欠的にしか転送されていない．カーネル内部

のTCPトレース機能を利用して，TCPの輻輳ウィンドウとスロー・スタート閾値について調査した．結果を図 8.14に示す．通常のTCPでは，タイム・アウトの原因はすべて輻輳だと考えて実装されている．BSD/OS 3.0では，経路MTU探索によるセグメントの喪失も特別扱いにせず，輻輳時と同じ処理が行われるように実装されている．そのため，輻輳ウィンドウの半分の値にスロー・スタート閾値が設定され，新しいMSSを基にスロー・スタートが行われる．輻輳ウィンドウが閾値を超えると，1つの確認応答につき，(MSS2/

輻輳ウィンドウ)ずつしか増加しない．デッドロックが解消するためには，コネクション確立時に交換したMSSの 2倍になるまで，輻輳ウィンドウが拡大されなければならない．そのため，比較的長い期間，繰り返しデッドロックが発生している．なお，経路MTUはある期間キャッシュされる．キャッシュされているときに，データ

を送信する実験も行った．結果を図 8.15に示す．1秒以内ではあるが，実装 1と実装 3はデータ転送開始時に間欠的なデータ転送を行っている．これは，コネクションの確立時に，キャッシュされているMTUを基にしたMSSではなく，FDDIのMTUを基にしたMSS

の値を交換していることが原因である．キャッシュされているMTUから求めたMSSを交換すれば，このデッドロックは起きず，そういう実装も存在する．しかし，これにはまだ議論の余地がある．現在，経路MTU探索をする場合に，MSSオプションでいくつの値を交換すべきかについて，TCPの標準は決められていない．そのため，各実装は独自の判断でMSSの値を決定しているが，IPv6が本格的に運用されるまでに標準化されないと問題になる可能性がある．

8.5 実験結果 157

0

50000

100000

150000

200000

250000

300000

0 1 2 3 4 5 6 7 8

Tot

al D

ata

Time (s)

1 2 3 4

図 8.13: 経路MTU探索に関する実験

0

2000

4000

6000

8000

10000

12000

0 1 2 3 4 5 6 7 8

Siz

e (b

yte)

Time (s)

cwnd ssthresh

図 8.14 輻輳ウィンドウ (cwnd)とスロー・スタート閾値 (ssthresh)の変化


0

50000

100000

150000

200000

250000

300000

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2

Tot

al D

ata

Time (s)

1 2 3 4

図 8.15 経路MTU探索に関する実験 (経路MTUがキャッシュされている場合)

8.5 実験結果 159

8.5.5 トラヒック量の評価

トラヒック量の評価をするため，図 8.6の環境で，バッファ・サイズごとのスループットと，送信データ 1MSSあたりの送信パケット数，送信データ 1MSSあたりの確認応答数を計測した．Nagleアルゴリズムが有効な場合の結果を図 8.16～図 8.18に，Nagleアルゴリズムを無効にした場合の結果を図 8.16～図 8.18に示す．実装 1と実装 4は，Nagleアルゴリズムが有効な場合でも無効な場合でも，ほとんど同

じトラヒック量である．しかし，実装 2では，確認応答のトラヒック量が，Nagleアルゴリズムが有効な場合は約 2倍，無効な場合には約 5倍になっている．実装 3では，Nagle

アルゴリズムが有効な場合はほとんど同じであるが，Nagleアルゴリズムが無効な場合には確認応答の割合が約 5倍になっている．

Nagleアルゴリズムが有効な場合，実装 2は，バッファ・サイズが比較的小さな 8k～18kbyteのときには，他の実装よりスループットが約 20%高い．しかし，バッファ・サイズが 20kbyte以上の大きな値になると，逆にスループットが約 10%低くなっている．バッファ・サイズが 3MSSや 4MSS未満の場合，1MSSのデータを最大 2つか 3つしか送信できない．そのため，他の実装では 1RTTあたり 1つの確認応答しか行われないのに対し，実装 2では 2つ以上の確認応答が行われる．このため，実装 2ではパイプライン的な効果が表れ，バッファが小さい場合にスループットが向上する．しかし，バッファが大きくなると，過剰な確認応答によってネットワークやホストの負荷が上昇し，スループットが低下する．


0

10

20

30

40

50

60

10000 100000

Thr

ough

put (

Mbp

s)

Buffer Size (byte)

Implement 1Implement 2Implement 3Implement 4

図 8.16: バッファ・サイズとスループット (Nagle有効)

0

0.5

1

1.5

2

2.5

3

10000 100000

Rat

e of

Sen

d P

acke

t (S

end

Pac

ket /

MS

S)

Buffer Size (byte)


図 8.17 バッファ・サイズと送信データ 1MSSあたりの送信パケット数(Nagle 有効)

8.5 実験結果 161

0

0.5

1

1.5

2

2.5

3

10000 100000

Rat

e of

AC

K (

AC

K r

ecei

ved

/ MS

S)

Buffer Size (byte)


図 8.18 バッファ・サイズと送信データ 1MSSあたりの確認応答パケット数(Nagle 有効)

0

10

20

30

40

50

60

10000 100000

Thr

ough

put (

Mbp

s)

Buffer Size (byte)


図 8.19: バッファ・サイズとスループット (Nagle無効)


0

0.5

1

1.5

2

2.5

3

10000 100000

Rat

e of

Sen

d P

acke

t (S

end

Pac

ket /

MS

S)

Buffer Size (byte)


図 8.20 バッファ・サイズと送信データ 1MSSあたりの送信パケット数(Nagle 無効)

0

0.5

1

1.5

2

2.5

3

10000 100000

Rat

e of

AC

K (

AC

K r

ecei

ved

/ MS

S)

Buffer Size (byte)


図 8.21 バッファ・サイズと送信データ 1MSSあたりの確認応答パケット数(Nagle 無効)

8.6 考察 163

8.6 考察8.6.1 実験結果への他のトラヒックの影響

実験 1，2，3，5は図 8.6に示す環境で行った．この環境は，実験に関係する 2つのホストのみで構成される FDDIリングであり，実験結果に影響するような他のトラヒックは流れていない．実験 4は図 8.7に示す環境で行った．この図の FDDI LANの部分は，奈良先端科学技

術大学院大学のバックボーン・ネットワークである曼陀羅環境の一部である．よって他のトラヒックが流れている可能性がある．他のトラヒックが流れているとしたら実験 4の結果に影響する可能性がある．この節では実験 4の結果に他のトラヒックが及ぼす影響について考える．実験 4の目的は，データ送信開始時に TCP短期デッドロックが発生しているかどうか

を調査することである．TCP短期デッドロックは，TCPのファスト・タイマの間隔である 0.2秒程度のデータの停止期間となって測定結果に現れている．図 8.13，図 8.15をみれば明らかであるが，実装 1と実装 3は約 0.2秒間隔のデータの停止期間が繰り返し発生している．

FDDIはトークンリングによって送信権を制御しているため，公平で輻輳に強いネットワークである．また，pingによる測定では，曼陀羅環境のFDDI LANのラウンド・トリップ時間は 1ミリ秒以下である．このため，たとえ他のトラヒックが流れていたとしても，0.2秒間隔のデータ転送停止の現象への影響は無視できるぐらい小さいと考えられる．また，本実験は，複数回の予備実験の結果と照らし合わせており，結果に再現性があることは確認済みである．以上のことから，実験 4は他のトラヒックのある環境で実験を行ったが，結果への影響

は無視できると考える．

8.6.2 他のトラヒックがある環境での本提案の効果

1～5のデータ転送実験は，他のトラヒックがない環境か，または，他のトラヒックによる結果への影響がない環境で行った．しかし，本提案を運用するときには，他のトラヒックがある環境で利用することになる．ここでは，本提案が他のトラヒックに悪影響を及ぼしたり，他のトラヒックによって悪影響を受けることがないかについて考えることにする．本提案は，デッドロック問題を解決することが目的である．逆にいえば，デッドロック

問題を解決する効果しか期待できない．その結果，他のトラヒックがある場合でも，通常の TCPと同じ振る舞いをするだけで，それ以上の効果や悪影響はないはずである．他のトラヒックがある場合には，次の 2つの影響が考えられる．

1. ラウンド・トリップ時間が大きく変化する


HOST A

ACK

ACK

HOST B

NDA

NDA

喪失

ACK

segment1

segment2

segment3

segment4

segment5

segment2

segment1のsegment1のsegment1の

図 8.22: ウィンドウの途中のデータが喪失した場合

HOST A

ACK

HOST B

NDA喪失

segment1

segment2

segment2

segment1の

遅延確認応答のタイムアウト

再送タイムアウト

NDA

図 8.23 ウィンドウの最後のデータが喪失した場合 (ウィンドウが小さい場合)

2. セグメントが喪失する

ラウンド・トリップ時間の変動は本研究の提案には関係ない．本研究は，遅延確認応答の制御を変更するだけであり，ラウンド・トリップ時間の計測はしていないからである．よって，ラウンド・トリップ時間の変動による再送処理への影響は全くない．次に，セグメントが喪失する場合の振る舞いについて議論する．TCPはセグメントの

喪失時に，送信したセグメントの途中のセグメントが喪失する場合と，送信した最後のセグメントが喪失する場合で異なる動作を示す．それぞれのときの，TCPの振る舞いと，本研究の提案の場合の振る舞いについて説明する．

1. 送信したセグメントの途中のセグメントが喪失した場合

8.6 考察 165

この場合の動作を図 8.22に示す．TCPの仕様では，次に受信すべきシーケンス番号ではなく，それ以降のシーケンス番号のセグメントを受信した場合には，受信すべきシーケンス番号の確認応答が遅延なく送信される．これは，8.1.2節で説明したように，本論文で提案する FDAフラグが設定されていても全く同じ動作が行われる．

2. 送信した最後のセグメントが喪失した場合

この場合の動作を図 8.23に示す．TCPの仕様では，送信する前のセグメントで確認応答を送信しなかった場合には，遅延確認応答の制限時間が経過するまで確認応答が遅延される．これは，本論文で提案するFDAフラグが設定されていても全く同じ動作が行われる．

そして，再送タイムアウトによって再送制御が行われる．これは，通常のTCPと全く同じ動作である．

よって，セグメントの喪失時も，既存の TCPと全く同じ動作をすることが明らかである．このことから，他のトラヒックの影響でセグメントが喪失した場合でも，本提案はTCPの挙動に悪影響を及ぼすことはない．以上より，本提案は，トラヒックがある環境でも，デッドロックが発生していないとき

の TCPと全く同じように振る舞うだけであり，他のトラヒックに影響したり TCPの制御機構に悪影響を及ぼすことはない．また，他のトラヒックがあったとしても，本提案はデッドロック問題を解決することができる．

8.6.3 TCPデッドロック問題の解決の重要性

BSD/OS 3.0のデフォルトの送受信バッファ・サイズは，8192byteである．図 8.8の8192byteのグラフをみると，メッセージ・サイズが 512byteや 4096byteの部分では，デッドロックが発生していることが分かる．512byteや 4096byteは，それぞれ 29，212であり，2進数を処理するコンピュータに取っては切りのいい数字である．よって，オペレーティング・システムやアプリケーション・プログラマに好んで使われる数字である．このため，アプリケーションプログラムのメッセージ・サイズが，このサイズを利用していたとしても不思議はない．また，このグラフは，利用するデータリンクのMTUによって変化する．データリンク

やオペレーティング・システムの実装によっては，1024byteや 8192byteでもデッドロックが発生する可能性がある．現在利用されている大部分のアプリケーション・プログラムでは，データリンクのMTUやTCPのバッファ・サイズには特に注意は払われていない．そのため，特定のシステムでは正常に動作するが，別のシステムへ移したとたんに TCP

デッドロック問題のために動作しなくなるという可能性がある．この様な問題を生じさせないためにも，TCPデッドロック問題を解決することが非常に重要でだといえる．


8.6.4 デッドロック問題の解決に関する考察

本実験はインターネット上で発生しうるすべての状態を網羅しているわけではない．しかし，TCPデッドロック問題を解決しているかどうかを判断するには，十分に網羅できていると考える．本論文の提案である実装 4は，デッドロックの原因として知られている4つの問題を解決できることがほぼ明らかである．また，実装 4は現状の TCPの実装と比べ，トラヒックの増加がほとんどないことも明らかである．実装 2は多くの TCPデッドロック問題を解決できるが，トラヒックが増加するという

問題がある．とくに，広帯域なネットワークの能力を使い切るためには，大きなバッファ(ウィンドウ)が必要になる．しかし，実装 2ではバッファ(ウィンドウ)が大きくなると性能が悪化する．そのため，ネットワークの未来を考えると受け入れられない実装である．実装 3はデッドロックを部分的にしか解決できず，また，トラヒックが増加するため意

味のない実装である．この実装は，TCPのデータ転送モデルをきちんと理解していない人によって行われたと考えられる．以上から，本論文で提案するTCPの短期的なデッドロック問題の解決策は，デッドロッ

クの防止に効果があり，十分に実用的であり，副作用も特にないと結論づける．また，今回の実装では，データを 2MSS送信するたびに確認応答するように実装した．

しかし，実装 2のスループット特性から，確認応答の割合を動的に変化させることにより，スループットを向上できると見込まれる．制御が複雑になる可能性があるが，十分に検討する価値のある課題だと思われる．

8.6.5 インターネットへの適用について

広く運用されているインターネットで，TCPのヘッダのフォーマットを変更することは，互換性上，問題となる可能性がある．しかし，本提案の場合は大きな問題とはならない．TCPの予約ビットは送信時に 0に設定されることになっている．また，受信時には無視されなければならない．中継するルータも同様である．本論文で提案するNDAフラグと FDAフラグの機能を，実装しているホストと実装していないホストが通信を行った場合は，現状の TCPの通信と全く同じように通信できる．つまり，デッドロック問題は何も解決しないが，副作用は特に何も生じない．問題があるとすれば次の 3点が考えられる．

1. TCP/IPのヘッダ圧縮機能 [75]を利用するネットワークを通る場合，NDAフラグ，FDAフラグがともに 0に設定される．

2. TCPの予約ビットが 1になっていると誤動作するホストまたはルータがある場合．

3. NDAフラグと FDAフラグに対応するフラグのいずれか，または両方に 1をつけて送信するホストがある場合.

8.6 考察 167

1.の機能は，ダイアルアップ式のモデムなどを利用した，低速なネットワークで利用されることがある．モデムを利用する場合は，帯域が 128kbps程度以下であることが多い．この小さな帯域を有効に利用するために，TCP/IPのヘッダ圧縮機能が利用されることがある．このヘッダ圧縮機能では予約ビットは考慮されていない．そのため，ヘッダの圧縮後にそれを復元すると，予約ビットは 0になり，値は維持されない．このように，NDAフラグや FDAフラグが 0に設定される場合は，既存の TCPの遅延確認応答と同じ処理が行われる．その結果，デッドロック問題は解決しないが，現状の TCPと全く同様に通信ができる．つまり，問題は解決しないが，現状の TCPの挙動より性能が悪化することはない．また，2.や 3.の機器がある場合には問題であるが，そのような機器はほとんどないと

考えられる．IPv6の場合はまだ実験段階であり，本格的に運用される前にこの提案が標準となれば，

1，2，3のすべての問題が発生せずにすむ．そのため，問題もなく TCPデッドロック問題を解決することができる．IPv6では経路MTU探索が頻繁に行われるようになり，デッドロックの問題が深刻化する可能性がある．本提案はその問題を解決するための有効な手段となるため，本格的に運用される前に標準化する必要がある．

8.6.6 実装に関する考察

どんなに優れた提案であっても，実装が著しく困難な場合には，机上の空論となる可能性がある．特に，インターネットでは，実装が現実的な範囲内で可能かどうかが問われる．実装に何十年もかかるような提案であったり，正しく動作するかどうかの検証が困難ならば，その提案は優れているとはいえない．また，実装が複雑になればなるほど，実行速度が低下する可能性が高くなる．たとえ，スループットを向上させることが目的であったとしても，実装が複雑になったために逆にスループットが低下するという可能性がないわけではない．このように考えると，実装が簡単であることは非常に大きな意味を持つことが分かる．本提案の実装と実験を行い，TCP短期デッドロック問題の解決に効果があることを示

した．この解決および実験により，実装が可能であることを証明したことになる．表 8.10

に実装したプログラムの規模を示すが，実際に TCP/IPのプログラムに加えた変更は 50

ステップ程度である．この数字だけから実装の難易を評価することはできないが，比較的少ない行数の修正であるということはできる．実装の際に最も注意しなければならない部分は，(8.8)式を基にして，NDAフラグの設定をするための条件文である．この条件文は非常に複雑である．しかし，この部分以外の実装は，特に難しい技法は必要なく，実装は

1)BSDのカーネルのコードには GOTO文が数多く含まれている．そのプログラミング・スタイルをあわせるために GOTO文を記述した．


表 8.10: 本提案の実装プログラムの規模項目命令の数変数の宣言 (新規変数) 1変数の宣言 (既存の構造体への追加) 4実行文 (演算および変数への代入) 21条件文 (if文) 15条件文 (case文) 3GOTO文 1) 3関数呼び出し 4合計 51

比較的容易である．カーネルを修正したことのあるプログラマであれば，大きな困難なく実装できるはずである．今回はBSDへの実装であったが，BSD特有の特別な実装は極力避けるようにした．唯

一，ソケット・モジュールからTCPモジュールにPRU SENDNOWメッセージを追加する部分は，BSD固有の実装である．この部分は，実装する各オペレーティング・システムのルールに基づいて実装する必要がある．ただし，アプリケーションとTCPモジュールを結ぶモジュールは，TCPモジュールに何らかのメッセージを送信するはずであり，そこに強制送信用のメッセージを 1つ追加すれば実現できるはずである．よって，PRU SENDNOW

メッセージの実装に関しても，ほとんどのシステムで大きな困難なく実装できると考えられる．以上より，本提案の実装には大きな困難はなく，また，他のオペレーティング・システ

ムへの実装も不可能ではないと考えられる．よって，本提案は実装可能な有効な提案と結論づける．

8.7 まとめこの章では，TCP短期デッドロック問題の解決法について提案を行った．さらに，その

提案を実装し，検証実験の結果について報告した．デッドロックを解決する方法として，送信ホストが遅延確認応答の処理を完全に制御する方法を提案した．また，TCPの遅延確認応答やピギーバック機構，PUSH機構に悪影響を与えることがないよう，TCPの転送モデルを考慮して，デッドロックを解消するように設計した．実装・実験によって，本論文の提案する解決策は，トラヒックの増加なしに，デッドロック問題を解決できることを示した．

PART V

研究の総括

第 9 章結論p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

本論文はTCPの性能改善に関する研究として，性能評価，実装検査，そして，TCP短期デッドロック問題について議論した．インターネットではトラヒックの大部分が TCP

で転送されている．このため，インターネットの利便性を高めるためには，TCPの性能改善が非常に重要なこととなっている．さらに，次世代のインターネット環境をより素晴らしいものにするために，次世代 TCP(TCPng: TCP Next Generation)を目指した研究活動をすることが強く求められている．インターネットで利用されている TCPは，シミュレーションの結果作られたものでは

なく，実装と運用を通して得られた経験に基づいて作られたプロトコルである．このため，現在のTCPからより多くの経験を積むことは非常に重要なことである．現在のTCPの経験を生かさないならば，次世代 TCPは実用的なプロトコルにはなり得ないであろう．これは，実践と経験によるプロトコル開発を行わなかったOSIに比べ，実践と経験を重視したインターネットのTCP/IPの方が遙かに広く普及したという歴史的事実からも類推できることである．そこで本研究では，TCPの実装に焦点をあて，TCPの性能改善に関する研究を行った．

以下に，本研究によって得られた成果と，今後の計画，残された課題を示す．

9.1 本研究の成果以下に，本研究の成果をまとめる．

9.1.1 TCPデータ転送モデルの明確化

今まで，TCPはバルク・データ転送とインタラクティブ・データ転送に対応しているということはいわれてきたが，データ転送をモデル化し TCPの挙動を明らかにする研究は行われていなかった．このため，TCPにはトラヒックやプロトコル処理を軽減させる仕組みが備えられているにもかかわらず，これらの機能が働くなるような実装が存在している．本論文では，バルク・データ転送，インタラクティブ・データ転送，即時性を必要とするデータ転送という 3つのデータ転送モデルで，TCPがトラヒックとプロトコル処理を軽減させる仕組みをもっていることを明確に示した．データ転送モデルに対する TCP

171

172 第 9章結論

の挙動を明確化したことにより，TCPの機能に変更や拡張を加えたときのトラヒック量に関する評価が可能になった．

9.1.2 TCP実装検査ツールの提案

本研究では，IPに経路MTU探索機構が加えられたことにより，不具合が含まれている実装がいくつか出荷されており，実際にインターネットで利用されていることを明らかにした．これらの不具合の中には，TCPによる通信時にデータ転送能力が極端に低下するものも含まれている．これは，プロトコルの実装に関する検査が軽んじられている証拠であり，今後のインターネット環境をよりよくしていくためには，TCPの実装を検査するシステムが必要であることを明らかにした．さらに，TCPの実装を検査するシステムの第 1段階として，TCPと経路MTU探索の

実装に関する検査システムを提案した．このシステムを実装すれば，既存のネットワーク環境を利用して，さまざまな経路MTUを持つネットワーク環境をエミュレートする事ができる．また，本システムは，HTTPや FTPなどの一般的なプロトコルを利用することにより，特定のシステムではなく，インターネットに接続されている多くのシステムの実装を検査することができる．

9.1.3 TCP性能評価ツールDBSの構築

インターネットでは実装が重視され，実装と運用を通してプロトコルが改善され発展してきた．しかし近年，TCPの性能向上に関する研究はシミュレーション・ベースのものが多く，実際に有効かどうかの証明がされていないものが多い．このため，TCPを性能改善することが強く求められているにもかかわらず，TCPに新たな提案を実装する動きや性能改善に関する標準化活動があまり活発化していない．本研究では，実装ベースで TCP の性能を評価できる DBS (Distributed Benchmark

System)の構築を行った．今まで，複数のホスト間で同時にデータ転送を行い，その挙動を調査する方法はシミュレーションしなかく，多くの研究がシミュレーション・ベースで行われる原因となっていた．本研究で提案・実装したDBSでは，TCPの実装と実際のネットワークを利用して，複数のホスト間で同時に複数のデータ転送を行い，その挙動を詳細に調査することができる．この DBSにより，シュミレーション・ベースの研究だけではなく，実装をベースにした研究活動が活発になり，インターネットをよりよい環境へ発展させるための研究活動が増加することが期待される．このDBSをフリーウェアとして配布している．現在，世界各国の研究者やネットワー

ク管理者によって，ネットワークの性能評価や TCPの性能評価に利用されている．また現在，TCPの評価ツールとしてDBSがインターネット・ドラフト [76]で紹介されている．

9.2 今後の予定と課題 173

このインターネット・ドラフトは将来情報提供のための RFC (Informational RFC)になる見込みである．今後も，DBSは長期間にわたって，インターネットの発展のために多くの人々に利用される予定である．

9.1.4 TCP短期デッドロック問題の解決

性能改善を目的としてTCPに加えられた機能により，TCPには短期的なデッドロックが発生するという問題が生じるようになった．この TCP短期デッドロック問題にはいくつかの原因がある．しかし，今までは，それぞれの問題が個別に扱われたり，特定の実装の問題として取り扱われてきた．このため，特定の原因に対する解決策が示されるだけであったり，特定の実装のみに有効な解決策が提案されるだけであった．また，提案の中には TCPのデータ転送モデルを考慮していない提案もあり，トラヒックを増加させたり処理の負荷を増加させるなど，TCPを改悪しているものまで存在している．本研究では，TCP短期デッドロック問題を特定の実装ではなく，一般的なTCPの実装

で発生する問題として取り扱った．そして，現在起こりうるすべてのTCP短期デッドロック問題を統一的に取り扱い，すべての問題を一辺に解決できる方法を提案した．さらに，解決案の実装と評価実験により，本提案により TCP短期デッドロック問題が解決することを証明した．

9.2 今後の予定と課題以下に，今後の予定と課題について論じる．

9.2.1 実装をベースとしたTCPの性能評価

本研究では，TCP 性能評価システム DBS (Distributed Benchmark System) を構築した．今後は，この DBSを利用して，TCP Vegas[40]，選択確認応答 (SACK: Selective

Acknowledgment)[37]，FACK(Forward Acknowledgement)[38]に関して，実装をベースとした評価を行う予定である．

9.2.2 TCP実装検査システムの実装

本研究では，経路MTU探索時のTCPの挙動を検査するシステムを提案した．今後は，検査システムを実装し，様々な実装の検査を行う．インターネットに接続されているWWW

サーバや，匿名FTPサーバの実装の検査を行うことで，インターネットでサービスの提供に利用されている実装の大部分を検査することができる．この検査結果を基に，実装に関する指標の作成や，実装者に不具合箇所の指摘を行うことで，インターネット環境をより

174 第 9章結論

便利で使いやすいもにするための活動を行う．また，経路MTU探索だけではなく，TCP

の機能のすべてを検査するシステムを構築し，TCPの実装検査機関として活動する計画である．

9.2.3 TCP短期デッドロック問題の解決の標準化

TCP短期デッドロック問題は，現在のTCPに残された明確で重大な問題である．本研究では，その解決策を提案し実装・評価して有効性を証明した．この問題は，次世代 IPである IPv6でも発生する問題であり，未来のインターネットを便利で使いやすいものにするためには，解決しなければならない大きな問題である．今後は，この提案がインターネットのプロトコルの標準になるように，IETFで議論を行い標準化活動をする計画である．

9.2.4 TCP短期デッドロック問題の実装検査システムの構築

TCP短期デッドロック問題の解決策の実装を検査するための実装検査システムも作成する予定である．本研究の提案がインターネットの標準となったとき，個々の実装が正しく実装されているかどうかを検査するためである．正しく実装されていなければデッドロック問題に対する効果がないだけではなく，別の問題を発生させる危険性がある．このような問題の発生を避けるため，TCP実装検査システムに，TCP短期デッドロック問題の解決策に関する実装の検査を組み込む予定である．

9.2.5 次世代TCPの提案

ここで述べたこれらの研究の成果をふまえて，次世代のインターネット環境をより素晴らしいものにするために，次世代 TCP(TCPng: TCP Next Generation)の提案と実装を行う．そして，本研究で提案したDBSで評価を行う予定である．

謝辞p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

本研究を行う機会を与えてくださり，御指導くださった，奈良先端科学技術大学院大学情報科学研究科の尾家祐二教授，高橋豊教授，福田晃教授，山口英助教授に感謝いたします．また，本研究に関する議論やアドバイス，実験設備の提供，その他，研究を遂行するう

えで必要な作業などをいろいろと御支援くださった，奈良先端科学技術大学院大学の山本平一副学長，情報科学研究科情報ネットワーク講座の馬場始三助手，岡山聖彦助手，谷田奈津江さん，小林和真さん，井上博之さん，Cheng Soon Giapさん，情報科学研究科の白川貴子さん，計算機アーキテクチャ講座の山本和彦助手，ATRの佃井敬子さん，そして，大阪大学大型計算機センター研究開発部の門林雄基助手に感謝いたします．最後に，本研究に関して議論してくださった，奈良先端科学技術大学院大学情報科学研

究科情報ネットワーク講座の卒業生を含む学生のみなさま，WIDEプロジェクトのみなさまに感謝いたします．

175

参考文献p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

[1] D. E. Comer著,村井純,楠本博之訳, “第3版 TCP/IPによるネットワーク構築 Vol.I”,

共立出版, 1996.

[2] C. Partridge, “Gigabit Networking”, Addison-Wesley Publishing Company, 1993.

[3] IEEE, “Supplement to 802.3 (DRAFT)”, the Institute of Electrical and Electronics

Engineers, Inc, 1997.

[4] T. Berners-Lee, D. Connolly, “Hypertext Markup Language - 2.0”, November 1995.

[5] 小林揚子, “全銀手順がようやく TCP/IP対応,コスト削減と高速化で EDI拡大へ”,

日経マグロウヒル社, 日経コンピュータ, No.419, pp.18, 1997.

[6] J. Postel, “INTERNET PROTOCOL”, RFC 791, September 1981.

[7] J. Postel, “Transmission Control Protocol”, RFC 793, September 1981.

[8] W. Stallings, “Data and Computer Communications”, Fifth Edition, Prentice-Hall,

Inc., 1997.

[9] J. Postel, “User Datagram Protocol”, RFC 768, August 1980.

[10] V. Fuller, T. Li, J. Yu, K. Varadhan, “Classless Inter-Domain Routing (CIDR): an

Address Assignment and Aggregation Strategy”, RFC 1519, September 1993.

[11] K. Egevang, P. Francis, “The IP Network Address Translator (NAT)”, RFC 1631,

May 1994.

[12] S. Deering, R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC

1883, December 1995.

[13] WIDEプロジェクト, “WIDEプロジェクト 1996年度研究報告書”, WIDEプロジェクト, 1997.

[14] R. Carlson, D. Ficarella, “Six Virtual Inches to the Left: The Problem with IPng”,

RFC 1705, October 1994.

177

178 参考文献

[15] B. Braden, “TCPng: An Insurmountable Opportunity?”, TCPng BOF, San Jose

IETF, 1994.

URL “http://www.ietf.cnri.reston.va.us/proceedings/94dec/tsv/tcpng.html”

[16] V. Jacobson, R. Braden, D. Borman, “TCP Extensions for High Performance”,

RFC 1323, May 1992.

[17] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, “TCP Selective Acknowledgment

Options”, RFC 2018, Oct 1996.

[18] J. Nagle, “Congestion Control in IP/TCP Internetworks”, RFC 896, January 1984.

[19] D. D. Clark, “Window and Acknowledgment Strategy in TCP”, RFC 813, July

1982.

[20] W. Stevens, “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast

Recovery Algorithms”, RFC 2001, January 1997.

[21] R. Braden, “Requirements for Internet Hosts — Communication Layers”, RFC

1122, 1989.

[22] 多田卓夫, “Studies on Route Management – Design Implementation of a Network

Management System for the Large Scale Internet”, 修士学位論文, 奈良先端科学技術大学院大学, 1997

[23] S. G. Cheng, Y. Kadobayashi, S. Yamaguchi, “Zero Internet Administration Ap-

proch: the case of DNS”, The 12th International Conference on Information Net-

working (ICOIN-12), pp.350-355, 1998.

[24] C. Huitema, “IPv6: The New Internet Protocol”, Prentice Hall PTR, 1996.

[25] D. D. Clark, “The Design Philosophy of the DARPA Internet Protocols”, ACM

SIGCOMM ’88, Vol. 18, No. 4, pp. 106-114, August 1988.

[26] J. Postel, “The TCP Maximum Segment Size and Related Topics”, RFC 879,

November 1983

[27] D. E. Comer, J. C. Lin, “TCP Buffering and Performance Over an ATM Network”,

Purdue Technical Report, CSD-TR 94-26, 1994.

[28] K. Moldeklev, P. Gunningberg, “How a Large ATM MTU Causes Deadlocks in TCP

Data Transfers”, IEEE/ACM Transactions on Networking, Vol.3, No.4, pp.409-422,

1995.

参考文献 179

[29] T. Luckenbach, R. Ruppelt, F. Schulz, “Performance Experiments within Local

ATM Networks”, GMD-FOKUS (Berlin, D).

[30] S. J. Leffler, M. K. McKusick, M. J. Karels, J. S. Quarterman, “The Design and Im-

plementation of the 4.3BSD UNIX Operating System”, Addison-Wesley Publishing

Company, inc., 1989

[31] 殿芝義貴, “ATM網におけるマルチメディア構成手法の提案”, 修士学位論文, 奈良先端科学技術大学院大学情報科学研究科, 1995.

[32] J. Crowcroft, I. Wakeman, Z. Wang, D. Sirovica, “Is Layering Harmful?”, IEEE

Network Magazine, vol.6, pp 20-24, January 1992.

[33] 長谷川輝之,長谷川亨,加藤聰彦,鈴木健二, “広域ATM網を介したLAN間接続のためのTCPゲートウェイの実装と性能評価”, 電子情報通信学会論文誌, B-I, Vol.J79-B-I,

No.5, pp.262-270, 1996.

[34] V. Jacobson, “Congestion Avoidance and Control”, ACM SIGCOMM ’88, pp. 314-

329, 1988. URL “ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z”

[35] P. Karn, C. Partridge, “Improving Round-Trip Time Estimates in Reliable Trans-

port Protocols”, ACM SIGCOMM ’87, Vol 17, No. 5, October 1987.

[36] W. E. Leland, M. S. Taqqu, W. Willinger, D. V. Wilson, “On the Self-Similar

Nature of Ethernet Traffic”, ACM SIGCOMM ’93, September 1993.

[37] K. Fall, S. Floyd, “Simulation-based Comparisons of Tahoe, Reno, and SACK

TCP”, Computer Communications Review, July 1996.

[38] M. Mathis, J. Mahdavi, ”Forward Acknowledgement: Refining TCP Congestion

Control”, ACM SIGCOMM 96, August 1996.

[39] W. R. Stevens, “TCP/IP Illustrated, Volume1 The Protocols”, Addison-Wesley

Publishing Company, 1994.

[40] L. S. Brakmo, S. W. O’Malley, L. L. Peterson, “TCP Vegas: New Techniques for

Congestion Detection and Avoidance”, National Science Foundation Grant IRI-

9015407 and ARPA Contract, DABT63-91-C-0030 , Febrary 16, 1994.

[41] 濱田浩司, 堀良彰, 尾家裕二 “ATMネットワーク上のTCPに対するセル送出レートの影響について”,電子情報通信学会,情報ネットワーク研究会,信学技報, Vol.95, No.91,

pp.15-22, 1996.

180 参考文献

[42] S. Floyd, K. Fall, “Router Mechanisms to Support End-to-

End Congestion Control”, Technical report, February 1997. URL

“"ftp://ftp.ee.lbl.gov/papers/collapse.ps"”

[43] S. Floyd, V. Jacobson, “Random Early Detection Gateways for Congestion Avoid-

ance”, IEEE/ACM Transactions on Networking, pp. 397-413, August 1993.

URL “ftp://ftp.ee.lbl.gov/papers/early.pdf”

[44] K. Washburn, J. Evans著, 油井尊訳, “TCP/IPバイブル”, ソフトバンク (株), 1994.

[45] Microsoft Corporation, 株式会社アスキー・ネットワーク・テクノロジー監修, “Mi-

crosoft Windows NT Workstation 4.0 リソースキット”, 株式会社アスキー, 1997.

[46] J. Postel, J. K. Reynolds. “File Transfer Protocol”, RFC 959, 1985.

[47] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, “Hypertext Transfer

Protocol – HTTP/1.1”, RFC 1945, January 1997.

[48] J. Postel, “Simple Mail Transfer Protocol”, RFC 821, 1982.

[49] B. Kantor, P. Lapsley, “Network News Transfer Protocol”, RFC 977, 1986.

[50] J. Myers, M. Rose, “Post Office Protocol - Version 3”, RFC 1939 May 1996.

[51] J. Postel, J. K. Reynolds, “Telnet Protocol specification”, RFC 854, 1983.

[52] R. W. Scheifler, “X Window System Protocol, version 11”, RFC 1013, Jun 1987.

[53] D. M. Piscitello, A. L. Chapin著, 門林理恵子, 塚本昌彦訳, “オープンシステムネットワーキング”, ソフトバンク株式会社, 1995.

[54] J. Mogul, S. Deering, “Path MTU Discovery”, RFC1191, 1990.

[55] 長谷川祐作, “経路MTUの効率の良い探索方法に関する研究について”, 修士学位論文, 奈良先端科学技術大学院大学, 1997.

[56] D. E. Comer, J. C. Lin, “Probing TCP Implementations”, USENIX Summer 1994

Conference, 1994.

[57] 村山公保, 門林雄基, 山口英, “TCPデッドロック問題の解決策の提案”, 情報処理学会,

マルチメディア通信と分散処理研究会, 情処技報 Vol. 97, No. 35, pp.135-140, 1997.

[58] S. McCanne, S. Floyd. “ns-LBNL Network Simulator”,

URL “http://www-nrg.ee.lbl.gov/ns/”

参考文献 181

[59] S. Keshav, “REAL: A Network Simulator”, Computer Science Department Techni-

cal Report, University of California, December 1988.

[60] 村山公保, 門林雄基, 山口英, 山本平一, “多点間接続での TCP 性能評価システム DBS の提案”, 情報処理学会, マルチメディア通信と分散処理研究会, 情処技報 Vol. 95, No. 61, pp.139-144, 1995. URL

“http://shika.aist-nara.ac.jp/member/yukio-m/papers”

[61] 村山公保, 門林雄基, 山口英, “TCP 性能評価システム DBS の構築”, インターネットコンファレンス’ 96, 日本ソフトウェア科学会, 研究会資料シリーズ No.3, pp.39-44,

1996.

URL “http://shika.aist-nara.ac.jp/member/yukio-m/papers”

[62] Y. Murayama, S. Yamaguchi, “DBS: a powerful tool for TCP

performance evaluation”, Conference on Performance and Control

of Network Systems, SPIE Volume 3231, pp.570-581, 1997. URL


[63] 村山公保, 門林雄基, 山口英, “TCP 性能評価システム DBS の構築”, 日本ソフトウェア科学会, コンピュータソフトウェア, Vol.15, No.2, 1998.

[64] Hewlett-Packard Company, “Netperf: A Network Performance Benchmark Revision

2.1”, Hewlett-Packard Company, 1995.

[65] R. Jonkman, “Net Spec: A Network Performance

Evaluation and Experimentation Tool”, 1995. URL

“http://www.tisl.ukans.edu/Projects/AAI/products/netspec/”

[66] D. Mills, “Network Time Protocol version 2 specification and implementation”,

RFC 1119, 1989.

[67] G. R. Wright, W. R. Stevens, “TCP/IP Illustrated, Volume1 The Implementation”,

Addison-Wesley Publishing Company, 1995.

[68] B. W. Kernighan, D. M. Ritchie, 石田晴久訳, “プログラミング言語C第 2版”, 共立出版社, 1989.

[69] L. Wall, R. L. Schwartz,“Programming perl”, O’Reilly & Associates, Inc., January

1991.

[70] Thomas Williams, Colin Kelley, “GNUPLOT: An Interactive Plotting Program”,

1993.

182 参考文献

[71] 籠浩明, 若原俊彦, 由比藤光宏, 村岡洋一, “ATM上に構築したインターネットにおける高速通信に関する課題について”, 情報処理学会, マルチメディア通信と分散処理研究会, 情処技報 Vol. 96, No. 20, pp.115-120, 1996.

[72] Y. Murayama, S. Yamaguchi, “A Proposal for a Solution of the

TCP short-term Deadlock Problem”, The 12th International Confer-

ence on Information Networking (ICOIN-12), pp.269-274, 1998. URL


[73] 村山公保, 山口英, “TCP 短期デッドロック問題の解決”, 情報処理学会論文誌, 第 39

巻, 第 2号, pp.239-252, 1998.

[74] 村山公保, 門林雄基, 山口英, “PUSH ビットの有効利用による TCP デッドロック問題の解決”, 情報処理学会, マルチメディア通信と分散処理ワークショップ, 情処ワークショップ論文集 Vo.96, No.1, pp.229-236, 1996.

URL “http://shika.aist-nara.ac.jp/member/yukio-m/papers”

[75] V. Jacobson, “Compressing TCP/IP Headers for Low-Speed Serial Links”,

RFC1144, 1990.

[76] S. Parker, C. Schmechel, “Some Testing Tools for TCP Implementors”, Internet-

Draft, draft-ietf-tcpimpl-tools-01.txt,1997.

URL“ftp://ds.internic.net/internet-drafts/draft-ietf-tcpimpl-tools-01.txt”

研究業績p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p pp p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p

1. 発表論文1.1 学術論文誌

1. 村山公保，門林雄基，山口英，“TCP 性能評価システム DBS の構築”，日本ソフトウェア科学会，コンピュータソフトウェア，Vol.15，No.2，1998．

2. 村山公保，山口英，“TCP 短期デッドロック問題の解決”，情報処理学会論文誌，第39巻，第 2号，pp.239-252，1998．

1.2 国際会議 (査読つき)

3. Yukio Murayama, Suguru Yamaguchi, “DBS: a powerful tool for TCP perfor-

mance evaluation”, Conference on Performance and Control of Network Systems,

Proceedings of SPIE Volume 3231, pp.570-581, 1997.

4. Yukio Murayama, Suguru Yamaguchi, “A Proposal for a Solution of the TCP

short-term Deadlock Problem”, Proceedings of The 12th International Conference

on Information Networking (ICOIN-12), pp.269-274, 1998.

1.3 国内会議 (査読つき)

5. 村山公保，門林雄基，山口英，“TCP 性能評価システム DBS の構築”，インターネットコンファレンス’ 96，日本ソフトウェア科学会，研究会資料シリーズ，No.3，pp.39-44，1996．

1.4 研究会等 (査読つき)

6. 村山公保，門林雄基，山口英，“PUSH ビットの有効利用による TCP デッドロック問題の解決”，情報処理学会，マルチメディア通信と分散処理ワークショップ，情処ワークショップ論文集 Vo.96，No.1，pp.229-236，1996．

183

184 研究業績

1.5 研究会等 (査読なし)

7. 村山公保，山口英，“TCP デッドロック問題の解決策の提案”，情報処理学会，マルチメディア通信と分散処理研究会，情処技報 Vol. 97，No. 35，pp.135-140，1997．

8. 村山公保，門林雄基，山口英，山本平一，“多点間接続での TCP 性能評価システムDBSの提案”，情報処理学会，マルチメディア通信と分散処理研究会，情処技報 Vol.

95，No. 61，pp.139-144，1995．

1.6 発表プログラム等

9. TCP 性能評価システム DBS

http://www.ai3.net/products/dbs/index.html

2 参加研究2.1 研究会等 (査読つき)

10. 藤田謙，村山公保，門林雄基，山口英，“動的 IPアドレス環境下での TCPコネクション継続方式の提案”，情報処理学会，マルチメディア通信と分散処理ワークショップ，情処ワークショップ論文集 Vo.96，No.1，pp.439-446，1996．

2.2 研究会等 (査読なし)

11. 栗山宜巳，森川直洋，村山公保，山口英，山本平一，“B-ISDN における TCP のスループットに関する評価方法の提案”，電子情報通信学会技術報告，vol.96，No.513，CQ-96-56，pp.17-23，1996．

博士論文 - 倉敷芸術科学大学yukio-m/papers/dthesis.pdfshow measurement results of the...

Documents