Кратко

  • PADDING — фрейм из одного байта без содержимого и смыслового значения; он добавляет байты, но не переносит данные приложения, STREAM или CRYPTO.
  • Пакет только с PADDING находится в полёте и расходует окно перегрузки, не вызывая ACK, необходимый для его открытия; RFC 9000 указывает, что отправитель SHOULD периодически добавлять другие ack-eliciting фреймы.
  • Клиент MUST расширить до 1200 байт каждую UDP-дейтаграмму с Initial; сервер MUST делать это только для дейтаграммы с ack-eliciting Initial-пакетом. Ни одно из этих правил не доказывает прогресс.

Оператор видит UDP-дейтаграмму размером 1200 байт и отмечает полезно отправленный Initial. Затем растут байты в полёте, и система объявляет о продвижении. Так смешиваются разные виды свидетельств: длина UDP-дейтаграммы; границы и типы QUIC-пакетов; число байт PADDING; наличие фреймов, вызывающих ACK; байты в полёте; изменения окна перегрузки; ACK; состояние рукопожатия; и результат приложения.

Фрейм QUIC PADDING имеет тип 0x00 и состоит только из идентифицирующего байта. У него нет содержимого и смыслового значения. Он может увеличить размер пакета, довести Initial до требуемого размера и сократить часть информации, доступной анализу трафика. Но PADDING не переносит данные приложения, STREAM, CRYPTO, квитанцию, результат или сигнал завершения. Его байты сами по себе не доказывают полезную обработку узлом, продвижение рукопожатия или доставку приложению.

Дейтаграмма может содержать Initial с PADDING и другими фреймами либо несколько объединённых QUIC-пакетов. По одной длине нельзя определить, какие байты продвинули рукопожатие. Нужен разрешённый разбор границ пакетов и защищённой структуры фреймов. Пакет с PADDING может также содержать ack-eliciting фрейм и получить ACK. Такой ACK доказывает только обработку пакета в пределах семантики QUIC и не превращает PADDING в содержание рукопожатия или приложения.

Ack-eliciting пакет содержит фрейм, отличный от ACK, PADDING и CONNECTION_CLOSE. Один лишь PADDING не приводит к тому, что получатель отправляет ACK. Пакет с PADDING всё же считается находящимся в полёте для контроля перегрузки. Пакет только с PADDING расходует окно, но не создаёт ACK, который его открыл бы. Поэтому RFC 9000 говорит, что отправитель SHOULD периодически добавлять другие ack-eliciting фреймы. Рост байтов в полёте нельзя автоматически считать полезным продвижением.

Правило 1200 байт имеет ограниченную область действия. Клиент MUST расширить каждую UDP-дейтаграмму с Initial минимум до 1200 байт, используя PADDING или объединение пакетов. Сервер MUST сделать то же для дейтаграммы с ack-eliciting Initial-пакетом. Правило проверяет поддержку разумной MTU пути; расширение со стороны клиента также уменьшает доступное серверу усиление до проверки адреса. Это не минимальный объём данных рукопожатия и не означает, что каждый Initial использует PADDING.

До проверки адреса сервер включает в трёхкратный лимит защиты от усиления все UDP-байты нагрузки, однозначно относящиеся к соединению, включая PADDING. Отсутствие смысла не делает байты бесплатными. PADDING может менять видимый размер и сокращать часть сведений для анализа трафика, но не гарантирует приватность и не скрывает время, направление, число пакетов или все длины. Защищённое хранение минимально необходимой доказательной информации и отдельный журнал — редакционные рекомендации, а не требования QUIC.