Привет, Хабр! Меня зовут Ильнар Зайнуллин, я системный инженер в К2Тех. Сегодня хочу поговорить о балансировщиках. Пока всё хорошо, о них вспоминают разве что при плановом расширении, очередной миграции или когда нужно красиво разрулить сертификаты. Когда же внезапно начинаются жалобы «подтормаживает», «отваливается», «иногда долго открывается» — балансировщик быстро становится «главным подозреваемым», даже если на самом деле виноваты сеть, backend или конкретный клиент.     

В этой статье разберу три решения для закрытия проблемы с «главным подозреваемым»: F5 BIG-IP, Citrix NetScaler и Termidesk Connect. Если решения от F5 и Citrix хорошо известны на рынке, то Termidesk Connect — достаточно молодое решение от «Группы Астра». Релиз версии 1.0 состоялся весной 2025 года, под конец года вышел релиз 1.2 — его-то я и разберу в статье.

Логика сравнения продуктов максимально приземленная: одинаковые вводные, единая методика и попытка посмотреть на поведение «как в жизни». У меня нет цели выбрать лучшее из представленных решений, скорее — честно показать сильные стороны и возможные подводные камни.

Функции  балансировщика давно уже вышли за рамки  простой раздачи трафика между несколькими серверами. В реальной жизни это и TLS (с его рукопожатиями, настройками и неожиданными эффектами), и L7-логика, и health-check’и, и таймауты, и поведение при деградации сети, и предсказуемость под пиками. И что особенно важно, это ещё и комфортная эксплуатация: насколько удобно жить с решением каждый день — наблюдать, разбирать инциденты, обновляться и не превращать каждое изменение в мини-проект.

В этом сегменте много лет на слуху два решения: F5 BIG-IP и Citrix NetScaler, и во многих инфраструктурах они воспринимаются как привычные, зрелые инструменты. Но на рынке появляется всё больше альтернатив, в том числе российских, и в какой-то момент возникает      вопрос: как новые решения проявят себя в сравнении с признанными лидерами, которое мы проведем в условиях, максимально приближенных к реальным? Решения тестировались на стенде на практических сценариях:

• нагрузочные проверки (чтобы понять, как решения держат поток запросов и что происходит с задержками); 

• проверки под HTTPS/TLS (потому что именно там часто прячутся сюрпризы); 

• прикладной сценарий с загрузкой большого файла (чтобы увидеть поведение, приближенное к пользовательскому); 

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

Для каждого теста отдельно будут описаны вводные, результаты и графики, и описание с трактовкой полученного результата. Еще до тестов мы договорились о следующих подходах:

• Все три балансировщика запускались на одинаковых по выделенным ресурсам виртуальных машинах. Мы сознательно выбрали именно такой метод, а не физические сервера: виртуализация обеспечивает максимально повторяемые условия и исключает влияние аппаратных различий. 

• В тестах не выполнялся тюнинг производительности, не было цели выжать максимум из каждого решения: использовались типовые настройки и дефолтное поведение продуктов.

• На графиках мы использовали следующее обозначение: красный — BIG-IP F5, зелёный — Termidesk Connect, синий — Citrix NetScaler. 

Все остальное — специфика стенда и тестов. Итак, мы начинаем!

Тестовое окружение

Тестовый стенд был развернут на серверах с процессорами Intel(R) Xeon(R) CPU E5-2650 v4. Если вы решите повторить проведенные тесты, то в зависимости от модели процессора результаты могут отличаться для всех решений.  

Стенд включал следующий набор виртуальных машин:

В тестировании используем k6, curl и wget — общеизвестные инструменты для генерации и анализа нагрузки, tc позволяет гибко моделировать сетевые деградации, а Grafana + InfluxDB обеспечивают удобную визуализацию метрик.

Часть 1. Тестирование SSL-производительности и поведения под нагрузкой

В первом тесте проверяли, как BIG-IP F5, Citrix NetScaler и Termidesk Connect ведут себя под высокой HTTPS-нагрузкой. Задача — поймать момент, когда система начинает сдавать: растут задержки, появляются ошибки, проседает фактический RPS, упирается CPU.

Как мы тестировали

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

Базовые параметры:

• Нагрузку генерировали k6 в режиме ramping-arrival-rate: RPS рос ступенчато, шаг — каждые 10 секунд.

• Каждый запрос создавал новое TLS-соединение (Connection: close), чтобы исключить «облегчающий» эффект keep-alive.

• Тело ответа не загружалось (discardResponseBodies: true), чтобы не упираться в IO.

• Лимит VU — до 20 000, чтобы нагрузка упиралась именно в балансировщик, а не в генератор трафика.

Для каждого балансировщика брали свой диапазон RPS. Причина простая:  различия в архитектуре и предельной производительности,  при использовании единого, как правило заниженного, порога тест потерял бы информативность — все результаты  оказались бы примерно сопоставимыми.

Здесь задача была другая: довести каждое решение до его реального предела и посмотреть, как именно проявляется деградация — через задержки, ошибки, рост времени TLS-handshake.

Результаты: пропускная способность (RPS)

На графике видно, какой фактический RPS держал каждый балансировщик во время своего прогона:

• BIG-IP F5. В ходе прогона фактический RPS держится примерно в диапазоне 5-7 тыс., постепенно растёт.

• Termidesk Connect. Большую часть времени RPS колеблется около 2,5-3,5 тыс. В конце — короткий скачок до ~7 тыс.

• Citrix NetScaler. После старта быстро выходит на 6-6,7 тыс. и держит этот уровень ровно. 

Среднее время ответа (latency)

Эти графики показывают среднее время выполнения HTTP-запроса на каждом прогоне. Пока балансировщик справляется с нагрузкой, линия лежит почти у нуля. С появлением очередей — растет задержка.

• BIG-IP F5 почти весь прогон задержка сохраняется на низком уровне, в конце есть короткий пик — примерно до 1 s. 

• Termidesk Connect. Задержка растёт по мере нагрузки от ~0.2-0.3 s до ~3.0-3.2 s и держится на этом уровне до конца прогона.

• NetScaler большую часть прогона задержка на минимуме, а ближе к концу — плавный рост примерно до 0.4-0.5 s.

95-й перцентиль (P95)

P95 показывает, во сколько укладываются 95% запросов: нагляднее, чем среднее, потому что реагирует на очереди и редкие «долгие» ответы.

• BIG-IP F5. Почти весь прогон P95 держится низко (десятки миллисекунд), в конце есть короткий пик примерно до 1 s.

• Termidesk Connect. P95 растёт вместе с нагрузкой и выходит на уровень ~3.4-3.6 s, дальше держится примерно там же до конца прогона.

• NetScaler долго остаётся низким, ближе к концу плавно растёт примерно до 0.5-0.6 s.

Время установки TLS-соединения (handshake)

Графики показывают задержку рукопожатия между клиентом и сервером, которое происходит перед началом обмена данными по HTTPS.

• BIG-IP F5 большую часть прогона handshake держится на десятках миллисекунд (примерно 20-80 ms), к концу поднимается до ~150-200 ms.

• Termidesk Connect. Время установки TLS-сессии изначально также составляет десятки миллисекунд, однако по мере роста нагрузки оно резко увеличивается, достигая примерно 1.4–1.5 секунд.

• Citrix NetScaler стартует примерно с десятков миллисекунд, дальше постепенно растёт и к концу прогона выходит примерно на ~400-450 ms.

Результаты тестирования SSL-производительности и поведения под нагрузкой 

Если суммировать все метрики, то результат выглядит так:

• BIG-IP F5. Держит полку около 5-7 тыс. RPS; средняя задержка почти весь прогон низкая, с коротким пиком в конце; P95 большую часть времени остаётся на десятках миллисекунд; время TLS растёт от десятков миллисекунд до ~150-200 ms ближе к финишу.

• Termidesk Connect. Рабочий уровень производительности составляет около 3–3,5 тыс. RPS; в конце теста наблюдается всплеск из-за обработки накопившихся запросов. При росте нагрузки задержки (latency) и 95-й процентиль достигают примерно 3–3,6 с, а время установки TLS-сессии увеличивается до ~1,4–1,5 с.

• Citrix NetScaler — средний, но устойчивый результат. Полка около 6-6,7 тыс. RPS, стабильная; средняя задержка низкая, к концу растёт до ~0.4-0.5 s; P95 поднимается до ~0.5-0.6 s; TLS-handshake плавно растёт до ~400-450 ms.

При интенсивной нагрузке HTTPS-запросами у Termidesk Connect в первую очередь растут задержки (latency/P95) и время установки TLS-соединения. В то же время BIG-IP F5 дольше сохраняет низкие показатели задержек, а у NetScaler наблюдается более плавный рост метрик на пиковых ступенях нагрузки.

Часть 2. Сравнительное тестирование скорости выгрузки большого файла (1 GB)

Во второй части переходим от синтетических RPS-замеров к более прикладному сценарию — скачиванию большого файла объёмом 1 GB. Это ближе к реальному использованию: обновления, образы, большие архивы.

Здесь уже нет шифрования, весь трафик идёт по-обычному HTTP. Цель — посмотреть, насколько уверенно каждый балансировщик умеет проксировать большой поток данных:

• насколько быстро устанавливается соединение;

• как скоро клиент получает первый байт;

• какую среднюю скорость удаётся держать на протяжении всей загрузки.

Методика

Для каждого решения запускался один и тот же bash-скрипт: каждые 10 секунд он делал curl-запрос на скачивание 1 GB файла. С каждого запуска автоматически собирались метрики:

• time_connect — время установления TCP-соединения;

• TTFB — время до первого байта (time_starttransfer);

• speed_download — средняя скорость передачи;

• и другие параметры, отправляемые в InfluxDB.

Условия были максимально честными:

• все балансировщики и backend-сервера находились в одной сети;

• задержки минимальны и одинаковы;

• backend-узлы одинаковой конфигурации.

Time To First Byte (TTFB)

TTFB показывает, сколько времени проходит от установки соединения  до получения первого байта ответа. Проще говоря, это задержка перед началом передачи  данных.

Результат:

• BIG-IP F5. Основное значение держится примерно в районе 1,6-2,0 ms, но встречается заметный разовый пик примерно до 4,3 ms — поэтому кривая выглядит менее ровной.

• Termidesk Connect. В целом стабильные 1,4-1,8 ms без резких скачков, линия ровная.

• Citrix NetScaler. Самый низкий — примерно 1,0–1,4 ms, иногда поднимается до ~1,5 ms, при этом без выбросов.

Средняя скорость скачивания

Эта метрика показывает итоговую пропускную способность: с какой средней скоростью клиент получал файл размером 1 GB через балансировщик.

• BIG-IP F5. Пропускная способность держится довольно ровно в районе ~150-160 MiB/s, без резких провалов.

• Termidesk Connect. Заметно выше остальных — в основном ~210-245 MiB/s, есть короткий провал в начале серии, дальше скорость стабилизируется и колеблется в этом диапазоне.

• Citrix NetScaler. Самая низкая скорость — примерно 92-98 MiB/s, линия почти ровная.

Время установления TCP-соединения (time_connect)

• BIG-IP F5. В основном около 0,45-0,6 ms, но есть заметные редкие всплески — примерно до 1,4 ms и один пик до ~2,6 ms.

• Termidesk Connect держится ровно в районе 0.35-0.5 ms, без резких скачков.

• Citrix NetScaler. Время составляет примерно 0.35-0.5 ms, линия тоже ровная, местами даже чуть ниже остальных.

Утилита wget 

Чтобы перепроверить результаты, отдельно прогнали скачивание того же 1 GB файла через wget — без разложения на метрики curl, просто как обычную длительную загрузку. По средней скорости получилось так: 

• F5 BIG-IP — 57.8 MB/s; 

• Termidesk Connect — 170 MB/s; 

• Citrix NetScaler — 106 MB/s.

Разница с графиками из curl — нормальная история: curl в нашем сценарии даёт больше измерительных точек (соединение, старт передачи, TTFB), а wget, по сути, показывает, как система держит длинный непрерывный поток данных. Поэтому в wget картина может отличаться, а относительное позиционирования решений — меняться. Это не ошибка, а следствие  разных паттернов нагрузки и того, как балансировщик ведёт себя на коротких запросах против длительной передачи.

Часть 3. Поведение под потерей пакетов и нестабильной сетью

Третья серия тестов моделирует реальную «плохую» сеть: мобильный интернет, общественный Wi-Fi или загруженный корпоративный VPN. Мы проверяли, как BIG-IP F5, Termidesk Connect и Citrix NetScaler обрабатывают HTTPS-трафик, если клиентская сеть частично теряет пакеты и дает высокий, нестабильный RTT.

Главная задача — понять, какое из решений лучше справляется с непредсказуемыми задержками, как меняется число ошибок и насколько падает стабильность обслуживания.

Мы не подбирали и не «выжимали» оптимальные TCP-параметры под каждый продукт: никаких специальных TCP-профилей и тонких настроек под потери/RTT не включали. Все три решения тестировались в режиме as is — с базовой конфигурацией.

Как мы моделировали плохую сеть

Мы использовали tc с комбинацией очередей prio и netem, чтобы для каждого балансировщика трафик попадал в «проблемный» класс:

• 5% потерь пакетов;

• задержка ~150 ms;

• джиттер 30 ms;

• нормальное распределение задержек.

Для каждого решения создавался свой фильтр, чтобы условия были абсолютно идентичны.

Backend-серверы при этом работали в идеальной сети — все сложности были только со стороны клиента.

Профиль нагрузки

Мы использовали k6 в профильном режиме ramping-arrival-rate с фиксированными 1000 RPS:

• 3 этапа по 10 секунд;

• Connection: close для каждого запроса;

• отключенные тела ответов (discardResponseBodies: true).

Это позволило понять, кто умеет работать под постоянной нагрузкой, когда сеть начинает сыпаться.

Поведение без деградации сети

Сначала проверили, как всё работает в идеальных условиях — без задержек, потерь пакетов и прочих проблем. На графиках видно, что все три балансировщика спокойно держат нагрузку: RPS ровный, задержки стабильные, никаких провалов.

Результаты под деградирующей сетью

Сводная таблица ключевых метрик

Метрика	BIG-IP F5	Termidesk Connect	Citrix NetScaler	Примечание
Ошибки	http_req_failed 6.74% ; checks 93.25% (25980/1880)	http_req_failed 17.14% ; checks 82.85% (23164/4792)	http_req_failed 14.95% ; checks 85.04% (21939/3857)	http_req_failed – общий процент запросов, которые k6 пометил как неуспешные на уровне HTTP/транспорта. ​
Dropped iterations	2124	2034	4193	k6 планирует запуски итераций по расписанию, и если в нужный момент нет свободных VU (обычно из-за роста латентности/длительности итераций), часть итераций «не стартует» и считается dropped.
RPS стабильность	662.0 req/s (из 1000 = 66.2%)	559.1 req/s (из 1000 = 55.9%)	436.3 req/s (из 1000 = 43.6%)	Практический индикатор «удержания цели по нагрузке»: сравнение фактического http_reqs/s с целевыми 1000 iters/s в сценарии; чем ниже процент достижения, тем сильнее система/генератор не выдерживает заданный темп.
HTTP latency p95	613 ms	2010 ms	1630 ms	p95 — это «хвост» задержек: 95% запросов быстрее этого значения, а 5% — медленнее; удобно сравнивать деградацию под нагрузкой и влияние очередей/таймаутов.
TLS-handshake avg	0.818 s	0.389 s	1.790 s	Среднее время TLS рукопожатия отражает «среднюю стоимость» установления защищённого соединения (без привязки к обработке запроса приложением) и часто растёт при дефиците ресурсов на фронте/балансировщике или проблемах сети.
TLS-handshake p95	4.03 s	2.14 s	10.46 s	p95 TLS особенно полезен для диагностики пиков/очередей: даже если среднее нормальное, высокий p95 означает, что заметная доля пользователей будет «залипать» на установлении TLS.
p95 iteration_duration	7.27 s	5.59 s	12.90 s	iteration_duration — время выполнения всей итерации VU (весь пользовательский сценарий), поэтому p95 здесь показывает «хвост» по end-to-end сценарию, а не только по одному HTTP-запросу.
Общая устойчивость	Высокая	Средняя	Низкая	Итоговая качественная оценка по сочетанию: меньше ошибок, меньше dropped, ближе фактический RPS к целевому, ниже p95 по HTTP/TLS и по длительности итерации — значит, система устойчивее при заданной нагрузке.

Теперь разберем поведение каждого решения.

BIG-IP F5

Неуспешных запросов меньше всего (6,74%), и чаще всего возвращается нормальный ответ со статусом 200 — успешных проверок 93,25%.​

По нагрузке он ближе всех к тому, что мы пытались дать: вместо 1000 запросов в секунду получается примерно 662 (то есть 66%), и пропущенных запусков (dropped iterations) 2124 — меньше, чем у NetScaler, значит тест реже не успевает выдавать плановый темп.​

По задержкам результат также лучше, чем у остальных: 95% запросов укладываются примерно в 613 мс, и хотя редкие длинные итерации под нагрузкой есть (p95 итерации 7,27 с), в целом хвост по времени заметно спокойнее, чем у NetScaler.

Termidesk Connect

В условиях нестабильного соединения наблюдаются небольшие отклонения в работе: примерно 17% запросов завершаются с ошибками, а 83% соответствуют ожидаемому статусу 200.  

Средняя пропускная способность составляет около 559 запросов в секунду (56% от целевого значения), при этом зафиксировано 2034 случая, когда нагрузка не была достигнута в запланированном объеме.​

По задержкам картина такая: 95% запросов укладываются примерно в 2 секунды, что заметно хуже, чем у BIG-IP, но зато TLS-соединения устанавливаются стабильнее — в среднем около 0,4 секунды, а в 95% случаев не дольше 2,1 секунды.

Citrix NetScaler

По нагрузке хуже остальных держит темп: вместо 1000 запросов в секунду выходит около 436 (то есть примерно 44% от цели), и при этом больше всего «пропущенных» запусков — dropped iterations 4193.​

По ошибкам не самый плохой, но и не лучший: 14,95% запросов считаются неуспешными, а успешных ответов со статусом 200 — около 85%.​

Самая большая проблема — TLS и «длинные хвосты»: установка TLS в среднем занимает 1,79 секунды, а в 95% случаев может растягиваться до 10,46 секунды. Плюс 95-й перцентиль времени одной итерации сценария — 12,90 секунды, то есть заметная часть запросов/сценариев начинает выполняться очень долго.

Результаты тестирования под нестабильной сетью

• BIG-IP F5 — минимальные ошибки, максимальный checks, лучший p95 HTTP и наибольший процент достижения целевого RPS.​

• Termidesk Connect — TLS устанавливается быстрее всех, но цена за это — максимальная доля ошибок и самый высокий p95 HTTP.​

• Citrix NetScaler — наиболее чувствителен к плохой сети: хуже всех удерживает целевой RPS, имеет максимум dropped iterations и самые тяжёлые TLS-«хвосты» и p95 длительности итерации.

Часть 4. Реакция балансировщиков на падение backend-сервера

Что делает балансировщик, когда один из backend-серверов внезапно перестаёт отвечать?

В жизни это происходит чаще, чем хотелось бы: сервер завис, контейнер упал, база данных недоступна. Главное — чтобы балансировщик быстро понял, что узел мёртв, и не слал туда новые запросы.

Важно: redispatch/повторный запрос на другой backend намеренно не включали — хотели увидеть базовую реакцию балансировщика и health-check’ов на падение узла.

Как мы тестировали

Стенд остался тем же: все машины в одной сети, минимальные задержки, одинаковые backend-серверы. На всех балансировщиках настроили идентичные health-checks:

• interval 2 s — проверка раз в 2 секунды;

• resptimeout 1 s — если ответ не получен за 1 секунду, попытка считается проваленной;

• retries 1 — один ретрай перед признанием узла недоступным;

• successRetries 1 — одной успешной проверки достаточно, чтобы вернуть сервер в пул.

Нагрузка та же: 1000 RPS через k6, три этапа по 10 секунд, Connection: close. Через 10 секунд после старта мы вручную выключали Nginx на одном из backend-серверов — полный и мгновенный отказ.

Сводные результаты

Теперь разберем поведение каждого балансировщика подробнее.

BIG-IP F5

Ошибок получилось 15,8% (4725 из почти 30 тысяч запросов). Это заметно, но средняя задержка осталась низкой — 1,50 мс, максимальная — всего 15,28 мс.

BIG-IP F5 реагирует агрессивно: быстро выкидывает мёртвый сервер из пула, но в момент переключения часть запросов всё же уходит в никуда.

Termidesk Connect

Здесь картина лучше: ошибок 6,8% — почти в 2,5 раза меньше, чем у F5. Средняя задержка — 1,42 мс, максимальная — 2,03 секунды (но это именно на ошибочных запросах).​

Самый сбалансированный результат: низкие задержки, минимум ошибок, никаких провалов.

Citrix NetScaler

Лучший процент успешных ответов — 96%, ошибок всего 4%. Но есть нюанс: средняя задержка — 43,77 мс. Правда, если смотреть только на успешные запросы, там всего 0,74 мс — как у остальных.​

Проблема в том, что NetScaler медленнее исключает упавший сервер. Несколько запросов ещё успевают уйти на мёртвый узел и висят там до таймаута. 

Результаты по реакции балансировщиков на падение backend-сервера

При падении одного backend-узла все три балансировщика продолжают держать нагрузку около 1000 RPS, но ведут себя по-разному в части ошибоки задержек. BIG-IP F5 быстрее отсекает проблемный узел, поэтому задержки остаются ровными, но в момент отказа получается больше ошибок. Termidesk Connect даёт более спокойную картину: задержки такие же низкие, а ошибок заметно меньше. NetScaler показывает минимальный процент ошибок, но часть запросов успевает попасть на уже недоступный сервер и дожидается таймаута — из-за этого растёт средняя задержка.

Подведем итоги

Тесты хорошо показывают одну простую мысль: балансировщики отличаются не только скоростью, но и характером поведения. Причем этот характер меняется в зависимости от сценария: в одном случае важнее выдержать поток, в другом — не раздувать задержки, в третьем — не сыпаться при неидеальной сети, а в четвёртом — просто быть предсказуемым и понятным в эксплуатации. И именно поэтому сводить сравнение к одной цифре обычно бессмысленно — в продуктивной среде никто не живёт в одном-единственном режиме.

Отдельный вывод — про HTTPS и TLS. Очень часто кажется, что достаточно включить шифрование, но именно на TLS начинают проявляться нюансы реализации, настройки и поведения под нагрузкой. Там же обычно находятся неожиданные причины периодических проблем: то рукопожатие внезапно становится дорогим, то соединения ведут себя не так, как ожидалось, то таймауты и ретраи начинают усиливать эффект от любой деградации.

Сценарии с ухудшенной сетью — вообще отдельный вид истины. Пока канал идеальный, большинство решений выглядят достойно. Но как только появляются задержки, потери и неровность, на поверхность всплывает то, что реально определяет пользовательский опыт: как быстро система восстанавливается, насколько мягко деградирует, как ведут себя health-check’и, и не превращается ли небольшой сетевой шум в лавину ошибок.

Подводя итог, могу сказать, что Termidesk Connect — молодой российский продукт — проявил себя как полноценный рабочий инструмент, вполне сопоставимый с BIG-IP F5 и Citrix NetScaler. Безусловно, на текущем этапе существуют определённые ограничения и «типовые грабли». Будем следить за тем, как вендор развивает и дорабатывает продукт. Задачу по объективному сравнению решений я считаю выполненной — картина, на мой взгляд, получилась полной. Дальнейший выбор зависит от конкретных условий: помимо функциональности продукта, важно учитывать планируемую нагрузку, особенности сети, модель эксплуатации и требования к технической поддержке.