单线程持续吞吐

受控文件下载吞吐测试

测量浏览器经由当前代理节点在持续数据流传输时的单线程下行速率。提供明确的流量消耗上限，支持即时中断并按字节结算。

诊断目标：浏览器受控吞吐量压测● 未开始

工具回答的问题：当前代理节点在持续数据流传输时，单线程下载吞吐上限能否达到流媒体与大文件的要求？

测试前流量消耗提示：本测试会从公开 CDN 边缘真实下载指定容量的测试字节流。请留意当前选择的流量配额（单次消耗约 10 MB 真实流量）。支持随时中途取消，已下载数据精确按字节结算。

测试流量消耗上限：

测量边界与客观影响因素说明：

单连接 vs 多并发：本测试计算的是浏览器单个 HTTP GET 连接到达边缘 CDN 的吞吐速率。日常看 4K 视频或多线程下载软件可能会建立多个并发连接，实际峰值可能更高。
本地瓶颈影响：家庭 Wi-Fi 信号强度、路由器 CPU 负载、本地代理客户端的加解密损耗均会直接约束吞吐数值。

单线程持续下载吞吐的核心物理机制

解析 TCP 拥塞控制（BBR vs Cubic）、BDP 带宽时延积与 MTU 衰减对代理下载体验的实质制约。

1. 什么是单线程吞吐？为什么它比多线程测速更贴合实际？

常见的测速平台开启 16~32 线程并发抢占带宽，数字往往非常夸张。但在实际使用中，从 GitHub 克隆仓库、在终端拉取 pip/npm 包、下载应用更新或播放单个 YouTube 视频切片，绝大多数应用在某一瞬间只有一条活动 TCP 连接。根据网络物理定律，单连接最大吞吐受限于「TCP 窗口大小 ÷ 往返往返时间（RTT）」。即便物理带宽有千兆，若线路 RTT 高达 200ms 且有 1% 丢包，单线程吞吐也会被压制到 20Mbps 以下。

2. 提高持续下载速度的技术调优方案

① 选择低 RTT 的近场节点：南方选香港专线（RTT 30~50ms），北方选日本专线（RTT 40~60ms），低往返时间天然成倍放大了单连接最大可能吞吐；
② 关注服务端 BBR 拥塞控制算法：优质机场服务商在海外节点全线编译开启 Google BBR 拥塞控制算法，相比传统 Cubic 算法，抗偶发弱网丢包性能提升数倍；
③ 谨慎选择极速协议：在丢包严重的恶劣公网下，基于 UDP 的现代协议（如 Hysteria 2、TUIC）通过自研拥塞控制算法强制发包，单线程表现大幅优于传统 TCP。