介绍
虚拟主机 是在 同一台服务器。 尽管这是当今的规范，但在HTTP的早期（1.1之前的版本）是不可能的。
最初，如果为每个网站分配了专用端口，则服务器只能在同一台计算机上托管多个网站（即，使用相同的IP地址）。 这不是理想的解决方案，因为浏览器默认为端口 80 用于HTTP，除非用户指定其他名称。 结果，大多数网站所有者选择专用服务器来避免用户忘记正确端口号并最终进入另一个网站的风险。
但是，随着更多用户加入Web和更多网络设备开始在线出现，可用IP地址的数量开始以惊人的速度减少。 这种预期的损耗，称为 IPv4地址范围耗尽，已促使业界设计并实施各种对策，例如 IPv6 （IPv4的后继），可以支持 地址超过我们所需的地址。 不幸的是，尽管IPv6是可行的解决方案，但其采用速度仍然很慢。 根据 Google的IPv6统计数据，在撰写本文时，只有大约25％的Internet设备是通过IPv6部署的。
通过引入虚拟主机，还可以实施虚拟主机，以尽早缓解疲惫问题。 Host HTTP 1.1中的标头。 通过HTTP 1.1进行通信的浏览器现在可以连接到服务器的端口 80 并包含域名（例如 www.ssl.com）他们想要访问的网站 Host 标头。 无论服务器在同一端口上托管多少站点，它都可以使用此信息来标识正确的网站并返回其内容。
HTTPS和虚拟主机
但是，有关网络漏洞和针对Web用户的攻击的大量已发布报告激发了该行业的兴趣。 开始从不安全的HTTP转向更安全的替代HTTPS。 的广泛采用 HTTPS 改善了整体用户安全性。 但是，它的其他增强功能也增加了Web通信的总体复杂性。
原则上，HTTPS与HTTP非常相似，不同之处在于浏览器和服务器之间的HTTPS通信是加密的。 简而言之，HTTPS要求服务器向浏览器提供由公众信任的有效SSL证书 证书颁发机构 （CA），例如 SSL.com。 然后，浏览器可以使用证书中包含的公钥来 与服务器建立加密的通信通道。 此外，还会为特定的域名颁发证书，浏览器会检查该证书是否与用户要访问的域名相匹配。 因此，无论服务器托管多少个网站，浏览器都希望为其请求的网站找到有效的SSL证书。
细心的读者可能已经感觉到了问题：浏览器需要正确的网站证书才能建立加密通道并发送 Host 标头，而服务器需要 Host 标头以找到正确的站点的证书。 这是一个经典的鸡肉和鸡蛋问题。
很明显，虚拟主机（如针对HTTP设想的那样）不适用于HTTPS，因为安全控件会阻止浏览器发送 Host 信息传递到服务器。 尽管如此，由于IPv4耗尽问题仍未解决，并且行业不断采用云技术（需要负载平衡和多个故障转移后端服务器），因此虚拟主机仍然是必需的。
那么多域证书呢？
针对此问题的建议解决方案是使用多域或 SAN证书。 单个SAN证书可以保护数百个不同的域名，如果浏览器在SAN证书的域列表中找到要访问的域名，浏览器也不会抱怨。 配置加密通道后，浏览器可以发送 Host 头连接到服务器，然后继续进行其他操作。 这是一个很好的主意，它利用了已经存在且可用的技术，但是确保SAN证书安全的相同机制也带来了一些潜在的不良副作用：
SAN证书是保护同一实体（个人，公司或组织）拥有的多个域的一种很好的工具，但是在共享托管中使用它们不切实际。 每当准备将新域添加到证书中或从证书中删除新域时，CA都必须发布具有最新域列表的新证书，并将其重新部署在所有域上。
此外，SAN证书只能以 组织验证（OV）或扩展验证（EV） if 所有 域属于同一组织。 这些验证级别是指 由CA验证的预期证书所有者信息的数量和类型 在向他们颁发证书之前。 研究表明，验证级别越高，用户对网站的信任程度越高，用户信任度就会影响品牌识别度和转化率。
最后，在共享Web托管环境中，公司与其他企业或组织（甚至与竞争对手）共享服务器也很普遍。 由于SAN证书中的域是公开列出的，因此企业所有者可能不愿意与第三方公司共享同一证书。
尽管SAN证书是功能强大且用途广泛的工具，可用于数不清的应用程序，但这些问题促使IETF（Internet标准的管理机构）寻求针对虚拟托管HTTPS网站的特定问题的更合适方法。
救援的服务器名称指示
该解决方案以 服务器名称指示 (SNI）的扩展 TLS 协议（HTTPS处理加密的部分）。
SNI使浏览器可以指定在连接过程中要连接的域名 TLS 握手 （与服务器的初始证书协商）。 结果，网站可以使用自己的SSL证书，同时仍托管在共享的IP地址和端口上，因为HTTPS服务器可以使用SNI信息来标识建立连接所需的适当证书链。
之后，在配置了加密的通信通道后，浏览器可以继续将网站的域名包括在 Host 标头，然后像往常一样继续。 本质上，SNI执行与HTTP相同的功能 Host 创建加密连接期间的标头。
这个简单的技巧最终使服务器可以在同一端口上托管多个HTTPS网站。 但是，与大多数Internet技术一样，SNI也有一些限制。
SNI支持问题
尽管SNI自1999年首次起草以来就已经相当成熟，但是仍然有一些不支持它的旧版浏览器（Windows XP上的IE）和操作系统（Android版本<= 2.3）。 有关支持SNI的浏览器和操作系统的完整列表，请查看 这张表格.
尽管与现代浏览器相比，不支持SNI的浏览器的市场份额很小（并且通过扩展来说明这种情况的发生），但是如果浏览器无法识别SNI，它将退回到默认的SSL证书，并有可能产生 通用名称不匹配错误.
许多公司，例如Google，都为支持SNI的客户端实施SNI，并在少数情况下不使用SAN证书。 自然，随着越来越多的用户和企业主将其系统升级为现代技术，预计该问题将减少。
SNI隐私问题
当前的稳定版本 TLS （版本1.2）传输握手的初始部分，并且通过扩展SNI信息进行加密。 因此，尽管Web通信本身已完全加密，但网络攻击者仍可以发现用户的Web历史记录。
诸如Amazon或Google之类的各种云服务提供商已允许一种（肮脏的）变通方法，称为 域前沿。 域名前置可以防止网络历史记录的泄露，因为它通过使用云提供商的主机名混淆了SNI信息。 TLS 协商和目标网站位于HTTP标头中。 但是，此方法不再可行，因为Google和Amazon已公开声明他们 禁用对域前沿的支持 自2018年XNUMX月起开始提供服务。
幸运的是，已经提出了更系统的解决方案 实验草案 详细说明 加密的SNI (埃斯尼）最新的扩展名 TLS 版本1.3。 ESNI加密SNI信息，从而减轻了所有隐私问题。 不幸， TLS 1.3尚未被业界广泛采用，即使 TLS 1.3正在逐渐成为事实上的网络安全协议。 请留意我们以后有关ESNI的状态以及HTTPS和HTTPS隐私的文章。 TLS.
结论
总之，使用SNI，您可以在单个服务器上托管数百万个HTTPS网站。 但是，根据您的具体情况，SAN证书可能更适合您。 关于SNI的隐私问题仍然存在，尽管ESNI也存在潜在的解决方案。 无论如何，使用这两种方法中的一种或两种方法的组合，您可以轻松地为所有网站轻松实现虚拟主机。
如果您对SNI有更多疑问，或者不知道如何在SAN和SNI之间进行选择，我们将很乐意回答所有客户关于SNI的问题。 PKI 需要。 只需向我们发送电子邮件至 support@ssl.com 专家会为您提供帮助。
