ブラウザの「同時接続数制限」との果てなき戦い：HTTP/1.1時代の遺産「ドメインシャーディング」の深淵
ネットワークエンジニアとして現場を渡り歩いていると、いまだに「なぜ静的コンテンツをわざわざ別ドメインから配信しているのか？」という質問を若手から受けることがある。CDNが当たり前になった今、その問いに対する答えは「HTTP/1.1というプロトコルの制約を、泥臭い工夫で突破しようとした先人の知恵」という歴史的背景にたどり着く。
今日は、現代のHTTP/3時代から見れば「古き良き（あるいは悪しき）」ハックであるドメインシャーディング（Domain Sharding）について、その設計思想とトレードオフを紐解いていこう。
—
1. なぜ「制限」が必要だったのか：HTTP/1.1の呪縛
HTTP/1.1において、ブラウザには「1ドメインあたりの同時接続数」に厳しい制限があった。古くはRFC 2616、後のRFC 7230に至るまで、ブラウザベンダーはサーバー負荷を考慮し、同一ホスト名に対しては最大2接続までという制約を課していた（後にIE8やChrome等の近代ブラウザでは6〜8接続に緩和されたが）。
この制約下で、画像やスクリプトが数百個あるモダンなWebページを読み込もうとすると、ブラウザは「順番待ち」の行列を作る。これがWebの表示速度を殺す「Head-of-Line Blocking（HOLB）」の正体だ。
—
2. ドメインシャーディング：魔法の「別働隊」戦術
この行列問題を回避するための力技が「ドメインシャーディング」だ。同じサーバーを指す別名（`static1.example.com`, `static2.example.com`…）を用意し、リソースを分散させる。
ブラウザから見れば、これらは「別のホスト」であるため、ホストごとに同時接続数制限が適用される。結果として、制限が6接続だとしても、4つのドメインを使えば最大24接続を並列化できる計算になる。
シーケンスのイメージ
Client (Browser) Server (Origin)
| |
|– GET /img1.jpg (host: static1.example.com) —–>|
|– GET /img2.jpg (host: static2.example.com) —–>| (並列処理開始)
|– GET /img3.jpg (host: static3.example.com) —–>|
| |
—
3. 実践：インフラ構成とトレードオフ
この手法を導入する際、必ずぶつかるのが「DNSルックアップ」という名のコストだ。
DNSの罠
ドメインを増やすということは、ブラウザが最初にその名前を解決するための「DNSクエリ」を投げる回数が増えることを意味する。
- メリット: TCPコネクションの並列数が増え、低レイテンシでリソースを取得できる。
- デメリット: 名前解決のオーバーヘッド、コネクション確立（TCP Handshake + TLS Handshake）のオーバーヘッドが増大する。
特にモバイルネットワーク環境では、DNS解決が数ミリ秒〜数秒遅れることも珍しくない。多用しすぎると「並列化の恩恵」よりも「名前解決とTCP接続のコスト」が上回るという本末転倒な事態に陥る。
—
4. コードで確認：並列ダウンロードを擬似体験する
現代のフロントエンド開発ではブラウザが自動的に最適化してくれるが、バックエンド側から挙動を確認するなら、`curl`を使って並列アクセスをシミュレートしてみるのが手っ取り早い。
3つのドメインに対してリクエストを投げ、接続の挙動を確認する
実際には、複数の別名が同一IP（または同一CDNノード）を向いている前提
curl -w “Time: %{time_total}s\n” -o /dev/null http://static1.example.com/asset.jpg &
curl -w “Time: %{time_total}s\n” -o /dev/null http://static2.example.com/asset.jpg &
curl -w “Time: %{time_total}s\n” -o /dev/null http://static3.example.com/asset.jpg &
この際、TCPコネクションがそれぞれ確立されている様子を
netstat や ss コマンドで追うと、並列動作が可視化できる
ss -nt | grep :80
—
5. 現代における「ドメインシャーディング」の立ち位置
正直に言おう。HTTP/2以降、このテクニックは原則として「アンチパターン」だ。
HTTP/2の多重化（Multiplexing）は、単一のTCPコネクション上で複数のリクエストを同時に処理できる。ここでドメインシャーディングを過度に行うと、逆に「コネクションの再利用」ができなくなり、効率が悪化する。
私からのアドバイス
1. HTTP/1.1環境がメインのレガシーシステム: ドメインシャーディングは依然として有効な高速化手法である。ただし、2〜3ドメインまでに留めるのが定石だ。
2. HTTP/2 / HTTP/3 が有効な環境: ドメインシャーディングは今すぐ廃止し、ドメインを統合（Consolidation）すべきだ。キャッシュ効率の向上と、TLSコネクションの集約によるRTT（Round Trip Time）削減の方が遥かにインパクトが大きい。
まとめ
技術というものは、時代背景とともに「最適解」が移り変わる。ドメインシャーディングは、当時のブラウザの制限という「壁」を乗り越えるための知恵だった。今、私たちが学ぶべきは「どの技術が、どの制約を解決するために生まれたか」という文脈だ。
皆さんのインフラ設計においても、むやみに技術を適用するのではなく、「今、ボトルネックはどこにあるのか？」をパケットの流れと共に想像してみてほしい。それが、一流のエンジニアへの第一歩だ。
コメント