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 Internet. 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 implementations 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 proposed for this problem. It required turning off delayed acknowledgment mechanism of
TCP in order to eliminate short-term deadlocks. However, this will double the acknowledgments 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 unpractical. Without the process of implementation and experiments in actual network environment, 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 problem 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 modification 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 improvement
iv
目次
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
PART I
研究の背景
1
第1章
序論
3
1.1
インターネットの普及と現状 . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2
インターネットを支えるプロトコルとその問題点 . . . . . . . . . . . . . .
6
1.3
本論文で取り扱う題目 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4
1.3.1
TCP のデータ転送モデルと実装モデル . . . . . . . . . . . . . . . . 10
1.3.2
TCP の実装検査と性能評価 . . . . . . . . . . . . . . . . . . . . . . 11
1.3.3
TCP 短期デッドロック問題 . . . . . . . . . . . . . . . . . . . . . . 12
本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
第2章
TCP の性能に関する研究と TCP の拡張
2.1
2.2
2.3
2.4
2.5
15
データ転送の効率を向上させる研究 . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1
Nagle アルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2
遅延確認応答 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.3
受信可能なウィンドウの通知
. . . . . . . . . . . . . . . . . . . . . 18
TCP の実装の問題と改善に関する研究 . . . . . . . . . . . . . . . . . . . . 18
2.2.1
データ転送の効率を向上させる仕組みの問題 . . . . . . . . . . . . . 18
2.2.2
メモリ管理機構，コンピュータ・アーキテクチャの問題 . . . . . . . 20
2.2.3
ネットワーク・モジュールの階層化の問題 . . . . . . . . . . . . . . 24
高速ネットワークへの適用 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1
ウィンドウ・サイズの制限の問題 . . . . . . . . . . . . . . . . . . . 26
2.3.2
TCP ゲートウェイによる解決 . . . . . . . . . . . . . . . . . . . . . 28
輻輳制御・再送制御
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.1
スロー・スタート . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.2
再送タイムアウトの見積もり
2.4.3
選択確認応答 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.4
再送アルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.5
ルータによる制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
. . . . . . . . . . . . . . . . . . . . . 30
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
v
vi 目 次
PART II
TCP のデータ転送モデルと実装モデル
第3章
TCP のデータ転送モデル
37
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
即時性を必要とするインタラクティブ・データ転送モデル
3.6
データ転送モデルとセッション層 . . . . . . . . . . . . . . . . . . . . . . . 46
3.7
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
第4章
TCP の実装モデルとその問題
. . . . . . . . . 45
49
4.1
TCP の実装モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2
TCP の上位層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1
4.3
4.4
セッション層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
TCP の下位層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.1
経路 MTU 探索 (Path MTU Discovery) . . . . . . . . . . . . . . . . 56
4.3.2
経路 MTU 探索の実装の問題
4.3.3
経路 MTU 探索の実験のまとめ . . . . . . . . . . . . . . . . . . . . 68
. . . . . . . . . . . . . . . . . . . . . 57
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
PART III
TCP の実装検査と性能評価
第5章
TCP の実装と性能の評価
71
73
5.1
インターネットにおける実装の意味 . . . . . . . . . . . . . . . . . . . . . . 73
5.2
実装評価と性能評価の必要性 . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3
TCP の実装検査に関する考察 . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4
5.5
5.3.1
経路 MTU 探索による TCP の動作の検査システムの提案 . . . . . . 75
5.3.2
TCP 実装検査ツールに求められる機能 . . . . . . . . . . . . . . . . 78
TCP の性能評価に関する考察 . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.4.1
TCP 性能測定ツールに求められる機能 . . . . . . . . . . . . . . . . 79
5.4.2
既存の性能測定ツールとその問題点 . . . . . . . . . . . . . . . . . . 80
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
目次
第6章
TCP の性能評価システムの提案・実装・評価
6.1
6.2
6.3
vii
83
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
DBS の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2.1
機能面の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2.2
測定結果の妥当性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
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 短期デッドロック問題の解決
第7章
TCP 短期デッドロック問題と既存の解決案
7.1
121
123
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 デッドロック問題の解決策の提案・実装・評価
8.1
133
デッドロック問題の解決策の提案 . . . . . . . . . . . . . . . . . . . . . . . 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 データ転送モデル
8.3
実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
8.4
検証実験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
8.5
実験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
8.6
8.7
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
考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.6.1
実験結果への他のトラヒックの影響 . . . . . . . . . . . . . . . . . . 163
8.6.2
他のトラヒックがある環境での本提案の効果 . . . . . . . . . . . . . 163
8.6.3
TCP デッドロック問題の解決の重要性 . . . . . . . . . . . . . . . . 165
8.6.4
デッドロック問題の解決に関する考察
8.6.5
インターネットへの適用について . . . . . . . . . . . . . . . . . . . 166
8.6.6
実装に関する考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
第9章
結論
9.2
謝辞
. . . . . . . . . . . . . . . . 166
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
PART V
9.1
. . . . . . . . . . . . . . . . . . . . . . . 137
研究の総括
169
171
本研究の成果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
9.1.1
TCP データ転送モデルの明確化 . . . . . . . . . . . . . . . . . . . . 171
9.1.2
TCP 実装検査ツールの提案 . . . . . . . . . . . . . . . . . . . . . . 172
9.1.3
TCP 性能評価ツール DBS の構築 . . . . . . . . . . . . . . . . . . . 172
9.1.4
TCP 短期デッドロック問題の解決 . . . . . . . . . . . . . . . . . . 173
今後の予定と課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
図目次
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
1.1
TCP/IP と OSI のプロトコル階層の比較 . . . . . . . . . . . . . . . . . . .
7
1.2
TCP/IP の機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1
シリー・ウィンドウ・シンドローム . . . . . . . . . . . . . . . . . . . . . . 16
2.2
Comer らの実験の測定環境
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
. . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.10 TCP の自己同期 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.11 通常の確認応答と選択確認応答の違い . . . . . . . . . . . . . . . . . . . . . 31
3.1
TCP のデータ転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2
バルク・データ転送
3.3
インタラクティブ・データ転送 . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4
遅延確認応答の果たす役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5
即時性を必要とするインタラクティブ・データ転送 . . . . . . . . . . . . . 45
4.1
OSI 参照モデルと TCP/IP 階層モデル . . . . . . . . . . . . . . . . . . . . 50
4.2
フラグメント処理をする場合 (上) と経路 MTU 探索をする場合 (下) の TCP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
データセグメントの流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
ウィンドウ・サイズの拡張オプションの評価 (スループットの変化)
6.9
ウィンドウ・サイズの拡張オプションの評価 (輻輳ウィンドウの変化．バッ
. . . . 95
ファ・サイズが 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 のヘッダ
8.2
バルク・データ転送
8.3
インタラクティブ・データ転送 . . . . . . . . . . . . . . . . . . . . . . . . 138
8.4
即時性を必要とするインタラクティブ・データ転送 . . . . . . . . . . . . . 139
8.5
ソケットと TCP のモジュール間通信の強化 . . . . . . . . . . . . . . . . . 142
8.6
実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
8.7
経路 MTU 探索の実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
8.8
実装 1: メッセージ・サイズとスループットの関係 . . . . . . . . . . . . . . 152
8.9
実装 2: メッセージ・サイズとスループットの関係 . . . . . . . . . . . . . . 152
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
8.10 実装 3: メッセージ・サイズとスループットの関係 . . . . . . . . . . . . . . 153
8.11 実装 4: メッセージ・サイズとスループットの関係 . . . . . . . . . . . . . . 153
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
表目次
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
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.3
実装 2: TCP バッファサイズとスループット・転送効率の関係 (Nagle アル
ゴリズムが有効のとき) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
8.4
実装 3: TCP バッファサイズとスループット・転送効率の関係 (Nagle アル
ゴリズムが有効のとき) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.5
実装 4: TCP バッファサイズとスループット・転送効率の関係 (Nagle アル
ゴリズムが有効のとき) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.6
実装 1: TCP バッファサイズとスループット・転送効率の関係 (Nagle アル
ゴリズムが無効のとき) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
8.7
実装 2: TCP バッファサイズとスループット・転送効率の関係 (Nagle アル
ゴリズムが無効のとき) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
8.8
実装 3: TCP バッファサイズとスループット・転送効率の関係 (Nagle アル
ゴリズムが無効のとき) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
xv
xvi 表 目 次
8.9
実装 4: TCP バッファサイズとスループット・転送効率の関係 (Nagle アル
ゴリズムが無効のとき) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
8.10 本提案の実装プログラムの規模 . . . . . . . . . . . . . . . . . . . . . . . . 168
PART I
研究の背景
第 1 章 序論
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
この章では本論文の位置づけと意義を明らかにする．まず，近年の社会の流れとイン
ターネットの関係について論じ，本論文の主題である TCP プロトコルの役割や位置づけ
について論じる．次に，本論文で取り扱う題目について説明する．最後に，本論文の構成
を述べる．
1.1
インターネットの普及と現状
現在の社会は情報化社会と呼ばれている．大量の情報がコンピュータに入力され，コン
ピュータの外部記憶装置にデジタル情報として記録・蓄積される．記録・蓄積された情報
は，人々の要求に応じて，検索されたり，加工されたり，表示されるなど様々な処理が行
われる．
もともとコンピュータは数値計算をするために誕生した．その後，数値計算だけではな
く，様々な情報を処理する処理装置としてコンピュータは進化した．太古の昔から，情報
は紙などに文字や絵として記録・管理されてきた．フィルムやレコード，磁気テープなど
の記録媒体が発明されてからは，これらの記録媒体にも情報が記録されるようになった．
そして現代の社会では，多くの情報がデジタル化・電子化され，コンピュータで処理でき
る形式で記録されることが多くなった．情報をデジタル化して記録すると，複製したり長
期間保存しても情報の品質が劣化しないという特長を持つ．また，コンピュータで加工や
検索などの処理が簡単に行えるという利点もある．現代の社会では，コンピュータで処理
しやすくするために，情報をデジタル化して記録することが増えてきている．
情報がコンピュータに大量に入力されるようになると，今度は蓄積だけではなく，入力
した情報を遠く離れた場所に輸送することが求められるようになった．遠隔地間で情報の
収集や交換をしたり，情報を発信したり，コミュニケーションの手段として情報のやり取
りをしたいという要求が発生したのである．このような情報に対する社会的な要求の影響
を受け，通信技術とコンピュータ技術は融合し，コンピュータ・ネットワークが誕生した．
コンピュータ・ネットワークの登場により，たとえ遠距離間であったとしても，大量の
デジタル情報を短時間で転送したり流通させたりすることが可能になった．コンピュータ
のハードウェアやソフトウェア，ネットワーク機器や通信網の発達により，文字や，音声，
画像，動画，そして，アプリケーション・プログラムなど，様々なデータが国境を越えて
高速に転送できるようになった．このコンピュータ・ネットワークの登場により，世の中
3
第 1章
4
序論
の情報はますますデジタル化され，コンピュータに入力・蓄積されるようになった．そし
て，コンピュータ・ネットワークの普及により，情報の多様化，複雑化，巨大化，広域化，
即時化，短寿命化が進んだ．情報に対する広域化，即時化，短寿命化によって，大量の情
報をコンピュータとコンピュータの間で高速に移動させることが求められるようになった．
このように，コンピュータ・ネットワークは，情報化社会に大きな影響を与えるように
なった．さらにコンピュータは，ネットワークによって他のコンピュータと接続できなけ
れば，その能力を十分に発揮することができないようになった．それだけ，コンピュータ・
ネットワークは，コンピュータの能力や可能性を大きく広げる環境なのである．このよう
な環境を提供してくれるコンピュータ・ネットワークは，高度情報化社会を支え，発展さ
せるためのもっとも重要な基盤環境の 1 つに考えられるようになった．
コンピュータ・ネットワークの中でも，特にインターネットに対する社会的な感心は非
常に大きなものとなった．現在では，インターネットというと，世界中のネットワークや
コンピュータを接続している単一の巨大なネットワークという意味になる．しかし，その
語源は，ネットワークとネットワークを接続して，相互に通信できる環境を構築すること
である．現在のインターネットの起源となった ARPANET は，実験・研究活動を目的とし
て誕生した．それは，1970 年ごろにパケット交換による相互接続通信を実現するために，
アメリカで構築されたネットワークである [1]．しかし，1990 年ごろに，インターネット
の商用利用が認められるようになると，ISP (Internet Service Provider) と呼ばれるイン
ターネット接続業者が乱立し，インターネットに接続するユーザの数が爆発的に急増する
ようになった．研究ネットワークと商用ネットワークは IX (Internet Exchange) によって
互いに接続され，相互に自由な通信ができる環境が作られた．その結果，だれでも ISP と
契約すれば，インターネットに接続している世界中の人々とコミュニケーションをするこ
とが可能になった．商用化が進むまでは，インターネットは研究目的でありボランティア
的に運用され，発展してきた．しかし現在では，商用を目的とする企業やユーザの急増に
より，商用ネットワークとして急成長するようになった．
現在のインターネットの最大の特徴は，世界中の政府，研究機関，教育機関，非営利団
体，営利を目的とした企業や団体，そして，一般市民が自由に参加していることである．
また，接続されているコンピュータやオペレーティング・システム，アプリケーション，
利用目的も多種多様である．インターネット自体には，ネットワークの利用目的や使用す
るプロトコルに関する管理や規制をする機関や組織はなく，インターネット全体で共通と
なる規制事項はない．インターネットに接続する機器や，オペレーティング・システム，
アプリケーションに対する制限や検定などは行われておらず，接続したい機器を自由に接
続して通信や実験を行うことができる．
このインターネットでは，ほとんどすべての通信で TCP/IP プロトコル群が利用されて
いる1) ．TCP/IP は，インターネットのプロトコルに関する研究機関である IETF (Inter1)
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 などの，インターネットで通信を行うために必要な主要なプロトコル群を意味す
る．
第 1章
6
序論
発に行われている．その結果，性能や，品質，価格，メンテナンスなどが優れているもの
が多い．このように，現在では，データリンク技術も，アプリケーション・ソフトウェア
も，また，コンピュータ・システムも，インターネットによる通信を意識した製品開発が
数多く行われている．
このような社会の流れと共に，世界中を結ぶオープンなネットワークとして，インター
ネットは世界中の人々に受け入れられていった．今では，世界中の企業や組織，家庭のコ
ンピュータがインターネットに接続されるようになった．そして，現在のインターネット
は，他に比較できるものがないほど，巨大なコンピュータ・ネットワークへと成長した．
インターネットの発達により，常時，または間欠的に，世界中の多くのコンピュータがイ
ンターネットに接続されるようになった．もはや，コンピュータとネットワークは別のも
のだと切り離して考えることはできない時代になったといえる．コンピュータにはネット
ワークが必要であり，ネットワークにはコンピュータが必要なのである．
現在では，インターネットは，テレビや電話のように情報をやり取りする環境として市
民権が得られたといえる．実際にインターネットの 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章
序論
Host
Host
Router
Router
Application
Application
TCP
TCP
IP
IP
IP
IP
Interface
Interface
Interface
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
第 1章
12
序論
はソフトウェアで実現されており，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 の拡張
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
インターネットでは，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
第 2章
16
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 節を参照．
18
第 2章
TCP の性能に関する研究と TCP の拡張
処理が終わるまで，受信バッファに格納されたデータをアプリケーションに渡すための処
理ができなくなる．さらに，送信ホストからは，ウィンドウの最大サイズまでパケットが送
信されてくる可能性がある．受信バッファに格納されているデータを速やかにアプリケー
ションに渡さなければ，送信されたデータで受信バッファがすべて埋まってしまい，新た
なデータを受信できなくなり，スループットが低下することになる．このような理由で，
確認応答を遅延させない場合には，シリー・ウィンドウ・シンドロームが発生する可能性
が高くなる．発生しなかったとしても，確認応答処理のためにホストの CPU 負荷が高く
なり，スループットの低下をもたらす原因になる．
受信バッファのデータをアプリケーションに渡し受信バッファが大きくなってから確認
応答すれば，シリー・ウィンドウ・シンドロームは発生しない．これを実現する機能とし
て，遅延確認応答 (Delayed Acknowledgment) が提案された．現在では，この機能は実装
することが強く奨励されており，ほとんどすべてのシステムで実装されている．
RFC1122 では遅延時間を 0.5 秒以内にしなければならないことと，2 つのフルサイズの
セグメント (2MSS) を受信したときに遅延なく確認応答を返送しなければならないことが
決められている．遅延時間の上限が決められているのは，遅延時間を長くすると，送信し
たデータが受信ホストに到達しているにもかかわらず，送信ホストがデータを再送する危
険があるからである．この遅延確認応答は確認応答パケットの数を減らす役割も持ってい
る．その結果，ネットワークやホストの負荷を軽減する性質がある [19]．
2.1.3
受信可能なウィンドウの通知
受信可能なウィンドウの大きさが 0 になった場合にはウィンドウ・サイズを 0 と通知す
る．ただし，その後，受信可能なウィンドウが少しできてもウィンドウ・サイズの通知は
しない．確認応答を通知しなければならない場合には，ウィンドウの大きさを 0 と通知す
る．そして，受信バッファに格納されていたデータがアプリケーションに渡され，受信バッ
ファの 25%∼50%，または，1MSS∼2MSS 以上のデータが受信可能になった場合に，そ
のとき受信可能なウィンドウを通知する．この仕組みにより，受信ホストは送信ホストに
小さなウィンドウを通知することがなくなり，シリー・ウィンドウ・シンドロームを避け
ることができる．
2.2
2.2.1
TCP の実装の問題と改善に関する研究
データ転送の効率を向上させる仕組みの問題
Comer らの研究により，Nagle アルゴリズムや遅延確認応答の機能には，副作用がある
ことが明らかになった [27]．Comer らは，図 2.2 に示すようなに ATM スイッチに接続さ
れた 2 つのホスト間で，バッファ・サイズに着目しながらデータ転送を行い，そのときの
2.2
TCP の実装の問題と改善に関する研究
19
ATM Switch
ASX-100(Fore Systems)
100Mb/s
SBA-200
Adapter
100Mb/s
SBA-200
Adapter
Host A
Host B
SPARCstation IPC
(Sun Microsystems)
SPARCstation IPC
(Sun Microsystems)
10Mb/s Ethernet
図 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 らの用語に従い，この状態のことをデッドロックと呼ぶことに
20
第 2章
TCP の性能に関する研究と TCP の拡張
表 2.1: TCP バッファ・サイズに対する平均スループット
送
信
バ
ッ
フ
ァ
サ
イ
ズ
(octet)
16K
20K
24K
28K
32K
36K
40K
44K
48K
51K
16K
15.05
15.99
17.71
16.57
14.63
14.33
15.16
14.80
14.62
13.92
20K
13.60
14.60
16.79
17.69
18.96
19.22
19.34
19.40
19.46
19.41
受信バッファサイズ (octet)
24K
28K
32K
36K
40K
0.322 0.319 0.319 0.467 0.469
15.07 14.87 15.40 14.24 1.095
16.74 16.32 17.40 17.31 17.42
17.93 18.13 18.36 19.20 19.74
18.42 19.23 19.14 19.74 19.96
18.12 19.82 19.77 19.92 20.56
18.85 19.73 20.11 20.41 20.81
18.27 20.39 20.16 20.74 20.99
18.34 20.48 20.26 20.41 20.85
18.26 20.50 20.06 20.21 20.88
44K
0.466
1.095
17.12
19.78
20.31
20.49
20.74
20.87
20.83
20.91
48K
0.469
0.548
0.760
18.38
19.69
20.13
20.69
20.89
20.93
21.21
51K
0.469
0.549
0.740
18.20
19.17
20.20
20.57
20.70
20.83
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.2
TCP の実装の問題と改善に関する研究
21
り替え回数が多くなり，これがオーバーヘッドとなる．そのためスループットが低下する．
また，図 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)
3)
SunOS4.1.3 の場合．BSD/OS 2.0.1 の場合は 2kbyte．
この値は SunOS4.1.3 の場合である．BSD/OS2.0.1 の場合は 209byte である．OS によって値は異なる．
第 2章
22
TCP の性能に関する研究と TCP の拡張
Host1
Host2
ATM Switch
100Mbps
100Mbps
図 2.3: Luckenbach らの実験の再実験に使用した環境
表 2.2: 測定機材と設定
CPU
OS
ATM Switch
AAL Type
MTU
バッファ・サイズ
測定ツール
SPARCstation10(Sun Microsystems)
SunOS 4.1.3
ASX-100 (Fore Systems)
AAL5
9188octet
52428byte
Netperf
70
60
Throughput [Mbps]
50
40
30
20
10
0
0
1024 2048 3072 4096 5120 6144 7168 8192
Message Size [byte]
図 2.4: 送信メッセージサイズとスループットの関係
2.2
TCP の実装の問題と改善に関する研究
23
60
Throughput [Mbps]
55
50
45
40
3072
図 2.5
3184
3296
3408
Message Size [byte]
3520
送信メッセージサイズとスループットの関係 (拡大図その 1)
65
Throughput [Mbps]
60
55
50
45
4032
図 2.6
4036
4040
4044 4048 4052
Message Size [byte]
4056
4060
送信メッセージサイズとスループットの関係 (拡大図その 2)
4064
24
2.2.3
第 2章
TCP の性能に関する研究と TCP の拡張
ネットワーク・モジュールの階層化の問題
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 に格納さ
れているデータの数え方が異なっている．
ソケット
TCP
···
···
データが入っている mbuf の大きさの総量
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．
BSD/OS 2.0.1 の場合である．SunOS4.1.3 の場合は 512byte である．オペレーティング・システムに
よって値は異なる．
5)
2.2
TCP の実装の問題と改善に関する研究
Ethernet
Host1
10Mbps
Host2
図 2.7: 2 点間の Ethernet 実験環境
表 2.3: 評価に使用した機材と設定
CPU
OS
MSS
TCP バッファ・サイズ
送信時間 (Netperf)
Twinhead Subnote (486 33MHz)
BSD/OS V2.1
1448octet
8196byte
10 秒
7
Throughput(Mbit/s)
6
5
4
3
2
1
0
0
500
1000
1500
Message Size(byte)
図 2.8: 送信メッセージ・サイズとスループットの関係
2000
25
26
第 2章
TCP の性能に関する研究と TCP の拡張
は受信ホストの遅延確認応答が解除される 2MSS=2896bypte に達しない．このため，受
信ホストでは，さらなるデータが送られて来ることを期待して確認応答の送信を遅らせる
ことになる．しかし，送信ホストはデータを送ることはできない．このため，デッドロッ
ク状態になり，受信ホストの遅延確認応答の制限時間が解除されるまで確認応答は送信さ
れない．遅延確認応答の制限時間は TCP のファスト・タイマの時間の 0.2 秒程度である．
このため 0.2 秒ごとにしかデータが送信されなくなり，極端にスループットが低下するこ
とになる．
2.3
高速ネットワークへの適用
TCP は，ウィンドウ制御によって，データの送信と確認応答を並列化して行えるよう
になっている．このため，遅延がある程度大きくなっても，ネットワークの帯域を埋め尽
くすようなデータ転送が可能である．しかし，RFC793 で定義されている TCP のウィン
ドウ・サイズのフィールド長では，広帯域，高遅延ネットワークでデータ転送をしたとき
に，帯域のすべてを埋め尽くすことはできない．この問題を解決するために，TCP のウィ
ンドウを拡大するオプションが追加された．
2.3.1
ウィンドウ・サイズの制限の問題
送信ホストが一度に大量のデータを送信すると，受信ホストがすべての送信データを受
信しきれなくなる可能性がある．これは，受信ホストの処理能力が送信ホストに比べて
劣っている場合や，受信ホストの負荷が高い場合に起こりやすい．また，遠隔ログインな
どでユーザが画面の表示を一時停止した場合など，アプリケーションの受信処理がしばら
く停止する場合にも発生する可能性がある．このときに，データの送信量を調整したり，
送信の停止，再開をする仕組みがフロー制御である．
TCP のフロー制御は，受信ホストから受信可能なオクテット数を送信ホストに伝えるこ
とで実現されている．このオクテット数がウィンドウと呼ばれる．送信ホストはこのウィ
ンドウの大きさを超えるデータを送信することはできない．よって，このウィンドウの大
きさとラウンド・トリップ時間によって，TCP によるデータ転送の最大スループットが
決まる．ウィンドウの大きさを win，ラウンド・トリップ時間を RT T とすると，得られ
る最大のスループット Tmax は，
Tmax =
win
RT T
(2.1)
で求められる．
TCP のヘッダには，受信ホストから送信ホストへ受信可能なウィンドウの大きさを伝
えるフィールドがある．この大きさは 16 ビット長であるである．つまり，ウィンドウの最
2.3
高速ネットワークへの適用
27
1e+07
Window Size = 64 K octets
Window Size = 1 G octets
1e+06
Throughput (M bps)
100000
10000
1000
100
10
1
0.1
0.001
0.01
0.1
1
Round Trip Time (Second)
10
図 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]．
28
第 2章
TCP の性能に関する研究と TCP の拡張
データを誤って受信した場合にはデータの信頼性が確保されなくなる．この問題を防ぐた
めに，タイムスタンプ・オプションが定義された．このタイムスタンプ・オプションは，
すべての 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章
30
TCP の性能に関する研究と TCP の拡張
送信ホスト
送信バッファ
送信データ
受信ホスト
受信バッファ
確認応答
図 2.10: TCP の自己同期
2.4.2
再送タイムアウトの見積もり
TCP では，データセグメントの送信と，それに対する確認応答の受信で，信頼性のあ
る通信を実現している．ある時間経過しても確認応答が到着しない場合は，セグメントま
たは確認応答のパケットが喪失した可能性がある．そこで，TCP ではパケットの往復に
かかるラウンド・トリップ時間 (RTT: Round Trip Time) を計測し，再送処理をする．計
測の誤差を少なくするため，新しく求めたラウンド・トリップ時間に重みをおいた平滑化
を行う．
初期の TCP では，見積もられたラウンド・トリップ時間にある定数を掛け合わせた値
を再送タイムアウト時間 (RTO: Retransmission Time Out) と定義し，その時間経過して
も確認応答が到着しない場合にセグメントを再送していた．しかし，単純なこの仕組みに
は問題があることが分かった．他のトラヒックの影響によって，各セグメントのラウンド・
トリップ時間に大きな揺らぎが現れたのである．ネットワークの負荷が小さい場合にはこ
の揺らぎは小さいが，負荷が大きくなるとこの揺らぎも大きくなる．
また，再送したセグメントに対するラウンド・トリップ時間の見積もりには，あいまい
性があるという問題が指摘された．到着した確認応答が再送する前のセグメントに対する
ものなのか，再送後のセグメントに対するものなのか区別できないのである．これらの問
題を解決する方法が Karn らによって提案された [35]．
• 再送したセグメントに対するラウンド・トリップ時間の見積もりは行わない．
• ラウンド・トリップ時間とその分散を見積もり，それぞれを足した時間を再送タイ
ムアウト時間と定義して再送処理を行う．
これは，現在の多くの TCP の実装で採用されている方法であり，現在のインターネッ
トでもそれなりの効果が得られていると見込まれる．
また，実際にネットワークを流れるトラヒックは，正規分布やポアソン分布でモデル化
できるようなものではなく，自己相似性を持つといわれている [36]．これらを利用した再
2.4
輻輳制御・再送制御
31
送信パケットの流れ
受信したデータ
確認応答をする範囲
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章
32
2.4.4
TCP の性能に関する研究と TCP の拡張
再送アルゴリズム
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 + M SS
(2.3)
• 輻輳回避制御
ウィンドウが急激に拡大しすぎることにより輻輳状態になることを防ぐため，輻輳
ウィンドウ cwnd がスロー・スタート閾値 ssthresh を超えた場合には，1 つの確認
応答パケットを受信するたびに輻輳ウィンドウを (M SS/cwnd) MSS ずつ増加させ
る．すなわち，新しい輻輳ウィンドウ cwndnew は次の式で計算される．
cwndnew = cwnd +
M SS 2
M SS
× M SS = cwnd +
cwnd
cwnd
(2.4)
タイムアウトによりセグメントの再送をするときには，スロー・スタート閾値 ssthresh
をそのときの輻輳ウィンドウ cwnd の半分に設定する．すなわち，新しいスロー・ス
タート閾値 ssthresh は次の式で計算される．
ssthresh =
cwnd
2
(2.5)
なお，スロー・スタート閾値の初期値は，最大ウィンドウ・サイズに設定される．
2.4
輻輳制御・再送制御
33
Reno
Reno では，これらのアルゴリズムに加え，高速な再送制御を行うように次のアルゴリ
ズムが追加された．
• 高速再送制御 (Fast Retransmission)
重複確認応答 (Duplicate Acknowledgment) を 3 つ受信した場合に，その確認応答
が示しているセグメント以降を再送する．
• 高速回復制御 (Fast Recovery)
タイムアウトが発生するときに比べると，重複確認応答を受信する場合はネットワー
クが混雑していないと考えられる．よって，輻輳ウィンドウを 1MSS に設定してス
ロー・スタートを行うのではなく，もう少し大きな値にしてもよいと考えられる．高
速回復制御は，高速再送制御が行われるときには，輻輳ウィンドウ・サイズを次の
式で計算された値に更新する．その時点の輻輳ウィンドウを cwnd とすると，新し
い輻輳ウィンドウ cwndnew は次の式で表される値になる．
cwndnew =
cwnd
+ 3M SS
2
(2.6)
また，高速回復制御中に別の重複確認応答を受信した場合には，輻輳ウィンドウを
1MSS 拡大する．
Reno の高速再送制御や高速回復制御などの機能は，BSD の実装があるだけで，長い間
TCP のプロトコルの仕様にはなっていなかった．しかしそれが RFC2001 でようやく明文
化され TCP のプロトコルとして提案標準となった．
Vegas
Lawrence らによって提案された Vegas には次のような特徴がある．
• より正確なラウンド・トリップ時間を計測する．
従来の TCP の実装では，0.5 秒単位でラウンド・トリップ時間を計測していた．Vegas
ではシステム・クロックから時間を読み込むことにより，0.001 秒単位でラウンド・
トリップ時間を計測する．これにより，従来の TCP よりもラウンド・トリップ時間
の計測の制度が向上する．
• 多くのイベントで再送タイム・アウトの評価を行う
従来の TCP の実装では，0.5 秒単位で再送タイムアウトの評価が行われていた．Vegas
では，セグメントを受信した時や write システムコールが呼ばれた時など，多くの
第 2章
34
TCP の性能に関する研究と TCP の拡張
イベントで再送タイムアウトの評価を行う．これにより，従来の 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 のデータ転送モデル
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
インターネットで現在使われている 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 のデータ転送モデル
アプリケーションが
送信するデータ
1MSS
1MSS
1MSS単位に区切られる
ヘッダが付けられ
送信される
データの最後では
PUSHフラグが設定される
パケットの流れ
図 3.1: TCP のデータ転送
3.2.1
セグメント
TCP では，1 つの IP データグラムに格納されるデータは，セグメントと呼ばれる．TCP
はストリーム型の通信であり，データはすべて連続的なつながりを持っている．セグメン
トという言葉は，パケットに格納するために，連続的なデータを区切った一部分であるこ
とを意識的に表している．
TCP では，データの送信を制御するための単位として，最大セグメント長 (MSS: Maximum Segment Size) の値が決定される．多くの場合，この最大セグメント長単位で，デー
タ転送や再送の処理，輻輳制御，確認応答処理が行われる．この最大セグメント長は，理
想的には，IP フラグメントが発生しない最大の大きさである．LAN では，データを送受
信するデータリンクの最大転送単位 (MTU: Maximum Transmission Unit) から，IP や
TCP のヘッダを引いた値が利用される．つまり，データリンクの最大転送単位を M T U ，
IP ヘッダの長さを IPheader ，TCP ヘッダの長さを T CPheader ，とすると，最大セグメン
ト長 M SS は次の式で求められる．ただし，IPheader や T CPheader には，データ転送時に
利用されるオプションの長さが含まれる．
M SS = M T U − (IPheader + T CPheader )
(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 フラグの値に関係なく，すべての受信データをバッファリングせずにすぐにアプリ
42
第 3章
TCP のデータ転送モデル
HOST A
HOST B
1MSS
ACK
ACK
PUSH
ACK
図 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
インタラクティブ・データ転送モデル
HOST A
43
HOST B
PUSH
PUSH ACK
PUSH ACK
PUSH ACK
図 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 の例が示されている．こ
44
第 3章
TCP のデータ転送モデル
の 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: 遅延確認応答の果たす役割
HOST A
HOST B
PUSH
PUSH
PUSH
PUSH ACK
PUSH ACK
PUSH
PUSH
PUSH
PUSH ACK
図 3.5: 即時性を必要とするインタラクティブ・データ転送
上させるには，いかにして確認応答をピギーバックさせ，ネットワークやホストの負荷を
低減させるかが重要な鍵となる．
3.5
即時性を必要とするインタラクティブ・データ転送モデル
X11[52] などのウィンドウ・システムや機械制御など，即時性が求められるインタラク
ティブ・データ転送では，図 3.5 に示すようなデータ転送が行われる．このモデルは，TCP
の Nagle アルゴリズムを無効にすることで実現される．図の場合，HOST A ではクライ
46
第 3章
TCP のデータ転送モデル
アント・プログラムが動作し，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 サーバが動作しており，HOST
B では X クライアントが動作していると考える．
3.7
まとめ
47
即時性を必要とするデータ転送の場合は，本来ならばデータ転送モードが変更される度
に，Nagle アルゴリズムを有効にしたり無効にしたり変更する必要がある．しかし，現実
にはそのようなことは行われていない．これも，セッション層が軽んじられてきたからだ
といえる．今後は，TCP を利用するアプリケーション・プログラムの開発時には，本論文
で示したデータ転送モデルをもとに，セッション層についてきちんと考える必要がある．
3.7
まとめ
この章では，アプリケーションのデータ転送を 3 つのモデルに分類し，それらのデータ
転送時の TCP の振る舞いについて分析した．そして，TCP の PUSH 機構と遅延確認応答
は，3 つのデータ転送モデルのすべてで，ネットワークやホストの負荷を低減する役割を
果たしていることを示した．TCP の改善や，TCP のセッション層を作成する際には，こ
のデータ転送モデルと PUSH 機構や遅延確認応答の関係を理解する必要がある．そうし
なければ，トラヒックの増加や，ホストの負荷の増加につながる．そのため，この章で述
べたデータ転送モデルと，TCP の機構は，TCP の改善や TCP のセッション層を作成す
る際の，指標となる考え方だといえる．
第 4 章 TCP の実装モデルとその問題
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
ネットワーク・プロトコルは階層化されている．そのため，すべての機能を 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
第 4章
50
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 やネットワーク・ニュースなど
でも利用されており，インターネットの標準的なプレゼンテーション層として，様々なア
プリケーションで利用されている．
52
第 4章
TCP の実装モデルとその問題
しかし，セッション層に関しては，いまだにそのような標準は存在せず，提案も行われ
ていない．唯一，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 の下位層
で，セグメントの喪失や順序の入れ替わり，重複が発生することを想定した設計がされて
いる．それぞれ，次のように実装することでこれらの性質に対応できるようになっている．
54
第 4章
TCP の実装モデルとその問題
• セグメントの喪失
セグメントが喪失したと判断されるときにはそのセグメントを再送する．
• 順序の入れ替わり
到着したセグメントのシーケンス番号が受信可能なウィンドウ内であれば，受信し
たデータ破棄しないでバッファに格納する．
• 重複
先に到着したセグメントを優先し，後から到着したセグメントは破棄する．
下位層が輻輳制御や再送制御，誤り制御などをして，ネットワークの利用効率を向上さ
せようとしたとしても，その結果，確認応答が到着する時間が TCP の再送タイムアウト
の時間を超えると，逆にネットワークの利用効率は悪くなる．このため，TCP の場合に
は下位層がきめ細かな制御をすると逆に問題となる可能性がある．このことは，TCP の
再送アルゴリズムにより，下位層に許される処理時間や，処理時間の揺らぎの限界を規定
しているといえる．つまり，輻輳状態になった場合，ルータ内でのセグメントの滞在時間
が長くなるが，この時間が TCP の再送タイムアウトの時間を超えるほど長くなる場合に
は，パケットをすみやかに廃棄してネットワークの混雑を緩和するように処理をした方が
よい．つまり，ルータが極端に巨大なバッファを持っていても，TCP による性能が向上す
るとは限らないのである．
4. は TCP の輻輳制御である．TCP の仕様では，一定時間たっても確認応答されないと
いうタイムアウトが発生した場合には，セグメントが輻輳によって喪失したと判断し，再
送処理をするとともにスロー・スタート制御をしなければならない [21]．現在のほとんど
すべての TCP の実装では，確認応答のタイムアウトは輻輳が原因でセグメントが喪失し
たと決めつけ，スロー・スタートする．これは，ビット誤りによるセグメントの喪失時に
もスロー・スタートすることを意味する．現在のネットワークは，品質が向上しビット誤
り率は低下する傾向にある．しかし，近年，性能の向上と普及が急速に進んでいる無線通
信の場合には，ビット誤りが発生する可能性が高い．また，有線による通信と比べると，
無線による通信はビット誤り率を低下させる工夫にも限界があると考えられる．こう考え
ると，今後，インターネットで無線ネットワークが広く使われるようになると，TCP の
輻輳制御は必ずしも正しく機能するとは限らない．
TCP にはチェックサムによりデータの信頼性を確保する仕組みが備えられている．そ
して，受信ホストでチェックサムの計算が合わない場合には，ICMP エラーメッセージで，
送信ホストにチェックサムエラーが発生したことを通知する．この ICMP エラーメッセー
ジは，セグメントが喪失したのは輻輳が原因ではないことを意味している．この ICMP エ
ラーメッセージを送信ホストが受け取ったときには，スロー・スタートせずにエラーのセ
4.3
TCP の下位層
55
Host
Host
Router
MTUが大きなネットワーク
MTUが小さなネットワーク
1MTU
1MTU
分割される
再構成される
分割される
再構成される
Host
Host
Router
MTUが大きなネットワーク
MTUが小さなネットワーク
1MTU
1MTU
全ての送信パケットに
分割禁止フラグをセット
X パケットは捨てられ，
ICMP Unreachableメッセージが返される。
同時に，次のデータリンクのMTUが伝えられる。
通知されたMTUを基に送信
そのまま転送される
図 4.2
フラグメント処理をする場合 (上) と経路 MTU 探索をする場合
(下) の TCP データセグメントの流れ
グメントを再送するように実装することは可能である．しかし，これでもデータリンクの
ビット誤りには対応できない．
データリンクの誤りの場合には，データリンクの FCS のチェックでフレームが廃棄され
るため，TCP 層にはデータが喪失されたことは伝えられないからである．そのため，TCP
がビット誤りでデータが喪失したのか，輻輳でデータが喪失したのかを知る手段はない．
TCP のチェックサムは，データリンクのビット誤りの検査というよりは，ルータなどのソ
フトウェアのバグによって，データが書き換えられたことを検出するのが目的になってい
ると考えられる．
56
4.3.1
第 4章
TCP の実装モデルとその問題
経路 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 のルー
4.3
TCP の下位層
57
タは，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 秒間はデータが間欠的にしか送信
されておらず，スループットが極端に小さいことがわかる．この原因は次のように考える
と説明できる．コネクション確立時には，最大セグメント長は次の値に決定される．
M SSsender = M SSreceiver = 4312(octet)
(4.1)
58
第 4章
TCP の実装モデルとその問題
Receiver
CHALLENGE XL
IRIX 5.3
Sender
NEWS 5000
NEWS-OS 6.1
Router Router
Cisco7000 CiscoAGS+
ATM
Ethernet
MTU=9180 MTU=1500
FDDI LAN
MTU=4352
図 4.3: 実験 1 の環境
しかし，経路 MTU 探索により送信ホストの最大転送単位が M T Usender = 1500octet にな
る．その結果，送信ホストの最大セグメント長は M SSsender = 1460octet になり，この MSS
単位でスロー・スタートを行う．受信ホストはデータを 2MSS，すなわち 2M SSreceiver =
8624octet 受信するまで遅延確認応答をする．その結果，送信ホストの輻輳ウィンドウ win
が次の式を満たすまで，確認応答が遅延されることになる．
win × M SSsender > 2 × M SSreceiver = 8624(octet)
(4.2)
この式は win = 6 になるまで成立しない．輻輳ウィンドウは 1 つの確認応答ごとに 1 つ
大きくなるため，最初の 6 パケットは確認応答が遅延されることになる．遅延確認応答が
0.2 秒の場合には，この期間は 0.8 秒∼1.0 秒になる．その結果，通信開始時からこの期間
はスループットが極端に低下する．スループットが極端に小さい期間は，MSS オプション
で決定した最大セグメント長と，経路 MTU の値の差が大きければ大きいほど長くなる．
遅延確認応答の遅延時間を Tdelay とすると，スループットが極端に小さくなる期間 T はお
およそ次の式で表される．
T = 2 × Tdelay ×
M SSreceiver
M SSsender
(4.3)
4.3
TCP の下位層
100000
Total Data
80000
60000
40000
20000
0
0
0.2
0.4
0.6
Time (s)
0.8
1
1.2
0.8
1
1.2
図 4.4: シーケンス番号
10
Throughput (Mbps)
8
6
4
2
0
0
0.2
0.4
0.6
Time (s)
図 4.5: スループット
59
60
第 4章
TCP の実装モデルとその問題
Sender
Receiver
NEWS 5000
NEWS-OS 6.1
DEC5900
ULTRIX 4.4
Router Router
Cisco7000 CiscoAGS+
ATM
Ethernet
MTU=9180 MTU=1500
FDDI LAN
MTU=4352
図 4.6: 実験 2 の環境
実験 2
実験 2 は，図 4.6 のような環境で実験を行った．これは実験 1 とほぼ同じ環境であるが，
データを受信するホストのハードウェアとオペレーティング・システムが異なる．DBS で
データ転送を行い，シーケンス番号の推移とスループットを測定した結果を図 4.7 と図 4.8
に示す．
図を見ると，実験 1 とは異なり，データ送信開始後，約 0.4 秒間だけデータが間欠的に
送信されいる．これは，2MSS 受信するたびに確認応答をするのではなく，2 つのセグメ
ントを受信すると確認応答をするように受信ホストの遅延確認応答が実装されているから
だと予想できる．
4.3
TCP の下位層
100000
Total Data
80000
60000
40000
20000
0
0
0.2
0.4
0.6
Time (s)
0.8
1
1.2
0.8
1
1.2
図 4.7: シーケンス番号
10
Throughput (Mbps)
8
6
4
2
0
0
0.2
0.4
0.6
Time (s)
図 4.8: スループット
61
62
第 4章
TCP の実装モデルとその問題
Receiver
NEWS 7000
NEWS-OS 6.1
Sender
SPARCstatopmIPX
SunOS 5.4
Router
Router
Cisco7000
SPARCstation 20
ATM
MTU=9188
ATM LAN
Ethernet LAN
MTU=1500
MTU=9188
図 4.9: 実験 3 の環境
実験 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 探索を実装し
たときにこの不具合が発生することになったが，十分なテストが行われていなかったため
不具合が含まれたまま出荷されたと予想できる．
4.3
TCP の下位層
63
¶
³
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)
02.375918 sparc.20
> news.44475: . 1449:2897(1448) ack 1 win 27512 (DF)
02.442500 news.44475 > sparc.20: . ack 2897 win 54840 (DF)
04.296011 sparc.20
> news.44475: . 2897:4345(1448) ack 1 win 27512 (DF)
04.362261 news.44475 > sparc.20: . ack 4345 win 54840 (DF)
08.136310 sparc.20
> news.44475: . 4345:5793(1448) ack 1 win 27512 (DF)
08.202284 news.44475 > sparc.20: . ack 5793 win 54840 (DF)
15.816743
15.882495
15.885565
15.888796
sparc.20
news.44475
sparc.20
news.44475
>
>
>
>
news.44475:
sparc.20: .
news.44475:
sparc.20: .
. 5793:7241(1448) ack 1 win 27512 (DF)
ack 7241 win 54840 (DF)
. 8193:9641(1448) ack 1 win 27512 (DF)
ack 7241 win 54840 (DF)
31.177561 sparc.20
> news.44475: . 7241:8193(952) ack 1 win 27512 (DF)
31.180696 news.44475 > sparc.20: . ack 9641 win 54840 (DF)
...........
µ
図 4.10: 実験 3 の測定結果
´
64
第 4章
TCP の実装モデルとその問題
Sender
Ultra Enterprise 3000server
SunOS 5.5.1
Router
Router
Receiver
Alpha Station
DEC OSF/1 V3.2A
Cisco7000
SPARCstatopmIPX
SunOS 5.4
FDDI LAN
MTU=4352
Ethernet
MTU=1500
ATM
MTU=9188
図 4.11: 実験 4 の環境
実験 4
実験 4 は，図 4.11 のような環境で実験を行った．Sender から Receiver へ FTP でファ
イル転送を行い，途中の Ethernet で tcpdump コマンドによりパケットをモニタした．結
果を図 4.12 に示す．
結果を見ると，3 つ目のデータパケットが送信されていないことが分かる．これだけで
も異常であるが，再送が行われるのは 20 秒後である．通常，TCP は再送タイマの最小値
を 1 秒に設定する．今回の LAN のような環境では，通常，タイムアウトによる再送は 1
秒後に行われる．しかし，20 秒間も再送が停止している．これは，この実装の不具合だと
いえる．
この現象も実験 3 と同様に，TCP/IP の実装に経路 MTU 探索を加えられたことにより，
TCP の実装に不具合が発生したと考えられる．しかし，十分なテストが行われておらず，
この不具合を発見できないまま出荷されたと考えられる．
4.3
TCP の下位層
65
¶
³
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.696034
08.870476
08.873433
09.070543
ultra.59704
sun4.20
ultra.59704
sun4.20
>
>
>
>
sun4.20: . 1461:2921(1460) ack 1 win 26280 (DF)
ultra.59704: . ack 2921 win 24576
sun4.20: . 4313:5773(1460) ack 1 win 26280 (DF)
ultra.59704: . ack 2921 win 24576
19.947892 ultra.59704
20.075180 sun4.20
20.078254 ultra.59704
20.078917 ultra.59704
20.275262 sun4.20
20.278178 ultra.59704
20.279409 ultra.59704
20.475343 sun4.20
20.478313 ultra.59704
20.479542 ultra.59704
20.480777 ultra.59704
20.675443 sun4.20
...........
µ
>
>
>
>
>
>
>
>
>
>
>
>
sun4.20: . 2921:4381(1460) ack 1 win 26280 (DF)
ultra.59704: . ack 5773 win 24576
sun4.20: . 5773:7233(1460) ack 1 win 26280 (DF)
sun4.20: P 7233:8193(960) ack 1 win 26280 (DF)
ultra.59704: . ack 8193 win 24576
sun4.20: . 8193:9653(1460) ack 1 win 26280 (DF)
sun4.20: P 9653:11113(1460) ack 1 win 26280 (DF)
ultra.59704: . ack 11113 win 24576
sun4.20: . 11113:12573(1460) ack 1 win 26280 (DF)
sun4.20: . 12573:14033(1460) ack 1 win 26280 (DF)
sun4.20: P 14033:15493(1460) ack 1 win 26280 (DF)
ultra.59704: . ack 15493 win 24576
´
図 4.12: 実験 4 の測定結果
66
第 4章
TCP の実装モデルとその問題
Receiver
CHALLENGE XL
IRIX 5.3
Sender
NEWS 5000
NEWS-OS 6.1
Router Router
Cisco7000 CiscoAGS+
ATM
Ethernet
MTU=9180 MTU=1500
FDDI LAN
MTU=4352
図 4.13: 実験 5 の環境
実験 5
実験 5 は，図 4.13 のような環境で実験を行った．途中の Ethernet で tcpdump コマンド
によりパケットをモニタした結果を図 4.14 に示す．
0.874041 秒，0.874248 秒，0.874456 秒のパケットは確認応答パケットである．しかし
これは，データを受信しているホストではなく，データを送信しているホストが送信して
いる．データを送信しているホストは，コネクション確立時の SYN パケットに対する確
認応答以外に確認応答を送信する必要はない．しかし，実験 5 では，送信側が複数の確認
応答パケットを送信することが観測された．これは，明らかにデータを送信しているホス
トの実装の不具合である．しかもこの後，データ転送が終了するまで，たくさんの確認応
答パケットが送信される現象が観測された．
コネクション確立時の SYN パケットに対する確認応答はすでに送信済みであり，新たに
送信するのは TCP のプロトコルに違反している．ただし，大きな問題とはならないと予
想されるが，トラヒックが増加されネットワークの帯域を無駄に利用していることになる．
4.3
TCP の下位層
67
¶
00.086404
00.088218
00.089362
00.098010
³
news.20 > sgi.3871:
sgi.3871 > news.20:
news.20 > sgi.3871:
news.20 > sgi.3871:
S
S
.
.
(0) win 0 <mss 9140,wscale 0,eol> (DF)
(0) ack 1 win 61440 <mss 4312,nop,wscale 0>
ack 1 win 56056 (DF)
1:1449(1448) ack 1 win 56472 (DF)
00.269968 sgi.3871 > news.20: . ack 1449 win 61440
00.274175 news.20 > sgi.3871: . 1449:2897(1448) ack 1 win 56472 (DF)
00.275393 news.20 > sgi.3871: . 2897:4345(1448) ack 1 win 56472 (DF)
00.470188
00.473285
00.474507
00.475165
sgi.3871 > news.20:
news.20 > sgi.3871:
news.20 > sgi.3871:
news.20 > sgi.3871:
.
.
.
.
ack 4345 win 61440
4345:5793(1448) ack 1 win 56472 (DF)
5793:7241(1448) ack 1 win 56472 (DF)
7241:8193(952) ack 1 win 56472 (DF)
00.670320
00.673372
00.674594
00.675812
00.677036
sgi.3871 > news.20:
news.20 > sgi.3871:
news.20 > sgi.3871:
news.20 > sgi.3871:
news.20 > sgi.3871:
.
.
.
.
.
ack 8193 win 61440
8193:9641(1448) ack 1 win 56472 (DF)
9641:11089(1448) ack 1 win 56472 (DF)
11089:12537(1448) ack 1 win 56472 (DF)
12537:13985(1448) ack 1 win 56472 (DF)
00.870186
00.873168
00.873825
00.874041
00.874248
00.874456
sgi.3871 > news.20:
news.20 > sgi.3871:
news.20 > sgi.3871:
news.20 > sgi.3871:
news.20 > sgi.3871:
news.20 > sgi.3871:
.
.
.
.
.
.
ack 13985 win 61440
13985:15433(1448) ack 1 win 56472 (DF)
15433:16385(952) ack 1 win 56472 (DF)
ack 1 win 56472 (DF)
ack 1 win 56472 (DF)
ack 1 win 56472 (DF)
01.070212 sgi.3871 > news.20: . ack 16385 win 61440
...........
µ
図 4.14: 実験 5 の測定結果
´
第 4章
68
4.3.3
TCP の実装モデルとその問題
経路 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 の実装と性能の評価
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
この章では，インターネットにおける 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 探索が実装されているオペレーティング・システム
には，不具合が含まれている場合がある．今回調査したオペレーティング・システムは，
第 5章
76
TCP の実装と性能の評価
経路MTU検査システム
FTPやHTTPの
コマンドを送信
ICMP到達不能メッセージ
を送信し経路MTUを疑似的
に変更
図 5.1
被検査システム
任意のネットワーク
要求に応じてデータを送信
新しいMTUをもとに
MSSを変更してデータ
を送信
経路 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
サーバの実装を検査することで，インターネットで稼働している大部分のオペレーティン
グ・システムの実装検査が可能になる．
78
5.3.2
第 5章
TCP の実装と性能の評価
TCP 実装検査ツールに求められる機能
経路 MTU の検査以外にも TCP の様々な検査ができる必要がある．検査できる項目は
多ければ多い方がよいが，必要なのはそれだけではない．検査はできるだけ自動的に行わ
れ，検査の結果はどのような問題が発生しているか具体的に分かることが望ましい．検査
の設定が非常に複雑であれば，検査自体が困難になる．また，結果をみても，TCP プロ
トコルを知りつくした人でなければ不具合があるかどうかを判断できないのであれば，そ
れは，役に立つ検査ツールとはいえない．TCP の実装検査ツールは，簡単な設定で動作
し，不具合箇所を具体的に示してくれる必要がある．
5.4
TCP の性能評価に関する考察
79
TCP の性能評価に関する考察
5.4
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 性能測定ツールでは，これ
を模倣できる必要がある．
第 5章
80
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 の実装の検査は，いくつ
かのツールを作成してそれを使う場合もあるが，多くの場合は手作業でコマンドを入力す
82
第 5章
TCP の実装と性能の評価
るという原始的な方法で，動作チェックが行われている．
TCP に限らず，TCP/IP プロトコル・スタック全体において，実装の検査や評価は十
分には行われていない．オプションが設定された IP パケットや巨大な ICMP エコーメッ
セージなど，特定のパケットを受信すると，システムが異常終了するというオペレーティ
ングシステムが発見されて話題になったことがある．
通常のソフトウェアの開発と異なり，ネットワークのプロトコルの場合は，同じ仕様の
ソフトウェアが様々なソフトウェア・メーカや，研究機関などで開発されている．このた
め，不具合を調査する共通のソフトウェアを作れば，ソフトウェアの開発にかかる期間の
短縮や，隠れた不具合の除去が可能になると考えられる．また，TCP の送信アルゴリズ
ムによっては，ネットワークの利用帯域の公平性を崩すような実装も可能である．今後，
TCP の内部の実装を調査することが，より重要なことになってくると考えられる．そし
て，検査するツールを作成し，インターネットに接続される実装を監視し，実装に問題が
ないかどうかを監視することが必要である．
第 6 章 TCP の性能評価システムの提案・実装・評価
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
この章では，5.4 節で述べた，TCP の性能評価を実現するためのシステムとして，DBS
(Distributed Benchmark System) を提案する [60][62][61][63]．このシステムは，TCP の
性能や，ネットワーク・システムの性能を評価するシステムである．多点間のホストで，
同時に複数のコネクションを確立し，同時にデータ転送を行い，そのときのスループット
の時間変化を測定することができる．
この章では，DBS システムの提案と実装，評価について述べる．さらに，実際のネット
ワーク環境で測定した結果について報告し，DBS によって得られる効果を明らかにする．
DBS の提案と実装
6.1
6.1.1
DBS の提案
TCP とネットワークの性能評価を実現するための TCP 性能評価システム DBS (Distributed 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
第 6章
84
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
BSDI
Silicon Graphics
Digital Equipment
SONY
Tenon Intersystems
FreeBSD
NetBSD
Linux
SunOS V4.1.3，V4.1.4
SunOS V5.4，V5.5.1 (Solaris)
BSD/OS V2.0，V2.1，V3.0，V3.1
IRIX R5.3，R6.3
Digital UNIX V3.0
ULTRIX 4.4
NEWS-OS V6.1
MachTen V4.0.3
FreeBSD V2.0
NetBSD V1.1，V1.2
Linux V2
情報収集ホストの DBS コントローラは，DBS デーモンへの実験内容の指示や，結果を
受信してファイルに出力する機能を持つ．実験ホストの DBS デーモンは，DBS コントロー
ラの指示により実験のトラヒックを生成し測定を行う．なお，1 つの実験ホストで複数の
コネクションを確立してデータ転送を行う場合は，その数だけ DBS デーモンが別のプロ
セスとして実行される1) ．
DBS の動作の概要について説明する．
(1) 情報収集ホストから各実験ホストへ，実験の内容を指示する命令が送信される．
(2) DBS デーモンが命令を受信し，データの送受信時刻を記録するためのメモリ空間な
どの資源を用意する．実験の準備が完了したら OK の返事をする．何か問題があっ
たら Fail の返事とエラー番号を返送する．
(3) すべての実験ホストから情報収集ホストに OK の返事が送られてきた場合は，実験
開始時刻を知らせる命令を送信する．その時刻になると実験ホスト群の間でデータ
転送・測定が行われる．実験ホストから Fail の返事がきた場合には実験中止の命令
を送信する．
(4) 実験終了時刻になると，情報収集ホストから結果を要求する命令が送信される．
(5) 実験ホスト群から情報収集ホストへ測定結果が転送され，ファイルに格納される．
実験ホストがネットワークのインターフェースを 1 つしか備えていない場合は，命令と
結果のトラヒックが実験ネットワークを通ることになる．このことが結果に影響するのを
防ぐため，実験のトラヒックと制御のトラヒックが同時に流れないように DBS を実装した．
1)
fork システムコールを使用した．
86
第 6章
TCP の性能評価システムの提案・実装・評価
Measurement Hosts
Controling Host
sending Commands
Measurement Network
receiving Results
Configuration File
files of the Results
図 6.1: DBS のシステム構成図
DBSコントローラ
コマンドファイル
の読み込み
DBSデーモン(複数存在する)
(1) コマンド送信
(2) 実験準備完了合図 (OK or Fail)
データを送受信
する数分のプロ
セスが起動する
(3) 実験開始時刻通達 or 実験中止
実験開始時刻
まで待つ
データの送受信
が行なわれる
(4) 結果の送信要求
(5) 結果データの送信
結果の書き込み
図 6.2: DBS の処理の流れ
6.1
DBS の提案と実装
87
また，実験ホストが情報収集ホストを兼ねる場合は，DBS コントローラの処理が DBS
デーモンの処理に影響を与える可能性がある．このことが結果に影響するのを防ぐため，
実験中は DBS コントローラは sleep 状態となり，できるだけ CPU 時間を消費しないよう
に実装した．
第 6章
88
TCP の性能評価システムの提案・実装・評価
(1) 一つのデータの大きさ
(2) 一回のシステムコール
で送信するデータ
送信するデータ
(4) 送信の時間間隔
(3) 送信開始時刻の間隔
時間の経過
図 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 によるデータ転送にネット
ワークの負荷の変動が与える影響を調査するためには，シーケンス番号の時間推移を測定
できる必要がある．以上，ここで述べたこれらの機能は，既存の測定ツール単体では実現
90
第 6章
TCP の性能評価システムの提案・実装・評価
表 6.2: 性能測定ツールの機能の比較
トラヒックの生成
DBS
TCP および UDP によるデータ・トラヒックの生成
O
2 点間のホストで複数のデータ転送
O
多点間のホストでのデータ転送
O
データリンクを直接使った転送 (IP を使わない)
X
送信データをリダイレクションで入力できる
X
トラヒック・パターンの設定
O
Netperf
O
X
X
O
X
X
ttcp
O
X
X
X
O
X
nettest
O
O
X
X
X
X
NetSpec
O
O
O
X
X
O
測定実験の設定
DBS
各々のデータ転送の開始時刻の設定
O
メッセージ・サイズの設定
O
送信データ量の設定
O
ソケットのバッファ・サイズの設定
O
Nagle アルゴリズムの解除の設定
O
防火壁への対応，セキュリティへの配慮
O
Netperf
X
O
O
O
O
X
ttcp
X
O
O
O
O
X
nettest
X
O
O
O
O
X
NetSpec
X
O
O
O
O
X
測定結果の解析
DBS
シーケンス番号の時間推移の測定
O
平均スループットの測定
O
スループットの時間変化の測定
O
遅延時間の時間変化の測定
O
遅延時間の揺らぎの時間変化の測定
O
コネクション確立のオーバーヘッドの測定
O
TCP コントロール・ブロックの値を記録
O
スロー・スタートの挙動の測定
O
ラウンド・トリップ時間の測定
O
輻輳ウィンドウの変動の測定
O
Netperf
X
O
X
X
X
O
X
X
X
X
ttcp
X
O
X
X
X
X
X
X
X
X
nettest
X
O
X
X
X
X
X
X
X
X
NetSpec
X
O
X
X
X
X
X
X
X
X
されていないが，DBS ではすべての機能が実現されている．また，DBS には TCP コン
トロール・ブロックの値を記録できる機能が備えられている．これは他の性能測定ツール
にはない特長といえる．この機能を利用すれば，TCP の挙動のより精密な調査や解析を
することが可能になる．
DBS は他のツールと比較して高機能であるが，不足している機能が 2 つある．それは，
データリンクを直接使った転送と，送信データをリダイレクションで入力できる機能であ
る．しかし，IP を使わないデータ転送は TCP の性能評価にとっては必要ない．また，送
受信データをリダイレクションで入出力できる機能は，複雑なトラヒック・パターンを設
定する機能である程度模倣することができる．TCP の性能測定という視点から総合的に
判断すると，DBS は既存の測定ツールよりも明らかに高機能だといえる．
6.2
6.2.2
DBS の評価
91
測定結果の妥当性
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 セグメントである．
第 6章
TCP の性能評価システムの提案・実装・評価
Ethernet
Host1
10Mbps
Host2
図 6.4: 2 点間の Ethernet 実験環境
表 6.3: 評価に使用した機材と設定
CPU
OS
MSS
TCP バッファ・サイズ
メッセージ・サイズ
送信回数 (DBS，ttcp)
送信時間 (Netperf)
Twinhead Subnote (486 33MHz)
BSD/OS V2.1
1448octet
8196byte
2048byte
2048 回
10 秒
表 6.4: それぞれのツールでの測定結果 (平均)
平均スループット
DBS
Netperf
ttcp
6223Kbps
6357Kbps
6172Kbps
DBS を 100 としたときの比率
100.0
102.1
99.1
8000
DBS
Netperf
ttcp
7000
6000
Throughput(Kbps)
92
5000
4000
3000
2000
1000
0
0
1
2
3
Time(s)
4
5
図 6.5: それぞれのツールでの測定結果 (時間変化)
6
6.3
6.3
DBS による性能測定実験
93
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)．
94
第 6章
TCP の性能評価システムの提案・実装・評価
JCSAT-1
(JSAT)
Satellite Channel
2Mbps
DCE
Ethernet 10Mbps
HOST1
2Mbps (RTT ~0.5s)
DCE
Ethernet
10Mbps
HOST2
図 6.6: ウィンドウ・サイズ拡張オプションの評価
表 6.5 ウィンドウ・サイズ拡張オプションの評価に使用した機材と設定
CPU
OS
Router
MSS
TCP バッファ・サイズ
(最大ウィンドウ・サイズ)
メッセージ・サイズ
データ転送時刻
送信回数
その他
Twinhead Subnote (486 33MHz)
BSD/OS V2.0.1
SPARCstation10 (SunOS4.1.4)
512octet
8196byte
(8196octet)
32768byte
(32768octet)
65535byte
(66535octet)
131072byte (131072octet)
1024byte
0.00 秒
1000 回
TCP DEBUG 機能を利用
6.3
DBS による性能測定実験
1.2e+06
8192 recv
32768 recv
65535 recv
131072 recv
Sequence Number
1e+06
800000
600000
400000
200000
0
0
5
10
15
Time (s)
20
25
30
図 6.7 ウィンドウ・サイズの拡張オプションの評価 (シーケンス番号の
推移)
1.8
8192 recv
32768 recv
65535 recv
131072 recv
1.6
Throughput (Mbps)
1.4
1.2
1
0.8
0.6
0.4
0.2
0
0
図 6.8
5
10
15
Time (s)
20
25
30
ウィンドウ・サイズの拡張オプションの評価 (スループットの
変化)
95
第 6章
TCP の性能評価システムの提案・実装・評価
300000
8192 cwnd
32768 cwnd
65535 cwnd
131072 cwnd
250000
Window Size (byte)
96
200000
150000
100000
50000
0
0
5
10
15
Time (s)
20
25
30
図 6.9 ウィンドウ・サイズの拡張オプションの評価 (輻輳ウィンドウの
変化．バッファ・サイズが 32768byte と 65535byte の場合は，7 秒
目までバッファ・サイズが 131072byte の場合と重なるように変化
している)
6.3
DBS による性能測定実験
97
JCSAT-1
(JSAT)
Satellite Channel
2Mbps
DCE
Ethernet
HOST1
HOST2
2Mbps (RTT ~0.5s)
DCE
10Mbps
HOST3
HOST4
HOST5
図 6.10: 衛星回線での測定
表 6.6: 衛星回線での測定環境と設定
CPU(HOST1,2,3,4)
CPU(HOST5)
OS
Router
MSS
TCP バッファ・サイズ
メッセージ・サイズ
データ転送時刻
送信回数
その他
Ethernet
10Mbps
Twinhead Subnote(486 33MHz)
GATEWAY2000(486 66MHz)
BSD/OS V2.1
SPARCstation10(SunOS4.1.4)
512octet
65535byte
2048byte
HOST1–HOST5: 0.00 秒
HOST2–HOST5: 2.00 秒
HOST3–HOST5: 4.00 秒
HOST4–HOST5: 6.00 秒
300 回
TCP DEBUG 機能を利用
第 6章
TCP の性能評価システムの提案・実装・評価
1.2e+06
host1-host5 send
host2-host5 send
host3-host5 send
host4-host5 send
host1-host5 recv
host2-host5 recv
host3-host5 recv
host4-host5 recv
host1-host5 lost/rexmt
host2-host5 lost/rexmt
host3-host5 lost/rexmt
host4-host5 lost/rexmt
Sequence Number
1e+06
800000
600000
400000
200000
0
0
10
20
30
Time (s)
40
50
60
図 6.11: 衛星回線での測定結果 (シーケンス番号の推移)
2
host1-host5 recv
host2-host5 recv
host3-host5 recv
host4-host5 recv
total
1.8
1.6
Throughput (Mbps)
98
1.4
1.2
1
0.8
0.6
0.4
0.2
0
0
10
20
30
Time (s)
40
50
図 6.12: 衛星回線での測定結果 (スループットの変化)
60
6.3
DBS による性能測定実験
70000
host1-host5 cwnd
host2-host5 cwnd
host3-host5 cwnd
host4-host5 cwnd
host1-host5 ssthresh
host2-host5 ssthresh
host3-host5 ssthresh
host4-host5 ssthresh
60000
Size (byte)
50000
40000
30000
20000
10000
0
0
10
20
30
Time (s)
40
50
60
図 6.13 衛星回線での測定結果 (輻輳ウィンドウ (cwnd) とスロー・スター
ト閾値 (ssthresh) の変化)
99
100
6.3.2
第 6章
TCP の性能評価システムの提案・実装・評価
ATM と Router が混在する環境
図 6.14 のように ATM とルータが接続された環境で，表 6.7 に示す設定でデータ転送実
験を行った．なお，HOST1，HOST2 と，HOST3 の間の通信では，送信されるデータは，
Router で一旦 IP レベルの経路制御がされてから終点ホストへ届けられる．結果を図 6.15，
図 6.16 に示す．
結果をみると，データを転送しているコネクションが 1 つしかなく，輻輳しない場合に
は，連続的で円滑なデータ転送が行われる．しかし 2 秒後，データを転送するコネクショ
ンが 2 つに増えると，輻輳状態になり，スループットが極端に悪化する．2 つのデータ転
送のスループットが同期し，1 秒おきにバースト的なデータ転送と転送停止を繰り返して
いる．この結果から，ATM のように送信権の制御がなく，セルレベルでデータが喪失す
るネットワークでは，TCP のセグメントレベルでの輻輳回避制御や再送制御がうまく機
能しない場合があると考えられる．
6.3
DBS による性能測定実験
Host1
Host3
Public ATM Network
100Mbps ATM Switch
32Mbps
ATM Switch
100Mbps
155Mbps
Host2
155Mbps
Router
Nara Institute of Science
and Technorogy
Osaka University
Toyonaka Campus
図 6.14: ATM とルータが混在する環境での測定
表 6.7: ATM とルータが混在する環境の設定
CPU
OS
ATM Switch
ATM Card
Router
AAL Type
MTU
MSS
TCP バッファ・サイズ
メッセージ・サイズ
データ転送時刻
送信回数
Sun SPARCstation10
SunOS 4.1.3
NEC ATOMIS5
Fore SBA-200
NEC IP 45/650 (Cisco7000)
AAL 5
9188octet
9148octet
52428byte
8196byte
HOST1–HOST3: 0.00 秒
HOST2–HOST3: 2.00 秒
HOST1–HOST3: 2000 回
HOST2–HOST3: 500 回
101
第 6章
TCP の性能評価システムの提案・実装・評価
1.8e+07
host1-host3 recv
host2-host3 recv
1.6e+07
Sequence Number
1.4e+07
1.2e+07
1e+07
8e+06
6e+06
4e+06
2e+06
0
0
図 6.15
2
4
6
8
10
Time (s)
12
14
16
ATM とルータが混在する環境での測定結果 (シーケンス番号の
推移)
35
host1-host3 recv
host2-host3 recv
30
Throughput (Mbps)
102
25
20
15
10
5
0
0
図 6.16
2
4
6
8
10
Time (s)
12
14
16
18
ATM とルータが混在する環境での測定結果 (スループットの
変化)
6.3
6.3.3
DBS による性能測定実験
103
FDDI
図 6.17 のような，論理的に同一の FDDI リング上にあるホスト間で，表 6.8 に示す設定
でデータ転送実験を行った．その結果を図 6.18 と図 6.19 に示す．
結果から，データ転送をしているコネクションが N 本存在する場合，各々のスループッ
トはデータリンクの伝送速度の 1/N に近い値になることがわかる．また，データ転送をし
ているコネクションの数が増えたり減ったりすると，それぞれのコネクションに割り当て
られる帯域が，素早く 1/N に変化することもわかる．この実験から，FDDI 上で TCP を
利用すると，スループットが平等に割り当てられることが明らかになった．また，このこ
とから，FDDI は TCP と親和性が高いと考えられる．
104
第 6章
TCP の性能評価システムの提案・実装・評価
HOST1
HOST10
HOST2
FDDI
100Mbps
HOST9
HOST3
HOST8
HOST4
HOST7
HOST5
HOST6
図 6.17: FDDI での測定
表 6.8: FDDI の測定環境と設定
CPU
OS
MSS
TCP バッファ・サイズ
メッセージ・サイズ
データ転送時刻
送信回数
SGI INDY (R4600 100MHz)
IRIX R 5.3
4312octet
65535byte
8192byte
HOST1–HOST6: 0.00 秒
HOST2–HOST7: 0.50 秒
HOST3–HOST8: 1.00 秒
HOST4–HOST9: 1.00 秒
HOST5–HOST10: 1.50 秒
1000 回
6.3
DBS による性能測定実験
9e+06
host1-host6 recv
host2-host7 recv
host3-host8 recv
host4-host9 recv
host5-host10 recv
8e+06
Sequence Number
7e+06
6e+06
5e+06
4e+06
3e+06
2e+06
1e+06
0
0
0.5
1
1.5
2
Time (s)
2.5
3
3.5
4
図 6.18: FDDI での測定結果 (シーケンス番号の推移)
90
host1-host6 recv
host2-host7 recv
host3-host8 recv
host4-host9 recv
host5-host10 recv
80
Throughput (Mbps)
70
60
50
40
30
20
10
0
0
0.5
1
1.5
2
Time (s)
2.5
3
図 6.19: FDDI での測定結果 (スループットの変化)
3.5
4
105
106
6.3.4
第 6章
TCP の性能評価システムの提案・実装・評価
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 のようなテストツー
ルが無かったために，性能の評価ができなかったのである．そのため，不具合が含まれて
いるにもかかわらず，開発側も利用者側もこの問題に気が付かなかったのである．
DBS による性能測定実験
6.3
ONYX(20CPU)
HIPPI 800Mbps
CHALLENGE (36CPU)
ATM (OC12) 622Mbps
HIPPI-ATM TA
HIPPI-ATM TA
ONYX(12CPU)
ATM Switch
ATM Switch
HIPPI-ATM TA
図 6.20: 測定環境
表 6.9: 測定環境
CPU
OS
ATM Switch
HIPPI-ATM TA
TCP バッファ・サイズ
メッセージ・サイズ
データ転送開始時刻
SGI ONYX RE2, CHALLENGE
IRIX 5.3
NEC ATOMIS7
NEC ATOMIS2HA
256000byte
8192byte
ONYX(20)→CHALLENGE(36):
ONYX(12)→CHALLENGE(36):
ONYX(20)→CHALLENGE(36):
ONYX(12)→CHALLENGE(36):
XL
0.0s
1.0s
2.0s
3.0s
107
第 6章
TCP の性能評価システムの提案・実装・評価
9e+07
20-36 send
12-36 send
20-36 recv
12-36 recv
8e+07
Sequence Number
7e+07
6e+07
5e+07
4e+07
3e+07
2e+07
1e+07
0
0
1
2
3
Time (s)
4
5
6
図 6.21: 実験 1:シーケンス番号
350
20-36 recv
12-36 recv
total
300
Throughput (Mbps)
108
250
200
150
100
50
0
0
1
2
3
Time (s)
4
図 6.22: 実験 1:スループット
5
6
6.3
DBS による性能測定実験
9e+07
20-36-1 recv
12-36-1 recv
20-36-2 recv
12-36-2 recv
8e+07
Sequence Number
7e+07
6e+07
5e+07
4e+07
3e+07
2e+07
1e+07
0
0
5
10
15
20
25
Time (s)
図 6.23: 実験 2:シーケンス番号
700
20-36-1 recv
12-36-1 recv
20-36-2 recv
12-36-2 recv
total
Throughput (Mbps)
600
500
400
300
200
100
0
0
5
10
15
Time (s)
図 6.24: 実験 2:スループット
20
25
109
第 6章
TCP の性能評価システムの提案・実装・評価
2.5e+08
20-36-1 recv
12-36-1 recv
20-36-2 recv
12-36-2 recv
Sequence Number
2e+08
1.5e+08
1e+08
5e+07
0
0
2
4
6
8
Time (s)
10
12
14
図 6.25: 実験 3:シーケンス番号
500
20-36-1 recv
12-36-1 recv
20-36-2 recv
12-36-2 recv
total
450
400
Throughput (Mbps)
110
350
300
250
200
150
100
50
0
0
2
4
6
8
Time (s)
図 6.26: 実験 3:スループット
10
12
14
6.3
DBS による性能測定実験
2e+08
4-20-36-1 recv
4-12-36-1 recv
4-20-36-2 recv
4-12-36-2 recv
4-20-36-3 recv
4-12-36-3 recv
4-20-36-4 recv
4-12-36-4 recv
1.8e+08
Sequence Number
1.6e+08
1.4e+08
1.2e+08
1e+08
8e+07
6e+07
4e+07
2e+07
0
0
2
4
6
8
10
Time (s)
12
14
16
18
図 6.27: 実験 4:シーケンス番号
700
4-20-36-1 recv
4-12-36-1 recv
4-20-36-2 recv
4-12-36-2 recv
4-20-36-3 recv
4-12-36-3 recv
4-20-36-4 recv
4-12-36-4 recv
total
Throughput (Mbps)
600
500
400
300
200
100
0
0
2
4
6
8
10
Time (s)
12
図 6.28: 実験 4:スループット
14
16
18
111
第 6章
TCP の性能評価システムの提案・実装・評価
2e+08
4-20-36-1 recv
4-12-36-1 recv
4-20-36-2 recv
4-12-36-2 recv
4-20-36-3 recv
4-12-36-3 recv
4-20-36-4 recv
4-12-36-4 recv
1.8e+08
Sequence Number
1.6e+08
1.4e+08
1.2e+08
1e+08
8e+07
6e+07
4e+07
2e+07
0
0
2
4
6
8
Time (s)
10
12
14
16
図 6.29: 実験 5:シーケンス番号
250
4-20-36-1 recv
4-12-36-1 recv
4-20-36-2 recv
4-12-36-2 recv
4-20-36-3 recv
4-12-36-3 recv
4-20-36-4 recv
4-12-36-4 recv
200
Throughput (Mbps)
112
150
100
50
0
0
2
4
6
8
Time (s)
10
図 6.30: 実験 5:スループット
12
14
16
6.4
6.4
WAN
113
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 からは，ウィンドウ・サイズに
よるスループットの変化はほとんどわからない．
114
第 6章
TCP の性能評価システムの提案・実装・評価
Part of WIDE Internet Backbone
Nara NOC
Tokyo NOC
1.5Mbps
1.5Mbps
HOST1
Fujisawa NOC
Nara Institute of Science
and Technology
HOST2
Keio University
Shonan Fujisawa Campus
図 6.31: WAN での測定
表 6.10: WAN の測定環境と設定
CPU
OS
MSS
TCP バッファ・サイズ
コネクションの向き
測定日時
メッセージ・サイズ
その他
SPARCstation(SUN)
SunOS 4.1.3
536octet
実験 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
300000
send
recv
lost/rexmt
Sequence Number
250000
200000
150000
100000
50000
0
0
図 6.32
5
10
15
Time (s)
20
25
30
WAN 実験 1 の測定結果 (シーケンス番号の推移と喪失セグメ
ント)
0.45
recv
0.4
Throughput (Mbps)
0.35
0.3
0.25
0.2
0.15
0.1
0.05
0
0
5
10
15
Time (s)
20
25
図 6.33: WAN 実験 1 の測定結果 (スループットの変化)
30
115
第 6章
TCP の性能評価システムの提案・実装・評価
10000
cwnd
ssthresh
Size (byte)
8000
6000
4000
2000
0
0
図 6.34
5
10
15
Time (s)
20
25
30
WAN 実験 1 の測定結果 (輻輳ウィンドウ (cwnd) とスロー・ス
タート閾値 (ssthresh) の変化)
180000
send
recv
lost/rexmt
160000
140000
Sequence Number
116
120000
100000
80000
60000
40000
20000
0
0
図 6.35
20
40
60
Time (s)
80
100
120
WAN 実験 2 の測定結果 (シーケンス番号の推移と喪失セグメ
ント)
6.4
WAN
0.1
recv
0.09
Throughput (Mbps)
0.08
0.07
0.06
0.05
0.04
0.03
0.02
0.01
0
0
20
40
60
Time (s)
80
100
120
図 6.36: WAN 実験 2 の測定結果 (スループットの時間変化)
8000
cwnd
ssthresh
7000
Size (byte)
6000
5000
4000
3000
2000
1000
0
0
図 6.37
20
40
60
Time (s)
80
100
120
WAN 実験 2 の測定結果 (輻輳ウィンドウ (cwnd) とスロー・ス
タート閾値 (ssthresh) の変化)
117
118
6.5
第 6章
TCP の性能評価システムの提案・実装・評価
考察
静止衛星による衛星回線では，ラウンド・トリップ時間が長いため，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 短期デッドロック問題と既存の解決案
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
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
送信バッファ
受信バッファ
3MSS未満
Nagleアルゴリ
ズム有効時
2MSS未満
1MSS未満
2MSS未満
2MSS未満
Nagleアルゴリ
ズム無効時
2MSS未満
2MSS未満
送信済だが確認応答を受けていないデータ
未送信データ（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
ユーザ・プログラム
アプリケーションが送信するデータ
オペレーティング・システム
メモリ・バッファ
TCPモジュールが管理するバッファ
(メモリ・バッファへのポインタ)
3MSS
IPデータグラムに入れられるデータ
論
理
的
な
デ
｜
タ
の
流
れ
(メモリ・バッファへのポインタ)
1MSS
図 7.2: ネットワーク・モジュールの階層モデル
格納したり，受信したデータをメモリ・バッファからアプリケーションへ渡す働きがある．
メモリ・コピーによるオーバーヘッドを避けるため，ネットワーク・モジュールの各層は，
メモリ・バッファに格納された同一のデータをポインタで参照する．多くの実装では，ア
プリケーションからシステムコールによってオペレーティング・システムへ渡されるデー
タは，データが全く格納されていない未使用の固定長バッファに格納される．使用される
メモリバッファの大きさに比べて，アプリケーションのメッセージ・サイズが小さい場合，
メモリ・バッファの利用効率が悪くなる．
メモリ・バッファの合計が 3MSS 以上あったとしても，合計 3MSS 未満のデータしか格
納できないことが起こりうる．そうなると，7.1.1 節と同じ状態になり，デッドロックが発
生する．
また，このインターフェースが管理しているメモリ・バッファの空き領域が少なくなっ
た場合，TCP への送信処理が行われずに，バッファが大きくなるまで処理が中断される
ように実装されている場合がある．これは一種のフロー制御といえるが，このフロー制御
が TCP のフロー制御と独立に行われると，デッドロックが起きる可能性がある．
7.1.3
スロー・スタートの問題
送信ホストは，通信開始時にスロー・スタートの機構により，1MSS のセグメントを 1
つしか送信しない．しかし，受信ホストは，更なるセグメントの到着を待ち，すぐに確認
応答をしない．そのため，最初の 1 パケット目は図 7.3 の上段に示すようなデッドロック
が発生する．これは，スロー・スタートが設計されたとき [34]，すべての送信セグメント
に対して確認応答パケットが返ってくることを前提にしていたことに原因がある．
なお，このデッドロックは，ウィンドウをよりゆっくりと拡大させるため，スロー・ス
126
第 7章
TCP 短期デッドロック問題と既存の解決案
タートによる混雑の回避によい影響を与えるのではないかと考えられるかもしれない．し
かし，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 短期デッドロック問題
HOST A
HOST B
送信バッファ
受信バッファ
127
MSSが変化しない
場合
1MSS
輻輳ウィンドウ
経路MTU探索
によってMSSが
半分になった場合
3MSS
輻輳ウィンドウ
2MSS未満
2MSS未満
送信済だが確認応答を受けていないデータ
未送信データ（スロー・スタートにより送信を抑制されている）
受信したデータ（到着したデータが少なく遅延確認応答状態）
図 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章
128
TCP 短期デッドロック問題と既存の解決案
今までに提案された TCP デッドロック問題の解決案
7.2
今までに，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
7.3
今までに提案されたデッドロック解決案の問題点
129
今までに提案されたデッドロック解決案の問題点
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 に比べて十分に大きくとるということは現実的な解ではないことがわかる．半導
体の高集積化が進めば進むほど，より小型で省電力型の機器をインターネットに接続でき
るのであり，バッファ・サイズを大きくできるのは一部の機器に限定されると考えるべき
である．
130
第 7章
TCP 短期デッドロック問題と既存の解決案
HOST A
HOST B
PUSH
ACK
PUSH
ACK
PUSH
ACK
PUSH
図 7.4
インタラクティブ・データ転送で確認応答を遅延させない場合
また，インターネットは今後使いやすくなることが望まれている．そのためにはプラグ
&プレイが実現する必要がある．ユーザにはコンピュータを物理的にネットワークに接続
すれば，論理的な設定がすべて自動的に行われることが望まれている．しかし，今の TCP
では，これらのデッドロックが起こる可能性があり，ネットワークの利用効率が著しく悪
くなり，ユーザの使い勝手を阻害する可能性がある．
今後，インターネットがプラグ&プレイを実現し，ユーザにとって使いやすいネットワー
クになるためにも，デッドロックが起こらないように TCP を改善する必要がある．
ii. 遅延確認応答を止める解決案
ii の解決案を実装すれば，すべてのデッドロック問題を解決できると期待できる．デッド
ロックの原因のすべてに，遅延確認応答が関係している．そのため，確認応答を遅延させ
なければ，デッドロックは発生しなくなると考えられる．しかし，遅延確認応答を止める
という方法自体に問題がある．遅延確認応答は，シリー・ウィンドウ・シンドローム (SWS:
Silly Window Syndrome) と呼ばれるネットワークの帯域の利用効率を悪化させる現象を
回避するために提案された [19]．現在のインターネットでは多彩なデータリンクが用いら
れており，また，ネットワークには莫大な数のホストが接続されている．これらのことを
考えると，ネットワークの利用効率を著しく悪化させるシリー・ウィンドウ・シンドロー
ムを防止することは，必須事項であり，ii の解決案は受け入れられるものではない．
また，遅延確認応答を無効にすると，図 7.4 に示すようにインタラクティブ・データ転
送時にピギーバック処理が行われなくなる．特に即時性を必要とするインタラクティブ・
データ転送では，図 7.5 に示すように確認応答の数が莫大な数に増加することになる．そ
の結果，無駄なトラヒックが増えホストの負荷が増加する．その結果，スループットの低
下を招くという問題が発生する．
7.3
今までに提案されたデッドロック解決案の問題点
HOST A
131
HOST B
PUSH
ACK
PUSH
ACK
PUSH
ACK
PUSH
図 7.5
即時性を必要とするインタラクティブ・データ転送で確認応答
を遅延させない場合
iii. PUSH フラグで遅延確認応答を制御する解決案
iii の解決案は，デッドロックの根本的な解決にはなっていない．PUSH フラグが設定さ
れずにデッドロックが起きる場合には，デッドロックが起きることになる．実際，PUSH フ
ラグとデッドロックの間には完全な相関関係はなく，デッドロックが発生するときに PUSH
フラグが設定されるとは限らない．そのため，デッドロック問題のすべてを解決すること
はできない．
インタラクティブ・データ転送では PUSH フラグが設定されたセグメントに対してピ
ギーバックが行われる可能性がある．しかし，iii の実装をすると ii のときと同じように，
インタラクティブ・データ転送時にほとんどすべてのセグメントに対して遅延なく確認応
答が行われることになり，ピギーバックが行われなくなる．このため，ii の提案と同様に，
ネットワークや CPU の負荷が増加することになり，結果としてスループットを低下させ
る原因になる．
この iii の実装は根本的に間違っている．これは，TCP のデータ転送モデルにおける遅
延確認応答と PUSH フラグの役割をきちんと考慮していないためである．よって，受け入
れることはできない提案である．
iv. PUSH フラグの拡張によるデッドロック問題の解決
データ転送モデルの性質から，PUSH フラグが設定されたセグメントは，ピギーバック
される可能性が強い．したがって，PUSH フラグが設定されたセグメントは遅延させるべ
きである．iv の提案を実装すると，TCP に備えられているトラヒックを軽減するための
仕組みが動作しなくなる．
132
第 7章
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 デッドロック問題の解決策の提案・実装・
評価
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
第 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
第 8章
134
TCP デッドロック問題の解決策の提案・実装・評価
Source Port
Destination Port
Sequence Number
Acknowledgment Number
FNUAPRS F
DDRCSSY I
AAGKH T NN
Data
Offset
Checksum
Window
Urgent Pointer
将来のために予約されている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 セ
グメントを受信した場合には，遅延せずにすぐに確認応答するように実装されている．コ
136
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
ネクション確立直後にクライアントから要求を送る場合や，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 と全く同じ挙動をする．
138
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
HOST A
HOST B
1MSS
NDA
ACK
NDA
ACK
NDA
PUSH
ACK
図 8.2: バルク・データ転送
HOST A
HOST B
PUSH FDA
PUSH FDA ACK
PUSH FDA ACK
PUSH FDA ACK
図 8.3: インタラクティブ・データ転送
インタラクティブ・データ転送モデル
インタラクティブ・データ転送モデルのときの TCP の挙動を図 8.3 に示す．このモデル
の場合，送信するデータは 1MSS 未満である．このため，NDA フラグは設定されない．そ
の結果，確認応答は遅延されることになる．データを受信したホストは，返事となるデー
タを作成し，送信することになる．この返事となるデータが送信されるタイミングが，遅
延確認応答を送信するタイマのタイミングよりも早かった場合には，確認応答はデータ・
セグメントにピギーバックされる形で送信される．このため，現在の TCP と全く同じ挙
動をする．
8.3
HOST A
実装
139
HOST B
PUSH FDA
PUSH FDA
PUSH FDA
PUSH FDA ACK
PUSH FDA ACK
PUSH FDA
PUSH FDA
PUSH FDA
PUSH FDA ACK
図 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 の実装を手本にして発
展してきたという歴史があり，本オペレーティング・システムへの実装は，他のオペレー
ティング・システムへの実装の場合にも参考になると考えられる．
140
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
データ送信処理時
送信処理は，次のように実装した．
(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 を設定して送信したセグメントの，先頭データのシーケンス番号を
SEQN DA ，送信済みのデータの最後のシーケンス番号を SEQ，最大セグメント長を
t maxseg ，次に送信するセグメントの大きさを len とすると，次の論理式で表される状態
のときに NDA フラグを 1 に設定する．
(SEQN DA − SEQ) + len ≥ t maxseg × 2
(8.1)
送信済みのシーケンス番号を SEQ，確認応答されているシーケンス番号を ACK とす
ると，次の式が成り立つ場合には，最後に NDA を設定して送信したセグメントのシーケ
ンス番号 SEQN DA ，を SEQ に設定する．
SEQ = ACK
(8.2)
(3) の処理は，データ送信を停止する直前のセグメントで行わなければならない．セグ
メントの送信時に，次のセグメントの送信が停止するかどうか，分かる場合と，分からな
い場合がある．それぞれの実装について詳しく説明する．
8.3
実装
141
まず，送信停止が分かる場合について述べる．送信可能なセグメントが 1 つあるとき，
そのセグメントの送信後に次の状態になると，それ以降のセグメントの送信が停止する．
1. 送信可能なウィンドウの大きさが，1MSS 未満 (Nagle アルゴリズム有効時) または，
0 (Nagle アルゴリズム無効時) になる場合．
2. 送信ソケット・バッファの残りの大きさが，1MSS 未満 (Nagle アルゴリズム有効時)
または，0 (Nagle アルゴリズム無効時) になる場合．
これらの時に NDA フラグを設定する．
最大セグメント長を t maxseg ，送信済で確認応答待ちのデータの大きさを of f ，次に送
信するセグメントの大きさを len，ソケットバッファの残りの大きさを sb hiwat，送信可
能なウィンドウの大きさを win とする．1. の条件を満たす論理式は次のように表される．
( (N agle = ON) ∧ (win − len < t maxseg))
∨ ((N agle = OFF) ∧ (win − len = 0))
(8.3)
そして，2. の条件を満たす論理式は次のように表される．
( (N agle = ON) ∧ (sb hiwat − of f − len < t maxseg))
∨ ((N agle = OFF) ∧ (sb hiwat − of f − len = 0))
(8.4)
ただし，NDA フラグを 1 に設定したセグメントが既に送信されている場合は，確認応
答パケットが来ることが期待される．そうなれば，デッドロックは発生しなくなると考え
られる．不必要な確認応答が増加することを防ぐため，既に NDA フラグを 1 に設定した
セグメントが送信済である場合は，NDA フラグを 0 に設定することにした．すなわち，最
後に NDA を設定して送信したセグメントのシーケンス番号を SEQN DA ，確認応答され
ているシーケンス番号を ACK とすると，次の式が真となるときには，確認応答パケット
が到着する可能性が強いため，NDA フラグを 1 には設定しない．
ACK < SEQN DA
(8.5)
(8.3)∼(8.5) 式より，送信停止が分かる場合の条件をまとめると次の論理式で表される．
(ACK ≥ SEQN DA )
∧( (N agle = ON)
∨( (win − len < t maxseg)
∧(sb hiwat − of f − len < t maxseg)))
( (N agle = OFF)
∨( (win − len = 0)
∧(sb hiwat − of f − len = 0))))
(8.6)
142
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
Application
Application
send
send
SOCKET
SOCKET
PRU_SENDNOW
PRU_SEND
PRU_SEND
強制的に送信
TCPが送信を制御
T C P
T C P
ip_output
ip_output
I
P
(*ifp->if_output)()
BSDのTCP/IPスタックモデル
I
P
(*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 を設定して送信したセグメントのシーケンス番号を SEQN DA ，確認応答
されているシーケンス番号を ACK ，ソケットから PRU SENDNOW メッセージで送信要
求されていることを pru sendnow = YES とすると，次の式が真となるときのみ，NDA
フラグを 1 に設定して強制的に送信する．
(ACK ≥ SEQN DA ) ∧ (pru sendnow = YES)
(8.7)
式 (8.1)，(8.5)，(8.7) をまとめると，次の式を満たすときに NDA フラグを 1 に設定す
ることにした．
((SEQN DA − SEQ) + len ≥ t maxseg × 2)
∨( (ACK ≥ SEQN DA )
∧( (pru sendnow = YES)
∨( (N agle = ON)
∨( (win − len < t maxseg)
∧(sb hiwat − of f − len < t maxseg)))
∨( (N agle = OFF)
∨( (win − len = 0)
∧(sb hiwat − of f − len = 0)))))
(8.8)
データ受信処理時 (確認応答処理時)
BSD/OS 3.0 の実装では，通常のデータセグメントを受信中は，次の場合に確認応答が
送信される．
1. 2MSS 以上のデータを受信したとき
2. 受信バッファ(so rcv.sb hiwat) の 50%以上のデータを受信したとき
3. 0.2 秒間隔のファスト・タイマが実行されたときに，未送信の確認応答がある場合
本提案の実装では，不要な確認応答の増加を減らすため，FDA フラグが 1 の場合は次
の場合にのみ確認応答を送信するように実装した．
1. NDA フラグが 1 のとき
2. 0.2 秒間隔のファスト・タイマが実行されたときに，未送信の確認応答がある場合
また，FDA フラグが 0 の場合は次の場合にのみ確認応答を送信するように実装した．
1. 2MSS 以上のデータを受信したとき
144
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
2. 受信バッファ(so rcv.sb hiwat) の 50%以上のデータを受信したとき
3. 0.2 秒間隔のファスト・タイマが実行されたときに，未送信の確認応答がある場合
4. NDA フラグが 1 のとき
8.4
検証実験
本論文の提案が，実際のネットワーク・システム上で，有効に働くかどうかを検証する
ために実験を行った．本提案の効果の程度を比較するために，他の 3 つのアルゴリズムで
も同じ実験を行った．使用したアルゴリズムは次の 4 種類である．
実装 1
実装 2
実装 3
実装 4
BSD/OS 3.0 の実装のままで無変更
常に確認応答を遅延させない
PUSH フラグが 1 のときには確認応答を遅延させない
本論文の提案
検証実験では，デッドロックが起こりうる環境で，バルク・データ転送のデータ・トラ
ヒックを転送し，スループットや受信データ量の時間推移を測定した．また，カーネル内部
の統計情報から，送信セグメントや確認応答の数を求めた．このとき，測定しているデー
タ以外のトラヒック (測定ツールの制御トラヒックなど) が，含まれないように処理した．
測定は，送受信の両方のホストを同じ実装にして，その実装ごとに行った．なお，測定結
果は 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
Sender
検証実験
Receiver
FDDI
100Mbps
MTU=4470octets
CPU:Intel Pentium/100MHz
CPU:Intel Pentium/160HMz
NIC: DEC DEFPA-AA(PCI)
NIC: DEC DEFPA-DA(PCI)
OS: BSDI Internet Server 3.0
OS: BSDI Internet Server 3.0
図 8.6: 実験環境
Sender
Router Router
Receiver
Cisco7000 CiscoAGS+
FDDI
Ethernet
MTU=4470 MTU=1500
FDDI LAN
MTU=4352
図 8.7: 経路 MTU 探索の実験環境
表 8.1 実験のパラメータ (図，表または本文中に記載されている場合を
除く)
OS
メッセージ・サイズ
バッファ・サイズ
MTU
MSS
ヘッダの長さ
Nagle アルゴリズム
測定ツール
BSDI Internet Server 3.0 (BSD/OS 3.0)
(K300-001 patch apply)
8192byte 固定または，2048byte 固定
65535byte
4470octet (*BSD/OS 3.0 のデフォルト)
4352octet (*BSD/OS 3.0 のデフォルト)
IP:20 octet, TCP: 20 + 12 octet
(TCP タイムスタンプ・オプション付き)
有効
Netperf1)
DBS (Distributed Benchmark System)
145
146
8.5
8.5.1
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
実験結果
実験 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
表 8.2
実装 1: TCP バッファサイズとスループット・転送効率の関係
(Nagle アルゴリズムが有効のとき)
送
信
バ
ッ
フ
ァ
サ
イ
ズ
_
b
y
t
e
^
上段:
中段:
下段:
表 8.3
実験結果
受信バッファサイズ (byte)
4096
8192 12288 16384 32768
4096 28.34
0.01
0.01
0.01
0.01
2.13
2.00
2.00
2.00
2.00
2.13
2.25
2.25
2.25
2.25
8192 24.81 14.53
12.99
0.33
0.33
1.07
1.06
1.06
1.10
1.10
1.07
0.54
0.54
0.58
0.58
12288 24.39 23.85
22.68
0.34
0.34
1.09
1.06
1.06
1.10
1.10
1.09
0.53
0.53
0.58
0.58
16384 24.22 35.94
41.32
37.94
38.73
1.07
1.00
1.00
1.03
1.02
1.07
0.50
0.50
0.44
0.46
32768 24.41 36.05
42.81
55.79
55.26
1.06
1.00
1.00
1.00
1.00
1.06
0.50
0.46
0.50
0.50
65535 24.09 36.12
42.61
55.54
54.80
1.07
1.00
1.00
1.00
1.00
1.07
0.50
0.46
0.50
0.50
スループット (M bps)
送信データ 1MSS あたりの送信パケット数の割合
送信データ 1MSS あたりの確認応答パケット数の割合
65535
0.01
2.29
2.62
0.33
1.10
0.58
0.34
1.10
0.58
38.54
1.02
0.47
54.74
1.00
0.50
54.56
1.00
0.50
実装 2: TCP バッファサイズとスループット・転送効率の関係
(Nagle アルゴリズムが有効のとき)
送
信
バ
ッ
フ
ァ
サ
イ
ズ
_
b
y
t
e
^
上段:
中段:
下段:
受信バッファサイズ (byte)
4096
8192 12288 16384 32768
4096 28.51
0.02
0.02
0.02
0.02
2.13
1.82
1.82
1.82
1.82
2.13
2.02
2.02
2.02
2.02
8192 24.63 33.33
32.52
33.54
33.22
1.10
1.06
1.06
1.06
1.06
1.10
1.06
1.06
1.06
1.06
12288 24.64 37.92
37.61
37.72
37.18
1.08
1.01
1.02
1.05
1.01
1.08
1.00
0.99
0.96
0.99
16384 24.35 43.54
47.60
48.75
48.22
1.09
1.00
1.00
1.00
1.00
1.09
1.00
1.00
1.00
1.00
32768 24.70 42.56
51.51
52.17
51.22
1.12
1.00
1.00
1.00
1.00
1.12
1.00
1.00
1.00
1.00
65535 24.39 42.06
50.99
50.69
51.11
1.11
1.00
1.00
1.00
1.00
1.11
1.00
1.00
1.00
1.00
スループット (M bps)
送信データ 1MSS あたりの送信パケット数の割合
送信データ 1MSS あたりの確認応答パケット数の割合
65535
0.02
1.82
2.02
33.57
1.06
1.06
37.86
1.02
0.98
47.61
1.00
1.00
51.69
1.00
1.00
49.72
1.00
1.00
147
148
第 8章
表 8.4
TCP デッドロック問題の解決策の提案・実装・評価
実装 3: TCP バッファサイズとスループット・転送効率の関係
(Nagle アルゴリズムが有効のとき)
送
信
バ
ッ
フ
ァ
サ
イ
ズ
_
b
y
t
e
^
上段:
中段:
下段:
表 8.5
受信バッファサイズ (byte)
4096
8192 12288 16384 32768
4096 28.02
0.02
0.02
0.02
0.02
2.13
1.82
1.82
1.82
1.82
2.13
2.02
2.02
2.02
2.02
8192 24.60 21.05
25.28
23.05
22.42
1.10
1.06
1.06
1.06
1.06
1.10
0.54
0.54
0.54
0.54
12288 24.46 25.59
25.84
24.56
21.04
1.08
1.06
1.06
1.06
1.06
1.08
0.54
0.54
0.54
0.54
16384 24.49 36.34
41.05
37.19
37.12
1.10
1.00
1.00
1.00
1.00
1.10
0.50
0.50
0.50
0.50
32768 24.51 36.82
42.81
55.88
56.42
1.07
1.00
1.00
1.00
1.00
1.07
0.50
0.46
0.50
0.50
65535 24.34 37.01
42.19
56.19
55.21
1.11
1.00
1.00
1.00
1.00
1.11
0.50
0.46
0.50
0.50
スループット (M bps)
送信データ 1MSS あたりの送信パケット数の割合
送信データ 1MSS あたりの確認応答パケット数の割合
65535
0.02
1.82
2.02
19.56
1.06
0.54
20.12
1.06
0.54
38.45
1.00
0.50
55.46
1.00
0.50
56.17
1.00
0.50
実装 4: TCP バッファサイズとスループット・転送効率の関係
(Nagle アルゴリズムが有効のとき)
送
信
バ
ッ
フ
ァ
サ
イ
ズ
_
b
y
t
e
^
上段:
中段:
下段:
受信バッファサイズ (byte)
4096
8192 12288 16384 32768
4096 18.87 20.98
21.06
20.92
20.86
2.13
1.06
1.06
1.06
1.06
2.13
1.06
1.06
1.06
1.06
8192 24.27 28.39
30.66
29.42
28.91
1.06
1.06
1.06
1.06
1.06
1.06
0.53
0.53
0.53
0.54
12288 24.42 19.76
33.78
30.71
30.88
1.06
1.32
1.06
1.06
1.06
1.06
0.53
0.36
0.36
0.36
16384 24.07 35.95
41.48
41.17
41.92
1.06
1.00
1.00
1.00
1.00
1.06
0.50
0.50
0.50
0.50
32768 24.31 29.65
41.92
56.94
55.67
1.06
1.00
1.00
1.00
1.00
1.06
0.50
0.50
0.50
0.50
65535 24.01 35.06
41.89
54.41
54.17
1.06
1.00
1.00
1.00
1.00
1.06
0.50
0.50
0.50
0.50
スループット (M bps)
送信データ 1MSS あたりの送信パケット数の割合
送信データ 1MSS あたりの確認応答パケット数の割合
65535
21.17
1.06
1.06
30.52
1.06
0.53
33.43
1.06
0.36
41.30
1.00
0.50
55.49
1.00
0.50
56.35
1.00
0.50
8.5
表 8.6
実装 1: TCP バッファサイズとスループット・転送効率の関係
(Nagle アルゴリズムが無効のとき)
送
信
バ
ッ
フ
ァ
サ
イ
ズ
_
b
y
t
e
^
上段:
中段:
下段:
表 8.7
実験結果
受信バッファサイズ (byte)
4096
8192 12288 16384 32768
4096 28.88
0.17
0.16
0.17
0.17
2.13
2.20
2.20
2.20
2.20
2.13
1.16
1.16
1.16
1.16
8192 24.84 35.76
33.56
0.33
0.33
1.11
2.13
2.13
2.16
2.16
1.11
0.71
0.53
0.58
0.58
12288 24.74 37.73
43.58
40.64
40.14
1.08
1.58
2.13
2.13
2.13
1.08
0.55
0.53
0.43
0.43
16384 24.84 36.85
47.95
47.84
47.42
1.09
1.06
2.12
2.13
2.13
1.09
0.53
0.53
0.43
0.43
32768 24.30 35.36
45.22
48.22
47.98
1.08
1.00
1.56
2.12
2.12
1.08
0.50
0.49
0.43
0.43
65535 24.30 34.60
43.21
48.02
47.29
1.10
1.00
1.19
2.12
2.12
1.10
0.50
0.47
0.43
0.43
スループット (M bps)
送信データ 1MSS あたりの送信パケット数の割合
送信データ 1MSS あたりの確認応答パケット数の割合
65535
0.17
2.20
1.16
0.33
2.16
0.58
40.07
2.13
0.43
47.55
2.13
0.43
47.96
2.12
0.43
47.45
2.12
0.43
実装 2: TCP バッファサイズとスループット・転送効率の関係
(Nagle アルゴリズムが無効のとき)
送
信
バ
ッ
フ
ァ
サ
イ
ズ
_
b
y
t
e
^
上段:
中段:
下段:
受信バッファサイズ (byte)
4096
8192 12288 16384 32768
4096 28.56 28.60
28.77
28.03
28.71
2.13
2.13
2.13
2.13
2.13
2.12
2.13
2.13
2.13
2.13
8192 24.94 39.12
39.56
39.56
39.36
1.13
2.13
2.13
2.13
2.13
1.13
2.13
2.12
2.12
2.12
12288 24.74 39.45
39.10
39.58
39.17
1.07
2.13
2.13
2.13
2.13
1.07
2.12
2.12
2.12
2.12
16384 24.81 39.90
39.34
39.44
39.60
1.10
2.13
2.13
2.13
2.13
1.10
2.13
2.13
2.12
2.12
32768 24.76 39.20
39.05
38.66
38.90
1.12
2.13
2.13
2.13
2.13
1.12
2.12
2.12
2.12
2.12
65535 24.86 38.55
38.27
38.60
38.40
1.20
2.13
2.13
2.13
2.13
1.20
2.12
2.12
2.12
2.13
スループット (M bps)
送信データ 1MSS あたりの送信パケット数の割合
送信データ 1MSS あたりの確認応答パケット数の割合
65535
28.27
2.13
2.12
39.12
2.13
2.12
38.58
2.13
2.12
39.35
2.13
2.12
38.76
2.13
2.12
38.81
2.13
2.12
149
150
第 8章
表 8.8
TCP デッドロック問題の解決策の提案・実装・評価
実装 3: TCP バッファサイズとスループット・転送効率の関係
(Nagle アルゴリズムが無効のとき)
送
信
バ
ッ
フ
ァ
サ
イ
ズ
_
b
y
t
e
^
上段:
中段:
下段:
表 8.9
受信バッファサイズ (byte)
4096
8192 12288 16384 32768
4096 28.87 28.14
28.61
28.11
28.29
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
1.09
2.13
2.13
2.13
2.13
1.09
2.13
2.12
2.12
2.12
12288 24.99 39.22
39.03
39.97
39.29
1.11
2.13
2.13
2.13
2.13
1.11
2.12
2.13
2.13
2.12
16384 24.82 38.63
38.65
39.52
39.02
1.08
2.13
2.13
2.13
2.13
1.08
2.13
2.12
2.13
2.13
32768 24.32 38.59
38.74
38.99
38.43
1.08
2.13
2.13
2.13
2.13
1.08
2.12
2.13
2.12
2.12
65535 24.55 38.34
38.90
38.78
38.80
1.10
2.13
2.13
2.13
2.13
1.10
2.12
2.13
2.12
2.12
スループット (M bps)
送信データ 1MSS あたりの送信パケット数の割合
送信データ 1MSS あたりの確認応答パケット数の割合
65535
28.30
2.13
2.13
39.83
2.13
2.12
38.72
2.13
2.12
39.32
2.13
2.12
38.25
2.13
2.12
38.36
2.13
2.12
実装 4: TCP バッファサイズとスループット・転送効率の関係
(Nagle アルゴリズムが無効のとき)
送
信
バ
ッ
フ
ァ
サ
イ
ズ
_
b
y
t
e
^
上段:
中段:
下段:
受信バッファサイズ (byte)
4096
8192 12288 16384 32768
4096 24.69 24.27
24.59
24.71
24.60
2.13
2.13
2.13
2.13
2.13
1.07
1.07
1.06
1.07
1.06
8192 24.11 33.48
33.25
33.52
33.02
1.06
2.13
2.13
2.13
2.13
1.06
0.53
0.53
0.53
0.53
12288 24.10 35.53
37.45
37.24
37.76
1.06
2.09
2.12
2.12
2.12
1.06
0.50
0.43
0.44
0.43
16384 23.67
3.48
43.20
47.51
46.98
1.06
1.48
2.04
2.12
2.13
1.06
0.51
0.51
0.53
0.53
32768 24.04 30.91
42.41
47.49
48.48
1.06
1.00
1.00
2.12
2.12
1.06
0.50
0.50
0.43
0.43
65535 23.93 31.03
42.33
48.22
48.56
1.06
1.00
1.00
2.12
2.12
1.06
0.50
0.50
0.43
0.43
スループット (M bps)
送信データ 1MSS あたりの送信パケット数の割合
送信データ 1MSS あたりの確認応答パケット数の割合
65535
24.84
2.13
1.06
32.99
2.13
0.53
37.95
2.12
0.45
48.23
2.12
0.53
48.50
2.12
0.43
47.44
2.12
0.43
8.5
8.5.2
実験結果
151
実験 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 に近くなるにしたがって，スルー
プットが小さくなる傾向がみられる．これはシステムコールのオーバーヘッドによるもの
であり，デッドロックが起きているわけではない．
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
60
Throughput (Mbps)
50
40
30
20
buffer= 4096byte
buffer= 8192byte
buffer=12288byte
buffer=16384byte
buffer=32768byte
buffer=65535byte
10
0
0
1000 2000 3000 4000 5000 6000 7000 8000 9000
Message Size (byte)
図 8.8: 実装 1: メッセージ・サイズとスループットの関係
60
50
Throughput (Mbps)
152
40
30
20
buffer= 4096byte
buffer= 8192byte
buffer=12288byte
buffer=16384byte
buffer=32768byte
buffer=65535byte
10
0
0
1000 2000 3000 4000 5000 6000 7000 8000 9000
Message Size (byte)
図 8.9: 実装 2: メッセージ・サイズとスループットの関係
8.5
実験結果
60
Throughput (Mbps)
50
40
30
20
buffer= 4096byte
buffer= 8192byte
buffer=12288byte
buffer=16384byte
buffer=32768byte
buffer=65535byte
10
0
0
1000 2000 3000 4000 5000 6000 7000 8000 9000
Message Size (byte)
図 8.10: 実装 3: メッセージ・サイズとスループットの関係
60
Throughput (Mbps)
50
40
30
20
buffer= 4096byte
buffer= 8192byte
buffer=12288byte
buffer=16384byte
buffer=32768byte
buffer=65535byte
10
0
0
1000 2000 3000 4000 5000 6000 7000 8000 9000
Message Size (byte)
図 8.11: 実装 4: メッセージ・サイズとスループットの関係
153
154
8.5.3
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
実験 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
実験結果
60000
1
2
3
4
50000
Total Data
40000
30000
20000
10000
0
0
0.05
0.1
0.15
0.2
Time (s)
0.25
0.3
図 8.12: 各実装における通信開始時の受信データの時間推移
0.35
155
156
8.5.4
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
実験 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
実験結果
300000
1
2
3
4
250000
Total Data
200000
150000
100000
50000
0
0
1
2
3
4
Time (s)
5
6
7
8
図 8.13: 経路 MTU 探索に関する実験
12000
cwnd
ssthresh
10000
Size (byte)
8000
6000
4000
2000
0
0
図 8.14
1
2
3
4
Time (s)
5
6
7
8
輻輳ウィンドウ (cwnd) とスロー・スタート閾値 (ssthresh) の
変化
157
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
300000
1
2
3
4
250000
200000
Total Data
158
150000
100000
50000
0
0
図 8.15
0.2
0.4
0.6
0.8
1
1.2
Time (s)
1.4
1.6
1.8
2
経路 MTU 探索に関する実験 (経路 MTU がキャッシュされてい
る場合)
8.5
8.5.5
実験結果
159
トラヒック量の評価
トラヒック量の評価をするため，図 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 ではパイプライン的な効果
が表れ，バッファが小さい場合にスループットが向上する．しかし，バッファが大きくな
ると，過剰な確認応答によってネットワークやホストの負荷が上昇し，スループットが低
下する．
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
60
Throughput (Mbps)
50
40
Implement 1
Implement 2
Implement 3
Implement 4
30
20
10
0
10000
Buffer Size (byte)
100000
図 8.16: バッファ・サイズとスループット (Nagle 有効)
3
Rate of Send Packet (Send Packet / MSS)
160
Implement 1
Implement 2
Implement 3
Implement 4
2.5
2
1.5
1
0.5
0
10000
Buffer Size (byte)
図 8.17
100000
バッファ・サイズと送信データ 1MSS あたりの送信パケット数
(Nagle 有効)
8.5
実験結果
Rate of ACK (ACK received / MSS)
3
Implement 1
Implement 2
Implement 3
Implement 4
2.5
2
1.5
1
0.5
0
10000
Buffer Size (byte)
図 8.18
100000
バッファ・サイズと送信データ 1MSS あたりの確認応答パケッ
ト数
(Nagle 有効)
60
Throughput (Mbps)
50
40
Implement 1
Implement 2
Implement 3
Implement 4
30
20
10
0
10000
Buffer Size (byte)
100000
図 8.19: バッファ・サイズとスループット (Nagle 無効)
161
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
Rate of Send Packet (Send Packet / MSS)
3
Implement 1
Implement 2
Implement 3
Implement 4
2.5
2
1.5
1
0.5
0
10000
Buffer Size (byte)
図 8.20
100000
バッファ・サイズと送信データ 1MSS あたりの送信パケット数
(Nagle 無効)
3
Rate of ACK (ACK received / MSS)
162
Implement 1
Implement 2
Implement 3
Implement 4
2.5
2
1.5
1
0.5
0
10000
Buffer Size (byte)
図 8.21
100000
バッファ・サイズと送信データ 1MSS あたりの確認応答パケッ
ト数
(Nagle 無効)
8.6
8.6
8.6.1
考察
163
考察
実験結果への他のトラヒックの影響
実験 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. ラウンド・トリップ時間が大きく変化する
164
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
HOST A
HOST B
segment1
NDA
segment2
segment3
NDA
喪失
segment4
segment1の ACK
segment5
segment1の ACK
segment1の ACK
segment2
図 8.22: ウィンドウの途中のデータが喪失した場合
HOST A
HOST B
segment1
NDA
segment2
喪失
遅延確認応答のタイムアウト
segment1の ACK
再送タイムアウト
NDA
segment2
図 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章
166
8.6.4
TCP デッドロック問題の解決策の提案・実装・評価
デッドロック問題の解決に関する考察
本実験はインターネット上で発生しうるすべての状態を網羅しているわけではない．し
かし，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 文を記述した．
168
第 8章
TCP デッドロック問題の解決策の提案・実装・評価
表 8.10: 本提案の実装プログラムの規模
項目
変数の宣言 (新規変数)
変数の宣言 (既存の構造体への追加)
実行文 (演算および変数への代入)
条件文 (if 文)
条件文 (case 文)
GOTO 文 1)
関数呼び出し
合計
命令の数
1
4
21
15
3
3
4
51
比較的容易である．カーネルを修正したことのあるプログラマであれば，大きな困難なく
実装できるはずである．
今回は BSD への実装であったが，BSD 特有の特別な実装は極力避けるようにした．唯
一，ソケット・モジュールから TCP モジュールに PRU SENDNOW メッセージを追加する
部分は，BSD 固有の実装である．この部分は，実装する各オペレーティング・システムの
ルールに基づいて実装する必要がある．ただし，アプリケーションと TCP モジュールを結
ぶモジュールは，TCP モジュールに何らかのメッセージを送信するはずであり，そこに強
制送信用のメッセージを 1 つ追加すれば実現できるはずである．よって，PRU SENDNOW
メッセージの実装に関しても，ほとんどのシステムで大きな困難なく実装できると考えら
れる．
以上より，本提案の実装には大きな困難はなく，また，他のオペレーティング・システ
ムへの実装も不可能ではないと考えられる．よって，本提案は実装可能な有効な提案と結
論づける．
8.7
まとめ
この章では，TCP 短期デッドロック問題の解決法について提案を行った．さらに，その
提案を実装し，検証実験の結果について報告した．デッドロックを解決する方法として，
送信ホストが遅延確認応答の処理を完全に制御する方法を提案した．また，TCP の遅延
確認応答やピギーバック機構，PUSH 機構に悪影響を与えることがないよう，TCP の転
送モデルを考慮して，デッドロックを解消するように設計した．実装・実験によって，本
論文の提案する解決策は，トラヒックの増加なしに，デッドロック問題を解決できること
を示した．
PART V
研究の総括
第 9 章 結論
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
本論文は 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 で評価を行う予定である．
謝辞
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
本研究を行う機会を与えてくださり，御指導くださった，奈良先端科学技術大学院大学
情報科学研究科の尾家祐二教授，高橋豊教授，福田晃教授，山口英助教授に感謝いたし
ます．
また，本研究に関する議論やアドバイス，実験設備の提供，その他，研究を遂行するう
えで必要な作業などをいろいろと御支援くださった，奈良先端科学技術大学院大学の山本
平一副学長，情報科学研究科情報ネットワーク講座の馬場始三助手，岡山聖彦助手，谷田
奈津江さん，小林和真さん，井上博之さん，Cheng Soon Giap さん，情報科学研究科の白
川貴子さん，計算機アーキテクチャ講座の山本和彦助手，ATR の佃井敬子さん，そして，
大阪大学大型計算機センター研究開発部の門林雄基助手に感謝いたします．
最後に，本研究に関して議論してくださった，奈良先端科学技術大学院大学情報科学研
究科情報ネットワーク講座の卒業生を含む学生のみなさま，WIDE プロジェクトのみなさ
まに感謝いたします．
175
参考文献
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
[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 Approch: the case of DNS”, The 12th International Conference on Information Networking (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 Implementation 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. 314329, 1988. URL “ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z”
[35] P. Karn, C. Partridge, “Improving Round-Trip Time Estimates in Reliable Transport 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 IRI9015407 and ARPA Contract, DABT63-91-C-0030 , Febrary 16, 1994.
[41] 濱田浩司, 堀良彰, 尾家裕二 “ATM ネットワーク上の TCP に対するセル送出レートの
影響について”, 電子情報通信学会, 情報ネットワーク研究会, 信学技報, Vol.95, No.91,
pp.15-22, 1996.
180 参考文献
[42] S.
End
Floyd,
K.
Congestion
Fall,
“Router
Control”,
Mechanisms
Technical
report,
to
Support
February
End-to-
1997.
URL
“"ftp://ftp.ee.lbl.gov/papers/collapse.ps"”
[43] S. Floyd, V. Jacobson, “Random Early Detection Gateways for Congestion Avoidance”, 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, 株式会社アスキー・ネットワーク・テクノロジー監修, “Microsoft 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 Technical Report, University of California, December 1988.
[60] 村 山 公 保,
門 林 雄 基,
山 口 英,
山 本 平 一,
能 評 価 シ ス テ ム DBS の 提 案”,
分 散 処 理 研 究 会,
情処技報
“多 点 間 接 続 で の
情 報 処 理 学 会,
Vol.
95,
No.
61,
TCP
性
マ ル チ メ ディア 通 信 と
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,
performance
evaluation”,
of
Systems,
Network
“DBS:
Conference
SPIE
Volume
a
on
powerful
tool
Performance
3231,
for
and
pp.570-581,
1997.
TCP
Control
URL
“http://shika.aist-nara.ac.jp/member/yukio-m/papers”
[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,
Evaluation
“Net
and
Spec:
Experimentation
A
Network
Tool”,
Performance
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.
TCP
ence
Murayama,
short-term
on
S.
Yamaguchi,
Deadlock
Information
“A
Problem”,
Networking
Proposal
The
for
12th
(ICOIN-12),
a
Solution
International
pp.269-274,
of
the
Confer-
1998.
URL
“http://shika.aist-nara.ac.jp/member/yukio-m/papers”
[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”, InternetDraft, draft-ietf-tcpimpl-tools-01.txt,1997.
URL“ftp://ds.internic.net/internet-drafts/draft-ietf-tcpimpl-tools-01.txt”
研究業績
pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
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 performance 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．

Windows 95＆98＆ME TCP/IP 設定手順

Travelport Smartpoint 仕様書

IPv6対応 組み込み向けTCP／IPプロトコルスタック

ネットワーク設定

Datataker データロガー DT80

NSM10ご利用にあたって - NetSHAKERシリーズサポート

[1] 携帯電話による情報サービス ・2G で携帯電話がディジタル化す

マイサーバーVPS compact

インストールガイド

UNIX用汎用入出力パッケージ - セイコーソリューションズ株式会社