搞 WCF 的时候很多人容易陷入一个误区以为把服务端写出来、客户端添加服务引用、跑通就完事了。可一旦遇到跨域、代理、负载均衡、Docker 环境或者要从 SOAP 平滑切到 RESTHTTP 层面的东西立刻就会冒出来教做人。第9章我们接着上一章往下聊这次不碰那些“点几下配置就完事”的套路专门把 WCF 与 HTTP 网络编程里容易被忽略、但实战中极其要命的细节掰开揉碎讲清楚包括连接复用、超时控制、状态码处理、抓包分析还有那些让你查一整天都查不出原因的诡异报错。这一章的适用对象很明确已经会用 VS 建 WCF 服务、会添加服务引用的开发但总在部署和联调阶段被 HTTP 层问题卡住的人。如果你还在纠结“为什么本地跑得好好的一到测试环境就各种 400、415、超时”那这章就是给你写的。1. WCF与HTTP不只是“配置个绑定”的事1.1 为什么 WCF 要单独聊 HTTP很多人觉得 WCF 是“远程对象调用”框架跟 HTTP 关系不大其实这只说对了一半。WCF 的传输通道支持 TCP、命名管道、MSMQ但 HTTP 是唯一一个既能做 SOAP 又能做 REST、既能走内网又能穿防火墙、既能被 IIS 托管又能被 Windows 服务自托管的传输方式。我见过不少团队把 WCF 服务部署在内网客户端通过 TCP 绑定直连性能确实好但一旦要对外开放接口给第三方调用或者要接入云上的 API 网关基本都得换到 HTTP 绑定。HTTP 绑定之所以特别是因为它把“传输层”和“消息层”彻底分开了。传输层管字节流怎么走消息层管 SOAP 信封怎么解析、安全令牌怎么附加、消息版本怎么协商。你选择一个绑定实际上是在同时决定这两件事。很多人只关注绑定名字却忽略了绑定背后的 HttpTransportBindingElement、TextMessageEncodingBindingElement 这些要素导致连“为什么请求能到服务端但响应总是 400”这种基础问题都排查不清。我在实战中给团队定的规矩是凡是涉及对外提供接口、跨平台调用、需要负载均衡的场景一律先考虑 HTTP 绑定只有系统内部服务之间追求极致吞吐才用 NetTcpBinding。这是从大量踩坑里总结出来的决策标准不是哪本教科书上抄来的。1.2 HTTP 绑定选型basicHttpBinding、wsHttpBinding、webHttpBindingWCF 里和 HTTP 相关的绑定主要有三种但它们的目标场景完全不同。不少新手在面试或文档里看到这三个名字以为只是“安全性不同”真到写代码时就要出问题。basicHttpBinding 走的是最传统的 SOAP 1.1 HTTP POST消息用的是文本编码兼容性最好。它适合对接老系统、跨语言调用比如 Java 写的 AXIS 服务或者 Python 的 zeep 客户端。它默认不开 WS-Security也不支持 WS-Addressing所以它“笨”但也因为它笨它几乎能被任何 HTTP 中间件理解。你在它上面配个 HTTPS基本就是普通 POST 请求抓包直接能看到全文。wsHttpBinding 则是在 HTTP 之上叠加了 WS-* 协议栈支持 WS-Security、WS-ReliableMessaging、WS-Addressing。它的消息信封里会多出很多头部信息而且默认要求消息级安全这意味着抓包时 body 可能是加密的中间代理也可能因为看不懂扩展头而报错。我在实际项目里只在需要用 Windows 凭证做身份验证、且通信双方都是 WCF 的场景下用 wsHttpBinding。如果你把 wsHttpBinding 暴露给非 .NET 客户端对方大概率会疯掉。webHttpBinding 则是专门为 REST 风格设计的绑定。它不用 SOAP 信封直接用 HTTP 方法GET、POST、PUT、DELETE来映射操作配合 WebGet 和 WebInvoke 两个特性使用。它最大的特点是“让 WCF 看起来不像 WCF”而是像一个普通的 HTTP API。这个绑定在后面第3节会专门展开。我在团队里做过一张选型表这里直接给你参考绑定名称消息格式安全模型适用场景抓包可见性basicHttpBindingSOAP 1.1 文本传输安全为主跨语言互操作、老系统集成body 明文可见wsHttpBindingSOAP 1.2 文本消息安全、传输安全WCF 与 WCF 之间、强安全要求body 可能加密webHttpBindingJSON/XML 明文传输安全或自定义认证REST API、移动端、第三方开放接口body 明文可见这个表格我自己用了很多年直到现在做技术方案评审时还会翻出来看。选型选错了后面所有调试成本都会成倍上涨。1.3 服务契约与消息编码的关系绑定确定了 HTTP 通道怎么走服务契约确定了业务方法怎么暴露而消息编码则是两者之间的桥梁。很多人在 WCF 里遇到过“内容类型不对”的报错根因往往就是编码和绑定不匹配。WCF 支持三种消息编码文本编码Text、二进制编码Binary、消息传输优化机制编码MTOM。文本编码就是标准 XML/JSON所有 HTTP 组件都能解析二进制编码是 .NET 特有的优化格式只适合 WCF 对 WCF而且必须配合 NetTcpBinding 或者带 BinaryMessageEncodingBindingElement 的自定义绑定才能发挥最大价值MTOM 则是为了传输大二进制文件设计的它会将 SOAP 信封里的 base64 数据抽离成 MIME 附件减少报文体积但解析复杂度会高很多。我见过一个真实案例服务端用 wsHttpBinding但自定义了二进制消息编码客户端却老老实实用 basicHttpBinding 生成代理结果每次调用都报“由于消息编码不匹配无法读取消息”。抓包看请求头Content-Type 是 application/soapxml但 body 是二进制乱码。后来我把两端统一成文本编码问题立刻消失。所以我的建议是除非你确定两端都是自家 .NET 应用而且性能要求极高否则一律使用文本编码。在 HTTP 的世界里透明就是最大的美德。2. 抓包分析让HTTP交互“现出原形”2.1 Wireshark 抓取 WCF HTTP 通信的基本姿势WCF 的 HTTP 通信调试最忌讳的就是“凭感觉猜”。我见过有人为了排查一个 400 错误在代码里加了几十行日志最后发现是请求头里多了个空行。浪费时间不说那种挫败感极其打击人。所以遇到 HTTP 相关的问题我的第一反应永远是打开 Wireshark 抓包。Wireshark 抓本机回环流量时有一个坑Windows 上默认不抓 lo 回环接口需要装 Npcap 时勾选“Loopback Adapter”支持或者用 RawCap 之类工具。我实际测下来装 Npcap 时记得把“WinPing”和“Loopback”都勾上否则你抓 localhost 流量会什么都看不到。抓包前最好先把过滤器写好免得抓一堆无关包。HTTP 流量可以直接用http或者http2过滤WCF 的 SOAP 请求也是 HTTP 协议所以http过滤器对它是生效的。如果你想精确到某个端口可以加tcp.port 8080。我通常的习惯是http tcp.port 8080 !icmp这样既能过滤掉 ping 之类的干扰又能看到完整的请求响应。启动抓包后在客户端调用一次服务就能看到从 TCP 三次握手到 HTTP 请求、响应、再到四次挥手的完整过程。这里有个很实用的细节Wireshark 里可以右键任意一个 HTTP 请求包选择“Follow HTTP Stream”直接查看完整的请求头和响应体比在十六进制窗口里一帧一帧翻高效得多。2.2 从请求行到 SOAP 正文一帧一帧看协议当你能看到完整的 HTTP 交互时第一步要会读“请求行”。WCF 的 basicHttpBinding 发出去的请求通常长这样POST /Service1.svc HTTP/1.1 Content-Type: text/xml; charsetutf-8 SOAPAction: http://tempuri.org/IService1/GetData Host: localhost:8080 Content-Length: 456 Expect: 100-continue这里每一行都有意义。POST表示 SOAP 必须用 POST 方法不能改成 GET/Service1.svc是服务地址寻址失败时大多数问题出在这里Content-Type必须和绑定编码匹配basicHttpBinding 是text/xmlwsHttpBinding 是application/soapxml如果客户端硬编码错了就会出现 415SOAPAction是 SOAP 1.1 特有的头很多 Java 框架解析时会校验它空值或错误值会直接导致服务端不认这个操作。再往下看请求体。使用 basicHttpBinding 时请求体就是一段标准的 SOAP XML开头是s:Envelope里面包含s:Header和s:Body。很多开发第一次看到 SOAP XML 会不习惯觉得嵌套太深、信息冗余但你要知道这正是 SOAP 能跨语言互操作的原因——它把方法名、参数名、命名空间都写进了 XML所以 Java、PHP、Python 都能读懂。响应包的结构也类似常见的有HTTP/1.1 200 OK、500 Internal Server Error、400 Bad Request。通过 Wireshark 你能直观看到状态码和错误体。我遇到过最典型的例子是服务端返回 500响应体里却只有一行 “Server Error in /: Application” 的 HTML 页面。这是因为 WCF 默认没有启用异常详情返回你需要设置includeExceptionDetailInFaultstrue才能把具体异常返回给客户端。2.3 常见抓包误区和过滤规则抓包本身不难难的是如何快速定位问题。这里我总结几个自己在实际工作中踩过的误区。第一个误区是只抓 HTTP 层忽略 TCP 层。很多连接层面的问题表现为“请求发出去了但迟迟没有响应”这种情况你只看 HTTP 包是没有用的因为可能请求根本没到达服务端。正确做法是切换到tcp.stream视图看三次握手是否成功看有没有重传、乱序、零窗口。我排过一个大半夜的问题客户端和服务端之间有防火墙TCP 握手能完成但服务端的 FIN 包一直被丢弃导致连接处于半关闭状态客户端表现为“第一次调用成功第二次调用卡死”。这种情况在 HTTP 层完全看不出来必须回到底层 TCP 才能发现。第二个误区是忘记关闭 Windows 的 HTTP 代理或者抓包软件自身的回环绕过。有些抓包软件默认会注入自己的代理导致你抓到的根本不是真实流量。我建议抓包时先把系统代理设置清空尤其是用 Fiddler 抓过包之后再开 Wireshark很可能会有残留配置。第三个误区是过滤规则写得太宽或太严。太宽会看到大量无关 TCP 包太严又可能把需要的包过滤掉。我常用的过滤规则是组合条件比如同时抓回环和指定端口时可以写http (ip.addr 127.0.0.1) tcp.port 8080如果服务端用了 HTTPSWireshark 默认只能看到 TLS 握手看不到 HTTP 明文。这时需要配置 SSLKEYLOGFILE 环境变量。WCF 客户端基于 .NET 不一定直接支持这个变量但可以通过设置ServicePointManager.ServerCertificateValidationCallback加解密追踪来间接实现。不过一般情况下调试 WCF 时把 HTTPS 临时改成 HTTP 更省事等线上再用 HTTPS。3. 从WCF到RESTwebHttpBinding与HTTP动词实战3.1 REST 风格改造WebGet 与 WebInvoke 的映射规则现在很多项目都要求对外提供 REST 风格接口而 WCF 的老基础又是 SOAP两者之间的桥就是 webHttpBinding。我用它做过好几次从 SOAP 到 REST 的改造其中门道不少。webHttpBinding 下的服务契约不再用[OperationContract]默认映射到 SOAP Action而是通过[WebGet]和[WebInvoke]特性来指定 HTTP 方法与 URI 模板。简单说WebGet只支持 GET、HEADWebInvoke可以指定 POST、PUT、DELETE默认是 POST。比如一个普通的方法[OperationContract] string GetData(int value);如果要把它暴露成 REST 风格的GET /Service1.svc/GetData?value1你需要改成[OperationContract] [WebGet(UriTemplate GetData?value{value}, ResponseFormat WebMessageFormat.Json)] string GetData(int value);如果你要接收 POST 的 JSON 请求体方法签名里的参数需要是一个复合类型而不是简单类型。WCF 在处理 POST 时会把请求 body 反序列化成方法参数这对很多人来说是个容易踩的坑简单类型参数放在 POST body 里是无效的二进制或 XML 会被 WCF 拒掉。所以我的经验是POST 请求一律用一个 RequestDto 类来包装所有参数既符合 REST 习惯也能避开 WCF 的参数绑定陷阱。3.2 HTTP 状态码与错误契约的处理REST 接口和 SOAP 接口在错误处理上有一个本质区别SOAP 统一用 Fault 来表示错误不管底层是 500 还是 400REST 则要求你根据语义正确地使用 HTTP 状态码。webHttpBinding 也支持 Fault但火焰主要集中在你如何控制返回的状态码上。默认情况下如果 WCF 服务方法抛出异常客户端收到的是 500 Internal Server Error。这很合理但如果你希望校验失败时返回 400 或 404就需要在代码里显式控制。WCF 提供了WebFaultExceptionT这个类型比如throw new WebFaultExceptionstring(参数不能为空, HttpStatusCode.BadRequest);客户端收到后可以在响应 body 里拿到错误信息同时 HTTP 状态码是 400。这个类型最大的价值是它把 HTTP 语义直接带进了服务契约让调用者不用解析 SOAP Fault直接看状态码就知道发生了什么。实战中我还会定义一个全局的错误处理逻辑用IErrorHandler实现统一异常到状态码的映射。比如参数异常映射为 400找不到资源映射为 404未授权映射为 401服务器内部异常映射为 500。这样接口文档可以写得非常清晰第三方集成时也容易对接。但是要注意IErrorHandler和 webHttpBinding 配合时异常响应的 body 格式可能被 WCF 默认处理覆盖所以最好在自定义错误处理里显式设置 ResponseFormat。3.3 自托管场景下的 URL 配置与路由REST 改造中还有一个容易被忽略的点是 URL 的基地址和路由策略。webHttpBinding 服务有两种托管方式IIS 托管和自托管。自托管时的 URL 配置比 IIS 更自由但也更容易出问题。自托管 WCF 服务时你用ServiceHost指定基地址然后用WebServiceHost或手动添加绑定端点。有一个关键点如果基地址是http://localhost:8080/api而你的方法 UriTemplate 是GetData?value{value}那么完整 URL 是http://localhost:8080/api/GetData?value1不是http://localhost:8080/GetData。很多人在浏览器里测试时漏掉了基地址的路径前缀导致 404。另一个路由策略是使用WebServiceHost自动添加一个默认端点。这个默认端点会把操作方法名作为路径的最后一段。如果你不喜欢这种“方法名直接暴露”的风格可以使用UriTemplate前缀来模拟控制器路由。举个例子[WebGet(UriTemplate users/{id}, ResponseFormat WebMessageFormat.Json)] User GetUser(string id);这样 URL 会是/users/123而不是/GetUser?id123。从可读性和客户端对接的角度前者显然更好。我个人做项目时都会要求所有对外接口使用这种资源化 URI 模板而不是把方法名裸露出来。因为接口一旦公开方法名的改动会牵连所有客户端而资源路径的语义更稳定。4. 连接复用、超时与性能调优4.1 HTTP 连接复用的原理与配置WCF 客户端底层的 HTTP 连接管理是由ServicePoint和ServicePointManager控制的这部分很多人没了解过但几乎所有的“连接数不够导致请求排队”问题都源于这里。HTTP 连接复用Keep-Alive是指同一个 TCP 连接可以在一个请求完成后不关闭继续发送下一个请求。HTTP/1.1 默认开启 Keep-AliveWCF 也一样。如果每次请求都重新建立 TCP 连接三次握手的开销会非常可观尤其是在高并发场景下。WCF 有一个连接池的概念每个ServicePoint对应一组相同主机和端口的目标地址。ServicePointManager.DefaultConnectionLimit限制了每个 ServicePoint 能并发的连接数默认值在 .NET Framework 里是 2在 .NET Core / .NET 5 里是更大一些但这个默认值往往不够用。我遇到过线上 WCF 服务在双 11 大促时突然大量超时一查发现是客户端没设置DefaultConnectionLimit所有请求都在排队等着那 2 个连接。这个坑极其隐蔽因为日志里看不到任何异常只有延迟越来越高。配置方式很简单在客户端启动时加上ServicePointManager.DefaultConnectionLimit 100; ServicePointManager.Expect100Continue false;第二个设置同样关键。Expect100Continue默认是 true它会让客户端在发送较大请求体之前先发一个Expect: 100-continue头等待服务端确认后才继续发送 body。这在某些代理或奇葩服务器上会导致额外的握手延迟甚至直接卡死。我建议在调用 WCF 服务时统一关掉它除非你明确需要它来优化大包发送。4.2 超时机制从 DNS 到 TCP 到 HTTPWCF 的超时设置有很多层如果你分不清每一层各自管什么很容易调了半天没效果。这里我按“从底层到上层”的顺序给你理一遍。DNS 解析超时。WCF 客户端调用的地址如果是域名第一步就是 DNS 解析。系统默认 DNS 超时比较长如果 DNS 服务器不通请求会卡很久。这个层面的超时没法在 WCF 配置里直接调需要通过修改注册表或者使用DnsRefreshTimeout来影响缓存行为。我碰到过一个奇葩问题服务端换了 IP客户端还在用旧 IP 反复连接失败原因就是客户端 DNS 缓存没有刷新。解决办法是调用前强制Dns.GetHostAddresses刷新缓存或者把服务的 IP 地址直接写进配置文件。TCP 连接超时。WCF 的OpenTimeout其实管的是通道打开的耗时包括 TCP 连接和可能的认证握手。默认是 1 分钟你可以通过绑定配置调大或调小。但注意OpenTimeout不是万能的它并不严格等于 TCP 连接超时因为在 WCF 里 Open 还包含其他操作。HTTP 请求超时。SendTimeout和ReceiveTimeout分别管发送和接收。你可能觉得名字叫“发送”和“接收”很直观但在 WCF 里ReceiveTimeout影响的是整个消息处理生命周期不只是读 socket 的字节流。比如服务端执行一个耗时 3 分钟的报表任务客户端ReceiveTimeout设置为 1 分钟那结果一定是客户端先报超时即使服务端最终能成功返回。我给的调优建议是内网服务OpenTimeout可以放宽到 30 秒SendTimeout保持默认ReceiveTimeout根据最慢的接口耗时再加 80% 的余量。如果某个接口就是需要跑很久更合适的方式是改成异步调用而不是无限调大ReceiveTimeout。4.3 性能调优实战参数参考性能调优不能只靠“感觉加配置”。我先说几个真实压测中比较有用的参数你可以当作出发点。第一个是并发连接数。上面提到的DefaultConnectionLimit建议设置为预期并发数的 1.2 到 1.5 倍。如果你预期单机峰值 5000 QPS连接数设成 500 可能都不够因为 HTTP 连接可以复用但不会无限共享。我压测时通常先设 100然后用并发工具逐步往上压观察 CPU 和延迟曲线找到瓶颈再调整。第二个是服务端ServiceThrottlingBehavior。WCF 服务端默认有限流包括MaxConcurrentCalls、MaxConcurrentSessions、MaxConcurrentInstances。默认值很低我记得MaxConcurrentCalls默认是 16。如果你压测时发现并发一高就大量超时第一件事就是检查这个值。我曾经把一个服务的MaxConcurrentCalls从默认值调到 200吞吐直接翻了几倍。不过要注意无脑调大也会导致线程资源耗尽必须配合压测观察。第三个是消息压缩。HTTP 传输时WCF 默认是不压缩的如果接口返回的是大 JSON 或大 XML可以开启 IIS 动态压缩或者在自定义编码器里加入 GZip 流。我在一个对接第三方系统的项目里把返回的 XML 用 GZip 压缩后流量从 17MB 降到 1.2MB传输时间从 8 秒降到 1 秒以内。对带宽敏感的场景这比调任何超时都管用。第四个是反序列化性能。WCF 默认的DataContractSerializer在大对象图、多继承、循环引用场景下性能不佳。如果接口只给内部应用用可以考虑换成NetDataContractSerializer或者直接绕过 WCF 改成 ASP.NET Web API。实际上很多时候 WCF 的“性能问题”本质是技术栈选型问题REST API 用 JSON 序列化显然比 SOAP XML 快这也是我后来慢慢把新接口都迁移到 Web API 的原因。5. 常见问题与排查技巧实录5.1 HTTP 400、404、415 错误排查这三个状态码是 WCF HTTP 编程里最常见的拦路虎下面我们逐个拆解。HTTP 400 Bad Request通常表示请求的格式不能被服务端解析。WCF 中出现 400 最常见的原因是 SOAP 消息结构被破坏比如 XML 里有非法字符、Content-Length 与实际发送字节数不符、或者请求头里存在无法解析的字段。我排查时习惯先抓包然后对比 WCF 生成的正常请求和报错请求的差别。有一次我找了半天最后发现是客户端在请求头上多拼了一个\r\n\r\n导致服务端认为 HTTP 头结束的位置错位了直接 400。这类问题靠日志根本看不出来只能抓包。HTTP 404 Not Found在 WCF 里一般不是真的“资源不存在”而是服务基地址和端点地址配置不一致。比如服务端绑定的地址是http://host:8080/MyService.svc客户端却访问了http://host:8080这就会报 404。或者自托管时你把基地址写成了http://localhost:8080/MyService但实际 ServiceHost 打开的是/MyService.svc也会 404。我自己的习惯是用ServiceMetadataBehavior开启元数据端点然后直接用浏览器访问 WSDL 地址看它生成的 service 地址到底是什么用这个地址去配置客户端基本不会 404。HTTP 415 Unsupported Media Type说明请求的 Content-Type 和绑定期望的不一致。basicHttpBinding 期望text/xml或text/xml; charsetutf-8wsHttpBinding 期望application/soapxmlwebHttpBinding 期望application/json或application/xml。如果你在代码里手动构造 HttpWebRequest 调 WCF最容易遇到这个问题。解决办法是严格设置 ContentType不要只设置成application/json就完事还要关注 charset。有些服务端对 charset 很敏感少一个; charsetutf-8直接报 415。5.2 无法启动 HTTP 服务端口冲突、权限与命名空间保留自托管 WCF HTTP 服务时最经典的启动异常有两种“HTTP 服务未能注册”和“拒绝访问”。这两个都和 Windows HTTP 服务框架HTTP.sys有关。HTTP.sys 是 Windows 上负责 HTTP 监听的系统组件WCF 自托管时通过HttpListener向它注册 URL 前缀。如果你注册的端口已经被别的进程占用比如 IIS 占用了 80 端口或者另一个 ServiceHost 占用了相同 URL启动就会报“地址已在使用中”。排查端口占用我用的是netstat -ano | findstr :8080看 PID再在任务管理器里定位进程。权限问题则是 URL 保留命名空间的权限不足。HTTP.sys 默认只允许管理员注册新 URL或者允许系统账户和某些服务账户注册特定前缀。如果你用普通用户身份运行服务启动时会报“拒绝访问”。解决办法有两种一是用netsh http add urlacl urlhttp://:8080/ userEveryone手动给所有用户授予注册权限二是让服务跑在管理员权限下。前者更适合部署场景因为你不能要求线上服务永远用管理员跑。还有一个坑是 URL 前缀的冲突。比如你已经有一个 ServiceHost 注册了http://:8080/Service1再启动一个注册http://:8080/的服务第二个启动会失败因为它的前缀范围覆盖了第一个且没有被显式保留。这时候需要把多个服务放在同一个 ServiceHost 下或者为每个服务分配独立的路径前缀。5.3 与 Docker、代理等环境集成时的 HTTP 异常现在很多基础设施都是容器化的WCF 服务跑在 Docker 里、外部通过端口映射访问这在 Windows 容器和 Linux 容器里都会遇到和 HTTP 相关的特殊问题。Linux 容器里跑 WCF 服务需要特别注意WCF 本身是 Windows 时代的框架跨平台支持是通过 .NET Core 的 CoreWCF 社区方案实现的。如果你在 Linux Docker 里用原版 .NET Framework WCF基本不可能跑起来。我做过一个项目服务端是 CoreWCF客户端是 .NET 6最开始在容器内测试一切都正常但通过 Docker 端口映射从宿主机访问时总是出现响应延迟和偶发连接重置。后来抓包发现问题出在 Docker 的 NAT 环境下HTTP 的 Keep-Alive 连接被防火墙的 conntrack 表回收了。当客户端多路复用同一个 TCP 连接时如果该连接长时间空闲Docker 宿主机的 NAT 表会把这连接状态丢掉导致后续请求在已失效连接上发送收到 RST 重置。解决办法有三个方向一是缩短客户端的ConnectionLeaseTimeout让连接在空闲时及时关闭重建二是在服务端启用 HTTP 连接心跳三是调大 Docker 宿主机的net.netfilter.nf_conntrack_max。我实测中最有效的还是第一种因为调整内核参数在云上不一定有权限。代理环境同样容易出问题。公司内外网访问时客户端代码如果走系统代理而代理不识别 WCF 的 SOAPAction 头就可能出现 407 Proxy Authentication Required。如果你的客户端运行在用户桌面环境一定要把WebRequest.DefaultWebProxy的默认行为理清楚。WCF 默认会使用系统代理但在服务账户运行的容器里系统代理可能指向一个不存在的地址导致每个请求都尝试去连接一个无效代理然后超时。排查方法是临时让客户端走直连WebRequest.DefaultWebProxy null;如果直连后问题消失那就是代理配置的问题不要在 WCF 绑定上调半天。5.4 疑难杂症Chunked 编码、Expect 头与内容类型不一致最后聊几个我一看到就头大但实际都有解的疑难问题。第一个是 Chunked 传输编码。WCF 客户端一般默认使用Content-Length方式发送请求体但如果响应是流式返回服务端可能使用 Chunked 编码。在抓包里你会在 HTTP 响应头看到Transfer-Encoding: chunked。大部分情况下 WCF 客户端能正常解析但如果你把 WCF 服务放到某些网关后面网关对 Chunked 响应处理得不好客户端就可能出现“响应已结束但消息不完整”的异常。解决思路是让服务端禁用 Chunked强制使用 Content-Length。对于自托管 WCF可以在自定义绑定里设置HttpTransportBindingElement.TransferMode TransferMode.Buffered大部分时候能解决。第二个是 Expect: 100-continue 头引发的“请求不到达”问题。前面提过可以关掉客户端的Expect100Continue。如果你在服务端遇到客户端发来Expect: 100-continue而服务端因为有认证逻辑而没有先返回 100那么客户端会等待一段时间再发送 body造成明显的额外延迟。我在 Java 客户端调 WCF 时就遇到过这种问题对方用了 HTTP 标准客户端默认会发 Expect 头而 WCF 服务端没及时响应 100导致每次请求都多 1 秒延迟。解决办法是要求对方客户端设置Expect: 100-continue为 false或者在网关上把该头剥掉。第三个是内容类型不一致导致的“不直观错误”。WCF 的 webHttpBinding 允许 JSON 和 XML 两种内容类型但如果你服务契约上标注了ResponseFormat WebMessageFormat.Json而某个方法返回了非序列化对象比如返回了 Stream客户端收到的响应可能是一个空 body 加上 200 状态。排查这种问题很费劲因为从状态码看是成功但业务数据是空的。我的建议是REST 风格接口的返回类型尽量使用 DTO不要直接返回 Stream 或XmlDocument这样能避免 WCF 自动选择响应格式时的歧义。还有一个我特别想强调的WCF 在处理Content-Type: application/json时其内部使用的 JSON 序列化器对日期的格式要求是 ISO 8601如果你传入的时间字符串是yyyy-MM-dd HH:mm:ss这种格式OGNL 反序列化在 .NET 中往往会抛异常。很多团队对接时被这个问题卡住最后只好把所有 DateTime 改成 string 传输。如果你不想改契约可以在客户端序列化时配置DataContractJsonSerializerSettings里的DateTimeFormat统一成服务端能识别的格式。6. 从调试到防线HTTP 层日志与监控建议调试一个 HTTP 问题抓包是“手术刀”日志是“影像学检查”两者缺一不可。WCF 自带的跟踪日志其实很强大很多人没用过。启动方式是在web.config或app.config配置system.diagnostics开启System.ServiceModel的Tracing和MessageLogging。这样 WCF 会生成一个 svclog 文件里面记录了每个消息的传输方向、内容类型、耗时甚至包括 SOAP 头。我经常用SvcTraceViewer.exe打开这个日志能看到调用链路上每一跳的时间分布。这比你在业务代码里手写日志要准确得多因为 WCF 的消息日志是框架级的不会漏掉序列化、传输、反序列化这些隐藏耗时。用日志定位问题有一个原则先看“请求是否到达服务端”再看“响应是否正常返回”。如果请求根本没到服务端那问题在网络层或网关层不用浪费时间看业务代码。如果到了但响应异常再逐层查看序列化、业务逻辑、绑定配置。这套排查顺序我屡试不爽能节省大量时间。监控方面自托管 WCF 可以在宿主程序里注入性能计数器也可以直接利用 Windows 自带的System.ServiceModel性能计数器组。不过我个人更喜欢把 WCF 服务的调用信息以结构化日志输出到集中日志平台比如 Serilog 直接输出到 Elasticsearch。在 HTTP 层面对每个请求记录Method、Uri、StatusCode、ElapsedMilliseconds这四个字段就能覆盖大部分问题定位需求。如果以后再遇到“某个接口偶发慢”你只需要查日志里耗时超过阈值的请求长什么样不需要再抓包。至于从 WCF 向更现代化的 HTTP 框架迁移我的建议是不要一刀切。老接口保持 WCF 稳定运行新接口逐步用 ASP.NET Core Web API 或网关替代。如果你已经积累了大量 WCF 服务契约可以先在网关层做协议转换让外部调用者用 REST 接口内部继续走 WCF平滑过渡后再逐模块重写。这样既不影响业务也能规避大版本升级带来的风险。最后再分享一个我个人体会很深的小技巧不管你用哪种绑定写客户端调用代码时千万不要在每次调用时都 new 一个客户端代理出来用完就丢。WCF 客户端的创建非常消耗资源尤其是ChannelFactoryT的创建。正确做法是缓存ChannelFactory通过它反复创建通道如果某个通道进入 Faulted 状态再重新打开一个。但要注意缓存的ChannelFactory也要处理好生命周期服务端重启后客户端通道可能已经失效需要监听Faulted事件自动重建。这套逻辑我封装成了一个工具类在多个项目里复用稳定性远远高于每次 new 一个代理的方式。HTTP 网络编程的很多问题本质上不是不会写代码而是没把底层交互逻辑、连接生命周期和调试手段的优先级搞清楚。把这些理清了WCF 就不再是玄学。