Кратко

  • Пакет QUIC с кадром DATAGRAM является ack-eliciting; полученный ACK может позволить отправителю сообщить своему приложению, что датаграмма была передана и принята.
  • Раздел 5.2 RFC 9221 ограничивает смысл такого сообщения обработкой кадра транспортным уровнем получателя и не гарантирует успешной обработки данных его приложением.

В журнале инцидента ACK часто выглядит как последняя точка. Есть номер подтверждения, есть локальное уведомление, и запись быстро превращается в «сообщение обработано». Для DATAGRAM это подмена предмета свидетельства. Стандарт подтверждает событие в транспортном механизме, а не решение, принятое прикладной логикой за его пределами.

RFC 9221 опубликован в марте 2022 года; его авторами указаны Tommy Pauly, E. Kinnear и David Schinazi. Документ добавляет в QUIC кадры DATAGRAM для ненадёжных прикладных данных. Такой кадр вызывает подтверждение. Когда подтверждён пакет, который его содержит, отправляющая реализация может уведомить своё приложение, что датаграмма была передана и принята. Это содержательный, но именно транспортный факт.

В разделе 5.2 намеренно проведён предел. ACK говорит о том, что транспортный уровень получателя обработал кадр. Он не гарантирует, что приложение получателя успешно обработало данные. Подтверждение не доказывает разбор полезной нагрузки, семантическую проверку, изменение состояния или видимый пользователю результат.

У ненадёжного DATAGRAM нет скрытого механизма, который дополнил бы этот пробел: после обнаружения потери его данные не передаются повторно. Прикладной протокол сам определяет идентификаторы мультиплексирования, смысл данных и необходимость подтверждения доставки либо обработки. Такое прикладное подтверждение будет самостоятельным объектом — с собственной корреляцией, условием успеха, сроком и способом сообщить об ошибке. Описание QUIC и восстановления после потерь в RFC 9000 и RFC 9002 не создаёт его автоматически.

Столь же узко следует понимать полученный max_datagram_frame_size. Ненулевое значение выражает готовность конечной точки принимать DATAGRAM до данного размера в этом направлении и на этом соединении. Оно не подтверждает отправку, использование, понимание или завершение работы приложением. Публикация RFC и имена авторов также не служат свидетельством того, что расширение работает в конкретной сети, продукте или конечной точке.

Подход Heng Lu о минимальной исходной спецификации здесь даёт простое правило учёта: сохранять только то детерминированное локальное утверждение, которое механизм способен проверить. Транспорт отвечает за свою обработку; парсер, хранилище состояния и пользовательский поток приложения должны отвечать за свои результаты.

Поэтому ACK не нужно обесценивать. Его нужно записывать под собственным именем. Если требуется гарантия обработки, рядом должна появиться явная прикладная квитанция с наблюдаемым условием успеха. Эти два свидетельства могут совпасть по времени и объекту, но одно не становится другим.

Источники