4.3 应用识别与QoS策略落地

4.3 应用识别与 QoS 策略落地

前两节的纠错与加速是"把链路救回来"，本节是"把流量排好队"——补课工具箱里最贴近业务的一层。承上：3.3 节策略表里的"应用组"从哪里来、每个组凭什么分到带宽，答案都在本节。启下：5.1 节的安全策略同样以应用识别为输入，识别能力是质量与安全两条线的共同地基。读完本节，你应当能独立写出一版可验证的应用识别加 QoS 策略骨架。

策略落地的完整链条

一条"视频会议优先"的策略，从声明到生效要过四道关：识别（边缘设备认出这个流是视频会议）、分类（打上应用组标签）、排队（按标签进对应的优先级队列）、验证（确认策略真的生效了、效果可量化）。传统 WAN 的 QoS 只做了后两道：靠端口和网段粗分类，策略效果无人验证。SD-WAN 的增量在前两道——深度包检测（DPI）认应用、云端应用库持续更新——与最后一道：每条策略的命中与效果都有统计回传。

识别：DPI 认应用，三层防线

第一层是签名匹配：DPI 引擎比对报文特征（协议握手特征、服务器证书域名、指纹库）识别应用，主流厂商的云端应用库覆盖数千种常见应用并持续推送更新。第二层是域名与证书：TLS 加密普及后，流量的目标域名（SNI）与证书信息仍可见，对 SaaS 应用是可靠的识别依据。第三层是行为启发：既认不出签名又无明确域名的流量，按包长分布、连接频率等特征归类，标注置信度，通常只用于观察不用于强策略。三层防线的产出统一进应用库：应用名、所属应用组、置信度。识别不出来的流量去哪，策略里必须显式写明（兜底队列），否则等于给未知流量开了优先级后门。

排队：队列模型与带宽写法

边缘出接口上按应用组排队，标准写法是保底加限顶：每个队列给一个拥塞时的保底带宽占比、一个平常可借用的上限。示例骨架：

# QoS 策略骨架（示意语法，按厂商规范改写）
app-groups:
  - name: "voice-video"          # 语音与会议
    slp: "critical"              # 最高优先级队列
    bandwidth: {guarantee: 20%, max: 40%}
    slp-actions: {fec: adaptive, priority: strict}
  - name: "erp-crm"              # 交易与业务系统
    slp: "high"
    bandwidth: {guarantee: 30%, max: 60%}
  - name: "batch-transfer"       # 备份与同步
    slp: "low"
    bandwidth: {guarantee: 5%,  max: 70%}
    schedule: "22:00-06:00"      # 夜间窗口优先
  - name: "default"              # 兜底：未识别流量
    slp: "normal"
    bandwidth: {guarantee: 10%, max: 100%}
​

配置之外的三条校验规则：所有队列的保底之和不超过 100%（超了配置都下不去）；实时类队列的最大值要封顶（语音占满出口时，低优先级业务全饿死）；兜底队列必须有保底（未识别流量完全无保障会让"识别失败"变成"体验事故"）。

识别与选路的联动写法

4.3 与 3.3 的联动是策略落地的收口：应用组标签既进 QoS 队列表，也进取路策略表。两个表必须用同一套应用组定义，否则会出现"视频会议在队列里是最高优先级、在选路里却没绑定偏好"的半吊子策略。成熟的控制器把应用组做成中心对象，两个策略域共同引用。

验证：策略生效的证据链

策略上线不算完成，验证才算。三个验证动作：一看命中统计——边缘设备报告每个应用组的识别命中数与未知流量占比，未知占比异常升高说明应用库过期或识别失效；二看队列效果——人为制造拥塞（把链路限速到业务总量的七成），确认语音队列时延抖动仍在 SLA 内、批量传输被正确压低；三看端到端体验——业务部门的实测反馈回填，与设备统计互校。三个动作的结论都入库存档，作为第 9 章验收与后续阈值校准的依据。

问题：应用识别错了或漏了，怎么办？

先说识别体系维护的现实：应用库是需要"喂养"的活资产——企业自研系统、小众 SaaS、改名换域名的服务，云端库大概率覆盖不全。成熟的处理机制有三层：自定义签名（管理平面录入自研系统的五元组或域名，纳入对应应用组）；域名兜底（按 SNI/证书域名匹配，覆盖绝大多数 HTTPS 服务的归属）；人工复核闭环（未知流量清单每周导出，IT 确认归属后补录）。一家维护良好的网络，未知流量占比应能压到 5% 以内；如果平台上"未识别"长期超过两成，说明识别体系名存实亡，所有基于应用组的策略都在沙子上。

问题：QoS 在宽带链路上真的有效吗？

有效，但作用点要理解对。QoS 队列只能管自己设备发出方向的排队（出接口排队），管不了运营商骨干里的拥塞。所以它在宽带链路上的效果边界是：出方向拥塞时保护关键流量（上行拥塞——常见于分支上行小的场景——效果显著）；入方向拥塞（下载方向挤爆）则主要靠接收端的策略与运营商的 QoS 标记透传，边缘设备能做的有限。方案设计时据此安排：上行敏感的关键应用（分支上传类）靠 QoS 保真；下行大流量应用（视频流、下载）靠限顶与错峰，不指望队列保护。理解这个边界，能避免"QoS 开了怎么下行还是卡"的经典困惑。

本节要点

• 策略链条四道关：识别、分类、排队、验证，传统 QoS 只有两道，SD-WAN 补齐了识别与验证。
• 识别三层防线：DPI 签名、域名证书、行为启发；未知流量的去处必须显式写进策略。
• 队列写法保底加限顶，三条校验规则：保底和不过百、实时要封顶、兜底不归零。
• 应用组是 QoS 与选路两个策略域的共同对象，定义必须同源。
• 验证三件套：命中统计、限速压测、业务实测，全部留档。

质量补课到此完整：选路、纠错、排队三件套让廉价链路扛起了关键业务。但分流出去的流量不再经过总部安全栈——下一章处理这个安全缺口。