こんにちは！ネットワークやインフラの世界へようこそ。
Webブラウザでホームページを見るとき、私たちは何気なくURLを入力し、一瞬でページが表示されるのを当たり前のように楽しんでいますよね。でも、その裏側でパソコンとサーバーがどんな会話をしているのか、少し気になったことはありませんか？
「HTTP/2」という言葉、聞いたことがあるかもしれません。実はこれ、インターネットの通信を劇的に速くしてくれた超重要なしきたり（プロトコル）なんです。
今回は、そのHTTP/2の心臓部とも言える「接続の再利用とコネクション管理」について、難しい専門用語の裏側に隠された「リアルな挙動」を、身近な例えを交えながら一緒に紐解いていきましょう。一歩ずつ優しく解説していくので、どうぞリラックスして読んでくださいね！
—
1. 昔のインターネットは「その都度使い捨て」だった？（HTTP/1.1の限界）
まずは、HTTP/2の先輩にあたる「HTTP/1.1」の頃のお話を少しだけさせてください。
例えば、あなたがとあるおしゃれなカフェのオンラインショップで、たくさんの商品写真が載ったページを開いたとします。ページには、メインの文章データに加えて、10枚の商品の写真、お洒落なロゴ画像、ページのデザインを決めるスタイルシートなど、なんと合計20個ものバラバラのファイル（リソース）が含まれていました。
昔のHTTP/1.1のやり方は、こんな感じでした。
1. 1つ目のファイル（文章）をもらうためだけに、サーバーへ「おーい！」と新しい電話回線（TCP接続）をつなぐ。
2. データをもらったら、用事が済んだのですぐ電話を切る（切断）。
3. 2つ目のファイル（画像A）をもらうために、また新しく電話回線を繋ぐ。
4. 画像をもらったら、またすぐ電話を切る。
5. これを20回繰り返す……！
……なんだかすごく非効率ですよね？ 毎回、電話の呼び出し音を鳴らして、相手が出るのを待って（これがネットワークの世界でいう「TCPハンドシェイク」という接続の手間です）、挨拶をしてから本題に入る。これが20回も繰り返されるわけですから、ページが開くまでにどうしても時間がかかってしまいました。
—
2. HTTP/2の「1本の太いパイプ」と郵便配達の例え
「毎回電話を繋ぎ直すなんて、やっぱり無駄が多いよね！」ということで登場したのが、今回主役のHTTP/2です。
HTTP/2では、考え方がガラリと変わりました。
最初にサーバーと繋いだ1本のTCP接続（＝太いパイプライン）を、ずーっと切り捨たずに維持し続けます。
これを身近な例えで考えてみましょう。
> 【郵便配達の例え】
> 昔のやり方（HTTP/1.1）は、手紙が10通あったら、郵便屋さんが1通ポストに入れてはわざわざ郵便局に帰り、また2通目を持って家まで走り、それを10回繰り返すようなものです。足がクタクタになってしまいますよね。
>
> 一方、HTTP/2のやり方は、郵便屋さんがあなたの家の前にドンと大きなバッグを持ってやってきて、その中に「10通分の手紙（リクエスト）」をまとめて入れ、さらに「返事の封筒（レスポンス）」も同じバッグの中で同時に行き来させるようなものです。これなら何度も往復する必要がありませんよね！
この仕組みを、ネットワークの世界では「マルチプレクシング（多重化）」と呼びます。1本の同じ接続（パイプ）の中で、いくつもの通信（ストリーム）を同時に、お互いを邪魔することなく流すことができるのです。
—
3. 接続をずっと繋ぎっぱなしにするメリットと「お片付け」のルール
では、この「1本の接続をずっと維持する（Keep-Alive）」ことには、どんな素晴らしいメリットがあるのでしょうか？
メリット1：通信の準備運動（オーバーヘッド）がゼロになる
先ほどお話した、TCPの接続開始にかかるタイムラグ（ハンドシェイクや、セキュリティを強固にするTLSのやり取り）は、最初の1回だけで済みます。2回目以降のファイルのやり取りは、すでに繋がっているパイプにパケットをポンと放り込むだけなので、圧倒的に速く（低遅延で）なります。
メリット2：サーバーの負担が軽くなる
何度も接続を作ったり壊したりすると、サーバー側のCPUやメモリも「あ、また新しい人が来た！」「あ、切断された！」と大忙しになってしまいます。接続を維持することで、サーバーの省エネにも繋がるのです。
—
でも、いつまでも繋ぎっぱなしで大丈夫？（タイムライトとコネクション管理）
「じゃあ、一度繋いだら一生そのままにしておけばいいの？」と思われるかもしれませんが、世の中そんなに甘くありません（笑）。ネットワークには現実的な「お片付けのルール」が必要です。
もし、ユーザーがページを見終わって別のサイトに移動したあとも、サーバーとブラウザがずっと無駄な通信路を繋ぎっぱなしにしていたらどうでしょう？ サーバーの限られた「同時接続できる枠（リソース）」が埋まってしまい、本当に困っている他のユーザーがアクセスできなくなってしまいます。
ここで登場するのが、接続のタイムアウト（Idle Timeout）とコネクション管理です。
- アイドルタイムアウト: 「一定時間（例えば60秒間）、何も通信がなかったら、このお互いのパイプラインはもう用済みだからいったん閉じましょうね」というお約束のタイマーです。
- GoAwayフレーム（お別れの合図）: HTTP/2には、「そろそろこの接続を終了しますよ」という専用の合図（GoAway）をサーバーからブラウザに優しく伝える仕組みがあります。「今受けている通信が終わったら、次の新しい通信はこの古いパイプではなく、新しく作り直したパイプを使ってね」と、綺麗にバトンタッチができるようになっています。
—
4. 実務で役立つ設定例：Nginxでのキープアライブ制御
さて、ここからは少しだけ実践的なお話をしましょう。
実際にWebサーバー（今回は世界中で大人気の「Nginx」を例にします）を構築・設定する際、このHTTP/2の接続管理をどうコードで書いているのか、覗いてみましょう。
サーバーの設定ファイル（`nginx.conf` など）では、次のようなパラメータで接続の寿命や長さをコントロールしています。
http {
# HTTP/2 を有効にし、単一のTCP接続を維持する設定のブロック
# 1つのTCP接続上で、クライアントから何回までリクエストを受け付けるか
# （無限に受け付け続けることによるメモリリークや負荷を防ぐため、一定回数で一度接続をリフレッシュさせます）
keepalive_requests 1000;
# クライアントとの接続を「何秒間」保持し続けるか（アイドルタイムアウト）
# この時間を過ぎて何も通信がなければ、サーバー側からそっと接続を切断します
keepalive_timeout 65;
server {
listen 443 ssl http2; # ポート443番でSSLを有効にしつつ、HTTP/2を有効にする
server_name example.com;
# SSL証明書の設定などは省略…
location / {
root /var/www/html;
index index.html;
}
}
}
このように、インフラエンジニアは「速さ」を追求しつつも、「サーバーがパンクしないための安全弁（タイムアウトや回数制限）」のバランスを取りながら、日夜コネクションを管理しているのです。
—
まとめ：パケットの旅を想像してみよう
いかがでしたでしょうか？ 今回のポイントをギュッとまとめてみますね。
1. HTTP/1.1は、ファイルをもらうたびに電話回線を繋いだり切ったりしていたので、すごく非効率だった。
2. HTTP/2は、1本の太いパイプライン（TCP接続）をずっと維持し、その中で複数のデータを同時にやり取りする（マルチプレクシング）。
3. これにより、接続の準備にかかるムダな時間が消え、Webサイトが爆速で表示されるようになる。
4. ただし、永遠に繋ぎっぱなしにするのはサーバーの負担になるため、タイムアウトや切断のルール（コネクション管理）がしっかり用意されている。
普段、私たちが何気なくブラウザで見ているWebページ。その裏側では、目に見えない小さなパケットたちが、この洗練されたパイプラインを通って行儀よく、かつ猛スピードで駆け巡っています。
「今、サーバーとブラウザの間に1本の太いパイプが繋がっていて、そこを上手にデータの荷物が往復しているんだな」──そんなふうに、ネットワークの向こう側のリアルな挙動を頭に思い描けるようになると、インフラやプロトコルの勉強がぐっと楽しくなりますよ！
それでは、また次回の技術解説でお会いしましょう。一歩ずつ、一緒にエンジニアとしての引き出しを増やしていきましょうね！
コメント