如何按时间段配置服务器带宽限制

一天之内手动调整带宽上限会浪费你的时间。你可能过早限速，导致高峰时段出现拥塞；也可能在夜间仍保持较高限制，从而浪费带宽资源。这种不一致会损害网站性能和页面加载速度。

你可以自动配置服务器带宽限制的切换。使用 Linux 流量整形工具 tc 配合 cron 定时调度，即可针对不同时间段设置不同的限制。

本指南将向你展示具体做法。你将识别网络接口、编写 tc 规则、通过 cron 实现自动化，并测试结果。正确的配置可以在业务繁忙时减少服务器响应时间。当拥塞下降时，服务器的初始响应时间也会改善。更快的服务器响应时间意味着访客拥有更好的体验。

让我们开始吧。

前提条件与工具

在创建基于时间段的限制之前，你需要做好两件事：识别你的网络接口，并选择合适的流量整形工具。正确配置能够在流量高峰时降低服务器响应时间。把这些基础环节处理好，才能更高效地控制服务器带宽。

识别网络接口与带宽使用情况

你可以使用以下任一命令来查找网络接口：

• ip a —— 显示所有网络接口详情及其 IP 地址。

• ip link show —— 显示接口状态和 MAC 地址。

• nmcli device status —— 列出 NetworkManager 管理的设备状态。

你的网络接口通常是 eth0 或 ens33。请选择绑定公网 IP 的那个接口。

接下来，使用 nload 测量实际带宽使用情况。该工具会读取 /proc/net/dev 中的计数器，不会抓取数据包，因此开销很低。你需要了解网站的流量模式。它会以 ASCII 图形显示入站和出站流量，同时显示当前、平均、最小、最大速率以及总字节数。

nload 通过读取 /proc/net/dev 获取流量计数器。这种方式开销极低，且运行时不需要 root 权限。

运行 nload eth0 来观察带宽使用情况。准确的测量有助于改善服务器响应时间。利用这些数据来确定高峰和低谷时段的网络带宽限制。了解当前的实际消耗，才能设置出有效的带宽上限。

选择流量整形工具

tc 配合 HTB（Hierarchical Token Bucket，分层令牌桶）是 Linux 上的标准解决方案。HTB 允许你为不同流量类别设置保证速率和上限速率。在拥塞期间使用 HTB，有助于维持良好的服务器响应时间。你可以让 SSH 的优先级高于 HTTP，或者为管理网段分配更高优先级。下表展示了其主要使用场景：

如果你的规则更简单，也可以使用 TBF（Token Bucket Filter，令牌桶过滤器）。它不区分类别，只对所有流量施加单一速率限制。其他替代方案包括 iptables --limit 和 cgroups。但在基于时间段的规则场景中，tc 配合 HTB 提供了最高的灵活性。

完成这些前提准备后，你就能更好地降低服务器响应时间。现在你已经知道如何识别网络接口并选择合适工具。下一节将展示如何编写 tc 规则。

使用 tc 配置服务器带宽限制

现在开始编写实际规则。本节将解释两种主要的队列规则，并演示如何在不同时间段设置不同带宽上限。你将学会如何根据每日流量模式来配置服务器带宽限制的自动切换。

理解 HTB 和 TBF 队列规则

HTB 是 Hierarchical Token Bucket（分层令牌桶）的缩写。它将带宽组织成一个类别树，每个类别都拥有自己的令牌桶。令牌以固定速率生成，只有当令牌足够时，数据包才能被发送。这个机制能够精确执行你的带宽限制。

HTB 将简单令牌桶扩展为层级结构。你可以创建父类和子类，每个类别都拥有自己的参数。下表说明了两个关键参数：

rate 参数确保某个类别至少获得这部分带宽；ceil 参数则定义绝对上限。当某个类别需要超过其 rate 的带宽时，它会从父类中借用。借用会持续到该类别达到自身的 ceil，或者达到父类的 ceil 为止。这种设计可以高效利用未被占用的带宽容量。

来看一个简单例子。叶子类 #10 的 rate 为 200 kbps，ceil 为 400 kbps；叶子类 #20 的 rate 为 200 kbps，ceil 也为 200 kbps。类别 #10 最多可以再借用 200 kbps，而类别 #20 则完全不能借用，因为它的 rate 等于 ceil。

TBF 是 Token Bucket Filter（令牌桶过滤器）的缩写。它不区分类别，只施加单一速率限制。对于只需要给所有流量设定统一上限的简单场景，TBF 很合适。而对于基于时间段切换规则的需求，HTB 更灵活，因为你可以调整各个独立类别。

HTB 分两个阶段工作。首先，它满足每个子队列的保证速率；其次，它允许子类别从父类别借用令牌。这种分层满足机制确保关键流量总能获得最低保障，而优先级较低的流量则可以在链路空闲时使用剩余带宽。

为高峰与低谷时段编写规则

你将创建两组规则：一组用于高峰时段，另一组用于低谷时段。先从高峰时段开始。假设你希望将带宽上限设为 10 Mbps，可以使用以下命令：

tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit ceil 10mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 8mbit ceil 10mbit

第一条命令创建根队列；第二条命令定义父类别；第三条命令创建子类别。你还可以继续添加更多子类别，以适配不同端口组的带宽控制需求。

对于低谷时段，如果你希望将带宽上限提高到 50 Mbps，先删除旧规则，再应用新配置：

tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 50mbit ceil 50mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 40mbit ceil 50mbit

rate 参数表示保障带宽，ceil 参数表示最大带宽上限。当链路存在空闲容量时，服务器可以在高于 rate 的水平上突发传输。这种借用机制有助于在突发流量出现时改善服务器响应时间。

实际测试表明，HTB 表现良好。当两个客户端同时在 100 mbit 链路上传输时，每个客户端大约可获得 50–59 Mbits/sec；当其中一个客户端停止后，另一个客户端会提升至约 75–77 Mbits/sec。说明借用机制确实按设计工作。

CAKE 也是另一种可选方案。它默认提供按主机公平分配带宽的能力。在启用 triple-isolate 时，一个只有单连接的客户端可获得 50 mbit；另一个拥有十个连接的客户端，其总带宽也同样为 50 mbit。如果不进行流量整形，每个客户端的带宽可能会在 6–14 mbit 之间波动，且延迟显著恶化。合理的流量整形能够显著降低服务器响应时间。

这些规则可以有效控制服务器带宽。你可以根据测量得到的实际使用情况调整数值。下一节将介绍如何使用 cron 实现这些切换的自动化。

使用 Cron 实现自动化

手动切换规则违背了基于时间段管理带宽的初衷。你需要自动化，而 cron 能可靠完成这项任务。它会在你指定的精确时间运行 tc 命令。本节将向你展示如何构建脚本并正确设置调度。

为规则编写脚本

使用单一脚本可以让整个流程更简单。你可以在脚本中定义多个函数，每个函数应用不同的一组 tc 规则，然后在适当时间调用对应函数。

创建一个名为 /usr/local/bin/bandwidth-limits.sh 的文件。脚本中包含两个主要函数：一个应用高峰时段限速，另一个应用低谷时段限速。每个函数都会先删除现有规则，再添加新规则。

#!/bin/bash
apply_peak() {
    tc qdisc del dev eth0 root 2>/dev/null
    tc qdisc add dev eth0 root handle 1: htb default 10
    tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit ceil 10mbit
    tc class add dev eth0 parent 1:1 classid 1:10 htb rate 8mbit ceil 10mbit
}
apply_offpeak() {
    tc qdisc del dev eth0 root 2>/dev/null
    tc qdisc add dev eth0 root handle 1: htb default 10
    tc class add dev eth0 parent 1: classid 1:1 htb rate 50mbit ceil 50mbit
    tc class add dev eth0 parent 1:1 classid 1:10 htb rate 40mbit ceil 50mbit
}
case "$1" in
    peak) apply_peak ;;
    offpeak) apply_offpeak ;;
esac

使用 chmod +x /usr/local/bin/bandwidth-limits.sh 为脚本添加可执行权限。先手动测试它。运行 sudo /usr/local/bin/bandwidth-limits.sh peak，然后使用 tc -s qdisc ls dev eth0 检查当前规则。你应该会看到 10mbit 的速率设置。这个验证步骤能避免后续出现意外问题。

该脚本接受一个参数，即 peak 或 offpeak。这种设计使你的 cron 条目更简洁、更易读，也无需在 crontab 中重复冗长的 tc 命令。

使用 Cron 调度脚本

Cron 会从名为 crontab 的文件中读取任务计划。你可以使用 crontab -e 进行编辑。每一行包含五个时间字段和一个命令，字段依次表示：分钟、小时、每月第几日、月份、星期几。

你的计划需要两条记录：一条在 9:00 切换为高峰规则，另一条在 17:00 切换为低谷规则。配置如下：

0 9 * * * /usr/local/bin/bandwidth-limits.sh peak
0 17 * * * /usr/local/bin/bandwidth-limits.sh offpeak

第一条会在每天 9:00 运行，第二条会在每天 17:00 运行。如果你将这些行添加到 root 的 crontab 中，cron 就会以 root 权限执行脚本。请使用 sudo crontab -e 来完成此操作。

你也可以将这种方式扩展到更复杂的计划。例如，如果周末的高峰时段开始时间不同，就可以添加更多具有不同小时值的条目。Cron 会分别独立执行它们。

多个特定时间间隔可以用逗号指定（例如 1,2,3）。下面这行命令会在第 1、2、3 个小时内的每隔 5 分钟输出一次 “hello world”（也就是从 01:00、01:05、01:10 一直到 03:55）。

*/5 1,2,3 * * * echo hello world

这种逗号语法有助于合并条目。例如，如果你想在 8:00、12:00 和 17:00 应用高峰限制，可以写成 0 8,12,17 * * *，而不必分成三行。这样你的 crontab 会更整洁，也更容易审计。

编辑完 crontab 后，请进行验证。运行 crontab -l 查看当前计划，确认两条记录都已正确添加。接下来等待下一个计划时间观察变化，或者也可以先手动运行脚本测试各个函数，再正式依赖 cron 自动执行。

自动化可以从带宽管理中移除人为错误。你的服务器会在无需人工干预的情况下自动应用正确的带宽上限。这种一致性会直接改善高峰时段的服务器响应时间。由于拥塞得到控制，用户感受到的延迟也会更少。服务器响应时间能够在全天保持更稳定，夜间也不会再无谓浪费带宽资源。你的服务器将实现全天候高效运行。

测试与优化，以降低服务器响应时间

测试可以确认你的配置是否真正生效。本节将展示如何验证规则并探索替代方案。这些步骤有助于你在高负载情况下进一步降低服务器响应时间。

使用 iperf 验证带宽限制

iperf3 可以测量服务器的实际吞吐能力。先使用 iperf3 -s 启动监听模式，再通过客户端运行 iperf3 -c <host> 发起测试。你可以使用 --server-bitrate-limit #[KMG][/#] 选项测试你的带宽上限。这个工具会展示在 tc 规则作用下的真实传输速率。将测试结果与你的目标限制进行比较；若差异明显，通常意味着配置存在问题。

合理的带宽限制能够通过控制拥塞来降低服务器响应时间。当数据到达速度超过网络可承载能力时，数据包会进入输出队列，队列延迟会沿着多个网络跳点逐步累积。路由器缓冲区被填满后会发生丢包，TCP 会检测到丢失并将拥塞窗口缩减 50%。这种流量控制机制会降低数据传输速率，从而增加服务器响应时间。

不过，拥塞对服务器响应时间的影响并不是绝对的，因为服务器处理时间本身也可能占主导地位。举例来说，总响应时间为 5 秒，其中服务器处理用时 4.8 秒，网络部分仅占 0.2 秒，也就是 4%。在这种情况下，即使完全消除网络延迟，也未必会带来明显改善。你可以在应用限速前后使用 ping 测量延迟，以验证实际效果。

当网络流量需求超过可用容量时，就会发生网络拥塞。这会导致数据传输变慢、延迟升高，并可能引发数据丢失。更高的延迟会迫使系统进行重传，并延迟请求与响应的交付。

替代方案：防火墙与备份软件

你并不只能依赖 tc 规则。Palo Alto 防火墙提供带有基于时间调度的 QoS 配置文件。通过其 schedule（计划）选项卡，你可以按一天中的不同时间应用不同的服务质量策略。例如，可以在上午 7 点到中午 12 点以及下午 1 点到晚上 7 点限制 YouTube，仅在午休时段允许用户以 class4 类别观看视频。这种方式适用于网络边界层面的控制。

备份软件同样提供定时限速功能。例如 Arcserve 允许你在备份窗口期间设置带宽上限。这类工具可以管理服务器在数据传输过程中的出站流量。

通过这些规则管理网站流量，有助于提高页面加载速度。当拥塞下降时，服务器初始响应时间也会改善。你还可以支撑更高的 rps 以及更高的 maximum requests per second。请持续监控服务器响应时间，并观察在不同带宽上限下服务器处理传入请求的表现。每次调整计划后都测试一次服务器响应时间，再根据真实数据持续优化。这样的测试与调优循环，能够不断改善服务器响应时间。

你首先识别了网络接口，然后为高峰与低谷时段配置了 tc 规则，再通过 cron 自动切换这些限制，最后使用 iperf 验证吞吐量是否符合预期。

这种动态方法可以让你在无需手动操作的情况下完成服务器带宽限制切换。合理的带宽上限能够在业务高峰时控制服务器拥塞。当队列保持较短时，服务器响应时间就会改善。更快的服务器响应时间能让访客在流量高峰期间保持良好体验。这些调整能够有效降低高负载时的服务器响应时间。

你可以根据自身阈值调整这些示例。例如，白天设置为 20 Mbps，夜间设置为 100 Mbps。每次修改后都要监控服务器响应时间，并根据实际流量数据进行调优。通过恰当的定时调度，服务器就能更平稳地处理请求。

现在就运行 tc -s qdisc ls dev eth0，然后在今晚设置你的第一次定时切换吧。

常见问题

服务器重启后，我设置的带宽限制会怎样？

你的 tc 规则会在服务器重启后消失，而 cron 不会自动重新应用它们。请添加一条带有 @reboot 的 cron 记录，在系统启动时运行脚本。这样可以确保服务器在启动后立即应用正确的带宽限制，从而保持稳定的服务器响应时间。

我如何验证带宽限制是否真的生效？

运行 tc -s qdisc ls dev eth0 查看当前激活的规则，再使用 iperf3 测试实际吞吐量，并将结果与你预期的带宽上限进行比较。测试可以帮助你在高负载下更有效地降低服务器响应时间。当队列保持较短时，服务器响应时间也会随之改善。

如果周末的高峰时段和工作日不同怎么办？

你可以为周末单独添加更多 cron 条目。使用不同的行分别指定工作日和周末即可。Cron 支持星期字段，你可以使用 1-5 表示工作日，6-0 表示周末。这样的灵活配置能让服务器在整周内都维持稳定的响应时间。

我可以设置两个以上的时间段吗？

可以。你只需在脚本中添加更多函数，例如用于中午或晚间的不同带宽上限，并在 cron 中加入对应的调度条目。每个函数负责应用一套不同的 tc 规则，服务器会在每个计划时间点自动切换。每次切换后，请继续监控服务器响应时间。