為什麼 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 Session 相關的物件，或由某個網路功能維護的其他狀態資訊。

例如，某個使用者的存取管理訂閱資料可以對應一個特定 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 Session 服務也遵循相同思路。不同的 SM 上下文和 PDU Session 相關資源都有各自的 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 內容以及前後信令序列進行判斷，才能確認整個端到端流程是否真正完成。