TCPの残響を聴け：HTTP/1.1の持続的接続とパイプライン処理の深淵
ネットワークエンジニアにとって、HTTP/1.1は「完成されたプロトコル」であると同時に、現代のWebパフォーマンスにおける「終わりのない呪縛」でもあります。
HTTP/1.0の時代、ブラウザが画像ひとつを読み込むたびにTCPの3ウェイ・ハンドシェイク（SYN, SYN-ACK, ACK）と、続くTLSのネゴシエーションを繰り返していた光景を覚えているでしょうか。あの頃のネットワークは、パケットの往復（RTT）の分だけ「無」を待つ時間で埋め尽くされていました。
本稿では、この非効率を打破するために導入された`Connection: keep-alive`と、野心的だったが故に挫折したパイプライン処理の真実を、パケットレベルの挙動から紐解きます。
—
1. 持続的接続（Keep-Alive）：TCPの寿命を制御する
HTTP/1.1において、デフォルトで有効化された`Connection: keep-alive`は、TCPセッションの生存戦略を大きく変えました。クライアントとサーバーがリクエスト終了後に切断せず、次のリクエストのためにソケットを「開いたまま」にする。これにより、コネクションのオーバーヘッドを劇的に削減しました。
パケットレベルの最適化とチューニング
しかし、この「開きっぱなし」はカーネルレベルでのリソース消費を意味します。サーバー側では、TIME_WAIT状態のソケットが溢れ、`net.ipv4.tcp_tw_reuse`や`tcp_fin_timeout`の調整が必須となるでしょう。
sysctlでの最適化例
TIME_WAITソケットを再利用可能にする（安全性を考慮して慎重に）
sysctl -w net.ipv4.tcp_tw_reuse=1
FIN-WAIT-2のタイムアウトを短縮し、リソース解放を早める
sysctl -w net.ipv4.tcp_fin_timeout=15
ここで重要なのは、`Keep-Alive`のタイムアウト設定です。アプリケーション層のタイムアウトと、TCPのキープアライブ・プローブ（`tcp_keepalive_time`）のバランスが悪いと、中継するロードバランサー（L7 LB）が先にセッションを切断し、クライアントに「Empty Reply from Server」を突き返すという悲劇を招きます。
—
2. パイプライン処理：夢見た「同時並行」の正体
パイプライン処理は、HTTP/1.1が提示した最もアグレッシブな回答でした。「レスポンスを待たずに、次のリクエストをTCPの送信バッファに詰め込む」。理論上、RTTの影響を最小化できるはずでした。
なぜパイプラインは失敗したのか
しかし、この仕様は実装レベルで致命的な欠陥を抱えていました。それは「Head-of-Line Blocking（HoL Blocking）」です。
1. 順序の強制: サーバーはリクエストを受信した順番通りにレスポンスを返さねばなりません。
2. ブロッキング: 最初の1つ目のリクエストが重い処理（DBクエリなど）で詰まると、後ろに控える2つ目、3つ目のレスポンスもすべて滞留します。
3. パケットの紛失: 万が一、TCPセグメントが一つでも欠落すれば、TCPスタックは後続のデータを渡すことができません。
結果として、ブラウザベンダーやサーバー実装者はこの機能を実質的に無効化しました。現代の我々がHTTP/2やHTTP/3でマルチプレクシング（多重化）に熱狂するのは、この「HTTP/1.1のパイプライン処理が解決できなかった順序依存性の克服」こそが真のブレイクスルーだったからです。
—
3. 実践：トランスポート層からのセキュリティとパフォーマンス
HTTP/1.1を運用する際、特にTLS 1.2/1.3環境下では、以下のチューニングがWebサーバー（Nginx等）のレスポンスを左右します。
TLSハンドシェイクの最適化
TLS 1.3ではハンドシェイクが1RTTで完了しますが、HTTP/1.1のコネクション再利用と組み合わせることで、実質的なレイテンシはほぼゼロに近づきます。
Nginx設定例：コネクション維持とバッファの最適化
keepalive_timeout 65; # クライアント側の待機時間
keepalive_requests 1000; # 1つの接続で処理するリクエスト上限（高負荷時は増やす）
送信バッファのチューニング
sendfile on;
tcp_nopush on; # パケットの断片化を防ぎ、効率的な送信を促す
tcp_nodelay on; # 小さなパケットを即座に送信（パイプライン時は注意が必要）
—
4. 結び：インフラアーキテクトが今、見るべきもの
HTTP/1.1のパイプライン処理は、現代のネットワークにおいて「過去の遺物」として扱われがちです。しかし、そこには「いかにしてRTTを克服するか」という、エンジニアが常に直面する課題の本質が詰まっています。
セキュリティの観点から言えば、Keep-Aliveの維持はDDoS攻撃の標的にもなり得ます。適切な `client_body_timeout` や `client_header_timeout` の設定を怠ることは、ネットワークの脆弱性を放置するのと同義です。
我々インフラエンジニアの仕事は、プロトコルの仕様をただなぞることではなく、パケットがワイヤーの上をどう飛び、カーネルのスタックでどう処理され、アプリケーションに届くのか、その「生命の律動」を理解し、最適化することにあります。
HTTP/1.1のコードを読み、パケットをキャプチャし、TCPウィンドウサイズの変化を観察してください。そこに、次世代のプロトコルを設計するヒントが必ず隠されています。
コメント