为什么 5GC SBI 围绕 HTTP/2 服务调用构建？

5G 核心网采用服务化架构后，网络功能之间的关系发生了明显变化。AMF、SMF、UDM、PCF、NSSF、AUSF 等功能不再局限于通过固定的点到点协议接口交换消息，而是由每个 NF 以服务形式暴露自身能力，供其他网络功能在需要时调用。

在这种模式下，一个 NF 可以从另一个 NF 获取资源、创建新的上下文、更新已有资源，或删除不再需要的资源。通信模式自然变成 请求 → 资源操作 → 响应。HTTP 方法、URI、状态码和 JSON 为表达这类服务交互提供了实用方式。

一个简化的 SBI 协议栈可以表示为：

应用/JSON → HTTP/2 → TCP → IP → 以太网

JSON 定义应用数据如何表示；HTTP/2 负责组织请求和响应并进行传输；TCP 提供可靠传输；IP 负责寻址和路由；以太网则在底层网络中承载数据帧。

这与 N2、N3、N4 等接口明显不同。N2 使用 NGAP，N4 使用 PFCP，用户面通常使用 GTP-U。服务化接口则以 HTTP/2 作为服务通信的传输框架。这并不只是更换了一个协议，而是反映了 5GC 设计理念更深层的变化——从交换预先定义好的接口消息，转向调用服务。

例如，当 AMF 需要获取某个用户的接入管理签约数据时，AMF 作为 NF 消费者，向作为 NF 生产者 的 UDM 请求资源。消费者主要需要知道访问哪个资源、执行什么操作以及返回什么结果，而没有必要为每一个具体服务流程单独设计一套完全不同的传输机制。

HTTP/2 在这种环境下还有一个非常实际的优势：多个服务请求可以共享同一条 TCP 连接。网络功能之间的 SBI 交互非常频繁，如果每次 API 调用都重新建立 TCP 连接，会产生不必要的连接管理开销。

与 HTTP/1.1 相比，HTTP/2 解决了哪些传输问题？

HTTP/2 并没有取代 HTTP/1.1 的整个应用模型。GET、POST 等方法依然存在，基本的请求—响应模式也仍然相同。真正的主要变化在于数据如何组织和传输。

对于 5GC 来说，更快加载网页并不是重点。真正的价值在于，HTTP/2 能为网络功能之间大量并发的 API 调用提供更高效的连接模型。

一条连接可以同时承载多个流

HTTP/1.1 支持持久连接，但单条连接上的并发能力仍然有限。在许多传统部署中，为了提高并行度会建立多条 TCP 连接，这会增加客户端和服务器两侧的连接管理开销。

HTTP/2 引入了多路复用。一条 TCP 连接可以同时包含多个相互独立的流。新的请求不必等到前一个事务完全结束后才能发送，来自多个流的帧可以在同一连接中交错传输。

在 5GC SBI 环境中，当 AMF 与另一个 NF 建立 HTTP/2 连接后，这条连接并不是一次只能处理一个 API 请求。多个服务操作可以分别使用不同的流，每个流承载各自的请求和响应。

更少的 TCP 连接意味着更低的连接管理开销，非常适合 5G 核心网网络功能之间高频发生的服务交互。

HTTP 消息以二进制帧进行传输

HTTP/1.x 在很大程度上是面向文本的，请求行、头部和消息体都以清晰的文本结构表示。HTTP/2 改变了报文在网络上的传输格式，以二进制帧承载协议信息。

HTTP 头部通常由 HEADERS 帧承载，实际的应用载荷则可以由 DATA 帧承载。接收端利用帧头中的信息，包括流标识符，判断某个帧属于哪个流，然后重组出完整的 HTTP 消息。

因此，在 Wireshark 中抓取 HTTP/2 数据时，通常不会看到一整块完整的 HTTP 文本，而是会看到由 HEADERS、DATA 以及其他类型帧组成的序列。

重复的头部无需每次都完整发送

在 SBI API 流量中，HTTP 头部会反复出现。如果每个请求都完整携带相同的头字段，重复开销会很快变得明显。

HTTP/2 使用 HPACK 对头部进行压缩。简单来说，通信双方都会维护头部表，使经常重复的字段可以通过索引表示，而无需每次重新发送完整文本。

头部越重复，压缩的收益越明显。当网络功能反复调用相似 API 时，方法、路径以及常用头字段会不断出现，因此 HPACK 在减少重复传输方面尤其有效。

HTTP/2 还定义了服务器推送

HTTP/2 包含服务器推送机制，并定义了 PUSH_PROMISE 帧，使服务器可以在客户端逐一明确请求相关资源之前，主动提供这些资源。

不过，在理解 5GC SBI 时，服务器推送并不是最需要关注的概念。对实际 SBI 分析来说，连接复用、多路复用、流、帧、头部压缩以及 API 的请求—响应模型更重要。

应该如何理解连接、流、消息和帧？

HTTP/2 最容易让人混淆的地方之一，是连接、流、消息和帧这些概念经常同时出现。与其分别死记定义，不如把它们看成一个层级关系来理解。

连接 是底层 TCP 连接。TCP 会话建立后，HTTP/2 流量就在这条连接上承载。

流 是连接内部的逻辑双向通道。每个流都有自己的整数标识符。同一条 TCP 连接内可以同时存在多个流，这是 HTTP/2 多路复用的基础。

消息 表示一个逻辑上的 HTTP 请求或响应。例如，AMF 可以向 UDM 发送 GET 请求消息，UDM 则返回对应的响应消息。

帧 是 HTTP/2 实际传输所使用的更小数据单元。一条消息可以由一个或多个帧组成。常见示例包括：

• HEADERS 帧：承载 HTTP 头部信息。

• DATA 帧：承载应用载荷数据。

• 其他帧类型：用于连接管理、流量控制以及 HTTP/2 的其他功能。

因此，这些概念之间的关系可以概括为：

一条连接包含多个流；一个流承载请求消息和响应消息；每条消息由一个或多个帧组成。

HTTP/2 帧头包含长度、类型、标志位、保留位和流标识符等字段。其中流标识符尤其重要，因为它告诉接收端该帧属于哪个逻辑流。

即使来自多个流的帧以交错顺序到达，接收端仍可以利用流 ID 将正确的数据关联并重新组装起来。这正是 HTTP/2 能够在一条 TCP 连接上高效承载多个并发事务的核心机制。

对于 5G 核心网工程师来说，这个概念在抓包分析时尤其重要。不能仅仅因为数据包在抓包文件中彼此相邻，就把 SBI 流量归为同一事务。需要把流 ID、URI、HTTP 方法和响应状态结合起来判断。

JSON 和 RESTful API 如何把 5GC 能力变成资源？

HTTP/2 回答的是 服务流量如何高效传输 这个问题。真正定义 5GC SBI 应用模型的，是 RESTful API 与面向资源设计的结合。

REST 是一种架构风格，其核心思想之一是把业务对象表示为资源，为每个资源分配唯一 URI，再通过 HTTP 方法对资源执行操作。

5GC 中的“资源”并不限于通常与网站相关的对象。它可以表示用户签约数据、SM 上下文、与 PDU 会话相关的对象，或由某个网络功能维护的其他状态信息。

例如，某个用户的接入管理签约数据可以对应一个特定 URI，会话管理签约数据则可以使用另一个 URI。从消费者的角度看，操作不再只是：

“调用某个特定的 UDM 信令流程。”

而是变成：

对指定资源执行 GET、POST、PUT/PATCH 或 DELETE 操作。

HTTP 方法定义如何操作资源

常见操作可以这样理解：

• GET：获取或读取资源。

• POST：创建资源或调用已定义的操作。

• PUT / PATCH：更新已有资源。

• DELETE：删除资源。

服务器处理请求后，会返回 HTTP 状态码来表示处理结果。

200 响应通常表示处理成功并返回了数据；201 通常表示资源创建成功；204 可以表示操作成功但没有返回响应体；4xx 响应通常指向请求、资源或授权方面的问题，而 5xx 响应一般表示服务器端处理异常。

这些状态码在 5GC 故障排查中非常有用。HTTP/2 连接已经建立，并不代表服务操作本身一定成功。工程师仍需检查请求的 URI、HTTP 方法，以及 NF 生产者返回的状态码。

JSON 承载实际业务数据

SBI 的应用载荷通常使用 JSON 表示。JSON 是一种基于键值结构的轻量级数据交换格式，可以表示字符串、数字、布尔值、数组、对象以及嵌套数据结构。

换句话说，HTTP/2 的 DATA 帧负责承载载荷，而帧中的 JSON 则定义这些应用数据实际表示什么含义。

从工程角度看，不应把 HTTP/2 和 JSON 当成同一协议层。HTTP/2 负责组织传输，JSON 表示应用数据，RESTful API 则定义资源以及可以对资源执行的操作。

5GC SBI 的资源 URI 是如何组成的？

理解“资源”概念后，SBI URI 的结构就容易理解得多。资源路径并不是随意定义的，而是遵循结构化的层级关系。

一种典型格式可以表示为：

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart}

各部分都有明确作用：

• apiRoot：访问服务所使用的根地址，通常形式为 http(s)://host(:port)。

• apiName：网络功能对外提供的具体 SBI API 或服务名称。

• apiVersion：API 版本，例如 v1。

• apiSpecificResourceUriPart：用于标识具体资源或操作的路径。

例如，接入管理签约数据和会话管理签约数据都可能由 UDM 提供，但它们使用不同的资源路径。因此，URI 可以明确指出消费者究竟正在请求哪个资源。

SMF 的 PDU 会话服务也遵循相同思路。不同的 SM 上下文和 PDU 会话相关资源都有各自的 URI，并使用不同 HTTP 方法创建、获取、修改或释放资源。

这种面向资源的设计改变了工程师理解 SBI 接口的方式。与其只记忆“消息 A → 消息 B”这样的传统流程，不如把一次 SBI 交互分析为：

服务 → 资源 → 方法 → URI → 状态码 → JSON 消息体

如果完全沿用传统电信思维，只把请求消息名称与响应消息名称一一对应来理解 5GC SBI，整个架构会显得比较零散。把它视为基于 API 的资源模型后，逻辑会清晰得多。

工程师应该如何在 Wireshark 中跟踪一次 SBI 事务？

理解 HTTP/2 的概念后，下一步就是将其用于真实抓包分析。由于一条 TCP 连接可以同时承载多个 HTTP/2 流，仅按源 IP 和目的 IP 过滤，仍可能把几个彼此无关的 SBI 事务混在同一个抓包结果中。

一种实用方法是先确定 NF 消费者和 NF 生产者的 IP 地址，再使用相关的流 ID 缩小分析范围。

例如，如果某个请求使用流 ID 1，可以把服务器地址与该流 ID 结合起来，隔离出属于对应请求—响应事务的帧。

过滤流量后，重点关注以下信息：

• 流 ID：确认这些帧是否属于同一个逻辑流。

• HEADERS：查看 HTTP 方法、路径以及其他头字段。

• DATA：确认事务是否携带 JSON 应用载荷。

• 状态码：表示 NF 生产者如何处理该请求。

• URI：标识实际访问的服务、API 版本和具体资源。

一个实用的故障排查顺序是从传输层开始逐层向上。首先确认 TCP 连接已经建立。如果 TCP 不可用，就不存在 HTTP/2 或 RESTful API 通信的基础。

接着确认 HTTP/2 层存在正常的 HEADERS 和 DATA 帧，并利用流 ID 把它们与正确的事务对应起来。

然后检查 HTTP 方法和 URI 是否符合预期操作。许多 SBI 问题实际上并不是网络连通性造成的，而可能源于资源路径错误、API 版本不正确或 HTTP 方法使用错误。

随后检查 HTTP 状态码。4xx 响应应把排查方向引向请求语法、资源不存在、授权或应用参数；5xx 响应则更倾向于说明 NF 生产者内部处理出现问题。

只有确认 HTTP 请求已经被正确送达后，才应进一步详细检查 JSON 载荷。

完整的 SBI 故障排查路径可以概括为：

TCP → HTTP/2 连接 → 流 → HEADERS → 方法/URI → DATA/JSON → 状态码

这种方法可以把一开始看起来非常“互联网化”的 5GC 协议，转化为熟悉的分层工程问题：底层确认连通性，中间检查 HTTP/2 的传输行为，上层检查 API 资源和业务数据。这样更容易确定故障边界。

从更广泛的 5GC 架构看，SBI 使用 HTTP/2 并不只是因为它比 HTTP/1.1 更新。更深层的原因是，5G 核心网把 NF 能力组织成服务，因此需要一种能够高效支持频繁 API 调用、并发服务交互以及面向资源访问的通信模型。

HTTP/2 提供连接、流和帧。多路复用提高连接利用率，HPACK 减少重复头部开销，二进制分帧提供结构化的传输格式。JSON 承载应用数据，而 RESTful API 定义资源以及对资源执行的操作。这些要素共同构成 5GC 服务化接口所使用的完整通信模型。

常见问题

HTTP/2 和 RESTful API 是一回事吗？

不是。HTTP/2 是 HTTP 传输协议，定义了连接、流、帧等机制；REST 是一种 API 架构风格，定义如何把应用对象表示为资源，以及如何通过 URI 和 HTTP 方法访问这些资源。5GC SBI 在 HTTP/2 之上使用 RESTful 风格的 API。

流 ID 0 可以承载普通 SBI 应用请求吗？

不可以。流 ID 0 在协议层具有特殊用途，不用于普通应用流。在分析实际 SBI 请求时，工程师应关注分配给业务事务的非零流 ID。

SBI 的 apiRoot 必须包含 IP 地址吗？

不一定。apiRoot 的逻辑形式是 http(s)://host(:port)。host 会根据网络架构和服务发现机制标识相应的服务端点。分析 URI 时，应把 apiRoot 与 apiName、apiVersion 以及资源专用路径区分开来。

既然 HTTP/2 使用二进制分帧，为什么在 DATA 帧中仍能看到 JSON？

二进制分帧是指 HTTP/2 如何组织和传输协议数据，并不要求应用层载荷本身也必须采用二进制数据格式。DATA 帧仍然可以承载 JSON。JSON 定义 5GC 的应用字段，而 HTTP/2 则把这些载荷放入相应的流中进行传输。

HTTP 200 响应能证明整个 5GC 流程都成功了吗？

不能。HTTP 200 只表示当前这个特定 HTTP 请求在该处理点成功完成。一个完整的 5GC 流程可能涉及多个网络功能之间的多次服务调用。工程师仍需结合 URI、JSON 内容以及前后信令序列进行判断，才能确认整个端到端流程是否真正完成。