Кратко

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

Панель мониторинга окрашивает запрос в зелёный цвет, как только несущий его пакет входит в диапазон ACK. Если это новый подтверждённый пакет, вызывающий ACK и выбранный для измерения, по нему можно получить выборку RTT; подтверждение также прекращает повторную передачу уже подтверждённой информации. Но принимающий процесс остановился до чтения: данные ещё не разобраны, не записаны и не вызвали действие. Транспортное подтверждение без оснований превратили в результат приложения.

Точная граница задана в разделе 13.1 RFC 9000. Получатель не должен подтверждать пакет, пока не снята защита и не обработан каждый кадр. Для STREAM достаточно поместить данные в очередь, подготовив их к приёму прикладным протоколом; приложение не обязано уже получить или потребить их. Значит, ACK надёжно свидетельствует об обработке в QUIC, но останавливается до прикладного потребления.

Важен и объект подтверждения. Раздел 19.3 определяет диапазоны ACK как номера полученных и обработанных пакетов в одном пространстве нумерации. Номера обозначают защищённые транспортные пакеты, а не деловые сообщения. Один пакет может содержать разные виды кадров, а одно сообщение — занимать несколько кадров STREAM.

Модель потока подчёркивает расхождение. Раздел 2.2 задаёт упорядоченный поток байтов и говорит, что границы кадров STREAM не сохраняются при передаче, повторной передаче или доставке. Раздел 3.2 отделяет Data Recvd, когда все данные потока прибыли, от Data Read, наступающего после того, как приложение прочитало все данные. Полное прибытие на транспортный уровень, начало приёма приложением и завершение чтения — разные переходы.

Видимость ACK также не образует реестр «один пакет — одна квитанция». По разделу 13.2 пакеты, вызывающие ACK, должны подтверждаться в пределах объявленной максимальной задержки с учётом правил протокола. Остальные могут ждать последующего трафика. Сам кадр ACK может потеряться, а старые диапазоны — позднее исчезнуть. Поэтому отсутствие видимого отправителю ACK не является немедленным доказательством отсутствия обработки.

При повторной передаче не сохраняется и идентичность пакета. Раздел 13.3 предписывает повторять информацию, а не весь потерянный пакет. Те же смещения STREAM могут появиться в новом кадре с новым номером пакета. Обычно повторная передача уже подтверждённой информации прекращается, когда подтверждён один из несущих её пакетов. Чтобы рассуждать о байтах, диапазон ACK нужно связать с кадрами, ID потока, смещением, длиной, FIN и историей повторов. Даже такая связь доходит лишь до транспортной очереди.

Алгоритмы восстановления сохраняют ту же область доказательства. Раздел 5.1 RFC 9002 строит выборку RTT по наибольшему новому подтверждённому пакету, вызывающему ACK, с обработкой ACK Delay. Это измерение транспортной обратной связи, а не времени работы приложения. Раздел 6.1 выводит потерю из последующих ACK и порогов по пакетам и времени, допуская переупорядочивание. Тишина не равна мгновенной потере, а ACK — успеху приложения.

Полезные свидетельства образуют лестницу. Сначала сохраняются соединение, пространство номеров, номер пакета, время отправки и ACK, ACK Delay и кадры. Затем — STREAM ID, смещения, длины, FIN, решение о потере и история повторов. Далее — постановка в очередь у получателя и чтение или уведомление процесса. Наконец — ID сообщения или транзакции, подтверждение прикладного протокола, подтверждение долговременной записи, наблюдаемый эффект и ответ.

Каждая ступень разрешает отдельный вывод: партнёр обработал защищённый пакет; байты попали в очередь QUIC; процесс их прочитал; приложение приняло сообщение; операция завершена устойчиво. Один зелёный индикатор не заменяет эти факты.

Разделение определяет и полномочия повторной попытки. Если считать ACK завершением, можно оставить работу заблокированной в очереди. Если считать невидимый ACK мгновенным сбоем, можно продублировать уже обработанную операцию. Только слой, знающий ID операции и её идемпотентность, вправе решать, безопасен ли повтор.

Квитанция QUIC сильна именно потому, что её утверждение узко. Прикладной результат должно подтвердить само приложение.