一句话：网络负载就是网络上"正在跑的数据量"占了多少能力。负载低，数据畅通无阻；负载接近上限，数据开始排队，于是延迟升高、抖动变大，最后直接丢包。

前几篇讲了网关（数据从哪出去）、子网（谁和谁是邻居）、抖动缓冲（怎么扛波动）、CDN（怎么把大文件分散出去）。这一篇讲它们背后共同的问题：网络的能力是有限的，用多了会怎样，以及怎么少用。

一、生活里的例子：高速公路

一条三车道高速公路：

关键：路堵不堵，不只看车多不多，要看"车流 ÷ 路的能力"。同样 1000 辆车，在单车道是灾难，在八车道很轻松。

二、几个必须分清的概念

单位换算：最常见的误会

运营商说的 100M 宽带 = 100 Mbps（兆比特每秒） 下载软件显示的速度 = MB/s（兆字节每秒） 1 字节 = 8 比特 → 100 Mbps ÷ 8 ≈ 12.5 MB/s

所以"办了 100M 宽带，下载只有 12MB/s"是正常的，不是被骗。

带宽和 PPS 是两种不同的上限

游戏服务器经常是带宽还很空，PPS 已经满了。每个包无论大小，都要经过一次中断、一次系统调用（前面讲过的recvfrom/sendto）、一次路由查表 ——处理开销是按"个"算的。很多云服务器也会对每台机器的 PPS 设上限。

三、负载高了为什么会变慢：排队

网络设备里，每个出口都有一个队列。包到得比发得快，就要排队。

一个反直觉的事实：利用率不是"越接近 100% 越好"

用最简单的排队模型估算，平均等待时间大约是：

平均耗时 ≈ 处理一个包的时间 ÷ (1 − 利用率)

延迟 │ ╱ │ ╱ │ ╱ │ ╱ │ __╱ │____________________───── └──────────────────────────────────── 利用率 0% 50% 80% 100% ↑ 过了这里，延迟开始飙升

这就是为什么运维常说"链路利用率长期超过 70%～80% 就该扩容了"。不是因为满了，而是因为还没满，体验就已经崩了。

负载升高的完整过程

负载低 → 包几乎不用排队 延迟稳定 负载升高 → 队列时长时短 **抖动变大**（抖动缓冲区要变大） 接近上限 → 队列一直很长 **延迟持续升高** 超过上限 → 队列满了，新包被直接扔掉 **丢包**

上一篇提到的**缓冲膨胀（Bufferbloat）**就发生在第三步：路由器的队列设得太大，宁可让包排几百毫秒也不丢，结果"能用但巨卡"。

四、负载从哪来：家里、路上、服务器

一个玩家打游戏，数据要经过好几段路，任何一段满了都会卡：

玩家电脑 ─ Wi-Fi ─ 家用网关 ─ 运营商接入 ─ 骨干网 ─ 机房出口 ─ 服务器网卡 ─ 游戏进程 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧

第 ⑧ 点容易被忽略：网络没满，是程序处理不过来。表现和网络拥塞一样（延迟高、丢包），但要优化的是代码，不是带宽。

五、动手查看网络负载

客户端 / 个人电脑

一个简单的"缓冲膨胀"自测：

1. 不开任何下载，ping 游戏服务器 → 比如 30ms 2. 开一个大文件下载，同时继续 ping → 如果涨到 200ms+，就是排队严重

Linux 服务器

nload# 实时看网卡收发带宽iftop# 看哪些连接在占流量sar-nDEV1# 每秒的收发字节数、包数（PPS）ss-s# 连接数统计netstat-su# UDP 统计：留意 "receive buffer errors"（程序来不及收）iperf3-c服务器IP# 测两台机器之间的实际带宽

netstat -su里的receive buffer errors一直在涨，说明内核替你丢包了：网络把包送到了，你的进程没来得及读。这时调大接收缓冲区（SO_RCVBUF）或优化处理逻辑，比加带宽有用。

Unity 里

六、算一笔账：射击游戏到底要多少带宽

假设一局64 人的射击游戏，服务器30Hz（每秒 30 次快照）。

每个玩家的状态（朴素写法）

计算

每个快照： 63 个其他玩家 × 52 字节 ≈ 3276 字节 + IP/UDP 头部 28 字节 ≈ 3.3 KB ← 已经超过一个包大约 1200～1400 字节的安全上限，要拆成 3 个包 每个玩家下行：3.3 KB × 30 次/秒 ≈ 99 KB/s ≈ 790 Kbps 一局服务器出口：× 64 人 ≈ 6.3 MB/s ≈ 50 Mbps 一台机器跑 50 局：≈ 2.5 Gbps ← 普通千兆网卡直接打满 PPS：64 人 × 30 次 × 3 个包 × 50 局 ≈ 29 万包/秒

这还没算子弹、技能、特效事件、语音。所以带宽优化不是"锦上添花"，而是决定一台服务器能开多少局、服务器账单是多少。

优化之后（第七节的技巧组合）

优化后每个快照：20 × 6 + 28 ≈ 150 字节 → 一个包就够 每个玩家下行：150 × 30 ≈ 4.5 KB/s ≈ 36 Kbps

从 790 Kbps 降到 36 Kbps，约二十分之一。同一台服务器可以多开很多局，玩家在差网络下也更稳。

七、降低负载的六个核心技巧

1. 量化：别用 float 存不需要那么精确的东西

地图范围 ±1024 米，精度 1 厘米就够：

可能的取值：2048 ÷ 0.01 = 204,800 种 2^18 = 262,144 ≥ 204,800 → 每个轴 18 位就够 位置：3 × 32 位 = 96 位 → 3 × 18 位 = 54 位

publicstaticclassQuantize{// 把 [min, max] 范围的 float 压到 bits 位整数publicstaticuintEncode(floatv,floatmin,floatmax,intbits){uintmaxValue=(1u<<bits)-1;floatt=UnityEngine.Mathf.InverseLerp(min,max,v);// 自动夹到 0~1return(uint)UnityEngine.Mathf.RoundToInt(t*maxValue);}publicstaticfloatDecode(uintq,floatmin,floatmax,intbits){uintmaxValue=(1u<<bits)-1;returnUnityEngine.Mathf.Lerp(min,max,q/(float)maxValue);}}

2. 位压缩：按"位"写，不按"字节"写

量化之后是 18 位、7 位、1 位这种零碎的长度，用字节存会浪费。写一个简单的位写入器：

publicclassBitWriter{readonlybyte[]buffer;intbitPos;publicBitWriter(intcapacity)=>buffer=newbyte[capacity];publicvoidWrite(uintvalue,intbits){for(inti=0;i<bits;i++){if(((value>>i)&1)!=0)buffer[bitPos>>3]|=(byte)(1<<(bitPos&7));bitPos++;}}publicvoidWriteBool(boolb)=>Write(b?1u:0u,1);publicintByteCount=>(bitPos+7)>>3;// 向上取整到字节publicbyte[]Buffer=>buffer;}

使用：

varw=newBitWriter(1200);w.Write(Quantize.Encode(pos.x,-1024,1024,18),18);w.Write(Quantize.Encode(pos.y,-64,192,15),15);// 高度范围小，位数更少w.Write(Quantize.Encode(pos.z,-1024,1024,18),18);w.Write(Quantize.Encode(yaw,0,360,10),10);w.Write((uint)health,7);w.WriteBool(isCrouching);// 合计 69 位 ≈ 9 字节，原来是 52 字节

这里的移位和按位与，和上一篇子网掩码的计算是同一套东西：>> 3是除以 8，& 7是对 8 取余。

3. 增量压缩：只发变了的

站着不动的玩家，位置每帧都一样，没必要重发。

每个字段前加 1 位"变了吗"： 0 → 没变，后面不带数据 1 + 新值 → 变了 更进一步：以"客户端已确认收到的那一帧"为基准做差

基准必须是对方确认收到过的帧，否则丢一个包，后面的增量全都对不上。

4. 兴趣管理（AOI）：只发你需要知道的

地图另一头的敌人，你看不见、听不见、打不着，就不用每帧告诉你。

第一篇讲遮挡剔除时说"看不见的不画"；这里是"看不见的不发"。思路完全一样，甚至可以复用同样的空间划分和可见性数据。

5. 带宽预算 + 优先级：总量固定，重要的先发

给每个客户端每个快照一个固定预算（比如 1200 字节），按优先级装包，装不下的留到下一次 —— 但它的优先级会一直累积，不会被永远饿死。

usingSystem.Collections.Generic;publicclassPrioritySender{classEntry{publicintentityId;publicfloataccumulated;}readonlyList<Entry>entries=newList<Entry>();publicvoidAdd(intid)=>entries.Add(newEntry{entityId=id});// basePriority：根据距离、是否在视野内、是否在开火等计算publicList<int>Pick(System.Func<int,float>basePriority,System.Func<int,int>sizeOf,intbudgetBytes){foreach(vareinentries)e.accumulated+=basePriority(e.entityId);entries.Sort((a,b)=>b.accumulated.CompareTo(a.accumulated));varpicked=newList<int>();intused=0;foreach(vareinentries){intsize=sizeOf(e.entityId);if(used+size>budgetBytes)continue;// 这次放不下，下次优先级更高used+=size;picked.Add(e.entityId);e.accumulated=0;// 发了就清零}returnpicked;}}

6. 合并小包、控制发送频率

八、网络已经拥塞时怎么办：拥塞控制

TCP 自带"刹车"

TCP 发现丢包或延迟升高，会自动降低发送速度，等路况好了再慢慢提速。所以下载大文件时，网络不会被一个连接彻底堵死。

UDP 没有刹车，游戏要自己做

射击游戏大多用 UDP。如果路已经堵了还照常狂发，只会让队列更长、丢包更多，自己和别人都更卡。

自适应发送的简单思路：

这和抖动缓冲区里"缓冲区根据抖动自动调整"是一个思路：持续测量，动态适应，变化要平滑。

客户端能做的

九、服务器扛不住时：把负载分出去

单台机器的带宽、PPS、CPU 都有上限。超过之后，就要把负载分摊到多台机器。

┌─ 静态资源 ─→ CDN 玩家 ─────────┼─ 登录/商城 ─→ 负载均衡器 ─→ 多台 Web 服务器 └─ 实时战斗 ─→ 匹配服务分配 ─→ 某台战斗服务器（某一局）

这又回到"架构原则"：不同类型的负载走不同的路，各自独立扩容，一边出问题不拖垮另一边。

十、和前面几篇的联系

十一、常见的坑

一句话总结

网络负载 = 实际流量 ÷ 网络能力。负载升高时，数据先排队（抖动变大、延迟升高），再丢包；而且延迟不是线性增长，利用率过了 70%～80% 就会急剧变差。
衡量负载要同时看带宽和