WCF服务超MaxReceivedMessageSize后为何出现不同错误类型？

Great question—this is a super common gotcha with WCF’s message size limits, and it all comes down to how the WCF runtime handles message reception at different stages. Let’s break this down step by step:

为什么两种超出配额的场景会触发不同错误？ #

1. 略大于MaxReceivedMessageSize的情况（x字节） #

当消息只是刚超过配额时，WCF仍能先读取消息头。消息头包含了消息的元数据，包括它的总大小。一旦WCF检测到声明的大小超过MaxReceivedMessageSize，就会立即终止连接并返回明确的配额超限错误。这个过程发生在接收完整消息之前，所以客户端能收到预期的精准错误。

2. 远大于配额的情况（2x字节） #

当发送的消息远大于配额时，在WCF能够正确验证消息大小之前，就会出现一系列问题：

• 缓冲区耗尽：WCF使用缓冲区接收传入数据。如果消息大到在运行时检查总大小之前就填满了配置的缓冲区（由MaxBufferSize控制，默认与MaxReceivedMessageSize匹配），底层传输层（比如TCP）会直接中止套接字连接。
• 超时触发：如果消息传输耗时过长（因为体积太大），绑定的ReceiveTimeout会在WCF读完足够消息以检测配额违规之前触发。传输层断开连接，客户端只能看到超时或套接字中止错误。
• 缓冲模式限制：如果使用默认的缓冲传输模式，WCF会尝试先将整个消息加载到内存中。对于2x大小的消息，这个内存操作会失败或耗时过久，导致传输层故障而非配额错误。

简单来说：超大消息会先引发传输层故障，WCF的配额验证逻辑还没来得及运行并向客户端发送正确的错误响应。

如何让客户端收到明确的配额超限错误？ #

要确保即使是超大消息，客户端也能收到清晰的“配额超限”错误，需要在客户端和服务器端的绑定中调整以下设置：

• 同步MaxBufferSize与MaxReceivedMessageSize：对于非流式绑定，MaxBufferSize必须等于或大于MaxReceivedMessageSize（默认两者匹配，但如果手动修改过其中一个，需要同步）。这能保证WCF有足够的缓冲区空间读取消息头并验证大小，避免缓冲区提前耗尽。
• 临时增加超时时间：调高绑定的ReceiveTimeout和SendTimeout。这给WCF足够的时间接收足够的消息以检测配额违规并发送错误响应，而不是先触发超时。
• 在服务器端启用详细错误日志：添加WCF追踪来捕获服务器端的精确错误（即使是传输中止）。然后可以使用自定义错误处理器捕获底层的配额异常，并将其映射为客户端可识别的明确错误。
• 考虑为大负载启用流式传输：如果经常发送大数据，切换到TransferMode.Streamed或TransferMode.StreamedRequest/StreamedResponse模式。流式传输避免将整个消息加载到内存中，WCF可以更早地对照MaxReceivedMessageSize验证流大小，减少传输层中止的概率。

例如，以下是在配置中更新基本HTTP绑定以对齐设置的示例：

<bindings>
  <basicHttpBinding>
    <binding name="LargeMessageBinding"
             MaxReceivedMessageSize="10485760"
             MaxBufferSize="10485760"
             ReceiveTimeout="00:10:00"
             SendTimeout="00:10:00">
      <readerQuotas maxDepth="32" maxStringContentLength="10485760" />
    </binding>
  </basicHttpBinding>
</bindings>

内容的提问来源于stack exchange，提问作者Srihari