SNI实际上是在浏览器中使用和支持的吗？
我可以find有关SNI的各种信息（请参阅维基百科 ），但我无法find任何有关浏览器实际支持的统计信息。
我能find的最好的是它应该在Windows XP和SP3上工作。
有没有人知道SNI是否可以在实际中使用？
我可以分享我的经验和方法，从一个虚拟主机环境（每个服务器多个域）中的每个IP一个IP切换到一个负载平衡的环境，对于所有域都有一个IP。
我们查看了我们的Google Analytics（每月超过100万次访问者），这大多数是北美男性用户在线购买汽车部件，并且在2014年3月8日发现，大约4％的用户使用Internet Explorer（Windows XP）其他人是轻微的 – 最坏的情况下4.5％的总用户会受到不支持SNI的影响）。 请记住，我们没有对这些用户的“控制”，所以我们不能告诉他们切换浏览器。 至less在美国，这个比例也在迅速下降。
我们首先决定，对于非SNI客户来说，与支持SNI的客户有一些不同的经历是“可以的”。
我们的方法是检测服务器端（使用UAstring）哪个浏览器/操作系统组合不支持SNI（正如其他人提到的： 关于SNI支持的维基百科文章 ）。 我们所有的域（〜120）都会有一个Alogging指向一个负载均衡的IP。 我们有一个第二个IP（也是负载均衡）的域名，我们可以称为generic-autoparts.com。
所以设置是[我没有关联任何域我用下面的例子]：
mikesautoparts.com – > IP X的域名服务器logging
dansautoparts.com – > IP X的名称服务器logging
jensautoparts.com – > IP X的名称服务器logging
…等
generic-autoparts.com – > IP Y的名称服务器logging
如果客户打到http://www.dansautoparts.com ，并支持SNI，则什么都不会发生。 他浏览dansautoparts.com，当它结束时，他使用https://www.dansautoparts.com 。
如果客户点击http://www.dansautoparts.com ，并且我们发现他不支持SNI，我们立即将客户redirect到http://generic-autoparts.com/dansautoparts.com 。 他在那里购物，在结帐时他使用https://generic-autoparts.com/dansautoparts.com
现在，如果客户直接访问https://www.dansautoparts.com （链接电子邮件，在search引擎的索引页面），你是运气不好。 他们会得到一个令人讨厌的证书错误。 在我们的例子中，我们确保我们的系统发送的所有电子邮件都没有使用https，并且我们知道search引擎没有将我们的https页面编入索引。
每个环境都有不同的挑战和潜在的取舍。 我们发现这在我们的案例中运行良好，客户将“接受”（或不知道）redirect到http://generic-autoparts.com/%5BORIGINAL DOMAIN] .com。 我们还通过generic-autoparts.com保持结帐安全。
假设有20％的nonSNI用户注意到redirect，这看起来很可疑，而且他们离开了。 在我们的案例中，用户数量为0.8-0.9％（基于2014年3月8日的数字），我们愿意“为此而活”。 我现在没有具体数据，但整体销售稳定。 [编辑3/28/2014：我们切换100％的客户后，我们看到没有影响销售]
实施更新2014年7月8日
事实certificate，在服务器上静态检测每个UA代理string是不可能的。 我们实现了以下JavaScript来检测浏览器的SNIfunction。 一般的做法是针对需要SNI的域进行JSONP请求（Apache通过“SSLStrictSNIVHostCheck on”支持）。 如果JSONP请求超时失败，我们将客户redirect到nonSNI域。
更复杂的是，我们不想因为SNI_TEST_DOMAINclosures而redirect每个人。 如果JSONP请求失败（由于无法直接检测到JSONP失败而超时），我们通过执行HTTP“健康检查”请求来validation服务器是否可用。 另外，我们不希望在每个页面上运行这个javascript代码，因为这会增加一些奇怪的超时和错误地redirect许多客户的机会，所以我们设置一个会话variables，一旦SNI检查完成，所以不会发生当客户浏览网站时也是如此。
我们知道，由于JSONP超时是不可靠的，所以我们得到了某些错误的检查失败，但是由于实现这一点，我们没有收到客户的投诉。
var redirect='http://REPLACE_WITH_NON_SNI_URL'; var sni_https_timeout, sni_http_timeout; var https_req = $.ajax({ url : 'https://SNI_TEST_DOMAIN.com/snitest.php', dataType : "jsonp", }).done(function() { window.clearTimeout(sni_https_timeout); var request = $.ajax({ url: "index.php?ua=sni_check_done", type: "POST" }); }) sni_https_timeout = window.setTimeout(function() { var http_req = $.ajax({ url : 'http://SNI_TEST_DOMAIN/sni_healthcheck.php', dataType : "jsonp" }).done(function() { window.clearTimeout(sni_http_timeout); window.setTimeout(function() { window.location = redirect; }, 200); }); sni_http_timeout = window.setTimeout(function() { sni_http_fail(); }, 8000); }, 8000); function sni_http_fail() { var request = $.ajax({ url: "index.php?ua=sni_check_done", type: "POST" }); } snitest.php / sni_healthcheck.php：
<?php if (array_key_exists('callback', $_GET)) { header( 'Content-type: application/javascript' ); echo "{$_GET['callback']}();\n"; }
您引用的维基百科文章列出了支持的浏览器和服务器版本。 例如，Internet Explorer 7（Vista或更高版本，不是XP）或更高版本以及Mozilla Firefox 2.0。 除非您知道所有访问者正在使用受支持的浏览器，否则不能使用SNI（在一个IP地址上具有多个证书），而不将其从您站点的SSL部分切断。
Windows XP上的Internet Explorer（所有版本; 6,7和8）不支持SNI。 所有其他工作。 我真的不知道XP上有多less用户使用Internet Explorer，但这是不能使用SNI的魔术师数量。
移动支持：
Android default browser on Honeycomb or newer Windows Phone 7 MobileSafari in Apple iOS 4.0 or later
问题是Windows XP客户端和Android <3.0客户端。 不幸的是，他们仍然有将近10％的访问者访问了我们的许多网站。 另外，虽然黑莓用户数量不多，但他们是我们的一些付费用户。 XP，Blackberry和Gingerbread的合并使得SNI目前在我们的大部分网站（2015年2月）无法接受。 我预计这个问题在一两年内就会减less。
2016年11月更新（21个月后）：在一个相当标准的网站上，每月约10,000个访问者。 2013年1月〜10％非SNI。 2014年1月〜6％，2015年1月<2％，2016年1月〜0.5％，2016年11月〜0.1％（千分之一）。 我们在2015年11月/ 12月进行了交易。但是，某些市场可能有更多的这些用户。 我在Google Analytics中创build了自定义受众群体，因此很容易看出影响。 只是由操作系统名称来定义，版本以XP开头，浏览器为IE。
是
您将无法使用SNI支持XP连接的SSL连接。 但是，允许XP客户端连接并不符合某些标准，因此您可能需要放弃其他原因。
他们只是在2016年几个百分点，下降。 如果你必须支持每个用户使用SSL，那么你将需要dynamic切换，但如果你只需要绝大多数…当然。
我迟到了，但对于所有可能对这种解决scheme感兴趣的读者来说。 只需使用服务器端function检测浏览器和操作系统，并告诉访问者使用“安装和使用安全浏览器在线购物，如Chrome或Firefox，并提供下载和安装的链接。
这是为您的顾客提供购物安全的最佳方式，这有两个目的，一个是SNI启用SSL使用，并使客户“购物安全”。 因为那些过时的XP浏览器真的不安全，不pipe服务器使用SNI启用SSL或不。
我们可以冒这个风险，因为在XP上使用旧IE版本的用户比例在美国低于5％，在其他国家可以忽略不计或者为零。 事实上，其他国家的人们习惯于开源浏览器。
我自己的经验，我为自己和许多客户托pipe了很多网站，并且我使用了没有专用IP的SNI技术的SSL。我相信很多国家的人们已经转向了Chrome或者Firefox，几乎所有的人而在美国则有95％。
原谅我的任何不准确的信息。
我认为这有两个方面，用户界面和检测部分。
UX
<!--[if lt IE 7]> <div>You're using a browser that has high security risks (SSL, XSS, etc). Please consider upgrading it.</div> <![endif]-->
很显然，使用IE6 or below在Windows XP上很有可能不支持SNI。 另一个欺骗用户代理的人在这里并不重要。
服务器端
- 嗅探用户代理。 在unit testing完成后会提出正则expression式。
- 使用上面的AJAX实现。
特别说明
使用AJAX解决scheme为您提供99％的防弹检测，但不符合一些Web开发原则。
- 渐进式增强 – 您正在向所有用户提供相同的AJAX请求。 支持SNI的用户不应该被打扰。
- 传统 – 您不能轻易弃用此代码。
- 如果您使用jQuery与您的AJAX请求，您可能会影响您的代码取决于$ .ajaxStop（）方法。
