单线程和多线程测速差在哪，为什么测速好看晚上却卡

同一条线路，同一个时刻，Speedtest 用多连接跑出 386.22 Mbps，切成单连接只剩 152.06 Mbps。线路没变，节点没变，变的只是测法。

这张图是本文想说清楚的全部事情。下面把它拆开讲。

先用搬家打个比方

单线程下载，像搬家时只有一个搬运工。他每次从旧家搬一箱东西到新家，放好再回来搬下一箱。东西少的时候还行，几百箱的话，就算路很宽、搬运工跑得也快，一箱一箱来，整体速度就是有上限。

多线程下载，像同时叫来好几个搬运工。一个搬衣服，一个搬电脑，一个搬书，另一个搬家具，同时往新家运，最后一起整理好。

对应到下载，就是把一个大文件切成几块同时下，下完再拼成完整文件。所以哪怕你的带宽很高、服务器也很快，只要单条连接跑不满，多开几条往往就能明显快起来。

常见工具各用几条连接

不同测速站、下载工具和实际应用，用的连接方式并不一样。这也是一张测速图常常代表不了真实体验的原因。

Fast.com 默认偏多连接。下面这张图里，测出 300 Mbps 的同时，连接面板中同时有好几条到 nflxvideo.net 的下载，每条各拿到 7 到 10 MB/s。

Google Fiber Speed Test 同样会开多条并发连接来压带宽。这张图测出 232.6 Mbps，连接面板里同时有六条链路在跑。

Telegram 下载文件也会开多条连接，所以它比较容易体现一条线路的综合带宽。这张图在下一个 1152 MB 的压缩包，连接面板里六条链路同时在传。

YouTube 就不一样了。播放视频时的加载方式和传统测速站不同，连接面板里往往只有一条在跑。所以 Speedtest 跑出的高带宽，不代表 YouTube 加载时也能到那个数。

在 Windows 上用 Tsukimi 这类客户端看 Emby，情况类似，实际体验更依赖单条连接的持续传输能力。

想看 YouTube 的实时速度可以装个脚本

YouTube 播放器右键菜单里有「统计信息」，能看到 Connection Speed，但单位是 Kbps，看起来不直观。有个油猴脚本可以把它转成 MB/s，并顺带记录最高与最低值。

脚本地址在 Greasy Fork 的 YouTube 视频网速实时转换器。装完打开统计信息就能看到换算后的数值。

为什么有些线路测速很快，晚上却很卡

这是测速里最容易被忽略的一点。

一张漂亮的测速图，可能是在网络空闲时段、用多连接跑出来的。这种条件下，即使单条连接的表现一般，几条连接同时传也能把总带宽利用起来，最后得到一个很好看的数字。

普通人真正使用时的条件完全不同。晚高峰，应用只开一两条连接。前面那张 Speedtest 对照图里，多连接 386 Mbps、单连接 152 Mbps，就是在同一时刻测出来的；换成晚高峰，两者的差距还会被拉大。

于是就出现了那句常见的抱怨，测速几百兆甚至上 G，晚上看视频却一直缓冲。

所以评价一条线路，只看多线程峰值是不够的。测速发生在什么时间段、用的哪个节点、单线程表现如何、延迟和丢包怎么样、能不能长时间稳住，这些都要一起看。只放空闲时段的多线程峰值、完全不给晚高峰实际表现的测速图，参考价值其实很有限。

为什么越来越多人开始盯单线程

因为晚高峰的单线程表现，比一个漂亮的多线程峰值更容易暴露线路在拥堵时的真实能力。

看视频、打开网页、加载资源、用 Emby，这些场景里用户真正关心的并不是这条线路最高能跑多少，而是晚上大家都在用的时候它还能不能稳住。有些测速机器人已经专门提供单线程后端，可以直接测这一项。

我自己测线路时，比较关注晚高峰单线程能不能长期稳定在 30 MB/s 左右或以上。

这里还有一个前提要说清楚。单线程能跑 30 MB/s，不代表整条线路总共有 30 MB/s 就够了。如果线路总容量本身就小，用户一多照样互相抢带宽，你单独测的时候好看，大家一起用就不行。比较理想的情况是单线程能力不错、总带宽充足、晚高峰还稳得住，三样都占。

那到底该怎么判断

可以按场景分开看。

看视频、Emby 这类持续加载的场景，更关注单线程或者少量连接下的表现。大文件下载、并发下载这类场景，更关注多线程能力和线路总带宽。日常综合体验的话，单线程表现、延迟、丢包和晚高峰稳定性都得算进去。

我个人不会只凭一张多线程测速图判断线路好坏。真要测一条线路，最好同时看晚高峰的单线程、晚高峰的多线程，再加上实际的视频或下载体验，三样对照着来。

测速终究只是个测试工具，代表不了真实体验。数字可以当参考，最后还是以自己用起来的感觉为准。

以上主要是我在实际使用和测试过程中的理解，尽量用直白的方式说明。有不够严谨或者遗漏的地方，欢迎补充和指正。