QoS在Linux网络中的核心作用是通过精细化流量管理，确保关键应用在网络拥堵时获得优先带宽和低延迟。它能解决带宽饥饿、缓冲膨胀、关键业务中断等问题，提升用户体验与资源分配公平性。
Linux上的QoS流量控制，简单来说，就是通过精细化管理网络数据包的排队、转发，来确保关键应用或服务在网络拥堵时依然能获得足够的带宽和优先权，避免“劣币驱逐良币”的情况发生。它不是为了凭空增加带宽，而是为了更合理地分配和利用现有带宽资源，确保用户体验和业务连续性。
解决方案
在Linux上实现QoS流量控制，核心工具是tc（traffic control）命令。它的学习曲线确实有点陡峭，但一旦掌握，威力巨大。我们通常会使用分层令牌桶（HTB, Hierarchical Token Bucket）作为主要的排队规则（qdisc），因为它能很好地实现带宽分配和优先级管理。
下面是一个相对基础的配置流程，旨在为SSH流量提供更高的优先级和保障，同时限制HTTP流量：
首先，清除可能存在的旧规则，确保从一个干净的状态开始：
sudo tc qdisc del dev eth0 root
这步很重要，有时候旧的规则会干扰新的配置。
接着，在你的网络接口（例如eth0）上添加一个HTB根排队规则。default 10表示所有未被明确分类的流量都会进入classid为1:10的默认类别。
sudo tc qdisc add dev eth0 root handle 1: htb default 10
然后，创建主类别（parent class），它代表了接口的总带宽能力。这里假设你的出口带宽是100Mbps。rate是保证带宽，ceil是最大可突发带宽。
sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit
现在，我们为不同类型的流量创建子类别。为高优先级流量（比如SSH）创建一个类别，给予它较高的保证带宽和优先级。prio 0代表最高优先级。
sudo tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50mbit ceil 80mbit prio 0
这里我给了50Mbps的保证，最高可以跑到80Mbps，优先级最高。
为低优先级流量（比如HTTP）创建一个类别，给予它较低的保证带宽。
sudo tc class add dev eth0 parent 1:1 classid 1:20 htb rate 20mbit ceil 30mbit prio 1
这个类别保证20Mbps，最高30Mbps，优先级稍低。
最后，为默认流量（未匹配任何规则的流量）也创建一个类别。注意，这个1:10与根qdisc中default 10的classid对应。
sudo tc class add dev eth0 parent 1:1 classid 1:30 htb rate 10mbit ceil 20mbit prio 2
这里我故意把默认流量的优先级放低，这样未被分类的流量就不会抢占关键服务的资源。
现在，我们需要定义过滤规则，将特定的流量导向到对应的类别。将SSH流量（目标端口22）导向到高优先级类别1:10。prio 1是过滤器本身的优先级，与HTB类别的prio含义不同，这里用来决定哪个过滤器先被匹配。
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 22 0xffff flowid 1:10
parent 1:0表示这个过滤器作用于根qdisc，它会决定流量进入哪个子类别。
将HTTP流量（目标端口80）导向到低优先级类别1:20。
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dport 80 0xffff flowid 1:20
这个配置提供了一个基本框架，你可以根据实际需求调整带宽、优先级，并添加更多基于源/目的IP、端口、协议等条件的过滤器。记得，tc的配置是临时的，重启后会丢失，需要将其加入启动脚本（如/etc/rc.local或systemd service）来持久化。
QoS在Linux网络中的核心作用是什么，它能解决哪些实际问题？
QoS在Linux网络中的核心作用，说白了，就是让你对网络流量拥有“指挥棒”的能力。它不是魔法，不能无中生有地创造带宽，但它能让你在有限的带宽资源下，最大限度地保障那些对你来说最重要的网络活动。
具体来说，它能解决一系列令人头疼的实际问题：
避免“带宽饥饿”： 想象一下，你正在进行一个重要的视频会议，突然有人开始下载大文件。没有QoS，你的视频流很可能卡顿、延迟，因为下载流量把带宽都占满了。有了QoS，你可以给视频会议流量更高的优先级和更稳定的带宽保障，即使在网络拥堵时，也能保持流畅。消除“缓冲膨胀”（Bufferbloat）： 这是现代网络设备的一个常见问题。路由器和交换机内置了大量缓存，当网络拥堵时，数据包会堆积在这些缓存里，导致延迟急剧增加，即使是少量数据包（比如游戏或VoIP）也会受到影响。QoS，特别是结合像FQ_Codel这样的排队规则，能够主动管理队列长度，减少不必要的缓冲，从而显著降低延迟。保障关键业务连续性： 在服务器环境中，数据库同步、SSH管理、内部API调用等，这些流量虽然可能不大，但其稳定性和低延迟至关重要。通过QoS，你可以确保这些“生命线”级别的流量，无论服务器负载多高，都能优先被处理，避免因网络拥堵导致业务中断或管理失控。优化用户体验： 对于面向用户的服务，比如流媒体、在线游戏，QoS能够确保用户获得更低的延迟和更少的卡顿，直接提升满意度。公平性与资源分配： 在多用户或多服务共享一个网络连接的场景下，QoS可以实现更公平的带宽分配，或者按照预设策略进行倾斜。比如，你可以限制某个不那么重要的服务或某个用户的最大下载速度，以防止它独占带宽。
总而言之，QoS就是让你从被动接受网络状况，转变为主动管理和优化网络资源，让网络真正为你的需求服务。
配置QoS时，选择哪种流量整形算法最适合我的场景？
选择合适的流量整形（qdisc）算法，就像选择合适的工具一样，没有“万能药”，只有“最适合”。这取决于你的具体需求：是需要严格的带宽保证、简单的速率限制、还是更注重公平性或低延迟？
我来大致梳理几种常见的QoS算法及其适用场景：
HTB (Hierarchical Token Bucket)：
特点： 这是我个人最常用也最推荐的。HTB是一个分层排队规则，它允许你创建复杂的带宽分配树结构。你可以为不同的流量类别设置保证带宽（rate）和最大突发带宽（ceil），并且可以嵌套类别。它还支持优先级（prio）。适用场景： 几乎所有需要复杂带宽管理和优先级划分的场景。比如，你需要为Web服务器、数据库服务器、SSH管理分别分配不同级别的带宽和优先级；或者在一个共享网络中，为不同部门或用户组设定不同的流量限制和保障。它的灵活性和可扩展性非常强。如果你需要精细控制，HTB是首选。
TBF (Token Bucket Filter)：
特点： TBF是一个简单的令牌桶过滤器，主要用于对单个流量流进行速率限制。它通过一个“桶”来存储“令牌”，每个数据包的发送都需要消耗令牌。如果桶里没有足够的令牌，数据包就会被延迟或丢弃。适用场景： 最简单的速率限制。比如，你只想限制某个特定IP地址的最大上传速度，或者限制某个应用的最大带宽。它不具备HTB那样的分层能力，更适合点对点的简单限速。
SFQ (Stochastic Fair Queueing)：
特点： SFQ旨在实现公平性。它通过哈希算法将不同的流量流（基于源/目的IP、端口等）分配到不同的内部队列中，并轮流为这些队列服务。这样可以防止单个“流氓”流占用所有带宽。适用场景： 当你希望所有独立的网络连接都能获得相对公平的带宽份额时。SFQ通常作为HTB或TBF的叶子qdisc（leaf qdisc）使用，也就是说，在HTB分配完大类带宽后，每个大类内部的流量再通过SFQ进行公平调度。它能有效解决单个大流量下载任务“饿死”其他小流量的问题。
FQ_Codel (Fair Queueing with Controlled Delay)：
特点： FQ_Codel是一个相对现代的、非常有效的算法，旨在解决“缓冲膨胀”问题。它结合了公平排队（FQ）和受控延迟（Codel）的优点。它能智能地识别和丢弃那些导致高延迟的数据包，同时保持公平性。适用场景： 几乎是所有通用场景的优秀选择，尤其是对延迟敏感的应用，如VoIP、在线游戏。如果你不确定从哪里开始，或者只是想改善整体网络响应速度和公平性，FQ_Codel通常是一个很好的默认选择，可以直接作为根qdisc使用，或者作为HTB的叶子qdisc。它比SFQ更先进，对CPU占用也更优化。
我的建议是：
复杂分级管理： 如果你需要为不同服务、不同用户、不同协议设定严格的带宽保证和优先级，那么HTB是你的不二之选。简单限速： 如果仅仅是限制某个单一流量的速率，TBF足够了。改善公平性和低延迟（通用）： 如果你主要关注整体网络体验的公平性和降低延迟，FQ_Codel是一个非常优秀的通用解决方案，通常可以作为根qdisc。HTB与叶子qdisc结合： 在HTB的每个子类别下，你还可以再添加一个叶子qdisc，比如SFQ或FQ_Codel，这样可以在大类带宽分配的基础上，进一步实现类内流量的公平性或低延迟优化。这是非常常见的组合，能发挥出HTB的最大潜力。
最终的选择，往往需要根据你网络的具体流量模式、设备性能以及你最看重的网络指标（吞吐量、延迟、抖动）来决定。
如何在生产环境中监控和调试Linux QoS配置？
在生产环境配置QoS，最怕的就是“一配就废”或者“配了没用”。有效的监控和调试手段是确保QoS配置按预期工作，并能及时发现和解决问题的关键。这不仅仅是看一眼tc -s qdisc show那么简单，它需要一些系统性的方法。
查看tc统计信息：
sudo tc -s qdisc show dev eth0: 这是最直接的方式，它会显示指定接口上所有排队规则的统计信息，包括发送的字节数、数据包数、丢弃的数据包数、过载（overlimits）情况等。通过观察dropped和overlimits，可以初步判断是否有流量被限制或丢弃。sudo tc -s class show dev eth0: 查看各个类别的详细统计，包括每个类别发送的流量、排队的数据包、以及最重要的dropped（丢弃）和overlimits（超出限制）计数。如果某个类别的dropped很高，说明该类别的流量被严重限制了。
系统级网络统计：
ip -s link show dev eth0: 这会显示网卡层面的发送/接收数据包和字节数，以及错误和丢弃计数。虽然不如tc细致，但可以用来对比总流量和QoS报告的流量。netstat -s: 提供各种协议（TCP, UDP, IP等）的统计信息，有助于了解整体网络健康状况。
实时流量监控工具：
iftop或nload: 这些工具可以实时显示接口的流量使用情况，包括每个连接的带宽占用。结合QoS配置，你可以观察高优先级流量是否真的获得了预期的带宽，低优先级流量是否被限制。bmon或vnstat: 提供更长时间范围的流量统计和图表，有助于分析流量趋势和QoS效果。
测试工具：
iperf3: 这是测试网络吞吐量和延迟的利器。你可以通过运行多个iperf3客户端，模拟高优先级和低优先级流量，然后观察QoS是否按预期进行整形和优先级分配。例如，同时运行一个高优先级的SSH端口流量（通过iperf3 -p 22模拟）和一个低优先级的HTTP端口流量，看它们各自能达到的带宽。ping和mtr: 用于测试网络延迟和丢包率。在有QoS和无QoS的情况下对比，尤其是在网络拥堵时，看看QoS是否有效地降低了高优先级流量的延迟。
调试思路：
从简单到复杂： 刚开始调试时，不要一下子配置复杂的HTB树。可以先从一个简单的TBF或FQ_Codel开始，确认基本功能。检查过滤器： 最常见的错误是流量没有被正确地匹配到对应的类别。使用tc filter show dev eth0检查你的过滤器规则是否正确，以及流量是否确实命中了你预期的flowid。如果流量总是进入default类别，那说明你的过滤器有问题。逐步调整带宽和优先级： 不要一次性设定过于激进的rate和ceil。从小流量开始测试，逐步增加负载，观察tc -s class show的统计数据，特别是overlimits和dropped。日志记录： 对于一些复杂的QoS规则，可以考虑结合iptables的LOG功能，将匹配特定QoS规则的流量记录下来，以便分析。模拟拥堵： 在测试环境中，你可以使用netem qdisc来模拟网络延迟、丢包或带宽限制，从而更真实地测试你的QoS配置在恶劣网络条件下的表现。
调试QoS是一个迭代的过程，需要耐心和细致的观察。没有一劳永逸的配置，只有持续的监控、调整和优化。
以上就是Linux如何配置QoS流量控制的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/197349.html
微信扫一扫 
支付宝扫一扫 
