HTTP2 ERR СОЕДИНЕНИЕ ЗАКРЫТО (слишком много служебной информации) - PullRequest
Новая
       102

HTTP2 ERR СОЕДИНЕНИЕ ЗАКРЫТО (слишком много служебной информации)

0 голосов
/ 24 апреля 2020

Мы разрабатываем проект, используя Angular спереди и Spring на бэкэнде. Ничего нового. Но мы настроили серверную часть на использование HTTP2, и время от времени мы находим странные проблемы.

Сегодня я начал играть с «Экспорт сетевого журнала» с chrome, и я нашел эту интересную информацию в строка HTTP2_SESSION журнала. 

t=43659 [st=41415]    HTTP2_SESSION_RECV_GOAWAY
                  --> active_streams = 4
                  --> debug_data = "Connection [263], Too much overhead so the connection will be closed"
                  --> error_code = "11 (ENHANCE_YOUR_CALM)"
                  --> last_accepted_stream_id = 77
                  --> unclaimed_streams = 0
t=43659 [st=41415]    HTTP2_SESSION_CLOSE
                  --> description = "Connection closed"
                  --> net_error = -100 (ERR_CONNECTION_CLOSED)
t=43661 [st=41417]    HTTP2_SESSION_POOL_REMOVE_SESSION
t=43661 [st=41417] -HTTP2_SESSION

Похоже, root проблемы для ERR_CONNECTION_CLOSED заключается в том, что сервер решает, что слишком много служебных данных от того же клиента, и закрывает соединение.

Вопрос в том, можем ли мы настроить сервер на прием служебных данных до определенного предела? как? Я считаю, что это то, что мы должны быть в состоянии настроить весной или tomcat или где-то там.

Приветствия Игнасио

1 Ответ

0 голосов
/ 27 апреля 2020

Защита от накладных расходов была введена в ответ на коллекцию CVE , сообщенную против HTTP / 2 в середине 2019 года. Хотя Tomcat не был напрямую затронут (злонамеренный ввод не вызывал чрезмерного загрузить) мы предприняли шаги для блокировки ввода, соответствующего вредоносному профилю.

Из вашего комментария GitHub вы видите проблемы с POST. Это настоятельно говорит о том, что клиент отправляет данные POST в виде нескольких небольших пакетов, а не меньшего количества более крупных пакетов. Известно, что некоторые клиенты (например, Chrome) иногда делают это из-за того, что они буферизуют данные.

Количество DoS-атак HTTP / 2 можно суммировать как отправку дополнительной информации. чем данные. Хотя Tomcat не был затронут напрямую, мы приняли решение отслеживать клиентов, работающих таким образом, и отбрасывать соединения, если таковые были обнаружены, на том основании, что клиент может быть вредоносным.

Как правило, пакеты данных сокращаются. количество служебных данных, пакеты без данных увеличивают количество служебных данных и (потенциально) вредоносные пакеты значительно увеличивают количество служебных данных. Идея состоит в том, что установившееся, как правило, хорошо себя зарекомендовавшее себя соединение должно быть способно выдержать случайный «подозрительный» пакет, но больше, чем это, быстро вызовет закрытие соединения.

В терминах небольших пакетов POST ключ настройка конфигурации :

  • overheadCountFactor
  • overheadDataThreshold

Счет служебных данных начинается с -10. Для каждого полученного кадра DATA оно уменьшается на 1. Для каждого кадра SETTINGS, PRIORITY и PING оно увеличивается на overheadCountFactor. Если количество служебных данных превышает 0, соединение закрывается.

Кроме того, если средний размер принятого неконечного кадра DATA и ранее принятого кадра DATA (в том же потоке) меньше overheadDataThreshold, тогда количество служебных данных увеличивается на overheadDataThreshold/(average size of current and previous DATA frames). Таким образом, чем меньше кадр DATA, тем больше увеличение издержек. Небольшого количества небольших неконечных кадров DATA должно быть достаточно, чтобы инициировать закрытие соединения.

Усреднение существует, поэтому буферизация, представленная Chrome, не вызывает защиту от накладных расходов.

Чтобы диагностировать эту проблему, вам нужно просмотреть журналы, чтобы увидеть, какой размер не окончательных кадров данных отправляется клиентом. Я подозреваю, что будет показан ряд не финальных кадров DATA с размером менее 1024 (по умолчанию overheadDataThreshold).

Чтобы решить эту проблему, я рекомендую сначала посмотреть на клиента. Почему он отправляет небольшие не окончательные кадры DATA и что можно сделать, чтобы остановить его?

Если вам нужно немедленное смягчение, вы можете уменьшить overheadDataThreshold. Информация, которую вы получаете о размерах фрейма DATA, отправленных клиентом, должна подсказать вам, что нужно установить. Он должен быть меньше, чем кадры DATA, отправляемые клиентом. В крайнем случае вы можете установить overheadDataThreshold на ноль, чтобы отключить защиту.

...