Анализ HTTP/2 GOAWAY и RST_STREAM PCAP: отладка потоков сброса, ограничений прокси и сбоев gRPC

---

Сбои HTTP/2 бывает сложно диагностировать, поскольку одно TCP-соединение может передавать множество потоков. Одиночный запрос может завершиться неудачно с сообщением «RST_STREAM», все соединение может получить сообщение «GOAWAY», или клиент gRPC может сообщить «UNAVAILABLE», «INTERNAL», «CANCELLED» или «сброс потока». Пользователи ищут «HTTP2 GOAWAY pcap», «Анализ RST_STREAM», «Захват пакета сброса потока gRPC», «Сброс прокси-сервера HTTP/2» и «Устранение неполадок ALPN HTTP2», когда журналы не объясняют, завершил ли поток клиент, прокси, балансировщик нагрузки или сервер.

PCAP Surgery полезен, поскольку доказательства HTTP/2 должны сохранять TLS, ALPN, время подключения, сброс потока и поведение закрытия TCP. Если TLS зашифрован и ключи недоступны, захват пакетов по-прежнему показывает время, сброс TCP, повторное использование соединения и иногда расшифрованный HTTP/2 только в контролируемых средах.

Соединение HTTP/2 против потока

HTTP/2 мультиплексирует несколько потоков по одному соединению. Сброс потока — это не то же самое, что сброс TCP-соединения.

• RST_STREAM: один поток отменен или не выполнен.
• GOAWAY: конечная точка закрывает или опустошает соединение HTTP/2.
• TCP FIN/RST: базовое соединение закрывается или прерывается.

Приложения часто объединяют их в одну ошибку. Доказательства пакетов и журналы должны разделять их.

Переговоры ALPN

HTTP/2 через TLS обычно зависит от ALPN. Подтверждение TLS согласовывает h2 или другой протокол. Если ALPN не согласовывает HTTP/2, клиент и сервер могут отступить или выйти из строя.

Сохранять:

• Расширение ClientHello ALPN.
• Выбранный сервером ALPN, где он виден.
• TLS-оповещения.
• TCP сбрасывается во время рукопожатия.

Если HTTP/2 никогда не согласовывался, пока не отлаживайте RST_STREAM.

GOAWAY

GOAWAY сообщает партнеру, что в этом соединении не следует создавать новые потоки. Это может быть нормальным явлением во время постепенного опорожнения, развертывания, устаревания прокси-соединения или поведения балансировщика нагрузки. Это становится проблемой, когда клиенты неправильно повторно используют сливные соединения или когда GOAWAY появляется во время активных запросов.

Важные вопросы:

• Кто послал GOAWAY?
• Какой был идентификатор последнего потока?
• Активные потоки не удались?
• Клиент повторил попытку нового соединения?
• Происходит ли GOAWAY в фиксированном возрасте подключения?

RST_STREAM

RST_STREAM завершает один поток HTTP/2. Причины включают в себя:

• Отказ от клиента.
• Сервер отклоняет запрос.
• Тайм-аут прокси.
• Проблема с контролем потока.
• Максимальный лимит потока.
• Срок действия gRPC превышен.
• Сброс бэкэнда, переведенный через прокси.

Идентификатор потока и время имеют значение. Без них история пакетов будет неполной.

Уровень TCP все еще имеет значение

HTTP/2 работает на TCP. Если базовое соединение имеет повторные передачи, нулевое окно, сброс, проблемы с MTU или тайм-аут простоя, ошибки HTTP/2 могут быть вторичными.

Коррелировать:

• Время сброса потока.
• TCP повторяет передачу перед сбросом.
• Отправитель FIN/RST.
• Интервал простоя.
• TLS close_notify, если виден.

Checklist

Используйте этот рабочий процесс:

1. Сохраните подтверждение DNS, TCP и TLS.
2. Подтвердите согласование ALPN HTTP/2.
3. Определите, является ли сбой на уровне потока или на уровне соединения.
4. Найдите время и отправителя GOAWAY.
5. Ищите время RST_STREAM и идентификатор потока в расшифрованных трассировках или журналах.
6. Коррелируйте с журналами прокси-сервера/балансировщика нагрузки.
7. Проверьте повторную передачу TCP, нулевое окно, FIN и RST.
8. Проверьте, правильно ли клиент повторяет попытку.
9. Сохраняйте синхронизацию пакетов при обрезке.
10. Объедините доказательства pcap с журналами отладки HTTP/2 в зашифрованном виде.

Окончательный диагноз

Ошибки HTTP/2 GOAWAY и RST_STREAM не являются типичными сетевыми сбоями. Это сигналы управления потоком и соединением, которые должны быть коррелированы с ALPN, поведением прокси-сервера, крайними сроками gRPC, работоспособностью TCP и повторным использованием соединения.

PCAP Surgery помогает сохранить временную шкалу, поэтому сбои HTTP/2 и gRPC можно свести к нужному уровню: согласование TLS, сброс потока, утечка соединения, тайм-аут прокси-сервера или сбой транспорта TCP.