UDPとTCPでFW挙動が違う理由【ステート管理・セッション・実務トラブルの本質】

「TCPは通るのに、UDPだけ通らない」
「同じFWルールなのに挙動が違う」

これはFWの不具合ではなく、TCPとUDPの設計思想の違いが原因です。

本記事では、
FWがTCPとUDPをどう扱っているのか を内部動作レベルで解説し、 なぜUDP通信は壊れやすいのか を実務目線で整理します。

結論：FWはTCPとUDPを「同じ通信」として見ていない

FWはプロトコルごとに、
チェック方法・セッション管理・破棄条件 を変えています。

項目	TCP	UDP
コネクション	あり（3-way handshake）	なし
セッション確立判断	SYN/SYN-ACK/ACK	パケット到達のみ
FWでの状態管理	詳細	簡易
壊れやすさ	低い	高い

FWにおけるTCP通信の扱い

① ステートフル検査が前提

TCPでは、FWは以下を必ず確認します。

• SYNが来たか
• SYN-ACKが戻ったか
• ACKで確立したか

このためFWは「正当な通信かどうか」を高精度で判断できます。

② セッションが安定しやすい理由

• 通信開始・終了が明確
• 再送制御あり
• RST/FINで終了検知

FWにとってTCPは非常に扱いやすい通信です。

FWにおけるUDP通信の扱い

① 「通信開始」という概念がない

UDPにはSYNもACKもありません。

FWは以下のように処理します。

• UDPパケットを見た瞬間に「仮セッション」を作る
• 一定時間で破棄

② タイムアウト依存が非常に強い

UDPセッションは通信が止まった瞬間に消えるため、

• 応答が遅い
• 間欠通信

これだけで通信断が発生します。

実務で起きる「挙動の違い」具体例

例① TCPはOK、UDPはNG

• TCP：セッション維持 → 通信継続
• UDP：タイムアウト → 戻り通信破棄

例② FWログに何も出ない

UDPはdenyされる前に破棄されるケースが多く、 ログに残らないことがあります。

NAT環境での違い（特に重要）

TCPのNAT

• セッションと強く紐づく
• 戻り通信を識別しやすい

UDPのNAT

• 短時間でNATエントリ消失
• 戻り通信が不正扱いされやすい

UDP＋NAT＋FW は 実務で最もトラブルが多い組み合わせです。

QoS・MTUが与える影響の違い

TCPの場合

• 再送で回復
• ウィンドウ制御で適応

UDPの場合

• ドロップ＝即通信品質低下
• フラグメント破棄で完全断

FW通過後の品質差も大きく異なります。

実務での切り分け観点（TCPとUDPで変える）

TCPトラブル時

• 3-way handshake確認
• RST/FINの有無
• ウィンドウサイズ

UDPトラブル時

• FWセッション存在時間
• タイムアウト値
• MTU・フラグメント
• 非対称ルーティング

まとめ

• FWはTCPとUDPを別物として扱う
• UDPは状態管理が弱く壊れやすい
• ログに出ない＝正常ではない

「TCPは通るのにUDPが通らない」 のは、 設計上ごく自然な現象です。

UDP通信では、 FWの中で何が起きているかを想像できるか が トラブル解決の分かれ道になります。