奇迹器带宽的独享和分享到底差在哪？从旨趣到实测讲昭彰一、从一个问题提及奇迹器带宽标称100M，日间 iperf 跑出来99M，没问题。

但用户反馈每天晚上七八点以后网站特等慢。

查奇迹器 CPU、内存、负载，全浅近。Nginx 日记莫得特地。应用层莫得任何问题。

然后让运维跑了一下 iperf：

# 晚上8点

#后端 #奇迹器 #运维 #每天一个学问点

iperf3 -c 民众测试 IP -t 30 -P 4

[ ID] Interval Transfer Bitrate

[ 5] 0.00-30.00 sec 42.5 GBytes 12.2 Mbits/sec

100M 带宽只跑出12M。

第二天凌晨再测：

# 凌晨2点

iperf3 -c 民众测试 IP -t 30 -P 4

[ ID] Interval Transfer Bitrate

[ 5] 0.00-30.00 sec 348 GBytes 99.7 Mbits/sec

跑满了。

归拢个奇迹器，归拢条清醒，凌晨100M，晚上12M。

这种"日间浅近晚上慢"的带宽阐发，根因时时是 分享带宽 。

二、独享和分享的技艺现实独享带宽奇迹器接入的物理链路带宽全部分派给你。不存在和其他用户争抢的问题。

[你的奇迹器] ──── 100Mbps专线 ──── [中枢交换机] ──── [互联网]

无论什么时段，这条100M 清醒王人是你的。现实速度受限于物理链路才调，不会因为别东说念主的流量而缩水。

分享带宽奇迹器接入的是一个大带宽池，你和其他用户共同使用。

[你的奇迹器] ──┐

[用户A] ──┤

[用户B] ──┼── 1Gbps总清醒 ──── [中枢交换机] ──── [互联网]

[用户C] ──┤

[用户D] ──┘

假定总清醒1Gbps，分给20个客户，每家"100M"。表面上20家同期跑满刚好用完1G。

但现实上不是整个东说念主同期跑满。日间大大王人东说念主访谒量不大，总带宽有豪阔，你偶尔能跑满100M。但到了晚上，民众王人在线，20家通盘抢1G，每家现实分到的就少了。 分享带宽用的是统计复用（Statistical Multiplexing）的念念路： 假定所灵验户不会同期用满带宽，是以在总带宽不变的情况下分派了跨越总带宽的答应。这在大部分时候是斥地的——大部分奇迹器大部分时刻用不悦带宽。但一朝出现所灵验户同期高负载的场景，答应的带宽就罢了不澄清。

三、怎样阔别：iperf不同期段测试最成功的设施：不同期段跑 iperf 看各别。

# 找一台独享带宽的测试奇迹器（各大云厂商时时有民众iperf节点）

# 或者用 iperf.he.net / bouygues.iperf.fr 等民众节点

# 不同期段各跑一次

iperf3 -c 测试 IP -t 30 -P 4

写个剧本自动纪录：

#!/bin/bash

# save as bandwidth_test.sh

# crontab: 不同时间扩充，比如 0 2，10，14，20，22 * * *

TEST_IP="你的测试 IP" LOG_FILE="/var/log/bandwidth_test.log"

echo "=== $(date '+%Y-%m-%d %H:%M:%S') ===" >> $LOG_FILE iperf3 -c $TEST_IP -t 30 -P 4 2>&1 | grep "sender" >> $LOG_FILE echo "" >> $LOG_FILE

# 加到crontab，每天不同期段各跑一次

crontab -e

0 10 * * * /root/bandwidth_test.sh

0 14 * * * /root/bandwidth_test.sh

0 20 * * * /root/bandwidth_test.sh

0 22 * * * /root/bandwidth_test.sh

跑几天之后看数据：

[ 5] 0.00-30.00 sec 348 GBytes 99.7 Mbits/sec

=== 2024-12-01 10:00:00 === [ 5] 0.00-30.00 sec 238 GBytes 68.5 Mbits/sec

=== 2024-12-01 14:00:00 === [ 5] 0.00-30.00 sec 192 GBytes 55.2 Mbits/sec

=== 2024-12-01 20:00:00 === [ 5] 0.00-30.00 sec 42.5 GBytes 12.2 Mbits/sec

=== 2024-12-01 22:00:00 === [ 5] 0.00-30.00 sec 65.0 GBytes 18.7 Mbits/sec 判断尺度： 凌晨和晚岑岭差距 30% → 好像率是分享带宽四、上行和下行可能不不异除了独享/分享，还有一个容易忽略的问题：辗转行速度是否对称。 对 Web 奇迹器来说： 上行 （奇迹器往外发）= 用户下载页面、图片、API反映下行 （奇迹器接纳）= 用户上传文献、发送恳求大部分 Web 业务，上行流量弘大于下行。上行才是瓶颈。 有些带宽决策是不合称的：

# 测上行（默许地方：客户端发给奇迹端）

iperf3 -c 测试 IP -t 10

# 测下行（-R回转：奇迹端发给客户端）

iperf3 -c 测试 IP -t 10 -R

要是两个数字差距很大，阐述辗转行不合称。对 Web 奇迹来说，要要点怜惜上行阿谁数字。

对称的清醒两个地方的速度应该基本一致（差距

五、一个完竣的带宽排查历程遭受"带宽跑不悦"或者"岑岭期网速慢"的问题，按这个礼貌排查：

Step 1：证据网卡和清醒物理景况# 看网卡协商速度

ethtool eth0 | grep Speed

# Speed: 1000Mb/s ← 千兆网卡，浅近

要是是 Speed: 100Mb/s ，阐述网卡协商到了百兆，滚球app(中国)官网下载可能网线或者交换机端口有问题。

# 看网卡装假统计

ethtool -S eth0 | grep -i "error\|drop"

rx_errors、tx_errors、rx_dropped 要是有抓续增长，阐述物理层有问题。

Step 2：iperf测现实带宽iperf3 -c 测试IP -t 30 -P 4

-P 4 暗示4个并发流，幸免单流被 TCP 窗口限定。要是带宽很大（>1G），可能需要更多并发流。

要是 iperf 跑出来的速度远低于标称带宽，问题在链路层。要是 iperf 能跑满但业务访谒慢，问题在应用层。

Step 3：不同期段对比用上头的剧本跑几天，看是否惟恐段性波动。

Step 4：搜检TCP拥塞限度要是 iperf 跑不到标称带宽，摒除了分享身分后，搜检 TCP 拥塞限度算法：

sysctl net.ipv4.tcp_congestion_control

# cubic

在跨网场景下 CUBIC 可能只可用到带宽的30-50%。换成 BBR 试试：

sysctl -w net.ipv4.tcp_congestion_control=bbr

sysctl -w net.core.default_qdisc=fq

切换后再行 iperf 测试。要是带宽哄骗率彰着进步，阐述之前的瓶颈在拥塞限度算法。

Step 5：搜检TCP缓冲区sysctl net.ipv4.tcp_rmem

sysctl net.ipv4.tcp_wmem

net.ipv4.tcp_rmem = 4096 87380 6291456

net.ipv4.tcp_wmem = 4096 65536 6291456

第三个数字是最大缓冲区大小。高延长场景下，带宽时延积（BDP）= 带宽 × 延长。要是缓冲区最大值小于 BDP，带宽会被缓冲区限定。

# 例：100M带宽，100ms延长

# BDP = 100Mbps × 100ms = 1.25MB = 1，250，000字节

# 要是tcp_wmem最大值惟有6MB，对这个场景够用

# 但要是带宽更大或延长更高，可能需要调大

sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216" sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

Step 6：证据不是应用层瓶颈# 看Nginx的现实传输速度

# 开启access_log的$body_bytes_sent和$request_time

tail -f /var/log/nginx/access.log | awk '{print $NF， $(NF-1)}'

要是 Nginx 的传输速度远低于 iperf 测出来的带宽，阐述瓶颈在应用层（Nginx 建树、后端处理、磁盘 IO 等），不在集聚层。

六、对于BGP清醒的带宽BGP 多线的带宽情况更复杂一些。"100M BGP"可能有几种含义：

含义A：电+联+移 所有100M（三线分享总量）

含义B：每条清醒各100M（每线独处）

含义C：总出口100M，BGP只隆重智能选路（选哪条清醒出去，但总量不变）

这几种情况下现实可用带宽差距很大。拿到 BGP 清醒后，分裂从不同运营商的节点 iperf 测试：

# 从电节点测

iperf3 -c 奇迹器电信 IP -t 30

# 从联节点测

iperf3 -c 奇迹器联通 IP -t 30

要是电跑满的同期联通也跑满了，阐述每线独处。要是电信跑满时联惟有三分之一，阐述总量分享。

七、纪念遭受带宽关联的问题，中枢排查念念路就一条线：

物理层浅近吗？（网卡速度、装假统计）

→ 浅近 → iperf能跑满吗？

→ 不可 → 不同期段有各别吗？

→ 有各别 → 好像率是分享带宽

→ 无各别 → 查TCP拥塞限度和蔼冲区

iperf 是最基础的用具。拿到奇迹器后第一时刻不同期段跑几次 iperf，对我方的带宽情况冷暖自知。别等业务出问题了才去测。

TCP 调优（换 BBR、调缓冲区）能照顾不少"带宽跑不悦"的问题。特等是跨网场景下，CUBIC 和 BBR 的差距绝顶大。

要是是分享带宽导致的岑岭期缩水滚球app中国官网下载入口，TCP 调优帮不了——瓶颈不在 TCP 层，在物理链路的总容量。这种情况要么给与，要么换独享清醒。