WCF流传输超时问题：无MTOM是否可行及客户端适配疑问

首先明确回答你的第一个问题：WCF的流传输完全不需要依赖MTOM就能正常工作，MTOM只是WCF用来优化二进制数据传输的一种编码方式，而非流传输的必要条件。

关于MTOM的补充说明 #

MTOM的核心作用是避免把二进制数据编码成Base64（这种编码会让数据体积膨胀约30%），它会将二进制内容和XML报文分开传输，提升大文件传输的效率。但如果你的场景（比如Mono客户端兼容性）要求关闭MTOM，完全没问题——只要你的绑定配置了正确的流传输模式（比如TransferMode.Streamed、StreamedResponse或StreamedRequest），WCF依然能通过普通的SOAP报文（甚至纯文本编码）实现流传输，只是可能在传输效率上略有损失，但功能完全正常。

针对ReceiveAsync后下载流超时的解决思路 #

你遇到的超时问题，大概率是配置或流处理环节的限制导致的，下面是几个常见的排查和修复方向：

• 调整绑定的超时参数
  默认情况下WCF绑定的ReceiveTimeout和SendTimeout只有1分钟，对于大文件下载来说肯定不够。你需要在客户端和服务器的绑定配置里都调大这些值，比如：

  <!-- 服务器端web.config示例 -->
  <bindings>
    <basicHttpBinding>
      <binding name="StreamedBinding" 
               transferMode="StreamedResponse"
               receiveTimeout="00:10:00"
               sendTimeout="00:10:00">
      </binding>
    </basicHttpBinding>
  </bindings>
  

  客户端的配置也要对应修改，确保两端的超时设置匹配。

• 检查IIS的请求限制
  托管在IIS上的WCF服务，还会受到IIS自身的配置限制：

  1. 在web.config的<system.web>节点下，调整ASP.NET的执行超时和最大请求长度：

     <httpRuntime executionTimeout="600" maxRequestLength="1048576" />
     

     这里executionTimeout单位是秒（600=10分钟），maxRequestLength单位是KB（1048576=1GB）。
  2. 如果是IIS 7及以上版本，还要在<system.webServer>节点下设置maxAllowedContentLength（单位字节）：

     <security>
       <requestFiltering>
         <requestLimits maxAllowedContentLength="1073741824" />
       </requestFiltering>
     </security>
     

• 优化客户端流读取逻辑
  调用ReceiveAsync获取流之后，确保你的读取逻辑高效且正确：

  • 使用较大的缓冲区（比如4KB或8KB）读取流，避免频繁的IO操作；
  • 读取完成后及时调用Stream.Dispose()释放资源，防止连接被长时间占用；
  • 不要在读取流的过程中做阻塞性的耗时操作，避免触发超时。

• 排查网络环境因素
  因为你的客户端是基于Mono的macOS应用，还要考虑跨平台网络环境的影响：比如防火墙、代理服务器是否会主动截断长时间的连接，或者网络延迟过高导致传输变慢触发超时。可以先在局域网内测试，排除外部网络的干扰。

• 考虑分块传输优化
  如果传输的文件特别大，也可以考虑把数据分成多个小块，分多次请求传输，这样既避免了单次请求超时，也提升了传输的容错性。

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