# HTTP/2 GOAWAY при обновлении inference endpoint

Как проверять HTTP/2 GOAWAY при обновлении inference endpoint: last-stream-ID, принятые запросы, неоднозначный POST и ограниченный draining-тест.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-http2-goaway-draining/
Language: ru

Одно HTTP/2-соединение может обслуживать несколько потоков. Поэтому его закрытие при rollout нельзя анализировать как завершение ровно одного inference-запроса. GOAWAY сообщает о прекращении использования соединения в определённых границах, но прикладной результат каждой генерации требует собственного учёта. Для провайдера полезен небольшой тест draining, который связывает транспортный сигнал, допуск новых запросов и судьбу уже открытых ответов.

## Разделите соединение и stream

[RFC 9113](https://www.rfc-editor.org/rfc/rfc9113.html) описывает HTTP/2 streams и GOAWAY, включая last-stream-ID. Этот идентификатор помогает определить границу обработки на конкретном соединении. Он не является model request ID и не должен подменять прикладной идентификатор генерации в журнале сервиса.

Сохраните карту соответствий между клиентской операцией и транспортным stream, если тестовая инфраструктура позволяет её наблюдать. Не делайте вывод о судьбе всех запросов по одному закрывшемуся socket. Некоторые операции могли уже завершиться, другие продолжать обработку, а новые больше не должны приниматься через уходящий путь.

## Опишите поведение при rollout

[Kubernetes документирует termination flow](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/), в котором readiness и состояние endpoints участвуют в выводе экземпляра из обслуживания. Это отдельный механизм от HTTP/2 GOAWAY. Наличие одного не доказывает, что другой настроен или вообще используется на рассматриваемом участке.

До теста нарисуйте цепочку: клиент, балансировщик, API-процесс, движок. Укажите, кто завершает HTTP/2 и где происходит graceful shutdown. Если прокси преобразует протокол, downstream-сигнал может не описывать внутреннее соединение с движком. Именно эту границу следует сохранить в выводе.

## Создайте ограниченный эксперимент

Откройте небольшое число synthetic streams с известным сроком и размером. Во время их работы инициируйте согласованное завершение тестового экземпляра. Отдельно отправьте новый короткий запрос после начала draining. Наблюдайте, какие операции приняты, завершены, отклонены либо остались с неоднозначным исходом.

Тест не требует реальной клиентской нагрузки. Установите верхний срок ожидания и условия остановки, чтобы не создавать бесконечные соединения. Сохраните timeline событий для каждого запроса, а не только общее число успехов после завершения. Иначе редкий обрыв будет трудно связать с конкретной фазой обновления.

## Не обещайте безопасный replay POST

[RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html) различает идемпотентные методы и осторожность при повторении неидемпотентных запросов. Генерация через POST не становится автоматически безопасной для повтора от появления GOAWAY. Нужны сведения о принятии операции либо отдельно определённая прикладная политика.

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

## Сохраните границы результата

Успешный draining-тест подтверждает выбранный путь и версию компонентов. Он не устанавливает отказоустойчивость на любом балансировщике или при аварийном завершении процесса. Особенно отдельно проверяют сценарий, где grace period закончился до завершения длинной генерации.

Связанные темы — [резервная маршрутизация](/ru/journal/inference-routing-fallback/) и [canary обновления](/ru/journal/model-update-canary/). Они помогают описать прикладную стратегию, а GOAWAY-трасса подтверждает конкретные транспортные границы без заявления об универсальной поддержке сторонней платформой.