机场多线程测速很快，单个下载却慢？用两任务对照核验并发收益
看到机场推荐文章展示“多线程测速很快”，自己的单个下载任务却慢，先别把两张数字直接放在一起。单任务与并发任务回答的问题不同：前者贴近一次下载，后者观察多个传输同时工作时的表现。本文给出一个低并发、可复查的对照办法，不评价任何具体服务商。
先把“任务数”和“连接数”分清
curl 默认依次处理多个 URL；--parallel 才会尝试并行处理，--parallel-max 限定并发传输数。根据 curl 官方说明，并发传输还可能复用或多路复用已有连接，因此两个传输任务不能直接写成“两条独立线路”，也不一定等于两条 TCP 连接。并发传输说明
示意图：并发任务共享网络资源；总吞吐与单个任务完成情况需要分别记录，图中不代表实测速率。
第一步：确定要解决的实际问题
如果只是一个工作文件下载很慢，单任务结果应当优先；如果希望两台设备同时下载，才需要额外观察并发与公平性。网页打开、会议和视频也各有自己的验收任务，下载总速度不能代替它们。
准备自己有权访问、服务器允许测试的固定 HTTPS 文件，先核对大小和可用性。不要用订阅链接作测试文件，也不要向不允许压测的网站连续发请求。安排很小的流量预算，文件越大、重复越多，套餐消耗越多；到达预算就停止。
第二步：固定条件，先做单任务
记录设备、接入方式、客户端、节点、规则模式、测试文件和时间。暂停其他下载与同步，确认测试流量实际经过所选节点。每轮使用相同文件和保存方式，出现失败也照实记录，不能只留下最快的一次。
先运行 curl.exe --version 核对版本；后面的逐任务编号和退出码统计要求 curl 7.75.0 或更新版本，旧版不支持时不要把缺少输出记成测量结果。Windows 可用下面的示例；127.0.0.1:7890 只是占位的本机 HTTP 代理入口，须改成客户端真实入口，两个示例文件也须换成获准测试的地址。若用 TUN 接管，先确认路由，再按实际方式测试。
curl.exe -q --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 60 --output NUL --write-out 'status=%{response_code} bytes=%{size_download} seconds=%{time_total} Bps=%{speed_download}\n' https://example.com/test-a.bin
示例不自动跟随重定向。若返回跳转或登录页，先核对真实文件地址，不能把小页面当成文件传输成功。speed_download 的单位是字节/秒；size_download 与总耗时帮助确认任务规模。curl 参数手册
第三步：只增加一个并发任务
在相同条件下，用两个事先获准的文件做一次两任务对照。两者应大小接近，单任务轮也分别测过，避免把不同文件源的差异算给机场。
$roundTimer = [System.Diagnostics.Stopwatch]::StartNew()
curl.exe -q --proxy http://127.0.0.1:7890 --parallel --parallel-max 2 --connect-timeout 10 --max-time 60 --write-out 'task=%{urlnum} status=%{response_code} bytes=%{size_download} seconds=%{time_total} exit=%{exitcode}\n' --output NUL https://example.com/test-a.bin --output NUL https://example.com/test-b.bin
$roundTimer.Stop()
$roundTimer.Elapsed.TotalSeconds
这里显式限制为两个传输，切勿直接沿用工具可能较高的默认并发量。输出中的 task 区分两个任务，status、bytes 与 exit 分别记录响应、字节及传输退出码，最后一行为整轮计时秒数。保留每个任务是否完成、错误、总下载字节和从启动到全部结束的实际墙钟时间；共享总吞吐可用“总字节÷整轮实际秒数”计算。不要把两个任务各自的平均速率简单相加，当作整轮速率；它们的开始、结束时间未必相同。
第四步：交替复测，保留完整结果
建议采用“单任务—两任务—单任务”的短顺序，下一轮反过来，避免只因时段变化误判。记录表至少有以下栏目：
| 条件 | 完成情况 | 任务字节 | 整轮耗时 | 失败或重试 | 当时其他流量 |
|---|---|---|---|---|---|
| 单任务 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 |
| 两任务 | 分别填写 | 合计并保留明细 | 待填写 | 分别填写 | 待填写 |
怎样验收与选择
若两任务总吞吐更高，但单任务仍慢，只能说明该条件下并发有收益，不能直接证明服务商对单连接限速；源站限制、共享路径与传输协商都可能影响结果。若并发时某个任务频繁失败，即使总速度漂亮，也不适合把“同时下载”当卖点。
最终把记录对应回自己的任务：单个大文件按单任务完成时间选；多设备并用还要看每个任务是否稳定完成。换一个获准的文件源、另一个常用时段再验证，才有更完整的选购依据。本文方法不产生商业排名，也不承诺任何套餐的速率。
来源与核验日期
核验日期：2026-11-03。命令需以本机版本支持的参数为准；表格为空白记录模板，并非实测数据。
评论