Вопросы Теги

Дополнительный байт RTMP / TCP в пакете?

Я анализирую RTMP (протокол обмена сообщениями в реальном времени) и обнаружил кое-что действительно странное. В одном из перехваченных пакетов длина полезной нагрузки TCP больше ожидаемой. Вот пакет в Wireshark: Wireshark TCP payload view

Байт C3 делает RTMP длиннее, чем ожидалось. Что неожиданно исчезло в представлении полезной нагрузки RTMP:

Wireshark RTMP payload view

Как видите,байт C3 исчез в представлении RTMP. Но это часть полезной нагрузки TCP. Я не понимаю, почему это происходит, подозреваю:

  1. Какой-то более длинный символ UTF-8?

    Согласно википедии , строка в AMF0 закодирована в 16-битный UTF-8 . Это означает, что он может быть 8/16-битным. Однако \ u33C3 и \ uC32E оба являются корейскими символами, что на втором рисунке показывает, что это не мой случай.

  2. Заполнение / escape-символ для полезной нагрузки TCP?

    Нет ... Я никогда не слышал об этом ...

  3. Что-то о TCP, чего я не знаю?

    Вот что я нашел:

    a. Это не был фрагмент сообщения RTMP, пакет TCP содержал все, что нужно сообщению RTMP.

    b. Контрольная сумма хорошая, вроде все хорошо

    c. Пакет был правильно подтвержден партнером (не показан на рисунке)

    d. Это можно воспроизвести с помощью программного обеспечения для потоковой передачи Wirecast

. Я что-то упустил? Почему Wireshark мог правильно декодировать полезную нагрузку? Почему Wireshark просто удаляет C3 (что говорит о том, что он не имеет ничего общего с кодеком AMF0)? Я так запуталась. Пожалуйста, помогите: '(

спецификации протокола RTMP здесь: https://wwwimages2.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf

0
задан 17 September 2020 в 19:01
1 ответ

О, наконец-то я понял! Согласно документу Adobe,

Максимальный размер фрагмента по умолчанию составляет 128 байт

И

5.3.1.2.4. Тип 3
Фрагменты типа 3 не имеют заголовка сообщения... Поток, состоящий из сообщений точно такого же размера, идентификатора потока и временного интервала, ДОЛЖЕН использовать этот тип для всех фрагментов после фрагмента типа 2.

( Заголовок фрагмента, также называемый "основной заголовок фрагмента", не является заголовком сообщения, они совершенно разные! )

Здесь тип 3 относится к заголовку фрагмента типа 3, в первых двух битах первого байта со значением 0b11xxxxxx.А сброс шести байтов — это идентификатор потока (здесь 3, 0bxx000011). Эти два утверждения соответствуют поведению моего вопроса: новый блок со смещением 128 байт (заголовок сообщения не учитывается) с заголовком блока типа 3 . И Wireshark правильно его разобрал. Немного сбивает с толку: они не считают заголовок блока частью сообщения, что имеет смысл. Но они рассматривали заголовок фрагмента типа 0-2 как часть сообщения (первый 0x03), что не имеет смысла.

Также я нашел ссылку здесь (поиск C3 и... вы поняли...): https://en.wikipedia.org/wiki/Real-Time_Messaging_Protocol

0
ответ дан 17 September 2020 в 17:19

Теги

Похожие вопросы