Кратко

  • Принятие QUIC 0-RTT — решение TLS и транспорта, а не доказательство однократного выполнения в приложении.
  • ACK пакета подтверждает обработку транспортом, но не защиту от повторной передачи, постоянную фиксацию, аутентифицированную идентичность клиента или деловой результат.
  • Допустимое использование ранних данных определяет приложение, сохраняя раздельные записи об исполнении, идемпотентности, эффектах и результате.

QUIC 0-RTT позволяет клиенту повторно использовать конфигурацию прежнего соединения, включая билет сеанса TLS, чтобы передать данные приложения до завершения нового рукопожатия. Сервер принимает такой режим, посылая расширение TLS early_data в EncryptedExtensions. Затем он обрабатывает полученные пакеты 0-RTT и подтверждает их. Если расширение не отправлено, 0-RTT отклонён, и такие пакеты нельзя обрабатывать как принятые ранние данные.

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

QUIC 0-RTT наследует риск повторного выполнения TLS early data. Меры TLS необходимы, но не дают универсальной гарантии приложению. Обработка транспортных кадров QUIC идемпотентна: повтор кадров сам по себе не создаёт недействительное состояние соединения. Постоянные последствия появляются в прикладном смысле данных. STREAM, RESET_STREAM, STOP_SENDING и CONNECTION_CLOSE могут нести такое значение и потому быть небезопасными в 0-RTT. Протокол приложения, использующий QUIC, обязан определить допустимый профиль применения.

В HTTP заголовок Early-Data показывает, что посредник передал запрос в условиях ранних данных. Если нет более точной информации, клиент может использовать безопасные методы и не должен использовать небезопасные или неизвестные по безопасности методы. Ответ 425 Too Early означает, что сервер не готов рисковать обработкой запроса, который может быть повторно передан или выполнен. Повторная попытка сама не должна идти через early data. Ожидание завершения рукопожатия после отметки Early-Data не делает запрос безопасным задним числом; распределённые экземпляры должны применять единую политику.

Журнал доказательств должен раздельно хранить билет сеанса и запомненную конфигурацию; 0-RTT запрошен, принят или отклонён; подтверждение пакета; передачу Early-Data и обработку 425; идентификатор запроса и ключ идемпотентности; попытки выполнения; побочные эффекты; квитанцию постоянной фиксации; наблюдения повторных передач и повторных попыток; результат клиента или финансовый результат. Ключи идемпотентности, журналы транзакций и распределённые реестры повторов — операционные рекомендации, а не требования QUIC, если только их отдельно не задаёт прикладной протокол.

Вывод — не повсеместно отключать 0-RTT, а разрешать его только операциям с явно ограниченными последствиями повторной передачи. Отключение остаётся самым сильным средством защиты. Но принятие ранних данных доказывает транспортное решение, а не фиксацию транзакции.