18.6 TCP状態遷移ダイアグラム

1

18.6 TCP状態遷移ダイアグラム

2 正当だが、バークレー系ではサポートされていない

同時オープンでない場合は正当(クライアントからリセットを受け取った場合)

2MSL待ち状態

3

最大セグメント寿命 (MSL)

ネットワーク上でセグメントが破棄されるまでに存在できる最大の時間量

RFC793では2分だが、実際には30秒・1分・2分など多様

アクティブクローズ実行後は TIME_WAIT でMSL2回分待機する

＊  最後のACKが消失した場合でも再度ACKを送れる＊  同一ポート番号の新しいコネクションへの古いセグメントの紛れ込みを防ぐ

2MSL待ち状態

4

通常はクライアント側の話なので問題ないが、サーバ側だとポートがAlready in useとなる

SO_REUSEADDRオプションでポート番号の再利用はできるが、ソケットペアが2MSL待ちにあるとアクティブ・オープンでエラーとなる

バークレー系実装では、ソケットペアが2MSL待ち状態でも他のホストからの接続だとエラーにならない

前のコネクションの最終シーケンス番号より大きいシーケンス番号による接続は受け入れる

沈黙時間・FIN_WAIT_2状態

5

ハーフ・クローズでない場合はFIN_WAIT_2で相手からのFINを待つ

相手からのFINがなければ永遠にFIN_WAIT_2にとどまり得る

バークレー系実装では、完全なクローズを行う場合はタイマーをセットして強制クローズを行う

ホストのクラッシュ時にはMSL時間以内に新しいコネクションを確立してしまう可能性が考えられる

RFC793ではホストの再起動後MSLの間はTCPコネクションを確立しないように定められている

殆どの場合はMSLの時間より再起動にかかる時間のほうが長い

18.7 リセット・セグメント

6

ソケットに対して正しくないセグメントが到着した時に送られる

宛先ポートにプロセスが待機していない場合

UDPにおけるICMPポート到達不可の代わりにリセットが用いられる

シーケンス番号は0確認応答番号は ( 受信ISN + セグメントのデータ・バイト数 )

コネクションを中断する�ハーフ・オープン・コネクションを検知する

7

正規リリース

FIN送る通常のコネクション終了

中断リリース

リセットを送ってコネクションを中断する場合

リセットセグメントは他方のエンドから何の応答も引き出さない

一方のエンドが他方のエンドに知らせずに終了・中断した場合データの転送が行われない限りクラッシュは検知されない

ハーフ・オープン

クラッシュしたホストが再起動されている場合はコネクションが確立されていないため、次に送られたセグメントに対してリセットで応える

18.8 同時オープン

8

2つのアプリケーションが同時にアクティブ・オープンを実行する場合

各エンドは双方のエンドに対してウェルノウンポートを持つ必要がある

双方がクライアントであると同時にサーバーとしても機能している

同時クローズ

9

双方のエンドからアクティブ・クローズを行う場合

18.10 TCPオプション

10

オリジナルのTCP仕様で定義

NOPは4バイト境界にするためのパッドとして用いられる

TCPサーバー設計

11

TCPサーバでは並行処理を行うためにさまざまなテクニックがある

＊  fork関数を用いて新しいプロセスを生成する＊ スレッドを用いる

サーバは同じポート上でTCPコネクションを受け付けることができるが、クライアントが複数接続を保つ場合はエフェメラルポートを使用する

UDPでは外部IPアドレス・外部ポートを指定できたTCPでも外部ソケットを指定することはできるが、殆どのAPIがその方法を提供していない