应用体验质量
应用体验质量 （AppQoE）
应用体验质量简介
随着云计算、移动性和基于 Web 的应用的无情增长，网络需要在应用层面识别和控制流量，并单独处理每种应用类型，为用户提供体验质量 （QoE）。为了确保特定于应用的 QoE （AppQoE），您需要在不损害性能或可用性的情况下，有效地对应用流量进行优先级排序、隔离和路由。
AppQoE 利用（或采用）两种应用安全服务的功能 - 应用识别 （AppID） 和基于策略的高级路由 （APBR）。它使用 AppID 识别网络中的特定应用，并使用基于策略的高级路由 （APBR） 通过将 SLA 配置文件关联到根据 APBR 规则发送应用流量的路由实例，为某些流量指定路径。
软件定义 WAN （SD-WAN） 的一项重要要求是测量底层网络路径的质量，并根据结果确定用于传输每个数据包的最佳路径。AppQoE 监控关键业务应用程序的性能，并根据分数为该应用程序流量选择最佳链路，以满足 SLA（服务级别协议）中指定的性能要求。
APBR 配置中存在 SLA 规则会触发 AppQoE 功能;如果没有可用的 SLA 配置文件，则 APBR 在不触发 AppQoE 的情况下运行。
支持的用例
您可以使用 Contrail 服务编排 （CSO） 以最佳方式配置 AppQoE。我们建议您使用 CSO 为瞻博网络 Contrail SD-WAN 解决方案配置 AppQoE。有关详细信息，请参阅 应用程序体验质量概述 和 配置和监视应用程序体验质量。
支持的配置选项
SD-WAN 部署中的中心辐射型和全网状拓扑都支持 AppQoE。
您可以在两个 Junos OS 防火墙端点（预订端）之间配置 AppQoE，并且两个防火墙必须具有相同版本的 Junos OS 映像。
应用体验质量的优势
-
通过实时监控应用流量来提供一致且可预测的服务级别，从而实现经济高效的 QoE。
-
通过为特定流量（如视频流量）的交付提供有保证的 SLA，提高客户保留率和满意度。AppQoE 确保审批的流量获得适当的优先级和所需的带宽，以确保为用户提供最佳体验质量。
局限性
在安全设备上实施 AppQoE 具有以下限制：
-
通过不同接口到达目标的所有不同路由必须配置相同的首选项、权重和指标。所有路由都必须添加为目标的 ECMP 路径，并且还必须是同一转转发表的一部分。
-
仅支持两个安全设备端点之间的 AppQoE SLA 服务（预订端）。不支持端到端 AppQoE SLA 服务。
-
仅当所有接口都属于同一区域时，才能应用 AppQoE。
-
AppQoE 不能用于反向流量。
-
AppQoE 不会影响会话目标的更改。
-
AppQoE 不支持 IPv6/UDP 探测封装、GRES、机箱群集（ISSU、高可用性、双 CPE 高可用性、Z 模式高可用性）和逻辑系统。
-
AppQoE 不支持首选路径选择，也不支持中转虚拟路由和转发 （VRF）。
-
AppQoE 不支持对 IPv6 数据包进行被动探测。
-
非 WAN 接口需要输入防火墙过滤器，以丢弃 UDP 目标端口为 36000 的 UDP 数据包。
应用体验质量的工作原理是什么？
AppQoE 利用 AppID 和 APBR 功能来识别特定的应用/应用组，并通过将 SLA 配置文件关联到根据 APBR 规则发送应用流量的路由实例，为某些流量指定路径。
AppQoE 监控应用程序的性能，并根据分数为该应用程序流量选择最佳链路，以满足 SLA（服务级别协议）中指定的性能要求。
识别应用程序或应用程序组
识别应用程序或应用程序组涉及以下步骤：
-
Junos OS 应用识别可识别应用，一旦识别出应用，其信息将保存在应用系统缓存 （ASC） 中。
-
APBR 评估数据包，以确定会话是否适合基于应用的路由（基于高级策略的路由）。如果这是新会话的第一个数据包，并且流量未针对基于应用的路由进行标记，则该流量将进行正常处理（非 APBR 路由）到达目标。
-
如果会话需要基于应用的路由，APBR 会查询 ASC 模块以获取应用属性（IP 地址、目标端口、协议类型和服务）。
-
如果在 ASC 中找到应用程序，则会根据 APBR 配置文件中的匹配规则进一步处理流量。
-
如果找到匹配的规则，则会将流量重定向到指定的路由实例，以便进行路由查找。
-
AppQoE 检查是否为会话启用了 SLA。如果会话是 SLA 测量的候选会话，AppQoE 将启动主动和被动探测以进行性能测量。
-
如果未在 APBR 规则中为会话启用 SLA，则 AppQoE 将忽略该会话，并将 APBR 的默认行为应用于这些会话，也就是说，流量通过目标的指定路由实例进行路由。
-
-
如果在 ASC 中找不到中的应用程序，APBR 将请求对流进行深入检查。也就是说，安装应用签名包并启用会话的应用标识，以便可以填充 ASC，以供后续会话用于 APBR 处理（请参阅步骤 2）。
-
指定应用程序或应用程序组的路径
以下步骤总结了 AppQoE 如何根据 SLA 规则为应用程序流量指定路径。
-
APBR 使用应用程序详细信息在 APBR 配置文件（应用程序配置文件）中查找匹配规则。与应用和应用组匹配的流量将被转发到路由实例中指定的静态路由和下一跃点地址。
-
附加到 APBR 配置文件的 SLA 规则指定测量 SLA 和识别是否发生任何 SLA 违规所需的参数。
-
根据使用主动探测测量的叠加链路的 SLA 指标，将应用流量分配给该特定叠加链路。
-
通过被动探测实时应用/应用组流量来确定 SLA 违规。通过路径选择算法确定应用程序/应用程序组的最佳路径/叠加链接。
应用流量路径选择
将执行以下步骤将数据流量从源路由到目标，具体来说，就是选择最佳路径
-
对于流的第一个数据包（第一个路径），如果应用程序已知（通过 ASC 查找），则会在数据库中搜索应用程序的最佳路径。如果应用程序未知或新建（从 ASC 查找中），则选择随机路径或默认路径。此路径将在整个会话中继续。稍后，在 DPI 检测到应用程序后，数据库将更新为应用程序的最佳路径。
-
对于流的剩余数据包（快速路径），如果应用程序最初未知，则特定会话将在同一路径上继续。如果应用程序最初是已知的，则 AppQoE 会为应用程序流量选择最佳路径。
检测到新应用程序时，路径选择机制会尝试查找满足所有 SLA 指标的路径。如果不存在此类路径，则使用下一个最佳路径（基于满足的指标数）。如果有多个路径满足指标，则在可用路径中选择一条随机路径。根据配置文件配置，当任何一个指标被违反或没有一个指标满足要求时，将检测 SLA 冲突。
应用体验质量如何衡量应用性能
应用程序性能由以下指标决定：
-
延迟 - 介质传输所需的物理时间，具体取决于需要覆盖的介质长度和距离
-
RTT— 从源地到目的地所需的往返时间，反之亦然。
-
数据包丢失 — 数据包丢失反映主机发送的每 100 个数据包丢失的数据包数。
-
抖动 — 抖动是指不同数据包之间的延迟差异。可以指定入口抖动、出口抖动和双向抖动来评估链路的性能。
AppQoE 监控每个链路上的 RTT、抖动和数据包丢失，如果主链路的性能低于 SLA 指定的可接受水平，则根据分数将应用无缝转移到备用路径。使用主动和被动探测来检测 SLA 违规，并为该特定应用选择备用路径，从而完成应用性能的测量和监控。
AppQoE 通过持续监控应用流量并通过以下方式识别网络或设备问题来收集实时数据：
-
监控所有已配置的叠加链路的性能。
-
使用无源探测（与应用数据路径内联）和有源探测（针对特定应用的合成探测）监控应用或应用组的流量性能。
-
将所有收集的性能指标或元数据发送到日志收集器进行分析。
-
将指定的应用与特定的性能指标进行比较，并在发生违反 SLA 的情况时动态更改应用流量的路径。
-
支持对给定应用或应用组进行灵活的 SLA 指标配置。
AppQoE 跨多个 WAN 链路测量应用 SLA，并将应用流量映射到可用链路中的路径，即最能满足 SLA 要求的路径。
使用主动和被动探测测量应用性能
主动和被动探测测量是用于网络端到端分析的两种方法。
-
主动探测 — 主动探测可衡量应用的服务质量，从而提供对网络性能的端到端测量。
在主动探测中，会在所有多个路由上的分支点和中枢点之间发送自定义数据包，并在已安装的探测点之间测量 RTT、延迟、抖动和数据包丢失情况。主动探测会在所有主动和被动链路上定期发送。收集配置数量的样本，并测量每个此类应用的探测路径的运行平均值。如果检测到任何应用流量违规，则会评估探测指标，以确定满足 SLA 的最佳链路。
-
无源探测 — 无源探测安装在网络内的链路上，探针监控流经这些链路的所有流量。
被动探测可监控实时数据流量上的链路是否存在违反 SLA 的行为。在无源探测中，实际数据包封装在设备预订点之间的实时流量中的 IP/UDP 探测标头中。探测可测量探头安装点之间的 RTT、抖动和数据包丢失，以计算服务质量。
如果检测到任何应用程序存在冲突，则会评估综合探测指标，以确定满足 SLA 的最佳链路。
注意：为了检测链路或路径是否因被动探测而中断，在给定会话的采样期内，必须至少发生三个探测请求且 100% 的数据包丢失，才能触发 SLA 违规。
注意：当设备在机箱群集模式下运行时，如果重新启动转发流量的辅助节点（节点 1），则会发生跨辅助节点链路的链路之间的应用流量的多次切换。当主节点（节点 0）上的可用链路与辅助节点链路相比，活动探测 SLA 路径分数较低时，会出现这种情况。此行为一直持续到 AppQoE 主动探测 SLA 路径分数结果可用，以指示辅助节点上的所有链路上存在 100% 的数据包丢失。
您可以使用主动和被动探测参数配置 SLA 规则，并将 SLA 规则与 APBR 配置文件相关联。APBR 配置文件还包括一个 APBR 规则。规则与一个或多个应用或多个应用组相关联，与规则匹配的流量将重定向至路由实例
AppQoE 触发对应用程序的所有探测路径的探测请求。主动和被动探测可监控网络中的故障或拥塞区域或点。
AppQoE 使用主动和被动探测为学习的应用程序收集流量类统计信息，并采取以下措施：
-
衡量 SLA 性能 — 探针提供的实时指标用于根据应用的 SLA 对服务质量进行评分，并确定应用路径是否不符合 SLA 要求。也就是说，如果检测到任何应用程序存在违规，则评估合成探测指标，以确定满足 SLA 的应用程序流量的最佳备用链路。
-
重新路由流量 — 在两个链路之间切换应用程序流量，也就是说，当一个链路出现性能问题时，流量将在同一会话中路由到另一个链路。
如果可以通过多个链路访问应用的流量，则必须将所有可访问的路径配置为叠加路径，并将叠加路径附加到应用的 SLA 规则中。
将应用流量切换到备用路径
在违反 SLA 期间，您可以启用或禁用将应用程序流量切换到另一个路由（设备本地）。启用本地路由切换时，将启用应用流量到备用路由，并且 SLA 监控和报告功能也可用。即使在 SLA 规则配置中禁用了将应用程序流量切换到备用路径的选项，AppQoE 也会解决 SLA 违规问题，例如，通过将应用程序流量切换到新路径。
禁用本地路由切换时，仅 SLA 监控和报告功能可用，并且会关闭因违反 SLA 而将应用流量切换到其他路由。
当应用程序流量切换到备用路径时，在很短的时间内，如果发生违反 SLA 的情况，应用程序流量将无法再次切换到其他路径。此时间段有助于避免跨链路的流量抖动。
了解 AppQoE 配置限制
当您配置特定于应用程序的 SLA 规则并将 SLA 规则关联到 APBR 配置文件时，AppQoE 会强制执行每个配置文件的叠加路径、指标配置文件、探测参数和每个配置文件的 SLA 规则的配置限制。
如果配置的参数超过允许的限制，则在提交配置时将显示错误消息。
错误消息示例：
配置限制的值可能无法反映支持的确切数量;受支持设备之间的数字可能不同
[edit security advance-policy-based-routing]
'sla-rule sla0'
Cannot configure more than 32 sla rules
error: configuration check-out failed
[edit security advance-policy-based-routing]
'overlay-path grep2'
Cannot configure more than 2000 overlay paths
error: configuration check-out failed
[edit security advance-policy-based-routing]
'metrics-profile m0'
Max metrics for this system is 32
error: configuration check-out failed
[edit security advance-policy-based-routing]
'active-probe-params pr0'
Cannot configure more than 64 probe params
error: configuration check-out failed
基于链路优先级和优先级的应用路径选择
软件定义 WAN （SD-WAN） 的一项重要要求是测量底层网络路径的质量，并根据结果确定用于传输每个数据包的最佳路径。
您可以配置特定于应用的体验质量 （AppQoE），以便在有多个满足 SLA 要求的路径可用时，根据链路优先级和链路类型选择应用路径。
您可以选择 MPLS 或 Internet 链路作为首选路径，在 1 到 255 之间分配优先级，较低的值表示更优先的链路。值为一 （1） 表示最高优先级。当有多个路径可用时，选择优先级最高的路径。
例如，如果为 VoIP 流量选择了 MPLS 路径，并且在呼叫期间由于抖动或数据包丢失而导致质量下降，则数据包将通过满足 SLA 要求的另一条路径 （Internet） 发送。现在，应用流量通过互联网路径发送，如果互联网路径的质量下降，则该路径将切换回 MPLS。
您可以在基于策略的高级路由 （APBR） 规则中配置每个底层接口的链路优先级和链路类型，并且相同的参数将由相应的叠加网络继承。在这种情况下，底层接口是叠加网络路由拓扑中的最终传出接口。
例如，在网络基础架构中，如果底层是第四代 （4G） LTE 连接，则可以将拨号器接口配置为 AppQoE 的底层接口。同样，如果底层是 DSL 连接，则可以将相应的以太网点对点协议 （PPPoE） 接口配置为 AppQoE 的底层接口。
AppQoE 路径选择机制通过自定义链路标记配置、应用流量切换到首选标记的更高优先级链路、基于非 SLA 指标的部署和叠加接口属性首选项得到了增强。
应用程序路径优先级和优先级的好处
-
可以灵活地为应用流量选择最佳路径。
-
通过经济高效的连接选项实现应用流量路由，同时确保满足 SLA 要求（延迟和抖动）。
-
如果所选应用程序路径的质量下降，则支持动态路径切换。
路径选择机制
应用流量根据链路优先级通过单独的链路路由，如下所示：
-
AppQoE 路径选择机制包括到满足 SLA 要求的特定目标的最佳路径列表。AppQoE 从此列表中选择与用户配置的链路首选项匹配的路径。
-
如果有多个此类路径可用，则选择所有路径中优先级最高的路径。
-
如果未配置优先级或链路类型首选项，则选择随机路径或默认路径。
-
如果未提供满足 SLA 要求的链路，则在配置严格关联的情况下，选择最高 SLA 分数和链路类型优先级方面的最佳可用链路。
-
如果有多个满足 SLA 要求的链路可用，则选择优先级最高的链路。
有关配置示例，请参阅 在主动/主动模式下配置使用 LTE 备份的 WAN 链路。
AppQoE 的系统日志消息
引入应用级日志记录是为了减少在处理会话级别生成的大量系统日志消息时对 CSO 或日志收集器设备的影响。安全设备维护会话级别信息，并提供会话级别的系统日志消息。随着应用级日志记录取代会话级日志记录，安全设备的开销会降低，AppQoE 日志吞吐量会增加。
AppQoE 发送以下系统日志消息：
-
APPQOE_SLA_METRIC_VIOLATION：当检测到会话违规时，以及会话的路径因移动到新链接而得到解决时。
-
APPQOE_BEST_PATH_SELECTED：当会话切换其数据流量的路径时。
使用应用程序级日志记录时，所有会话级日志均在应用程序级别受支持。发送实时探测、测量 SLA 指标、违规检测和路径切换等 AppQoE 功能在会话级别继续提供。但是，作为应用级汇总功能的一部分，数据路径会话会通知 SLA 指标、违规信息和路径切换到 AppQoE 数据库。因此，从数据通路接收到的信息在应用程序级别进行聚合，然后以系统日志的形式发送到收集器设备。
表 1 提供了支持的新应用级日志的详细信息。
| 系统日志消息 |
描述 |
|---|---|
| APPQOE_APP_SLA_METRIC_VIOLATION |
|
| APPQOE_APP_BEST_PATH_SELECTED |
|
| APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
|
应用程序级日志记录引入了以下 AppQoE 功能更改：
-
有源探头仅维护和使用实时 RTT 和抖动值。对于数据包丢失，它指的是前一个会话的原因，因为数据包丢失只能在窗口结束时计算。
-
在配置提交期间，主动探测器会将所有条目的 RTT 和抖动值设置为最高 32 位值。
-
活动探测将保留前一个会话的值，直到有适当的实时指标值可用。
-
当主动探测出现 100% 的数据包丢失时，所有其他指标都将设置为最高 32 位值。
报告 RTT 和抖动的无效值
当 RTT 和 Jitter 的数据不可用时，以无效值 0xFFFFFFFF 发送的日志消息，日志收集器可以忽略该值。 表 2 提供了发送无效 RTT 和抖动时的一些可能情况。
| 场景 |
受影响的系统日志 |
|---|---|
| 100% 丢包： |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
| 丢包率大于 0 且小于 100%： |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
| 无丢包 |
APPQOE_APP_SLA_METRIC_VIOLATION APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
禁用 AppQoE 日志记录
默认情况下，AppQoE 日志类型设置为系统日志。如果要禁用 AppQoE，请在以下配置中将日志类型配置为 disabled：
基于传入流量的 DSCP 位的应用体验质量 （AppQoE）
AppQoE 支持根据 DSCP 值为传入流量选择基于 SLA 的路径。AppQoE 根据应用签名或 DSCP 值，或应用标识和 DSCP 值的组合，为应用流量选择最佳链路。
APBR 中的 DSCP 支持
在 APBR 规则中同时配置 DSCP 和动态应用程序时，如果流量与规则中指定的所有条件匹配，则该规则被视为匹配。当 APBR 规则中存在多个 DSCP 值时，如果任何一个条件匹配，则将其视为匹配。
APBR 配置文件可以包含多个规则，每个规则具有各种匹配条件。
如果 APBR 配置文件中有多个 APBR 规则，则规则查找使用以下优先级顺序：
-
使用 DSCP + 动态应用程序的规则
-
具有动态应用的规则
-
具有 DSCP 值的规则
网络服务编排器可以在外部服务功能时将应用程序映射到 DSCP 值，并在网关路由器上配置相同的内容以将 DSCP 映射到所需的 SLA 配置文件。
图 1 显示了一个场景：在网关路由器用例中，AppQoE 根据 DSCP 值和应用签名为传入流量执行基于 SLA 的路径选择。
的流量路径选择
对于基于 DSCP 值的流量，AppQoE 的工作方式如下：
-
所有从 LAN 进入网关路由器的流量都经过应用识别。在 DPI 识别出应用程序之前，系统会将流量流转发到默认的转发虚拟路由和转发 （VRF） 实例。VRF 包括一个关联的传出接口。
-
Junos OS 应用识别可识别应用，一旦识别出应用，其信息将保存在应用系统缓存 （ASC） 中。
-
系统继续检查是否有任何来自 DPI 分类或 ASC 的应用信息。
-
APBR 机制根据众所周知的应用、签名和 DSCP 值对会话进行分类，并使用策略来确定应用的最佳可能路由。APBR 策略将应用流量映射到特定的 VRF。
-
APBR 配置中存在 SLA 规则会触发 AppQoE 功能;AppQoE 根据应用程序或 DSCP 值对流量执行基于 SLA 的路径选择。
单个 DSCP 包含捆绑到其中的多个应用程序类别。不同的应用类别有其各自的流量模式。在这种情况下，使用被动探测检测违规并将其应用于所有会话可能会导致假阴性和误报。解决方法，在配置了基于 DSCP 的 SLA 规则时，避免使用被动探测。您可以对流量转发到的目标路径组使用主动探测。
局限性
在机箱群集模式的设备上使用基于 DSCP 的规则的 AppQoE 部署具有以下限制：
-
如果在完成应用程序标识之前完成规则匹配，并且 AppQoE 将会话移动到另一个节点，则应用程序识别不会完成。配置基于 DSCP 的规则时，会出现这种情况。
-
如果配置了两个 APBR 规则 — 1） DSCP 值 2） 同时配置了 DSCP 和动态应用程序，并在两个规则中分配了相同的 DSCP 值，则在接收第一个数据包时，APBR 将与 DSCP 规则匹配。如果在其他节点上确定了最佳路径，则会将会话移动到另一个节点。在此方案中，应用程序会话与 DSCP 规则匹配，而不是与 APP+DSCP 规则匹配。
AppQoE 的 APBR 策略
AppQoE 利用 APBR 增强功能，为 APBR 发送的应用流量选择最佳链路，以满足 SLA 中指定的性能要求。AppQoE 利用 APBR 提供的精细化规则匹配功能，根据应用流量提供体验质量 （QoE）。
例如，您希望通过最佳可用链路将到达信任区域的 Telnet 和 HTTPS 流量转发到特定设备或接口。当流量到达信任区域时，APBR 会将流量与匹配标准、源地址、目标地址和 APBR 策略中定义的应用进行匹配。如果流量与策略匹配，则应用相应的 APBR 配置文件。
APBR 使用应用程序详细信息在配置文件中查找匹配规则。如果找到匹配的规则，则流量会重定向到规则中定义的指定路由实例。
具有主动-主动部署的 AppQoE 多宿主
AppQoE 已得到增强，可通过主动-主动部署支持多宿主。以前，AppQoE 支持具有主动-备用部署的多宿主。
在主动-主动部署中，分支设备连接到多个中枢设备。如果指向中枢设备的链路满足 SLA 要求，则应用流量可以通过任何中枢设备进行传输。如果发生违反 SLA 或活动中心设备未响应的情况，应用流量可以在中枢设备之间无缝切换
图 1 显示了网格拓扑。在此拓扑中，可以通过多个节点到达端点。
要在主动-主动模式下启用多宿主，必须将 BGP 多路径配置为允许设备选择多个等价 BGP 路径以到达给定目标。
启用 BGP 多路径时，设备会选择多个等价 BGP 路径以到达给定目标，并且所有这些路径都将安装在转转发表中。AppQoE 完成路由查找，并获取下一跃点路由详细信息以及相应的叠加链接。AppQoE 从配置的目标路径组中获取 overlay-link 属性。
根据应用程序的 SLA 要求和链接首选项，AppQoE 确定该目标路径组中所有链接之间的最佳链接。如果发生违反 SLA 的情况，AppQoE 会根据 SLA 分数和链路首选项在所有配置的目标路径组中选择备用链路（如果端点可通过这些链路到达）。
有关 BGP 多路径配置的详细信息，请参阅 配置 BGP 多路径示例。
限度
在某些情况下，当路由的下一跃点 ID 发生更改时，即使有另一个满足 SLA 要求的链路可用，现有会话仍保留在违反 SLA 的链路上。但是，在这种情况下，新会话不会受到影响，并且会通过满足 SLA 要求的链路进行路由。
支持 SaaS 应用
我们扩展了对软件即服务 （SaaS） 应用的应用体验质量 （AppQoE） 支持。
AppQoE 跨可用 WAN 链路（如底层、GRE、IPsec 或基于 GRE 的 MPLS）执行服务级别协议 （SLA） 测量。然后，它通过最符合 SLA 的链路发送 SaaS 应用数据，以提供一致的服务。
支持 IPv6 流量
-
您可以在 AppQoE 配置中使用 IPv6 地址。支持包括：
- 叠加路径配置中的 IPv6 地址
- 使用 IPv6 地址作为源地址和目标地址的活动探测会话。
- 来自客户端的 IPv4 和 IPv6 流量
- LAN 侧 IPv4 和 IPv6 双堆叠
- LAN 端的 IPv6 地址，用于 SaaS（软件即服务）探测。
对于 SaaS 探测，请确保为传入接口配置 IPv4 和 IPv6 地址，以实现 IPv4 和 IPv6 互作性。
变更历史表
是否支持某项功能取决于您使用的平台和版本。使用 功能浏览器 查看您使用的平台是否支持某项功能。