TCP の MSL（Maximum Segment Lifetime）とは何か

TCP には、接続を安全に終了させるための仕組みがいくつもあります。 その中でも MSL（Maximum Segment Lifetime） は、 「古いパケットがネットワーク上に残っている可能性」を考慮した、 TCP の根本的な安全装置です。

MSL は、 “TCP セグメントがネットワーク上に存在し得る最大時間” を意味します。

RFC 793 では 2 分 が推奨値として示されています。

1. なぜ MSL が必要なのか

TCP は「信頼性のある通信」を提供するため、 古いパケットが新しい通信に混ざることを絶対に避ける必要があります。

もし古いパケットが残っていて、 新しい接続に紛れ込んだらどうなるか。

• すでに閉じたはずの接続にデータが届く
• 新しい接続のデータとして誤解される
• 予期しない ACK が届く
• 通信が壊れる、アプリが誤動作する

TCP はこれを避けるために、 “古いパケットが完全に消えるまで待つ” という設計を採用しています。

その「待ち時間」が MSL です。

2. TIME_WAIT が MSL と深く関係している

TCP の終了処理でよく出てくる状態に TIME_WAIT があります。

TIME_WAIT の待ち時間は、

2 × MSL

です。

つまり、MSL が 2 分なら TIME_WAIT は 4 分。

なぜ 2 倍なのかというと、

• FIN を送る
• 相手が ACK を返す
• その ACK が届かなかった場合、FIN を再送する可能性がある

この往復を安全に処理するため、 MSL の 2 倍の時間を確保する必要があるからです。

3. MSL が短すぎると何が起きる？

MSL を短くすると、TIME_WAIT も短くなり、 サーバーのポート枯渇を防ぎやすくなります。

しかし短すぎると、

• 古いパケットが新しい接続に混ざる
• 接続が壊れる
• データが欠落する
• アプリケーションが不安定になる

といった問題が起きます。

MSL は「安全」と「効率」のバランスを取る値です。

4. MSL が長すぎると何が起きる？

逆に長すぎると、

• TIME_WAIT が大量に残る
• サーバーのポートが枯渇しやすくなる
• 高負荷環境で接続が張れなくなる

特に Web サーバーや API サーバーでは、 TIME_WAIT の増加が性能問題につながります。

5. 実際の OS ではどう扱われている？

RFC の推奨値は 2 分ですが、 実際の OS は独自の値を採用しています。

OS	MSL	TIME_WAIT
Linux	30 秒前後（実質的に固定）	60 秒
Windows	約 2 分	約 4 分
BSD 系	30 秒	60 秒

Linux が短いのは、 高負荷サーバー用途を想定しているためです。

6. MSL は“通信の安全装置”である

MSL の本質は、

「古いパケットが新しい通信を壊さないようにするための時間」

です。

TCP は「信頼性」を最優先するため、 ネットワーク上に残る可能性のあるパケットを完全に無害化するまで 接続を再利用しません。

その慎重さが、 TCP の安定性を支えています。

まとめ

MSL は、TCP の中でも特に“地味だけど重要な存在”です。

• 古いパケットが混ざらないようにする
• TIME_WAIT の根拠になる
• 信頼性と効率のバランスを取る
• OS によって値が違う

通信が難しく見える理由のひとつは、 こうした“安全のための待ち時間”が多層的に存在するからです。