Smart Shield は、複数のリクエストを共有接続にまとめることで、Cloudflare とオリジンサーバーのあいだの接続数を減らします。上位ティアデータセンター（オリジンに最も近い Cloudflare キャッシュ層）からのリクエストがサーバーへ届くとき、Smart Shield はリクエストごとに新しい接続を開かず、1 本の接続で送ります。オリジンへの接続数は平均で 30% 減ります。オリジンのリソース消費が下がり、高トラフィック時の接続枯渇リスクも下がります。
詳細は Smart Shield 発表ブログ ↗ を参照してください。
HTTP リクエストには、クライアントとサーバーのあいだの TCP 接続が必要です。各接続は、送信元の IP アドレスとポート、宛先の IP アドレスとポートというネットワークアドレスの組で識別されます。新しい TCP 接続を開くにはオーバーヘッドがあります。クライアントとサーバーのハンドシェイクが必要で、暗号化されている場合は TLS ネゴシエーションも必要です。
接続の再利用（持続的接続、または keep-alive とも呼ばれます）は、リクエストごとに新しい接続を開かず、1 本の TCP 接続で複数の HTTP リクエストを送ることで、このオーバーヘッドを避けます。HTTP/1.1 では、これがデフォルトの動作になりました。
たとえば、ブラウザーが shop.example.com への接続を開くと、ページはスタイルシート、画像、スクリプトなどの追加リソースを数十件参照することがあります。接続の再利用がなければ、各リソースに独自の TCP 接続が必要です。接続の再利用があれば、これらのリクエストはすべて同じ接続を通ります。
HTTP/2 では、接続の再利用は接続の結合（connection coalescing）によってさらに広がります。次の 2 つの条件を満たせば、異なるホスト名向けのリクエストが 1 本の接続を共有できます。
- ホスト名が同じ宛先 IP アドレスとポートに解決される。
- サーバー上の TLS 証明書が両方のホスト名をカバーしている（たとえば、Subject Alternative Names に
shop.example.comとblog.example.comの両方を記載した証明書）。
つまり、当初 shop.example.com 向けに開いた接続で、blog.example.com 向けのリクエストも運べます。オリジンへの接続数はさらに減ります。
Dedicated CDN Egress IPs を割り当てるときも、接続の再利用と接続の結合を考慮します。