IIS 日志显示 sc-win32-status=64 但仅通过某些网络

Question

我有一个在客户端服务器（W2k3、IIS6、.NET 2.0）上运行的 ASP.NET 应用程序。FWIW，这是一个测试实例，它还没有进入生产阶段。所以它不在 SSL、负载平衡等下运行。

当我从我们的办公室访问他们服务器上的其中一个页面时，该页面会被点击一次。检查 IIS 日志 (c:WINDOWS\system32\LogFiles\W3SVC1) 显示该页面的 GET，然后我按下页面上的按钮，日志文件显示 POST。到目前为止，这似乎工作正常。

现在，当我远程进入客户端的网络并从他们的一台本地机器访问页面时，日志文件显示一个 GET，然后我按下页面上的按钮，日志在同一秒显示两个POST。第一个显示状态（sc-status、sc-substatus、sc-win32-status）200 0 64，第二个显示200 0 0。

在日志文件中，两个 POST 是相同的。基本上日志看起来像这样（除了我屏蔽了一些数据）：

#Fields: 日期时间 s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status 
2009-08-11 20:19:32 xxxx GET /File.aspx - 80 - yyyy Mozilla/4.0+（兼容；+MSIE+8.0；+Windows+NT+6.0；+WOW64；+Trident/4.0；+SLCC1； +.NET+CLR+2.0.50727;+.NET+CLR+3.5.21022;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30618;+MDDR;+OfficeLiveConnector.1.4;+OfficeLivePatch .0.0) 200 0 0
2009-08-11 20:19:45 xxxx POST /File.aspx - 80 - yyyy Mozilla/4.0+（兼容；+MSIE+8.0；+Windows+NT+6.0；+WOW64；+Trident/4.0；+SLCC1； +.NET+CLR+2.0.50727;+.NET+CLR+3.5.21022;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30618;+MDDR;+OfficeLiveConnector.1.4;+OfficeLivePatch .0.0) 200 0 64
2009-08-11 20:19:45 xxxx POST /File.aspx - 80 - yyyy Mozilla/4.0+（兼容；+MSIE+8.0；+Windows+NT+6.0；+WOW64；+Trident/4.0；+SLCC1； +.NET+CLR+2.0.50727;+.NET+CLR+3.5.21022;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30618;+MDDR;+OfficeLiveConnector.1.4;+OfficeLivePatch .0.0) 200 0 0

问题是，页面被点击了两次。数据库对第一个请求执行一个操作，然后第二个请求检测到正在执行重复操作并抛出错误消息。用户认为他们的操作失败了，但实际上它成功了。

sc-win32-status 64 的错误描述是：“指定的网络名称不再可用。” 这让我相信，鉴于两个 POST 请求都显示 200 的 HTTP 状态，服务器成功地为请求提供服务，但客户端从未收到通知并重新提交请求。

• 我该如何解决这个问题？

• 任何想法可能仅在其内部网络上导致这种行为？

• 我应该提到，这是在两个不同的客户现场发生的事情，但不是我们的其他客户现场六发生，或者在我们的办公室，或者连接到任何我们的八个客户在网上。

• 什么可以使这种情况在本地网络上 100% 的时间可重现，而在其他任何地方的时间为 0%？

更新：我发现极少数重复的 POST 请求的 sc-win32-status 为 995，而不是最初报告的 64。sc-win32-status=995 的错误描述是：“由于线程退出或应用程序请求，I/O 操作已中止。” 这没有任何意义（考虑到我可以完全访问代码）。我仍然不明白这个问题是如何或为什么发生的，但新的错误代码让我相信这可能不是网络问题，我现在正在调查随机代码错误的可能性。

Answer 1

到目前为止，这是我对这个问题的理解：

• sc-win32-status 64 表示“指定的网络名称不再可用”。
• 在 IIS 将最终响应发送到客户端后，它通常会等待来自客户端的 ACK 消息。
• 有时客户端会重置连接而不是将最终 ACK 发送回服务器。这不是正常的连接关闭，因此 IIS 会记录“64”代码。
• 许多客户端在完成连接后会重置连接，以释放套接字而不是将其留在 TIME_WAIT/CLOSE_WAIT 中。
• 代理往往比其他人更倾向于这样做。

更新：我在这里和这里发现了一些有趣的信息，所以我基本上重新编写了页面以确保没有任何错误的标记等......问题现在消失了！这只是黑暗中的一个镜头，我不能肯定地说是什么解决了问题，因为它只在某些非常特定的情况下影响了我们的一些客户......