我们最近为我们的Web服务器实现了一个新的ASP.NET站点，以替换旧的Classic ASP站点（两个服务器都是使用IIS 7.5的Windows 2008 R2）。它们托管在Load Balancer上。
这个.NET webform应用程序用于大约30个客户端（每个客户端都有自己的URL .client1.mysite.biz，client2.mysite.biz等...）
我们最初的计划是将我们的新应用程序部署到3个“网站”中，每个网站都有自己的应用程序池，并将客户端绑定到相关网站。
绑定时，我们绑定了URL的Http和Https（我们有每个站点的证书）
初步问题： 我们注意到，在我们绑定了超过一半的网站并进行测试后，我们突然受到了“服务不可用。服务暂时不可用”（每次都没有数字）的问候。我们解开所有内容并再次尝试（每次绑定网站时都会仔细测试）。每次绑定一定数量的网站后，都会发生同样的事情。
我们用完了停机时间，然后去了B计划。我们把整个东西放在“默认网站”中作为虚拟目录（没有绑定）（这就是经典ASP网站的设置方式）
我们现在的问题： 偶尔我们会得到相同的可怕的白色屏幕“服务不可用。服务暂时不可用”（只有单词没有数字）。 它似乎是随机发生的（据我们所知，不是负载或时间依赖）。如果使用AJAX，它只是被捕获在AJAX代码的“错误”部分，但我相信它是同样的问题。当它确实发生时，错误会立即发生。如果用户尝试重复导致问题的操作，一切都很好（他们没有注销，他们继续前进）。
然而，这种情况每天发生多次，而且它遍及我们所有的网站（不仅仅是这个新网站）。
还有一件非常重要的事项。这似乎发生在我们所有的站点（我们的Web服务器上的虚拟目录和自定义Web站点）。这似乎排除了一个“糟糕”的服务器（两者都在我提到的云中吗？）并且“似乎”似乎“排除”应用程序池设置，但我知道什么？
关于我们的IIS服务器：我们有多个应用程序池运行多个不同的网站实例（不同的代码）。有些是测试网站。有些人正在使用经典的ASP和其他人并使用ASP.NET。
我们尝试了什么：我们搜索网页寻找答案并编辑了我们的machine.config文件以增加各种方式，例如“线程，最大连接等......” 。我们通过增加队列长度并打开所有日志来编辑我们的应用程序池设置。
之前有人见过这样的事吗？我的理论是它与绑定有关，并且我发起的每个绑定都增加了错误的频率，但是当它仅在我的生产服务器上发生时很难测试。
答案 0 :(得分：1)
我们终于解决了这个问题。如前所述，我们注意到当我们的网站使用sc-win32-status 64时（当且仅当）我们在浏览器中遇到Service Unavailable问题时，IIS日志包含Load Balancer错误。
为了帮助我们进一步研究，我们在测试时对Load Balancer的流量进行了网络捕获。我们重现了随机Service Unavailable问题，在IIS日志中看到了相关的win32-status 64错误，并确定了此事件的网络捕获上的特定流量数据包。
使用Wireshark，我们按照TCP流注意到此数据包后立即由Load Balancer重置TCP连接。我们将问题重复了三次，并且每次都会立即重置TCP。
向后走过TCP流，我们在所有三个实例中都注意到HTTP/1.1 200 (accplication/octet-stream)的数据包，在此之前我们从我们的一个文件中下载文件（即.pdf或.xlsx或.docx）的请求站点。包含所有文档的服务器不是Web服务器，并且没有IIS角色处于活动状态。文档服务器无法定义正在下载的文档的内容/媒体类型。因此，网络捕获中的通用（应用程序/八位字节流）数据包。 Load Balancer将对文档的请求视为潜在恶意，并决定在发出另一个请求时重置TCP连接。为解决此问题，我们使用此post作为指南，为我们的应用程序添加了内容类型库函数。排序！
摘要：
application/octet-stream 经验教训：
如果您从非Web服务器或运行IIS版本低于7的Web服务器提供内容，则始终定义您的内容/媒体类型（天堂禁止）。
答案 1 :(得分：0)
UC证书最初用于Microsoft Exchange，但它也可用于覆盖多个域。我们使用一个，它涵盖了大约60多个域（实际上有4或5个具有大量子域的域）。我们还将证书应用于负载均衡器和两个Web服务器，并且我们有多个站点。据我所知，证书可以按预期运行。您可以从60多个域中的任何一个查看它。关于我们设置的一个奇怪的事情是，在IIS UI中，您无法将同一证书绑定到多个站点，因此我们必须使用appcmd命令行界面将多个站点绑定到同一证书。
答案 2 :(得分：0)
在仔细查看我们的IIS日志后，似乎确实存在与此行为相符的内容。我们得到200 0 64的错误，这是sc-win32-status 64：“指定的网络名称不再可用”。
现在我们的2台IIS服务器托管在Sungard的云端，我们正在使用他们为我们设置的负载均衡器。我们的理论是，当发生64错误时，负载均衡器正在“丢失”用户的正确会话ID，并且不知道它应该在何处。
我们进行了一些受控测试。一组我们取消了负载均衡器并将它们直接发送到其中一台服务器而另一组使用了负载均衡器，但确保连接到同一台服务器。两个团队都进行了试图重现错误的测试（也就是说我们一遍又一遍地点击了网站上的弹出窗口）。
结果很有趣。不在负载均衡器上的组永远不会收到“服务不可用”错误！但是日志表明他们得到了64次错误45次。负载均衡器上的WAS能够生成“服务不可用”消息两次，并且日志确认正好有2个64错误的实例与观察到错误的确切时刻一致。
那是什么意思呢？ 1.）负载均衡器有一些设置“Sticky Sessions？”这些会议没有保持正确的会议（但我们找不到合适的设置。甚至我们的负载平衡器也不是SunGard的）。有人对ASP.NET的这些设置有任何建议吗？
2。）64个错误是网络生活的一部分？我们为其中一个虚拟IIS服务器提供了更多的CPU功率，并且收到的错误更少。这就是我能想到的。我们已经花费了太多的时间和金钱试图解决这个问题，但似乎我有一个选择，至少让人们离开负载均衡器并将它们路由到一个或另一个服务器，此外我至少可以加强服务器处理更多流量并减少64个错误。