实测导读与核心结论（TL;DR）：Speedtest、花云测速等工具默认开启 16–32 条并发 TCP Socket 线程，能够在高丢包网络中强行拼凑出漂亮的跑分截图。然而，YouTube 4K 视频切片下载与网页加载绝大多数依赖单一 TCP 长连接。在晚高峰 20% 丢包的线路上，多线程测速能跑出 2Gbps，但单线程连接由于 TCP 拥塞避免算法（Cubic）将拥塞窗口（CWND）强制砍半，真实吞吐量暴跌至 不足 3 Mbps，造成严重缓冲卡死。
一、 多线程测速的“分片拼接”数学欺骗
当你在测速网站点击“开始测试”时，客户端后台会同时向测速服务器建立数十条平行的 TCP 数据流。
- 假设线路上每 10 个数据包就随机丢掉 2 个（丢包率 20%）；
- 线程 A 遭遇丢包开始重传时，线程 B 和线程 C 正在接收数据；
- 测速软件将这 32 条并发连接在 1 秒内收到的所有字节直接相加除以时间，计算出一个虚假的“峰值带宽”；
- 截图发在论坛上显得速度惊人，但这种聚合带宽在实际单流业务中根本无法变现！
二、 单线程下 TCP 拥塞窗口（CWND）断崖下跌剖析
在真实场景中（如播放 YouTube 4K 视频或从 GitHub 下载 Release 安装包）：
- 客户端通过单个 TCP 套接字向服务器请求一个 25MB 的视频分片（Chunk）；
- 根据经典 TCP Reno / Cubic 拥塞控制算法，一旦网络中出现哪怕一个数据包丢失（未收到 ACK）：
CWND_new = CWND_old * 0.7 (在 Cubic 中) CWND_new = CWND_old * 0.5 (在 Reno 中) - 拥塞窗口瞬间缩减，发送端立刻暂停发包，等待慢启动重传；
- 视频播放器缓冲区在 2 秒内见底，屏幕中央出现转圈卡顿！
三、 如何在本地终端进行不被欺骗的单线程实测
使用 curl 直接拉取单线程真实大文件：
# 使用单线程 HTTP 请求测试节点真实承载力
curl -x http://127.0.0.1:7890 -o /dev/null -s -w "单线程真实下载速率: %{speed_download} 字节/秒 | 首字节响应: %{time_starttransfer}s
" https://speed.cloudflare.com/__down?bytes=52428800