Неправильно настроенные тайм-ауты создают скрытые сбои, призрачные отключения и ненужное ожидание в production.
Когда тайм-аут установлен неверно, сбой не всегда очевиден. Если serverTimeout зафиксирован на 30 секундах, long-polling запросы возвращают 504. Если connectTimeout слишком длинный, клиенты, ожидающие недоступного backend, зависают на секунды перед повторной попыткой — вызывая каскады повторных попыток. Если tunnelTimeout слишком короткий, WebSocket-соединения разрываются без причины и пользователи испытывают призрачные отключения.
Большинство систем представляют настройки тайм-аутов в виде плоского списка. Операторы не могут чётко определить, какое значение управляет фазой HTTP-запроса, какое управляет временем ответа backend, какое применяется к WebSocket-туннелям и какое влияет на ожидание FIN. Результат — либо все значения устанавливаются слишком высокими, создавая утечки соединений, либо все устанавливаются слишком низкими, прерывая легитимный пользовательский трафик.
WebSocket и долгоживущие соединения — это место, где проблема наиболее видна. HTTP keepalive значим в диапазоне 30–120 секунд, но WebSocket-сессия может оставаться открытой часами. Без отдельно управляемого tunnelTimeout приложения реального времени ограничены обычным поведением HTTP idle.
Поведение TCP teardown также важно. Когда clientFIN и serverFIN не контролируются, полузакрытые соединения могут истощить пул файловых дескрипторов. На публично доступных сервисах это усугубляется шаблонами атак медленного закрытия и превращается в проблему исчерпания ресурсов.
TR7 Профили тайм-аутов собирают 9 независимых осей тайм-аута в одном именованном профиле, гарантируя, что каждый пул применяет правильное поведение ожидания, drain и закрытия соединений для своего типа трафика.
Наш подход
TR7 управляет тайм-аутами через повторно используемые именованные профили, а не рассредотачивая отдельные настройки по пулам.
Именованные профили создаются и привязываются к пулам
Оператор определяет имя профиля и группирует 9 значений тайм-аута внутри него. Один и тот же профиль может быть привязан к нескольким пулам, давая веб-, API- или WebSocket-пулам согласованный общий стандарт тайм-аута.
Оси HTTP, TCP, queue, tunnel и FIN разделены
HTTP request, keepalive, connect, server, client, queue, tunnel, clientFIN и serverFIN управляются каждый как отдельное поле. Каждое поле настраивается в соответствии с собственной семантикой трафика; ни одно значение тайм-аута не используется как замена другого.
Тайм-аут туннеля WebSocket независим от HTTP keepalive
Долгоживущие соединения, такие как WebSocket и HTTP CONNECT, управляются через tunnelTimeout отдельно. Соединения чата, прямых трансляций и событийных потоков не ограничены таймером HTTP idle и не закрываются без необходимости.
clientFIN и serverFIN ограничивают полузакрытые соединения
То, как долго соединение удерживается после сигнала TCP close, настраивается независимо для сторон клиента и сервера. Это снижает риск потребления ресурсов в стиле FIN-WAIT и позволяет применять более агрессивные политики drain на публично доступных сервисах.
Возможности
Профили тайм-аутов позволяют операторам точно настраивать время жизни соединения и поведение ожидания через 9 независимых полей для каждого типа трафика.
httpKeepaliveTimeout управляет тем, как долго остаётся открытым idle HTTP-соединение
httpKeepaliveTimeout определяет, как долго HTTP/1.1 keep-alive соединение остаётся открытым между запросами. По умолчанию — 120 секунд. Слишком высокое значение расходует ресурсы на idle-соединения; слишком низкое увеличивает стоимость переподключений. Настраивается с учётом бюджета idle-соединений backend.
httpRequestTimeout ограничивает медленную доставку заголовков и снижает риск slowloris
httpRequestTimeout — это время, отведённое клиенту на завершение строки запроса и заголовков. По умолчанию — 30 секунд. Клиенты, отправляющие заголовки очень медленно, могут быть отключены на этом пороге. Это важная точка защиты от slowloris-подобных шаблонов на публично доступных сервисах.
connectTimeout управляет временем ожидания TCP-соединения с backend
connectTimeout определяет, как долго TR7 ожидает при установке TCP-соединения с backend. По умолчанию — 20 секунд. При слишком длинном значении недоступный backend без необходимости задерживает клиентов. Сценарии API, требующие быстрых ответов об ошибках, выигрывают от более низкого connectTimeout.
serverTimeout устанавливает время ожидания ответа от backend
serverTimeout — это время, отведённое backend на генерацию ответа. По умолчанию — 90 секунд. Может быть низким для быстрых API и увеличен для тяжёлых отчётов, long-polling или эндпоинтов с медленными запросами. Неправильно низкое значение вызывает 504 для работающих, но медленных запросов.
clientTimeout управляет поведением ожидания при ожидании данных от клиента
clientTimeout — это время ожидания данных от клиента. Применяется к загрузке тела запроса, конвейерным запросам и сценариям медленных клиентов. По умолчанию — 90 секунд. Может быть увеличен для загрузки больших файлов и снижен для уменьшения риска медленных клиентов на публичных API.
queueTimeout ограничивает, как долго клиент ждёт при заполненном пуле
queueTimeout определяет, как долго запрос ждёт в очереди пула при заполненной ёмкости соединений. По умолчанию — 60 секунд. При превышении запрос возвращается с ошибкой, и клиент не удерживается бесконечно. Это значение следует рассматривать совместно с ограничениями maxconn и SLA приложений.
tunnelTimeout управляет WebSocket и HTTP-туннельными соединениями отдельно
tunnelTimeout определяет idle-время для WebSocket и HTTP CONNECT туннельных соединений. По умолчанию — 120 секунд; для приложений реального времени это может быть увеличено до 3600 секунд и более. Поскольку этот тайм-аут независим от HTTP keepalive, долгоживущие соединения не ограничены настройками веб-трафика. Критичен для чата, живых уведомлений и приложений потоковой передачи.
clientFIN управляет тем, как долго удерживается соединение после закрытия клиентом
clientFIN устанавливает, как долго соединение удерживается после сигнала FIN от клиента. По умолчанию — 3 секунды. Более низкие значения предотвращают потребление файловых дескрипторов полузакрытыми соединениями. Особенно важно на публично доступных сервисах для снижения давления ресурсов FIN-WAIT.
serverFIN управляет временем graceful drain при закрытии backend
serverFIN ограничивает поведение соединения после сигнала FIN от backend. По умолчанию — 6 секунд. Поддержание serverFIN выше clientFIN обеспечивает большую толерантность к graceful drain при завершении работы backend. Эта настройка напрямую влияет на качество закрытия соединений в пулах backend с высоким трафиком.
Один профиль тайм-аута может быть привязан к нескольким пулам
Модель привязки профиль-пул позволяет использовать один стандарт тайм-аута для нескольких пулов. Все веб-пулы могут указывать на профиль web, API-пулы — на профиль api, а WebSocket-пулы — на профиль websocket. Одно изменение профиля централизованно обновляет поведение тайм-аута каждого привязанного к нему пула, снижая дублирование конфигурации и дрейф.
Нативный конвейер генерации преобразует поля профиля в runtime-директивы тайм-аута
9 полей профиля преобразуются в соответствующие runtime-директивы тайм-аута — connect, server, client, queue, tunnel, http-keep-alive, http-request, client-fin и server-fin. Операторы управляют значениями через профиль, а не пишут отдельные директивы, создавая согласованный мост между GUI и поведением во время выполнения.
Тайм-аут проверки работоспособности остаётся отдельным элементом управления вне профиля трафика
Время проверки работоспособности управляется через собственное поле тайм-аута и независимо от профиля тайм-аута трафика. Это разделение важно: задержка probe и поведение ожидания производственного трафика не смешиваются. Проверку работоспособности backend можно держать короткой, пока фактический serverTimeout эндпоинта остаётся длинным, позволяя отслеживать работоспособность сервиса и пользовательский трафик с разными семантиками.
Операционная глубина
Профили тайм-аутов работают совместно с диапазоном значений, значениями по умолчанию, поддержкой десятичных чисел, семантикой туннеля, балансом FIN и моделью привязки пулов.
Диапазон значений
Поля тайм-аута настраиваются от 0 до 60 000 секунд. Этот диапазон охватывает от субсекундных защитных настроек до сессий, превышающих 16 часов, обеспечивая достаточную гибкость для long-poll и требований постоянных соединений.
Поддержка десятичных чисел
httpKeepaliveTimeout принимает десятичные значения. Значение, такое как 0.5 секунды, позволяет более точное поведение idle keepalive. Остальные 8 полей тайм-аута обрабатываются как целые числа секунд.
Безопасные по умолчанию значения для production
Значения по умолчанию обеспечивают безопасную отправную точку, подходящую для большинства веб- и API-трафика. Подходящими базовыми значениями являются: httpKeepaliveTimeout 120, httpRequestTimeout 30, connectTimeout 20, serverTimeout 90, clientTimeout 90, queueTimeout 60, tunnelTimeout 120, clientFIN 3 и serverFIN 6 секунд. Для специализированных типов трафика эти значения должны корректироваться на уровне профиля.
Семантика туннеля
tunnelTimeout применяется к туннелированным соединениям, таким как WebSocket и HTTP CONNECT. Это не то же самое, что тайм-аут HTTP-запроса или keepalive. Слишком низкая настройка на долгоживущих соединениях создаёт проблемы с отключением.
Баланс FIN
В модели по умолчанию serverFIN более толерантен, чем clientFIN. Это оставляет больше места для graceful drain при завершении работы backend. На публично доступных сервисах оба значения могут быть установлены более агрессивно для снижения потребления ресурсов полузакрытыми соединениями.
Именованные профили вместо пресетов
TR7 не навязывает готовые пресеты. Операторы создают собственные именованные профили в соответствии со своим сценарием — web, api, websocket, longpoll или upload могут быть определены в соответствии со стандартами организации. Привязка пула к соответствующему профилю предпочтительна перед индивидуальными переопределениями на уровне сервиса.
Когда применять
Сбалансированный профиль тайм-аута для стандартных веб-приложений
Профиль web может быть создан близким к значениям по умолчанию. Keepalive сохраняет пользовательский опыт, пока значения тайм-аутов request и FIN ограничивают медленные или полузакрытые соединения. Один и тот же профиль может быть привязан к нескольким веб-пулам.
Длительный тайм-аут туннеля WebSocket для чата в реальном времени
Приложениям чата нужно, чтобы WebSocket-соединения оставались открытыми без частых разрывов. Внутри профиля websocket tunnelTimeout устанавливается в длинное значение, например 3600 секунд, пока другие HTTP-тайм-ауты остаются по умолчанию. Долгоживущие соединения больше не ограничены окном HTTP keepalive.
Увеличенный serverTimeout для long-polling API
Long-polling эндпоинт может ждать несколько минут ответа от backend. Установка serverTimeout в 300 секунд в профиле longpoll поддерживает окно ожидания в 5 минут. Без этого стандартный тайм-аут API обрезает запросы слишком рано.
Расширенный clientTimeout для загрузки больших файлов
Данные от клиента могут поступать медленно при загрузке больших тел POST или файлов. В профиле upload clientTimeout и при необходимости httpRequestTimeout могут быть увеличены до 600 секунд. Это предотвращает прерывание законных, но медленных операций загрузки.
Агрессивный профиль тайм-аута для быстрого банковского API
Когда банковский API ожидает быстрого ответа backend, могут использоваться жёсткие значения, такие как connectTimeout 2 секунды и serverTimeout 5 секунд. Медленный или недоступный backend не задерживает клиентов надолго. Поведение повторных попыток и failover запускается раньше.
Профиль защиты от медленных атак для публично доступного веба
Защитный профиль может использовать низкие значения, такие как httpRequestTimeout 5 секунд и clientFIN/serverFIN 1 секунда. Эта структура ограничивает медленную доставку заголовков и шаблоны потребления полузакрытых соединений. Снижает поверхность атаки на публично доступных сервисах.
Часто задаваемые вопросы
Чем управляет каждое из 9 полей тайм-аута?
Почему WebSocket-соединениям нужен отдельный профиль тайм-аута?
Почему значения clientFIN и serverFIN важны с точки зрения безопасности?
Как один профиль привязывается к нескольким пулам?
В чём разница между serverTimeout и queueTimeout?
Есть ли встроенные шаблоны профилей тайм-аутов?
Моделируйте управление тайм-аутами в соответствии с типами трафика
9-осные именованные профили тайм-аутов для ваших веб-, API-, WebSocket- и upload-пулов. Давайте разберём живую настройку с вашей собственной конфигурацией.