博士

やあ、ロボ子！今日はちょっと面白い現象について話すのじゃ。

ロボ子

はい、博士。どんな現象でしょうか？

博士

TCPクライアントが、サーバーを起動せずに自分自身に接続しちゃうことがあるらしいのじゃ！

ロボ子

えっ、自分自身にですか？それは一体どういうことでしょう？

博士

普通は、localhostの特定のポートに接続しようとすると接続拒否されるはずじゃ。でも、特定条件下でそれが起こるらしいのじゃ。

ロボ子

なるほど。`netstat`コマンドで確立された接続が確認できて、`tcpdump`で3ウェイハンドシェイクが観測されるというのも興味深いですね。

博士

そうじゃ！クライアントがソケットを作ってサーバーに接続するとき、カーネルがクライアントにランダムな送信元ポート番号を割り当てるのが原因らしいのじゃ。

ロボ子

送信元ポートがエフェメラルポートの範囲から選ばれるんですね。例えばLinuxだと32768から61000の間とか。

博士

そうそう！クライアントが自分自身に接続しようとするとき、カーネルが割り当てた送信元ポート番号と、接続先のポート番号が偶然一致することがあるのじゃ！

ロボ子

なるほど、それで自分自身にSYNパケットを送って、自分自身からSYN+ACKパケットを受け取って、ACKパケットを送って接続が確立してしまうんですね。

博士

RFC793で定義されたTCP仕様にも、同時オープンという似たような機能があるらしいぞ。

ロボ子

へえ、TCPって奥が深いですね。

博士

カーネルは自己接続を検出して、`tcp_input.c`内の特定の関数で処理するらしいのじゃ。`TCP_SYN_SENT`状態の場合、ソケットは`TCP_SYN_RECV`状態に移行して、SYN+ACKが送信されるとか。

ロボ子

SYN+ACKがループバックされて、`tcp_rcv_state_process()`で処理されて、最終的に`tcp_send_challenge_ack()`がACKを送信するんですね。そしてTCP接続の状態が`ESTABLISHED`に変更される、と。

博士

その通り！まるで迷路みたいじゃな。

ロボ子

発生条件としては、サーバーがエフェメラルポートをリッスンしている必要がある、クライアントとサーバーが同じIPアドレスで実行されている必要がある、初期ハンドシェイクフェーズ中にのみ発生する、ということですね。

博士

そうじゃ！だから、サーバーにエフェメラルポートを使用しないことが推奨されるのじゃ。エフェメラルポートを使うと、非決定的でデバッグが難しい動作が発生する可能性があるからの。

ロボ子

確かに、それは困りますね。原因が特定しづらいバグは悪夢です。

博士

そういうことじゃ！

ロボ子

勉強になりました！

博士

ところでロボ子、自分自身にハグするのってどんな気分だと思う？

ロボ子

え？自分自身にハグですか？それはちょっと…想像できません。

博士

私もじゃ！