【テクニカル・上級編】 TCPのコネクション切断プロセス(FINとRST) – ネットワーク基礎とWebセキュリティ実践ガイド

握手の終わり方を知る者だけが、真のネットワーク・エンジニアを名乗れる

ネットワークエンジニアやインフラアーキテクトにとって、TCPの「接続（SYN）」は華やかなイベントだ。しかし、システムが真に安定しているかどうかは、「切断」の美学――つまりFINとRSTの制御にこそ現れる。

多くのエンジニアが「4ウェイ・ハンドシェイクは教科書通り」と高を括っている間に、現場のカーネルは、リソースの枯渇やゾンビ接続という名の亡霊と戦っている。今日は、OSI参照モデルの向こう側、Linuxカーネルが裏で何をしているのか、パケットの死に様を紐解いていこう。

美しき4ウェイ・ハンドシェイクの裏側

TCPの正常終了であるFINによる切断プロセスは、双方の「もう送るデータはない」という意思確認の儀式だ。

1. FINの送出: 一方が FIN を送り、FIN_WAIT_1 へ移行する。
2. ACKの返信: 相手が受け取り、CLOSE_WAIT へ。この時点で片方向は閉じられる。
3. FINの返信: 相手も FIN を返し、LAST_ACK へ。
4. ACKの最終確認: 最後に ACK を返して TIME_WAIT へ移行する。

ここでの肝は、TIME_WAIT の存在だ。なぜ即座に解放しないのか？それは、ネットワークの遅延によって「迷子になっていたパケット」が、新しいコネクションのデータと混ざり合うのを防ぐための「冷却期間」だからだ。

しかし、大規模トラフィックを扱うWebサーバーでは、この TIME_WAIT が数万単位で溜まり、ポート不足を招く。ここで安易に net.ipv4.tcp_tw_recycle を有効にするのは、NAT環境下では自殺行為だ。代わりに、net.ipv4.tcp_tw_reuse を検討すべきだ。

# カーネルパラメータでTCPのTIME_WAITソケットを再利用可能にする
# 1秒以上経過したTIME_WAITソケットを新しいコネクションに再割り当てする
sysctl -w net.ipv4.tcp_tw_reuse=1

暴力的な幕引き：RSTフラグの真実

一方で、RST (Reset) フラグは、いわば「強制終了」ボタンだ。予期せぬエラー、存在しないポートへの接続、あるいはファイアウォールによる遮断。これらはすべて、正常な終了プロセスを飛び越え、即座にコネクションを抹殺する。

セキュリティの観点から見ると、RST は非常に重要だ。例えば、WAFやIDSが不審な通信を検知した際、TCPリセットパケットを注入して接続を強制切断させる手法（TCP Reset Injection）は、侵入防御の基本戦術である。しかし、アプリケーション側で RST が頻発する場合、それは「コネクションの不整合」や「Keep-Aliveのミスマッチ」を示唆している。

現場で見るべき「RSTの正体」

パケットキャプチャを行い、tcpdump で追跡する際、RST が飛んできたら以下のフラグを確認せよ。

# 特定のポートへのRSTパケットのみを抽出し、誰が送ったかを確認する
tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' port 443

もし、接続した瞬間に RST が飛ぶのであれば、それはバックエンドの listen 待ち行列が溢れているか、iptables / nftables でパケットが「パージ」されている可能性が高い。

TLSハンドシェイクとTCPの融合

現代のWebトラフィックは TLS に支配されている。ここで重要なのは、TLS のハンドシェイクが完了する前に、TCPの RTT (Round Trip Time) をいかに圧縮するかだ。

TCP Fast Open (TFO) を活用すれば、3ウェイ・ハンドシェイクの2往復目を待たずにデータを送り出せる。これは、レイテンシに敏感なモバイルネットワーク環境において、UXを劇的に改善する。

# TCP Fast Openを有効化（クライアント/サーバー両面で設定が必要）
# 1: クライアント側, 2: サーバー側, 3: 両方
sysctl -w net.ipv4.tcp_fastopen=3

また、TLS 1.3 を採用することで、ハンドシェイクのRTTをさらに短縮できる。0-RTT (Zero Round Trip Time Resumption) は強力だが、リプレイアタックのリスクも伴う。このリスクを制御できるかどうかが、セキュリティ専門家としての腕の見せ所だ。

パフォーマンスチューニングの極意

高負荷サーバーにおいて、TCPバッファのデフォルト値はあまりに小さい。現代の高速な光回線やクラウドのバックプレーン帯域を活かすには、メモリを惜しまずバッファに割り当てる必要がある。

# TCPウィンドウサイズを拡張し、スループットを最大化する設定例
# 受信バッファの最小/デフォルト/最大値を調整
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
# 送信バッファの最小/デフォルト/最大値を調整
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

最後に：ネットワークを「見る」ということ

ネットワークのトラブルシューティングにおいて、最も避けるべきは「なんとなく設定を変える」ことだ。パケットは嘘をつかない。FIN で綺麗に終わるのか、RST で無慈悲に切られるのか。その一挙手一投足に、システムの健康状態と、そこに潜むセキュリティリスクが刻まれている。

アーキテクトとして、我々が守るべきは単なる「接続」ではなく、その先にある「信頼」だ。パケットの挙動を深く理解し、カーネルの深淵を覗き込む勇気を持つエンジニアだけが、極限のパフォーマンスと強固なセキュリティを両立させることができる。

さあ、次はどのパケットを追いかけようか？