Кратко

  • STREAM задаёт диапазон байтов в одном упорядоченном потоке через stream ID, смещение и поля кодирования.
  • При передаче, восстановлении после потери и доставке приложению исходные границы кадра не сохраняются.
  • Для вывода о сообщении или транзакции нужны прикладное кадрирование, результат разбора и подтверждение обработки.

Ошибка возникает, когда наблюдение на уровне транспорта превращают в утверждение об операции приложения. Экспортёр показывает полный кадр STREAM, и оператор записывает одну завершённую заявку. Но кадр означает прежде всего, что для конкретного потока закодирован определённый диапазон байтов в определённом месте. Он не объявляет этот диапазон сообщением или транзакцией.

RFC 9000 описывает потоки как упорядоченные последовательности байтов, доступные приложению. Получатель размещает данные с помощью stream ID и Offset. Порядок действует внутри одного потока. Байты разных stream ID не получают общего порядка исполнения только потому, что захват вывел их в определённой последовательности. Порядок строк в трассировке не является порядком работы приложения.

OFF, LEN и FIN относятся к транспортному кодированию. OFF показывает наличие Offset; без него данные начинаются со смещения ноль. LEN показывает наличие Length; без него данные занимают остаток пакета. FIN устанавливает конечную границу байтов потока, а итоговый размер выводится из смещения и длины данных. Эти поля не задают синтаксис приложения, границу записи, факт обработки или успех.

При потере QUIC не передаёт потерянный пакет целиком и не восстанавливает прежнее разбиение кадров. Информация потока отправляется повторно в новых кадрах STREAM. Поздний кадр может покрывать другой диапазон, сохраняя те же логические байты. Поэтому исходная форма кадра не является постоянной границей сообщения. Дубликаты диапазонов допустимы и могут быть отброшены; содержимое байтов по одному смещению не должно меняться. Другие байты по тому же смещению означали бы нарушение протокола.

Конечная точка ДОЛЖНА быть способна буферизовать данные потока, пришедшие не по порядку, до объявленного ограничения управления потоком, чтобы выдать упорядоченный поток. Возможность реализации передавать приложению сведения о доставке вне порядка является отдельной и необязательной; QUIC её не требует. QUIC не задаёт единой модели сообщений. Прикладной протокол может распределить сообщение по нескольким кадрам, поместить несколько структур в один переносимый диапазон или передать только часть структуры. FIN закрывает направление потока, но не доказывает корректность, разбор, выполнение, фиксацию или успех.

В журнале следует раздельно хранить ID и время наблюдения, направление конечных точек, packet number space и packet number, stream ID и направление, смещение, кодированную длину или правило остатка пакета, отпечаток диапазона, FIN и известный конечный размер, обработку дубликатов, отслеживание повторной передачи, сведения о подтверждении, завершение сборки, идентификатор прикладной записи, результат парсера, квитанцию обработки и устойчивый бизнес-результат. При отсутствии необходимости хранить содержимое можно использовать безопасные для приватности отпечатки. Такой журнал является операционной рекомендацией, а не требованием QUIC.

Граница доказательства узка. STREAM подтверждает кодирование диапазона байтов для потока, а аутентифицированная обработка пакетов может дополнить доказательство получения транспортной конечной точкой. Но кадр сам по себе не доказывает сообщение, запрос, ответ, выполнение, долговременную фиксацию или успех, а также не устанавливает порядок между потоками. Границы сообщений, конечный размер, диапазоны криптографических данных и свидетельства ACK остаются разными вопросами доказательства.