Настройка сброса TCP и времени ожидания подсистемы балансировки нагрузки
Чтобы создать более предсказуемое поведение приложения для ваших сценариев, вы можете использовать Load Balancer (цен. категория "Стандартный"), включив сброс протокола TCP в неактивный режим для данного правила. По умолчанию, когда истекает время ожидания простоя потока, Load Balancer автоматически прерывает его. Включение сброса TCP приводит к тому, что Подсистема балансировки нагрузки отправляет двунаправленные пакеты TCP (пакеты TCP RST) во время ожидания простоя, чтобы сообщить конечным точкам приложения о времени ожидания подключения и больше не используется. При необходимости конечные точки могут немедленно установить новое соединение.
Сброс TCP
Изменить это поведение по умолчанию и включить отправку признаков TCP Reset при истечении времени ожидания простоя можно в правилах NAT для входящего трафика, правилах балансировки нагрузки и правилах для исходящего трафика. При включении для каждого правила Load Balancer отправляет двунаправленные пакеты TCP (ПАКЕТЫ TCP RST) как в конечные точки клиента, так и на серверные конечные точки во время ожидания простоя для всех соответствующих потоков.
Конечные точки, получившие TCP-пакеты RST, немедленно закрывают соответствующий сокет. Это обеспечивает немедленное уведомление о выпуске подключения конечной точки, а любое дальнейшее взаимодействие с тем же TCP-подключением завершится ошибкой. Приложения могут очищать подключения при закрытии сокета и повторном удалении подключений по мере необходимости, не ожидая истечения времени ожидания TCP-подключения.
Во многих сценариях сброс TCP может снизить потребность в отправке хранимых данных TCP (или уровня приложений) для обновления времени ожидания простоя потока.
Если продолжительность простоя превышает ограничения конфигурации или приложение показывает нежелательное поведение с включенными сбросами TCP, то для отслеживания активности TCP-подключений по-прежнему может потребоваться использовать хранимые tcp-подключения или уровни приложений. Кроме того, сообщения об активности, особенно об активности прикладного уровня, могут по-прежнему быть полезными, если где-то на пути соединения есть прокси-сервер.
Тщательно проверив весь комплексный сценарий, вы можете определить преимущества включения сбросов TCP и настройки тайм-аута простоя. Затем вы решите, можно ли выполнить дополнительные действия, чтобы обеспечить требуемое поведение приложения.
Настраиваемое время ожидания в режиме простоя для TCP-подключения
Azure Load Balancer имеет 4 минуты до 100-минутного диапазона времени ожидания для правил Load Balancer, правил исходящего трафика и правил NAT для входящего трафика. Значение по умолчанию — 4 минуты. Если период бездействия превышает значение времени ожидания, нет никакой гарантии, что сеанс TCP или HTTP между клиентом и облачной службой возобновится.
При закрытии подключения клиентское приложение может получить следующее сообщение об ошибке: "Базовое соединение было закрыто: подключение, которое, как ожидается, будет сохранено в живых, было закрыто сервером".
Распространенной практикой является проверка активности 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.
- Порты высокого уровня доступности ILB не поддерживают сброс TCP, когда в пути находится сетевой виртуальный модуль. Возможное решение заключается в использовании правила для исходящего трафика со сбросом TCP с устройства NVA.