应用 QoS

通过 AppQoS,您可以识别和控制对特定应用的访问,并提供状态防火墙规则库的粒度,以匹配并实施应用层的服务质量 (QoS)。有关更多信息,请参阅以下主题:

了解应用服务质量 (AppQoS)

应用 服务质量 (AppQoS) 功能扩展了 Junos OS 服务等级 (CoS) 的功能,包括根据第 7 层应用类型标记 DSCP 值,通过丢包优先级设置遵守基于应用的流量,以及根据第 7 层应用类型控制出口 PIC 上的传输速率。

在安全设备上标记 DSCP 值有四种方法:

  • 基于 IDP 攻击操作的 DSCP 重写器

  • 第 7 层基于应用程序的 DSCP 重写器

  • 基于 ALG 的 DSCP 重写器

  • 基于防火墙过滤器的 DSCP 重写器

根据 IDP 规则在入口端口进行 IDP 重新标记。根据应用规则在出口进行应用重新标记。基于接口的重新标记也会根据防火墙过滤器规则在出口端口进行。(有关 Junos OS CoS 功能的详细说明,请参阅 服务等级用户指南(安全性设备) 。)

这三个重写器的标记决定可能不同。如果数据包触发了所有三个触发器,则优先处理的方法取决于对数据包内容的深入进行匹配。IDP 重新标记优先于应用程序重新标记,后者优先于基于接口的重新标记。

如果数据包同时触发 AppQoS 和基于 ALG 的 DSCP 重写器,则 AppQoS 优先于基于 ALG 的 DSCP 重写器。

AppQoS DSCP 重写器通过转发类和丢失优先级来传达数据包的服务质量。AppQoS 速率限制参数控制其关联队列的传输速度和传输量。

应用 QoS 的优势

AppQoS 提供了对应用流量进行优先级排序和计量的能力,从而为关键业务或高优先级应用流量提供更好的服务。

独特的转发类和队列分配

转发类提供三个功能:

  • 对具有相似特征的数据包进行分组

  • 分配输出队列

  • 解决与现有 Junos OS 防火墙基于过滤器的重写器的冲突

唯一的转发类名称可防止 AppQoS 标记被基于接口的 重写规则覆盖。如果数据包的转发类与专门为此重写器定义的类匹配,则基于防火墙过滤器的重写器会标记数据包的 DSCP 值。如果数据包的转发类与任何基于防火墙过滤器的重写器的类都不匹配,则不会标记 DSCP 值。因此,为了防止 AppQoS 值被覆盖,请使用防火墙基于过滤器的重写器不知道的转发类名称。

每个转发类都被分配给一个出口队列,该队列提供适当程度的增强或标准处理。可以将许多转发类分配给单个队列。因此,为设备定义的任何队列都可以由 IDP、AppQoS 和基于防火墙过滤器的重写器使用。区分传输优先级的是转发类名称,而不是队列。(有关配置队列和调度程序的信息,请参阅 服务等级用户指南(安全性设备) 。)

应用感知 DSCP 代码点和丢失优先级设置

对于 AppQoS,流量会根据将定义的转发类与所选应用相关联的规则进行分组。规则的匹配标准包括一个或多个应用程序。当来自匹配应用的流量遇到规则时,规则操作会设置转发类,并将 DSCP 值和丢失优先级标记为适合应用的值。

差异服务 (DiffServ) 代码点 (DSCP) 值在规则中由 6 位位图值或用户定义或默认别名指定。 表 1 提供了 Junos OS 默认 DSCP 别名和位图值的列表。

表 1:标准 CoS 混叠和位值

别名

位值

EF

101110

AF11

001010

AF12

001100

AF13

001110

AF21

010010

AF22

010100

AF23

010110

AF31

011010

AF32

011100

AF33

011110

AF41

100010

AF42

100100

AF43

100110

是

000000

CS1

001000

CS2

010000

CS3

011000

CS4

100000

CS5

101000

NC1/CS6

110000

NC2/CS7

111000

有关详细信息,请参阅 默认 CoS 值和别名 。

队列的调度程序使用丢失优先级,通过将丢弃配置文件与特定的丢失优先级值相关联,来控制拥塞期间的数据包丢弃。(有关配置队列和调度程序的信息,请参阅 服务等级用户指南(安全性设备) 。)

该规则将丢失优先级应用于流量组。高丢失优先级意味着数据包在拥塞期间被丢弃的可能性很高。有四个级别的丢失优先级可用:

  • high

  • medium-high

  • medium-low

  • low

规则集在配置命令中 class-of-service application-traffic-control 定义:

速率限制器和配置文件

当发生拥塞时,AppQoS 会在设备上的所有出口 PIC 上实施速率限制。如果数据包超过分配的限制,它们就会被丢弃。 速率限制器 可针对不同类别的流量保持一致的吞吐量级别和丢包灵敏度。所有出口 PIC 都采用相同的速率限制方案。

PIC 的总带宽约为 10 Gbps。 PIC 的速率限制器硬件最多可配置 2 Gbps。因此,速率限制的带宽上限为 231 bps。

速率限制器配置文件定义了限制。它是规格和burst-size-limit规格的bandwidth-limit独特组合。定义bandwidth-limit每秒可遍历端口的最大千比特数。定义burst-size-limit在单个突发中可以遍历端口的最大字节数。burst-size-limit通过确保每个突发的大小有限,减少低优先级流量的枯竭。

AppQoS 允许每台设备多达 16 个配置文件和多达 1000 个速率限制器。多个速率限制器可以使用相同的配置文件。在以下示例中,使用两个配置文件定义了五个速率限制器:

速率限制器名称

公司简介

带宽限制

突发大小限制

限制器-1

200

26000

限制器 2

200

26000

限制器-3

200

26000

限制器-4

400

52000

限制器 5

400

52000

速率限制器通过配置命令定义 class-of-service application-traffic-control 。

速率限制器分配

速率限制器根据流量的应用应用于规则中。每个会话应用两个速率限制器: client-to-server 和 server-to-client。这种使用允许单独调配每个方向的流量。

无论流量方向如何,速率限制器都会在数据包级别进行流量带宽处理。例如:假设您只配置了一个 10G 速率限制器,如果入口和出口流量来自同一线卡,则吞吐量(入口和出口方向的最大流量总和)最高只能达到 10G,而不能达到 20G。但是,如果设备支持 IOC(I/O 卡 (IOC)),并且入口流量通过一个 IOC,出口流量通过其他 IOC,则在配置单个 10G 速率限制器的情况下,预计吞吐量为 20G。

同一规则集中的不同 AppQoS 规则可以共享速率限制器。在这种情况下,这些规则的应用程序共享相同的带宽。一个规则集中可分配相同速率限制器的规则数量没有限制。

以下示例显示如何分配上一节中定义的速率限制器。例如,一个规则集可以在多个规则中以及一个或两个流向中重用速率限制器:

  • 规则集-1

    • 规则 1A

      • 客户端到服务器限制器-1

      • 服务器到客户端限制器-1

    • 规则 1B

      • 客户端到服务器限制器-1

      • 服务器到客户端限制器-1

如果在多个规则集中需要相同的配置文件,则需要定义足够数量的速率限制器,指定相同的 bandwidth-limit 和 burst-size-limit。以下示例中的两个规则集通过分配不同但可比的速率限制器来实现相同的配置文件。

  • 规则集 2

    • 规则 2A

      • 客户端到服务器限制器 2

      • 服务器到客户端限制器-2

    • 规则 2B

      • 客户端到服务器限制器 2

      • 服务器到客户端限制器-4

  • 规则集 3

    • 规则 3A

      • 客户端到服务器限制器 3

      • 服务器到客户端限制器 3

    • 规则 3B

      • 客户端到服务器限制器 3

      • 服务器到客户端限制器 5

使用命令 edit class-of-service application-traffic-control rule-sets 应用速率限制器的方式与设置转发类、DSCP 值和丢失优先级的方式相同。

如果在出口 PIC 上同时实施了 AppQoS 和基于防火墙过滤器的速率限制,则会同时考虑两项功能。首先考虑 AppQoS 速率限制。之后会进行基于防火墙过滤器的速率限制。

注意:

如果数据包从 PIC 中丢失,设备不会向客户端或服务器发送通知。客户端和服务器设备上的上层应用程序负责重传和错误处理。

速率限制器操作

根据安全设备的类型,AppQoS 规则可配置不同的速率限制器操作:

  • 丢弃

    • 选择此选项后,只会丢弃超出配置文件的数据包。

    • 这是默认操作类型,无需配置。

    • 所有安全设备都支持此选项

  • 丢失优先级-高

    • 选择此选项后,它会将丢失优先级提升到最大值。换句话说,这是一个延迟的下降;也就是说,丢弃决策在出口输出队列级别进行。如果没有拥塞,即使丢失优先级达到最大,也允许流量传输。但是,如果发生拥塞,它会首先丢弃这些最大丢失优先级数据包。

    • 必须使用以下命令在 AppQoS 规则中配置此选项(以覆盖默认操作):

    • 选定设备上支持此选项。请参阅特定 于平台的 AppQoS 行为 表。

AppQoS 安全性策略配置

AppQoS 规则集可以在现有策略或特定应用策略中实施。

示例:配置应用程序服务质量

此示例说明如何在策略中启用 AppQoS 优先级和速率限制。

要求

配置此功能之前,不需要除设备初始化之外的特殊配置。

概述

在此示例中,实施了 AppQoS,以便将 FTP 应用程序限制在低于指定吞吐量的级别,而其他应用程序则以更传统的速度和丢失优先级级别进行传输。

配置

过程

要快速配置此示例,请复制以下命令,将其粘贴到文本文件中,移除所有换行符,更改任何必要的详细信息以匹配您的网络配置,然后将命令复制粘贴到 [edit] 层级的 CLI 中。

分步程序

要在安全设备上配置 AppQoS,请执行以下操作:

  1. 定义一个或多个专门用于 AppQoS 标记的转发类。在此示例中,定义了一个转发类 my-app-fc,并将其分配给队列 4。

    或者

    瞻博网络设备支持八个队列(0 到 7)。默认队列 0 到 3 分配给默认转发类。队列 4 到 7 没有对 FC 的默认分配,也不会映射。要使用队列 4 到 7,您必须创建自定义光纤通道名称并将其映射到队列。有关更多详细信息,请参阅 转发类概述。

  2. 定义速率限制器。在本例中,定义了两个速率限制器。

  3. 定义 AppQos 规则和应用匹配标准。

    在此示例中,匹配时,数据包将使用转发类 my-app-fc、DSCP 值 af22 和丢失优先级低标记。我们在两个方向上分配了相同的速率限制器。

    您可以在单个规则中为一个或两个流量方向分配速率限制器。您还可以将相同的速率限制器分配给规则集中的其他规则。但是,不能将相同的速率限制器分配给不同的规则集。

  4. 定义另一个规则来处理与上一个规则不匹配的应用数据包。在此示例中,第二个也是最后一个规则适用于所有剩余应用程序。

  5. 将 AppQoS 设置添加到安全策略。

结果

在配置模式下,输入 show security policies and show class-of-service 命令以确认您的策略配置。如果输出未显示预期的配置,请重复此示例中的说明以更正配置。

为简洁起见,此 show 命令输出仅包含与此示例相关的配置。系统上的任何其他配置都已替换为省略号 (...)。

如果完成设备配置,请从配置模式进入。commit

验证

确认配置工作正常。

验证流会话配置

目的

验证 AppQoS 是否已启用。

行动

在操作模式下,输入命令 show security flow session application-traffic-control extensive 。

意义

应用流量控制的条目标识当前会话的规则集和规则。

验证会话统计信息

目的

验证是否在每个出口节点上累积 AppQoS 会话统计信息。

行动

在操作模式下,输入命令 show class-of-service application-traffic-control counter 。

意义

仅当启用了应用流量控制服务时,才会保留 AppQoS 统计信息。已处理、标记和已完成的会话数表明,会话是根据配置的 AppQoS 功能进行定向的。速率限制统计信息计算已受速率限制的定向会话流的数量。

验证速率限制器统计信息

目的

验证遇到 FTP 应用时带宽是否按预期受到限制。

行动

在操作模式下,输入命令 show class-of-service application-traffic-control statistics rate-limiter 。

意义

按规则集显示每个 PIC 的实时应用带宽限制信息。此命令指示正在受速率限制的应用程序和正在应用的配置文件。

验证规则统计信息

目的

验证规则是否与规则统计信息匹配。

行动

在操作模式下,输入命令 show class-of-service application-traffic-control statistics rule 。

意义

此命令提供有关每个规则集下规则的(会话)命中数的信息。

针对统一策略的应用服务质量支持

统一策略是一种安全策略,允许您将动态应用用作现有五元组或六元组(带有用户防火墙的五元组)匹配条件的一部分,以检测应用程序随时间的变化。

当安全设备配置了统一策略时,将支持应用服务质量 (AppQoS)。您可以配置默认的 AppQoS 规则集,以在多个安全策略与流量匹配时管理统一策略冲突。

统一策略中包含 AppQoS 规则集,用于实施应用感知的服务质量控制。您可以在选项 application-traffic-control 下使用规则配置规则集,并将 AppQoS 规则集作为应用服务附加到统一安全策略。如果流量与指定的动态应用匹配,且允许策略操作,则应用应用感知服务质量。

请注意统一策略中的以下 AppQoS 功能:

  • 从传统安全策略升级到统一策略 — 在统一策略中,将选项 dynamic-application 配置为 none时,将在安全策略匹配期间应用 AppQoS 规则集,并且 AppQoS 会为已识别的流量查找相应的规则。这与 18.2R1 版之前的 Junos OS 版本中的 AppQoS 功能行为相同。

  • 具有统一策略的 AppQoS 规则 — 在应用流量控制配置中,AppQoS 规则集配置为匹配条件 application-any ,在统一策略中,使用特定的动态应用作为匹配条件,然后,AppQoS 功能根据统一策略中的规则运行。

了解统一策略的默认应用服务质量规则集

您可以配置 AppQoS 默认规则集来管理安全策略冲突。

初始策略查找阶段发生在识别动态应用之前。如果潜在策略列表中存在多个包含不同 AppQoS 规则集的策略,则安全设备将应用默认的 AppQoS 规则集,直到出现更明确的匹配。

您可以将 AppQoS 设置为层级下的 edit security ngfw 默认 AppQoS 规则集。默认 AppQoS 规则集可从现有的 AppQoS 规则集之一中利用,这些规则集在层次结构级别下 [edit class-of-service application-traffic-control] 配置。

表 2 总结了统一策略中不同场景下默认 AppQoS 规则集的使用情况。

表 2:统一策略中的 AppQoS 规则集用法

应用识别状态

AppQoS 规则集用法

行动

没有安全策略冲突。

当流量与安全策略匹配时,将应用 [edit class-of-service application-traffic-control] 层次结构下设置的 AppQoS 规则。

AppQoS 的应用方式与 AppQoS 规则集中的相同。

安全性策略冲突和冲突策略具有不同的 AppQoS 规则集。

默认 AppQoS 规则集未配置或未找到。

由于未配置默认 AppQoS 配置文件,因此会忽略会话。

因此,即使策略冲突场景中的最终匹配策略具有 AppQoS 规则集,也不会应用该规则集。我们建议配置一个默认的 AppQoS 规则集来管理安全策略冲突。

配置了默认的 AppQoS 规则集。

AppQoS 的应用与默认 AppQoS 规则集一样。

确定最终应用

匹配的安全策略具有AppQoS规则集,该规则集与默认的AppQoS规则集相同。

AppQoS 的应用与默认 AppQoS 规则集一样。

匹配的安全策略没有 AppQoS 规则集。

不会应用默认 AppQoS 规则集,并且不会将 AppQoS 应用于会话。

匹配安全策略的 AppQoS 规则集与已应用的默认 AppQoS 规则集不同。

默认 AppQoS 规则集仍为默认 AppQoS 规则集。

当对流量应用了默认的 AppQoS 规则集,而最终安全策略具有不同的 AppQoS 规则集时,不支持从默认 AppQoS 规则集切换到最终安全策略中的 AppQoS 规则集。

不同方案下的默认应用服务质量规则集

以下链接指向的示例,这些示例讨论了不同场景下的默认 AppQoS 规则集:

表 3 显示了为统一策略配置的不同 AppQoS 规则集,这些规则以动态应用为匹配条件。

表 3:统一策略中的不同 AppQoS 规则集

安全性策略

源区段

源 IP 地址

目标区域

目标 IP 地址

端口号

协议

动态应用

服务

AppQoS 规则集

策略-P1

第 1 季

50.1.1.1

第 1 天

任何

任何

任何

脸书

AppQoS

AppQoS-1

策略-P2

第 1 季

50.1.1.1

第 1 天

任何

任何

任何

谷歌

AppQoS

AppQoS-2

策略-P3

第 1 季

50.1.1.1

第 1 天

任何

任何

任何

YouTube

AppQoS

应用QoS-3

在此示例中,任何 AppQoS 规则集(AppQoS-1、AppQoS-2、AppQoS-3)都可以配置为层次结构级别下的 [security ngfw] 默认 AppQoS 规则集。默认规则集不一定是安全策略配置的一部分。可以将层级下 [edit class-of-service application-traffic-control] 的任何 AppQoS 规则集分配为默认 AppQoS 规则集。

无策略冲突 — 所有策略均具有相同的 AppQoS 规则集

所有匹配的策略都具有相同的 AppQoS 规则集,如 表 4 所示。

表 4:所有匹配策略都具有相同的 AppQoS 规则集

安全性策略

源区段

源 IP 地址

目标区域

目标 IP 地址

端口号

协议

动态应用

服务

AppQoS 规则集

策略-P1

第 1 季

任何

第 1 天

任何

任何

任何

脸书

AppQoS

AppQoS-1

策略-P2

第 1 季

任何

第 1 天

任何

任何

任何

谷歌

AppQoS

AppQoS-1

在此场景中,策略 Policy-P1 和 Policy-P2 具有相同的 AppQoS 规则集;即 AppQoS-1。将应用规则集 AppQoS-1。此方案中未配置策略 P3。

如果已将规则集 AppQoS-2 配置为默认规则集,则不会应用该规则集。这是因为冲突策略(Policy-P1 和 Policy-P2)中的 AppQoS 规则集不存在冲突。

无策略冲突 — 所有策略都具有相同的 AppQoS 规则集,最终策略没有 AppQoS 规则集

所有匹配策略都具有相同的 AppQoS 规则集,如 表 5 所示,最终策略没有 AppQoS 规则集。

表 5:所有匹配策略都具有相同的 AppQoS 规则集,最终策略没有 AppQoS 规则集

安全性策略

源区段

源 IP 地址

目标区域

目标 IP 地址

端口号

协议

动态应用

服务

AppQoS 规则集

策略-P1

第 1 季

任何

第 1 天

任何

任何

任何

脸书

AppQoS

AppQoS-1

策略-P2

第 1 季

任何

第 1 天

任何

任何

任何

谷歌

AppQoS

AppQoS-1

策略-P3

第 1 季

50.1.1.1

第 1 天

任何

任何

任何

YouTube

其他

无

在此方案中,Policy-P1 和 Policy-P2 具有相同的 AppQoS 规则集,即 AppQoS-1。在这种情况下,将应用规则集 AppQoS-1。

当最终策略 Policy-P3 匹配时,AppQoS 将忽略该会话,因为未为 Policy-P3 配置 AppQoS 规则集。

如果最终安全策略未设置任何 AppQoS 规则,则不会对流量应用 AppQoS。在预匹配阶段应用的所有 AppQoS 设置都将恢复为原始值。

策略冲突 — 未为最终策略配置 AppQoS 规则集

默认 AppQoS 规则集(在此场景中为 AppQoS-1)将在潜在策略匹配期间应用,如 表 6 所示。最后一个策略 Policy-P3 没有设置 AppQoS 规则。

表 6:匹配策略具有不同的 AppQoS 规则集,最终策略没有 AppQoS 规则集

安全性策略

源区段

源 IP 地址

目标区域

目标 IP 地址

端口号

协议

动态应用

服务

AppQoS 规则集

策略-P1

第 1 季

50.1.1.1

第 1 天

任何

任何

任何

脸书

AppQoS

AppQoS-1

策略-P2

第 1 季

50.1.1.1

第 1 天

任何

任何

任何

谷歌

AppQoS

AppQoS-2

策略-P3

第 1 季

50.1.1.1

第 1 天

任何

任何

任何

YouTube

其他

不适用

如果应用了最终匹配策略 Policy-P3,AppQoS 将忽略该会话。

如果最终安全策略未设置任何 AppQoS 规则,则不会对流量应用 AppQoS。在这种情况下,在预匹配阶段应用的所有 AppQoS 设置都将恢复为原始值。

策略冲突 — 默认 AppQoS 规则集和用于最终策略的不同 AppQoS 规则集

规则集 AppQoS-1 配置为默认规则集,并在尚未识别最终应用程序时应用。最终策略 Policy-P3 具有不同的 AppQoS 规则集 (AppQoS-3),如 表 7 所示。

表 7:针对最终策略的不同 AppQoS 规则集

安全性策略

源区段

源 IP 地址

目标区域

目标 IP 地址

端口号

协议

动态应用

服务

AppQoS 规则集

策略-P1

第 1 季

50.1.1.1

第 1 天

任何

任何

任何

脸书

AppQoS

AppQoS-1

策略-P2

第 1 季

50.1.1.1

第 1 天

任何

任何

任何

谷歌

AppQoS

AppQoS-2

策略-P3

第 1 季

50.1.1.1

第 1 天

任何

任何

任何

YouTube

AppQoS

应用QoS-3

识别出最终应用时,将匹配并应用策略 Policy-P3。在这种情况下,不应用规则集 AppQoS-3。相反,规则集 AppQoS-1 将作为默认规则集应用,并保留为默认规则集。

统一策略下的 AppQoS 的局限性

将安全策略应用于匹配流量时,AppQoS 规则集将应用于允许的流量。如果安全策略和应用的 AppQoS 规则集具有不同的动态应用,则可能会发生冲突,如以下示例所示:

在此示例中,为 junos:GOOGLE 配置了应用流量控制规则,动态应用的安全策略匹配条件为 junos: FTP。在这种情况下,应用最终策略时可能会发生冲突。

示例:使用统一策略配置应用程序服务质量

此示例说明如何在统一策略中启用应用服务质量 (AppQoS),以便为流量提供优先级和速率限制。

要求

此示例使用以下硬件和软件组件:

  • 运行 Junos OS 18.2R1 及更高版本的 SRX 系列防火墙。此配置示例针对 Junos OS 18.2R1 版进行了测试。

配置此功能之前,不需要除设备初始化之外的特殊配置。

概述

在此示例中,您将配置一个 AppQoS 规则集,并在 Facebook 应用程序的安全策略中调用 AppQoS 作为应用程序服务。

您可以在 [edit security ngfw] 层次结构级别下定义一个默认的 AppQoS 规则集,用于管理安全策略冲突(如果有)。

配置

过程

分步程序

要使用统一策略配置 AppQoS:

  1. 定义 AppQoS 规则集。

  2. 配置默认 AppQoS 规则集。选择在应用流量控制下创建的规则集 RS1 作为默认 AppQoS 规则集。

  3. 将服务等级规则集与统一策略相关联。

结果

在配置模式下,输入 show security policies 命令以确认您的策略配置。如果输出未显示预期的配置,请重复此示例中的说明以更正配置。

为简洁起见,此 show 命令输出仅包含与此示例相关的配置。系统上的任何其他配置都已替换为省略号 (...)。

如果完成设备配置,请从配置模式进入。commit

验证

确认配置工作正常。

验证流会话配置

目的

显示 AppQoS 会话统计信息。

行动

在操作模式下,输入命令 show class-of-service application-traffic-control counter 。

示例输出
命令名称
意义

输出显示已处理、标记和已接受的会话数。速率限制统计信息计算已受速率限制的定向会话流的数量。

验证规则统计信息

目的

显示 AppQoS 规则统计信息。

行动

在操作模式下,输入命令 show class-of-service application-traffic-control statistics rule 。

意义

输出提供有关每个 AppQoS 规则集下与规则匹配的会话数的信息。

HTTP2: AppQoS DSCP 支持

HTTP/2 应用服务质量 (AppQoS) 差异服务代码点 (DSCP) 支持通过利用第一流分类增强了跨 HTTP/2 会话的服务质量 (QoS) 规则应用。此增强功能支持将 QoS 规则应用于 HTTP/2 会话,确保根据应用类型对流量进行分类和优先级排序。此功能允许您在 HTTP/2 流量中实施精细的 AppQoS 策略,这在处理分类在不同应用程序下的多个流时至关重要。通过根据第一个流会话的分类应用 AppQoS 规则,您可以确保一致的 QoS 管理,即使由于未指定的规则而调用回退逻辑也是如此。此功能可集成到现有 HTTP/2 流量管理框架中,解决传统和统一策略案例中的场景,并在加密会话中保持有效的 QoS 实施,无需任何额外的 CLI 配置。

概述

现在,当特定 HTTP/2 规则不存在时,HTTP/2 流量会继承 HTTP AppQoS 规则,用于 DSCP 标记,从而保证一致的 QoS 行为。

HTTP 是一个总括式应用,其中多个应用(例如,facebook、twitter)显示为单独的会话,并进行独立分类,并为每个会话应用 AppQoS。以前,HTTP/2 会话仅被归类为 http2,没有任何子流应用分类

也就是说,对于 HTTP/2 会话,只能应用父会话的 AppQoS 规则。但是,HTTP/2 使用多个流,每个流被归类为不同的应用程序。对于 AppQoS 规则匹配,子会话分类将被忽略。

在新的更新中,第一个流会话的应用程序分类用于匹配 AppQoS 规则并将其应用于 HTTP/2 父会话。如果第一个流的最终分类应用程序没有 AppQoS 规则,则会话将回退到父 HTTP/2 AppQoS 规则。

示例:

考虑包含多个流的 HTTP/2 会话。

  • 第一个流被标识为 twitter。
  • 应用了 twitter 的 AppQoS 规则。
  • HTTP/2 父会话的每个流都继承该规则。

在这里,数据包不再进入通用的 http2 队列;它们完全进入 First Stream 的应用程序队列 (Twitter)。

回退逻辑

HTTP/2 流量被视为 HTTP 流量的一部分。如果缺少 HTTP/2 规则,流量将回退到 DSCP 标记的 HTTP AppQoS 规则。为了实现此回退,将调整分类路径,如以下示例所示:

家长会议

  • 以前的行为: ip.tcp.ssl.http2
  • 新行为: ip.tcp.ssl.http.http2

子会话

  • 以前的行为: ip.tcp.ssl.http.facebook
  • 新行为: ip.tcp.ssl.http.http2.facebook

分类逻辑

适用于 HTTP/2 的 AppQoS 使用自上而下的规则查找,从最具体的应用开始,回退到 HTTP2、HTTP、SSL 和 application-any。第一个流会话的分类现在用于父会话规则匹配,确保准确的 QoS 分配和日志记录。

规则集和应用映射
  • 每个安全策略都使用一个规则集,其中包含适用于不同应用(例如 http、http2、facebook)的特定 AppQoS 规则。
  • 每个规则分配一个转发类(尽力而为、保证转发、加急转发、网络控制)和一个 COS 队列。
分类路径
  • AppQoS 规则查找从最具体的应用(嵌套应用)开始,然后向上移动。会话(父/子)使用分层路径(示例: ip.tcp.ssl.http.http2.facebook)进行分类。

    在本例中,查找顺序如下:

    1. 如果未在规则集中配置嵌套应用 (facebook-chat) ,则应用该 http2 规则。
    2. 如果未配置,则 http2 应用规则 http 。
    3. 如果未配置,则 http 应用规则 ssl 。
    4. 如果任何分类应用都不存在 AppQoS 规则,则应用该 application-any 规则。
    5. 如果未配置,则 application-any 会话继续使用之前应用的 DSCP 规则。

    此分类可确保 HTTP/2 会话永远不会被忽略,并且始终接受 QoS 处理。

示例: AppQoS 配置文件包含特定应用的规则以及“任意”包罗万象规则。例如,该配置文件包括 HTTP、Facebook、Yahoo 和 Any 的规则集,第一个流分类为:Http.http2.twitter

案例 A — 配置了“任何”规则

  • 不存在明确的推特规则。
  • 由于存在 Any 规则,因此 AppQoS 选择 Any。
  • 结果:应用“任意”规则。

案例 B — 未配置“任何”规则

  • 不存在明确的推特规则。
  • 没有任何可用的规则。
  • 在这种情况下,系统将按特异性降序回退到下一个最佳匹配项:
    • HTTP2 规则(如果存在)
    • 如果没有 http2 规则→回退到 http
    • 如果没有 http 规则→使用默认队列
  • 结果:根据上述回退顺序选择最接近的匹配规则。
父会话和子会话处理
  • 父会话:通常分类在更高级别(例如:http2)。
  • 子会话:使用更具体的嵌套应用(例如:facebook、twitter)进行分类。

现在,第一个流会话的分类被考虑用于父会话中的规则匹配。

转发和日志记录
  • 系统会根据匹配的规则为每个会话的流量分配一个转发类和队列。
  • 系统日志条目反映了会话和流关闭的分类和规则匹配

限制

  • 对于 HTTP/2,只有第一个流的应用程序分类用于父会话中的 AppQoS 规则匹配。
  • 在长时间会话中,中游应用切换(HTTP/1 或 HTTP/2)会导致 CoS 队列更改,从而导致数据包重新排序。终端设备上的 TCP 重装使用序列号处理此问题。
  • 机箱群集和多节点高可用性方案不支持用于 AppQoS 的 HTTP/2。
  • 配置 SSL 转发代理时,AppQoS 速率限制器无法在 HTTP/1.1 和 HTTP/2 流量设置中的 HTTPS 流量正常工作。

HTTP2 加密流量

对于加密流量,HTTP/2 模块将被禁用,因此不会创建 HTTP/2 子会话。AppQoS 仅应用于父会话。

特定于平台的 AppQoS 行为

使用 AppQoS 和 功能浏览器 确认特定功能的平台和版本支持。

使用下表查看平台的特定于平台的行为:

平台

差异

SRX 系列

SRX5400、SRX5600 和 SRX5800 使用以下配置语句定义转发类名称和队列分配:

[edit class-of-service] 
user@host# set forwarding-classes class forwarding-class-name queue-num queue-number
SRX 系列

SRX300、SRX320、SRX340、SRX345、SRX380、SRX400、SRX440、SRX550M、SRX1500、SRX4100、SRX4200、SRX4600 和 vSRX,使用以下配置语句定义转发类名称和队列分配:

[edit class-of-service] 
user@host# set forwarding-classes queue queue-number forwarding-class-name
SRX 系列 SRX300、SRX320、SRX340、SRX345、SRX400、SRX440 使用 loss-priority-highAppQoS 规则中的选项覆盖默认操作。
[edit] 
user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high
SRX 系列

SRX5400、SRX5600 和 SRX5800 每台设备最多支持 1000 个速率限制器。但是,它只允许 16 个不同的配置文件,每个配置文件由带宽限制和突发大小限制参数的唯一组合定义。

变更历史表

是否支持某项功能取决于您使用的平台和版本。使用 功能资源管理器 确定您的平台是否支持某个功能。

发布
描述
18.2R1
支持统一策略。