Кратко

  • QUIC DATAGRAM ненадёжно переносит одну прикладную дейтаграмму и сохраняет её границу без повторной передачи и без гарантии порядка относительно других сообщений DATAGRAM.
  • max_datagram_frame_size сообщает о направленной готовности принимать и о размере, но не о ёмкости или доставке.
  • ACK пакета подтверждает обработку на транспортном уровне, а не успех приложения или завершение операции.

Главная ошибка возникает тогда, когда успешную локальную передачу объявляют удалённой доставкой. QUIC DATAGRAM сохраняет сообщение как отдельную единицу, но не добавляет смещения потоков, упорядоченную доставку байтов или повторную передачу после обнаружения потери. Порядок сообщений DATAGRAM относительно друг друга также не гарантируется. Граница сообщения остаётся; гарантия надёжности не появляется.

Нужно различать QUIC DATAGRAM frame и UDP-дейтаграмму, которая переносит QUIC-пакет. Frame находится внутри QUIC-пакета, а пакет может находиться внутри UDP-дейтаграммы. Поэтому наличие внешнего контейнера, построение пакета или ACK дают разные свидетельства. Ни одно из них само по себе не доказывает, что сообщение обработало удалённое приложение.

max_datagram_frame_size объявляется отдельно для каждого направления. Значение по умолчанию равно нулю. Значение больше нуля означает готовность принимать соответствующие DATAGRAM frames в данном направлении с учётом условий рукопожатия и применимых правил сохранённого состояния 0-RTT. Отправитель не должен превышать объявленный предел. Но параметр не доказывает наличие памяти, способность приложения обработать данные или будущую доставку. Фактический размер может быть меньше из-за max_udp_payload_size и MTU пути. Расширение не фрагментирует DATAGRAM frames, поэтому прикладной протокол должен уметь работать с меньшим пределом.

У DATAGRAM frame нет QUIC stream ID; он относится ко всему соединению. Идентификаторы логических потоков, смысл данных, срок действия, дедупликация, требуемый порядок и условие завершения определяются приложением. Транспорт не может понять, являются ли два сообщения повтором одной бизнес-операции.

После передачи данных приложением QUIC создаёт новый frame и старается отправить его в первом доступном пакете с учётом управления перегрузкой и pacing. Если отправка пока запрещена, реализация должна удержать frame до разрешения или отбросить его до передачи. Срок, заданный приложением, также может привести к такому отбрасыванию. Поэтому успешный возврат API нужно описывать по его фактическому контракту; RFC 9221 не делает его квитанцией передачи, приёма или завершения приложения.

На стороне получателя корректный frame следует немедленно передавать приложению только при наличии возможности обработать его и удержать содержимое в памяти. DATAGRAM не предоставляет явного управления потоком и не учитывается в обычных ограничениях потока или соединения. Отсутствие блокировки по flow control не доказывает ёмкость получателя. Если получатель не может обработать frame или удержать его содержимое в памяти, он может его отбросить.

DATAGRAM frames вызывают ACK, хотя после обнаружения потери не передаются повторно. ACK может задерживаться в обычных пределах; зондирующие пакеты могут ускорить ответ. Переупорядочивание способно отменить прежнее предварительное заключение о потере. ACK доказывает обработку пакета транспортным уровнем получателя, но не обработку приложением, долговременное хранение или завершение операции приложением.

Журнал свидетельств должен отдельно хранить идентификатор сообщения, локальную передачу данных в QUIC и результат API, политику срока действия, объявленную для каждого направления готовность к приёму и эффективный размер, задержку из-за перегрузки или pacing, отбрасывание до передачи, номер пакета и пространство номеров, наблюдения ACK или потери с возможными исправлениями, обработку транспортным уровнем получателя, обработку приложением и долговременное хранение или завершение операции.