在 Internet 上搜索“WCF 超时”会找到大量资料。然而，到目前为止，我还没有找到 解释所有不同超时设置、它们存在的原因以及它们各自的副作用是什么的 place™ 。本文试图将我发现的位和字节综合成一篇综合性文章。
（WCF 将进一步发展——如果您将来偶然发现这篇文章：它是在考虑 WCF 4.5 的情况下编写的。）
WCF 中有不少于 6 次超时，而 WCF 附带的绑定中还有 2 次：
| 财产 | 应用于 | 默认值 |
|---|---|---|
| 打开超时 | 捆绑 | 1分钟 |
| 关闭超时 | 捆绑 | 1分钟 |
| 操作超时 | IContextChannel | （发送超时） |
| 发送超时 | 捆绑 | 1分钟 |
| 接收超时 | 捆绑 | 10分钟 |
| 不活动超时 | 可靠会话 | 10分钟 |
| 通道初始化超时 | ConnectionOrientedTransportBinding | 30秒 |
| 请求初始化超时 | HttpTransportBinding | 无穷 |
此外，它们中的大多数在服务器端和客户端的含义略有不同。那是一大堆，所以让我们一次讨论一个。
从客户端的角度来看，这些超时非常简单：如果无法在配置的时间范围内打开/关闭通信通道，WCF 将引发 TimeoutException。打开/关闭时间跨度包括所有必要的安全握手、协议协商等。在服务器端，该属性会影响 WCF 回调的连接设置和拆除。
注意：如果根本无法建立到服务端点的连接（即服务不可访问），WCF 不会抛出 TimeoutException，而是框架立即抛出 EndpointNotFoundException。
操作超时涵盖整个服务调用（发送请求、处理请求和接收回复）。换句话说，它从客户端的角度定义了服务调用处于活动状态的最长时间。
通常，您不会为每个调用单独设置操作超时。如果未设置，WCF 将使用配置的发送超时初始化操作超时。从另一个角度，您可以说操作超时允许您在必要时覆盖配置的发送超时。
与我最初的意图相反，此配置设置不仅涵盖发送请求的时间。它被 WCF 用作操作超时的默认值。同样，该设置会影响服务器端的 WCF 回调。
可能是最容易被误解的财产。它在客户端被 WCF 完全忽略（它与接收响应所需的时间无关）。服务主机使用此超时来确定何时丢弃空闲连接。如果在配置的时间范围内没有收到任何消息，则关闭连接。当然，这假定配置的绑定具有会话的概念（即，如果与 BasicHttpBinding 结合使用，该属性没有任何效果）。
每当您使用 WCF 可靠消息传递时，必须满足第二个超时以保持连接处于活动状态：非活动超时。与上述接收超时不同，如果接收到基础设施消息，例如保持活动消息，则不活动超时也会重置。在正常情况下，底层基础设施会确保在此超时限制内发送此类消息，因此它通常仅在网络出现故障时才会过期。正如您可能已经得出的结论，将非活动超时设置为高于接收超时的值是没有意义的。
此超时特定于面向连接的传输通道（例如，TCP 或命名管道），并确定通道可以保持初始化状态多长时间。与不活动超时类似，它可以防止恶意调用者打开连接并无限期地阻塞资源。在初始化期间，客户端尚未经过身份验证，这就是为什么您可能希望设置比正常不活动超时更小的时间跨度。
这是我没有找到任何可靠信息的唯一超时。默认值设置为 0 秒，这会停用超时。如果您知道为什么有人想将此超时配置为不同的值，请访问我的相关 StackOverflow 问题。
将所有这些配置值设置为无限可能听起来是克服与超时相关的问题的好主意。通常，安全性是严格的超时限制的原因。它可以防止恶意调用者（和草率的开发人员）阻止服务器上的大量资源。为您的场景找到最佳设置需要一些初步的思考和估计，稍后还应该包括对服务日志的评估。您应该问自己的问题应该包括：客户多久致电一次我的服务运营？服务和客户端之间发送的请求和回复有多大？处理请求需要多长时间？与用户数据相比，建立连接的成本是多少？回答这些问题将导致合理且安全的超时配置。