为什么 AzureSearch SDK 会因传输连接问题自发失败？
Why would AzureSearch SDK spontaneously fail with transport connection issue?
昨天我们很兴奋。我们的两个使用 AzureSearch SDK 的 Web 应用程序（均已部署且至少 3 个月未受影响）在不同时间停止工作（一个清晨；另一个在晚上）。 indexClient.Documents.Search 方法开始失败并出现此错误：
与 XXXXsearch.search.windows.net（对于 #435）的 HTTPS 握手失败。 System.IO.IOException 无法从传输连接读取数据：远程主机强行关闭了现有连接。 <现有连接被远程主机强行关闭
经过疯狂的 google 争夺后，我们在修复它的搜索之前添加了这 3 行。
const SslProtocols _Tls12 = (SslProtocols)0x00000C00;
const SecurityProtocolType Tls12 = (SecurityProtocolType)_Tls12;
ServicePointManager.SecurityProtocol = Tls12;
我能想象的是我们错过了某种 "AzureSDK is changing" 电子邮件？这非常糟糕，我们幸运地找到了快速解决方案，否则这可能是一场灾难。有谁知道为什么会这样？
传输连接错误是 Azure 搜索中 known issue 的结果。
偶尔会出现意外的连接问题。稍后再通过索引器尝试 运行 文档。更详细的可以参考这个article.
我是 Azure 认知搜索工程团队的项目经理。首先，得知您和其他人由于最新的服务更新取消了对 TLS 1.0 和 1.1 的支持而遇到客户端连接问题，我深表遗憾。这些类型的更改很少见，我们努力在任何更新中永远不会破坏客户代码。在这种情况下，帮助保护通过 Internet 传播的信息的隐私至关重要。 TLS 1.2 是一种标准，可提供比以前版本更高的安全性。您可以了解有关此内容的更多信息 here。
可以找到有关如何解决此问题的更多信息 here。我们强烈建议您避免对 TLS 版本进行硬编码（如上所述），因为 TLS 1.2 最终将被最新发布的标准 TLS 1.3 取代，后者速度更快且安全性更高。最好让 .NET 或 OS 为您选择 TLS 版本，但这在上面的链接中有更多讨论。
我们在 1 月初就门户中即将发生的变化发送了通知，但我们意识到很容易错过这些变化，并为随后造成的问题道歉。请知道我们想尽我们所能提供帮助。由于我们被要求不要使用 Whosebug 来帮助解决个别支持案例，如果您需要有关您的服务的个人帮助，我们会要求您打开 support case.
昨天我们很兴奋。我们的两个使用 AzureSearch SDK 的 Web 应用程序（均已部署且至少 3 个月未受影响）在不同时间停止工作（一个清晨；另一个在晚上）。 indexClient.Documents.Search 方法开始失败并出现此错误：
与 XXXXsearch.search.windows.net（对于 #435）的 HTTPS 握手失败。 System.IO.IOException 无法从传输连接读取数据：远程主机强行关闭了现有连接。 <现有连接被远程主机强行关闭
经过疯狂的 google 争夺后，我们在修复它的搜索之前添加了这 3 行。
const SslProtocols _Tls12 = (SslProtocols)0x00000C00;
const SecurityProtocolType Tls12 = (SecurityProtocolType)_Tls12;
ServicePointManager.SecurityProtocol = Tls12;
我能想象的是我们错过了某种 "AzureSDK is changing" 电子邮件？这非常糟糕，我们幸运地找到了快速解决方案，否则这可能是一场灾难。有谁知道为什么会这样？
传输连接错误是 Azure 搜索中 known issue 的结果。
偶尔会出现意外的连接问题。稍后再通过索引器尝试 运行 文档。更详细的可以参考这个article.
我是 Azure 认知搜索工程团队的项目经理。首先，得知您和其他人由于最新的服务更新取消了对 TLS 1.0 和 1.1 的支持而遇到客户端连接问题，我深表遗憾。这些类型的更改很少见，我们努力在任何更新中永远不会破坏客户代码。在这种情况下，帮助保护通过 Internet 传播的信息的隐私至关重要。 TLS 1.2 是一种标准，可提供比以前版本更高的安全性。您可以了解有关此内容的更多信息 here。
可以找到有关如何解决此问题的更多信息 here。我们强烈建议您避免对 TLS 版本进行硬编码（如上所述），因为 TLS 1.2 最终将被最新发布的标准 TLS 1.3 取代，后者速度更快且安全性更高。最好让 .NET 或 OS 为您选择 TLS 版本，但这在上面的链接中有更多讨论。
我们在 1 月初就门户中即将发生的变化发送了通知，但我们意识到很容易错过这些变化，并为随后造成的问题道歉。请知道我们想尽我们所能提供帮助。由于我们被要求不要使用 Whosebug 来帮助解决个别支持案例，如果您需要有关您的服务的个人帮助，我们会要求您打开 support case.