gRPC分片上传报错：请求流被中止，连接被强制关闭

1. 是什么关闭了流？ #

导致连接被强制关闭（SocketException 10054）的原因可从三个方向排查：

• 客户端侧问题

  • 代码逻辑错误：发送第一个分片后，提前调用了AsyncClientStreamingCall.CompleteAsync()，或者包裹gRPC客户端的using块提前释放，导致请求流被主动关闭。
  • 本地环境限制：客户端防火墙拦截了后续分片的发送，或者客户端进程在发送过程中意外崩溃。
  • 分片格式错误：第一个分片的proto字段不符合定义（比如分片数据长度溢出、文件ID为空），导致客户端发送的数据包不符合gRPC规范，触发服务端主动断开。

• 服务端侧问题

  • 未捕获异常：处理第一个分片时抛出未捕获的异常，gRPC框架会主动关闭连接以避免资源泄漏。
  • 超时设置过短：服务端或客户端设置的Deadline（调用超时）太短，第一个分片处理完成后还未等到后续分片，连接就被超时机制关闭。
  • 逻辑错误：服务端在处理第一个分片时，提前结束了流式调用（比如提前返回响应或主动关闭请求流）。

• 网络中间件问题

  • 代理/防火墙/NAT设备：这类中间件可能因为长连接空闲（即使在传分片，若间隔过长）、数据包大小超限，或者安全策略限制，主动断开了客户端与服务端的连接。

2. 流是否应保持打开直到收到服务端返回的上传完成响应？ #

在gRPC客户端流式调用（客户端发送多个分片，服务端最终返回单个响应）的场景下，正确流程是：

• 客户端保持请求流打开，直到所有分片发送完成，再主动调用CompleteAsync()关闭请求流。
• 服务端在客户端关闭请求流后，开始拼接所有分片、完成文件上传逻辑，最后返回上传完成的响应。

也就是说，流不需要一直保持到收到服务端响应——客户端发完所有分片就可以主动关流，服务端处理完再返回响应。如果客户端未发完分片就关流，服务端会收到流中止的错误；如果服务端提前关流，客户端也会触发连接断开异常。

关键排查步骤 #

• 检查客户端代码
  确认是否存在提前关流的错误逻辑，比如：

  // 错误示例：提前调用CompleteAsync
  await call.RequestStream.WriteAsync(firstChunk);
  await call.RequestStream.CompleteAsync(); // 此时后续分片还未发送，服务端会报错
  

  同时检查CallOptions的Deadline设置是否足够长，避免超时断开。

• 检查服务端代码
  排查处理分片的逻辑是否有未捕获异常，比如：

  public async Task<UploadResponse> Upload(IAsyncStreamReader<UploadChunk> requestStream, ServerCallContext context)
  {
      try
      {
          await foreach (var chunk in requestStream.ReadAllAsync())
          {
              // 处理分片逻辑，确保不会抛出未捕获异常
          }
      }
      catch (Exception ex)
      {
          // 捕获并记录异常，避免gRPC框架直接关闭连接
          Logger.LogError(ex, "处理分片出错");
          throw; // 若需要返回错误响应，可返回特定的StatusCode
      }
      // 完成上传后返回响应
      return new UploadResponse { Success = true };
  }
  

• 抓包分析
  使用Wireshark抓取客户端与服务端之间的TCP流量，查看是哪一方主动发送了FIN/RST包，明确是客户端、服务端还是中间件关闭的连接。

• 调整超时与连接设置
  在客户端和服务端都设置更长的调用超时，比如：

  var callOptions = new CallOptions().WithDeadline(DateTime.UtcNow.AddMinutes(10));
  var call = client.Upload(callOptions);
  

  同时检查服务端的gRPC配置，确保长连接的空闲超时时间足够。

内容的提问来源于stack exchange，提问作者Linda Lawton - DaImTo