Axum请求处理程序在等待Future时出现调用瓶颈的原因排查

我来帮你拆解这个问题——你遇到的延迟瓶颈根本不是Axum或Tokio的调度问题，而是测试端的TCP连接限制导致的，咱们一步步理清楚：

核心原因：Windows TCP栈的并发连接限制+测试脚本的请求方式 #

你用PowerShell的Start-Job发起12个请求时，每个Start-Job都会创建一个独立的Windows进程，每个进程都会单独和服务器建立TCP连接。而Windows的TCP/IP栈默认带有防SYN洪水攻击的机制：当短时间内从同一源IP向同一目标IP:Port发起过多并发SYN连接请求时，会将后续的连接请求延迟处理（默认延迟约10秒），以此避免恶意攻击。

你的物理核心数是6，刚好前6个请求的TCP连接能被快速建立，服务器能立刻收到请求并调用handler；剩下的6个请求被Windows TCP栈拦截延迟，直到10秒后才允许建立连接——这就是为什么服务器的handler日志里，第7到12个请求要等到21:19:13才被触发，和前一批请求间隔了整整10秒。

为什么不是Axum/Tokio的问题？ #

你可能会疑惑：Tokio的异步模型不是应该能处理大量并发请求吗？没错，你的handler里的sleep(Duration::from_millis(500)).await是非阻塞的异步睡眠，它会主动让出Tokio工作线程，不会占用线程资源。哪怕你的Tokio工作线程数是6（默认等于物理核心数），也能同时处理远多于6个的异步请求，因为sleep的时候线程会被其他任务复用。从你前6个请求的处理时间也能看出来：它们的handler几乎是连续被调用的，500ms后也几乎同时返回，说明异步调度是完全正常的。

验证与解决办法 #

1. 修改测试脚本，避免创建过多独立进程 #

把PowerShell脚本里的Start-Job替换成Start-ThreadJob——ThreadJob是轻量级的线程任务，所有请求都在同一个PowerShell进程内的不同线程发起，不会触发Windows的TCP并发限制。修改后的脚本片段：

$jobs += Start-ThreadJob -ScriptBlock {
    $headers = @{ "X-Request-Id" = "$using:index" }
    try {
        $response = Invoke-RestMethod -Uri http://localhost:3000/ -Method Post -Headers $headers -Body ""
        "Response $using:index: $response"
    } catch {
        "Response $using:index: ERROR - $_"
    }
}

运行这个修改后的脚本，你会看到12个请求的handler几乎同时被调用，500ms后所有请求同时返回，完全符合你的预期。

2. 用其他并发请求工具验证 #

比如用curl的并发请求命令测试：

# 用xargs并发12个请求
seq 0 11 | xargs -P 12 -I {} curl -X POST -H "X-Request-Id: {}" http://localhost:3000/

服务器的handler日志会显示所有请求被快速触发，没有延迟，进一步证明问题出在测试脚本的请求方式上。

总结 #

你的Axum服务器本身的异步处理逻辑是完全正常的，瓶颈来自测试端的Windows TCP连接限制，以及Start-Job创建过多独立进程触发了这个限制。只要调整测试脚本的请求发起方式，就能解决这个延迟问题。

内容来源于stack exchange