ニュースソース：The Akamai Blog
以下は 2017年3月23日に公開されたReaching toward universal TLS SNIの記載を要約したものです。
アカマイ・テクノロジー社では、TLSの拡張仕様であるSNI（Server Name Indication）のクライアントサポートが急増しています（2017年3月時点で、アカマイ社のクライアントによるHTTPS要求は、SNIの使用率が99％超）。
従来、すべてのWebトラフィックをHTTPSに移行するには、2つの大きな問題がありました。
- 第1に、サーバー証明書の可用性（アベイラビリティ）の問題です。
Let’s Encryptなどのプロバイダーにより提供される自動ドメイン認証（DV）証明書が、この問題の解決に貢献しています。 - 第2に、TLS仮想化ホスティングに関する技術的な問題です。
SNIは、これに対して最も拡張性（スケーラビリティ）の高い解決策です。
その背景には、TLSプロトコルが、HTTPSの基盤として認証と暗号化を可能としていることがあります。
SSL3.0と、その後継のTLS1.0が初めて開発された当時、仮想化ホスティングはサポートされていませんでした。
つまり、クライアントがサーバーに「ClientHello」というメッセージを送信した場合、サーバーから「ServerHello」というメッセージがサーバー名を認証する証明書とともに返信されますが、サーバー名がクライアント側で一致しない場合には、接続に失敗しエラーが発生します。
一方、1台のサーバーで数十、数千、数百万のWebサイトを処理することが可能な仮想化ホスティングでは、サーバーは複数の証明書の中から適切な証明書を特定して返信する必要があります。「ClientHello」にホスト名が含まれない場合、ポート番号443の指定に基づいてHTTPSを提供するサーバーは、証明書ごとにIPアドレスを利用するしかありません。
証明書ごとに数百、数千の仮想IPアドレスが必要になり、IPv4アドレスが枯渇した場合、これはスケーリング（処理能力）の問題になります。
しかし、2003年にTLSの拡張仕様であるSNIが導入され（RFC 3546）、クライアントは接続するホスト名（サーバー名）を「ClientHello」に含めることが可能となり、サーバーは「ServerHello」内から適切な証明書を選択して返信することが可能となりました。