经典Asp.Net(C#)文件下载在低速网络下失败问题排查求助

我之前处理过好几起类似的经典ASP.NET文件下载在低速网络环境下失败的案例，结合你描述的场景——大文件在高速/局域网正常，但小文件都可能在下载到90%左右报错，给你几个针对性的排查和修复方向：

• 调整ASP.NET请求超时配置
  经典ASP.NET默认的请求超时时间（executionTimeout）只有110秒，低速网络下哪怕是1MB的文件，遇到网络波动也很容易超过这个时限。你需要在web.config的<httpRuntime>节点里延长这个值，比如设置为1小时（3600秒），同时确保maxRequestLength已经适配你的2GB文件需求：

  <system.web>
    <httpRuntime executionTimeout="3600" maxRequestLength="2097152" />
  </system.web>
  

• 启用分块传输并优化响应头
  默认情况下ASP.NET会把整个响应缓存到内存再发送，这在低速网络下不仅容易超时，还可能因为内存占用问题导致异常。你可以在下载逻辑里关闭缓冲，启用分块传输：

  // 在文件下载的Page或Handler中添加
  Response.BufferOutput = false;
  // 禁用缓存避免浏览器端的缓存冲突
  Response.Cache.SetCacheability(HttpCacheability.NoCache);
  // 确保正确设置Content-Length（如果是本地文件，可以通过FileInfo获取）
  FileInfo fileInfo = new FileInfo(filePath);
  Response.AddHeader("Content-Length", fileInfo.Length.ToString());
  

  分块传输会让服务器边读取文件边发送数据，既降低内存压力，也能让浏览器持续收到数据，避免因长时间无响应触发"Network Failure"。

• 实现断点续传支持
  低速网络最容易出现连接中断，断点续传能让浏览器从失败的位置继续下载，而不是从头开始，大幅降低失败概率。核心是处理HTTP的Range请求：

  long startByte = 0;
  FileInfo fileInfo = new FileInfo(filePath);
  long fileSize = fileInfo.Length;
  
  // 检查是否有Range请求
  if (Request.Headers["Range"] != null)
  {
      Response.StatusCode = 206; // Partial Content
      string rangeHeader = Request.Headers["Range"].Replace("bytes=", "");
      startByte = long.Parse(rangeHeader.Split('-')[0]);
      // 设置Content-Range响应头
      Response.AddHeader("Content-Range", $"bytes {startByte}-{fileSize-1}/{fileSize}");
  }
  
  // 从startByte位置开始读取文件并写入响应
  using (FileStream fs = new FileStream(filePath, FileMode.Open, FileAccess.Read))
  {
      fs.Seek(startByte, SeekOrigin.Begin);
      byte[] buffer = new byte[4096];
      int bytesRead;
      while ((bytesRead = fs.Read(buffer, 0, buffer.Length)) > 0)
      {
          Response.OutputStream.Write(buffer, 0, bytesRead);
          Response.Flush(); // 立即发送数据
      }
  }
  

  实现后，Chrome在遇到中断会自动发送Range请求继续下载，不会直接报错。

• 检查IIS和服务器端网络设置

  • IIS默认的连接超时是120秒，你需要在IIS管理器中找到对应站点，进入「高级设置」，把「连接超时」改成更大的值（比如3600秒）。
  • 排查服务器的防火墙或代理配置，有些安全设备会主动断开长时间无数据传输的连接，分块传输（上面的Response.Flush()）能有效避免这种情况。

• 验证Chrome模拟环境的准确性
  确认Chrome开发者工具里模拟低速网络的参数是否合理，比如是否同时设置了高延迟（比如300ms+）和低带宽。有时候过度极端的模拟参数会触发浏览器自身的保护机制，你可以逐步调整参数，排查是真实场景问题还是模拟设置导致的。

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