>>235
文書 "RFC 739" 内の図 "Figure 6. TCP Connection State Diagram" は
参照されていると思います。(もし見ていなければ開いてください)

この図の中央に状態 [ESTAB(コネクション確立中)] があります。
この状態でソケットから事象 "CLOSE" を受け付けると、
(TCPスタックは)IPスタック(=クライアント)へ事象 "snd FIN(FINパケットの送信)" を要求し、
(図の左下側にある)状態 [FIN WAIT-1(コネクション解放待ち(1)] へ遷移します。

ここでソケットからの事象 "CLOSE" は、実際にはshutdownかもしれませんし、
(>>216で「closeをいきなり呼んでも暗黙的にこの処理は行なわれる」とあるように)
いきなりのcloseかもしれないし、あるいは(プロセスのexitに伴う)カーネル内部の
close操作かもしれません。そこは実装に依存するのでRFCでは抽象的に記述されています。

で、状態 [FIN WAIT-1(コネクション解放待ち(1)] においては、IPスタック(=クライアント)から
事象 "rcv ACK of FIN(FINに対するACKパケットを受信)"、
あるいは事象 "rcv FIN(FINパケット受信)" を受け付けない限り、
(永遠に)次の状態へは進めない(遷移できない)ことが確認できるのではないかと思います。
これが「(質問>>232にある)鯖側のソケットをclose()しても残ったまま」になる状況(の一例)です。

眠いんで、今晩はこれで落ちます。