QUIC idle timeout не задаёт срок выполнения запроса
Фотография конкретного исполнения не приложена.
Соединение может оставаться активным благодаря транспортным пакетам, пока полезная операция не продвигается. Обратная ситуация тоже возможна: редкий клиент теряет тихий сеанс между запросами. Эти сценарии требуют разных правил ожидания.
RFC 9000 вычисляет effective idle timeout из объявленных сторонами значений по предусмотренным правилам. Таймер обновляется при определённой активности, а не только при появлении полезного ответа. Также протокол учитывает PTO, чтобы слишком короткое ожидание не обрывало нормальные попытки восстановления.
PING способен поддерживать транспортную активность, но не доказывает работоспособность прикладного обработчика. Поэтому keepalive-policy нельзя считать готовым deadline запроса. Срок соединения и допустимое время бизнес-операции должны быть согласованы отдельно.
В приёмке проверяют тихое соединение, возобновление после паузы и зависшую обработку при живом transport. Сохраняют фактические параметры обеих сторон. Отчёт должен объяснять, кто завершает ожидание в каждом случае. Только отсутствие idle close не подтверждает, что сервер выполнил запрос или что приложение сможет ждать его результат бесконечно без ущерба ресурсам.
Основание — Numbered QUIC/HTTP3/QPACK RFCs; base version1 and version2 extension identified per task, разделы RFC9000 10.1 Idle Timeout; liveness testing; max_idle_timeout. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC QUIC, HTTP/3 и расширений. Реальная поддержка версий, транспортные параметры, библиотека и настройки сети не проверялись. Это план интерпретации и приёмки; пакеты, рабочие соединения, firewall и сервисы не изменялись.
Запросы отправляются на наш e-mail из вашей почтовой программы.
