Android调用SOAP接口偶发Unexpected end of stream异常排查

java.io.IOException: Unexpected end of stream 本质是HTTP客户端读取响应数据时，TCP连接在数据传输完成前被异常关闭，没有读到预期的响应结束标识，直接碰到了流末尾。无固定复现路径的偶发场景，90%以上由以下原因导致：

• 长连接复用冲突：Android 4.4以上版本HTTP底层默认使用OkHttp，默认开启keep-alive长连接复用，会将已建立的连接存入连接池重复使用。如果服务端/运营商NAT网关的长连接空闲超时时间比客户端短，会提前回收空闲连接，客户端此时从连接池拿到已经失效的连接发请求，就会直接触发该异常，这是这类偶发问题最常见的诱因。
• 网络链路瞬时波动：移动网络场景下基站切换、弱网丢包、WiFi/移动网络切换，都会导致连接被中间节点掐断，没有走正常TCP断开流程，客户端无法提前感知连接状态。
• 服务端侧偶发故障：服务端负载过高触发限流、请求处理进程重启、网关超时，会直接断开TCP连接不返回任何HTTP响应内容，客户端读流时就会碰到EOF。
• 依赖库兼容缺陷：ksoap2-android老版本的HttpTransportSE实现没有适配OkHttp连接池机制，不会自动检测失效连接，也没有内置重试逻辑，碰到异常直接抛出。

按落地成本从低到高排序：

• 快速止血方案：给请求头加Connection: close，强制关闭长连接复用，每次请求都新建TCP连接，从根源上避免拿到失效的池化连接。只需要在构造请求信封后加一行代码即可：

  envelope.addHeaderProperty("Connection", "close");
  

  该方案缺点是每次请求都要重新做TCP、TLS握手，弱网下请求耗时会增加100-300ms，仅适合临时验证问题、快速修复线上故障，不建议作为长期方案。
• 增加幂等重试逻辑：这类流意外终止的错误属于瞬时网络错误，只要接口满足幂等性（查询类接口、或者服务端做了请求幂等去重），在捕获到IOException时自动重试1-2次即可覆盖90%以上的偶现场景。重试时加300-500ms的随机退避，避免瞬间重试冲击服务端。注意非幂等的提交类接口不要盲目重试，避免重复提交数据。
• 升级依赖优化传输配置：将ksoap2-android升级到最新正式版本，新版本修复了和OkHttp的兼容问题；有条件的话可以把HttpTransportSE替换为基于OkHttp3自定义的传输实现，利用OkHttp自带的连接健康检查、失效连接自动剔除、请求重试能力，稳定性比原生实现高很多。另外当前代码设置的180s超时过长，建议拆分超时配置：连接超时设15s，读超时根据接口实际耗时设30-60s即可，减少无效等待。
• 服务端侧协同优化：协调后端开发调整服务端keep-alive超时时间，保证服务端长连接超时比客户端OkHttp默认的5分钟连接池超时长10s以上，消除两端连接状态不一致的时间差；同时在网关层配置异常兜底响应，不要直接断开连接。

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