如何配置Linux网络QoS 流量优先级标记方案

在linux系统上配置网络qos流量优先级标记方案，需先使用iptables对数据包进行分类和标记，再通过tc工具实现流量调度。1. 使用iptables的mangle表设置dscp值对流量进行标记，如将ssh、voip标记为ef，网页流量标记为af21，p2p流量标记为cs1或be；2. 在网络接口上配置tc规则，采用htb队列策略创建带宽层级结构，并结合fq_codel等算法实现低延迟与公平调度，通过filter将不同dscp值映射到对应的流量类，确保高优先级流量获得优先处理。

在Linux系统上配置网络QoS（服务质量）流量优先级标记方案，核心在于利用netfilter（通常通过iptables或nftables）对数据包进行分类和标记，然后结合tc（traffic control）工具根据这些标记来调度和管理流量。这并不是一个简单的“一劳永逸”的设置，它需要你对网络流量的理解以及对Linux内核网络栈的深入认识。说实话，每次我需要动这块儿的时候，都得翻翻手册，因为细节太多，而且很容易搞错。但一旦配置得当，那种网络体验的提升是实实在在的，尤其是在带宽有限或者对延迟敏感的场景下。

解决方案

配置Linux网络QoS流量优先级标记方案，大致可以分为两个主要步骤：标记和调度。

1. 数据包标记 (Marking Packets)

我们通常使用iptables的mangle表来给数据包打上标记。这些标记可以是内部的netfilter mark（MARK），也可以是Differentiated Services Code Point（DSCP）值，后者更常用于跨设备（如路由器、交换机）的QoS策略。

假设我们想优先处理SSH（端口22）和VoIP（比如SIP端口5060和RTP端口10000-20000）流量。

• 标记SSH流量为EF (Expedited Forwarding)：

  # 允许所有出站流量通过
  iptables -A FORWARD -j ACCEPT
  iptables -A INPUT -j ACCEPT
  iptables -A OUTPUT -j ACCEPT
  
  # 将SSH流量标记为DSCP EF (Expedited Forwarding)
  # EF通常用于低延迟、高优先级的应用，如VoIP
  iptables -t mangle -A PREROUTING -p tcp --dport 22 -j DSCP --set-dscp-class EF
  iptables -t mangle -A PREROUTING -p tcp --sport 22 -j DSCP --set-dscp-class EF

  这里我用了PREROUTING链，因为它发生在路由决策之前，这样即使数据包被转发，标记也能生效。当然，你也可以根据实际情况选择INPUT、OUTPUT或FORWARD链。

• 标记VoIP流量为EF：

  # SIP信令
  iptables -t mangle -A PREROUTING -p udp --dport 5060 -j DSCP --set-dscp-class EF
  iptables -t mangle -A PREROUTING -p udp --sport 5060 -j DSCP --set-dscp-class EF
  
  # RTP媒体流 (通常是UDP范围)
  iptables -t mangle -A PREROUTING -p udp --dport 10000:20000 -j DSCP --set-dscp-class EF
  iptables -t mangle -A PREROUTING -p udp --sport 10000:20000 -j DSCP --set-dscp-class EF

• 标记普通网页流量为AF21 (Assured Forwarding Class 2, Low Drop Precedence)： AF类通常用于对延迟有一定要求但不如EF严格的流量，比如一些企业应用。

  iptables -t mangle -A PREROUTING -p tcp --dport 80 -j DSCP --set-dscp-class AF21
  iptables -t mangle -A PREROUTING -p tcp --sport 80 -j DSCP --set-dscp-class AF21
  iptables -t mangle -A PREROUTING -p tcp --dport 443 -j DSCP --set-dscp-class AF21
  iptables -t mangle -A PREROUTING -p tcp --sport 443 -j DSCP --set-dscp-class AF21

• 标记大文件下载（比如P2P或BT）为BE (Best Effort) 或更低： 如果你的网络上有大量P2P流量，你可以考虑将其降级，以避免影响其他关键应用。默认情况下，未标记的流量就是BE。

  # 假设P2P流量使用特定端口，或者你可以通过L7协议匹配
  # 这里只是一个示例，实际应用中可能需要更复杂的匹配规则
  # iptables -t mangle -A PREROUTING -p tcp --dport 6881:6889 -j DSCP --set-dscp-class CS1
  # CS1 (Class Selector 1) 是最低优先级，通常用于背景或尽力而为的流量

2. 流量调度 (Scheduling Traffic with tc)

标记好数据包后，我们需要在网络接口上配置tc规则，让它根据这些DSCP值来调度流量。这里我倾向于使用HTB (Hierarchical Token Bucket) 队列规则，因为它提供了很好的分层和限速能力。

假设我们要在eth0接口上进行QoS配置：

# 清除eth0上已有的tc规则，每次重新配置前都建议这么做
tc qdisc del dev eth0 root 2>/dev/null

# 在eth0上创建根队列，使用HTB
# default 10 表示未匹配任何分类规则的流量将进入1:10类
tc qdisc add dev eth0 root handle 1: htb default 10

# 创建主类，定义总带宽上限 (rate)
# 例如，总带宽是100Mbps
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit

# 为DSCP EF流量创建子类 (例如1:100)，赋予高优先级
# rate是保证带宽，ceil是最大可用带宽
tc class add dev eth0 parent 1:1 classid 1:100 htb rate 50mbit ceil 100mbit prio 1
# 将EF流量的队列策略设置为fq_codel，它能有效减少缓冲区膨胀和延迟
tc qdisc add dev eth0 parent 1:100 fq_codel

# 为DSCP AF21流量创建子类 (例如1:200)，赋予中等优先级
tc class add dev eth0 parent 1:1 classid 1:200 htb rate 30mbit ceil 80mbit prio 2
tc qdisc add dev eth0 parent 1:200 fq_codel

# 为默认（未标记或BE）流量创建子类 (1:10)，赋予低优先级
# 这是tc qdisc add dev eth0 root handle 1: htb default 10中定义的默认类
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 20mbit ceil 50mbit prio 3
tc qdisc add dev eth0 parent 1:10 fq_codel

# 将DSCP值映射到HTB类
# 0x2e 是EF的DSCP值 (十进制46)
tc filter add dev eth0 parent 1: protocol ip prio 100 u32 \
    match ip dscp 0x2e 0xff flowid 1:100

# 0x22 是AF21的DSCP值 (十进制34)
tc filter add dev eth0 parent 1: protocol ip prio 200 u32 \
    match ip dscp 0x22 0xff flowid 1:200

# 任何未匹配的DSCP流量（包括BE）将流向默认类1:10

这套配置会优先保障EF流量的带宽和低延迟，其次是AF21，最后是默认流量。在带宽不足时，低优先级的流量会首先被限制或丢弃。

千问APP

阿里最强大模型官方AI助手

下载

为什么我们需要在Linux上进行流量优先级标记？

你有没有过这样的经历：正在进行一个重要的视频会议，突然家里有人开始下载一个巨大的文件，然后你的视频就开始卡顿、声音断断续续？或者，你正在玩一个对延迟极其敏感的在线游戏，结果后台的系统更新开始下载，你的Ping值瞬间飙升？嗯，没错，这些都是缺乏流量优先级管理的典型症状。

在Linux系统上进行流量优先级标记，根本原因在于我们希望在有限的网络带宽资源上，实现“好钢用在刀刃上”。不是所有的数据包都生而平等，有些流量对延迟非常敏感（比如VoIP、在线游戏），有些则需要稳定的带宽（比如视频流），而有些则只是“尽力而为”的背景流量（比如大文件下载、系统更新）。如果不加区分地对待所有流量，当网络拥堵时，所有流量都会受到影响，导致关键应用的用户体验直线下降。通过标记，我们就能告诉路由器和交换机：“嘿，这个数据包很重要，请优先处理它！”或者“这个数据包不那么紧急，可以等等。”这就像在高速公路上设置了紧急车道，确保救护车、消防车等关键车辆能够优先通行，而不是和普通车辆挤作一团。这种精细化管理，对于提升网络效率和用户满意度至关重要，尤其是在服务器、网关或家用路由器等场景下。

DSCP标记在Linux QoS中扮演什么角色？

DSCP（Differentiated Services Code Point），直译过来就是“区分服务代码点”，它在IP数据包的IP头中占据6个比特位。这6个比特位可不是随便摆设的，它们能够表示64种不同的值，每种值都代表着一种特定的服务类别。你可以把它想象成数据包的“身份证”，上面写着这个数据包的“重要程度”和“服务要求”。

在Linux QoS的语境下，DSCP扮演着分类器和协调者的关键角色。

1. 分类器： iptables（或nftables）作为第一道关卡，根据我们定义的规则（比如源/目的IP、端口、协议等），识别出特定类型的流量，然后利用DSCP模块将对应的DSCP值写入数据包的IP头。例如，将VoIP流量标记为EF（Expedited Forwarding），将普通网页流量标记为AF21（Assured Forwarding Class 2, Low Drop Precedence），将P2P流量标记为CS1（Class Selector 1）。这个标记动作，就是给数据包贴上“优先级标签”。

2. 协调者： DSCP的强大之处在于它的“可传递性”。一旦数据包被标记了DSCP值，这个标记会随着数据包在网络中传输，被沿途支持QoS的路由器、交换机等网络设备识别。这些设备会根据预设的QoS策略，优先处理带有高DSCP值的流量，或者对带有低DSCP值的流量进行限速、甚至丢弃。这意味着，你不仅仅是在你自己的Linux机器上实现了QoS，而是将你的优先级策略“告知”了整个网络路径。这对于构建端到端的QoS至关重要，尤其是在企业网络或ISP网络中。没有DSCP，你的Linux机器可能只是在本地做做样子，流量一离开你的网卡，就又回到了“尽力而为”的混沌状态。所以，DSCP是实现跨设备、跨网络QoS策略的基石。

如何选择合适的QoS队列策略？

选择合适的QoS队列策略，就像为不同的交通路口选择不同的红绿灯控制方案，没有一劳永逸的万能解药。它取决于你的具体需求、网络环境以及你希望达到的效果。在Linux的tc中，有多种队列规则（qdisc）可供选择，每种都有其独特的优势和适用场景。

1. HTB (Hierarchical Token Bucket)：

   • 适用场景： 这是我个人最常用也最推荐的策略，尤其适用于需要进行复杂带宽管理和多层级流量分配的场景。比如，你有一个服务器，既要跑Web服务，又要跑数据库，还要提供SSH访问，同时可能还有一些后台同步任务。你希望Web和数据库有保障带宽，SSH有高优先级，而后台任务则在空闲时才占用带宽。
   • 特点： HTB允许你创建分层的流量类别，每个类别都可以独立设置保证带宽（rate）和最大可用带宽（ceil）。它能够有效地实现带宽的借用和归还，即低优先级的流量可以在高优先级流量不饱和时借用其闲置带宽，而一旦高优先级流量有需求，借用的带宽就会被收回。它非常灵活，能够应对多种复杂的QoS需求。
   • 考虑点： 配置相对复杂，需要仔细规划带宽分配和层级结构。

2. FQ_Codel (Fair Queueing with Controlled Delay)：

   • 适用场景： 对于希望减少网络延迟、消除缓冲区膨胀（bufferbloat）并提供公平队列的场景，FQ_Codel是一个极佳的选择。它特别适合于混合流量环境，例如家庭网络中的游戏、视频、下载同时进行。
   • 特点： FQ_Codel结合了公平队列（确保每个流都能获得一部分带宽）和Codel算法（主动管理队列长度，防止延迟累积）。它不需要手动配置优先级或带宽，而是通过智能算法自动实现公平和低延迟。
   • 考虑点： 它更多地侧重于公平性和低延迟，而不是严格的带宽保障或优先级抢占。如果你需要对特定流量设置硬性的带宽上限或下限，可能需要结合HTB或其他策略。我常常将FQ_Codel作为HTB子类下的叶子队列，这样既能分层限速，又能保证每个流的公平和低延迟。

3. SFQ (Stochastic Fair Queueing)：

   • 适用场景： 简单的公平队列需求，特别是在希望避免单个流量流霸占所有带宽的情况下。
   • 特点： SFQ通过哈希算法将不同的流量流分配到不同的子队列中，并轮询这些子队列，从而实现流量的公平分配。它的配置比HTB简单得多。
   • 考虑点： 它只提供公平性，不提供优先级或带宽保障。在流量类型差异大、需要严格区分优先级的场景下，SFQ可能不够用。

4. Prio (Priority)：

   • 适用场景： 简单的优先级划分，将流量分成几个优先级队列，高优先级队列清空后才处理低优先级队列。
   • 特点： 配置简单直观，直接根据优先级处理。
   • 考虑点： 可能会导致低优先级流量饿死（starvation），尤其是在高优先级流量持续不断的情况下。它没有带宽管理能力，只是纯粹的优先级。

在实际操作中，我通常会采用一种混合策略：使用HTB作为主要的流量整形和带宽管理骨架，然后在其叶子节点（即每个流量类别对应的子队列）上挂载FQ_Codel。这样既能利用HTB的层级管理和带宽分配能力，又能借助FQ_Codel的智能队列管理来保持低延迟和公平性。选择哪种，最终还是得看你对网络流量的理解，以及你到底想解决什么问题。有时候，试错和观察效果也是必不可少的一步。