Почему SBI в 5GC строится вокруг сервисных вызовов HTTP/2?

Взаимодействие сетевых функций существенно изменилось после перехода ядра 5G на сервисно-ориентированную архитектуру. Такие функции, как AMF, SMF, UDM, PCF, NSSF и AUSF, больше не ограничиваются обменом сообщениями через фиксированные протокольные интерфейсы «точка-точка». Вместо этого каждая NF предоставляет свои возможности в виде сервисов, которыми другие сетевые функции могут пользоваться по мере необходимости.

В такой модели одна NF может получить ресурс у другой NF, создать новый контекст, обновить существующий ресурс или удалить ресурс, который больше не нужен. Схема взаимодействия естественным образом принимает вид запрос → операция с ресурсом → ответ. Методы HTTP, URI, коды состояния и JSON дают практичный способ описания такого сервисного взаимодействия.

Упрощенный стек протоколов SBI можно представить так:

Приложение/JSON → HTTP/2 → TCP → IP → Ethernet

JSON определяет представление прикладных данных. HTTP/2 организует запросы и ответы для передачи. TCP обеспечивает надежную доставку, IP отвечает за адресацию и маршрутизацию, а Ethernet переносит кадры по нижележащей сети.

Это заметно отличается от интерфейсов N2, N3 и N4. N2 использует NGAP, N4 — PFCP, а в пользовательской плоскости обычно применяется GTP-U. Сервисный интерфейс использует HTTP/2 как транспортную основу для взаимодействия сервисов. Это не просто замена одного протокола другим, а отражение более глубокого изменения философии 5GC — от обмена заранее определенными сообщениями интерфейсов к вызову сервисов.

Например, когда AMF требуются данные подписки для управления доступом конкретного абонента, AMF выступает как потребитель NF и запрашивает ресурс у UDM, действующей как поставщик NF. Потребителю прежде всего нужно знать, к какому ресурсу обратиться, какую операцию выполнить и какой результат будет возвращен. Для каждой отдельной сервисной процедуры не требуется разрабатывать собственный транспортный механизм.

HTTP/2 также дает в такой среде очень практичное преимущество: несколько сервисных запросов могут совместно использовать одно TCP-соединение. Взаимодействия SBI между сетевыми функциями происходят часто, поэтому постоянное создание нового TCP-соединения для каждого вызова API приводило бы к лишним затратам на управление соединениями.

Какие транспортные проблемы HTTP/2 решает по сравнению с HTTP/1.1?

HTTP/2 не заменил всю прикладную модель HTTP/1.1. Методы GET и POST по-прежнему используются, а базовая модель «запрос-ответ» остается привычной. Основные изменения касаются того, как данные организуются и передаются.

Для 5GC ускорение загрузки веб-страниц не является главным преимуществом. Реальная ценность HTTP/2 заключается в более эффективной модели соединения для большого количества одновременных вызовов API между сетевыми функциями.

Одно соединение может одновременно переносить несколько Streams

HTTP/1.1 поддерживает постоянные соединения, однако параллельная работа внутри одного соединения все равно ограничена. Во многих традиционных реализациях для увеличения параллелизма открывают несколько TCP-соединений, что повышает нагрузку на управление соединениями как со стороны клиента, так и со стороны сервера.

HTTP/2 вводит мультиплексирование. Одно TCP-соединение может одновременно содержать несколько независимых Streams. Новому запросу не нужно ждать полного завершения предыдущей транзакции, прежде чем начнется передача следующего трафика. Frames разных Streams могут передаваться вперемешку по одному и тому же соединению.

В среде 5GC SBI после установления HTTP/2-соединения между AMF и другой NF это соединение не ограничено обработкой только одного запроса API за раз. Несколько сервисных операций могут использовать разные Streams, каждый из которых несет собственный запрос и ответ.

Меньшее число TCP-соединений означает меньшие затраты на их управление, что хорошо соответствует частым сервисным взаимодействиям между сетевыми функциями ядра 5G.

HTTP-сообщения передаются в виде двоичных Frames

HTTP/1.x в основном ориентирован на текст. Строки запросов, заголовки и тела сообщений явно представлены в текстовой форме. HTTP/2 меняет формат передачи по сети и переносит протокольную информацию в двоичных Frames.

HTTP-заголовки обычно передаются в HEADERS Frames, а фактическая прикладная полезная нагрузка может передаваться в DATA Frames. Получатель использует данные заголовка Frame, включая идентификатор Stream, чтобы определить, к какому Stream относится конкретный Frame, а затем собрать полное HTTP-сообщение.

Поэтому захват HTTP/2 в Wireshark часто не выглядит как единый блок HTTP-текста. Вместо этого инженер видит последовательность HEADERS, DATA и других типов Frame.

Повторяющиеся заголовки не нужно каждый раз передавать полностью

HTTP-заголовки постоянно повторяются в трафике SBI API. Если бы каждый запрос полностью включал одни и те же поля заголовков, объем дублирующих служебных данных быстро стал бы значительным.

HTTP/2 использует HPACK для сжатия заголовков. Упрощенно говоря, обе стороны поддерживают таблицы заголовков, благодаря чему часто повторяющиеся поля можно передавать через индексы вместо повторной передачи полного текста.

Чем чаще повторяются заголовки, тем выше эффект от сжатия. Когда сетевые функции многократно вызывают похожие API, такие поля, как методы, пути и типовые заголовки, появляются снова и снова, поэтому HPACK особенно эффективно сокращает избыточную передачу.

HTTP/2 также определяет Server Push

HTTP/2 включает механизм Server Push и определяет PUSH_PROMISE Frame, благодаря которому сервер может заранее предоставить связанные ресурсы еще до того, как клиент явно запросит каждый из них.

Однако при изучении SBI в 5GC Server Push не является главным понятием. Для практического анализа SBI гораздо важнее повторное использование соединений, мультиплексирование, Streams, Frames, сжатие заголовков и модель «запрос-ответ» для API.

Как понимать Connection, Stream, Message и Frame?

Одна из самых сложных частей HTTP/2 связана с тем, что термины Connection, Stream, Message и Frame часто встречаются вместе. Проще воспринимать их как иерархию, чем заучивать каждое определение отдельно.

Connection — это нижележащее TCP-соединение. После установления TCP-сеанса трафик HTTP/2 передается по этому соединению.

Stream — это логический двунаправленный канал внутри Connection. Каждый Stream имеет собственный целочисленный идентификатор. В одном TCP-соединении одновременно могут существовать несколько Streams, что и является основой мультиплексирования HTTP/2.

Message представляет логический HTTP-запрос или HTTP-ответ. Например, AMF может отправить UDM сообщение запроса GET, а UDM возвращает соответствующее сообщение ответа.

Frame — это более мелкая единица, которую HTTP/2 использует для фактической передачи. Один Message может состоять из одного или нескольких Frames. Типичные примеры:

• HEADERS Frame: переносит информацию HTTP-заголовков.

• DATA Frame: переносит данные прикладной полезной нагрузки.

• Другие типы Frame: используются для управления соединением, управления потоком и других функций HTTP/2.

Таким образом, взаимосвязь можно кратко представить так:

Один Connection содержит несколько Streams. Stream переносит Messages запросов и ответов, а каждый Message состоит из одного или нескольких Frames.

Заголовок Frame в HTTP/2 содержит такие поля, как Length, Type, Flags, резервные биты и Stream Identifier. Stream Identifier особенно важен, поскольку сообщает приемнику, к какому логическому Stream относится Frame.

Даже если Frames разных Streams приходят вперемешку, приемник может использовать Stream ID, чтобы правильно сопоставить и собрать данные. Это основной механизм, позволяющий HTTP/2 эффективно переносить несколько одновременных транзакций по одному TCP-соединению.

Для инженеров 5G Core это особенно важно при анализе пакетов. Нельзя объединять SBI-трафик только потому, что пакеты расположены рядом в трассировке. Нужно одновременно учитывать Stream ID, URI, метод HTTP и статус ответа.

Как JSON и RESTful API превращают возможности 5GC в ресурсы?

HTTP/2 отвечает на вопрос, как эффективно передавать сервисный трафик. Прикладную модель SBI в 5GC фактически определяет сочетание RESTful API и ресурсно-ориентированного проектирования.

REST — это архитектурный стиль. Одна из его основных идей состоит в том, чтобы представлять бизнес-объекты как ресурсы, назначать каждому ресурсу уникальный URI, а затем использовать методы HTTP для выполнения операций над этими ресурсами.

«Ресурс» в 5GC не ограничивается объектами, которые обычно ассоциируются с веб-сайтами. Ресурсом могут быть данные абонента, SM Context, объект, связанный с PDU Session, или другое состояние, которое хранит сетевая функция.

Например, данные подписки управления доступом для абонента могут иметь один конкретный 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 — это легковесный формат обмена данными на основе структур «ключ-значение». Он может представлять строки, числа, логические значения, массивы, объекты и вложенные структуры данных.

Иными словами, DATA Frame в HTTP/2 отвечает за перенос полезной нагрузки, а JSON внутри этого Frame определяет фактический смысл прикладных данных.

С инженерной точки зрения HTTP/2 и JSON нельзя считать одним и тем же уровнем протокола. HTTP/2 организует транспорт, JSON представляет прикладные данные, а RESTful API определяют ресурсы и операции, которые можно над ними выполнять.

Как устроен URI ресурса SBI в 5GC?

После того как понятие ресурса стало ясным, структуру SBI URI понимать гораздо проще. Пути ресурсов не являются произвольными — они следуют определенной иерархии.

Типовой формат можно представить следующим образом:

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

Каждая часть выполняет свою роль:

• apiRoot: корневой адрес для доступа к сервису, обычно в форме http(s)://host(:port).

• apiName: имя конкретного SBI API или сервиса, предоставляемого сетевой функцией.

• apiVersion: версия API, например v1.

• apiSpecificResourceUriPart: путь, идентифицирующий конкретный ресурс или операцию.

Например, данные подписки управления доступом и управления сессией могут предоставляться одной и той же UDM, но использовать разные пути ресурсов. Поэтому URI позволяет точно определить, какой именно ресурс запрашивает потребитель.

Сервисы PDU Session в SMF следуют той же общей логике. Разные SM Contexts и связанные с PDU Session ресурсы имеют собственные URIs, а различные методы HTTP используются для их создания, получения, изменения или освобождения.

Такой ресурсно-ориентированный подход меняет способ анализа SBI. Вместо запоминания только традиционной последовательности вроде «Сообщение A → Сообщение B» взаимодействие SBI можно рассматривать как:

Сервис → Ресурс → Метод → URI → Код состояния → Тело JSON

Если рассматривать SBI в 5GC исключительно с традиционной телекоммуникационной точки зрения, сопоставляя имена сообщений запроса и ответа, архитектура может казаться разрозненной. Если же воспринимать ее как основанную на API ресурсную модель, логика становится гораздо понятнее.

Как инженеру отследить транзакцию SBI в Wireshark?

После понимания принципов HTTP/2 их нужно применить к реальному анализу пакетов. Поскольку одно TCP-соединение может одновременно переносить несколько HTTP/2 Streams, фильтрация только по исходному и конечному IP-адресам все еще может оставлять в одной трассировке несколько не связанных между собой транзакций SBI.

Практичный подход — сначала определить IP-адреса потребителя NF и поставщика NF, а затем сузить анализ по соответствующему Stream ID.

Например, если определенный запрос использует Stream ID 1, адрес сервера и этот Stream ID можно совместно использовать для выделения Frames, относящихся к соответствующей транзакции «запрос-ответ».

После фильтрации трафика следует обратить внимание на следующие сведения:

• Stream ID: подтверждает, относятся ли Frames к одному логическому Stream.

• HEADERS: показывает метод HTTP, путь и другие поля заголовка.

• DATA: показывает, несет ли транзакция прикладную полезную нагрузку JSON.

• Код состояния: показывает, как поставщик NF обработал запрос.

• URI: определяет точный сервис, версию API и ресурс, к которому выполняется обращение.

Полезно начинать поиск неисправности с транспортного уровня и двигаться вверх. Сначала следует подтвердить, что TCP-соединение установлено. Без TCP нет основы для HTTP/2 или взаимодействия по RESTful API.

Затем нужно убедиться, что на уровне HTTP/2 присутствуют нормальные HEADERS и DATA Frames, и использовать Stream ID для привязки их к нужной транзакции.

После этого проверяется, соответствуют ли метод HTTP и URI ожидаемой операции. Многие проблемы SBI связаны не с сетевой доступностью, а с неправильным путем ресурса, версией API или методом HTTP.

Далее следует проверить код состояния HTTP. Ответ 4xx направляет диагностику в сторону синтаксиса запроса, отсутствующих ресурсов, авторизации или параметров приложения. Ответ 5xx с большей вероятностью указывает на ошибку обработки внутри поставщика NF.

Только после подтверждения правильной доставки HTTP-запроса следует подробно анализировать полезную нагрузку JSON.

Полную последовательность диагностики SBI можно свести к следующему:

TCP → HTTP/2-соединение → Stream → HEADERS → Метод/URI → DATA/JSON → Код состояния

Такой подход превращает протокол 5GC, который поначалу может казаться слишком «интернетным», в знакомую послойную инженерную задачу. На нижнем уровне проверяется связность, на среднем — работа транспорта HTTP/2, а на верхнем — ресурсы API и бизнес-данные. Граница неисправности становится значительно понятнее.

С более общей точки зрения на архитектуру 5GC SBI использует HTTP/2 не просто потому, что он новее HTTP/1.1. Более глубокая причина состоит в том, что ядро 5G организует возможности NF в виде сервисов, поэтому ему нужна модель взаимодействия, способная эффективно поддерживать частые вызовы API, одновременное взаимодействие сервисов и ресурсно-ориентированный доступ.

HTTP/2 предоставляет Connections, Streams и Frames. Мультиплексирование повышает эффективность использования соединения, HPACK снижает объем повторяющихся заголовков, а двоичное фреймирование задает структурированный транспортный формат. JSON переносит прикладные данные, а RESTful API определяют ресурсы и выполняемые над ними операции. Вместе эти элементы образуют полную модель взаимодействия сервисного интерфейса 5GC.

Часто задаваемые вопросы

HTTP/2 и RESTful API — это одно и то же?

Нет. HTTP/2 — это транспортный протокол HTTP, определяющий такие механизмы, как Connections, Streams и Frames. REST — архитектурный стиль API, который определяет представление прикладных объектов в виде ресурсов и обращение к этим ресурсам через URI и методы HTTP. SBI в 5GC использует API в стиле RESTful поверх HTTP/2.

Может ли Stream ID 0 переносить обычный прикладной запрос SBI?

Нет. Stream ID 0 имеет особое назначение на уровне протокола и не используется как обычный прикладной Stream. При анализе реальных запросов SBI следует обращать внимание на ненулевые Stream ID, назначенные бизнес-транзакциям.

Обязательно ли apiRoot в SBI должен содержать IP-адрес?

Не обязательно. Логическая форма apiRoot — http(s)://host(:port). Значение host определяет соответствующую сервисную точку в соответствии с сетевой архитектурой и механизмом обнаружения сервисов. При анализе URI полезно отделять apiRoot от apiName, apiVersion и пути конкретного ресурса.

Если HTTP/2 использует двоичные Frames, почему внутри DATA Frames все равно виден JSON?

Двоичное фреймирование описывает способ, которым HTTP/2 организует и передает протокольные данные. Оно не требует, чтобы полезная нагрузка прикладного уровня также имела двоичный формат. DATA Frame по-прежнему может переносить JSON. JSON определяет прикладные поля 5GC, а HTTP/2 помещает эту нагрузку в соответствующий Stream для передачи.

Доказывает ли ответ HTTP 200 успешное завершение всей процедуры 5GC?

Нет. HTTP 200 означает только то, что конкретный HTTP-запрос был успешно обработан в данной точке. Полная процедура 5GC может включать несколько сервисных вызовов между разными сетевыми функциями. Прежде чем сделать вывод об успешном завершении всей сквозной процедуры, инженер должен также оценить URI, содержимое JSON и окружающую последовательность сигнализации.