网络服务质量（QoS）全解析：从VLAN优先级到Linux tc的流量管控实战

1. 从一次网络卡顿说起为什么你的流量总被“欺负”上个月公司内部搞了一次视频会议结果好几个同事的画面卡成了PPT语音也断断续续。IT部门排查了一圈发现不是带宽不够也不是服务器问题。最后抓包分析发现是市场部那边在同步一个超大文件把网络带宽给“吃”满了导致视频会议的流量被挤得没路走。这其实就是典型的网络服务质量问题不同的应用、不同的数据流在网络这个“公共马路”上没有“红绿灯”和“专用车道”结果就是“大货车”大流量下载堵死了“救护车”实时音视频的路。要解决这个问题就得靠网络中的“交通管制”技术——服务质量Quality of Service QoS。但QoS不是一个单一的命令或开关它是一套从数据链路层到网络层再到Linux系统层面的完整体系。今天我们就来把这套体系彻底拆开揉碎了讲清楚核心就是四个关键词VLAN优先级、IP优先级、QoS策略、以及Linux下的终极工具tc命令。无论你是网络工程师还是运维开发或者是想优化自家NAS和软路由的极客理解这套组合拳都能让你对网络流量的掌控力提升一个维度。2. VLAN优先级在二层给数据包“贴标签”我们常说网络分七层QoS的“管制”可以从第二层也就是数据链路层就开始。在以太网环境中VLAN虚拟局域网技术除了用来隔离广播域其帧格式里还有一个至关重要的字段——802.1Q标签头中的优先级字段也叫COSClass of Service或PCPPriority Code Point占3个比特。2.1 802.1Q标签与优先级位一个标准的以太网帧在插入802.1Q标签后结构会发生变化。标签头包含TPID标签协议标识固定为0x8100和TCI标签控制信息。TCI里又包含了12位的VLAN ID和3位的PCP。这3位PCP就是VLAN优先级取值范围是0-7。| 目的MAC | 源MAC | 0x8100 (TPID) | PCP(3) | CFI(1) | VID(12) | 类型/长度 | 数据 | FCS |这8个优先级0-7在IEEE 802.1p标准中被大致定义了一套推荐映射0 (Best Effort)默认值尽力而为。1 (Background)后台流量如网络备份。2 (Spare)未分配。3 (Excellent Effort)优秀尽力用于业务量较大的数据。4 (Controlled Load)受控负载用于流媒体。5 (Video, 100ms latency)视频延迟小于100ms。6 (Voice, 10ms latency)语音延迟小于10ms。7 (Network Control)网络控制如生成树协议、OSPF等协议报文。注意这个映射只是推荐并非强制。实际网络中交换机的具体行为取决于其硬件芯片和软件实现。比如有些交换机可能只支持4个或8个硬件队列那么它内部会将0-7这8个优先级映射到有限的几个硬件队列上。2.2 配置与实践在交换机上打标签VLAN优先级的标记通常发生在网络的入口边缘。比如连接IP电话的交换机端口我们会将其信任来自电话的VLAN优先级通常电话会将自己语音RTP流的帧标记为优先级6。配置命令因厂商而异但逻辑相通。以华为交换机VRP系统为例# 进入连接IP电话的接口 interface GigabitEthernet 0/0/1 port link-type hybrid # 或access/trunk根据实际情况 port hybrid pvid vlan 10 # 设置端口默认VLAN port hybrid untagged vlan 10 # 对VLAN 10的帧去掉标签发出给PC trust 8021p inner # 信任并依据接收到的帧的802.1p优先级进行内部调度以思科交换机IOS为例interface GigabitEthernet1/0/1 switchport mode access switchport voice vlan 10 # 为语音数据设置VLAN mls qos trust cos # 信任接口接收到的COS值实操心得配置trust cos或类似命令是关键。如果不信任交换机入口会忽略数据包自带的优先级或者将其重置为默认值通常是0。这意味着你后面所有的QoS策略都失去了依据。所以在规划QoS时第一步就是确定网络的“信任边界”——从哪里开始我们相信数据包自带的优先级标签。3. IP优先级与DSCP在三层细化“通行证”数据包进入三层IP层后VLAN的802.1p标签在路由器间传输时通常会被剥离除非是Q-in-Q等特殊封装。这时就需要依靠IP头部的服务类型字段来传递优先级信息。3.1 ToS字段、IP优先级与DSCP的演进IPv4包头中有一个1字节的“服务类型Type of Service, ToS”字段。历史上这个字段被解释为两部分IP优先级IP Precedence占用高3位意义与802.1p的PCP类似取值0-7常被称为“RFC 791优先级”。延迟、吞吐量、可靠性、成本位占用中间4位每个位表示一种服务诉求D、T、R、C但实际应用很少。这种划分方式太粗犷。于是IETF推出了差分服务Differentiated Services, DiffServ模型重新定义了这8位称为DSCPDifferentiated Services Code Point。DSCP占用ToS字段的高6位0-63低2位保留未用ECN显式拥塞通知。原ToS字段| IP Prec (3 bits) | D | T | R | C | 0 | 0 | DiffServ字段| DSCP (6 bits) | ECN (2 bits) |3.2 常见的DSCP值与PHBDiffServ定义了一系列“每跳行为Per-Hop Behavior, PHB”并用特定的DSCP值表示CSClass Selector为了向后兼容IP优先级DSCP值XXX000即十进制8, 16, 24, 32, 40, 48, 56对应IP优先级0-7。例如CS6 (48) 用于网络控制CS5 (40) 用于语音。EFExpedited Forwarding, 加速转发DSCP值为46二进制101110。这是为低延迟、低抖动、低丢包率的流量设计的如VoIP。路由器会为EF流量提供优先处理和保证的带宽。AFAssured Forwarding, 确保转发定义了4个等级AF1-AF4每个等级内有3个丢弃优先级低、中、高。格式为AAADD0。例如AF11 (DSCP 10): 用于不太重要的保证数据。AF31 (DSCP 26): 用于重要的业务数据。AF43 (DSCP 38): 用于重要业务但在拥塞时丢弃概率最高。AF41 (DSCP 34) 常被用于视频流量。一个实用的对照表应用类型推荐DSCP值十进制二进制含义网络控制 (OSPF, BGP)CS6 (48)110000最高优先级保证路由稳定语音 (VoIP)EF (46)101110加速转发极低延迟交互式视频 (视频会议)AF41 (34)100010确保转发高优先级流媒体视频 (点播)AF31 (26)011010确保转发中高优先级关键业务数据 (CRM, ERP)AF21 (18)010010确保转发中优先级尽力而为数据 (Web, Email)CS0 (0)000000默认无保证清道夫流量 (BT下载)CS1 (8)001000最低优先级带宽空闲时才转发3.3 在路由器/防火墙上标记DSCP标记行为通常由网络边缘设备如出口路由器、防火墙完成基于ACL访问控制列表或NBAR基于网络的应用识别来识别流量并打标。以华为设备VRP为例创建一个流分类匹配视频会议服务器的流量并为其标记DSCP为AF41acl number 3000 rule 5 permit ip source 192.168.10.100 0 # 视频会议服务器 traffic classifier VIDEO operator or if-match acl 3000 traffic behavior MARK-VIDEO remark dscp af41 # 标记DSCP值为AF41 traffic policy QoS-OUTBOUND classifier VIDEO behavior MARK-VIDEO interface GigabitEthernet 0/0/0 # 出方向接口 traffic-policy QoS-OUTBOUND outbound以思科设备IOS为例使用MQC模块化QoS命令行实现类似功能access-list 101 permit ip host 192.168.10.100 any class-map match-all VIDEO-CLASS match access-group 101 policy-map MARKING-POLICY class VIDEO-CLASS set dscp af41 interface GigabitEthernet0/0 service-policy output MARKING-POLICY踩坑记录这里最容易出问题的是标记的位置。一定要在流量离开你的管控域、进入运营商或下一跳网络之前进行标记。如果在内部核心交换机标记而出口路由器没有相应的信任和队列调度机制这个标记就白做了。同时要确保沿途的网络设备都信任DSCP值trust dscp否则它们会重写或忽略你的标记。4. QoS策略模型管制、整形、队列与丢弃打好了标签VLAN PCP或IP DSCP只是告诉了网络“这是什么类型的流量”。接下来我们需要在网络设备主要是路由器和三层交换机上根据这些标签来执行具体的“交通规则”。这就是QoS策略的核心分类、标记、管制、整形、队列、拥塞避免。4.1 流量管制与流量整形这两个概念经常被混淆但它们的方向截然不同。流量管制Policing像一个严厉的交警发现超速超过承诺速率就立刻开罚单丢弃或降级数据包。它不缓存数据对突发流量容忍度低主要用于限制进入网络的流量速率保护网络资源。通常用在网络入口。工具令牌桶算法。桶有固定容量突发尺寸bc以承诺信息速率cir向桶中添加令牌。数据包需要拿到令牌才能通过拿不到就被丢弃或标记为更低优先级。流量整形Shaping像一个智能的匝道控制器当主路拥堵时让车在匝道上排队等候平滑地放入主路。它会缓存超额的数据包以平均速率整形速率发送减少丢包但会增加延迟。主要用于使输出流量符合下游设备的接收能力避免被下游管制丢弃。通常用在网络出口。工具也是令牌桶但多了一个队列缓存区。令牌不足时数据包在队列中等待而不是直接被丢弃。配置示例华为在接口出方向整形interface GigabitEthernet 0/0/1 qos lr outbound cir 10000 # 将出方向流量整形为10Mbps这个命令会平滑该接口的出流量即使有突发对外发送的速率也会被限制在10Mbps左右避免冲击下游设备。4.2 队列调度机制当接口发生拥塞输出队列有数据堆积时决定哪个数据包先被发送的规则就是队列调度。这是影响不同优先级流量体验的关键。FIFO先进先出最简单的队列所有流量一视同仁没有QoS。不适合混合流量环境。PQ优先队列定义多个优先级队列如高、中、普通、低。高优先级队列不为空时绝不发送低优先级队列的数据。这保证了高优先级流量的绝对优先但可能导致低优先级流量“饿死”。CQ定制队列为每个队列分配一个固定的带宽比例如queue1 40%,queue2 30%。按轮询方式从各队列取数据发送取的数据量与其带宽比例相关。保证了带宽分配但不够灵活延迟无法保证。WFQ加权公平队列动态的、基于流的公平队列。它会识别不同的“流”如基于源/目的IP、端口并为每个流分配一个独立的队列。调度时根据流的优先级权重来分配带宽。低带宽的流也能得到及时服务防止大流独占资源。它是早期解决“大象流”欺负“老鼠流”的利器。CBWFQ基于类的加权公平队列这是目前企业网最常用的队列机制。它结合了PQ和WFQ的优点。LLQ低延迟队列这是一个具有严格优先级的队列通常用于承载EF语音流量。只要LLQ有数据设备就会优先发送LLQ的数据发送完后才调度其他队列。为了防止LLQ饿死其他流量需要为LLQ设置一个带宽上限。BANDWIDTH队列其他类别的流量如AF41视频、AF21业务数据被分配到不同的BANDWIDTH队列每个队列被分配一个最小保证带宽bandwidth或占用剩余带宽的比例bandwidth percent。默认队列未分类的流量进入默认队列通常采用WFQ调度。配置示例思科CBWFQLLQclass-map match-any VOICE match dscp ef # 匹配语音流量 class-map match-any VIDEO match dscp af41 af42 # 匹配视频流量 policy-map WAN-OUT class VOICE priority 1000 # LLQ严格优先级保证带宽1Mbps class VIDEO bandwidth 2000 # 保证带宽2Mbps fair-queue # 队列内使用WFQ class class-default fair-queue # 默认流量使用WFQ bandwidth remaining percent 50 # 占用剩余带宽的50% interface Serial0/0/0 service-policy output WAN-OUT这个策略保证了1. 语音流量绝对优先且带宽不超过1M2. 视频流量至少有2M保证带宽3. 默认流量公平分享剩余带宽。4.3 拥塞避免WRED当队列快满时是等到全满后“尾丢弃”所有新来的包还是提前有选择地丢一些包尾丢弃会导致全局同步所有TCP连接同时减速然后同时加速造成网络震荡。WRED加权随机早期检测解决了这个问题。WRED会监控队列长度当长度超过某个最低阈值时开始随机丢弃数据包丢弃概率随队列长度增加而增加。关键是WRED可以根据IP优先级或DSCP值设置不同的丢弃阈值。高优先级的流量如EF的丢弃阈值设得更高意味着更不容易被丢弃。配置思路通常为AF类流量特别是AFx3丢弃优先级高配置WRED而对EFLLQ中的流量和默认尽力而为流量不配置WRED。因为EF流量需要低延迟不能缓存太久尽力而为流量则无所谓。5. Linux tc命令在服务器端实现精细化流量控制前面讲的都是网络设备上的QoS。但在云原生和自建服务的时代我们经常需要在服务器本身比如一台运行着Nginx、数据库的Linux服务器上控制流量防止某个应用吃光带宽影响其他服务。这就需要祭出Linux内核的强大工具——tcTraffic Control。tc命令功能极其强大也相对复杂。它通过操作内核中的QDisc队列规则、Class类和Filter过滤器来实现流量控制。5.1 tc的核心概念与结构想象一下服务器的一个网络接口如eth0的出口流量处理管道QDisc队列规则这是管道的总阀门和调度器。每个接口都有一个根QDisc默认为pfifo_fast一个简单的优先级FIFO队列。我们可以把它替换成更复杂的、支持分类的QDisc如HTB分层令牌桶或CBQ。Class类存在于可分类的QDisc如HTB内部。我们可以创建多个Class每个Class代表一个流量类别如“网页服务”、“数据库同步”、“备份”并为每个Class分配不同的带宽限制。Filter过滤器附着在QDisc或Class上像是一个分类员。它检查每个要通过的数据包基于IP、端口、协议等然后决定将这个包送到哪个Class去排队。最常用的过滤器是u32通过匹配IP头和数据来分类。叶子QDisc每个Class下面还可以挂一个QDisc用于管理该类内部的排队行为比如用sfq随机公平队列来平滑该类下的多个小流。一个典型的HTB结构如下根QDisc (HTB, 总带宽100Mbps) | |-- Class 1:1 (HTB, 保证速率10M, 最大速率20M) [给SSH流量] | -- 叶子QDisc (sfq) | |-- Class 1:2 (HTB, 保证速率30M, 最大速率60M) [给Web流量] | -- 叶子QDisc (sfq) | -- Class 1:3 (HTB, 保证速率10M, 最大速率不限) [默认类] -- 叶子QDisc (sfq)过滤器将去往22端口的流量导向Class 1:1将去往80/443端口的流量导向Class 1:2其余流量导向Class 1:3。5.2 实战使用HTB限制服务器出站流量假设我们有一台服务器eth0出口总带宽100Mbps。我们要保证SSH管理流量端口22至少有2Mbps最高不超过5Mbps。Nginx Web服务流量端口80/443至少有30Mbps最高可以借用空闲带宽到80Mbps。其他流量共享剩余带宽。步骤1清空现有规则谨慎操作tc qdisc del dev eth0 root 2/dev/null # 忽略可能的“No such file or directory”错误步骤2创建根HTB QDisc并设置总带宽tc qdisc add dev eth0 root handle 1: htb default 30handle 1:给这个根QDisc一个标识符1:。htb使用HTB算法。default 30未分类的流量默认发送到1:30这个类。步骤3创建HTB根类总带宽限制tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbitparent 1:父节点是根QDisc1:。classid 1:1创建类ID为1:1。rate 100mbit保证带宽100Mbps等于物理带宽。ceil 100mbit最大带宽100Mbps。步骤4创建子类为不同流量分配带宽# 为SSH流量创建类 1:10 tc class add dev eth0 parent 1:1 classid 1:10 htb rate 2mbit ceil 5mbit burst 15k cburst 15k # 为Web流量创建类 1:20 tc class add dev eth0 parent 1:1 classid 1:20 htb rate 30mbit ceil 80mbit burst 15k cburst 15k # 为默认流量创建类 1:30 tc class add dev eth0 parent 1:1 classid 1:30 htb rate 10mbit ceil 100mbit burst 15k cburst 15kburst和cburst令牌桶的突发尺寸允许短时间内超过rate。通常设置为rate/8左右但不宜过大。步骤5为每个类挂载叶子QDisc进行内部排队tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10sfq随机公平队列防止同一个类下的单个TCP流独占带宽。perturb 10每10秒重置一次哈希算法增强公平性。步骤6创建过滤器将流量分类到对应的类# 将SSH流量目标端口22定向到类 1:10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 22 0xffff flowid 1:10 # 将HTTP/HTTPS流量目标端口80/443定向到类 1:20 tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dport 80 0xffff flowid 1:20 tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dport 443 0xffff flowid 1:20prio过滤器优先级数字越小优先级越高。u32使用u32过滤器进行匹配。match ip dport 22 0xffff匹配IP包中目标端口为220xffff是掩码表示精确匹配16位端口。flowid 1:10匹配到的流量送往类1:10。步骤7验证配置tc -s qdisc show dev eth0 # 查看队列统计 tc -s class show dev eth0 # 查看类统计 tc filter show dev eth0 # 查看过滤器5.3 高级技巧结合iptables的MARK与tc的fw过滤器u32过滤器语法复杂对于更复杂的匹配如连接状态、字符串匹配我们可以借助iptables的MARK功能来打标然后tc用fw过滤器根据标记来分类。这更灵活。# 1. 用iptables给流量打标记 iptables -t mangle -A OUTPUT -p tcp --dport 22 -j MARK --set-mark 10 iptables -t mangle -A OUTPUT -p tcp --dport 80 -j MARK --set-mark 20 iptables -t mangle -A OUTPUT -p tcp --dport 443 -j MARK --set-mark 20 # 2. 在tc中使用fw过滤器根据mark值分类 tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 10 fw flowid 1:10 tc filter add dev eth0 protocol ip parent 1:0 prio 2 handle 20 fw flowid 1:20handle 10 fw表示匹配iptables设置的mark值为10的数据包。踩坑实录tc配置的持久化是个大问题。通过命令行配置的规则重启后会消失。在生产环境你需要将tc和iptables命令写入启动脚本如/etc/rc.local或者使用像systemd服务单元、ifup脚本、或者专门的配置管理工具如ansible来管理。另外tc命令的参数顺序非常严格写错一个地方可能整个规则都不生效而且错误提示往往不清晰排错时最好从最简单的规则开始逐步叠加测试。6. 端到端QoS实战从桌面到服务器的完整流量管控理解了各个组件我们来看一个从源到目的地的完整QoS案例保障一个公司分支机构的语音通话质量。场景分支机构通过一条10Mbps的MPLS专线连接到总部。分支内部有IP电话和办公电脑。设计目标优先保障语音流量G.711编码约80Kbps一路其次保障视频会议流量最后是办公数据。端到端配置思路接入层交换机连接IP电话的端口配置trust cos或trust dscp信任电话标记的优先级。连接PC的端口一般不信任或者根据MAC地址/协议识别出软电话流量并标记。在交换机上配置基于端口的优先级映射例如将语音VLAN的流量映射到高优先级队列。汇聚/核心层三层交换机启用全局QoS。配置DSCP信任trust dscp。配置CBWFQ出方向队列。为EF语音流量创建LLQ保证带宽1Mbps足够10路以上通话为AF41视频流量分配保证带宽3Mbps其余为默认队列。在连接出口路由器的接口上应用出方向策略。出口路由器识别流量使用NBAR或ACL识别语音RTP端口范围、视频会议如H.323, SIP, WebRTC。标记流量如果下游设备信任DSCP则标记语音为EF(46)视频为AF41(34)。如果与运营商采用VLAN优先级映射则可能需要将DSCP映射回VLAN PCP例如EF 46映射到PCP 5或6。流量整形将出方向流量整形为9.5Mbps为控制协议留出空间。队列调度应用与核心层类似的CBWFQLLQ策略。拥塞避免对AF类流量启用WRED。服务器端Linux运行语音/视频服务器使用tc的HTB为语音服务端口如UDP 10000-20000创建高优先级类rate和ceil设置为略高于预估总语音流量并可能使用pfifo或fq_codel作为叶子QDisc以降低延迟。为视频服务端口创建第二优先级类。确保服务器的网卡驱动和内核支持并启用了ethtool的诸如txqueuelen调整、GRO/GSO等优化。验证与监控show policy-map interface思科或display qos policy interface华为查看接口上应用的QoS策略统计信息包括分类匹配的包数、字节数以及队列的丢弃情况。ping与traceroute结合DSCP标记如ping -Q 46 目标测试不同优先级流量的延迟和抖动。Wireshark抓包直接查看数据包中的VLAN PCP和IP DSCP字段是否按预期标记。网络性能测试工具如iperf3可以指定DSCP值-S生成测试流验证带宽分配和优先级效果。个人体会部署QoS不是一劳永逸的。它需要前期的仔细规划流量识别、分类、带宽分配、实施时的精细配置信任边界、标记点、策略应用方向以及后期的持续监控和调整。最忌讳的就是在网络上到处开启QoS却不清楚流量模型那样反而可能引入不必要的复杂性和性能开销。最好的方法是先监控一段时间了解流量基线然后从最关键的业务通常是语音开始小范围实施验证效果后再逐步推广。记住QoS的目标不是让慢的变快而是在拥塞时让重要的业务不受影响。如果链路永远不拥塞QoS就英雄无用武之地。因此增加带宽永远是解决拥塞问题的首选方案QoS是在带宽不足或成本受限时的优化手段。