live-common: Общий модуль NGINX для Kaltura Media Framework

Установка

Вы можете установить этот модуль в любой дистрибутив, основанный на RHEL, включая, но не ограничиваясь:

RedHat Enterprise Linux 7, 8, 9 и 10
CentOS 7, 8, 9
AlmaLinux 8, 9
Rocky Linux 8, 9
Amazon Linux 2 и Amazon Linux 2023

CentOS/RHEL 8+, Fedora Linux, Amazon Linux 2023+CentOS/RHEL 7 и Amazon Linux 2

dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-live-common

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-live-common

Включите модуль, добавив следующее в начало файла /etc/nginx/nginx.conf:

load_module modules/ngx_http_api_module.so;

Этот документ описывает nginx-module-live-common v2.0.6, выпущенный 13 ноября 2025 года.

Распределенная платформа для потоковой передачи видео в реальном времени. Система состоит из нескольких компонентов, каждый из которых отвечает за определенную функцию.

Компоненты могут быть развернуты на одном сервере для небольших развертываний/тестирования, но рекомендуется развертывать их отдельно для более оптимального использования ресурсов. Например, транскодер может использовать GPU, поэтому будет более экономически эффективно развернуть транскодеры на серверах с поддержкой GPU, в то время как другие компоненты будут работать на серверах без GPU.

Медиа передается между различными компонентами внутренне с использованием пользовательских протоколов - 1. Kaltura Media Protocol (KMP) - протокол на основе TCP для доставки потокового медиа, концептуально аналогичный одной дорожке fMP4/MPEG-TS 2. Kaltura Segmented Media Protocol (KSMP) - протокол на основе HTTP для доставки медиа в сегментах, концептуально, суперсет LLHLS/DASH

Оркестрация различных медиа-компонентов выполняется "контроллером". Основная ответственность контроллера заключается в построении топологии медиа-пайплайна и обновлении ее в случае сбоев. Контроллер получает JSON-события от медиа-компонентов, отправленные в виде HTTP-POST. Кроме того, все компоненты обработки медиа предоставляют JSON-ориентированный REST API, который используется контроллером для получения последнего статуса и выполнения действий. Пример реализации контроллера для сервера "всё в одном" предоставлен в папке conf.

Основные функции

Протоколы публикации: RTMP, MPEGTS (по SRT/HTTP/TCP)
Протоколы воспроизведения: HLS/LLHLS, DASH
Протоколы живой передачи/ретрансляции: RTMP
Транскодирование видео/аудио - включая поддержку GPU, основанное на API ffmpeg
Хранение - в объектном хранилище S3 (или совместимом)
Доставка с адаптивной битрейтом
Поддержка субтитров - включая преобразование 608/708 в WebVTT
Альтернативное аудио
Шифрование медиа и DRM
Захват видеофреймов

Начало работы

Папка conf содержит пример кода и конфигурацию для запуска сервера "всё в одном".

Глоссарий

Канал - контейнер, представляющий поток в реальном времени, может содержать дорожки, варианты, временные линии и т.д.
Дорожка - одна версия видео/аудио/субтитров. Например, канал может иметь 3 видеодорожки: 1080p, 720p, 540p.
Вариант - группа дорожек, используемая для упаковки. Варианты определяют, какая аудиодорожка будет сопоставлена каждой видеодорожке, когда используются мультиплексированные сегменты. Вариант может указывать на несколько дорожек, но не более одной дорожки на тип медиа. Дорожки должны быть связаны с вариантами, чтобы быть доставленными через HLS/DASH.
Сегмент - группа кадров конкретной дорожки. Сегменты всегда независимы - видеосегменты всегда начинаются с ключевого/IDR кадра.
Индекс сегмента - число, идентифицирующее сегменты различных дорожек, которые связаны с конкретным временным интервалом.
Период - набор индексов сегментов, которые могут воспроизводиться непрерывно.
Временная линия - набор периодов. Можно создать несколько временных линий, каждая со своим набором периодов. Временные линии могут использоваться, например, для реализации "предварительного просмотра" - издатель использует одну временную линию, в то время как зрители используют другую. Временная линия издателя всегда активна, в то время как временная линия зрителей активируется по усмотрению издателя.

Примеры топологий

Диаграммы ниже демонстрируют несколько примеров топологий, которые можно создать с использованием компонентов Media-Framework.

Простой RTMP-проход

flowchart LR;
    enc(Encoder);
    ingest(nginx-rtmp-kmp-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Player);
    enc-->|RTMP|ingest;
    ingest-->|KMP|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Проход + Хранение в S3

flowchart LR;
    enc(Encoder);
    ingest(nginx-rtmp-kmp-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    s3(Amazon S3);
    play(Player);
    enc-->|RTMP|ingest;
    ingest-->|KMP|live;
    live-->|HTTP|s3;
    s3-->|HTTP|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Вход SRT + Транскодирование видео

flowchart LR;
    enc(Encoder);
    ingest(nginx-mpegts-kmp-module);
    srt(nginx-srt-module);
    trans(transcoder);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Player);
    enc-->|SRT|srt;
    srt-->|MPEG-TS|ingest;
    ingest-->|KMP video|trans;
    trans-->|KMP video|live;
    ingest-->|KMP audio|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Декодирование закрытых субтитров

flowchart LR;
    enc(Encoder);
    ingest(nginx-rtmp-kmp-module);
    cc(nginx-cc-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Player);
    enc-->|RTMP|ingest;
    ingest-->|KMP video|cc;
    cc-->|KMP subtitle|live;
    ingest-->|KMP video|live;
    ingest-->|KMP audio|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Транскодирование + RTMP Push

flowchart LR;
    enc(Encoder);
    ingest(nginx-mpegts-kmp-module);
    trans(transcoder);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    push(nginx-kmp-rtmp-module);
    yt(YouTube);
    play(Player);
    enc-->|MPEG-TS/HTTP|ingest;
    ingest-->|KMP|trans;
    trans-->|KMP|live;
    trans-->|KMP|push;
    push-->|RTMP|yt;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Обзор компонентов

Медиа-компоненты

nginx-rtmp-kmp-module - потоковая передача медиа в реальном времени, вход: RTMP, выход: KMP x N
nginx-mpegts-kmp-module - потоковая передача медиа в реальном времени, вход: MPEG-TS по TCP/HTTP, выход: KMP x N
transcoder - транскодирование видео/аудио, вход: KMP, выход: KMP x N
nginx-live-module - сегментация медиа в реальном времени, вход: KMP x N, выход: KSMP

Дополнительные функции: хранение, заполнитель, поддержка временных линий.
nginx-pckg-module - упаковка медиа в реальном времени (без состояния), вход: KSMP, выход: HLS/LLHLS, DASH

Дополнительные функции: адаптивный битрейт, субтитры, альтернативное аудио, шифрование медиа / DRM, захват видеофреймов
nginx-kmp-cc-module - декодер закрытых субтитров, вход: KMP video (h264/5), выход: KMP subtitle (WebVTT) x N
nginx-kmp-rtmp-module - ретрансляция медиа в реальном времени, вход: KMP x N, выход: RTMP

Важно: Все компоненты на основе nginx с состоянием (= все, кроме nginx-pckg-module) должны быть развернуты на одном сервере nginx с одним процессом (worker_processes 1;). Состояние модуля сохраняется на процесс, и при использовании нескольких процессов невозможно контролировать, какой процесс получит запрос. Например, запрос на создание канала на сегментаторе может поступить на рабочий процесс 1, в то время как соединение KMP с фактическим медиа попадет на рабочий процесс 2. В развертываниях, использующих контейнеры, это не должно быть проблемой - несколько контейнеров могут быть развернуты на одном сервере, вместо использования нескольких процессов nginx. Другой возможностью является использование патча, такого как per-worker listener от arut, но, вероятно, его нужно будет обновить, чтобы применить к соединениям stream.

Опции отладки

Некоторые компоненты Media-Framework поддерживают необязательные макросы препроцессора для целей отладки - - NGX_LBA_SKIP (nginx-common) - Пропускает использование модуля "Large Buffer Array" (LBA). Когда включено, выделения LBA перенаправляются на ngx_alloc / ngx_free. - NGX_RTMP_VERBOSE (nginx-rtmp-module) - Включает дополнительные сообщения отладочного журнала - NGX_LIVE_VALIDATIONS (nginx-live-module) - Включает проверки согласованности на внутренних структурах данных, включено по умолчанию при использовании --with-debug - NGX_BLOCK_POOL_SKIP (nginx-live-module) - Пропускает использование пулов блоков. Когда включено, выделения пулов блоков перенаправляются на ngx_palloc / ngx_pfree.

Для тестирования модулей с valgrind рекомендуется применить патч no-pool-nginx и настроить nginx с --with-cc-opt="-O0 -DNGX_BLOCK_POOL_SKIP -DNGX_LBA_SKIP" и --with-debug.

Kaltura Media Protocol (KMP)

Kaltura Media Protocol - это простой пакетный протокол для потоковой передачи медиа по TCP. Соединение KMP может доставлять медиа одной видеодорожки/аудиодорожки/субтитров - когда требуется несколько дорожек, устанавливаются несколько TCP-соединений.

Каждый пакет начинается с заголовка, который содержит следующие поля (по 32 бита каждое) - - Тип - тип пакета. Типы пакетов - это четырехсимвольные коды, ниже приведен список в настоящее время определенных типов. - Размер заголовка - размер заголовка пакета, должен быть между sizeof(kmp_packet_header_t) и 64KB. Парсеры должны использовать размер заголовка для доступа к данным пакета, это позволяет добавлять новые поля в заголовки пакетов без нарушения работы существующих парсеров. - Размер данных - размер данных пакета, должен быть между 0 и 16MB. - Зарезервировано - зарезервировано для будущего использования, должно быть установлено в 0.

Структуры и константы, используемые в KMP, можно найти в ngx_live_kmp.h.

Идентификаторы KMP фреймов

Идентификатор фрейма - это 64-битное целое число, которое уникально идентифицирует входной фрейм. Модули захвата (nginx-rtmp-kmp-module / nginx-mpegts-kmp-module) выделяют начальный идентификатор фрейма в соответствии с системными часами (в единицах временной шкалы), когда создается выходная дорожка. Чтобы избежать необходимости отправлять идентификатор фрейма для каждого отправляемого фрейма, идентификаторы фреймов в KMP являются последовательными - идентификатор N-го фрейма, отправленного по соединению KMP, равен initial_frame_id + N.

Если входное соединение (например, RTMP) обрывается и восстанавливается, будут выделены новые идентификаторы KMP фреймов. Поскольку стандартная временная шкала высока (90 кГц), а частота кадров вряд ли превысит 60 кадров в секунду, даже в случае повторного подключения после короткого периода потоковой передачи, начальный идентификатор фрейма будет значительно выше, чем идентификатор фрейма, который был последний раз отправлен по предыдущему соединению. Таким образом, крайне маловероятно, что возникнет конфликт с любыми ранее использованными идентификаторами фреймов из-за повторного подключения.

Идентификаторы фреймов используются: - Для идентификации, какие фреймы подтверждаются в KMP ack пакетах - Для пропуска ранее обработанных фреймов, если соединение KMP восстанавливается

Транскодер добавляет несколько сложностей к управлению идентификаторами фреймов - - Поскольку транскодер может изменить частоту входных фреймов или пропустить фреймы, идентификаторы фреймов во входе транскодера не обязательно совпадают с идентификаторами фреймов на выходе транскодера. Если транскодер перезапускается, ему нужно знать, какое значение отправить в качестве initial_frame_id своего вышестоящего сервера (обычно nginx-live-module). Для этой цели используется поле upstream_frame_id. - Транскодер может быть настроен на изменение частоты дискретизации аудиодорожки, и в этом случае транскодированные фреймы не совпадают с входными фреймами. Чтобы справиться с этой ситуацией, транскодер должен иметь возможность подтверждать только часть входного фрейма. Для этого предназначено поле offset - оно может хранить, например, количество аудиосэмплов, которые должны быть подтверждены в рамках фрейма. Точное значение поля offset определяется приемником KMP - приемник устанавливает offset в ack фреймах, которые он возвращает, и получает его обратно в поле initial_offset пакета подключения в случае повторного подключения.

Пакеты KMP издателя

В следующих разделах перечислены пакеты KMP, которые могут быть отправлены издателем KMP.

Подключение (`cnct`)

Отправляется сразу после установления TCP-соединения KMP.

Заголовок содержит следующие поля: - channel_id - строка, идентификатор канала, который публикуется. Максимально допустимая длина - 32 символа. - track_id - строка, идентификатор дорожки, которая публикуется. Максимально допустимая длина - 32 символа. - initial_frame_id - целое число, идентификатор первого отправляемого фрейма. - initial_upstream_frame_id - целое число, начальный идентификатор фрейма, который должен быть отправлен на вышестоящий сервер (используется транскодером) - initial_offset - целое число, смещение, с которого начинать, внутри начального фрейма. - flags - целое число, битовая маска флагов, в настоящее время определен один флаг - consistent - этот флаг устанавливается, когда издатель KMP генерирует согласованный (битовый) выход, при одинаковом входе. nginx-rtmp-kmp-module и nginx-mpegts-kmp-module являются примерами издателей, которые являются согласованными. Транскодер, с другой стороны, не является таковым. Флаг consistent используется LL-сегментатором в случае повторного подключения. Когда издатель согласован, LL-сегментатор может продолжить с точки, на которой он остановился. Когда издатель несогласован, LL-сегментатор может продолжить только с следующего GOP - он не должен смешивать частичный GOP до отключения с GOP, полученным после отключения.

Данные пакета подключения являются необязательными, ожидаемый формат данных определяется конкретным приемником KMP.

Информация о медиа (`minf`)

Содержит параметры медиа. Некоторые поля в заголовке общие для всех типов медиа, в то время как остальные определены только для конкретного типа (объединение).

Общие поля заголовка: - media_type - целое число, тип медиа - video / audio / subtitle, использует константы KMP_MEDIA_XXX. - codec_id - целое число, идентификатор кодека, использует константы KMP_CODEC_XXX. - timescale - целое число, единицы, используемые в полях dts / pts_delay / created пакетов фреймов, в Гц. - bitrate - целое число, битрейт, в битах в секунду.

Специфичные для видео поля заголовка: - width - целое число, ширина видео, в пикселях. - height - целое число, высота видео, в пикселях. - frame_rate - рациональное число, частота кадров видео, в кадрах в секунду. - cea_captions - булевое значение, устанавливается в 1, когда видеодорожка содержит субтитры EIA-608 / CTA-708.

Специфичные для аудио поля заголовка: - channels - целое число, количество аудиоканалов. - bits_per_sample - целое число, размер аудиосэмплов, в битах. - sample_rate - целое число, частота дискретизации аудио, в сэмплах в секунду. - channel_layout - целое число, битовая маска позиций каналов, использует константы KMP_CH_XXX.

Данные пакета информации о медиа содержат приватные/дополнительные данные кодека. Например, при использовании кодека h264 данные содержат тело MP4-бокса avcC.

Приемники KMP должны обрабатывать изменения информации о медиа, например, изменение разрешения видео. Однако тип медиа (видео/аудио/субтитры), который отправляется в соединении KMP, не должен изменяться.

Приемники KMP должны игнорировать пакеты информации о медиа, когда они идентичны ранее полученному пакету информации о медиа.

Фрейм (`fram`)

Представляет собой один видеофрейм / аудиофрейм / субтитры.

Заголовок фрейма содержит следующие поля: - created - целое число, время, в которое фрейм был получен первым модулем Media-Framework в пайплайне, в единицах временной шкалы. - dts - целое число, временная метка декодирования фрейма, в единицах временной шкалы. Когда тип медиа - subtitle, содержит начальную временную метку подсказки. - flags - целое число, в настоящее время определен только один флаг - key - включен для ключевых кадров видео. - pts_delay - целое число, разница между временной меткой представления фрейма и временной меткой декодирования, в единицах временной шкалы. Когда тип медиа - subtitle, содержит продолжительность подсказки - end_pts - start_pts.

Когда тип медиа - видео / аудио, данные пакета фрейма содержат сжатое медиа. Когда тип медиа - субтитры и кодек - WebVTT, данные фрейма следуют формату образца WebVTT, как указано в ISO/IEC 14496-30 (обычно в этом случае образец - это боксы vttc, которые содержат боксы payl).

Нулевой (`null`)

Отправляется для сигнализации о "живом" состоянии и предотвращения истечения таймеров бездействия. Нулевые пакеты не содержат никаких данных, кроме основного заголовка KMP. Парсеры должны игнорировать нулевые пакеты.

Конец потока (`eost`)

Используется для сигнализации о корректном завершении сессии публикации. Пакеты конца потока не содержат никаких данных, кроме основного заголовка KMP.

Пакеты KMP приемника

В следующих разделах перечислены пакеты KMP, которые могут быть отправлены приемником KMP.

Подтверждение фреймов (`ackf`)

Подтверждает получение фреймов.

Приемник KMP решает, когда отправить пакет подтверждения. Например, когда включено хранение, сегментатор отправляет подтверждение только после того, как сегмент, содержащий фрейм, сохранен в хранилище.

Некоторые приемники вообще не отправляют подтверждения, в этом случае производитель KMP должен быть настроен на отбрасывание фреймов после их отправки (с использованием настройки resume_from).

Заголовок пакета содержит следующие поля: - frame_id - целое число, идентификатор первого фрейма, который должен быть повторно отправлен, если соединение обрывается. Другими словами, пакет подтверждения фреймов подтверждает все фреймы, идентификатор которых меньше frame_id. Если соединение KMP восстанавливается, это значение будет отправлено в поле initial_frame_id. - upstream_frame_id - целое число, идентификатор фрейма, который был отправлен на вышестоящий сервер. Если соединение KMP восстанавливается, это значение будет отправлено в поле initial_upstream_frame_id. - offset - целое число, смещение для подтверждения внутри фрейма. Если соединение KMP восстанавливается, это значение будет отправлено в поле initial_offset. - padding - целое число, зарезервировано для будущего использования, должно быть установлено в ноль.

Данные пакетов подтверждения не используются.

Kaltura Segmented Media Protocol (KSMP)

Kaltura Segmented Media Protocol - это протокол на основе HTTP для доставки медиа в сегментах, аналогично HLS/DASH.

Запрос KSMP - это HTTP GET запрос, определены следующие параметры запроса - - channel_id - обязательная строка, идентификатор канала - timeline_id - обязательная строка, идентификатор временной линии - flags - обязательное шестнадцатеричное целое число, флаги: - Выбор подмножества данных, которые необходимы (как список столбцов в SQL SELECT запросе) - Управление различными поведениями при обслуживании запроса. Например, флаг 'closest key' возвращает только ключевой кадр, который ближе всего к временной метке запроса, вместо того чтобы возвращать весь сегмент. - variant_ids - необязательная строка, выбирает подмножество вариантов, которые должны быть возвращены, по умолчанию возвращаются все варианты. Если указано несколько вариантов, они должны быть разделены дефисом (-). - media_type_mask - необязательное шестнадцатеричное целое число, устанавливает типы медиа, которые должны быть возвращены, по умолчанию возвращаются все типы медиа. - time - необязательное целое число, запрашиваемая временная метка. Временная метка используется, например, для захвата видеокадра в определенное время. - segment_index - необязательное целое число, индекс сегмента - max_segment_index - необязательное целое число, используется для ограничения объема сегментов, возвращаемых в ответе. Этот параметр можно использовать для повторного воспроизведения сохраненного потока для отладки. - part_index - необязательное целое число, индекс частичного сегмента внутри сегмента, начиная с нуля. Запрос, использующий part_index, должен также отправить segment_index. - skip_boundary_percent - необязательное целое число, устанавливает значение skip boundary как процент от target duration (см. определение атрибута CAN-SKIP-UNTIL в спецификации HLS для получения дополнительных сведений) - padding - необязательное целое число, добавляет дополнительные нулевые байты в конце ответа. Используется для соблюдения требований по дополнению ffmpeg без дополнительных операций копирования.

Ответ KSMP использует формат KLPF (см. ниже) с типом Serve (serv). Специфические определения KSMP можно найти в ngx_ksmp.h.

Kaltura Live Persist File (KLPF)

Kaltura Live Persist File - это схема сериализации, которая используется в ответах KSMP и в объектах S3, созданных модулем nginx-live-module.

KLPF состоит из блоков, аналогично атомам/боксам MP4. Каждый блок имеет следующий заголовок - - id - четырехсимвольный код, идентифицирующий блок - size - uint32, полный размер блока (заголовок и данные) - flags - 4 бита, определены следующие флаги: - container (0x1) - блок содержит другие блоки - index (0x2) - блок является индексом к другому блоку, размер заголовка не должен использоваться - compressed (0x4) - данные блока сжаты с помощью zlib - header_size - 28 бит, размер заголовка блока. Парсеры должны использовать размер заголовка для доступа к данным блока, чтобы можно было добавлять поля в заголовок без нарушения совместимости.

Файл KLPF - это блок, идентификатор которого установлен в klpf. После общих полей заголовка блока (перечисленных выше) файл KLPF имеет следующие поля в своем заголовке - - uncomp_size - uint32, содержит несжатый размер данных, когда данные KLPF сжаты - version - uint32, версия формата файла. Версия, используемая для новых файлов, обновляется при каждом нарушении формата, код будет обновлен, чтобы либо поддерживать чтение как нового формата, так и старого формата, либо игнорировать файлы, использующие старый формат - type - четырехсимвольный код, который идентифицирует тип данных, хранящихся в KLPF. Тип определяет, какие идентификаторы блоков поддерживаются, и их внутреннюю структуру. Тип serv (Serve) используется для ответов KSMP, в общении между упаковщиком и сегментатором. Дополнительные типы используются внутренне сегментатором. - created - uint64, метка времени unix, когда KLPF был создан.

Для получения дополнительных сведений о внутренней структуре блоков KLPF см. KLFP-SPEC.md.

Чтобы просмотреть содержимое объектов KLPF/ответов KSMP, используйте klpf_parse.py. Скрипт может показать структуру блока без какой-либо дополнительной информации, однако, чтобы разобрать поля внутри блоков: - запустите generate_persist_spec.py и сохраните вывод в файл - предоставьте имя файла klpf_parse.py с помощью параметра -s / --spec-file.

Обзор API

Все компоненты обработки медиа предоставляют JSON-ориентированный REST API. Этот раздел объясняет общие свойства API Media-Framework. Для подробной справки по доступным конечным точкам API смотрите документацию конкретных модулей.

Типы запросов

В API используются следующие HTTP-методы: - GET - получить полный статус модуля или его подмножество. К запросу можно добавить аргумент ?pretty=1, чтобы вернуть ответ в "красивом" / отформатированном виде. - GET с ?list=1 - вернуть имена "папок" под определенным путем в API. Может использоваться для обхода дерева возможных маршрутов API. - POST - создать объект. - PUT - обновить объект, идентификатор объекта для обновления передается в URI. - DELETE - удалить объект, идентификатор объекта для удаления передается в URI.

Тело запроса в запросах POST / PUT должно быть в формате JSON (обычно объект), и запрос должен использовать заголовок Content-Type: application/json.

Когда размер тела запроса превышает определенный порог, nginx записывает его во временный файл. Однако реализация API Media-Framework требует, чтобы тело запроса POST / PUT было доступно в памяти. При необходимости можно использовать директиву nginx client_body_buffer_size, чтобы увеличить размер буфера, выделенного для тела запроса.

Мульти-запрос

Настройка канала в nginx-live-module может потребовать нескольких вызовов API - создать канал, создать временную линию, создать вариант и т.д. Чтобы избежать штрафа за несколько круговых поездок, уровень API поддерживает "мульти" запросы. Мульти-запрос объединяет несколько запросов API в одном HTTP-запросе.

Мульти-запросы должны использовать метод POST, а их URI должен быть установлен на /multi. Тело запроса должно быть JSON-массивом объектов, каждый объект представляет собой один запрос API.

Объекты содержат следующие поля: - uri - строка, обязательное, относительный путь API. - method - строка, обязательное, HTTP-метод запроса - GET / POST / PUT / DELETE. - body - любой (обычно объект), необязательное, тело запросов POST / PUT.

Ответ мульти-запросов также является JSON-массивом объектов. Количество элементов в массиве ответа всегда соответствует количеству элементов в массиве запроса, и порядок объектов в массиве ответа соответствует порядку в массиве запроса. Другими словами, N-й элемент массива ответа - это ответ N-го запроса в массиве запроса.

Каждый объект ответа содержит следующие поля: - code - целое число, обязательное, HTTP-статус код - body - любой (обычно объект / массив), необязательное, тело ответа

GitHub

Вы можете найти дополнительные советы по конфигурации и документацию для этого модуля в репозитории GitHub для nginx-module-live-common.