【実務・中級編】 TCPフラグビット：SYN, ACK, FIN, RST, PSH, URGのパケット制御における役割 – ネットワーク基礎とWebセキュリティ実践ガイド

はじめに：パケットの「目」を持つということ

Web APIの設計や、コンテナがひしめくクラウドインフラの運用に日夜奔走しているエンジニアの皆さん、こんにちは。

「APIから突然 Connection reset by peer というエラーが返ってきた」
「ロードバランサーの裏側で、なぜかコネクションが宙ぶらりんになっている」

こうした障害に直面したとき、あなたはどう動きますか？多くの人はアプリケーションログに目を向けがちですが、シニアなインフラエンジニアやセキュリティスペシャリストが真っ先に開くのは、tcpdump や Wireshark のパケットキャプチャ画面です。

OSI参照モデルの第4層、トランスポート層でいぶし銀の働きをするTCP。その挙動のすべてを握っているのが、たった1バイト（正確にはヘッダー内の予約領域を含めた9ビット）のTCPフラグビットです。このフラグたちが、TCPステートマシン（状態遷移）をどのように駆動させ、パケットの運命を決定づけているのか。

今回は、ネットワークの泥臭い実務を知る我々が、RFCの仕様から現場のトラブルシューティングまで、TCPフラグの全貌を徹底的に解き明かしていこう。

—

1. TCPフラグの全体像とステートマシンへの影響

TCPは、信頼性の高い通信を保証するために「ステートフル」なプロトコルとして設計されている。クライアントとサーバーは、現在の通信状態（ESTABLISHED、TIME_WAIT など）を「TCPステートマシン」として厳密に共有しており、その状態を遷移させるトリガーとなるのが、TCPヘッダーに刻まれたフラグたちだ。

まずは、主要な6つのフラグビットの役割を整理しておこう。

これらのフラグが、実世界でどのようにパケットのやり取りを生み出しているのか、具体的な通信フローを見ていこう。

—

2. 通信フロー（シーケンス）の深掘り：確立と切断の裏側

2.1 3ウェイハンドシェイク（コネクション確立）

Web APIを叩くとき、HTTPリクエストが飛ぶ前に、必ずあの有名な3段階の握手が行われている。

Client                                               Server
  |                                                    |
  | ----- [SYN] (Seq=x) -----------------------------> |  CLOSED -> SYN_RECEIVED
  | <---- [SYN, ACK] (Seq=y, Ack=x+1) ---------------- |  
  | ----- [ACK] (Ack=y+1) ---------------------------> |  ESTABLISHED
  |                                                    |

1. 第1ステップ（SYN）: クライアントが SYN フラグを立て、自身の初期シーケンス番号（ISN）を通知する。
2. 第2ステップ（SYN-ACK）: サーバーはそれを受理し、自身の SYN と、クライアントの SYN に対する ACK を同時に返す。
3. 第3ステップ（ACK）: クライアントがサーバーの SYN に対して ACK を返す。これにて両者のステートが ESTABLISHED になり、データの往来が始まる。

ここでセキュリティ上の注意点がある。いわゆる「SYNフラッド攻撃」は、この第1ステップの SYN パケットを大量に送りつけ、サーバー側に SYN_RECEIVED のステートを意図的に大量保持させることでリソースを枯渇させる手法だ。現代のLinuxカーネルでは、net.ipv4.tcp_syncookies などを有効にしてこの脅威をいなしている。

2.2 グレースフル・シャットダウン（4ウェイハンドシェイクとFINの往来）

通信が終わるとき、TCPは綺麗にお片付けをする。これが FIN パケットの仕事だ。

Client                                               Server
  |                                                    |
  | ----- [FIN] -------------------------------------> |  ESTABLISHED -> CLOSE_WAIT
  | <---- [ACK] ------------------------------------- |  FIN_WAIT_2
  | <---- [FIN] ------------------------------------- |  LAST_ACK
  | ----- [ACK] -------------------------------------> |  TIME_WAIT -> CLOSED
  |                                                    |

クライアントとサーバー双方がお互いに FIN と ACK を送り合うことで、双方向の通信チャネルを個別に閉じていく。
ここでインフラエンジニアとして絶対に知っておくべきなのが、最後にクライアント側（あるいは能動的に切断した側）に残る TIME_WAIT ステート だ。

デフォルトでLinuxでは60秒間（2MSL）この状態が維持される。高トラフィックなAPIサーバーで TIME_WAIT が枯渇し、「ポートが足りない」というアラートに悩まされたことがある読者も多いだろう。これを回避するためには、カーネルパラメータの net.ipv4.tcp_tw_reuse の活用や、Keep-Aliveの適切なチューニングが不可欠となる。

—

3. 異常系とパフォーマンス最適化のフラグ：RSTとPSH

3.1 強制切断のシグナル：RSTフラグ

正常な切断（FIN）とは裏腹に、極めて暴力的なのが RST（Reset）フラグだ。
RST パケットを受信した側は、ハンドシェイクの過程やデータやり取りの最中であっても、一切の確認応答なしに即座にコネクションを破棄し、メモリ上のリソースを解放する。

よくある発生シナリオ:
ファイアウォールやセキュリティアプライアンス（WAFなど）が、不正なパケットを検知してセッションを断ち切るためにインジェクションする。
存在しないポートに対してパケットが届いた際、OSが自動的に送り返す（Port Unreachableの代わり）。
アプリケーションがクラッシュしてソケットが閉じられたため、OSが残存パケットに対して RST を返す。

実務で Connection reset by peer に直面したら、パケットキャプチャで誰が最初に RST を投げたのか（クライアントか、サーバーか、あるいは途中のルーターか）を特定することが、原因究明の第一歩だ。

3.2 バッファをバイパスする：PSHフラグ

HTTP/1.1や、リアルタイム性の高いWebSocketなどの通信において、データを書き込んだ端から即座に相手に届けたい場合がある。TCPは通常、ネットワークの効率を高めるためにNagleアルゴリズムなどを使い、ある程度データが溜まるまで送信を遅延させることがある。

ここで PSH（Push） フラグの出番だ。送信側のTCPスタックに対し、「このパケットのデータはバッファに溜め込まず、即座にアプリケーション層へ引き渡せ」と指示を出す。APIのレスポンスが小まめに、かつ遅延なくクライアントに届く背景には、この PSH フラグの細かい制御が絡んでいる。

—

4. 実務で役立つ検証コードとデバッグ手法

理論を学んだところで、これを実務の現場でどう確認・検証するか。Pythonとコマンドラインを使った実践的なアプローチを紹介しよう。

4.1 curl と tcpdump によるパケットのぞき見

まずは、身近な curl コマンドでHTTPリクエストを飛ばした際、背後でどんなTCPフラグが飛び交っているかを tcpdump でキャプチャしてみよう。

# ターミナルA: 特定のポート（例: 8080）のTCPフラグをリアルタイムで監視する
sudo tcpdump -nn -v 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0' port 8080

# ターミナルB: ローカルのAPIサーバーへリクエストを投げる
curl -X GET http://localhost:8080/api/health

tcpdump の出力結果に注目してほしい。
1. [S] （SYN）で始まり、
2. [S.] （SYN-ACK）が返り、
3. [.] （ACK）で確立。
4. データのやり取りの後、[F.] （FIN-ACK）や [F] で切断されていく様子が手に取るようにわかるはずだ。この「パケットの呼吸」が読めるようになると、障害調査のスピードが段違いに跳ね上がる。

4.2 Python（Scapyなど）を用いたカスタムパケットの概念

インフラのセキュリティテストやネットワークプログラミングの現場では、Pythonの socket ライブラリや Scapy などのライブラリを用いて、あえてフラグを制御したパケットを組み立てることがある。

以下は、標準の socket ライブラリではなく、より低レイヤーな制御を意識した概念的なPythonコードのイメージだ。実務において、ソケットオプション（TCP_NODELAY など）を調整し、Nagleアルゴリズムを制御する（結果として PSH フラグの挙動やパケット送信タイミングに影響を与える）設定の例を見てみよう。

import socket

def create_optimized_api_client(host, port):
    # TCPソケットを作成
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    
    # 【実務Tips】Nagleアルゴリズムを無効化（TCP_NODELAYを有効に）
    # これにより、小さなデータ片であっても遅延なく即座に送信（PSHの効率的利用）されるようになります。
    # リアルタイム性が求められるWeb APIやチャットサーバーなどで多用される設定です。
    s.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
    
    # サーバーへの接続（ここで3ウェイハンドシェイクが実行される）
    s.connect((host, port))
    print(f"Connected to {host}:{port} with TCP_NODELAY enabled.")
    
    return s

if __name__ == "__main__":
    # ローカルの検証用サーバーへ接続を試みる
    try:
        client_socket = create_optimized_api_client("127.0.0.1", 8080)
        # データの送信
        client_socket.sendall(b"GET / HTTP/1.1\r\nHost: localhost\r\n\r\n")
        
        # レスポンスの受信
        response = client_socket.recv(1024)
        print(response.decode('utf-8'))
    except ConnectionRefusedError:
        print("接続が拒否されました。サーバーが起動しているか確認してください。")
    finally:
        # クローズ時にFINパケットが送られ、グレースフル・シャットダウンが開始される
        client_socket.close()

このようなコードを書く際も、背後でOSがどのように SYN や ACK、そして最終的な FIN を組み立てているかをイメージできているかどうかが、ジュニアとシニアを分ける決定的な境界線となる。

—

おわりに：パケットの声を聞け

TCPフラグビットは、ネットワークという広大な海原を航海するパケットたちが交わす、極めてシンプルかつ強力な「手旗信号」だ。

Web APIの設計ミスによるコネクションリーク、ロードバランサーのタイムアウト設定の不備、あるいはセキュリティインシデントによる予期せぬ切断。それらのトラブルは、すべてこのフラグの不審な動きとして必ずパケットに記録されている。

「画面のエラーメッセージ」だけに囚われるのではなく、時には一段レイヤーを下げて、パケットの往来に耳を傾けてみてほしい。そこには、ネットワークの静かな、しかし確実な真実がすべて記されているはずだ。

さあ、次のインフラ障害に直面したときは、迷わずパケットキャプチャを開こう。パケットは、嘘をつかない。