带宽 / 时延 / 丢包

你抱怨"网速慢"的时候，到底在说什么？是下载电影慢？还是玩游戏卡？还是视频通话糊？这三件事对应的是网络的三个完全不同的指标——带宽、时延、丢包率。搞懂它们，你就能像医生看病一样精准诊断网络问题。

指标一 · 带宽（Bandwidth）与吞吐量（Throughput）

"路有多宽"——一秒钟能运多少数据。单位是 Mbps（兆比特/秒）或 Gbps（千兆比特/秒）。

说白了，带宽就是水管的粗细：管子越粗，一秒钟能流过的水越多。但请注意，管子粗细跟"水多久能流到你家"是两件完全无关的事——这就是后面要讲的时延。很多人把这两件事混成一件，于是花了大钱升带宽，游戏该卡还是卡。

这些数字换算成能感知的量就有画面了：1 Mbps 相当于每秒 125 KB，也就是每秒传 6 万多个汉字；100 Mbps 每秒 12.5 MB，一部标准清晰度电影（约 700 MB）不到一分钟下完；10 Gbps 每秒 1250 MB，相当于一秒钟传完将近两部标准清晰度电影。所以说家用 100M 已经"绰绰有余"——你一个人的眼睛压根消费不了那么多数据。

这里必须区分一对天天被混用的词：带宽（Bandwidth）是"理论上限"，吞吐量（Throughput）是"实际跑出来的量"。它们几乎从不相等，中间的差距被四样东西吃掉了：

这一对词的关系打个比方就是水管口径和实际流出来的水量：你家水管标称能过 500 升，但水龙头开一半、管子里有段生锈、楼上还有人同时用水——真正接到桶里的可能只有 300 升。带宽是"这管子最多能过多少"，吞吐量是"这一分钟实际过了多少"，两者从来不相等。

【一条 500 Mbps 宽带的实际账】
名义带宽                          500 Mbps = 62.5 MB/s
减去以太网/IP/TCP 头部开销（约 4%）    → 480 Mbps = 60 MB/s
减去 TCP ACK 反向占用、重传（约 3%）   → 466 Mbps = 58 MB/s
如果服务器端限速 20 MB/s             → 实际只有 160 Mbps
如果同时有家人在看 4K（占 25 Mbps）    → 你剩下 135 Mbps

结论：你测速跑到 480 Mbps 是"链路能力"，
      下载某个文件只有 5 MB/s 通常是"对方给你的配额"。
      ——这两件事经常被误解成"运营商虚标"。

这笔账里最容易被冤枉的是运营商。你测速跑到 480 Mbps，说明你家那根水管确实够粗；下载某个文件只有 5 MB/s，那是对面那家的水龙头只开了那么大。好比你家进水管很粗，但你去超市打水，人家那个出水口就那么细——回家怪自家管子细，纯属找错对象。

还有一个极其容易忽略的天花板，叫带宽时延积（BDP, Bandwidth-Delay Product）。它解释了一个非常反直觉的现象：跨国下载慢，往往不是带宽不够，而是时延太高导致带宽用不满。

BDP 这个概念听着玄，换成大白话就是：这条路上"同时在半路上飞着"的货最多能有多少。好比一条快递专线，车速固定（光速）、路程固定（距离），那么"路上同时跑着多少辆车"就是个定死的数。路越长，你必须同时派出去的车越多，才能让收货那头源源不断地收到东西——只派两辆车跑八百公里，收货方大部分时间都在干等。

BDP = 带宽 × 往返时延（RTT）
    = "这条链路上最多能同时'在飞'多少字节"

例 1：国内，1 Gbps，RTT = 10ms
  BDP = 1,000,000,000 ÷ 8 × 0.010 = 1.25 MB
  → 发送方的 TCP 窗口至少要有 1.25 MB 才能把带宽跑满

例 2：跨洋，1 Gbps，RTT = 200ms
  BDP = 1,000,000,000 ÷ 8 × 0.200 = 25 MB
  → 窗口必须有 25 MB！

而 TCP 头里的"窗口"字段只有 16 位 = 最大 65535 字节（64KB）
在例 2 的条件下，单条 TCP 连接的理论极限只有：
  65535 ÷ 0.2 秒 = 327 KB/s ≈ 2.6 Mbps
—— 一条千兆链路，单连接只能跑出 2.6 兆！

解决办法：
① 窗口缩放选项（Window Scaling，RFC 1323）—— 把窗口放大到 1GB
② 多线程并发下载（这就是迅雷、IDM 快的根本原因）
③ 就近部署 / CDN —— 直接把 RTT 打下来（最有效）

这段计算解释了三件日常现象：为什么多线程下载器比浏览器单线程下载快得多（它开 16 条连接，绕开了单连接的窗口限制）；为什么下载国外资源即使带宽充足也很慢（BDP 太大，窗口填不满）；为什么所有大公司都在拼命建 CDN（降 RTT 是唯一能同时改善时延和吞吐量的手段）。

那个"千兆链路单连接只跑出 2.6 兆"的结论特别反常识，但用水管一比就懂了：不是管子细，是你手里只有一个小水桶，来回跑一趟要 0.2 秒——桶再来回跑，一秒也只能提五桶水。解决办法不是换更粗的管子，而是换更大的桶（窗口缩放），或者叫十六个人一起提（多线程下载），或者干脆把水源挪到你家门口（CDN）。这就是迅雷之类的多线程下载器为什么快得离谱。

指标二 · 时延（Latency）

"跑一趟要多久"——从你发出一个请求，到收到响应，需要多长时间。单位是毫秒（ms）。

时延说白了就是水龙头打开以后，水从水厂流到你家花了多久——跟管子粗细压根没关系。管子再粗，水厂在两百公里外，第一口水就是得等那么久。你打游戏卡、点技能不响，抱怨的就是这件事，而不是带宽。

这几档换算成生活里的感受：10 毫秒你压根察觉不到（一次眨眼约 100 毫秒，这是它的十分之一）；100 毫秒开始能感觉"点了一下才反应"；300 毫秒以上，打电话就变成了"你说完我再说"的对讲机模式——两个人一抢就同时开口，然后一起停下。卫星电话那种奇怪的说话节奏，全是这半秒钟造成的。

时延的四种构成：那几十毫秒到底花在哪

"时延 30 毫秒"是个结果，但这 30 毫秒由四种性质完全不同的等待组成。搞清这四份，你才知道该往哪儿使劲——因为它们中只有两种是你能优化的。

这四份等待用叫外卖来分一遍就特别清楚：传播时延=骑手从店里骑到你家这段路程（距离决定，谁也快不了）；传输时延=把餐一份份装进餐箱的动作（东西多就久一点，但很快）；处理时延=每个路口红绿灯前判断该往哪拐（现在的设备快到可以忽略）；排队时延=店里前面还压着二十单没出（这一项波动最大，也是唯一真值得动手的地方）。

先算一遍第 ① 项，因为它是硬下限，值得刻在脑子里：

真空中光速：           300,000 km/s
光纤中的光速：约 200,000 km/s（折射率约 1.5，慢了三分之一）

北京 → 上海（约 1200 km 光纤路径）
  单程 = 1200 ÷ 200000 = 6 ms
  往返 RTT = 12 ms  ← 无论你办多少兆宽带，这 12ms 一分都省不掉

北京 → 洛杉矶（约 10000 km，实际光缆绕行更长）
  单程 ≈ 50 ms，往返 ≈ 100 ms
  实际测量常在 130～180 ms（因为要绕行、要过多个交换节点）

地球同步轨道卫星（高度 35786 km）
  上行 + 下行 = 71572 km ÷ 300000 = 239 ms
  往返 RTT ≥ 478 ms ← 这就是卫星电话必须"你说完我再说"的原因

Starlink 低轨卫星（高度约 550 km）
  往返仅约 7 ms 的传播时延，这是它最大的技术卖点

这一段里最该记住的是那个卫星的数字：478 毫秒往返，差不多是你眨五次眼。所以卫星电话必须"你说完我再说"——不是设备差，是光跑一趟三万六千公里的天上再回来，物理上就得这么久。而 Starlink 把卫星从三万六千公里降到五百多公里，往返一下子降到 7 毫秒——它卖的压根不是带宽，是这段路程。

第 ④ 项排队时延才是日常体验里波动最大、也最值得动手优化的一项。它有个非常著名的病症叫缓冲区膨胀（Bufferbloat）：厂商为了"少丢包"，给路由器塞了超大的缓冲区。结果当你在下载大文件时，缓冲区被塞满几百毫秒的数据，你的游戏包和语音包只能排在几百个下载包后面，延迟从 20ms 飙到 500ms。

缓冲区膨胀这个病，说白了就是超市只开一个收银台，却在前面摆了一条长得离谱的排队通道：厂家觉得"队伍能排得下就不会赶客人走"，结果你只想买一瓶水，前面却排着七百个推满整车的顾客。你那一瓶水不是买不到，是要等半小时才轮到——这就是下载时游戏延迟从 20 毫秒飙到 800 毫秒的全部原因。

【Bufferbloat 现场】
路由器缓冲区（大得离谱，能装 1MB 数据）
[下载包][下载包][下载包]……×700……[你的游戏操作]
                                        ↑ 排在最后
上行 10 Mbps 的情况下，1MB 缓冲要 0.8 秒才能排空
→ 你的游戏延迟 = 20ms + 800ms = 820ms

【测一测你家有没有这个病】
① 先 ping 网关，记下延迟（比如 2ms）
② 一边跑满速下载/上传，一边继续 ping
③ 如果延迟从 2ms 涨到 200ms 以上 —— 恭喜，典型 Bufferbloat

【解法】在路由器上开启智能队列管理（SQM）
   算法名：fq_codel 或 CAKE
   原理：主动丢弃/延迟排队过久的包，让缓冲区始终保持很短
   效果：牺牲约 5% 峰值带宽，换来延迟稳定在个位数毫秒
   ——OpenWrt、华硕梅林、部分商业固件都自带这个功能

SQM 那套解法通俗地说就是超市改成"排队通道只准站十个人，多了先在门外等，同时开一条快速通道给只买一两件的人"。代价是整体吞吐量掉个 5%（相当于收银台偶尔空转一下），换来的是你买一瓶水永远不用等超过几秒。这笔交易对家用网络来说，划算得不能再划算了。

把四项加起来，你就能看懂一次真实的 ping 结果为什么是那个数：北京 ping 上海 = 传播 12ms + 传输 0.05ms + 处理 0.5ms（约 5 跳）+ 排队 2ms ≈ 15ms。注意传播时延占了八成——这就是为什么"网络优化"的第一原则永远是"把数据搬得离用户更近"，而不是"加带宽"。

再把这条结论用大白话钉一遍：一次 ping 的时间里，八成花在"路上跑"这件谁也改不了的事上。所以想让网页更快，正确做法是把货提前搬到用户家门口（CDN），而不是把水管换粗。就好比你要缩短外卖送达时间，最有效的办法是在小区门口开一家分店，而不是给骑手换一辆更大的电动车。

RTT 与 ping：那个数字到底在测什么

RTT（Round-Trip Time，往返时延）是实际工程中最常用的时延指标，因为它是唯一能在单侧测量出来的——测单程时延需要两端时钟精确同步，这在互联网上几乎做不到；而测往返只需要"我发出去、我收回来"，一台机器就能完成。

为什么工程上只测往返、不测单程？打个比方，你想知道从家到公司走多久，最简单的办法是走过去再走回来、看总共花了多少、除以二——因为你只有自己一块表。要精确测单程，得你家和公司两块表校准到毫秒不差，这在互联网上几乎办不到。所以全世界的网络工程师，用的都是这个"来回一趟"的土办法。

但 ping 出来的数字有几个必须知道的陷阱，否则你会读出完全错误的结论：

• ping 用的是 ICMP，不是你的业务流量路由器处理 ICMP 的优先级极低，很多设备甚至完全屏蔽。所以"ping 不通"不等于"服务不可用"，"ping 很快"也不保证"网页打开很快"。
• 它测的是网络层，不含应用处理时间ping 一个网站 20ms，但网页打开花了 2 秒——那 1.98 秒花在 DNS、TLS 握手、服务器查数据库、浏览器渲染上，跟网络一点关系都没有。
• 只看平均值会骗人平均 30ms 可能是"每次都 30ms"（很好），也可能是"一半 5ms 一半 55ms"（体验很糟）。要同时看最小、最大、平均，和标准差。
• 默认包很小ping 默认只发 32～64 字节，这个大小的包基本不会被排队和分片影响。用 -l 1400 发大包再测一次，结果往往差很多——那才更接近真实业务体验。

这四个陷阱里最要紧的是第三条，值得单独说：只看平均值会骗人。好比一家餐厅"平均上菜 30 分钟"——可能是每桌都稳定 30 分钟（体验不错），也可能是一半桌子 5 分钟、另一半 55 分钟（一半客人骂街）。平均数把最难受的那部分人藏起来了，所以一定要同时看最快、最慢、平均那三个数。

PS> ping -n 20 baidu.com
来自 110.242.68.66 的回复: 字节=32 时间=28ms TTL=51
...
110.242.68.66 的 Ping 统计信息:
    数据包: 已发送 = 20，已接收 = 20，丢失 = 0 (0% 丢失)
往返行程的估计时间(以毫秒为单位):
    最短 = 26ms，最长 = 89ms，平均 = 31ms
              └ 最长和最短差 63ms —— 抖动偏大，说明路上有排队

# 比 ping 更有诊断价值的一条命令：mtr / pathping
$ mtr -r -c 100 baidu.com          # Linux/macOS
PS> pathping baidu.com             # Windows 自带
  它会显示"每一跳"的丢包率和延迟，
  能直接定位到"从第 4 跳开始丢包" —— 这是 ping 给不了的信息

# 测 HTTP 层的真实耗时（比 ping 更贴近用户体验）
$ curl -o /dev/null -s -w "DNS:%{time_namelookup} 连接:%{time_connect} \
TLS:%{time_appconnect} 首字节:%{time_starttransfer} 总计:%{time_total}\n" \
https://example.com

DNS:0.021 连接:0.048 TLS:0.112 首字节:0.203 总计:0.245
     └ 一眼看出瓶颈在 TLS 握手和服务器处理，不在网络传输

最后那条 curl 命令是排查"网页慢"最实用的工具，值得记下来。它把一次请求拆成五个阶段，让你能精确指出是域名解析慢、TCP 握手慢、TLS 协商慢、服务器思考慢，还是内容传输慢——这五种病的药方完全不同。在没有分段数据之前，"网慢"这个判断没有任何行动价值。

那条 curl 命令干的活儿，说白了就是给一次网页请求做分诊：把"慢"这一句含糊的抱怨，拆成"查号慢 / 接通慢 / 对口令慢 / 对方思考慢 / 传内容慢"五个能分别下药的毛病。病人说"我不舒服"，医生不能直接开药——得先量体温、测血压、问哪儿疼。没有这五个分段数字之前，"网慢"这三个字压根没法动手。

指标四 · 抖动（Jitter）：比高延迟更难受的东西

这是被普通人忽略最多、却对实时体验影响最大的一个指标。抖动（Jitter）指的是时延的"波动幅度"，而不是时延本身的大小。

抖动打个比方就是公交车的准点程度：一趟车"每 20 分钟一班、班班准点"，你完全能安排时间；另一趟车"平均也是 20 分钟一班，但可能 2 分钟来一辆、也可能等 50 分钟"——平均数一模一样，后者却完全没法用。抖动说的就是这件事。

反直觉的结论是：对于语音和视频通话，"稳定的 100ms"远好于"在 20ms 和 150ms 之间乱跳"。因为接收端可以用一个固定的缓冲区把稳定的延迟"藏起来"，但对付不了忽快忽慢——包一会儿挤在一起、一会儿断档，声音就会出现卡顿、金属音、机器人音、忽然加速。

为什么"稳定的 500 毫秒"比"在 20 和 150 之间乱跳"好用？因为只要节奏稳，人是能适应的——就像坐一趟固定慢十分钟的公交，你提前十分钟出门就完了。可要是这趟车忽快忽慢，你压根没法安排。语音通话的接收端也是这个思路：稳定的延迟能被一个固定缓冲"藏起来"，忽快忽慢藏不住。

C 的平均延迟只有 A 的 1.3 倍，却完全不能用；B 的平均延迟是 A 的 16 倍，反而勉强能用——这就是抖动的威力。

接收端的对策叫抖动缓冲区（Jitter Buffer），它的工作原理是一次经典的取舍：

【没有缓冲】包一到就播
  包到达间隔：20ms 20ms 90ms 5ms 20ms 110ms
  播放效果：正常 正常 卡顿 挤 正常 卡顿   ← 惨不忍睹

【有 100ms 抖动缓冲】先攒 100ms 再开始播
  攒够 5 个包才开始播，之后每 20ms 稳定播一个
  播放效果：全程平滑                     ← 但整体延迟 +100ms

取舍：缓冲越大 → 越平滑，但延迟越高
      缓冲越小 → 延迟越低，但抖动一大就爆
现代方案：动态自适应缓冲
      网络稳 → 缓冲缩到 20ms（追求低延迟）
      网络抖 → 缓冲涨到 200ms（追求不断线）
      这就是微信语音"有时特别流畅、有时明显延迟"的原因

# 测抖动最简单的办法
PS> ping -n 50 baidu.com
   看"最长"和"最短"的差值 —— 差值就是抖动的粗略量级
   差 < 10ms 优秀；10~50ms 一般；> 50ms 实时应用会受影响

抖动缓冲区干的活儿，说白了就是公交调度员在起点站先攒几辆车，然后按固定间隔一辆辆放出去：哪怕上游来车忽快忽慢，下游看到的都是准点发车。代价是每个人都得多等一会儿（缓冲的那段时间）。这就是微信语音"有时特别流畅、有时明显有延迟"的原因——它在根据网络好坏，偷偷调整"先攒多久再放"。

指标五 · 丢包率（Packet Loss）

"路上丢了多少件"——发出 100 个数据包，丢了几个。单位是百分比。

丢包率就是邮局的丢件率，这个类比几乎是一比一的：寄一百件丢三件，就是 3%。但网络的丢包有个邮局没有的特点——丢一件的代价远不止那一件，下面那个公式说的就是这件事。

丢包最狠的地方在于它对 TCP 的伤害是非线性放大的。你可能以为丢 2% 就是慢 2%，实际远不止——因为 TCP 把丢包解读成"网络堵了"，会主动把发送窗口砍半，然后慢慢爬回来。有一个经典的近似公式（Mathis 公式）能量化这件事：

为什么丢包的伤害会被放大？说白了就是快递公司一发现有件丢了，就以为路上堵得厉害，立刻把发车量砍掉一半——然后再一点点试着加回来。丢一件，损失的不是那一件，而是接下来一整段时间的运力。这就是"丢 2% 却慢了十倍"的来历。

单条 TCP 连接的最大吞吐 ≈ MSS ÷ (RTT × √丢包率)

代入 MSS=1460 字节，RTT=100ms：
  丢包率 0.01%  → 1460 ÷ (0.1 × 0.01) ≈ 1.46 MB/s ≈ 11.7 Mbps
  丢包率 0.1%   → 1460 ÷ (0.1 × 0.0316) ≈ 462 KB/s ≈ 3.7 Mbps
  丢包率 1%     → 1460 ÷ (0.1 × 0.1) = 146 KB/s ≈ 1.2 Mbps
  丢包率 2%     → 约 103 KB/s ≈ 0.8 Mbps

结论：丢包率从 0.01% 涨到 1%（只涨了一个百分点），
      吞吐量掉到原来的十分之一。
      而且你的千兆宽带在 1% 丢包下，
      单连接只能跑出 1.2 Mbps —— 带宽完全用不上。

这也解释了两个常见困惑：为什么"WiFi 信号只有两格"时下载速度会断崖式下跌（不是带宽变小了，是丢包率上去了，TCP 自己把速度砍了）；为什么跨国下载即使办了千兆也快不起来（RTT 和丢包率在公式的分母上，两个一起变大是致命的）。

用大白话把这两个现象再说一遍：WiFi 只有两格时下载断崖式下跌，不是带宽变细了，是包丢得多了，你的电脑自己主动踩了刹车。好比路上有点小坑，司机没往"绕一下就行"想，而是直接把车速降到二十码——路还是那条路，慢是自己慢的。这正是下面 BBR 算法要解决的问题。

丢包还分两种性质完全不同的类型，处理方式截然相反：

最后一行是 TCP 一个延续了三十年的设计缺陷：经典 TCP 把所有丢包都当成"网络拥塞"，所以在信号差的无线环境下会不必要地自我降速。这正是 Google 在 2016 年推出 BBR 拥塞控制算法的动机——它不看丢包，而是主动测量"实际带宽"和"最小 RTT"来决定发送速率。在丢包率 1% 的链路上，BBR 的吞吐量可以是传统 CUBIC 算法的几十倍。这也是 YouTube 在弱网下比很多视频站流畅得多的技术原因。

BBR 干的活儿换成大白话就是：老算法一看丢件就认定"路堵了，赶紧减车"；BBR 改成"我自己量一下这条路实际能过多少车、最快跑一趟要多久"，然后按量出来的数发车。因为它压根不把丢件当成堵车的信号，所以在信号飘忽的手机网络上不会冤枉自己减速——弱网下能快出几十倍，就是这么来的。

指标六 · 并发连接数与 QPS：服务器侧的性能指标

前面五个指标都是从"一条链路"的视角看的。但如果你站在服务器一侧，关心的就完全是另一组数字了——它能同时招待多少人、每秒能办多少事。

这一组指标换成餐厅的话就特别好懂：并发连接数=此刻店里坐了多少桌客人（哪怕他们只是在喝茶聊天）；QPS=每秒钟出几道菜；TPS=每秒钟结几单账；P99 延迟=一百桌里最慢那一桌等了多久。"坐满了"和"出菜快"是两件完全不同的事——一家茶馆能坐满两百桌却一小时才出十道菜。

其中 P99 这个概念值得单独说，它是"平均值骗人"最典型的解药。看这个例子：

某接口 1000 次请求的耗时分布：
  990 次：10 ms
   10 次：3000 ms（比如触发了慢查询）

平均延迟 = (990×10 + 10×3000) ÷ 1000 = 39.9 ms   ← 看起来很棒！
P50（中位数）= 10 ms                              ← 也很棒
P99          = 3000 ms                            ← 真相暴露

现实意义：每 100 个用户里就有 1 个等了 3 秒。
如果一个页面要发 20 个请求，那么
  至少有一个请求命中 P99 的概率 = 1 - 0.99^20 = 18%
—— 每 5 个用户就有 1 个会遇到"页面卡了一下"。

所以业界的监控标准是看 P95 / P99 / P999，
而不是平均值。"平均耗时 40ms" 是一句没有信息量的话。

P99 这个概念说白了就是"最惨的那百分之一有多惨"。餐厅说"平均上菜 40 秒"，可要是每一百桌里就有一桌等了三千秒（五十分钟），这家店的口碑是被那一桌毁掉的，跟平均数无关。更狠的是：一个页面要发二十个请求，只要其中任意一个撞上 P99，用户就觉得"卡了一下"——算下来每五个用户就有一个会撞上。

还有一条容易被误解的："高并发"和"高 QPS"不是一回事。一台服务器可以维持 50 万个长连接却只有 1000 QPS（比如消息推送服务，大部分连接长期空闲）；也可以只有 500 个并发连接却跑到 5 万 QPS（比如缓存服务，每个连接都在疯狂请求）。前者的瓶颈是内存，后者的瓶颈是 CPU——诊断和优化方向完全相反。

这两件事的差别打个比方：五十万个长连接却只有一千 QPS，好比一间大会议室坐了五百人开会，但一小时只有三个人发言——挤的是座位（内存）；五百个连接跑到五万 QPS，好比会议室只坐了五个人，可这五个人一秒钟能吵十几个来回——累的是嗓子（CPU）。两种"忙"该加的东西完全不一样。

QoS：当带宽不够时，谁该先走

前面所有的讨论都隐含一个前提：大家平等地抢带宽。但现实中不同流量的重要性天差地别——视频会议卡一秒是灾难，后台系统更新慢十分钟无人察觉。QoS（Quality of Service，服务质量）就是用来打破这种"绝对平等"的机制。

QoS 说白了就是医院的分诊制度：门诊大厅里排队的人不是先来先看，心梗的病人插到最前面，看个感冒的往后挪一挪。这不是不公平，恰恰是因为绝对公平会导致最糟的结果——让心梗病人在感冒队伍里排三小时，才是真正的荒谬。

它的核心思想是：带宽紧张时，不该让所有人一起变慢，而应该让不重要的先慢下来。常见手段有四类：

• 分类与标记 Classification先识别流量类型（靠端口、协议、五元组、或 DPI），然后在 IP 头的 DSCP 字段里打上优先级标签。企业网络里语音打 EF（快速转发）、视频打 AF41、批量下载打默认级。
• 优先队列 Priority Queuing路由器不再用一个队列先来先服务，而是分成几个队列，高优先级的队列永远先发。这是最直接的手段，也最容易把低优先级流量彻底饿死。
• 限速与整形 Shaping / Policing给某类流量设上限。整形是"超了就先缓一缓再发"（平滑），限速是"超了就直接丢"（粗暴）。家用路由器的"给某台设备限速"就是这个。
• 公平队列 Fair Queuing不分贵贱，但保证每条流都能分到一份，防止一个 BT 下载把全家的带宽吃光。前面提到的 fq_codel 就是"公平队列 + 主动队列管理"的组合。

这四类手段用分诊台来讲就是：分类与标记=在挂号单上写清"急诊 / 普通门诊 / 体检"；优先队列=急诊窗口永远先叫，代价是体检的人可能一整天叫不到号；限速与整形=给体检项目每小时限二十人，超了就明天来（整形是"先在候诊室等着"，限速是"直接让你回家"）；公平队列=不分贵贱，但保证每个科室都能轮到叫号，防止一个科室把全院的号都占了。

这张表是整节内容的实操总纲：没有一个应用同时对四项指标都敏感，所以"优化网络"从来不是把四项都拉满，而是搞清"这个场景在乎哪一项"，然后针对性地牺牲其他项。游戏玩家愿意为了 5ms 的延迟改用有线并关掉所有下载；备份任务愿意在凌晨慢慢跑一整夜。带宽、时延、抖动、丢包不是四个"越好越好"的分数，而是一组需要你按场景做取舍的旋钮。

这张表用大白话总结就一句：没有一个应用是"四项全都在乎"的。打电话在乎准点、压根不在乎水管粗细（30 Kbps 就够，相当于一根吸管）；下载电影在乎水管粗细、压根不在乎晚十分钟开始。所以"优化网络"从来不是把四个数字都拉满，而是想清楚这一件事在乎哪一项，然后果断牺牲其余的。游戏玩家为了 5 毫秒愿意插网线、关掉所有下载；备份任务愿意在凌晨慢慢跑一整夜——这就是取舍。

最后一个残酷的现实：QoS 只在"你能控制的那一段"有效。你在家用路由器上给游戏开最高优先级，只能保证在你家这段线路上它先走；一旦包出了你家，运营商和公网上的几十台路由器完全不认你的标记（互联网的默认承诺就是"尽力而为"，不保证质量）。所以家用 QoS 能解决"家人下载导致我打游戏卡"，但解决不了"跨国服务器延迟高"。企业专线（MPLS/SD-WAN）卖的就是"全程都受控"这件事，价格是普通宽带的几十倍。

最后那条限制值得记牢：你在自家路由器上给游戏开最高优先级，只在"你家小区里那一段路"有效。好比你在自己家门口那条小路上给自己划了条应急车道——车一开上市政大马路，交警压根不认你那条线。所以家用 QoS 能解决"家人下载导致我卡"，但解决不了"跨国服务器延迟高"。企业专线贵在哪？贵在它把全程每一段路都买下来了。

三件事各自的"罪魁祸首"

同样一句"网慢"，背后可能是三种完全不同的问题——对症下药才能根治：

这一步是整节最实用的地方。"网慢"这三个字，跟病人说"我不舒服"一样毫无信息量——头疼、肚子疼、脚踝肿，是三个科室的事。先把"慢"分诊成"下载慢 / ping 高 / 丢包多"这三种病，才谈得上下药。

把这套诊断思路再细化一层，就成了一张能直接照着做的对照表。关键是先用一两个命令把问题定位到某一层，再动手。

这张表的价值不在于记住每一条，而在于养成一个习惯：先做一次能区分"是我的问题还是对方的问题"的对比实验，再决定动哪里。换个网站、换根网线、换个时间、换台设备——这四个"换"能在两分钟内排除掉八成的错误方向。

这张表的用法，说白了就是医院的分诊问诊单：不管病人说得多含糊，护士都会按固定顺序问一串是非题，一步步把范围缩到某个科室。"换个网站、换根网线、换个时间、换台设备"这四个"换"，就是网络问题的四道分诊题——两分钟能排掉八成的错误方向，比瞎折腾一小时管用得多。

怎么"体检"自己家的网络

给你三个免费工具，一分钟搞定：

这三步就是给家里的网做一次基础体检：测带宽相当于量血压（看水管够不够粗），测时延相当于测反应速度（看水多久流到），测丢包相当于查漏（看路上丢没丢件）。跟人体检一样，最有价值的不是某一次的数字，而是有一份"平时正常是多少"的底账——出问题时才知道到底哪一项变了。

如果想做得更专业一点，下面这套"完整体检流程"能在五分钟内把六项指标全部量化。建议把结果记下来，作为你家网络的"基线"——以后出问题时才有对比的依据。

# ① 带宽：网页测速（注意关掉其他所有下载和视频）
   speedtest.cn / fast.com / 或命令行工具 speedtest-cli
   看三个数：下载 / 上传 / 空载延迟（Idle Latency）

# ② 时延与抖动：连测 50 次，看最短、最长、平均
PS> ping -n 50 223.5.5.5
   最长 - 最短 = 抖动量级

# ③ 丢包：发 200 个包统计
PS> ping -n 200 223.5.5.5
   丢包率 > 1% 就该查了

# ④ 逐跳定位：找出是哪一段出问题
PS> pathping baidu.com            # Windows 自带，会跑几十秒
$ mtr -r -c 100 baidu.com         # Linux/macOS，输出更清晰

# ⑤ Bufferbloat 专项：这一项最容易被忽略、却最影响体验
   打开 waveform.com/tools/bufferbloat 或 speedtest.net
   它会在跑满带宽时同时测延迟，直接给你一个 A~F 的评级
   拿到 C 以下就该在路由器上开 SQM 了

# ⑥ MTU 上限：只在"大文件传输异常"时才需要测
PS> ping -f -l 1472 223.5.5.5     # 通了说明 MTU ≥ 1500

# ⑦ 应用层分段耗时：判断"慢"到底慢在哪一步
$ curl -o /dev/null -s -w "DNS:%{time_namelookup} TCP:%{time_connect} \
TLS:%{time_appconnect} TTFB:%{time_starttransfer} 总:%{time_total}\n" \
https://你常用的网站

读测速结果时有三个容易被忽略的细节。第一，一定要看上传带宽——家用宽带的上传通常只有下载的十分之一（500M 下载可能只配 30M 上传），而视频会议、云盘同步、直播、远程办公全靠上传。很多"网卡"其实是上传被占满了。第二，要看"空载延迟"和"负载延迟"两个数——现在的测速网站都会给这两个值，两者差得越多，Bufferbloat 越严重。第三，测速服务器的位置会显著影响结果——默认选的是本市节点，那测的是"到本市"的能力，跟你访问国外网站的体验没什么关系。

那条"一定要看上传带宽"值得再敲一遍：家用宽带的上传通常只有下载的十分之一——500M 下载可能只配 30M 上传。而视频会议、云盘同步、直播、远程办公，全都靠上传。很多人抱怨"网卡"，真凶是某个网盘正在后台把上传那根细管子占满了——好比进水管很粗，出水管只有一根吸管，洗衣机一开，全家都没法用水。

常见误解澄清

• 误解 1 · 500M 宽带 = 500MB/s 下载速度错！运营商说的是 Mbps（兆比特），下载软件显示的是 MB/s（兆字节）。1 字节 = 8 比特，所以 500M 宽带理论下载峰值约 62.5 MB/s。
• 误解 2 · WiFi 信号满格 = 网速一定快错！信号满格只说明"你和路由器连得好"。但如果路由器本身只接了 100M 宽带，你再满格也只有 100M。
• 误解 3 · 5G WiFi 一定比 2.4G 快通常对，但 5G 信号穿墙能力差——隔两堵墙 5G 可能还不如 2.4G。
• 误解 4 · 手机流量"满格 5G 信号"就是快满格只代表信号强度，不代表基站不拥塞。演唱会现场信号满格但完全刷不出网页，就是基站过载。
• 误解 5 · 换根"贵网线"能提速网线只有"够不够规格"，没有"更快"。跑千兆只需 Cat5e（约 2 元/米），Cat6 及以上是为 2.5G/10G 准备的。几百块的"发烧级网线"对家用带宽零提升——数字信号只有对与错，没有"更清晰"。
• 误解 6 · Ping 值低就等于游戏不卡ping 测的是平均延迟，而游戏体验取决于抖动和丢包。平均 30ms 但每隔十秒抖到 300ms，比稳定的 80ms 难受得多。
• 误解 7 · 加带宽能降延迟带宽只影响四种时延中的"传输时延"那一项，而它通常只占总延迟的百分之一。把 100M 升到 1000M，你 ping 值几乎不会变。
• 误解 8 · 用了 VPN / 加速器一定更快加速器的原理是"换一条更优的绕行路径"，如果原路径本来就是最优的，绕路只会更慢。它对"路由绕行严重"的情况有效，对"物理距离远"的情况无解。
• 误解 9 · 只看下载带宽上传通常只有下载的 1/10。视频会议、云同步、直播全靠上传——很多"网卡"的真凶是上传被某个后台同步占满了。

这九条误解里最值得记住的是第 1 条和第 7 条。第 1 条：运营商说的"500M"是比特，下载软件显示的是字节，中间差 8 倍，所以 500M 宽带满速就是 62.5 MB/s，不是 500 MB/s——这跟"一斤"和"一公斤"的关系一样，不是虚标。第 7 条：加带宽降不了延迟，因为水管变粗改变不了水厂到你家的距离——把 100M 升到 1000M，你 ping 值几乎一个数都不会变。

给普通人三条实用建议

这三条为什么管用，用生活话讲就特别顺：① 有线比无线稳，好比走专用通道比在人堆里挤稳当得多——面试、网考这种场合，稳定压倒一切；② 路由器放高处放中间，是因为无线信号跟灯光一样直着走、怕遮挡，塞在电视柜里就相当于把灯泡关在抽屉里；③ 定期重启相当于把仓库里堆了一个月的废单据清一遍——那些早就断了却还占着记录的僵尸连接，清掉就顺了。