带宽评估需理论估算、iperf3压测与业务映射闭环：先算内存/端口/硬件天花板，再用iperf3 -c -p4测tcp极限、-u -b测udp敏感性，最后按实时交互（时延>100ms即异常）、批量传输（公式反推）、事务型（吞吐+p99延迟）三类业务校准。
带宽评估不能只看标称值，也不能只靠在线测速网站点一下就完事。真实可用带宽受设备能力、协议开销、并发模型、链路质量等多重因素制约。一套靠谱的评估流程，必须从理论估算起步，再通过可控压测验证，最后结合业务场景做闭环判断。
理论估算：先划出性能“天花板”
理论计算不是拍脑袋，而是为后续测试设定合理预期和排查边界。关键指标包括：
- 内存承载力：Nginx 或其他服务端每连接约占用 128–256 KB 内存。8 GB 服务器预留 20% 系统资源后，空闲连接理论上限约 3.4 万；若传输大文件，实际承载会大幅下降。
- 系统资源限制：检查 ulimit -n 和 worker_rlimit_nofile，确保文件描述符足够；确认本地端口范围（net.ipv4.ip_local_port_range）未被耗尽，尤其在反向代理高并发场景下。
- 硬件带宽基础：例如 LPDDR5 @6400MHz + 32bit 位宽，理论 DDR 带宽为 51.2 GB/s，但实际持续读写通常只能达到 30–40 GB/s，受总线调度与控制器效率拖累。
iPerf3 实测：绕过公网干扰，直测端到端链路
在线测速网页测的是“你到它”的路径，iPerf3 测的是“你到我”的路径——这才是你真正能掌控的链路。
- 服务端启动：iperf3 -s -p 5201，可加 -B 192.168.1.100 绑定指定网卡。
- TCP 基准测试：iperf3 -c 192.168.1.100 -t 30 -P 4，用 4 并发流逼近物理链路极限，观察是否稳定达到千兆或万兆标称值。
- UDP 敏感性验证：iperf3 -c 192.168.1.100 -u -b 100M -t 30，重点看丢包率与抖动，适用于视频会议、远程桌面等低延迟业务预判。
业务映射：把技术指标翻译成业务语言
带宽数字本身没有意义，必须对应到具体业务行为上才有决策价值。
- 实时交互型（如视频会议）：时延 >100ms、抖动 >30ms、丢包 >0.1%，画面/声音即明显异常。此时应优先优化路由、启用 QoS，而非盲目扩容带宽。
- 批量传输型（如日志回传）：只关心“X 小时内能否传完 Y GB 数据”。可用公式反推：所需最小带宽 =（数据量 × 8）÷ 时间窗口（单位：秒），再留 20% 余量。
- 事务型（如数据库主从同步）：对带宽与时延均有要求。需同时压测吞吐与 P99 延迟，确认 WAL 日志传输不积压、GTID 追赶不滞后。
瓶颈定位：识别真正的“短板”环节
整个链路中，性能由最弱一环决定。常见短板位置及验证方式：
- 网卡或驱动：用 ethtool 查协商速率与错误计数；更换网线或端口复测，排除物理层问题。
- 中间设备（交换机/防火墙）：在服务端直连客户端做 iPerf3，再逐级加入中间设备对比结果，快速隔离瓶颈点。
- 应用层处理：在 Nginx 后接一个轻量 HTTP 服务（如 Python http.server），对比直接 iPerf3 与走 Nginx 的吞吐差异，判断是否为配置或 worker 数量不足所致。
