我使用https://www.ssllabs.com/ssltest/扫描服务器的SSL / TLSconfiguration，并报告Session resumption (caching) No (IDs assigned but not accepted)
我在循环负载均衡器后面使用了2个Azure Webangular色实例。 我相信由于会话ID被caching在一台服务器上而不是另一台服务器上，会话恢复被破坏了。
如何configurationIIS使用共享caching（最好是Redis）的会话ID？
更新：
似乎没有共享会话caching的方法。 但是，Windows Server 2012 R2似乎支持无状态（基于故障单）会话http://technet.microsoft.com/en-us/library/hh831771.aspx#BKMK_Changes2012R2 。
尝试将HKLM SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ MaximumCacheSize设置为0，如http://technet.microsoft.com/zh-cn/library/dn786418.aspx#BKMK_SchannelTR_IssuerCacheSize中所述，以禁用会话caching，但没有任何影响。
尝试使用New-TlsSessionTicketKey和Enable-TlsSessionTicketKey（ http://technet.microsoft.com/en-us/library/dn296629.aspx ）启用基于票证的会话，但也没有效果。
任何人都设法使这些设置工作？
更新2：
通过设置两者来成功禁用会话caching
并重新启动服务器
尽pipe为IIS AppPool\{app pool GUID}和Network Service运行Enable-TlsSessionTicketKey命令，仍然无法让票证工作
最后，find了在win2k12 r2和win2k16上启用TLS会话票据的方法。 您需要遵循以下步骤：
在值为1的HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\EnableSslSessionTicket创build一个registry项（ DWORD ）
通过这个powershell命令创build一个新的TLS会话票证密钥： New-TlsSessionTicketKey -Password <password> -Path "C:\KeyConfig\TlsSessionTicketKey.config" -ServiceAccountName "System" https://technet.microsoft.com/en-us/itpro/powershell/windows/tls/new-tlssessionticketkey
通过这个powershell命令启用TLS会话票证密钥： Enable-TlsSessionTicketKey -Password <password> -Path "C:\KeyConfig\TlsSessionTicketKey.config" -ServiceAccountName "System" https://technet.microsoft.com/en-us/itpro/powershell/windows/tls/enable-tlssessionticketkey
重新启动服务器以启用TLS会话票据生成。 要使registry项生效，需要重新引导。
重要：要在负载均衡的服务器上重复使用相同的TLS会话票据，需要在其中一台服务器上复制运行“ New-TlsSessionTicketKey ”命令后生成的“ C:\KeyConfig\TlsSessionTicketKey.config ”文件，然后复制configuration文件在所有剩余的服务器上，并在每个文件上运行“ Enable-TlsSessionTicketKey ”powershell命令。 不幸的是，这只适用于win2k16。 它不能在win2k12r2上工作。
有关会议可能会有一些误解。
大多数Web应用程序都使用该会话来在多个HTTP请求之间创build持久性，即购物车的固有内容。 这不是SSLLabs正在testing的内容。
无论如何：当使用负载平衡器时，您通常应该复制该会话状态，以便在随后的HTTP请求分发到不同的后端Web服务器时，访问者不会收到空的购物车。
SSL / TLS会话也是SSLLabs正在testing的内容。
简而言之，当SSL连接build立时，networking服务器和浏览器首先使用计算上相对昂贵的公钥握手/协商（Diffie-Hellman）。 该协商的一部分是build立一个对称密钥，对于那个特定的连接是唯一的，这个密钥将被用于随后在该连接上传输的数据的encryption/解密。 对称encryption仍然是安全的，但计算相对便宜，这样就减less了networking服务器和网页浏览器的负载。 与普通的HTTP不同的是，浏览器会将HTTPS连接保留在networking服务器的打开状态，并将其用于多个HTTPS请求，但是在空闲一段时间之后，连接仍然会被closures。
这就是SSL会话caching起作用的地方。 如果启用，而不是协商新的对称密钥，则networking服务器可能允许网页浏览器在新的连接上重新使用旧的对称密钥。 这样做的好处是可以更快地build立一个新的连接（它节省了一些TCP / IP往返和一些繁重的计算），这可能是以我怀疑的安全性为代价的。
我不知道IIS（或其他Web服务器）是否具有将SSL会话高速caching复制到负载类集群中的其他节点的function。 也可能没有必要。 通常在负载均衡器上发生SSL终止，或使用TCP粘性会话来确保后续的HTTPS连接由同一个Web服务器处理，从而消除了Web服务器复制SSL会话高速caching的需要。
如果我sn鼻涕，Web服务器通告支持SSL恢复，但负载均衡器分配新的连接到不同的networking服务器，则会产生不匹配。