こんにちは！ネットワークの世界へようこそ。インフラエンジニアの視点から、普段私たちが何気なく使っているWebブラウザの裏側のドラマを熱く、そして優しくお届けする技術ブログです。
私たちが普段、URLをポチッと入力してWebサイトを表示するとき、画面の裏側ではWebブラウザ（クライアント）とWebサーバーが目にも留まらぬ速さで会話をしています。この会話の共通言語が「HTTP」であり、それを支える道路が「TCP」という通信規格です。
今日は、このHTTPの歴史の中でも非常に重要な「HTTP/1.1のTCP接続クローズシーケンス（お片付けの作法）」と、裏でひっそりとサーバーを悩ませる「TIME_WAIT（タイムウェイト）」という少し厄介な現象について、身近な例えを交えながら一歩ずつ紐解いていきましょう！
—
1. 郵便配達で例える「HTTPの会話」と「電話回線」
まずイメージしやすいように、HTTPとTCPの関係を身近なものに例えてみますね。
- TCP（電話回線）：まず相手と電話をつなぎ、「もしもし？」とお互いの声が聞こえる状態を作ってから本題に入り、用事が済んだら「ガチャリ」と電話を切るまでの「土台」の部分です。
- HTTP（手紙・会話の内容）：「このページの写真をください」「はい、どうぞ」とやり取りする具体的な内容です。
HTTPの初期（HTTP/0.9や1.0の時代）は、「1往復の会話をしたら、すぐに電話を切る」というルールになっていました。これが「Connection: close（用事が済んだら電話を切ってね）」の精神です。
しかし、今のWebサイトは1つのページの中に、テキストだけでなく、たくさんの画像、アイコン、デザインファイル（CSS）、プログラム（JavaScript）が何十個も散りばめられていますよね。
もし、ファイルをもらうたびに「もしもし」「ガチャリ」「もしもし」「ガチャリ」とやっていたら、電話をかける準備だけでヘトヘトになってしまいます。
そこでHTTP/1.1では、「一度つないだ電話（TCP接続）は切らずに、用事が終わるまで使い回そう！（Keep-Alive）」というエコで賢い仕組みが標準になりました。
—
2. あえて「電話を切る」とき：`Connection: close` の正体
では、今回のテーマである `Connection: close` はどんなときに登場するのでしょうか？
基本的には「今回のリクエストとレスポンスのやり取りが終わったら、この電話回線をプツッと切ってくださいね」と、クライアントかサーバーのどちらかが相手にお願いする合図です。
例えば、サーバー側が「もう今日の私の仕事は終わりです！これ以上この回線で会話する予定はありません！」と判断したときや、プロキシサーバーが通信の交通整理をする際などにこのヘッダーが添えられます。
この合図が出たあと、パケットの世界ではどのような「お片付け（切断シーケンス）」が行われるのでしょうか。詳しく見ていきましょう！
—
3. パケットたちのドラマ：FIN と ACK によるお片付け
電話を切る（TCP接続を終了する）とき、いきなり回線を引っこ抜くような無粋なことはしません。紳士淑女のネットワークらしく、お互いに「お疲れ様でした！」と挨拶を交わす美しい手順（4wayハンドシェイクとも呼ばれます）があります。
ここでは、サーバー側から「Connection: close」を伝えて電話を切るシーンを覗いてみましょう。
[クライアント] [サーバー]
| |
| <--- [FIN] 「お話し終わりです」 --- | (サーバーから切断の申し出)
| --- [ACK] 「承知いたしました」 ---> | (クライアントが了解の返事)
| |
| — [FIN] 「こちらからも切ります」-> | (クライアントからも切断の申し出)
| <--- [ACK] 「了解です」---------- | (サーバーが了解の返事)
| |
(TIME_WAIT状態へ) (すぐスッキリ！)
1. サーバーからのお願い（FIN）：「そろそろこの通信を終わりますね」という終了フラグ（`FIN`）を送ります。
2. クライアントの返事（ACK）：「承知しました、お話が終わった旨を確認しました」と返事（`ACK`）を返します。
3. クライアントからの終了（FIN）：クライアント側からも「では、私の方からも回線を閉じますね」と `FIN` を送ります。
4. 最後の確認（ACK）：サーバーが「了解です」と返して、これにて一件落着……とはいかないのが、ネットワークの奥深いところです。
—
4. サーバーの悩みの種？「TIME_WAIT」の正体
先ほどの切断シーケンスで、最後にパケットを送り終えた側（多くの場合、先に「切ろうよ」と言い出した側やサーバー側）には、`TIME_WAIT`（タイムウェイト）という少し特殊な状態（待機モード）が訪れます。
これは、人間で例えるなら「電話を切ったあとに、相手がまだ何か言い残していないか、受話器を耳に当てたまましばらくボーッと待っている時間」です。
なぜこの時間が必要かと言うと、ネットワークの途中で最後の「了解です（ACK）」の返事が迷子になってしまい、相手が「あれ？ちゃんと聞こえたかな？」ともう一度「切りますよ（FIN）」を送ってくるかもしれないからです。この取りこぼしを防ぐため、TCPの仕様では大体2分間（OSによってはもっと短い設定もありますが）ほど、その通信ポートを占有したまま待機し続けます。
TIME_WAITがサーバーリソースに与える影響
アクセスが少ない個人サイトであれば全く問題ありません。しかし、1秒間に何千、何万ものアクセスをさばく超人気の巨大ECサイトやニュースサイトではどうなるでしょうか？
- `Connection: close` が頻発する。
- その都度、新しいTCP接続が作られ、そして切断される。
- 切断されるたびに、サーバー側に `TIME_WAIT` 状態のポートが山のように積み上がっていく。
OSが同時に扱えるポートの数には限りがあります。この `TIME_WAIT` でポートが埋め尽くされてしまうと、「新しいお客さんからの電話がつながらない！（＝Webサイトにアクセスできない、エラーが出る）」という深刻なリソース枯渇を引き起こしてしまうのです。これが、インフラエンジニアが頭を悩ませる「TIME_WAIT問題」の正体です。
—
5. 現場で使える！実践的な対策と設定例
「じゃあ、どうすればいいの？」という声が聞こえてきそうですね。実務の現場では、この問題を回避するためにいくつかのスマートな対策が取られています。
対策①：HTTP/1.1の「Keep-Alive」をしっかり活かす
一番の特効薬は、そもそも無駄に接続を切らないことです。HTTP/1.1のデフォルトである持続的接続を有効にし、次のような設定をWebサーバー（NginxやApacheなど）に施します。
【Nginxのコンフィグ例】
http {
# クライアントとの接続を維持する時間（タイムアウト）を設定
keepalive_timeout 65;
# 1つのTCP接続あたりに処理できる最大リクエスト数を増やす
keepalive_requests 100;
# 余計な Connection: close を避け、持続的接続を促す
# （NginxはデフォルトでKeep-Aliveをサポートしています）
}
※日本語コメント：この設定により、1本の電話回線で何度も効率よくHTTPのやり取りが行われ、無駄な回線の切断＝`TIME_WAIT` の発生を劇的に減らすことができます。
対策②：OSレベルでのチューニング（必要に応じて）
どうしても `Connection: close` を多用せざるを得ないシステムや、リバースプロキシサーバーを構築している場合、Linuxのカーネルパラメータを調整して `TIME_WAIT` の消化を早めるアプローチをとることもあります。
【Linuxのカーネルパラメータ設定例（`/etc/sysctl.conf`）】
TIME_WAIT 状態のソケットを、新しい接続で安全に再利用することを許可する
net.ipv4.tcp_tw_reuse = 1
（参考）FIN-WAIT-2 状態のタイムアウト時間を短くし、メモリを保護する
net.ipv4.tcp_fin_timeout = 15
※日本語コメント：`tcp_tw_reuse` を有効にすることで、安全が確認できる場合に限り、過去の `TIME_WAIT` ソケットを新しい通信へリサイクルできるようになり、ポート枯渇を防ぎやすくなります。
—
まとめ
今回は、HTTP/1.1の通信の裏側にある `Connection: close` とTCPの切断シーケンス、そして `TIME_WAIT` がサーバーに与える影響についてお話ししました。
- HTTP/1.1の基本は「電話をつなぎっぱなしにする（Keep-Alive）」こと。
- あえて切断する `Connection: close` を使うと、お片付け（FIN/ACK）のあとに `TIME_WAIT` という待機状態が生まれる。
- アクセスが殺到する環境でこれを乱用すると、サーバーのポートが枯渇して繋がらなくなるリスクがあるため、持続的接続を維持する設定や適切なチューニングがインフラの腕の見所となる。
普段何気なく見ているWebページも、パケットたちのこうしたドラマや、先人たちの泥くさいチューニングの歴史の上に成り立っているんだなと感じていただけたら嬉しいです。
それでは、また次回のネットワーク探訪でお会いしましょう！一歩ずつ、確実に理解を深めていきましょうね。
コメント