C# 文件上传的流量控制 C#如何使用令牌桶或漏桶算法来限制上传速率

throttledstream 是最直接的上传流限速方案，它在每次 read 前检查速率并等待，不阻塞线程，仅拖慢读取节奏；需避免自行实现令牌桶时误用 datetime.now、锁竞争或高频补令牌，且 ratelimitingmiddleware 对上传无效。

用 ThrottledStream 包裹上传流是最直接的方案

不推荐自己从零实现令牌桶或漏桶——C# 生态已有成熟、轻量、线程安全的封装，比如 microsoft.AspNetCore.Server.Kestrel.Core.internal.http.ThrottledStream（内部类，不建议直接用），更现实的是采用社区验证过的 ThrottledStream（来自 NuGet 包 System.IO.Streams 或自行实现的简易版）。它的核心逻辑是：每次 Read 前检查是否允许读取指定字节数，若超出速率则等待，不阻塞整个请求，只拖慢流读取节奏。

常见错误现象：自己写 Thread.Sleep 控制间隔，结果在同步 I/O 下卡死整个线程；或在 async/await 中误用 Task.Delay 但没 await，导致限速失效。

• 使用场景：ASP.NET Core 中处理 IFormFile.OpenReadStream() 返回的流，或 HttpRequest.Body 直接读取大文件时
• 必须包装在最外层读取点，例如：把原始 Stream 传给 new ThrottledStream(original, bytesPerSecond: 1024 * 1024)
• 注意：ThrottledStream 通常不实现 Seek，所以不能用于需要随机读取的场景（如 ZIP 解压前校验）
• 性能影响极小，单次 Read 调用增加约 50–200ns 的判断开销，远低于网络 I/O 本身

RateLimitingMiddleware 对上传无效，别被名字误导

ASP.NET Core 7+ 内置的 RateLimitingMiddleware 只作用于请求频次（requests per second）、并发连接数或 IP 级别，它在管道早期就完成判定，**完全不感知请求体大小或传输过程**。你配置了每秒最多 5 个上传请求，但每个请求仍可能瞬间打满带宽上传 500MB。

典型误用：在 Program.cs 里加了 app.UseRateLimiter() 就以为上传也受控，结果监控看到网卡跑满，而限流中间件日志里毫无异常。

• 该中间件触发点在 HttpContext.Request 头解析完成后、Body 读取前，此时 Body 还没开始接收
• 它无法与 MultipartReader 或 FormReader 协同做字节级节流
• 若真想结合请求级 + 流量级控制，需两层：外层用 RateLimitingMiddleware 控制并发请求数，内层用 ThrottledStream 控制单个请求的上传速率

自实现令牌桶要小心 DateTime.UtcNow 和锁竞争

如果必须手写（例如嵌入非 ASP.NET 环境），令牌桶最简结构只需一个 long _availableTokens、一个 DateTime _lastRefill 和 refill 逻辑。但生产环境容易翻车的点很具体：

• 别用 DateTime.Now —— 时区和夏令时会导致 _lastRefill 计算错乱，必须用 DateTime.UtcNow
• 高并发下多个线程同时调用 Consume(long bytes)，必须用 Interlocked 操作 _availableTokens，而非 lock —— 否则上传峰值时锁争用会成为瓶颈
• 令牌补充频率别设太高（如每 1ms 补一次），系统时钟精度有限，高频更新反而导致抖动；推荐每 100ms 补一次，按比例折算令牌数
• 示例关键片段：

  long now = DateTime.UtcNow.Ticks; long elapsedMs = (now - _lastRefill) / TimeSpan.TicksPerMillisecond; long tokensToAdd = (long)(elapsedMs * _bytesPerSecond / 1000.0); _interlocked.Add(ref _availableTokens, tokensToAdd); _lastRefill = now;

前端配合能缓解后端压力，但不能替代服务端限速

前端用 XMLHttpRequest.upload.onprogress 或 fetch + ReadableStream 分块上传，可以切片、暂停、重试，看起来“更可控”。但这只是用户体验优化，**所有分块仍走同一 TCP 连接，服务端不做流控的话，nginx 或 Kestrel 仍会把数据全收进来再处理**。

真实踩坑：前端限制每秒发 1MB 分片，但服务端未对 Request.Body 做节流，Kestrel 缓冲区积压大量未处理数据，OOM 或超时断连。

• 必须服务端兜底：哪怕前端完全不可信（如被绕过、脚本篡改），也要保证单请求上传速率可控
• 若用 Nginx 做反向代理，可配 client_max_body_size 和 client_body_timeout，但它不支持动态速率限制，仅防恶意长连接
• 真正有效的组合是：前端分片 + 后端 ThrottledStream + 反向代理连接超时兜底

实际部署时，最容易被忽略的是 ThrottledStream 生命周期管理——它必须和上传请求绑定，不能复用或静态持有，否则多个请求会互相干扰令牌计数。另外，https 加密开销会让实测速率略低于设定值，预留 5–10% 余量更稳妥。