企业官网建设流程全解析

干过网络的人应该都知道，网络卡顿排查到最后的归宿往往不是带宽不够，而是“优先级”没人管。尤其语音、视频会议、关键业务和下载流量混在一起跑的时候，设备对着满队列的数据包往往一脸茫然——到底先转发谁？这时候DSCP标记就派上用场了。它其实就是IP报文头里那6个比特，用来告诉沿途每一台设备：“我这个包是语音，别给我乱丢；那个包是下载，实在不行先丢它。”

这6个比特看似简单，但它在差分服务（DiffServ）模型里是核心中的核心：没有DSCP标记，后面所有关于队列调度、拥塞避免、带宽保障的策略都无从谈起。这篇文章我想完整聊一聊DSCP标记的设计思路、常用码点取值、端到端的配置手法，以及我在实际项目里踩过的那些坑。无论你是刚接触QoS的入门工程师，还是正在做园区网、广域网优化的老手，这篇应该都能帮你少走弯路。

1. DSCP到底在管什么：从IP头里的8个比特说起

1.1 ToS字段的演进与DSCP的由来

IP报文头里有个字节，历史上叫ToS（Type of Service，服务类型）字段，总共8个比特。最早的设计是把前3个比特叫作IP优先级（IP Precedence），从0到7一共8个等级。3个比特只能表达8种“重要程度”，这在早期网络里勉强够用，但随着语音、视频、以及越来越复杂的应用出现，8个等级很快就捉襟见肘了。更麻烦的是，不同厂商对“优先级6”“优先级7”的理解并不一致，有的拿去做路由协议控制面，有的干脆给数据面用，跨厂商组网时经常鸡同鸭讲。

后来RFC 2474对ToS字段做了重新定义：取前6个比特作为DSCP（Differentiated Services Code Point，差分服务代码点），后2个比特留给ECN（显式拥塞通知）使用。6个比特意味着最多可以定义64个码点，从0到63。

这件事的本质变化其实不只是“等级变多了”，而是“含义标准化了”。DSCP不再像IP Precedence那样只是告诉你“这个包很重要”，而是告诉你“这个包对应的转发行为是什么”：是低延迟、低丢包的EF？还是分等级、可丢弃的AF？还是全力而为的BE？路由器看到标记，就知道该往哪个队列里放、丢包时按照什么概率去丢。

1.2 DiffServ模型的核心理念：边界做标记，核心做转发

如果只把DSCP当成“优先级字段”看，那就小看它了。差分服务DiffServ的整个设计哲学是：在网络边缘做复杂的分类和标记，在网络核心只做简单的调度和丢弃。换句话说，接入层设备要学会“察言观色”——识别应用、打标、重写；核心设备就不用想那么多，只看DSCP值，按预定义的PHB（Per-Hop Behavior，逐跳行为）处理。

这套思想可以用快递行业来类比。你寄件的时候，快递网点的人负责验视包裹、称重、贴上“易碎”“加急”“生鲜”之类的面单标签；之后包裹进入分拨中心和干线运输，分拣员不关心里面装的是什么，只看面单标签就知道该把它放进哪个筐、装哪辆车。如果每个分拨中心都要重新拆包验货，整个物流体系早就瘫痪了。DSCP就是网络世界里的那张贴纸，分类的“验货动作”只在网络边界做一次，中间设备高效转发。

这个设计相比更早的IntServ（综合服务）模型优势非常明显：IntServ需要为每一条流在沿途设备上预留状态，核心路由器要为每个会话维护资源信息，在大规模网络上根本撑不住。DiffServ则是让核心设备保持“无状态”，只管按照标记干活，扩展性一下子就好了。

不过这里必须说清楚一件事：DSCP标记本身不等于QoS。完整的QoS链路至少包括分类、标记、队列调度、拥塞避免、限速这五个环节。DSCP只负责“标记”这一环，它做得再好，后面没有队列调度配合、没有丢弃策略兜底，那也只是一张贴纸贴在包裹上，分拨中心不认识或者干脆不执行，照样白搭。理解这一点，后面才不会把方案想得太简单。

2. DSCP的常用标记值：从0到63该怎么选

2.1 一张表快速掌握常用码点

DSCP总共64个码点，实际项目里常用的其实就二十多个。我先把最核心的几类列个表，大家后面查起来也方便：

这张表看着数值很多，其实规律非常清晰：AF类码点由“类别”（1到4）和“丢弃优先级”（1到3）组成，格式就是AFxy。比如AF41，代表第4类、丢弃优先级为1，翻译成人话就是“这一类里最不能丢的”。每类内部，数值越大丢包概率越高，AF13比AF11更容易被丢弃。

2.2 EF为什么偏偏是46

很多初学者都会问：EF直接等于46，这个数字怎么来的，不能随便挑一个吗？当然不是随便挑的。EF的标准定义是RFC 3246，选择46这个码点其实是刻意为之。

46的二进制是101110，它高3位是101，也就是十进制的5。对照老的IP Precedence，5对应的是以前预留的最高用户优先级。之所以要把高3位设计成101，是为了兼容那些只认识旧IP Precedence字段的老设备：即便一台老路由器看不懂DSCP，它也能从高3位看出这流量等级不低，不至于一上来就给丢掉。EF在排队设计上目标非常明确——低延迟、低抖动、低丢包，它对应的就是话音媒体流这类对实时性要求极高的流量。

还有一个细节值得注意：EF没有选择43或者47，而是选了46，目的就是让它和老的控制面优先级CS6（值48）错开。控制面流量，比如BGP、OSPF这类路由协议报文需要在极端拥塞时仍然可达，但它和多媒体数据流的“实时”语义不同。把EF放在46而不是48、56，就是明确地告诉网络设备：用户实时业务不要占用控制面的最高优先级，否则一旦数据面霸占最高队列，出故障时路由协议都被卡住，整个网络就真“叫天天不应”了。

2.3 AF组的三个丢弃等级到底解决什么问题

AF类的设计精妙之处在于，它把“重要性”和“可丢弃性”拆成了两个维度。同样是视频会议业务，主讲人画面、共享屏幕和录制备份的优先级显然不该一样。如果一刀切全部标EF，拥塞时每个包对网络“同等重要”的诉求会让队列瞬间膨胀——收效未必好，还容易造成语音抖动。

用AF组就能做到：给不同子流量打不同丢弃优先级，网络发生拥塞时用WRED（加权随机早期检测）先丢那些低等级的包，保住核心内容。比如视频会议里画面数据标AF41，内容共享标AF42，文件传输/录制流标AF43。拥塞一发生，AF43先被丢弃，AF42次之，AF41能坚持到最后一刻。这样业务的体验是一种“逐渐降级”而不是“瞬间全断”，用户感知会好很多。

AF组还有一个实际好处：WRED对同一类AF的不同丢弃等级可以使用不同的丢包曲线，这让网络在拥塞时具备“弹性”。如果你连这个维度都不设计，路由器面对拥塞时只能一刀切，所有同一类包一起丢，那用户的体感就是会议画面卡成PPT之后直接断线。

2.4 CS类码点的取舍建议

CS类其实就是把旧的IP Precedence左移3位得到的码点，所以CS1到CS7分别对应8、16、24、32、40、48、56。它最大的作用是“兼容”和“控制面”。

我个人的经验是：CS6/CS7最好只用于设备之间的路由协议报文、网管报文这类控制面流量，不要让普通业务报文打CS6/CS7。理由有两点：第一，很多核心设备对CS6/CS7的队列处理策略和控制面保护机制是绑定在一起的，用户流量混进去极有可能触发控制面管制；第二，一旦你把某个数据流标成CS7，在网络拥塞时它会比路由协议还“优先”，万一这个流本身有突发，反而会挤掉关键控制报文。这属于给自己埋雷。

CS1这类低于BE的码点也很有用。我经常把内部的文件备份、日志上报、非关键监控流量统一标CS1，这样在网络拥塞时它们会被优先丢弃，而不是和办公上网流量抢带宽。很多团队在方案设计时只盯着“怎么让重要业务更优”，忽略了“怎么让不重要的业务更低”，其实CS1就是干这个的，别浪费。

3. 端到端DSCP方案设计：信任边界、映射与设备配置

3.1 先定信任边界，再谈标记

做DSCP方案最容易犯的错误就是一上来就配命令。真正动手之前必须先回答一个问题：网络里哪些设备、哪些端口打上来的DSCP值，我们选择相信？

这就是“信任边界”（Trust Boundary）。简单说，设备是否直接采信入向报文的DSCP，还是把所有入向报文一律重写成默认值，再由本地策略重新打标。信任边界如果画得太靠内，比如在整个园区都信任终端的DSCP，那任何一台被攻破或配置错误的PC都能给自己打上EF，拥塞时全网语音队列被垃圾流量塞满。信任边界如果画得太靠外，比如连语音网关发给交换机的话音流量都不信任，那交换机还得通过ACL重新识别语音，配置量巨大不说，识别效率和准确性都受影响。

我目前比较推荐的做法是：接入交换机面向用户PC的端口，一律不信任DSCP，默认把入向流量先改写成默认值0，再通过ACL按应用特征分类、打标；面向IP话机、视频会议终端这类专用设备的端口，可以信任它们自带的标准标记，因为专用设备打的标记一般符合标准，不会乱来；面向服务器接口的流量，要看服务器上有没有跑特殊应用，通常先在服务器侧或接入交换机上按五元组打标。边界问题想清楚，后面配置才有依据。

3.2 典型接入与核心的标记与重写配置

我先描述一个典型的园区网场景：某制造企业园区，出口是1Gbps的专线，内部有语音、视频会议、ERP系统和普通上网。规划如下：语音电话标记EF，视频会议标记AF41，ERP系统标记AF31，内部文件备份标记CS1，其余全部保持默认值BE。

接入交换机上，对面向PC的端口做入方向策略，匹配不同应用特征，改写DSCP。这里我用常见的命令行风格做个示意，具体关键字以自己手头设备手册为准：

# 入方向匹配IP话机地址段并标记EF traffic classifier VOICE if-match acl 3001 // 匹配话机网段 traffic behavior MARK_EF remark dscp ef traffic policy INPUT_POLICY classifier VOICE behavior MARK_EF # 接口下应用，同时关闭信任 interface GigabitEthernet0/0/1 trust dscp disable // 不信任终端标记 traffic-policy INPUT_POLICY inbound

核心设备上，面向出口的物理接口做队列调度策略，根据DSCP把流量映射到不同队列：

class-map match-any EF_QUEUE match ip dscp ef class-map match-any AF41_QUEUE match ip dscp af41 class-map match-any AF31_QUEUE match ip dscp af31 policy-map WAN_OUT class EF_QUEUE priority percent 10 police cir 100000000 // 防止EF队列被滥用 class AF41_QUEUE bandwidth percent 20 class AF31_QUEUE bandwidth percent 30 class class-default bandwidth percent 35 random-detect // 对BE启用WRED

这里有个细节要特别提醒：标签标记通常是在“入方向”做的，因为数据包一进入网络，我们就要决定它享受什么待遇；而队列调度、拥塞管理是在“出方向”做的，因为拥塞总是发生在接口发出的那一刻。这两个方向如果搞反，配置会莫名失效，而且排查起来相当痛苦。

3.3 队列调度和丢弃策略必须跟DSCP配合起来

标记只是“说”这个包重要，队列调度才是“做”。接口拥塞时，设备靠队列决定先送谁、后送谁、丢谁。

通常EF类流量放进优先级队列（PQ），PQ的特点就是：只要队列里有包，就先把它送出去。这保证了语音的低延迟，但PQ是“霸道的优先级”，必须配一个管制器（police）限制EF流量总量，否则语音和伪语音流量会把后面的队列饿死。AF类流量一般放入CBWFQ（基于类的加权公平队列），每个类可以配置保证带宽（bandwidth percent），拥塞时各类按权重分享剩余带宽。实现拥塞避免时，对AF类和BE类启用WRED：AF内部使用三个不同丢弃等级，让AF43比AF41更容易被丢弃；BE则按默认曲线丢弃，让后台大流量成为拥塞时的“牺牲品”。

再放一组我常用的带宽规划参考：在1Gbps出口上，EF预留10%（按实际并发话路计算，一般100路语音需要10Mbps左右，留10%已经很充裕），AF41预留20%，AF31预留30%，CS6/CS7预留5%，剩下的给BE。这里计算的关键不是“数字越大越好”，而是“保证带宽的总和不能超过接口实际带宽”。有些设备对百分比会自动换算，但你自己心里要对每条业务的实际流量模型有数。

还有一点很有意思：调度策略并不是非要在核心设备的出接口上做。如果你的园区出口路由器上同时接了几条链路，必须确认每个出接口都挂了同样的策略，或者至少关键的出接口都挂了。我见过只优化了主链路、备份链路完全裸奔的案例，平时没事，主备切换时语音直接全断。这种“备份链路没策略”的坑，比DSCP本身配置错误更隐蔽。

3.4 不同网络场景下的DSCP映射要点

DSCP不是在所有网络里都能原样透传的，跨二层、跨无线、跨MPLS、跨Overlay隧道时都要处理映射关系。

二层VLAN场景：报文在交换机之间传递时，如果走的是Trunk口，可以去信任802.1p优先级（即VLAN头里的User Priority），也可以按DSCP重新映射。纯二层组网通常建议把信任点设在接入交换机，这样从接入往上走，Trunk里的优先级已经一致，不容易乱。

无线场景：Wi-Fi报文在无线侧用的是WMM（Wi-Fi多媒体）的User Priority，AP收到无线报文时要把UP映射成DSCP；反过来，AP从有线口收到带DSCP的报文，转发到无线侧时也要映射成UP。很多AP默认会把所有非语音流量映射成最低UP，某一天你发现手机上的视频会议画面卡到不行，抓包一看DSCP确实是EF，但AP映射时把它降成了普通数据，那问题就出在这个映射环节。

MPLS场景：MPLS报头里的实验位（EXP，现在叫Traffic Class）用来标记优先级。IP报文进入MPLS网络时，PE设备通常会把DSCP复制到EXP；如果在P（核心）设备上要做队列调度，那就必须看EXP，而不是外层看不到的IP DSCP。这里最常见的问题是对端运营商没有把EXP映射好，导致IP侧和MPLS侧优先级脱节。

Overlay隧道场景：GRE、IPSec、VXLAN这类封装会把原始IP报文包进新IP报文里，外层IP头的DSCP默认是0还是复制内层，完全取决于封装实现。很多默认行为是“不复制”，甚至有些老版本干脆置零。在这种情况下，中间网络只能看到外层IP头，内层DSCP再漂亮也不会被感知。解决办法一般是在隧道接口上开启预分类（pre-classify），或者配置DSCP复制，让外层继承内层标记。这块我后面还会专门讲。

4. DSCP落地中的坑与排查实录

4.1 现象一：抓包看到DSCP全是0，但配置明明标记了

有一次我在一个园区网络里排查视频会议卡顿，终端上抓包看到报文DSCP确实是AF41，可是到了汇聚交换机再抓，DSCP居然变回了0。配置检查了一遍又一遍，标记策略明明生效了，问题在哪儿？

后来逐跳打点才发现，问题出在接入交换机上：从接入到汇聚用了Trunk口，汇聚交换机在这个Trunk口上配置了“不信任入向DSCP”，把收到的所有报文优先级全部重写成默认值。这其实就是一个信任边界设置的问题——接入设备打了标，汇聚设备不相信，又给擦掉了。排查思路其实很简单：从源到目的逐跳抓包，看DSCP在哪一跳消失，然后检查那一跳的端口信任关系和QoS策略方向。很多时候不是你标错了，而是别人在下一跳把你的标记擦了。

4.2 现象二：隧道流量优先级失效

某次做跨地域网络优化，业务通过GRE隧道互联，语音流量在隧道两端都打了EF，但中间链路的拥塞还是影响了语音质量。抓包一看，隧道外层IP头的DSCP是0，内层IP头是46。中间路由器根本不看内层头的DSCP，它只知道外层是一个普通IP包，于是语音和大量数据一起在队列里排队。

这种问题的修复方式要看是哪种隧道。如果是GRE隧道，一般需要在隧道接口上开启预分类，让隧道接口能够看到内层IP头的信息，并把内层DSCP复制到外层；如果是IPSec隧道，涉及加密和封装，通常要配置QoS预分类或者选择保留DSCP的封装参数；如果是VXLAN这类Overlay网络，则要看VTEP设备是否支持把内层DSCP复制到VXLAN/UDP/IP外层。核心原则就一条：中间网络只能看到外层报文头，所以优先级必须体现在外层头里。我前面反复强调这个，因为在实际项目里遇到的频率实在太高了。

4.3 现象三：EF队列反而把网络搞抖了

有些团队喜欢把“重要的流量”统统标成EF，视频标EF，语音标EF，核心交易也标EF。结果就是拥塞时PQ队列被塞满，后面CBWFQ里的关键业务反而得不到服务，网络更抖了。

EF的标准定位就是“带宽小、延迟低、必须优先”的实时业务，典型就是语音RTP流。视频会议带宽需求很大，不分青红皂白全标EF，会让PQ队列带宽消耗很高，反而增大语音抖动风险。正确的做法是：语音媒体流用EF；视频会议根据重要性用AF41/AF42；关键交易用AF31/AF32；网络控制面用CS6。普通流量用BE，后台垃圾流量用CS1。这样一个码点一层用途，真正做到各司其职。EF队列务必配置police，把进入PQ的突发流量限制住，否则任何一次异常突发都能瞬间击穿全网QoS设计。

4.4 现象四：无线环境手机业务优先级丢失

还有一个很常见的坑在无线侧。手机连接Wi-Fi打电话或开会，报文从手机发出时，WMM的UP值一般是根据应用自行设置的，但部分手机厂商的实现并不规范，很多报文到了AP之后UP值全是0。AP把无线流量转成有线流量时，需要根据UP映射成DSCP，如果UP是0，映射出来的DSCP自然是0。此时有线侧再怎么配置EF队列，它也匹配不到这些语音报文，因为它们在源端就已经丢标了。

这类问题的解法通常是在AP或无线控制器上做“重打标”策略：根据报文的应用特征（比如SIP端口号、RTP端口范围、以及目标IP地址段）重新对无线流量分类，匹配语音的报文统一设置DSCP为EF，匹配视频的统一设置AF41。不要指望终端自己会给你打一个完美的标记，无线环境里终端各行其是的概率极高。真要做企业级无线语音，接入侧重写几乎是必经之路。

4.5 常见问题速查表

最后把我在项目中反复遇到的DSCP问题整理成一个速查表，方便大家定位：

5. 关于DSCP项目实施，我的几点个人体会

做这套东西做久了，越来越觉得DSCP的难点从来不在“怎么配命令”，而在于你到底愿不愿意、能不能信任整条链路上的每一个节点。你在这头费尽心思打了EF，中间一台设备随手就给你清零，整个方案就是白做。所以真正靠谱的做法是，在项目规划阶段就把“信任边界”画清楚，并且把每一级设备上的标记、信任、映射、调度策略全部列成一张表，逐台核对。这比装机时现场拍脑袋写ACL可靠得多。

我个人的小心得是：平时做任何网络排障，抓包时先看一眼IP头的DSCP值再往下查，往往会省掉大量时间。很多所谓的“线路质量差”“设备性能不行”，追到根上就是DSCP在某处被改写成0或者被标错类别。养成看标记的习惯以后，你会发现网络拥塞时的表现其实非常“讲理”——它完全按照你贴的标签在做事。贴对了，关键业务哪怕带宽紧张也能稳住；贴错了，再大的带宽也救不了语音的抖动。就这么简单，也这么残酷。