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.1.0 выпущенный 11 июня 2026 года.

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

Компоненты могут быть развернуты на одном сервере для небольших развертываний/тестирования, но рекомендуется развертывать их отдельно для более оптимального использования ресурсов. Например, транскодер может использовать 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-based 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(Кодировщик);
    ingest(nginx-rtmp-kmp-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Игрок);
    enc-->|RTMP|ingest;
    ingest-->|KMP|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

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

flowchart LR;
    enc(Кодировщик);
    ingest(nginx-rtmp-kmp-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    s3(Amazon S3);
    play(Игрок);
    enc-->|RTMP|ingest;
    ingest-->|KMP|live;
    live-->|HTTP|s3;
    s3-->|HTTP|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

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

flowchart LR;
    enc(Кодировщик);
    ingest(nginx-mpegts-kmp-module);
    srt(nginx-srt-module);
    trans(транскодер);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Игрок);
    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(Кодировщик);
    ingest(nginx-rtmp-kmp-module);
    cc(nginx-cc-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Игрок);
    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(Кодировщик);
    ingest(nginx-mpegts-kmp-module);
    trans(транскодер);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    push(nginx-kmp-rtmp-module);
    yt(YouTube);
    play(Игрок);
    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
транскодер - транскодирование видео/аудио, вход: 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 (KMP)

Протокол Kaltura Media - это простой пакетный протокол для потоковой передачи медиа по 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. Поскольку стандартная временная шкала высокая (90kHz), а частота кадров вряд ли превысит 60fps, даже в случае переподключения после короткого периода потоковой передачи, начальный идентификатор кадра будет значительно выше, чем идентификатор кадра, который был последним отправлен на предыдущем соединении. Таким образом, крайне маловероятно, что возникнет конфликт с любыми ранее использованными идентификаторами кадров из-за переподключения.

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

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

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

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

Соединение (`cnct`)

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

Заголовок содержит следующие поля: - 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 (KSMP)

Протокол Kaltura Segmented Media - это протокол на основе 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-based 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.