Настройка сброса TCP и времени ожидания подсистемы балансировки нагрузки
Чтобы создать более предсказуемое поведение приложения для ваших сценариев, вы можете использовать Load Balancer (цен. категория "Стандартный"), включив сброс протокола TCP в неактивный режим для данного правила. По умолчанию, когда истекает время ожидания простоя потока, Load Balancer автоматически прерывает его. Включение сброса TCP приводит к тому, что Load Balancer отправляет двунаправленные пакеты TCP-сброса (пакеты сброса TCP) во время ожидания простоя, чтобы сообщить конечным точкам приложения, что истекло время ожидания подключения и больше не используется. При необходимости конечные точки могут немедленно установить новое соединение.
Сброс TCP
Изменить это поведение по умолчанию и включить отправку признаков TCP Reset при истечении времени ожидания простоя можно в правилах NAT для входящего трафика, правилах балансировки нагрузки и правилах для исходящего трафика. При включении для каждого правила Load Balancer отправляет двунаправленные пакеты TCP (ПАКЕТЫ TCP RST) как в конечные точки клиента, так и на серверные конечные точки во время ожидания простоя для всех соответствующих потоков.
Конечные точки, получающие пакеты REST TCP, немедленно закрывают соответствующий сокет. Это обеспечивает немедленное уведомление о выпуске подключения конечной точки, а любое дальнейшее взаимодействие с тем же TCP-подключением завершится ошибкой. Приложения могут очищать соединения при закрытии сокета и повторно устанавливать их по мере необходимости, не дожидаясь, когда время ожидания TCP-соединения окончательно истечет.
Во многих сценариях сброс TCP может снизить потребность в отправке хранимых данных TCP (или уровня приложений) для обновления времени ожидания простоя потока.
Если продолжительность простоя превышает ограничения конфигурации или приложение показывает нежелательное поведение с включенными сбросами TCP, то для отслеживания активности TCP-подключений по-прежнему может потребоваться использовать хранимые tcp-подключения или уровни приложений. Кроме того, сообщения об активности, особенно об активности прикладного уровня, могут по-прежнему быть полезными, если где-то на пути соединения есть прокси-сервер.
Тщательно проверив весь комплексный сценарий, вы можете определить преимущества включения сбросов TCP и настройки тайм-аута простоя. Затем вы решите, можно ли выполнить дополнительные действия, чтобы обеспечить требуемое поведение приложения.
Настраиваемое время ожидания в режиме простоя для TCP-подключения
Для правил балансировки нагрузки Azure Load Balancer уровня "Стандартный" требуется 4 минуты до 100 минут для правил балансировки нагрузки, правил исходящего трафика и правил NAT для входящих подключений. Значение по умолчанию — 4 минуты. Если период бездействия превышает значение времени ожидания, нет никакой гарантии, что сеанс TCP или HTTP между клиентом и облачной службой возобновится. Azure Load Balancer Basic имеет до 30 минут времени ожидания.
При закрытии подключения клиентское приложение может получить следующее сообщение об ошибке: "Базовое соединение было закрыто: подключение, которое, как ожидается, будет сохранено в живых, было закрыто сервером".
Если сбросы TCP включены, и он отсутствует по какой-либо причине, сбрасывает все последующие пакеты. Если параметр сброса TCP не включен, пакеты автоматически удаляются.
Распространенной практикой является проверка активности TCP. Такой подход позволяет поддерживать подключения активными в течение более длительного периода. Дополнительные сведения вы найдете в следующих примерах для .NET. Когда проверка активности включена, пакеты отправляются в периоды простоя подключений. Благодаря пакетам проверки активности значение времени ожидания простоя не достигается и подключение сохраняется в течение длительного времени.
Этот параметр применяется только для входящих подключений. Чтобы избежать потери подключения, настройте пакеты проверки активности для TCP с интервалом меньше, чем настроенное время ожидания простоя. Можно также увеличить значение времени ожидания простоя. Для поддержки этих сценариев доступна поддержка настраиваемого времени ожидания простоя.
Проверки активности TCP хорошо подходят для сценариев, в которых не нужно беспокоиться о расходе заряда аккумулятора. Мы не рекомендуем использовать этот вариант для мобильных приложений. Использование этого метода в мобильном приложении может привести к ускоренной разрядке аккумулятора устройства.
Порядок приоритетов
Важно учитывать, как значения времени ожидания простоя, заданные для различных IP-адресов, могут потенциально взаимодействовать.
Входящий трафик
- Если существует правило подсистемы балансировки нагрузки (входящего трафика) со значением времени ожидания простоя, заданное по-разному, чем время ожидания ожидания внешнего IP-адреса, которое он ссылается, время ожидания простоя внешнего IP-адреса подсистемы балансировки нагрузки имеет приоритет.
- Если существует правило NAT для входящего трафика с значением времени ожидания простоя, которое отличается от времени ожидания ожидания внешнего IP-адреса, на который он ссылается, время ожидания простоя внешнего IP-адреса подсистемы балансировки нагрузки имеет приоритет.
Исходящие
- Если правило исходящего трафика с значением времени ожидания простоя отличается от 4 минут (что такое время ожидания ожидания простоя исходящего ip-адреса общедоступного IP-адреса заблокировано), время ожидания простоя правила исходящего трафика имеет приоритет.
- Так как шлюз NAT всегда будет иметь приоритет над правилами исходящего трафика подсистемы балансировки нагрузки (и над общедоступными IP-адресами, назначенными непосредственно виртуальным машинам), будет использоваться значение времени ожидания простоя, назначенное шлюзу NAT. (По тем же линиям время ожидания исходящего исходящего IP-адреса заблокированного общедоступного IP-адреса не учитывается в течение 4 минут для всех IP-адресов, назначенных NAT GW.)
Ограничения
- Сброс TCP отправляется только во время подключения TCP в состоянии УСТАНОВЛЕН.
- Тайм-аут простоя TCP не влияет на правила балансировки нагрузки по протоколу UDP.
- Сброс TCP не поддерживается для портов высокой доступности внутренней подсистемы балансировки нагрузки, если сетевое виртуальное устройство находится в пути. Решением может быть использование правила исходящего трафика с сбросом TCP из сетевого виртуального устройства.