Asp.net 根据15秒的请求，连接被强制关闭

我有一个对我自己的服务的请求，需要15秒才能完成服务。应该不是问题吧？实际上，我们有一个服务端计时器，因此最多需要15秒才能完成。但是，客户端看到“连接被强制关闭”，并且自动（在System.Net层中——我通过打开诊断程序看到）重试GET请求两次

哦，BTW，这是一个非SOAP情况（WCF 4 REST服务），所以中间没有SOAP的东西。另外，我的客户端是一个程序，而不是浏览器

如果我把时间缩短到5秒（我可以人为地这么做），重试就会停止，但我无法解释为什么要这么快断开连接。HttpWebRequest.KeepAlive标志在默认情况下为true，并且未被修改，因此连接应保持打开状态

重试的时间安排很有趣。它们出现在我们选择的任何超时结束时（例如10、15秒或其他），因此客户端似乎只有在得到第一个响应后才做出反应

另一件事：服务端没有问题的迹象。它工作得很好，但是（对我来说）看到了来自客户端的请求的两次令人惊讶的重试

我在谷歌上搜索了这个问题，结果一无所获。keep alive的标准是100秒以上，所以我仍然不明白客户机为什么会这样做——而且行为是在System.Net层内，所以我无法通过它

任何帮助都将不胜感激

---

==Tevya=

更改您的服务，使其在关闭连接之前向客户端发送超时指示。

听起来像是硬件（路由器、防火墙、负载平衡器？）由于某些配置选择而发送RST。

我找到了答案，它几乎与超时无关。相反，问题与使用响应数据的自定义序列化有关。respose数据结构具有一些动态显示的类型，因此无法通过常规ASP.NET机制序列化

为了解决这个问题，我们创建了一个XmlObjectSerializer对象，然后将它和要序列化的对象一起传递到

System.ServiceModel.Channels.Message.CreateMessage（）

。这里有两件事出了问题：

消息[how and why I will not to here]中添加了一个意外类型，这导致序列化失败，并且

事实证明，

CreateMessage（）

方法不会立即序列化内容，而是将序列化延迟到稍后某个时间（可能刚好及时） 这两个事实一起在服务器端导致了不可调度的序列化失败，因为在用户编写的服务代码将控制权返回到WCF基础结构之前，没有实际尝试序列化对象

为什么看起来像是超时？事实证明，并不是所有返回的对象都包含意外的对象类型。特别是，前N个对象没有。因此，当时间限制延长到5秒以上时，第N+1个对象确实引用了未知类型，并包含在下载中，从而破坏了序列化。后来的测试证实，即使只有一个对象被传回，故障也可能发生

解决方案是预处理对象，以便不引用意外类型。然后一切顺利

---

==Tevya==

请详细说明您的解决方案。该服务不会显式关闭连接。即使如此，我也不知道在ASP.NET环境中如何向客户端发送超时指示。第三，请求没有超时。请求仅持续15秒。客户端应该能够等待那么长的时间。然后，服务似乎会隐式地关闭连接。很抱歉，我不熟悉您的基础架构层，无法解释这是如何发生的。