SNI实际上是在浏览器中使用和支持吗？ [英] Is SNI actually used and supported in browsers?

问题描述

我可以找到有关SNI的各种信息（请参阅维基百科），但我找不到任何有关实际支持的统计信息在浏览器中。

I can find various information about SNI (see Wikipedia), but I can't find any statistics about actual support in browsers.

我最好的发现是它应该在Windows XP SP3上运行。

The best I could find out is that it should work on Windows XP with SP3.

有没有人知道SNI是否可以在实践中使用？

Does anyone know if SNI can actually be used in practice?

推荐答案

我可以分享我的经验和方法， - 在一个虚拟主机环境（每个服务器多个域）到一个负载平衡环境的所有域的一个IP的证书。

I can share my experience and approach to switching from one-IP-per certificate in a virtual hosting environment (multiple domains per server) to a load balanced environment with one IP for all domains.

我们看了我们的分析独特访客/月），这是大多数北美男性用户希望在线购买汽车零件，并发现在2014年3月8日，大约4％的用户是在Windows XP使用Internet Explorer（其他人是轻微的 - 最坏的情况下4.5％的用户将受不支持SNI的影响）。请注意，我们对这些用户没有控制权，因此我们无法告诉他们切换浏览器。这个百分比也在迅速下降，至少在美国。

We looked at our Analytics (over 1 million unique visitors / month), which is mostly North American male users looking to buy auto parts online, and found on March 8th, 2014 that approximately 4 % of users were on Windows XP using Internet Explorer (others were minor -- worst case 4.5 % of total users would be affected by not supporting SNI). Keep in mind that we have no "control" over these users so we can't tell them to switch browsers. This percentage is also dropping fairly quickly, at least in the US.

我们首先决定，对于非SNI客户来说，与客户有不同的体验是OK支持SNI。

We first decided that it was "OK" for non SNI customers to have a somewhat different experience than customers supporting SNI.

我们的方法是检测服务器端（使用UA字符串）哪个浏览器/操作系统组合不支持SNI（如其他人提到的：关于SNI支持的维基百科文章）。所有我们的域（〜120）将有一个A记录指向一个负载均衡的IP。我们有一个域名的第二个IP（也负载平衡），我们可以调用generic-autoparts.com。

Our approach was to detect server-side (using UA string) which browser/operating system combination does not support SNI (as other people mentioned: Wikipedia article on SNI support). All our domains (~ 120) would have an A record pointing to a single load-balanced IP. We had a second IP (also load balanced) for a domain we can call generic-autoparts.com.

所以设置是[我没有关联任何域我使用下面的示例]：

So the setup is [I'm not associated with any domains I use as examples below]:

mikesautoparts.com - >名称服务器IP记录XÚ
dansautoparts.com - >名称服务器IP记录XÚ
jensautoparts.com - >名称服务器IP记录XÚ
... etc

mikesautoparts.com --> A Nameserver Record of IP X
dansautoparts.com --> A Nameserver Record of IP X
jensautoparts.com --> A Nameserver Record of IP X
... etc

generic-autoparts.com - > IP名称服务器记录

generic-autoparts.com --> A Nameserver Record of IP Y

如果客户点击 http://www.dansautoparts.com ，并且支持SNI，没有任何反应。他浏览dansautoparts.com，当到检查时，他使用 https://www.dansautoparts.com 。

If a customer hits http://www.dansautoparts.com, and supports SNI, nothing happens. He browses dansautoparts.com, and when it comes time to check out, he uses https://www.dansautoparts.com.

如果客户点击 http://www.dansautoparts.com ，我们检测到他不支持SNI，我们会立即将客户重定向到 http://generic-autoparts.com/dansautoparts.com 。他在那里购物，结帐时他使用 https://generic-autoparts.com/dansautoparts.com

If a customer hits http://www.dansautoparts.com, and we detect that he does not support SNI, we immediately redirect the customer to http://generic-autoparts.com/dansautoparts.com. He shops on there, and at checkout he uses https://generic-autoparts.com/dansautoparts.com

现在，如果客户点击 https://www.dansautoparts.com DIRECTLY（链接在电子邮件，搜索引擎中的索引页），你是运气不好。他们会得到一个讨厌的证书错误。在我们的例子中，我们确保系统发送的所有电子邮件都不使用https，并且我们知道搜索引擎没有将我们的https网页编入索引。

Now, if a customer hits https://www.dansautoparts.com DIRECTLY (link in e-mail, indexed page in search engines), you are out of luck. They'll get a nasty certificate error. In our case, we made sure all e-mails our system sent didn't use https, and we knew that search engines had not indexed our https pages.

每个环境有不同的挑战和潜在的权衡。我们发现这在我们的案例中运作良好，客户会接受（或不通知）重定向到 http：// generic-autoparts。 com / [ORIGINAL DOMAIN] .com。我们还通过generic-autoparts.com保持结帐安全。

Each environment has different challenges and potential trade-offs. We found that this worked well in our case and customers would "accept" (or not notice) getting redirected to http://generic-autoparts.com/[ORIGINAL DOMAIN].com . We also kept checkout secure through generic-autoparts.com.

假设20％的非SNI用户注意到重定向，似乎有点腥，他们离开。在我们的例子中，这是0.8 - 0.9％（基于2014年3月8日的数字）的用户，我们愿意生存。我现在没有这方面的具体数据，但总体销售保持稳定。

Let's say 20 % of nonSNI users notice the redirect, it seems fishy, and they leave. In our case, that's 0.8 - 0.9 % (based on March 8th, 2014 numbers) of users and we were willing to "live" with that. I don't have specific data on this right now, but overall sales held steady.

实施更新2014年7月8日

事实证明，不可能在服务器上静态检测每个UA代理字符串。我们实现了以下JavaScript来检测浏览器的SNI能力。一般的方法是对一个需要SNI的域（Apache支持通过SSLStrictSNIVHostCheck on）执行一个JSONP请求。如果JSONP请求因超时而失败，我们会将客户重定向到非SNI域。

Turns out that it's impossible to detect every UA Agent string statically on the server. We implemented the following JavaScript to detect the browser's SNI capability. The general approach is to do a JSONP request against a domain that requires SNI (Apache supports this through "SSLStrictSNIVHostCheck on"). If the JSONP request fails by timing out, we redirect the customer to the nonSNI domain.

为了进一步复杂的问题，我们不想重定向每个人，只因为SNI_TEST_DOMAIN下。如果JSONP请求失败（由于没有直接检测到JSONP失败的方法而超时），我们通过执行HTTP运行状况检查请求来验证服务器是否可用。此外，我们不想在每个页面加载运行这个JavaScript代码，因为这增加了一些奇怪的超时和不正确地重定向很多客户的机会，所以我们设置一个会话变量一旦SNI检查完成，所以不会发生

To further complicate matters, we do not want to redirect everyone just because the SNI_TEST_DOMAIN is down. If the JSONP request fails (by timing out since there's no way to detect a JSONP failure directly), we verify that the server is available by doing an HTTP "health-check" request. In addition, we do not want to run this javascript code on every page load, since that increases the chance of some strange timeout and incorrectly redirecting many customers, so we set a session variable once the SNI check is done so it won't happen again as the customer navigates the sites.

我们知道，由于JSONP超时不可靠，我们得到一些失败的错误检查，但自实施以来，我们没有收到任何投诉

We know that we get certain false checks that fails due to the JSONP timeout being unreliable, but since implementing this we are getting no complaints from customers.

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：

snitest.php / sni_healthcheck.php:

<?php
if (array_key_exists('callback', $_GET))
{
    header( 'Content-type: application/javascript' );
    echo "{$_GET['callback']}();\n";
}

这篇关于SNI实际上是在浏览器中使用和支持吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！