DMTF相关协议（一）：Redfish和SMBIOS

一、Redfish

1.简介

Redfish 是一种管理标准，使用超媒体 RESTful 接口中的数据模型表示。该模型以标准的、机器可读的模式表示，消息的有效负载以 JSON 表示。该协议本身利用了 OData v4。由于它是一个超媒体 API，因此能够通过一致的接口表示各种实现。它具有管理数据中心资源、处理事件、长时间任务和发现的机制。

2.root url

Redfish 是一个超媒体 API。这意味着你可以通过从其他资源返回的 URL 访问所有资源。但是有一个众所周知的 URL，使得每个实现都有一个共同的起点。对于 Redfish 接口的第一个版本，这个 URI 是 "/redfish/v1"。
URL 包含一个模式（HTTP:// 部分）、一个节点（例如 www.dmtf.org 或一个 IP 地址如 127.0.0.1）和一个资源部分。你可以将这些部分组合在浏览器的 URL 中。因此，如果你在自己的机器上使用 nginx 服务器，你应该能够在浏览器中输入 "HTTP://127.0.0.1/redfish/v1/" 来访问 Redfish 根目录。
从你构建的上述 URL 对服务根目录执行 GET 操作。

3.基本属性

以 "@" 开头的属性是针对整个对象的注解，而在属性名称中间带有 "@" 的属性用于注解单个属性。允许使用两种类型的注解属性：OData 和 DMTF 注解。OData 注解包含 "@odata."。这些属性的例子有：
"@odata.type"，用于查找定义此资源的架构。
"@odata.id"，包含此资源的 URL。这是一个 href，但由于 Redfish 基于 OData，因此这个属性被称为 "@odata.id" 而不是 "href"。
"[email protected]"，定义 "Members" 数组中的条目数量。
DMTF 注解包含 "@Redfish."。这些属性的例子有：
"@Redfish.Settings"，用于指示资源的设置
另一个常见的注解是 "@odata.context"。这实际上是为通用的 OData v4 客户端设计的。这在 OData v4 规范中有明确定义，但基本上 @odata.context 用于几种不同的用途：

提供描述有效负载的元数据的位置。
提供解析相对引用的根 URL。
@odata.context 的结构是指向带有描述数据片段的元数据文档的 URL。
从技术上讲，元数据文档只需要定义或引用它直接使用的任何类型，不同的有效负载可以引用不同的元数据文档。然而，由于 @odata.context 提供了解析相对引用（如 @odata.id）的根 URL，我们必须返回“规范”的元数据文档。此外，因为我们的 "@odata.type" 注解是作为片段而不是完整的 URL 编写的，这些片段必须在该元数据文档中定义或引用。而且，因为我们使用无版本的命名空间别名来限定操作，这些别名也必须通过引用在引用的元数据文档中定义。
例如，在资源 /redfish/v1/Systems/1 中，你会看到属性 "@odata.context"，其值为 "/redfish/v1/metadata#ComputerSystem.ComputerSystem"。这告诉通用的 OData v4 客户端在 metadata 中找到 ComputerSystem 定义，该定义引用了此实体的定义。
你还会看到一个名为 "@Redfish.Copyright" 的注解。实现不会返回此属性。它仅作为静态示例响应中使用的版权声明。

4.session

通常情况下，只有根用户可以在不建立会话的情况下访问。但如果使用的是公共模拟或本地Web服务器，则无需这样做，因为没有安全性。如果在安全模式下运行仿真器，或者正在处理实际实现，则需要建立会话。
首先，需要知道您的实现的有效用户名和密码。
用于建立会话的URI也允许用于未加密的POST，以便可以建立会话。这个URI在大多数情况下是/redfish/v1/Sessions，可以通过查看Links下的Sessions属性并找到服务根目录中的@odata.id属性值来确定（/redfish/v1/）。
会话是通过HTTP POST到由/redfish/v1#/Links/Sessions/@odata.id指示的URI创建的，包括以下POST主体：

POST /redfish/v1/SessionService/Sessions HTTP/1.1
Host: <host-path>
Content-Type: application/json; charset=utf-8
Content-Length: <computed-length>
Accept: application/json
OData-Version: 4.0
{
 "UserName": "<username>",
 "Password": "<password>"
}

返回结果包括带有会话令牌的X-Auth-Token头和Location头。
返回的JSON主体包含新创建的会话对象的表示：

Location: /redfish/v1/SessionService/Sessions/1
X-Auth-Token: <session-auth-token>
{
 "@odata.context": "/redfish/v1/$metadata#SessionService/Sessions/$entity",
 "@odata.id": "/redfish/v1/SessionService/Sessions/1",
 "@odata.type": "#Session.v1_0_0.Session",
 "Id": "1",
 "Name": "User Session",
 "Description": "User Session",
 "UserName": "<username>"
}

将在响应的X-Auth-Token头中使用令牌字符串，并在所有后续请求中使用相同的头。
当需要删除会话时，可以对响应中的@odata.id返回的URL执行DELETE操作（如上例中的/redfish/v1/Sessions/Administrator1

5.Etag

【ETag的核心作用】
ETag（实体标签）是HTTP协议中用于资源版本控制的机制。在Redfish标准中，ETag被设计用于：

缓存优化 - 浏览器/客户端通过发送带有ETag的If-Match请求头，可避免重复传输未变更的数据
变更检测 - 任何通过PUT请求的资源修改，或通过其他途径（如BIOS控制台配置工具）的操作，都会触发ETag值变更
并发控制 - 可及时发现Redfish客户端与非Redfish客户端（或其他Redfish客户端）之间的写入竞态条件

注：在真实生产环境中，ETag机制可有效防止"丢失更新"问题，确保当两个客户端同时修改资源时，后到达的请求会因ETag不匹配而被拒绝。

客户端操作流程

资源读取阶段
- GET请求获取资源当前状态
- 记录响应头中的ETag值（版本标识符）
本地修改阶段
- 修改资源属性（如BIOS配置参数）
- 生成新ETag（通常为哈希值或版本号）

提交更新阶段

http

PATCH /redfish/v1/Systems/1/Bios/Settings 
If-Match: "a18c7e5d"  // 携带原始ETag
{
  "Attribute": "NewValue"
}

冲突检测机制
- 服务端校验If-Match头与当前资源ETag
- 匹配成功 → 应用修改，更新ETag（HTTP 200）
- 匹配失败 → 返回412 Precondition Failed错误
客户端恢复策略
- 收到412错误后需重新执行完整操作链
- 建议采用指数退避重试机制

5.PUT or PATCH

维度	PUT	PATCH
数据完整性	必须提交完整资源表示	仅需提交变更字段
幂等性	是（多次提交结果相同）	是（基于RFC 5789规范）
传输效率	O(n) 全量传输	O(Δ) 差异传输
服务端处理	替换整个资源树	应用JSON Merge-Patch算法
典型场景	配置模板导入/恢复默认	实时调优/热更新

二、SMBIOS

SMBIOS规范解决了主板和系统供应商如何通过平台固件以标准格式呈现其产品的管理信息。该信息旨在允许通用仪器将这些数据传递给使用CIM（WBEM数据模型）或直接访问的管理应用程序，并消除诸如探测系统硬件以进行存在检测等容易出错的操作。

support processor

UUID

一、核心属性

标识符特性

唯一性保障：时空双重唯一性设计
编码长度：128位固定长度（16字节）
注册机制：无需中央注册机构

二、数据结构规范（RFC4122标准）

偏移量	字段名称	长度	描述
00h	time_low	DWORD(4字节)	时间戳低位段
04h	time_mid	WORD(2字节)	时间戳中位段
06h	time_hi_and_version	WORD(2字节)	时间戳高位段（含版本号）
08h	clock_seq_hi_and_reserved	BYTE(1字节)	时钟序列高位（含变体标识）
09h	clock_seq_low	BYTE(1字节)	时钟序列低位
0Ah	Node	6字节	空间唯一节点标识符

三、字节序规范（SMBIOS实现要求）

编码冲突点

RFC4122建议：网络字节序（大端序）
PC行业实践：小端序（包含ACPI/UEFI/SMBIOS）
→ 适用字段：time_low/time_mid/time_hi_and_version

传输格式要求

必须使用wire format（网络传输格式）
示例转换：
UUID {00112233-4455-6677-8899-AABBCCDDEEFF}
→ 字节序列：33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF
注：SMBIOS规范中UUID字段内容被视为不透明数据，重点仅关注字节顺序的正确处理。开发实现时需特别注意PC行业的小端序编码惯例与RFC标准的差异性