ASP.NET Core迁移至Service Fabric后读取Request.Body出现SocketException

问题原因 #

• 新旧代码请求体读取逻辑差异：旧代码调用ReadAsStreamAsync()会先将完整请求体缓冲到内存再返回流，后续反序列化操作都是读取内存数据，不会触发Socket IO操作。新代码直接读取Kestrel原生的Request.Body流，该流直接绑定底层Socket连接，反序列化过程中仍在持续从Socket读取数据，此时如果客户端主动断开连接、网络波动或者连接超时，就会直接抛出SocketException。
• Kestrel默认请求读取超时限制：从堆栈信息可判断你使用的是ASP.NET Core 2.2版本，该版本Kestrel默认请求体读取超时为30秒，你单请求体最大可达2-3MB，高流量场景下如果网络带宽不足或者服务端负载较高，读取请求体的耗时超过阈值，Kestrel会主动关闭连接，触发该报错。
• 同步IO性能瓶颈：当前代码使用同步的Deserialize方法，会触发Request.Body的同步读取操作，高并发场景下同步IO会大量占用线程池线程，导致请求堆积、处理延迟进一步升高，更容易触发超时断连。
• Service Fabric负载均衡/网络策略限制：Service Fabric集群的负载均衡默认有空闲连接超时阈值，如果大请求的传输/处理时间超过该阈值，负载均衡会主动断开连接。

解决方案 #

1. 复用旧代码的缓冲逻辑，先完整读取请求体到内存再处理 #

这是最低成本的修复方案，完全对齐经典云服务的运行逻辑，避免反序列化过程中触发Socket IO：

// 先启用请求体缓冲，允许重复读取
Request.EnableBuffering();
// 把请求体完整读到内存流
using var memoryStream = new MemoryStream();
await Request.Body.CopyToAsync(memoryStream);
memoryStream.Position = 0;
// 后续从内存流读取解压、反序列化
using (var decompressionStream = new GZipStream(memoryStream, CompressionMode.Decompress))
{
    using (var sr = new StreamReader(decompressionStream))
    {
        using (var jsonReader = new JsonTextReader(sr))
        {
            model = Serializer.Deserialize<Model>(jsonReader);
        }
    }
}
// 若后续还需读取Request.Body，可重置位置
Request.Body.Position = 0;

2. 调整Kestrel超时配置，适配大请求场景 #

在Program.cs中调整Kestrel的请求读取超时限制：

WebHost.CreateDefaultBuilder(args)
    .UseKestrel(options =>
    {
        // 调整请求体读取超时为2分钟，可根据实际业务调整
        options.Limits.RequestBodyReadTimeout = TimeSpan.FromMinutes(2);
    })
    .UseStartup<Startup>();

3. 改用异步反序列化，避免同步IO性能问题 #

升级Newtonsoft.Json到12.0.1及以上版本，使用异步反序列化接口，避免同步IO阻塞线程池：

// 先将请求体读到memoryStream，再做异步处理
using (var decompressionStream = new GZipStream(memoryStream, CompressionMode.Decompress))
{
    using (var sr = new StreamReader(decompressionStream))
    {
        using (var jsonReader = new JsonTextReader(sr))
        {
            // 异步反序列化
            model = await Serializer.DeserializeAsync<Model>(jsonReader);
        }
    }
}

4. 调整Service Fabric集群网络配置 #

如果上述方案仍有偶发报错，可以检查并调整：

• Service Fabric负载均衡的空闲连接超时阈值，调整到大于业务最大请求处理耗时
• 开启服务端点的TCP keep-alive配置，避免空闲连接被主动断开

5. 添加友好异常处理 #

对于确实是客户端主动断开的连接，可以捕获该异常并返回499状态码，不需要作为服务端错误上报，减少无效告警：

try
{
    // 业务处理逻辑
}
catch (IOException ex) when (ex.InnerException is SocketException se && se.SocketErrorCode == SocketError.ConnectionReset)
{
    // 客户端断开连接，返回499状态码
    Response.StatusCode = 499;
    return;
}

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