Поделиться через

Настройка сброса TCP и времени ожидания подсистемы балансировки нагрузки

Чтобы создать более предсказуемое поведение приложения для ваших сценариев, вы можете использовать Стандартный балансировщик нагрузки, включив сброс TCP при простое для данного правила. По умолчанию, когда истекает время ожидания простоя потока, Load Balancer автоматически прерывает его. Включение сброса TCP приводит к тому, что Load Balancer отправляет двунаправленные пакеты TCP-сброса (пакеты сброса TCP) при тайм-ауте бездействия, чтобы сообщить конечным точкам вашего приложения о том, что соединение прервано из-за тайм-аута и больше не доступно. При необходимости конечные точки могут немедленно установить новое соединение.

Диаграмма показывает поведение сброса TCP по умолчанию для узлов сети.

Сброс TCP

Можно изменить это поведение по умолчанию и включить отправку сбросов TCP при истечении времени ожидания простоя в правилах NAT для входящего трафика, правилах балансировки нагрузки и правилах для исходящего трафика. При включении для каждого правила Load Balancer отправляет двунаправленные пакеты TCP RST как в конечные точки клиента, так и на серверные конечные точки во время тайм-аута бездействия для всех соответствующих потоков.

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

Во многих сценариях сброс TCP может снизить потребность в отправке хранимых данных TCP (или уровня приложений) для обновления времени ожидания простоя потока.

Если продолжительность простоя превышает ограничения конфигурации или приложение демонстрирует нежелательное поведение при включенных сбросах TCP, может потребоваться использовать TCP keepalive пакеты или keepalive пакеты на уровне приложения для мониторинга живучести TCP-соединений. Кроме того, сигналы поддержания связи, особенно на уровне приложения, остаются полезными, если прокси-сервер присутствует где-то на пути соединения.

Тщательно проверив весь комплексный сценарий, вы можете определить преимущества включения сбросов TCP и настройки тайм-аута простоя. Затем вы решите, можно ли выполнить дополнительные действия, чтобы обеспечить требуемое поведение приложения.

Настраиваемое время ожидания в режиме простоя для TCP-подключения

Для правил балансировки нагрузки, правил исходящего трафика и правил NAT для входящих подключений в Azure Load Balancer уровня "Стандартный" предусмотрен интервал ожидания от 4 до 100 минут. Значение по умолчанию — 4 минуты. Если период бездействия превышает значение времени ожидания, нет никакой гарантии, что сеанс TCP или HTTP между клиентом и облачной службой возобновится. Azure Load Balancer Basic имеет до 60 минут времени ожидания.

При закрытии подключения клиентское приложение может получить следующее сообщение об ошибке: "Базовое соединение было закрыто: подключение, которое, как ожидается, будет сохранено в живых, было закрыто сервером".

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

Распространенной практикой является использование TCP keep-alive. Такой подход позволяет поддерживать подключения активными в течение более длительного периода. Дополнительные сведения вы найдете в следующих примерах для .NET. Когда функция keep-alive включена, пакеты отправляются в периоды простоя подключения. Благодаря пакетам проверки активности значение времени ожидания простоя не достигается и подключение сохраняется в течение длительного времени.

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

Механизм поддержания активности TCP хорошо подходит для сценариев, в которых заряд батареи не является ограничением. Мы не рекомендуем использовать этот вариант для мобильных приложений. Использование TCP keep-alive в мобильном приложении может привести к ускоренной разрядке аккумулятора устройства.

Порядок приоритетов

Важно учитывать, как значения времени ожидания простоя, заданные для различных IP-адресов, могут потенциально взаимодействовать.

Входящий трафик

  • Если существует правило балансировщика нагрузки (входящего трафика) со значением тайм-аута простоя, установленным иначе, чем тайм-аут простоя фронтального IP-адреса, на который оно ссылается, тогда тайм-аут простоя фронтального IP-адреса балансировщика нагрузки имеет приоритет.
  • Если существует правило NAT для входящего трафика с значением времени ожидания простоя, которое отличается от времени ожидания ожидания внешнего IP-адреса, на который он ссылается, время ожидания простоя внешнего IP-адреса подсистемы балансировки нагрузки имеет приоритет.

Исходящие

  • Если у правила исходящего трафика значение времени ожидания бездействия отличается от 4 минут (на которое заблокировано время ожидания бездействия общедоступного IP-адреса), то время ожидания бездействия этого правила имеет приоритет.
  • Так как шлюз NAT всегда будет иметь приоритет над правилами исходящего трафика подсистемы балансировки нагрузки (и над общедоступными IP-адресами, назначенными непосредственно виртуальным машинам), будет использоваться значение времени ожидания простоя, назначенное шлюзу NAT. (По аналогии, время ожидания простаивания фиксированного общедоступного исходящего IP-адреса не учитывается в течение 4 минут для всех IP-адресов, назначенных на NAT GW.)

Ограничения

  • Сброс соединения TCP отправляется только во время TCP-соединения в состоянии УСТАНОВЛЕННО.
  • Тайм-аут простоя TCP не влияет на правила балансировки нагрузки по протоколу UDP.
  • Сброс TCP не поддерживается для портов высокой доступности внутреннего балансировщика нагрузки, если на маршруте находится сетевое виртуальное устройство. Решением может быть использование правила исходящего трафика с сбросом TCP из сетевого виртуального устройства.
  • Время ожидания простоя TCP не поддерживается для портов внутренней подсистемы балансировки нагрузки (ILB), когда определяемый пользователем маршрут (UDR) используется для пересылки трафика в подсистему балансировки нагрузки.

Следующие шаги