我们有一堆WCF服务几乎一直在使用，使用各种绑定，端口，最大大小等。关于WCF的超级令人沮丧的事情是当它（很少）失败时，我们无力找到为什么失败了。有时您会收到如下消息：
System.ServiceModel.CommunicationException： 套接字连接已中止。 这可能是由错误引起的 处理您的消息或接收 远程超过超时 主机或底层网络 资源问题。本地套接字超时 是'01：00：00'。 ---＆GT; System.IO.IOException：无法读取 来自传输连接的数据： 现有的联系是强行的 由远程主机关闭。
问题是它给你的本地套接字超时只是一种方便的尝试。它可能是也可能不是问题的原因。但好的，有时网络有问题。没什么大不了。我们可以重试或者其他什么。但这是一个巨大的问题。除了没有告诉你哪个超时（如果有的话）导致失败（“你的服务器端接收超时被超出”或其他什么，将会有所帮助）之外，WCF似乎有两种类型的超时。
超时类型＃1） 超时，如果增加，将增加您的操作成功的机会。所以，相关的超时是一个小时，你上传一个需要一小时二十分钟的巨大文件。它失败。你增加超时，它成功。我对这种类型的超时没有任何问题。
超时类型＃2） 超时仅定义了您必须等待服务实际失败并给出错误的时间，但修改了这个超时对成功的机会没有影响。基本上，在服务请求的第一秒发生了某些事情，这会使事情变得糟糕。它永远不会恢复。 WCF不会神奇地为您重试网络连接。很好，有时建立网络连接并不顺利。但是，如果你的超时是2小时，你必须等待整整2个小时而没有机会它才能最终确认它不起作用并且给你错误。
但是你在两种情况下看到的错误都是一样的。超时类型＃2，它仍然看起来你正在超时。但是，您可以将所有超时时间增加到4年，而它所要做的就是花费4年时间才能收到错误消息。我知道类型＃2存在是因为我可以做一个已知在成功后不到一分钟就完成的操作，并且需要2个小时才能失败。但是，如果我杀了它并重试，它会很快成功。 （如果您想知道为什么在不到一分钟的操作中可能会有2小时超时，有时我会使用更大的文件运行操作，这可能需要一个多小时。）
因此，为了解决Type＃2的问题，你希望你的超时非常快，以便你立即知道是否存在问题。然后你可以重试。但是难以克服的问题是因为我不知道哪些超时是失败的原因，我不知道哪种超时是＃1型，哪些是＃2型。可能有一个超时（假设客户端发送超时）在某些情况下类似于＃1类型而在其他情况下类似＃2。我不知道，我无法找到答案。
有没有人知道如何追踪Type＃2超时，这样我就可以将它们设置为低值，而不必缩短实际（读取：类型＃1）超时并降低成功率？
谢谢。
澄清类型＃2超时以回应Andrew Anderson的评论：
我认为客户端请求与开始在服务器上执行的代码之间出现问题。在我们有服务器代码指示部分进度的所有情况下，如果没有完成整个操作，它就永远不会完成一些操作。因此，服务器代码永远不会执行，执行所需的时间是无关紧要的（除了它影响我们首先设置我们的超时值以便容纳它）。
答案 0 :(得分：3)
我总是在长时间运行的WCF服务中添加“心跳”消息。然后，您可以将类型＃1超时设置为较低的值（心跳呼叫频率的2-3倍），并且类型＃2超时变得明显。
答案 1 :(得分：0)
要了解哪个特定超时导致超时或其他错误，请配置并使用tracing。
答案 2 :(得分：0)
我遇到了同样的问题，而且它与硬件坏了有关，而且调试真的很困难，还有wireshark（tcp sniffer）数据包没有显示任何特定错误，我们发现了一些tcp-重试，这可能是一个症状，但实际上数据包只是卡在调制解调器路由器内的某个地方，这是一个电信调制解调器（倍耐力门2加），改变调制解调器/路由器后，问题完全消失。
无论如何，我们发现wsHttpBinding over http，对于没有控制权的互联网连接更可靠，而且你无法确定网站上安装了什么硬件。
希望这也有助于其他人：）
答案 3 :(得分：0)
确保您正确处理服务异常。如果未正确处理异常，您将经常获得无理由退出的连接。此外，如果他们这样做，并且他们处理得当，您通常可以获得更多有用的信息：
https://msdn.microsoft.com/en-us/library/ms733721(v=vs.110).aspx
此外，使用可以从客户端调用的“Heartbeat”或常规ping方法。我发现客户端路由器在TCP连接中内置了自动超时，用于终止空闲连接。如果没有心跳方法，客户端路由器可能会过早地结束不受WCF服务设置影响的连接