安讯士 AXIS OS 知识库

AXIS OS 门户| AXIS OS 发行说明| AXIS OS 安全公告| AXIS OS 强化指南| AXIS OS YouTube 播放列表

欢迎来到 AXIS OS 知识库，这是一个全面的知识库，旨在成为有关 AXIS OS 的技术信息的首选资源。AXIS OS是基于 Linux 的操作系统，用于大多数 Axis 网络设备。它专为满足网络设备最重要标准而设计：高标准的网络安全、易于集成、质量和长期价值。

AXIS OS 漏洞档案已移至其自己的在线手册。请访问AXIS OS 安全公告。

有关如何强化 AXIS OS 设备的信息，请访问AXIS OS 强化指南。强化指南是为所有运行 AXIS OS LTS 或活动轨道的 AXIS OS 设备编写的，可应用于这些设备。运行版本 4.xx 和 5.xx 的旧产品也属于适用范围。

概括

身份和访问管理包括确保个人和应用程序在正确的环境中访问系统资源的政策。例如，个人只能与应用程序交互，并且只有应用程序才能访问设备。IAM 可确保长期完整性，例如，密码不会泄露，并且在不再需要时撤销访问权限。

Axis 建议使用 Axis 的设备管理应用程序AXIS Device Manager或AXIS Device Manager Extend来设置和管理用于访问设备的应用程序的唯一服务帐户。以下部分进一步详细介绍了 Axis 对视频监控系统中身份和访问管理的建议。

介绍

身份和访问管理 (IAM) 系统负责管理组织内的身份、权限和访问控制。IAM 确保正确的个人和应用程序对正确的系统资源具有正确的访问权限。这是防止未经授权访问的基本网络安全措施。主要挑战之一是长期保持完整性。这包括确保密码和其他机密没有泄露，以及那些不应再拥有访问权限的个人和应用程序确实被撤销了访问权限。

身份和访问管理通常涉及身份验证、授权和特权。

• 身份验证。验证实体是否为其所声称的身份或事物。

• 授权。控制哪些实体被允许执行特定的功能。

• 特权。根据实体被授权执行的操作对其进行分组。Axis 将特权定义为角色。

在整个文档中，使用了用户帐户和服务帐户这两个术语。两者都通过 IAM 注册和管理。

• 用户帐户。用户帐户是个人用来访问应用程序的帐户。

• 服务帐户。服务帐户是应用程序用来访问设备的非人类帐户。服务帐户用于机器对机器通信或当应用程序需要以可信和自动化的方式访问设备时。

使用服务帐号的最佳实践

为了长期保持完整性，建议采用以下服务帐户管理的最佳实践。

• 使用 Axis 的设备管理应用程序AXIS Device Manager或AXIS Device Manager Extend进行服务帐户管理。

• 按照AXIS OS 强化指南中的建议，为每个应用程序访问设备设置唯一的服务帐户。

• 为每个服务帐户选择适当的权限。

• 删除不再使用的服务帐户。

• 避免人员直接访问设备（如果绝对必要，请使用唯一的临时服务帐户），可以按照AXIS OS 强化指南中的建议禁用 Web 界面。

• 确保密码复杂度高以避免帐户泄露，请参阅AXIS OS 强化指南中的建议。

下图直观地展示了设备中访问管理的最佳实践。

场景 A

人员 A 无权直接访问 AXIS 设备 人员 A 有权访问 AXIS 设备管理器应用程序 人员 A 使用 ADM 在 AXIS 设备中为 ADM 创建服务帐户 人员 A 使用 ADM 为视频管理应用程序创建服务帐户

场景 B

B 无法直接访问 AXIS 设备 B 有权访问视频管理应用程序 B 使用视频管理应用程序在 AXIS 设备上执行视频管理任务

使用设备中的用户账号时，设备面临以下风险：

• 未经授权的人员访问设备

• 不同设备中的授权级别错误

• 重复使用用户帐户凭证导致无法进行审计

• 随着设备数量的增加，可扩展性较差

不同的站点和组织可以有不同的策略，包括密码策略。系统的设置应适应这些策略。通常，每个应用程序都应该有自己的设备凭据。如果密码在设备中重复使用，Axis 建议经常轮换密码。

授权和账户权限

Axis 设备支持管理员、操作员和查看者角色，并具有不同的授权级别。Axis 建议为有权访问设备的管理应用程序设置一个管理员帐户。此帐户对于每个应用程序应是唯一的，并且不可共享。理想情况下，此帐户的密码应由管理应用程序本身生成，并且对所有人都保密。

如果需要直接访问设备

某些配置可能不受应用程序本身支持，可能需要通过设备 Web 界面进行。Axis 建议通过 Axis 设备管理应用程序提供的无缝访问来访问 Axis 设备 Web 界面。

如果有充分理由允许直接访问设备，Axis 建议使用临时服务帐户模拟和受限访问权限。应在设备上创建一个新的服务帐户，并赋予其执行所需操作的适当角色。一旦不再需要直接访问，应删除此服务帐户。

传统访问程序（默认用户和默认密码）

从历史上看，在出厂默认状态下，Axis 设备的 VAPIX 和 ONVIF 接口已激活，以便连接到它们的客户端快速轻松地开箱即用地访问网络。这意味着客户端（例如应用程序或视频管理系统）可以通过匿名 ONVIF 调用以及默认 VAPIX 用户“root”（使用默认密码“pass”）访问 Axis 网络设备，而无需在 Axis 网络设备上配置任何内容。

更新的访问程序（默认用户没有默认密码）

VAPIX 和 ONVIF 接口已被禁用，并且“root”VAPIX 用户密码不再设置为出厂默认状态。这意味着，如果不为 VAPIX 用户“root”设置密码，客户端将无法再访问或配置开箱即用的设备。

新的访问程序已在以下 AXIS OS 版本中实施：

• 版本 5.51.6

• 版本 6.50.4（2016 LTS）

• 版本 8.40.3（2018 LTS）

• 版本 9.40.1 及更高版本

此外，新的更新程序已在上述平台版本之外的单个产品版本中推出，例如：

• 1.65.x

• 1.8xx

• 5.75.x

• 6.53.x

• 6.55.x

• 7.15.x

现代访问程序（无默认用户）

在 AXIS OS 11.6 及更高版本中，默认 VAPIX 用户“root”已从 Axis 设备的出厂默认状态下删除，现在可以在出厂默认状态下创建自定义命名的 VAPIX 用户。

匿名接口调用

无需身份验证（=匿名）的接口调用仍可用于设备识别目的。Axis 设备在出厂默认状态下可通过其 HTTP 响应标头进行识别，当进行 VAPIX 或 ONVIF API 调用时，该标头设置为“AXIS-Setup:vapix”，如下所示：

HTTP/1.1 401
Unauthorized Date: Thu, 19 Sep 2019 18:15:20 GMT
Server: Apache/2.4.39 (Unix) OpenSSL/1.1.1c
Axis-Setup: vapix

激活 VAPIX 和/或 ONVIF 接口

可以使用以下方法激活 Axis 设备中的 VAPIX 和/或 ONVIF 接口：

• 当设置初始 VAPIX 用户密码时，VAPIX 界面就会激活，可以通过 VAPIX 系统设置 API（如 VAPIX 库中所述 ）或在安装向导过程中使用 Axis 设备的 Web 界面进行设置。

• 只有在激活 VAPIX 接口后才能激活 ONVIF 接口。此后，可以通过设备的 Web 界面创建 ONVIF 用户来激活 ONVIF 接口。

• AXIS 操作系统版本	Web 界面配置路径
  < 7.10	设置 > 系统选项 > 安全 > ONVIF
  ≥7.10	设置 > 系统 > ONVIF
  ≥10.9	系统 > ONVIF

• 此外，还可以使用 ONVIF Profile S 规范创建 ONVIF 用户。创建 ONVIF 用户的 API 调用示例如下：

POST /vapix/services HTTP/1.1
<SOAP-ENV:Envelope xmlns:wsdl=""
xmlns:xs=""
xmlns:tds=""
xmlns:xsi=""
xmlns:xsd=""
xmlns:onvif=""
xmlns:tt=""
xmlns:SOAP-ENV="">
<SOAP-ENV:Body>
<tds:CreateUsers xmlns="">
<User>
<tt:Username>admintt:Username>admin>
<tt:Password>admintt:Password>admin>
<tt:UserLevel>Administratortt:UserLevel>Administrator>
</User>
</tds:CreateUsers>
</SOAP-ENV:Body></SOAP-ENV:Envelope>

密码强度指示器

具有 AXIS OS 7.20 或更高版本的 Axis 设备支持密码强度指示器，当通过 Web 界面创建或修改用户帐户密码时，该指示器可见。它指示所选密码的强度是弱、中还是强，并提供有关如何增强密码的建议。该指示器遵循 Dropbox 开发的 ZXCVBN 算法。有关设置设备密码的更多信息，请参阅 AXIS OS 强化指南。

我忘记了密码，该怎么办？

无法恢复丢失或忘记的 Axis 设备访问凭证。需要将 Axis 设备重置为出厂默认设置，才能使用新的访问凭证重新配置它。

在本节中，您可以了解成功和失败的登录尝试如何根据所使用的网络协议记录在 Axis 设备的日志系统中。始终建议配置一个远程系统日志服务器，Axis 设备可将其系统日志发送到该服务器。这将确保日志可以保存和查看一段合适的时间，而不会在设备本身重新启动或恢复出厂设置后被删除。

SSH

FTP

RTSP 协议

HTTP(S) 协议

*需要从Plain Config > System启用访问日志参数。
**仅使用正确用户名的登录尝试才会被记录。此日志消息仅适用于 AXIS OS 10.4 及更高版本。

IP 过滤***

***Axis 设备中的 IP 过滤是网络第 2 层 Linux 内核功能，可根据配置的规则阻止网络包。如果不适合的源 IP 地址试图访问 Axis 设备，则不会执行身份验证，因为网络传输在第 2 层网络上被阻止，而身份验证在更高级别的应用程序层上执行。在IP 过滤部分的Plain Config > Network中启用 VAPIX 参数后，可以创建 IP 过滤的相应日志。

预防DoS攻击****

****PreventDosAttack 可以从Plain Config > System启用，并且只会记录不成功的登录尝试，并在源 IP 地址被阻止时相应地记录。

用户管理配置
从 AXIS OS 10.9 开始，与用户配置相关的更改将记录在系统日志中，因此可以发送到远程系统日志服务器。在 AXIS OS 中，VAPIX 和 ONVIF 用户通过拥有自己的管理界面和访问权限而分开。下表说明了在对用户管理配置进行某些更改时会出现哪些日志消息：

AXIS OS 7.30 或更高版本

运行 AXIS OS 7.30 及更高版本的 Axis 设备可以配置为自动阻止来自网络中客户端（IP 地址）的 HTTP/HTTPS 请求。在一定时间内，一定数量的身份验证会失败。此功能可以帮助避免和保护 Axis 设备免受暴力攻击，或无意中模仿类似行为的网络客户端的攻击。可以在Plain config > System中配置暴力延迟保护中配置暴力延迟保护。

AXIS OS 11.5 或更高版本

使用 AXIS OS 11.5 或更高版本时，使用下面的配置示例 1 默认启用暴力破解延迟保护。

通常，允许的页面/站点数量越少，保护就越安全。使用暴力延迟保护会大大增加猜测密码的时间。下面可以找到一些迹象。请注意，始终建议配置强密码。

*实际速率可能有所不同，取决于产品性能。

尝试从之前被识别为威胁的网络客户端访问 Web 界面将导致HTTP 403 禁止响应。

此外，Axis 设备会在系统日志中内部记录以下内容：

参数说明

配置示例

• 示例 1：一秒钟内登录尝试失败 20 次后，客户端 IP 地址将被阻止 10 秒。此配置是默认配置，可提供灵活的安全性，在一定程度上会考虑知名授权客户端的登录尝试失败。

• 示例 2：一秒钟内登录尝试失败 10 次后，客户端 IP 地址将被阻止 10 秒。建议将此配置用于非常严格且安全性较高的系统，因为几次登录尝试失败就会阻止客户端。

关于签名操作系统
签名操作系统是一项功能，旨在确保仅上传和使用经过验证的受信任软件到 Axis 设备。在本节中，您可以阅读有关技术细节，以确保选择正确的更新和降级路径以避免出现问题。有关签名操作系统功能的一般信息，请参阅Axis 产品中的网络安全功能白皮书。

Axis 从 AXIS OS 8.30.1 开始对其软件进行签名。在 AXIS OS 9.20.1 发布之前，设备仍会接受未签名和签名的软件以实现向后兼容性。在 AXIS OS 9.20.1 发布后，签名的操作系统已完全激活，Axis 设备将只接受由 Axis 签名的软件。这意味着无法回滚或降级到低于 AXIS OS 8.30.1 的版本，这是 Axis 最初开始对设备软件进行签名的版本。

• 问题：我的设备运行的是 AXIS OS 9.10.1，我想降级到 AXIS OS 8.40 LTS。这可行吗？
  回答：可以，这可行。

• 问题：我的设备运行 AXIS OS 9.20.1，我想降级到 AXIS OS 8.20.1 或更低版本，因为我的 VMS 要求我这样做以保持向后兼容性。这样可以吗？
  回答：降级将失败。设备将拒绝未签名的版本，它将继续运行 AXIS 9.20.1。为了执行此类降级，您需要使用 AXIS OS 8.30.1 作为网关分两步降级。因此，首先从 9.20.1 -> 8.30.1 -> 8.20.1 或更低版本。请注意，Axis 一般不鼓励降级到较旧的、不受支持的 AXIS OS 版本。

故障排除
如何确定升级因未签名的操作系统而失败？ 如果用户尝试上传未签名的版本，则当设备软件升级因签名的操作系统而失败时，摄像机的日志文件中将显示以下消息之一：

[ERR] fwmgr: Unknown firmware domain
[ERR] fwmgr: Image has no signature.
[ERR] fwmgr: No custom firmware certificate for camera group 'xxx'.

Axis 采取积极措施实施 ACAP 应用程序签名，与行业最佳实践保持一致，以实现安全软件交付。此外，它预计未来可能会通过立法予以执行，包括欧盟网络安全弹性法案、欧盟无线电设备指令和行政命令 14028。因此，从 AXIS OS 12.0 开始，默认情况下客户只能在 Axis 设备上安装已签名的 ACAP 应用程序。只有当设备主动配置为接受未签名的 ACAP 应用程序时，才可以安装未签名的 ACAP 应用程序。将设备配置为接受未签名的 ACAP 应用程序会降低设备的安全性，但在开发期间或在您开发和运行自己的 ACAP 应用程序时，它可能很有用。不建议运行未签名的 ACAP 应用程序。

这给最终客户带来什么好处？

签署的 ACAP 表明 Axis 与开发 ACAP 的合作伙伴建立了 TIP 关系。通过检查 ACAP，最终客户可以看到 TIP 合作伙伴是谁。供应商标签下的合作伙伴名称相当于 Axis CRM 记录中的公司名称。因此，签署过程可确保合作伙伴的验证、可追溯性和可问责性。此过程使最终客户能够验证其 ACAP 应用程序。

从网络安全方面来看，它有什么好处？

签名过程可确保 ACAP 在 Axis 设备上运行时仅需要 Axis 批准的访问权限和特权。经过签名过程的 ACAP 将仅在 Axis 设备上运行有限的、已批准的访问权限。此外，通过对 ACAP 应用程序进行签名，可确保应用程序的内容从发布到安装都不会被篡改，从而实现安全的软件交付。

Axis 是否正在审查软件质量、安全开发实践或对已签名的 ACAP 执行 QA 测试？

不，Axis 不对经过签名流程的 TIP 合作伙伴 ACAP 是否经过 QA 测试或是否根据行业最佳实践的安全开发流程进行开发承担任何责任。此责任完全由提供 ACAP 应用程序的 TIP 合作伙伴承担。

我们允许谁签署 ACAP？

只有 TIP 合作伙伴才被允许这样做。这表明 Axis 已经对其合作伙伴进行了审查。

Axis 是否也为非 TIP 合作伙伴提供 ACAP 签名功能？

对于需要签名功能的非 TIP 合作伙伴，我们还将执行审查流程。请使用此链接申请访问权限。

ACAP 签名在技术上如何运作？

在 ACAP 应用程序签名过程中，会在应用程序包末尾添加加密签名。作为整体安全软件交付架构的一部分，安装 ACAP 应用程序时，Axis 设备会验证该签名。

Axis 何时会强制执行 ACAP 签名？

为了符合安全软件交付实践，Axis 将仅接受签名的 ACAP 应用程序，并且无法在其设备上禁用此安全控制。Axis 的目标是通过下一代 AXIS OS 操作系统实现这一目标，该系统计划于 2026 年下半年及以后推出AXIS OS 13.0。

安全密钥库通常是指专用的硬件加密计算模块，可提供对加密操作、证书和密钥的保护。支持 AXIS Edge Vault的 Axis 产品 具有最多两个安全密钥库，并具有相应的安全认证，即根据联邦信息处理标准获得的通用标准 CC EAL6+ 和/或 CC EAL4+ / FIPS 140-2 2 级认证，这可能是某些客户和用例的监管要求。这两个安全密钥库在加密操作、证书和密钥方面提供相同级别的保护。此外，一些片上系统包括所谓的可信执行环境 (TEE)。根据安装要求，TEE 可能是一个不错的选择，因为它的加密操作延迟较低。

下表概述了 Axis 设备中密钥库的加密功能。

1. 对于无硬件保护的安全密钥库的产品而言，这是遗留的。

2. 支持 AXIS OS 5.50 及更高版本，.PFX 和 .P12 证书/私钥容器的最大大小限制为 102400 字节，但运行 AXIS OS 9.20 及更低版本的设备除外，这些设备仅支持最大文件大小为 10240 字节。

3. AXIS OS 10.10 中添加了对 ECC 的支持，但以下需要手动接收软件更新的产品除外：HWID 79C：AXIS Q3527-LVE、HWID 7DA：AXIS Q6074、HWID 7D9：AXIS Q6074-E、HWID 7B1：AXIS Q6075、HWID 7B0：AXIS Q6075-E、HWID 7B2：AXIS Q6075-C、HWID 7B3：AXIS Q6075-S、HWID 7FA：AXIS Q6075-SE 和 HWID 7C7：AXIS Q9216-SLV。

4. 从 AXIS OS 10.1 及更高版本开始，已添加对不带 TPM 模块的 Axis 设备的 ECC 加密支持。

5. 不支持 RSA 3072 密钥长度。

6. Axis 设备在创建自签名证书 (SSC) 或发出证书签名请求 (CSR) 时生成的私钥的最大密钥位大小。在首次启动期间，Axis 设备将自动生成自签名证书，在 AXIS OS 10.1 之前，该证书的私钥位大小为 1536 位。从 AXIS OS 10.1 及更高版本开始，大小为 2048 位。

7. 支持 AXIS OS 11.6 或更高版本。

默认设备证书
Axis 设备包含允许加密 HTTPS 和其他安全连接的证书，以便能够安全地访问设备并继续进行设备的初始配置。根据 Axis 产品的硬件功能及其运行的 AXIS OS 版本，适用不同的默认配置。

自签名证书
支持 TPM 模块或软件密钥库的 Axis 产品仅在首次启动时生成自签名证书。Axis 设备附带预安装的自签名证书，以便能够通过加密的 HTTPS 连接访问设备并继续进行设备的初始设置。由于首次启动证书是由设备自签名的，因此它不适合提供针对网络和应用程序的身份验证或真实性。因此，当 HTTPS 连接是设备的首选连接类型时，Axis 建议从设备中删除自签名证书并将其替换为组织中受信任的服务器证书。

Axis 设备 ID (IEEE 802.1AR)
配备Axis Edge Vault 的Axis 设备配备有 Axis 设备 ID。Axis 设备 ID 符合 IEEE 802.1AR 标准，可以使用 Axis 设备 ID 证书链进行验证。您可以在我们的公钥基础设施存储库中下载并查找有关 Axis 设备 ID 证书链的更多信息。在使用 Axis 设备 ID CA 证书作为信任锚之前，请记住根据提供的 sha256 哈希验证下载的证书。

CA 证书
CA 证书是 Axis 设备用来验证/核实网络中其他服务器真实性的证书。这意味着，要在 Axis 设备的 CA 证书部分上传的 CA 证书需要满足以下条件之一：

• 具有basicConstraints扩展的X509v3 CA 证书CA:TRUE*

• X509 v1 自签名证书

• 设置了keyCertSign位但没有设置basicConstraints 的keyUsage属性扩展

• Netscape 证书类型扩展表明它是 CA 证书

*CA:TRUE 或 CA:FALSE 属性还决定是否允许 CA 证书签署其他证书。

证书签名请求 (CSR)
证书签名请求 (CSR) 可以从 Axis 设备中现有的证书创建。PEM 格式的证书请求可以发送到证书颁发机构 (CA) 进行签名/验证。签名证书从 CA 返回后，需要将其上传到 Axis 设备并与原始证书请求进行比较/验证。如果所有信息均正确无误，证书上传将成功结束。但是，如果在颁发 CSR 和上传证书之间发生系统更改，则该过程可能会中断。证书上传失败的可能原因包括：

• 同时，Axis 设备已恢复出厂默认设置

• 用于签名请求的证书已在 Axis 设备中被删除或更改

AXIS OS 默认启用以下最常见的安全相关 HTTP(S) 标头，以提高出厂默认状态下的整体最低网络安全性。自定义 HTTP 标头 VAPIX API 可用于配置更多 HTTP(S) 标头。有关更多信息，请参阅Vapix 库。

AXIS OS 10.1 及更高版本
在 AXIS OS 10.1 或更高版本中，引入了以下默认 HTTP(S) 标头以提高整体最低网络安全级别：

AXIS OS 11.5 及更高版本
在 AXIS OS 11.5 或更高版本中，除了指定策略以告知浏览器哪些内容源对于 Axis 设备是可信的之外，还添加了内容安全策略 (CSP) HTTP(S) 响应标头。此标头可用于防范各种类型的攻击，包括跨站点脚本 (XSS) 和数据注入攻击。

当浏览器收到网页时，它会检查 CSP 标头以确定允许为该页面加载哪些内容源。如果尝试从不在列表中的源加载任何内容，浏览器将阻止它。

除了 CSP 之外，还添加了 Referrer-Policy 标头。HTTP 请求可能包含可选的 Referrer 标头，该标头指示发出请求的来源或网页 URL。Referrer-Policy 标头定义了在 Referrer 标头中提供哪些数据。

下面的示例展示了 AXIS OS 11.5 设备及其默认配置的 HTTP(S) 标头。

停用 Axis 设备时，应执行出厂默认设置。恢复出厂默认设置后，大多数数据都会通过覆盖/清理被删除。有关更多信息，请参阅AXIS OS 强化指南。

本节的目的是鼓励和使合作伙伴、系统集成商和最终用户在配置 Axis 设备中的常规视频流设置时考虑他们的个人设置，以确保最佳性能和用户体验。

一般注意事项
Axis 视频设备根据其所用系统的期望要求以及 Axis 设备本身的规格提供视频流。以下信息提供了有关 Axis 设备中视频流的工作原理以及需要考虑的设置的基础和理解。

关于视频流客户端
Axis 设备本身可识别多种类型的客户端，并向其编码和分发视频流。客户端可分为内部和外部，并根据请求向其提供视频流。请参阅以下每个类别的示例：

内部客户

• (S)FTP/HTTP(S) MJPEG 图像上传的操作规则

• (S)FTP/HTTP(S) 视频片段上传的操作规则

• 将视频录制到 SD 卡和网络共享的操作规则

• 连续录制至 SD 卡或网络共享

• （分析）请求视频流或 MJPEG 图像的 ACAP

外部客户

• 在网页界面上观看视频

• 通过安全远程访问观看视频

• 实时查看并录制至 AXIS Companion

• 实时查看并录制至 AXIS Camera Station

• 实时查看并录制至第三方视频管理系统

唯一编码流的数量告诉我们 Axis 设备正在编码多少个不同的视频流。此信息可在 5.70 或更高版本的设备的服务器报告中的“当前（缓存）流的快照”部分中找到。对于 AXIS OS 10.7 或更高版本的设备，此信息可在“所有正在运行的流的快照”部分中找到。唯一编码流的数量受流属性的影响，如下例所示。请注意，插图取自图形用户界面，以便更好地说明用例。

示例 1：在此示例中，Axis 设备正在对总共三个独特的编码视频流进行编码。这些视频流在一个流属性（分辨率）上有所不同，由于分辨率不同，Axis 设备需要分别对每个视频流进行编码。

示例 2：在此示例中，Axis 设备正在对总共两个独特的编码视频流进行编码。这两个视频流的一个流属性不同 - 帧速率 (fps) - 由于帧速率不同，Axis 设备需要分别对每个视频流进行编码。

结论：Axis 设备需要根据其流属性对视频流进行编码。如果流属性（例如 fps、压缩、VideoKeyFrameInterval (GOP) 等）因请求的视频流而异，则 Axis 设备必须对单独的视频流进行编码。这可能会影响视频流性能，通常建议优化设置以尽可能减少视频流数量。

注意：从 AXIS OS 10.8 开始，单个唯一编码视频流最多可以同时分发到八个物理网络客户端。如果更多物理网络客户端需要拉取相同的视频流，我们建议改为实施多播视频流，或者让其他客户端请求另一个唯一编码视频流。

分布式视频流的数量是指网络中实际物理网络客户端的数量以及它们请求的视频流数量。例如，可以从同一物理网络客户端的 AXIS Camera Station 和 Axis 设备的 Web 界面进行视频流传输。

此信息可在 9.80 及更高版本的设备的服务器报告中的“当前传出 RTP 流的快照”部分获得。此部分列出了分布式流的数量及其目标 IP 地址的关系。分布式流声明为视频流数量：物理网络客户端数量 的比率。

示例 1： 在此示例中，分布式流的数量为 2:2，因为 Axis 设备总共将两个视频流传输到两个物理网络客户端。

示例 2：在此示例中，分布式流的数量为 3:2，因为 Axis 设备总共向两个物理网络客户端传输三条视频流。观察到物理网络客户端 1正在请求唯一编码流 1两次。

结论：Axis 设备可以将一个或多个视频流传输到相同或多个物理网络客户端。物理网络客户端由其请求的视频流数量及其在网络中的目标 IP 地址定义。

注意：从 AXIS OS 10.8 开始，单个唯一编码视频流最多可以同时分发到八个物理网络客户端。如果更多物理网络客户端需要拉取相同的视频流，我们建议改为实施多播视频流，或者让其他客户端请求另一个唯一编码视频流。

通过以上信息，我们现在可以解释唯一编码流的数量与分发到物理网络客户端的流的数量之间的关系。

示例 1：在此示例中，两个物理网络客户端分别请求一个唯一的编码流。这会导致向每个物理网络客户端分发一个流。

示例 2： 在此示例中，Axis 设备正在编码两个唯一流并将它们分发到三个物理网络客户端。

示例 3：在此示例中，Axis 设备正在编码单个唯一流并通过多播将其分发到两个物理网络客户端。请注意，此设置将只产生单个分布式流，因为两个物理网络客户端将从多播地址接收流。因此，与下面的示例 4 相比，多播具有消耗更少网络带宽的优势。

示例 4：在此示例中，Axis 设备正在编码单个唯一流，并通过单播将其分发到两个物理网络客户端。与示例 3 相比，此设置将要求 Axis 设备消耗更多的网络带宽，因为必须分发两次唯一流。

另一个重要设置是可以接收视频流的客户端（=查看者）的最大数量。所有 Axis 设备中的数量设置为 10 或 20，具体取决于设备的配置和性能。

这意味着 Axis 设备要么向网络中的 10 或 20 个不同的物理客户端提供单个视频流，要么 Axis 设备向网络中的一个客户端提供 10 或 20 个不同的视频流。接收视频客户端（物理和软件实例）的数量是主要限制。可以通过读取以下 VAPIX 参数来获取此配置：https://ip-address/axis-cgi/param.cgi?action=list&group=Image.MaxViewers

实际上，任何时候都不应达到最大数量。如果越来越多的客户端需要访问视频流，建议使用多播等方式。

在“最大客户端数量”中，我们了解到设备最多可以提供多少个视频流是有限制的，我们用视频流的数量来解释这一点。除了视频流，Axis 设备还可以提供音频和元数据流。虽然视频和音频流的用途是不言而喻的，但元数据的用途可能并非如此。借助元数据流，应用程序或 VMS 可以监听 Axis 设备的事件流，并对其做出反应，并创建自己的事件和操作。

下面是一个 Axis 设备的示例，该设备当前正在将每种类型的流传输到单个物理网络客户端。观察在Media下传输的是哪种类型的流。

总而言之，最大客户端数量分别应用于视频、音频和元数据流，这意味着如果将参数MaxViewers配置为 20，则 Axis 设备总共可以提供 20 x 视频、20 x 音频和 20 x 元数据流。

性能考虑
虽然 Axis 设备可以同时编码多个视频流，但如果编码“太多”唯一视频流，这在某种程度上会对性能产生影响。在下面的示例图中，您可以观察到 Axis 设备可以以 30 fps 的全帧速率传输五个唯一视频流。如果需要编码第六个唯一视频流，则将超出产品的性能，导致 Axis 设备以降低的帧速率均匀传输所有请求的视频流。如果超出产品的性能，Axis 设备将不会优先以全帧速率传输任何视频流，而是将性能瓶颈分散到所有视频流上。

_{请注意，上述示例是一个过于简单的说明，Axis 设备能够以全帧速率传输的并发视频流数量在很大程度上取决于许多因素，例如请求的帧速率、分辨率、压缩、比特率等等。建议在与设备安装环境完全相同或接近的环境中针对所需行为测试设备。}

最大视频流比特率
典型的 1080p 和 30 fps 的 H.264 视频流的比特率约为 1 Mbit/s 到 10 Mbit/s，具体取决于场景、照明条件、运动和许多其他因素。为了避免网络瓶颈和 Axis 设备所连接的底层网络基础设施的拥塞，视频流的最大比特率有硬性上限，并且每个视频流总计不能超过 50 Mbit/s。

除了上述信息之外，下面列出的 Axis 设备还具有必须考虑的其他视频缓冲区配置。这些设备具有有限数量的静态配置的所谓视频源缓冲区。视频源缓冲区的数量取决于设备。

对于单传感器产品，视频源缓冲区可以提供至少一个唯一视频流，而对于多传感器产品，视频源缓冲区可以提供至少四个唯一视频流。因此，包含视频源缓冲区配置的 Axis 设备受到其可以提供的唯一视频流数量的限制。

2022 年之前发布的产品
在 2022 年之前发布的 Axis 设备中，最多有 4 个视频源缓冲区。

• 主源缓冲区：主源缓冲区静态配置为设备的最大默认分辨率，并且只能以该特定分辨率提供唯一的视频流。这由“固定”一词表示。

• 第二个源缓冲区：第二个源缓冲区是低分辨率视频缓冲区，适用于依赖较低分辨率的应用程序，例如（分析）ACAP 或运动 jpeg 图像。此缓冲区提供各种可能的分辨率。

• 第三个源缓冲区：第三个源缓冲区是一个高分辨率视频缓冲区，可提供设备的最大分辨率或接近该分辨率的分辨率。除此之外，支持 HDMI 的设备在启用时会分配第三个源缓冲区 HDMI 视频流。此缓冲区提供各种可能的分辨率。

• 第 4 个源缓冲区：第 4 个源缓冲区是一个高分辨率缓冲区，可提供设备的最大分辨率或接近该分辨率的分辨率。此缓冲区提供各种可能的分辨率。

2022 年及以后发布的产品
在 2022 年及以后发布的 Axis 设备中，至少有四个视频源缓冲区可用于编码视频，例如 H26X 和 MJPEG。HDMI 不会影响编码视频的可用源缓冲区数量。获取 YUV 的 ACAP（通常是分析应用程序）不会影响编码视频的可用源缓冲区数量。

• 固定源缓冲区（主）：固定源缓冲区静态配置为设备的最大默认分辨率，并且只能以该特定分辨率提供唯一的视频流。这由“固定”一词表示。

• 第二个源缓冲区：第二个源缓冲区是低分辨率视频缓冲区，适用于依赖较低分辨率运动 JPEG 图像的应用程序。此缓冲区提供各种可能的分辨率。

• 第 N 个源缓冲区：第 N 个源缓冲区是高分辨率视频缓冲区。此缓冲区提供各种可能的分辨率。

示例说明

总之，此设备可以提供 2 个最大分辨率为 1920x1080 的独特视频流 — 一个最大分辨率为 1280x960，另一个最大分辨率为 720x576。如独特编码流中所述，服务器报告中的信息可以帮助识别哪些视频源缓冲区已被使用且饱和，哪些仍然可用。

示例 1：在此示例中，Axis 设备正在提供以下唯一视频流，这意味着主、第 3 和第 4 个视频源缓冲区正在使用中。请求另一个分辨率为 1920x1080 且 fps = 15 的唯一视频流将失败，因为没有可用的视频源缓冲区来提供此请求。

示例 2：在此示例中，Axis 设备正在提供以下唯一视频流，这意味着主视频源缓冲区和第三个视频源缓冲区正在使用中。例如，请求另一个分辨率为 1920x1080 且 fps = 15 的唯一视频流将失败，因为没有可用的视频源缓冲区来提供此请求。但是，请求分辨率为 800x600 的唯一视频流缓冲区可以由第四个源缓冲区提供。

Axis 设备规格
下面列出了所有 Axis 设备及其视频源缓冲区配置：

* 分辨率仅适用于鱼眼概览，与其他去扭曲视图模式不同。在 AXIS M3047-P 和 AXIS M3048-P 上以相同分辨率拉动视图区域 1 和 2 时，可以使用最高分辨率 (1920x1440) 或较低分辨率（如 640x480 和 480x360）。
** 每个源缓冲区可以以相应的分辨率提供两个视频流。例如：总共 4x1080p，其中 2x1080p 从主源缓冲区提供，2x1080p 从第 4 个源缓冲区提供，或者 2x4K 从主源缓冲区提供，2x1080p 从第 4 个源缓冲区提供。
*** 该设备是具有 4 个物理传感器的多传感器设备，这意味着每个缓冲区能够为每个物理传感器提供一个视频流。示例：AXIS Q6010-E 上每个传感器的 1 个视频流分辨率为 2592x1944，使主源缓冲区上总共有 4 个视频流。
**** 第 4 个源缓冲区仅分配给四视图，这意味着即使不使用四视图，第 4 个源缓冲区也无法进一步使用。
***** 这些视频源缓冲区能够为每个缓冲区提供两个唯一的视频流，而不仅仅是一个。

故障排除
您可以参考每个设备的发行说明来了解所有支持的分辨率。您还会在具有硬件限制的设备的发行说明中注意到以下行：“5.40.5：L35026 不同配置的视频流数量受硬件限制”。

一个典型的第一手迹象表明，由于视频源缓冲区已超出限制，Axis 设备无法提供额外的唯一视频流，即 Axis 设备的 Web 界面中出现“503 服务不可用”错误消息。

其他应用程序（如 AXIS Companion 或 AXIS Camera Station）会向用户显示“摄像机错误”。服务器报告和 Axis 设备附带的日志消息是调试此类情况的绝佳工具。

下面列出了一些常见的日志消息，这些消息会在视频源缓冲区饱和且 Axis 设备无法提供所请求的唯一视频流时出现

故障排除示例 1：在此示例中，请求唯一视频流失败，因为根本没有可用的视频源缓冲区来支持另一个唯一的 1024x768 视频流。日志消息指示哪个源缓冲区已被占用，以及在请求新的唯一视频流时哪个源缓冲区仍可使用。

<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: Unable to find available stream configuration for resolution 1024x768
<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: buffer[0]: fixed 1920x1080, current 1920x1080
<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: buffer[1]: max 720x576, current 0x0
<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: buffer[2]: max 1920x1080, current 1280x960
<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: buffer[3]: max 1280x720, current 0x0
<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: Failed to allocate a source buffer


故障排除示例 2：与上述示例类似，由于没有可用的视频源缓冲区来提供另一个唯一的 800x600 视频流，因此请求唯一的视频流失败。

<INFO> Jan 4 11:22:03 axis-0040 /usr/bin/ambad[960]: Unable to find available stream configuration for resolution 800x600
<INFO> Dec 30 21:15:36 axis408 /usr/bin/ambad[1051]: buffer[0]: fixed 800x600, current 800x600
<INFO> Dec 30 21:15:36 axis408 /usr/bin/ambad[1051]: buffer[1]: max 720x576, current 0x0
<INFO> Dec 30 21:15:36 axis408 /usr/bin/ambad[1051]: buffer[2]: max 800x600, current 800x600
<INFO> Dec 30 21:15:36 axis408 /usr/bin/ambad[1051]: buffer[3]: max 800x600, current 800x600
<INFO> Dec 30 21:15:36 axis408 /usr/bin/ambad[1051]: Failed to allocate a source buffer

故障排除示例 3：具有较新 AXIS OS 版本的 Axis 设备以略有不同的方式打印其日志消息，如本例所示。

[ INFO ] /usr/bin/ambad[1035]: Failed to allocate a source buffer (1280x720, channel 1): No matching buffer available
[ INFO ] /usr/bin/ambad[1035]: stream[1]: encoding [ 1920x1080, 25/1 fps, buffer_id 2, state active, channel 1 ]
[ INFO ] /usr/bin/ambad[1035]: stream[2]: encoding [ 640x480, 25/1 fps, buffer_id 3, state active, channel 1 ]
[ INFO ] /usr/bin/ambad[1035]: stream[3]: encoding [ 320x240, 25/1 fps, buffer_id 1, state active, channel 1 ]
[ WARNING ] monolith: Failed to allocate 1280x720 H264 stream on channel 1: Failed to allocate stream resources: Failed to add stream
[ ERR ] monolith[925]: Could not set caching pipeline to playing.

建议
可以给出以下一般建议来降低复杂性、配置时间并优化 Axis 设备的视频流设置：

• 利用流配置文件以简单的方式打包流及其配置，以优化流和配置处理

• 上传 MJPEG 图像或视频片段的操作规则应利用用户配置的流配置文件

• 如果可能，使用相同的流设置（=流配置文件）进行实时查看和录制

• 请记住，一旦激活操作规则，操作规则就会分配视频源缓冲区。这意味着，即使 Axis 设备应该每天向 FTP 服务器发送一次图像，也会导致视频源缓冲区被分配一整天

• 请记住，（分析）ACAP（例如 AXIS 视频运动检测或第三方 ACAP）可能会消耗低分辨率缓冲区进行检测，例如 320x240

• 请记住，访问 Axis 设备的 Web 界面时默认启用的“自适应分辨率/流式传输”功能将请求根据用户物理显示器的实际分辨率大小定制的唯一视频流。这可能会消耗视频源缓冲区

• 避免启用匿名查看器。除了网络安全方面，启用匿名查看器还允许对 Axis 设备进行不受控制的访问，并且可能超出视频源缓冲区配置

• 避免使用可疑的设置，例如请求两个具有相同分辨率、帧速率但具有不同压缩率（如 30 和 35）的独特视频流。与消耗视频源缓冲区的成本相比，图像质量的差异可以忽略不计

从实际事件发生到显示在客户端屏幕上的时间称为延迟。延迟包括摄像机中的图像处理、网络传输和客户端上的解压缩。有关延迟的更多信息，请参见此处。在某些情况下，希望将此延迟保持在尽可能低的水平。要减少摄像机上的处理时间，有几种可能的方法。请注意，这些设置将影响所有视频流。

• 选择帧率较高的拍摄模式。高帧率拍摄模式下的处理速度通常比低帧率拍摄模式更快。

• 启用 LowLatencyMode（设置 > 普通配置 > 选择组：ImageSource > ImageSource / I0 / 传感器 > 低延迟模式：开启）。在此模式下，图像处理量会减少以降低延迟。缺点是图像会变得更嘈杂，尤其是在低光照条件下和移动物体周围。这将根据摄像机型号和设置将延迟减少多达 30 - 200 毫秒。根据 Axis 设备，此功能在 AXIS OS 9.80.1 或更高版本上可用。

使用多播传输视频流允许网络中的不同视频客户端访问单个视频流，Axis 设备会将该视频流分发到特定的多播地址和端口。使用多播作为视频流传输方法的好处之一是，Axis 设备只需向网络中的特定地址发送单个或两个视频流，即可保持其系统和资源消耗较低。这也是一种高效利用网络基础设施的方式，因为许多不同的视频客户端可以从多播地址检索视频流，而不是每个视频客户端都从 Axis 设备提取单独的视频流。网络中提供、分发和接收多播的方式实际上可以最大限度地减少网络基础设施及其所有相关客户端的带宽消耗。想象一下，在一个运行着 5,000 多台 Axis 设备的系统中，这会有多大的不同。

Axis 设备支持在多播场景中以多种方式传输视频。在以下部分中，我们将从流式传输的角度介绍多播，而不考虑多播的一般机制及其在网络中的路由方式，也不考虑不同形式多播的基础知识。

无论所需的传输方法是什么（即多播或单播），正确初始化视频客户端和 Axis 设备所需的初始 RTSP 协议通信都非常相似，只是多播模式下的视频客户端指定了这一点而不是单播场景。

下面我们将逐步介绍典型的 RTSP 构建细节。有关更多详细信息，请参阅“多播详解”中的实际网络跟踪。

步骤 1：视频客户端
视频客户端启动 RTSP DESCRIBE 并向 Axis 设备发出信号，使用 RTSP URL 中给出的指定流参数准备视频流，并共享其相应的会话描述协议 (SDP) 文件，其中包括有关如何解码视频流的信息。

DESCRIBE rtsp://172.25.201.100:554/axis-media/media.amp?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30 RTSP/1.0
CSeq: 2
User-Agent: OmnicastRTSPClient/1.0
Accept: application/sdp
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="00000450Y2804646c4d9f7d3175fa496417b9c4e7aa39a2", uri="rtsp://172.25.201.100:554/axis-media/media.amp?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30", response="7a2e2dcad7618b36479ec76e252bc1c3"

第 2 步：Axis 设备
Axis 设备验证请求并与视频客户端共享相应的 SDP 文件。请注意，在任意源多播模式下，不会共享任何特定于多播的网络参数。在特定于源的多播模式 (SSM) 下，情况有所不同。

RTSP/1.0 200 OK
CSeq: 2
Content-Type: application/sdp
Content-Base: rtsp://172.25.201.100:554/axis-media/media.amp/
Server: GStreamer RTSP server
Date: Thu, 11 Feb 2021 06:51:12 GMT
Content-Length: 1063

v=0
o=- 17136744296195211872 1 IN IP4 172.25.201.100
s=Session streamed with GStreamer
i=rtsp-server
t=0 0
a=tool:GStreamer
a=type:broadcast
a=range:npt=now-
a=control:rtsp://172.25.201.100:554/axis-media/media.amp?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:50000
a=rtpmap:96 H265/90000
a=framerate:30
a=fmtp:96 sprop-vps=QAEMAf//AUAAAAMAgAAAAwAAAwCcEJAk;sprop-sps=QgEBAUAAAAMAgAAAAwAAAwCcoAPAgBEHy55CbkSg8quTgoKC8IAAAAMAgAAAAwKE;sprop-pps=RAHANzwEbJA=
a=ts-refclk:local
a=mediaclk:sender
a=recvonly
a=control:rtsp://172.25.201.100:554/axis-media/media.amp/stream=0?videocodec=h265&adui=0&resolution=1920x1080&camera=1&compression=30&fps=30
a=transform:1.000000,0.000000,0.000000;0.000000,1.000000,0.000000;0.000000,0.000000,1.000000

步骤 3：视频客户端
然后，视频客户端继续定义适当的传输方法（如多播）、多播 IP 地址、流媒体端口和 TTL。这是 RTSP 构建中的重要步骤，视频客户端实际上可以指定所需的传输方法。请注意，为了使 Axis 设备接受特定于视频客户端的多播网络参数，必须启用Plain Config > Network中的VAPIX 参数RTSP Allow Client Transport Settings 。如果未设置此参数，Axis 设备可能会忽略这些参数并在Plain Config > Network > R0中提供自己的配置集。

SETUP rtsp://172.25.201.100:554/axis-media/media.amp/stream=0?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30 RTSP/1.0
CSeq: 3
User-Agent: OmnicastRTSPClient/1.0
Transport: RTP/AVP;multicast;destination=224.16.17.51;port=47806-47807;ttl=64
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="00000450Y2804646c4d9f7d3175fa496417b9c4e7aa39a2", uri="rtsp://172.25.201.100:554/axis-media/media.amp/stream=0?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30", response="48cf0f723aca20f6530e79ecb966ec0a"

步骤 4：Axis 设备
Axis 设备会验证请求，如果成功，则会使用完全相同的网络参数回复视频客户端，以准备即将到来的会话。

RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;multicast;destination=224.16.17.51;ttl=64;port=47806-47807;mode="PLAY"
Server: GStreamer RTSP server
Session: f2imQtCHhuoH2FbW;timeout=60
Date: Thu, 11 Feb 2021 06:51:12 GMT

步骤 5：视频客户端
然后，视频客户端最终通过 RTSP PLAY 向 Axis 设备发出信号，根据之前握手的网络和视频流参数按照约定开始视频流。

PLAY rtsp://172.25.201.100:554/axis-media/media.amp?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30 RTSP/1.0
CSeq: 4
Session: f2imQtCHhuoH2FbW
User-Agent: OmnicastRTSPClient/1.0
Range: npt=0.000-
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="00000450Y2804646c4d9f7d3175fa496417b9c4e7aa39a2", uri="rtsp://172.25.201.100:554/axis-media/media.amp?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30", response="d015b378a8a1000c964d6c48d1883d1f"

步骤 6：Axis 设备
Axis 设备通过发送 RTSP OK 来确认请求，并向视频客户端提供有关视频流如何在定义的多播网络参数下暂时可用的信息。为了向视频客户端发出视频流开始的信号，Axis 设备指定了第一个 RTP 包的序列号和初始 RTP 时间戳，以便客户端能够预期并处理视频流的正确开始。

RTSP/1.0 200 OK
CSeq: 4
RTP-Info: url=rtsp://172.25.201.100:554/axis-media/media.amp/stream=0?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30;seq=24067;rtptime=417717697
Range: npt=now-
Server: GStreamer RTSP server
Session: f2imQtCHhuoH2FbW;timeout=60
Date: Thu, 11 Feb 2021 06:51:12 GMT

SETUP rtsp://172.25.201.100:554/axis-media/media.amp/stream=0 RTSP/1.0
CSeq: 5
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="0003628fY51859629beb31964cb09d13947338e39266e77", uri="rtsp://172.25.201.100:554/axis-media/media.amp/", response="78be3d448c752bda36df4b82baf4ecf9"
User-Agent: LibVLC/3.0.11 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;multicast;port=55810-55811

RTSP/1.0 200 OK
CSeq: 5
Transport: RTP/AVP;multicast;destination=224.225.226.227;ttl=5;port=50000-50001;mode="PLAY"
Server: GStreamer RTSP server
Session: xvIhEhZ3W5QpueEZ;timeout=60
Date: Thu, 11 Feb 2021 06:28:05 GMT

在任意源多播 (ASM) 中，在初始 RTSP 构建期间共享会话描述协议 (SDP) 文件后，多播网络参数会进行握手，但在源特定多播模式下并非如此。在 SSM 中，多播网络参数在 Axis 设备中预先配置，并在共享 SDP 文件时与请求视频客户端共享。这样做的好处是，请求视频客户端可以加入多播组，并且只过滤视频客户端感兴趣的多播流量。这可以通过在加入多播组时应用源特定过滤器来实现。

SSM 最常用于的场景是多个 Axis 设备将视频流传输到同一个多播地址但使用不同的端口。通过任意源多播连接的视频客户端将接收来自所有流传输设备的多播流量，而请求源特定多播的视频客户端将能够过滤掉不需要的流量。除此之外，SSM 还允许可靠地规划多播路由/路径转发，因为我们知道多播是如何在网络中切换和路由的。

源特定多播需要在 Axis 设备上进行预配置，以配置所需的多播网络参数。您可以在VAPIX 库中找到有关如何为源特定多播配置 Axis 设备的信息，但也在下面进行了说明。没有特定的设置来启用或禁用源特定多播，但可以从Plain Config > Network为每个单独的视频源配置需要提前定义的源特定多播网络参数。以下是典型的示例配置：

步骤 1：视频客户端
与任意源多播模式相比，SSM 模式需要不同的流媒体 URL 来向 Axis 设备发出需要特定源多播的信号。

DESCRIBE rtsp://172.25.201.100:554/axis-media/ssm/media.amp?camera=1 RTSP/1.0
CSeq: 4
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="000006c7Y356087c783187c3a95be0ca315f5fa0cd57ddc", uri="rtsp://172.25.201.100:554/axis-media/ssm/media.amp?camera=1", response="3226806a8c988f0d473df291e8c7ffb8"
User-Agent: LibVLC/3.0.11 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

第 2 步：Axis 设备 Axis 设备
与请求视频客户端之间共享的 SDP 文件包括源特定的多播网络参数，视频客户端必须了解这些参数才能相应地加入多播组并过滤正确的流量。

RTSP/1.0 200 OK
CSeq: 4
Content-Type: application/sdp
Content-Base: rtsp://172.25.201.100:554/axis-media/ssm/media.amp/
Server: GStreamer RTSP server
Date: Thu, 11 Feb 2021 07:01:42 GMT
Content-Length: 749

v=0
o=- 9871677480407248934 1 IN IP4 172.25.201.100
s=Session streamed with GStreamer
i=rtsp-server
c=IN IP4 225.226.227.228/5
t=0 0
a=tool:GStreamer
a=type:broadcast
a=range:npt=now-
a=control:rtsp://172.25.201.100:554/axis-media/ssm/media.amp?camera=1
a=source-filter: incl IN IP4 225.226.227.228 172.25.201.100
m=video 60000 RTP/AVP 96
b=AS:50000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-sets=Z2QAKa0AxSAeAIn5ZuAgIDSDxIio,aO48sA==
a=ts-refclk:local
a=mediaclk:sender
a=recvonly
a=control:rtsp://172.25.201.100:554/axis-media/ssm/media.amp/stream=0?camera=1
a=framerate:30.000000
a=transform:1.000000,0.000000,0.000000;0.000000,1.000000,0.000000;0.000000,0.000000,1.000000

步骤3：视频客户端
由于视频客户端提前知道将要使用的多播网络参数，因此客户端可以将其包含在RTSP SETUP请求中。

SETUP rtsp://172.25.201.100:554/axis-media/ssm/media.amp/stream=0?camera=1 RTSP/1.0
CSeq: 5
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="000006c7Y356087c783187c3a95be0ca315f5fa0cd57ddc", uri="rtsp://172.25.201.100:554/axis-media/ssm/media.amp/", response="89e1cf3338144d096723df0b10864cab"
User-Agent: LibVLC/3.0.11 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;multicast;port=60000-60001

步骤 4：AXIS设备
AXIS设备根据在 R0 中完成的预配置，验证并使用正确的多播网络参数进行响应。

RTSP/1.0 200 OK
CSeq: 5
Transport: RTP/AVP;multicast;destination=225.226.227.228;ttl=5;port=60000-60001;mode="PLAY"
Server: GStreamer RTSP server
Session: 06yirClN7xQCtW8q;timeout=60
Date: Thu, 11 Feb 2021 07:01:42 GMT

第 5 步：视频客户端
然后，请求的视频客户端向 Axis 设备发出信号，开始按照商定的流和网络参数进行视频流传输。

PLAY rtsp://172.25.201.100:554/axis-media/ssm/media.amp?camera=1 RTSP/1.0
CSeq: 6
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="000006c7Y356087c783187c3a95be0ca315f5fa0cd57ddc", uri="rtsp://172.25.201.100:554/axis-media/ssm/media.amp/", response="c19526013f73f3db72cd4fca98ec1c40"
User-Agent: LibVLC/3.0.11 (LIVE555 Streaming Media v2016.11.28)
Session: 06yirClN7xQCtW8q
Range: npt=0.000-

步骤 6：Axis 设备
Axis 设备通过发送 RTSP OK 确认请求，并向视频客户端提供有关视频流如何在定义的多播网络参数下暂时可用的信息。为了向视频客户端发出视频流开始的信号，Axis 设备指定了第一个 RTP 包的序列号和初始 rtp 时间戳，以便客户端能够预期并处理视频流的正确开始。

RTSP/1.0 200 OK
CSeq: 6
RTP-Info: url=rtsp://172.25.201.100:554/axis-media/ssm/media.amp/stream=0?camera=1;seq=21707;rtptime=3563678630
Range: npt=now-
Server: GStreamer RTSP server
Session: 06yirClN7xQCtW8q;timeout=60
Date: Thu, 11 Feb 2021 07:01:42 GMT

始终多播不是网络多播模式，而是针对无法以上述任一方式（即通过 ASM 或 SSM）执行正确 RTSP 和/或多播设置的视频客户端的特定适应性调整。在始终多播模式下，Axis 设备静态配置为将视频流式传输到特定的多播地址和端口，并直接开始向其流式传输，无论网络中是否有视频客户端实际从该特定 Axis 设备请求视频。最重要是，RTSP 不用于连接，而是请求视频客户端将进行 HTTP 调用以检索会话描述协议 (SDP) 文件，以便了解并连接到视频流连接的多播地址和端口。可以在 Axis 设备的Plain Config > Network中为每个单独的视频源配置始终多播。

示例 1：设备将仅将视频流传输到多播地址 224.225.226.227 和视频端口 50000。如果在此处输入视频端口 0，则 Axis 设备将选择在RTP > 结束端口和起始端口配置中定义的下一个可能端口。

示例 2：设备将视频流传输到多播地址 224.225.226.227 的端口 50000，音频流传输到多播地址 239.216.121.37 的端口 51000。请注意，还可以在始终多播配置文件中调整视频流参数。如果要使用其他流参数，例如每秒 15 帧的帧速率和 15 的压缩率，则可以按以下方式调整该字段：videocodec=h264&fps=15&compression=15。否则将使用当前配置的默认流设置。

保存上述设置后，无论是否有客户端请求视频流，Axis 设备都会立即开始向配置的多播地址和端口进行流式传输。客户端可以通过 SDP 文件访问此多播流，SDP 文件确定视频流设置，以便视频客户端了解如何播放视频。可以使用http://ip-address/axis-cgi/alwaysmulti.sdp?camera=1 访问SDP 文件，其中 camera=1 映射到 R0。可以通过alwaysmulti.sdp找到此类 SDP 文件的示例找到此类 SDP 文件的示例。下面是说明该过程的网络跟踪示例。

步骤 1：视频客户端
视频客户端已向 Axis 设备请求 SDP 文件。请注意，客户端未提及任何流媒体参数或多播网络参数，因此必须在发出请求之前在 Axis 设备上执行此配置，如前面的示例所述。

GET /axis-cgi/alwaysmulti.sdp?camera=1 HTTP/1.1
Host: 172.25.201.100
Accept: */*
Accept-Language: en_US
Authorization: Basic cm9vdDpwYXNz
User-Agent: VLC/3.0.11 LibVLC/3.0.11
Range: bytes=0-

步骤 2：Axis 设备
Axis 设备在 R0 中查找当前配置，然后初始化并将 SDP 文件发送到请求的视频客户端。这样做是为了传递所需的信息，以便视频客户端可以在预先配置的多播地址和端口访问正在进行的多播流。此时不再交换单播通信，视频客户端将切换到指定的多播网络参数以访问流。

HTTP/1.1 200 OK
Date: Thu, 11 Feb 2021 06:14:25 GMT
Server: Apache/2.4.46 (Unix) OpenSSL/1.1.1g
Cache-Control: no-cache, no-store, max-age=0
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Transfer-Encoding: chunked
Content-Type: application/sdp

v=0
o=- 1188340656180883 1 IN IP4 172.25.201.100
s=Session streamed with GStreamer
i=rtsp-server
t=0 0
a=tool:GStreamer
a=type:broadcast
a=control:*
a=range:npt=now-
m=video 50000 RTP/AVP 96
c=IN IP4 224.225.226.227/5
b=AS:50000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-sets=Z2QAKa0AxSAeAIn5ZuAgIDSDxIio,aO48sA==
a=control:stream=0
a=ts-refclk:local
a=mediaclk:sender
a=framerate:30.000000
a=transform:1.000000,0.000000,0.000000;0.000000,1.000000,0.000000;0.000000,0.000000,1.000000

_{*在 VLC 中，您可能需要在“高级首选项”下的 RTP/RTSP/SDP 解复用器设置中启用“通过 RTSP 强制多播 RTP” 。
**为了让 FFMPEG 和 VLC 通过 HTTP 身份验证访问和检索 SDP 文件，必须在“普通配置”>“网络”>“身份验证策略”中配置 HTTP 基本身份验证。
***这些示例说明了视频客户端如何仅通过使用文件 SDP 即可连接到多播流，而无需与 Axis 设备建立任何进一步的连接。假设 Axis 设备上没有进行任何配置更改，用户只需下载一次 SDP 文件，然后就可以使用 SDP 开始播放视频。VLC 和 FFMPEG 是能够这样做的客户端的示例。}

典型的多播场景由三部分组成：源、多播网络基础设施和接收者。

Axis 设备是将流发送到多播地址的源。多播地址是在协商期间由客户端和设备商定的。网络基础设施必须由网络专业人员配置。路由器之间需要运行多播路由协议（如 PIM），最后一跳路由器和接收客户端之间需要运行 IGMP 协议。此外，需要在第 2 层交换机上启用 IGMP 侦听，以避免多播流量泛滥。

在某个 VLAN 和 IP 地址网络内传输流量的网络称为交换网络，因为不需要第 3 层 IP 路由。让我们从基本设置开始，并假设网络交换机未正确配置为处理多播流量。您将看到类似于下图的情况，即由带有客户端计算机和 Axis 设备的少量交换机组成的交换网络。在所有客户端中，只有客户端 2感兴趣并向 Axis 设备请求多播视频流。由于此时网络交换机未正确配置，多播流量（本应只从 Axis 设备通过穿越交换机流向客户端 2）将被泛洪到网络中的所有交换机和客户端，无论它们是否有兴趣接收流量。

让我们看看正确配置并启用 IGMP（Internet 组管理协议）的同一网络。IGMP 是一种协议，可帮助网络基础设施学习和了解谁在向哪个目的地传送多播流量，以避免多播泛滥到不感兴趣的客户端。要配置网络以避免多播泛滥，只需在以下示例配置中为 IGMP 配置主交换机（即第 2 层交换机）即可：

全局配置
ip igmp snooping querier 地址 172.25.201.10
ip igmp snooping querier 查询间隔 15
ip igmp snooping querier

通过这样做，第 2 层交换机将向所连接的网络设备发送 IGMP 查询，以便找出哪些设备有兴趣接收和发送多播包。

网络设备将以“加入”消息进行响应，以表明它们参与多播相关流量。

网络交换机将监听并学习此流量，以便正确地将网络包切换到适当的目的地。下图中，只有客户端 2通过多播向 Axis 设备请求视频。

正确配置后，网络交换机现在也能够跨交换机交换数据包。下图中，我们已切换客户端，因此客户端 1从之前为客户端 2提供服务的同一 Axis 设备请求多播视频流。结果将是正确交换的网络流量通过网络到达正确的目的地。

路由网络中的多播在处理多播流量的方式上与交换方案没有本质区别。客户端在不同 VLAN 和 IP 网络之间交换网络流量的网络称为路由网络，因为需要使用第 3 层 IP 路由技术来传输网络流量。让我们重新使用与交换网络方案中相同的网络拓扑。唯一但重要不同是，与客户端 2和3以及Axis 设备相比，客户端 1位于不同的 VLAN 和 IP 地址网络中。我们假设我们已经执行了前面提到的相同 IGMP 配置。作为参考，请参见下文：

全局配置
ip igmp snooping querier 地址 172.25.201.10
ip igmp snooping querier 查询间隔 15
ip igmp snooping querier

如您所见，客户端 2已使用多播从 Axis 设备请求视频，并且由于我们已将正确的 IGMP 配置应用于第3 层交换机，因此此设置可以完美运行。但是来自另一个 IP 网络的客户端 1也希望通过多播接收视频，这无法正常工作，因为多播在设计上不会跨不同的 IP 网络路由。因此，为了允许多播流量跨第 3 层网络路由，我们必须启用 IP 多播路由并使用协议独立多播 (PIM) 等协议。最基本和最简单的用例是利用 PIM 的被动模式，如下面建议的配置所示：

全局配置
ip multicast-routing

配置VLAN 201
接口Vlan201
描述LAN1客户端
ip地址172.25.201.10 255.255.255.0
ip pim positive
!

配置VLAN 202
接口Vlan202
描述LAN2客户端
ip地址172.25.202.10 255.255.255.0
ip pim positive
!

应用此配置后，多播可在不同网络间正确路由。从位于 VLAN 201 中的Axis 设备到位于 VLAN 202 中的客户端 1 。

在本节中，我们将仔细研究视频流方面的 VAPIX 和 ONVIF 图像旋转配置，其处理方式根据 AXIS OS 版本的不同而不同。

AXIS OS 8.50 及更高版本
在添加对 ONVIF 配置文件 T 的支持后，Axis 设备中的图像旋转处理已完全在 VAPIX 和 ONVIF 之间分离。这意味着两种协议都有用于图像旋转配置的专用参数，并且一种协议的图像旋转参数不会影响另一种协议，反之亦然。对于 VAPIX，这是通过图像旋转参数Image.I0.Appearance.Rotation进行的配置，可以在 Web 界面中的图像设置中进行配置，也可以直接通过 VAPIX HTTP 请求进行配置。对于 ONVIF，它是在 Web 界面中的 ONVIF 媒体流配置文件中进行配置，或者直接通过配置文件中旧设备的脚本编辑器进行配置：/etc/ws/onvif/media/media.conf。

例外：对于支持ImageSource.I0.SourceRotation=yes 的Axis 设备，上述情况不成立。在这些设备上，图像旋转参数通过 VAPIX 全局设置，ONVIF 将相应地进行调整。

AXIS OS 8.40 及更低版本
通过 Web 界面中的图像设置或直接通过 VAPIX HTTP 请求配置图像旋转参数Image.I0.Appearance.Rotation将影响 VAPIX 和 ONVIF 视频流。除非 ONVIF 流配置文件设置中另有规定，否则 ONVIF 视频流将适应通过 VAPIX 配置的相同图像旋转。

示例配置

VAPIX 从设备 Web 界面配置图像旋转：

从设备 Web 界面进行 ONVIF 图像旋转配置：

通过脚本编辑器进行 ONVIF 图像旋转配置：

在本节中，您可以了解在流式传输视频和从 Axis 设备下载单个图像时接收时间戳信息的不同方法。此元数据信息可用于业务应用程序中的处理，例如，当接收有关商店中有多少人经过某个区域的元数据时。它还可以用于需要与第三方视频客户端进行时间同步的其他用例

以下网络跟踪可用于测试下面描述的内容。

RTP 时间戳位于 RTP 包的有效负载中，用作单调时间戳，可用于识别视频流的特定帧。根据视频流构建过程中计算出的时钟速率，RTP 时间戳预计会从一帧到另一帧逐渐增加。

时钟频率取决于视频流的图像频率。在此示例中，视频流每秒包含 30 帧，这意味着计算出的时钟频率将为 3000。这反过来意味着单调 RTP 时间戳将在每个新的 I 帧或 P 帧上增加 3000，如以下两个屏幕截图所示。

当视频流开始时，Axis 设备将让外部视频客户端知道第一帧（I 帧）的初始 RTP 时间戳，如下所示。这允许接收视频客户端识别丢失的帧，并可用于在视频流正在进行时测量 RTP 时间戳漂移。

I 帧和/或 P 帧可以由多个 RTP 包组成。如您所见，属于同一 I 帧的所有包都具有相同的唯一时间戳，而随后的每个 P 帧都有自己的与时钟速率相对应的时间戳。因此，对于每个唯一的 I 帧或 P 帧，RTP 时间戳都会逐渐增加。

以下网络跟踪可用于测试下面描述的内容。

如果 Axis 设备与视频客户端之间发生 RTCP 通信，则会交换所谓的RTCP 发送方和接收方报告。这些报告包含有关正在进行的 RTSP/RTP 流中的时钟同步的重要信息。作为视频发送方的 Axis 设备会发送RTCP 发送方报告，其中包括当前 RTP 流时间和当前 NTP 时间戳（UTC）。

另一方面，接收视频客户端与 Axis 设备交换所谓的RTCP 接收器报告，以回复先前发送的信息，并允许相互进行时间同步检查并补偿 Axis 设备和视频客户端本身之间的时间漂移。RTCP 发送方和接收方报告每隔几秒钟就会在正在进行的视频流中交换一次。

以下网络跟踪可用于测试下面描述的内容。

所谓的 SEI 帧只有在启用此 VAPIX 参数时才可用：Image.I0.MPEG.UserDataEnabled=yes。此处Image.I0对应于默认视频源，如果有多个视频源可用，则需要为每个视频源启用该参数。

SEI 帧在每个 I 帧之前从 Axis 设备发送，并包含有用的时间戳信息。如VAPIX 库中所述，SEI 帧包含 Linux 纪元时间的时间戳信息，精度为 1/100ms（十六进制格式）。

出于调试目的，我们建议使用以下在线转换器：

• https://www.epochconverter.com/hex

• https://www.rapidtables.com/convert/number/hex-to-decimal.html

可以使用以下 VAPIX 请求从 Axis 设备下载单个图像：http://ip-address/axis-cgi/jpg/image.cgi。从 Axis 设备接收的 JPEG 图像从 JPEG 标头本身或 EXIF 标头数据提供有价值的时间戳信息，具体取决于 Axis 设备的 AXIS OS 版本。

AXIS OS 8.40 及更高版本
从 AXIS OS 8.40 开始，EXIF 标头数据可用于获取时间戳信息，如下面的屏幕截图所示。出于调试目的，可以使用简单的 Windows 应用程序（例如 Linux OS 中的 JPEGSnoop 或 EXIF）来获取 EXIF 标头提供的信息。有关 JPEG 和 EXIF 时间戳标头信息的更多信息，请访问以下来源：Exif 2 规范。

AXIS OS 6.50 及更低版本
由于旧版 AXIS OS 不提供 EXIF 标头数据，因此可以使用纯 JPEG 注释标头来接收时间戳信息。可以使用 HxD 编辑器等应用程序获取十六进制格式的时间戳信息，然后可以使用 Linux EPOCH 时间转换器将其转换为人类可读的时间格式，例如https://www.epochconverter.com/hex。对于 1/100 秒信息，可以使用简单的十六进制到十进制转换器，例如https://www.rapidtables.com/convert/number/hex-to-decimal.html。

这些示例图像可用于测试：

一般来说，Axis 设备中的元数据包括三种不同的类型：事件、PTZ 和分析元数据。元数据封装在可从 Axis 设备请求的 RTP/TCP 流中。让我们仔细看看可用的不同类型的元数据。

事件和 PTZ 元数据
多年来（从 AXIS OS 5.40 开始），Axis 设备已经能够将事件和 PTZ 元数据发送到接收第三方应用程序，例如视频管理系统。仅当 Axis 设备的状态发生变化时，才会发送事件和 PTZ 元数据，这意味着不会发送恒定流。事件元数据的一些常见示例是手动触发器、虚拟输入和存储相关触发器。对于机械 PTZ 摄像机，元数据包括定位数据以及有关何时达到 PTZ 预设或 Axis 设备何时移动的信息。

分析元数据
从 AXIS OS 9.50 及更高版本开始，分析相关元数据可用。与上面描述的事件和 PTZ 元数据流不同，分析元数据流会不断从 Axis 设备发送到接收客户端，即使场景中没有发生任何事情。分析元数据的典型示例是来自 Axis 分析应用程序 (ACAP) 的运动或对象检测，例如 AXIS 视频运动检测或 AXIS 对象分析。在此处阅读有关 AXIS 对象分析的更多详细信息。

可以在此处下载示例网络跟踪，其中说明了如何传输元数据信息。通过使用 Wireshark，可以在 RTP/TCP 流中搜索和查找特定的元数据事件，如下面的屏幕截图所示。

在以下部分中，您可以阅读有关如何开始和执行进一步测试的更多信息。

通过打开使用 TCP 传输协议的 RTSP 流，可以从 Axis 设备接收元数据信息。自主开发的 AXIS Metadata Monitor 可用作从 Axis 设备请求元数据的简单测试工具。您可以在此处下载 AXIS Metadata Monitor并将其安装在计算机上，以便连接到网络中的 Axis 设备。以下是从 Axis 设备接收元数据事件的 RTSP 请求示例列表。

可以将其他参数（例如camera=2到camera=9）添加到上述请求中，例如从不同的视频通道接收元数据事件。当 Axis 设备支持多个视频源或配置了不同的视图区域时，这很有用。在下面的示例中，我们使用 AXIS Metadata Monitor 通过使用上述 RTSP 请求之一以及 Axis 设备的 IP 地址及其访问凭据连接到 Axis 设备。

如您所见，Axis 设备正在使用其当前可用的所有元数据信息和状态响应 RTSP 请求。测试传入元数据事件的一种简单方法是切换 Web 界面中的手动触发器。

另一种选择是使用预先安装的 Axis 分析应用程序 (ACAP) 之一，例如 AXIS 视频运动检测，在 Axis 设备前触发测试警报或运动，以获取基于运动检测/分析的元数据事件。

在下面，您将看到 Axis 设备中可用的常见元数据和设备事件的（非完整）表格。可用事件的类型和数量取决于 Axis 设备的硬件/软件功能，其中一些功能包括：

• 机械和/或数字 PTZ

• 机械和/或数字 I/O

• 音频输入和音频输出功能

• 安讯士分析应用程序 (ACAP)，例如 AXIS 视频运动检测、AXIS 对象分析等。

• 第三方应用程序

从 AXIS OS 10.11 开始，可以在 Axis 设备中选择专用的分析生成器，也可以同时启用多个分析元数据生成器。在后端，Axis 设备可以配置为使用“Axis 视频运动跟踪器”（这是自 AXIS OS 9.50 以来常用的生成器）或使用较新的“Axis 对象分析”生成器来生成分析元数据。“Axis 对象分析”生成器提供了一些有价值的扩展和更多与分析数据相关的信息，例如更详细的对象分类（人脸、车牌号等），这在法医搜索场景中很有用。

从 AXIS OS 10.11 开始，可以使用 (安全) WebSocket 协议订阅元数据流。有关 Axis 元数据流的更多常规信息，请参阅通过 RTSP 传输元数据。

在下面的示例中，我们使用了Google Chrome 浏览器的WebSocket King 扩展，但还有许多其他客户端可支持 WebSocket 通信。

步骤 1：使用已安装扩展程序的浏览器登录您的 Axis 设备。

步骤 2：在 WebSocket King 扩展中，连接到：

• HTTP：ws：//IP/vapix/ws-data-stream？sources=events

• HTTPS：wss://IP/vapix/ws-data-stream?sources=events

请注意，如果您在步骤 1 中使用 HTTPS，则需要在 WebSocket King 扩展中使用相同的连接。

步骤 3：发送以下请求以接收所有事件：

{
  "apiVersion": "1.0",
  "method": "events:configure",
  "params": {
    "eventFilterList":[
      {
        "topicFilter":""
      }
    ]
  }
}

还可以订阅特定的topicFilter，例如：“topicFilter”：“tns1:Device/tnsaxis:IO/VirtualInput”。请参阅元数据事件示例以获取更多主题示例。此外，还可以订阅特定的端口。下面您可以看到虚拟输入端口 47 的示例。

{
  "apiVersion": "1.0",
  "method": "events:configure",
  "params": {
    "eventFilterList":[
      {
        "topicFilter":"tns1:Device/tnsaxis:IO/VirtualInput",
        "contentFilter":"boolean(//SimpleItem[@Name=\"port\" and @Value=\"47\"])"
      }
    ]
  }
}

步骤 4：事件将根据设置的过滤器开始流式传输。

步骤 5 ：下面是在 Axis 设备上切换手动触发器的示例，该示例反映在元数据流中。

在本节中，您可以阅读有关 Axis 设备用于网络上不同服务的常用网络端口的信息。

默认启用

取决于配置

*根据 RFC 6056 在预定义的端口号范围内自动分配。更多信息可以在这里找到。
**此网络流量没有关联的 TCP 或 UDP 端口号，因为它们与上面的传输层相关联。

***IEEE 802.1X 仅在支持 Axis Device ID 的设备上默认启用。

要了解哪些 Axis 产品支持 Axis 设备 ID，请转到Axis 产品选择器并选择网络安全下的Axis 设备 ID。

网络时间协议 (NTP)

网络时间协议用于同步互联网或本地网络中的计算机时钟。版本 4 (NTPv4) 是当前版本，由 RFC 5904 描述。它与 NTPv3 和所有以前的版本完全兼容，旨在支持 IPv6 协议和动态服务器发现。NTP 使用 UDP 作为通过端口 123 的传输协议，这意味着无法保证数据包的递送。

Axis 设备使用两种实现作为其当前平台，具体取决于 AXIS OS 版本。

与 OpenNTPD 相比，Chrony 是网络时间协议的较新实现。它在网络拥塞或网络连接断断续续的挑战性情况下表现良好。Chrony 可以更快地同步系统并快速适应突然的时钟速率变化。此外，Chrony 支持网络时间安全 (NTS) (RFC 8915)，因此设备获取的时间来自可信来源。您可以在此处找到有关 Chrony 的更多信息找到有关 Chrony 的更多信息。

NTP 使用分层结构，其中多个以不同级别和精度（=层）运行的 NTP 服务器相互同步，以向网络设备提供准确的时间同步。为此，网络中为本地网络设备提供时间的 NTP 服务器应始终与层次结构中较高级别的一个或多个 NTP 服务器同步，以避免时间波动并提高时间准确性。但是，如果没有其他 NTP 服务器可用，则可以在网络中以独立模式本地操作 NTP 服务器。有关 NTP 协议如何工作的更多信息可以从公共资源（例如Wikipedia ）获得。

网络时间安全 (NTS)

具有 AXIS OS 11.1 或更高版本的 Axis 设备支持网络时间安全。NTS 允许设备从受信任的来源获取时间。NTS 是一种使用传输层安全性 (TLS) 和带关联数据的认证加密 (AEAD) 为 NTP 的客户端-服务器模式提供加密安全性的机制。

NTS 由两个协议组成：

1. NTS 密钥交换 (KE)：通过传输层安全性 (TLS) 在 NTP 客户端和服务器之间交换必要的密钥。密钥交换完成后，TLS 通道将关闭。NTP 客户端还知道要查询哪个 NTP 服务器。

2. NTP 认证：NTP 客户端向 NTP 服务器查询时间，双方通过 TLS 握手的结果对 NTP 时间同步数据包进行认证。

关于 NTS 的更多公开信息可在此处找到。

开放NTPD

以下部分说明了使用 OpenNTPD 进行完整 NTP 同步期间所采取的步骤。此网络跟踪可用作以下步骤的参考，并显示从第一阶段到 Axis 设备与配置的 NTP 服务器完全同步的完整 NTP 同步。

• 第 1 阶段：从初始时间查询开始。
  从 Axis 设备到 NTP 服务器的第一次时间同步是“通用同步”，这意味着 NTP 服务器提供的任何时间都将被 Axis 设备视为系统时间。第 1 阶段通常在配置 Axis 设备以与 NTP 服务器同步（启用 NTP）时、Axis 设备重新启动时或启动升级（这会导致 Axis 设备重新启动）时启动。

• 第 2 阶段：第 1 阶段之后是整合阶段，其中 Axis 设备针对 NTP 服务器发出大量时间同步请求，间隔为 6 秒 - 60 秒 + 10% 随机化，以便进一步与 NTP 服务器对齐，确保时间同步紧密。时间同步的数量取决于 NTP 协议的准确性和信任度，但通常需要 5-15 次时间同步。

• 阶段 3：阶段 3 被视为常规操作模式。查询间隔将在第 2 阶段之后稳定在 30 - 1500 秒 + 10% 随机化之间。如果在正常操作模式下时间差增加，设备将缩短间隔以更频繁地同步以补偿这一点。如果时间漂移非常小，两次同步之间的间隔将更大。请注意，同步状态正在更改为“是”，这表明 Axis 设备与配置的 NTP 服务器时间同步良好。

克罗尼

以下部分说明了使用 Chrony 进行完整 NTP 同步期间所采取的步骤。

• 阶段 1：阶段 1 从初始时间查询开始。Chronyd 将以 4-8 个请求开始，以便更快地进行时钟的首次更新。一旦它从 NTP 服务器获得回复，它就会计算当前系统时间与 NTP 服务器时间戳之间的时间差。在我们的实施中，我们将 Chrony 设置为在调整大于 0.1 秒时步进系统时钟，但仅限于自 chrony 启动以来的第一次时钟更新。如果时间差小于 0.1 秒，Chrony 将进入斜率模式。Chrony 允许斜率调整时间的最大速率设置为 83333.333ppm（1/12 秒）。时间同步后，您将在网页上看到“是”。

• 第 2 阶段：第 2 阶段被视为通常的操作模式。一旦时间同步，向 NTP 服务器发出的一般查询轮询间隔将设置为 64 秒。大多数 Axis 设备都内置有实时时钟 (RTC)。系统将在启动时从 RTC 复制时钟。为了保持 RTC 的准确性，我们启用了 chronyd，每 11 分钟将系统时间复制到 RTC。请注意，chronyd 不会跟踪 RTC 漂移。chronyd 程序的主要活动之一是计算出系统时钟相对于实时增加或减少时间的速率。每当 chronyd 计算出增加或减少速率的新值时，它都会将该值记录在 /var/lib/chrony/drift 中。这也有助于在下次启动时稳定初始同步。

NTS 同步过程

要配置 NTS，请转到系统 > 日期和时间，然后选择自动日期和时间（手动 NTS KE 服务器）。
您可以输入 NTP KE 服务器的 IP 地址或主机名（确保 DNS 服务器配置正确）。以下是通过 NTS 成功同步时间的示例：

时间同步过程的行为与我们在上面提到的 Chrony 同步过程中提到的行为几乎相同。这里我们主要关注密钥交换和安全部分。

• 第 1 阶段
  Chrony 客户端通过建立 TLS 通道开始与 KE 服务器通信。接下来是密钥交换。在密钥交换过程中，客户端会收到稍后要使用的密钥和 cookie。cookie 包含只有 NTP 服务器才能理解的密钥。KE 服务器还会通知客户端要查询哪个 NTP 服务器。交换完成后，TLS 通道将终止。

• 第 2 阶段
  Chrony 客户端直接联系 NTP 服务器。它使用从第 1 阶段获得的密钥加密查询。该查询中还包含一个 cookie。服务器收到查询后，就知道如何读取查询。服务器将使用签名查询响应客户端。客户端验证传入数据包中的签名，然后设置时间，因为知道它是从正确的服务器发送的。

在 NTP/NTS 时间同步操作期间以及在某些错误情况下（例如，如果 NTP/NTS 服务器运行不正常或无法访问），可以看到来自 Axis 设备的以下常见日志消息。日志消息及其解释提供了有关 NTP/NTS 协议在实践中如何工作的详细信息。此外，在解决 NTP/NTS 协议相关问题时，了解日志消息也是很好的。

使用 AXIS OS 9.40.1 或更高版本，可以在 Web 界面中配置辅助 NTP 服务器，以及通过 VAPIX Time API 配置最多五个 NTP 服务器。设备会尝试与所有已配置的服务器同步。使用 VAPIX Time API，最多可以配置 5 个 NTP 服务器 URL。此外，一个 NTP 服务器 URL 可以解析为多个地址，但每个 URL 只能使用一个“有效”服务器进行同步。因此，如果您配置...

pool.ntp. AND 0.ntp.com，其中pool.ntp.解析为三个地址 [ 146.76.54.5, 146.76.54.56, 146.76.54.5 ]，而0.ntp.com解析为45.32.76.99

...实际使用的 NTP 服务器是第一个 URL 的一个有效且可访问的地址以及第二个 URL 的一个有效且可访问的地址：

（146.76.54.5 或 146.76.54.56 或 146.76.54.5 ） 和 45.32.76.99

NTP 算法确定从第一个池中使用哪个 NTP 服务器。

使用 AXIS OS 11.0 或更高版本时，设置多个 NTP 源时，Chrony 会尝试选择最准确、最稳定的源来同步系统时钟。设置多个 NTS 服务器时也适用此设置。

Axis 公共 NTP 服务器
Axis 公共 NTP 服务器是ntp.，连接到互联网的摄像机可以与其同步时间。

Meinberg NTP 服务器
Meinberg拥有自己的独立 NTP 服务器软件，可安装在 Microsoft Windows 操作系统上，并可与其他 NTP 服务器同步。它还具有独立操作模式，非常适合无需与外界网络连接的独立环境，且操作简单。

Netnod NTS 服务器
Netnod 的 NTP 服务由 PTS 资助，可供任何人免费使用。Netnod 目前提供以下 NTS 服务器。

• nts.netnod.se

• sth1.nts.netnod.se

• sth2.nts.netnod.se

Windows NTP 服务器
按照以下步骤操作，可以将本地 Windows 系统配置为 NTP 服务器。

请注意，默认情况下，Windows 的 NTP 时间精度较低，同步间隔较大，这可能不是实现良好时间精度的最佳方法。
对于 Chrony，Windows NTP 服务器的一个常见问题是它们报告的根分散非常大（例如三秒或更长时间），这导致 chronyd 忽略服务器，因为服务器太不准确。
建议将 Windows NTP 服务器配置为具有更严格和准确的时间精度和同步间隔。有关更多信息，请参阅以下指南：

• Windows 高精度时间

• Windows 高精度时间配置指南

如果您使用 Windows 作为离线安装的 NTP 服务器，Windows NTP 服务器可能会使用本地 CMOS 时钟时间。默认情况下，它将报告 10 秒的根散布。有关如何更改此值的更多信息，请参阅以下指南：

本地时钟分散条目

Windows 时间服务工具和设置

对等时钟层未指定或无效 (0)

Axis 设备发送的时间是多少？
在调试与 NTP 相关的网络问题时，可以观察到 Axis 设备正在向 NTP 服务器传输随机的 64 位时间，以减轻网络安全攻击的风险。这不会对 NTP 时间同步本身的性能或质量产生任何影响，因为 NTP 服务器仍将响应有效时间戳，Axis 设备将把该时间戳应用于其时间。

最大时间差

抵消时钟漂移
如果系统时钟有显著的漂移，Axis 设备的时钟将永远无法与 NTP 服务器实现足够接近的偏移。但是，系统时钟不应该以这种幅度的速率漂移。

QoS 提供了一种方法，可以保证网络上选定流量的特定资源达到一定水平。质量可以定义为，例如，保持带宽水平、低延迟、无数据包丢失等。QoS 感知网络的主要优势可以概括为：

• 能够对流量进行优先级排序，从而允许关键流量在优先级较低的流量之前得到服务

• 通过控制应用程序可使用的带宽量，从而控制应用程序之间的带宽竞争，网络可靠性更高

要在具有 Axis 视频产品的网络中使用 QoS，需要满足以下要求：

• 所有网络交换机和路由器都必须支持 QoS。这对于实现端到端 QoS 功能非常重要

• 使用的 Axis 视频产品必须启用 QoS

假设图 1 中的网络是一个普通（非 QoS 感知）网络。在此示例中，PC1 正在观看来自摄像机 Cam1 和 Cam2 的两个监控视频流，每个摄像机的流速为 2.5 Mbps。突然，PC2 开始从 PC3 传输文件。在这种情况下，文件传输将尝试使用路由器 R1 和 R2 之间的全部 10 Mbps 容量，而视频流将尝试保持其总计 5 Mbps。我们无法再保证分配给监控系统的带宽量，并且视频帧速率可能会降低。最坏的情况下，FTP 流量将消耗所有可用带宽。

现在，假设图 2 中的网络具有 QoS 感知能力并使用 DiffServ 模型（见下文）。路由器 R1 已配置为将可用 10 Mbps 中的 5 Mbps 专用于流式视频。FTP 流量可使用 2 Mbps，HTTP 和所有其他流量最多可使用 3 Mbps。使用这种划分，视频流将始终具有必要的可用带宽。文件传输被认为不太重要，获得的带宽较少，但仍有带宽可用于 Web 浏览和其他流量。请注意，这些最大值仅适用于网络拥塞的情况。如果有未使用的可用带宽，则任何类型的流量都可以使用它。通过使用 QoS，我们允许网络应用程序在同一网络上共存，而不会消耗彼此的带宽。

进一步阅读

有关服务质量标准的进一步阅读和更详细的文档，请参阅以下链接：

• RFC 2475 — 差异化服务架构

• RFC 2597 — 保证转发 PHB 组

• RFC 2598 — 快速转发 PHB

• RFC 3168 — 在 IP 中添加显式拥塞通知 (ECN)

• RFC 1633 — 互联网架构中的集成服务：概述

有几种不同的方式（模型）来实现 QoS。Axis 产品使用 DiffServ 模型，以实现更高的可扩展性和灵活性。请参阅下文了解更多信息。

IntServ 模型
IntServ 模型或集成服务模型使用一种称为 RSVP（预留设置协议）的协议，用于在网络中预留一定的流量质量。在使用之前，IntServ QoS 网络中的每个应用程序都会预留自己的资源，路由器会批准或拒绝该请求。收到预留请求后，路由器需要找到一条可以支持 IntServ 请求的路径以及提供最佳服务的路由。此模型的主要问题是可扩展性。随着网络规模的扩大，连接数据库将增长到巨大的比例，跟踪所有预留将既困难又低效。另一个缺点是该模型缺乏灵活性 – 每种流量将接收的最大资源量是模型中指定的最大值，即使还有其他未使用的资源可用。

DiffServ 模型
差异化服务 (DiffServ) 模型于 1998 年推出。它基于两个主要组件：

• 数据包标记

• 路由器排队规则

DiffServ 网络中的应用程序会标记其流量，以便路由器知道对数据包应用哪种服务。标记是在 IP 标头中完成的，通过设置称为 DSCP（差分服务代码点）的字段来完成的。这是一个 6 位字段，提供 64 个不同的类 ID。每个 DSCP 值代表一个 QoS 类，也称为行为聚合。因此，不同的应用程序可以使用相同的 DSCP 值标记自己的流量。DiffServ 网络的智能是在路由器中设置的，其中特定的 DSCP 值映射到特定的路由行为。此行为称为每跳行为 (PHB)，并使用不同的排队规则在路由器中实现。

DiffServ 模型放弃了 IntServ 中使用的状态概念，路由器以无连接模式运行。这增加了系统的可扩展性，因为每个路由器都独立工作，不知道网络规模和复杂性。此模型也更灵活，因为服务类别没有严格定义。当资源有限时，超过指定最大值的资源可以在可用时自由利用。在 Axis 产品中使用此模型的主要好处是产品标记自己的流量，而不是让 DiffServ 域的边界节点这样做。例如，边界节点中的调节算法无法区分 HTTP 上的视频和 HTTP 上的音频 - 它们只会看到 HTTP，并且可能提供比实际要求低得多的服务级别。要允许 DS 域外的节点对自己的流量进行分类：

• 边界路由器必须正确配置

• 必须将摄像机设置为可信节点

每跳行为 (PHB) 定义路由器对特定流量类别的转发处理。流量类别也称为行为聚合 (BA)。BA 的成员用相同的 DSCP 值标记。建议定义四种 PHB，每种都映射到一个或多个 DSCP 值。

默认 PHB：默认 PHB 提供传统的尽力而为服务。它由 DSCP 值 000000 表示（注意：6 位设置为 0），并且必须在任何 DiffServ 路由器上可用。这是应用于所有非 DiffServ 感知应用程序的转发处理。

类别选择器 PHB：为了保持与旧 TOS 字段定义的向后兼容性，类别选择器 PHB 定义了 xxx000 形式的 DSCP 值。这三位表示服务类型感知网络定义的 IP 优先级。类别选择器 PHB 确保 DiffServ 兼容节点可以与基于 IP 优先级的节点共存。

加速转发：加速转发 (EF) PHB 提供低丢失、低延迟、低抖动和保证带宽的服务，可视为最高优先级行为。VoIP 等应用程序需要这种强大的服务。EF 的建议 DSCP 值为 101110。

保证转发：使用保证转发 (AF)，流量可分为四个不同的类别。每个类别通常分配有特定数量的带宽。

在每个类别中，可以指定三个不同的丢弃优先级值。此值表示在发生拥塞时丢弃数据包的顺序。丢弃优先级较高的数据包将首先被丢弃。这为我们提供了一个 AF 矩阵，因此 AF 通常表示为 AFxy，其中 x 是类别编号，y 是丢弃优先级。下表显示了为 AF PHB 推荐的 DSCP 值。这为我们提供了一个 AF 矩阵，因此 AF 通常表示为 AFxy，其中 x 是类别编号，y 是丢弃优先级。表 1.1 显示了为 AF PHB 推荐的 DSCP 值。

DiffServ域
DiffServ 域 (DS 域) 是根据特定 DiffServ 规范设置的网络，它具有一组映射到某些 PHB 的 DSCP 值。由于 DiffServ 域中的每个路由器都根据 DSCP 值映射转发流量，因此我们只能保证在自己的 DS 域内获得正确的转发处理。一旦数据包离开域，我们就无法再保证其他路由器将如何映射我们的 DSCP 值。传入流量也是如此 - 我们必须重新分类传入流量以符合我们的规则。这意味着我们必须使用在我们的域中有效的 DSCP 值标记流量。这通常是通过查看数据包头并根据源地址、端口号等设置新的 DSCP 值来完成的。标记过程称为流量调节，在 DS 域的边界节点完成。

VLAN 802.1P 模型
IEEE 802.1P 在 OSI 第 2 层 (L2，数据链路) 上定义了一个 QoS 模型。这称为 CoS，即服务等级，并在 VLAN MAC 报头中添加了一个额外的 3 位字段 (称为用户优先级)。这会将流量分成 8 个不同的类别。优先级在交换机中设置，然后交换机使用不同的排队规则正确转发数据包。尽管 802.1P CoS 运行良好，但它缺乏可扩展性，无法提供端到端保证。我们不能假设 L2 协议在较大的网络或 Internet 上保持不变。因此，当今大多数高端交换机都实现了从 L3 (IP DSCP) QoS 到 L2 CoS 的映射。

路由器中的 DiffServ 实现
路由器负责将网络流量从一个网络转发到另一个网络。从一个网络进入的所有数据包（参见图 3）在处理之前都会进行排队，以确定应将它们转发到哪个网络。路由器中的 DiffServ 实现是一种根据传入数据包的 DSCP 提供转发处理的方法。这是通过使用排队规则和数据包优先级来实现的。请注意，路由器配置取决于品牌，本文档不涉及此内容。

队列规则
为了能够提供 DiffServ 所需的机制，路由器会采用不同的方式处理其队列。这些不同的技术称为排队规则，是旨在提供不同服务保证的算法。为了举例说明不同排队规则的使用，我们将简要介绍 FIFO 队列和优先级队列。

FIFO 是最简单的排队规则，通常是网络路由器中的默认设置。FIFO 描述了队列的简单先进先出行为。下图显示了一个 FIFO 队列，其中数据包从左侧进入并从右侧退出。第一个进入的数据包将是端口上发出的第一个数据包。其他数据包将被放置在队列的末尾，必须等待轮到它们。这种规则太基础了，无法提供任何 QoS 服务。

优先级排队
优先级排队是在路由器中实现区分服务类别的一种相对简单的方法。它不是只使用一个 FIFO 队列，而是使用多个队列，并且每个队列都分配不同的优先级。分类器确定将传入数据包放入哪个队列，然后调度程序将数据包发送到网络上。分类器解析传入数据包的报头，并决定将数据包放入哪个优先级队列。在 DiffServ 网络中，此决定基于传入数据包的 DSCP 值。调度程序确保首先为高优先级队列提供服务，然后是中优先级队列，依此类推。此规则允许对流量进行优先级排序。

Axis 选择使用 DiffServ 模型，以提供更高的可扩展性和灵活性。具体实现方式如下：

• 标记网络流量

• 将网络应用程序划分为 QoS 类别

• 提供用户界面

AXIS OS QoS 类
AXIS OS 使用四个 QoS 类。类中的成员都使用相同的 DSCP 值标记其流量，因此从路由器获得相同的转发处理：

• 实时视频 - 此类包括通过 HTTP 传输运动 JPEG 视频流以及通过 RTP、RTP/RTSP 和 RTP/RTSP/HTTP 传输 MPEG-4 视频流的应用程序。

• 实时音频 - 此类由生成音频流的应用程序组成，并且仅存在于支持音频的产品中。

• 事件/警报 - 此类由生成事件和警报流量的应用程序组成。此类处理 FTP、HTTP、SMTP 和 TCP 事件。

• 管理 - 此类由生成管理流量的应用程序组成。此类可以处理 FTP、HTTP、HTTPS 和 SNMP 管理流量。

AXIS OS QoS 配置
下图显示了使用 AXIS OS 6.5X 及更低版本的 Axis 设备中 QoS 的 HTTP 用户界面的屏幕截图示例。它显示了产品支持的不同 QoS 类，并允许用户为每个类指定 DSCP（DiffServ 代码点）值。默认 DSCP 值为 0，与默认 PHB 相同，可解释为禁用 QoS。

在运行 AXIS OS 7.10 及更高版本的 Axis 设备中，设置 > 系统 > 普通配置 > 网络中的普通配置用于执行 QoS 相关配置。

性能改进
下图说明了在启用 QoS 的网络上维持/改进性能的可能场景。

• 视频首先在安静的非 QoS 网络上传输，其中帧速率可以假设为大约每秒 30 帧。如线 A 所示。

• 然后通过添加无响应的 UDP 流等方式模拟网络拥塞。帧速率急剧下降，达到几乎无法使用的水平，如线 B 所示。

• 然后，视频通过启用 DiffServ 的网络进行传输，这里也添加了相同的拥塞。视频流量不受拥塞影响，帧速率保持不变，如线 C 所示。

TCP ECN
ECN 是显式拥塞通知的缩写，是对 TC P 中拥塞控制的改进。基本思想是让 TCP 在队列实际溢出之前报告即将发生拥塞。路由器通过在 IP 标头中标记一个称为 CE（拥塞经历）的字段来实现这一点。当发送方收到此信号时，流量会减慢。指示拥塞的传统方法是让路由器丢弃导致数据包重新传输的数据包。

仅当两个通信端点都支持 ECN 模型时，才会使用该模型。这是通过在 TCP 连接初始化时进行协商来实现的。通过引入 ECN 支持，网络上的重新传输被最小化，从而实现更高的吞吐量和更少的延迟。TCP ECN 在 Axis 视频产品中默认启用，可以在Plain Config > Network > TCP ECN中禁用。

IPv6（Internet 协议版本 6）最初由 IETF 设计，用于取代当前的 IP 版本 4（IPv4）。目前最有可能的情况是，即使 IPv6 进入舞台，IPv4 仍将保留。引入 IPv6 的主要原因之一是 IPv4 地址日益短缺。此外，IPv6 还在路由和网络自动配置等领域进行了改进。以下各节提供了有关 IPv6 地址和配置的一些一般信息，完整的 IPv6 规范可在 RFC 2460 规范中找到。

IPv6 地址
IPv6 地址以十六进制形式书写，由八个双字节组成，每个字节之间用冒号分隔。为了使地址表示尽可能简短，可以将多个连续的零缩写为双冒号，这在任何单个 IPv6 地址中都允许出现一次。IPv6 不使用 IPv4 中的子网掩码，而是仅使用网络前缀长度。前缀长度附加在地址后面。

例如：fe80::250:daff:fe4d:7592/64

前缀长度指定地址中有多少位将被视为前缀的一部分。在上面的示例中，前 64 位指定网络地址，而后 64 位指定主机地址。IPv6 地址可以按不同的方式分配：

• 自动配置链路本地 IPv6 地址。

• DHCPv6 服务器可用于分配 IPv6 地址。

• 路由器通告可用于分配自动配置的地址。

自动配置的链路本地地址
支持 IPv6 的设备将获得一个以 fe80 开头的自动配置的链路本地地址。地址的其余部分通常基于所谓的 EUI64 地址构建。EUI64 地址的构建方法是获取网络接口的以太网 MAC 地址，并在中间填充两个特定字节 (fffe)，以获得 64 位地址（请参阅上一节中的示例地址）。

使用路由器通告进行自动配置
在 IPv6 网络中，可以通过侦听网络中路由器发送的通告来自动配置网络设备。然后，这些通告将定义应如何配置网络设备才能进行路由。可以使用路由器通告中的信息来派生可路由的 IPv6 地址。此自动配置地址是使用 EUI64 地址以及路由器地址和网络前缀派生的。路由器通告可能会指示网络设备使用 DHCPv6，如果是，则指示在哪个级别使用。

DHCPv6 配置
正如 IPv4 网络可以使用 DHCP 服务器分配 IP 配置一样，IPv6 网络也可以使用 DHCPv6 服务器。DHCPv6 可以在不同级别使用：

• 在无状态模式下，DHCPv6 服务器将指定要使用的网络服务器，例如 DNS 服务器和 NTP 服务器，但不会为网络设备分配 IPv6 地址。这必须使用其他方法来完成。

• 在有状态模式下，DHCPv6 服务器还将为网络设备分配 IPv6 地址，以及像无状态模式一样分配网络服务器。

访问 IPv6 设备
大多数程序都接受主机名并会自动查找 IPv6 地址。这是将地址传递给程序的首选方式。如果名称映射到 IPv4 地址，则将使用 IPv4。如果名称映射到 IPv6 地址，则将使用 IPv6。如果同时存在 IPv4 和 IPv6 映射，操作系统将决定先尝试哪一个。 要将 IPv6 文字地址传递给程序，需要考虑几点。传递 URL 时，必须使用支架。 要将 IPv6 文字地址传递给程序，需要考虑几点。传递 URL 时，必须使用支架。例如：

大多数程序（例如 FTP、Telnet 等）将接受文字形式的 IPv6 地址，例如ftp 2001:5c0:84d9:2:240:8cff:fe6b:3cb9或ftp fe80::2:240:8cff:fe6b:3cb9%4。某些程序可能会以非标准方式获取接口标识符。通常随 linux 分发的 ping6 工具就是一个例子。它应像这样运行ping6 -I eth1 fe80::2:240:8cff:fe6b:3cb9。在 Windows 上，您可以通过运行“ipconfig”并查找该接口的 IPv6 链路本地地址来查看每个适配器的标识符。它可能看起来像这样：

常见 IPv6 地址和范围

Web 界面
Axis 视频产品的 IP 配置通常通过嵌入式 Web 界面中的 TCP/IP 设置（参见第 2.1 节）页面进行。除此之外，您还可以直接在Plain Config页面中列出参数。从这里，您可以通过更改 TCP/IP 设置页面中不可用的参数来自定义 IPv6 配置。在 TCP/IP 设置页面上，可以启用或禁用 IPv4 和/或 IPv6 的使用。

禁止用户同时禁用 IPv4 和 IPv6，因为这会导致 Axis 设备无法访问。但是，仍然可以从 Plain Config 页面同时禁用 IPv4 和 IPv6。如果发生这种情况，Axis 设备将覆盖配置并根据 IPv4 配置启动 IPv4。

默认情况下启用 IPv4。禁用 IPv4 后，设备上将不会进行任何 IPv4 配置。然后设备将只能通过 IPv6 访问。请注意，禁用 IPv4 后，不会分配链路本地 IPv4 地址，即使在“高级 TCP/IP 设置”页面上启用了链路本地 IPv4 地址的使用。

默认情况下，IPv6 的使用处于禁用状态。启用 IPv6 后，Axis 设备将分配一个链路本地 IPv6 地址。默认情况下，设备还将监听路由器通告并相应地分配 IPv6 地址。可以使用高级系统选项菜单中的普通配置界面更改 IPv6 配置行为。有关高级 IPv6 设置的更多说明。

普通配置
IPv6 配置默认设置为接受路由器通告并根据路由器通告使用 DHCPv6。在不同的环境中，可能需要更改 IPv6 配置。为此，请转到普通配置页面并选择网络参数组。通过更改 Network.IPv6 参数组中的参数，可以更改 IPv6 配置的行为。该组由五个参数组成：

网络基础设施及其所连接设备的安全级别各不相同。第一级是身份验证和授权。用户或设备通过用户名和密码向网络和远程端表明自己的身份，然后在允许设备进入系统之前对用户名和密码进行验证。可以通过加密数据来防止他人使用或读取数据，从而提高安全性。无线网络中的常用方法有 HTTPS（也称为 SSL/TLS）、VPN 和 WEP 或 WPA。IEEE 802.1X 是一种身份验证和授权技术。Axis 网络视频产品支持 IEEE 802.1X 作为安全功能。本节介绍了 IEEE 802.1X 的背景及其工作原理。它还介绍了如何在 Axis 设备中使用 IEEE 802.1X，以及如何配置 RADIUS（远程身份验证拨入用户服务）服务器和交换机。本文档的目标读者是技术人员和系统集成商。

IEEE 802.1X 是基于端口的网络访问控制的 IEEE 标准（“端口”是指与 LAN 基础设施的物理连接）。它是 IEEE 802.1 网络协议组的一部分，为设备连接到 LAN 提供了一种身份验证机制，可以建立连接，如果身份验证失败则阻止连接。IEEE 802.1X 可防止所谓的“端口劫持”，即未经授权的计算机通过建筑物内外的网络插孔访问网络。IEEE 802.1X 在网络视频应用中非常有用，因为它们的设备通常位于公共场所，而网络插孔可能会带来安全风险。在现代企业网络中，IEEE 802.1X 正在成为连接到网络的任何设备的基本要求。

工作原理
IEEE 802.1X 中有三个基本术语。需要进行身份验证的用户或客户端称为请求者。实际执行身份验证的服务器（通常是 RADIUS 服务器）称为身份验证服务器。中间的设备（例如交换机）称为身份验证器。IEEE 802.1X 中使用的协议是 EAPOL（LAN 上的可扩展身份验证协议封装）。有几种操作模式，但这里描述的是最常见的情况：

• 一旦检测到网络链接处于活动状态，验证者就会向请求者发送“EAP-Request/Identity”数据包（这可能是因为请求者（例如网络视频系统中的特定 Axis 设备）已连接到交换机）。

• 请求者向认证者发送“EAP-Response/Identity”数据包。

• 然后，认证者将“EAP-Response/Identity”数据包传递给认证（RADIUS）服务器。

• 身份验证服务器向身份验证器发回一个质询，例如使用令牌密码系统。

• 认证器从 IP 中解包该消息，并将其重新打包为 EAPOL 并发送给请求者。不同的认证方法会改变该消息和消息总数。EAP 支持仅客户端认证和强相互认证。

• 请求者对认证者的质询作出响应。

• 认证者将对质询的响应传递到认证服务器。

• 如果请求者提供了正确的身份，则认证服务器将向认证者响应成功消息。

• 然后，身份验证器将成功消息传递给请求者。身份验证器现在允许请求者访问 LAN，但可能根据从身份验证服务器返回的属性进行限制。例如，身份验证器可能会将请求者切换到特定的虚拟 LAN 或安装一组防火墙规则。

需要注意的是，设置和配置 IEEE 802.1X 是一个相当复杂的过程，正确设置 RADIUS 服务器、交换机和客户端（如 Axis 设备）非常重要。

Web 界面

要访问受保护的网络，Axis 设备必须具有 CA 证书、客户端证书和客户端私钥。这些证书应由服务器创建并通过 Web 界面上传。当 Axis 设备连接到网络交换机时，设备将向交换机出示其证书。如果证书获得批准，交换机将允许设备在预配置的端口上进行访问。如前所述，为了使用基于端口的身份验证，网络必须配备 RADIUS 服务器和支持 IEEE 802.1X 的网络交换机。您可能还需要联系网络管理员以获取有关证书、用户 ID 和密码的信息，具体取决于所使用的 RADIUS 服务器类型。

此处的设置使 Axis 设备能够访问受 IEEE 802.1X/EAPOL（LAN 上的可扩展身份验证协议）保护的网络。有多种 EAP 方法可用于访问网络。在 AXIS OS 11.6 之前，Axis 使用的协议是用于有线和无线 IEEE 802.1X 网络身份验证的 EAP-TLS（EAP-传输层安全性）以及用于无线 IEEE 802.1 网络身份验证的 EAP-PEAP/MSCHAPv2。

客户端和 RADIUS 服务器使用由认证机构签名的 PKI（公钥基础设施）提供的数字证书相互验证。请注意，为确保证书验证成功，应在配置之前在所有客户端和服务器上执行时间同步。应在安全的网络上对 Axis 设备进行进一步配置，以避免 MITM（中间人）攻击。Web 界面中使用的术语描述如下：

• CA 证书- CA 证书由认证机构创建，用于验证自身，Axis 设备需要它来检查服务器的身份。在 CA 证书下的安全选项卡中选择之前上传的正确证书。从 AXIS OS 10.1 及更高版本开始，选择无 CA 证书（无）意味着 Axis 设备将跳过对服务器身份的任何验证。

• 客户端证书- Axis 设备还必须使用客户端证书进行身份验证。在客户端证书下的安全选项卡中选择之前上传的正确证书。

• EAPOL 版本— 选择网络交换机中使用的 EAPOL 版本（1 或 2）。

• EAP 身份- 输入与您的证书关联的用户身份。最多可使用 16 个字符。

在 AXIS OS 11.6 及更高版本中，我们增加了对有线连接的 EAP-PEAP/MSCHAv2 支持。在 AXIS OS 11.8 及更高版本中，客户可以通过 Web 界面配置 EAP-PEAP/MSCHAPv2。

• 客户端证书-此身份验证模式不需要此证书。

• CA 证书- 可选。CA 证书由认证机构创建，用于 Axis 设备验证服务器的身份。无 CA 证书（无）表示 Axis 设备将跳过对服务器身份的任何验证。

• EAP 身份- MSCHAPv2 身份验证的用户名。

• EAPOL 版本— 选择版本 2。

• 密码- MSCHAPv2 身份验证的密码。

• Peap 版本— 选择 PEAPv0。

• 标签- 选择 1。

在 AXIS OS 11.8 及更高版本中，IEEE 802.1AE MACsec 功能被添加到基于 AXIS OS 的设备中。

IEEE 802.1AE MACsec（媒体访问控制安全）是一种明确的网络协议，它以加密方式保护网络第 2 层上的点对点以太网链路，确保两个主机之间数据传输的机密性和完整性。

* 受 IEEE 802.1AE MACsec 保护的 Axis 设备使用的示例网络协议列表。MACsec 为没有本机安全功能的网络协议增加了保护，并为具有内置安全性的网络协议增加了额外的保护层。

与 IPSec 等在第 3 层作为端到端技术运行的协议不同，MACsec 会加密离开以太网 LAN 的每个帧，并在帧进入以太网 LAN 时对其进行解密。为了使用 MACsec 实现端到端网络加密，源和目标之间的所有链路/跳数都需要启用 MACsec，以确保跨网络的流量受到 MACsec 保护。

因此，不支持 MACsec 的单个链路/跳跃将使从该链路/跳跃到下一个链路/跳跃的网络流量未加密。

MACsec 不仅通过强加密防止未经授权访问网络数据流，还可以防止中间人攻击。由于 MACsec 在网络堆栈的低层 2 上运行，因此它为不提供本机加密功能的网络协议（ARP、NTP、DHCP、LLDP、CDP……）以及提供本机加密功能的网络协议（HTTPS、TLS）增加了额外的安全层。下图概述了 MACsec 框架。

包含 MACsec 参数的安全标签 (SecTAG) 会立即插入以太网报头中的源 mac 地址之后。完整性检查值 (ICV) 由发送方通过约定的算法计算并附加到帧中。当接收方收到帧时，它将使用相同的算法再次计算 ICV 并将其与附加到数据包中的 ICV 进行比较。如果两个 ICV 值相同，则确认数据包的完整性，这意味着数据包未被篡改。

术语

MACsec 密钥协议 (MKA)

在两台设备之间实施 MACsec 时，MACsec 密钥协议 (MKA) 协议提供并管理会话密钥。MKA 协议依赖 EAP 框架来建立通信。两台设备建立唯一的连接关联。在 CA 内，有两个安全通道，一个用于入站流量，另一个用于出站流量。两台设备使用相同的密码套件进行数据加密。

MACsec 密码

为了保护通过 MACsec 安全通道传输的数据的机密性，数据包由工业标准 GCM-AES-128 或 GCM-AES-256 密码套件加密。还有另外两个密码套件 GCM-AES-XPN-128 和 GCM-AES-XPN-256。XPN 标准用于扩展数据包编号，这两个密码通常用于高速链路。

在当前实施中，AXIS OS 仅支持 GCM-AES-128 密码套件。可根据需要添加其他密码套件。

MACsec 模式

IEEE 802.1AE MACsec 标准描述了两种操作模式：手动配置的预共享密钥 (PSK)/静态 CAK 模式和使用 IEEE 802.1X EAP-TLS 会话的自动主会话/动态 CAK 模式。当连接网络交换机无法通过 IEEE 802.1X EAP TLS 支持自动协商时，建议使用预共享密钥模式。

由于 IEEE 802.1X EAP-TLS 默认启用，因此 MACsec 主会话/动态 CAK 模式也会自动启用。插入出厂默认的 Axis 设备时，将尝试 IEEE 802.1X 网络身份验证，如果成功，还将尝试 MACsec 动态 CAK 模式。如果连接的交换机不支持 IEEE 802.1X EAP TLS 和/或 MACsec 动态 CAK，则 Axis 设备将直接连接，而无需进一步强制执行安全机制。

在预共享密钥（PSK）模式（也称为静态CAK模式）下，MACsec实现包括三个阶段：PSK配置，MKA密钥协商和MACsec数据加密和解密。

此模式要求用户在两个设备（Axis 设备和网络交换机）上配置要使用的预共享密钥。每个 PSK 都包含两个字段：连接关联密钥名称 (CKN) 和连接关联密钥 (CAK)。CKN 和 CAK 必须在以太网链路的两端匹配。

一旦预共享密钥通过验证，MKA 协议就会启用，以在链路上维持 MACsec 会话。链路上的一个参与者将被选为密钥服务器，其主要职责是生成、分发和刷新安全关联密钥 (SAK)。SAK 是用于加密数据的实际密钥。MKA 协议限制了可以使用单个 SAK 保护的帧数。当 SA 中的数据包编号 (PN) 用尽时，将刷新相应的 SAK。

AXIS设备配置

要在 AXIS OS 设备中配置 MACsec PSK，请转到系统 > 安全 > IEEE 802.1ae MACsec > 模式，选择“静态 CAK / 预共享密钥 (PSK)”模式。

CAK 必须是 16 字节（32 个十六进制字符）或 32 字节（64 个十六进制字符）。CKN 必须是 1 到 32 字节（2 到 64 且能被 2 整除）十六进制字符。

在撰写本文时，请在保存配置之前选中启用 IEEE 802.1x 的复选框。当 MACsec 得到保护时，IEEE 802.1x 的状态将显示“已授权”。我们正在对此进行优化，因为 MACsec PSK 模式不能与 802.1x 协同工作。

交换机配置

下面的配置示例使用 Aruba CX 交换机系列概述。

1. 配置 MACsec 策略

switch(config)# macsec policy axis_ms_policyswitch(config-macsec-policy)# cipher-suite gcm-aes-128switch(config-macsec-policy)# replay-protection window-size 100switch(config-macsec-policy)# exitswitch(config)#

2.配置MKA策略

switch(config)# mka policy axis_mka_policyswitch(config-mka-policy)# pre-shared-key ckn 00112233445566771111111111111111 cak plaintext 00112233445566771111111111111111switch(config-mka-policy)# key-server-priority 5switch(config-mka-policy)# exitswitch(config)#

3. 在交换机端口上应用MAC

switch(config)# interface 1/1/28switch(config-if)# apply macsec policy axis_ms_policyswitch(config-if)# apply mka policy axis_ms_policyswitch(config-if)# exitswitch(config)#

当结合 EAP-TLS 实施 MACsec 时，认证器或接入交换机首先对设备执行 802.1x 认证。认证成功后，Radius 服务器将主会话密钥 (MSK) 发送到交换机和设备。双方将从 MSK 中派生出 CAK 和 CKN。

随后，链路两端均启用 MKA 协议，启动 MACsec 会话。与 PSK 模式相同，其中一方将被选举为密钥服务器，负责管理 SAK 密钥。一旦双方交换了 SAK 密钥，MACsec 加密和解密就开始了。

AXIS设备配置

自 AXIS OS 10.1（2020 年 9 月）起，使用符合 IEEE 802.1AR 标准的 Axis 设备 ID 证书，在出厂默认状态下启用 IEEE 802.1X。Axis 设备将自动尝试针对启用 IEEE 802.1X 的网络进行身份验证。有关手动 IEEE 802.1X 配置，请参阅AXIS OS 知识库。要使用基于 802.1x 端口的身份验证，网络必须配备 RADIUS 服务器和支持 IEEE 802.1X 和 IEEE 802.1AE MACsec 的网络交换机。您可能还需要联系网络管理员以获取有关证书和 RADIUS 服务器进一步配置的信息。

一旦 802.1x 认证完成，如果交换机支持 MACsec，则会相应地进行 MACsec 对话。

Freeradius 服务器配置

一旦 Freeradius 服务器启动并运行，只需执行一个额外步骤即可通过 Freeradius 服务器端启用 MACsec。在这种情况下，FreeRADIUS 服务器需要发送 EAP-KEY-NAME 属性，以便交换机派生用于创建 MKA 的 CKN 和 CAK 的 Session-ID。

为了允许 FreeRADIUS 在 Access-Accept 帧中发送 EAP-Session-ID，请取消注释里面的以下几行：

/etc/freeradius/sites-enabled/default for FreeRADIUS 2.x

或者

/etc/freeradius/3.0/sites-enabled/default in case of FreeRADIUS 3.x

在本文档中，我们使用 Aruba CX 交换机系列，该系列需要在 802.1x 身份验证后使用用户角色来触发 MACsec。“Aruba-User-Role”是根据 AXIS OS 设备中配置的 EAP 标识从 FreeRadius 服务器发送到 Aruba 交换机的供应商特定值。为此，请将以下内容添加到文件 /etc/freeradius/3.0/users。

Aruba ClearPass 策略管理器配置

请按照此处的说明将 Axis 设备安全地接入 Aruba 网络。集成指南详细概述了使用 IEEE 802.1AR 和 802.AE MACsec 的示例配置，以便将 Axis 设备安全地集成到 Aruba 网络中。还必须将“Aruba-user-Role”属性从 ClearPass Policy Manager 发送到交换机。

Aruba交换机配置

1. 配置 MACsec 策略

switch(config)# macsec policy macsec-eapswitch(config-macsec-policy)# cipher-suite gcm-aes-128switch(config-macsec-policy)# replay-protection window-size 100switch(config-macsec-policy)# exitswitch(config)#

2.配置端口访问角色

switch(config)# port-access role axiscameraswitch(config-pa-role)# associate macsec-policy macsec-eapswitch(config-pa-role)# auth-mode client-mode

3. 在端口上启用 MACsec

switch(config-if)# aaa authentication port-access dot1x authenticatorswitch(config-if-dot1x-auth)# macsecswitch(config-if-dot1x-auth)# mka cak-length 16

在我们当前的实现中，对于 dot1x 认证模式，cak-length 应该配置为 16 字节。

验证 AXIS OS 设备上的 MACsec 状态：

以下是直接从摄像机进行数据包跟踪时 MACsec 帧的样子。转到系统 > 日志 > 网络跟踪。

验证 Aruba 交换机上的 MACsec 状态：

switch# show macsec statusMACsec Protocol Status Interface  Port ID  Policy                    Protection           Status  State ---------- -------- ------------------------- -------------------- ------- -------------- 1/1/27     1        macsec-eap                IC, Conf, Offset 0   Up      Retire 1/1/28     1        axis_ms_policy            IC, Conf, Offset 0   Up      Retire

SW23# show mka policyMKA Policy Details===================  Policy Name: MKA_Auth_1/1/27_b8a44f4645f4  ---------------------------------------------------------------------------    Mode                     : EAP-TLS    CKN                      : b0d80475242fbcd5c97ece50670e4dfe    CAK (encrypted)          : AQBapQh5tkM/wWCQLE4jp0G/Iu6IfO+QutBMu8gFBKf...    Key-server Priority      : 0    Transmit Interval        : 2 seconds

  Policy Name: axis-mka_policy  ---------------------------------------------------------------------------    Mode                     : Pre-shared key    CKN                      : 00112233445566771111111111111111    CAK (encrypted)          : AQBapcO5rGnurI1zhrDB3JVwhbLmJhcgQkiRWgiJtfK...    Key-server Priority      : 5    Transmit Interval        : 2 seconds

Web 服务动态发现协议使用 UDP 端口 3702，并将自身定义为用于检测网络上的其他设备和服务的多播发现协议。ONVIF 依靠此协议来检测其他功能强大的设备，因此 Axis 设备支持 WS-Discovery 进行初始登录和配置。建议在使用后禁用 WS-Discovery，因为它容易受到此 安全公告中所述的攻击。请参阅以下有关如何禁用 WS-Discovery 的说明。

AXIS OS > 9.70通过在设置 > 系统 > 普通配置 > WebService > DiscoveryMode > 启用 WS-Discovery中禁用参数启用 WS-Discovery 可发现模式
来禁用该服务。对于 AXIS 设备管理器中的多设备配置，相应的 VAPIX 参数称为DiscoveryMode.Discoverable。