Возможность

Connection Multiplexing

Передавайте трафик клиентов на backend без зеркалирования каждого соединения — меньше handshake, ниже задержка.

TR7 Connection Multiplexing не зеркалирует каждый запрос клиента как новое TCP/TLS-соединение с backend. Вместо этого он поддерживает persistent connection pool на стороне backend, так что высокий клиентский трафик генерирует значительно меньше накладных расходов на установку соединений в сервисах, выполняющих реальную работу. На frontend современные протоколы, включая HTTP/2 и HTTP/3, обеспечивают поведение с несколькими потоками. На backend keepalive и повторное использование соединений применяются в соответствии с режимом, выбранным оператором: safe, aggressive, always или never. Этот подход наиболее важен для API-нагрузок, мобильных приложений, e-commerce, медиа и B2B-сервисов — везде, где короткие частые запросы являются нормой. Backend-сервисы сосредотачиваются на реальной бизнес-логике вместо расходования ресурсов на повторные TCP и TLS-handshake. Результат: TR7 превращает connection multiplexing из скрытой оптимизации в управляемую политику ADC — современные протоколы на frontend, persistent пул на backend и per-service контроль повторного использования на всём протяжении.

100K→1K

Типичное соотношение клиент–backend при мультиплексировании

Режимы http-reuse: never, safe, aggressive, always

95%+

Снижение CPU TLS-handshake при session ticket resumption

Когда каждый запрос клиента открывает новое backend-соединение, ресурсы уходят на установку соединений, а не на обслуживание нагрузки.

В классической модели соединений большое количество клиентов означает столь же большое количество TCP или TLS-соединений на стороне backend. Каждое новое соединение несёт трёхстороннее TCP-рукопожатие, TLS-handshake, управление сокетами и затраты на завершение. По мере роста трафика backend тратит всё больше времени на накладные расходы соединений, а не на реальную бизнес-логику.

Короткие частые API-запросы делают проблему более очевидной. Мобильные приложения, B2B-вызовы, микросервисы и потоки оформления заказов — все генерируют множество небольших запросов. Когда каждый запрос становится новым соединением, CPU, память, сокеты и сетевые ресурсы расходуются впустую.

Поведение HTTP/1.1 на frontend добавляет ещё одно ограничение. Медленный запрос на данном соединении может блокировать других, стоящих за ним; параллельная ёмкость потоков ограничена. Современный клиентский трафик движется эффективнее с HTTP/2 и HTTP/3, и управление backend-соединениями должно идти в ногу.

Правильный подход — не зеркалировать клиентские соединения один к одному на backend. Нужно пулировать и повторно использовать соединения, а также настраивать поведение мультиплексирования для каждого типа сервиса. Неидемпотентные операции требуют более безопасных режимов повторного использования; высоконагруженные API выигрывают от более агрессивных.

TR7 Connection Multiplexing реализует эту модель: современное мультиплексирование потоков на frontend, keepalive-пул на backend и управляемая per-service политика повторного использования соединений.

Наш подход

TR7 реализует connection multiplexing через keepalive-пул на backend, per-service режим повторного использования, поддержку протоколов HTTP/2 и HTTP/3 и TLS session resumption.

Backend connection pool устраняет повторные затраты на установку соединений

Соединения, открытые к backend, не закрываются сразу после завершения запроса — они возвращаются в пул для повторного использования. Это сокращает накладные расходы TCP и TLS-handshake на стороне backend.

Режим повторного использования выбирается под поведение сервиса

Повторным использованием соединений можно управлять через четыре режима: never, safe, aggressive и always. Операторы выбирают правильное поведение для каждого сервиса, балансируя требования безопасности, ограничения идемпотентности и цели пропускной способности.

HTTP/2 stream multiplexing обеспечивает параллелизм через одно соединение

С HTTP/2 ALPN несколько параллельных потоков передаются через одно соединение. Это особенно эффективно при большом количестве коротких API-запросов, улучшая эффективность соединений на стороне клиента.

TLS session resumption снижает стоимость handshake для возвращающихся клиентов

TLS session resumption позволяет возвращающимся клиентам пропустить полный handshake. В TLS-интенсивных сервисах это снижает потребление CPU и задержку установки соединения.

Возможности

Connection Multiplexing снижает накладные расходы backend-соединений через per-service повторное использование, keepalive, HTTP/2, HTTP/3 и профили таймаутов.

Режим http-reuse ставит повторное использование соединений под контроль оператора

TR7 управляет повторным использованием соединений как действием на уровне пула. Режим never ведёт себя близко к модели нового соединения на каждый запрос. safe обеспечивает более контролируемое повторное использование. aggressive и always нацелены на более значительную экономию соединений для высоконагруженных сервисов. Операторы выбирают режим, соответствующий профилю производительности и безопасности каждого сервиса.

Backend keepalive снижает накладные расходы открытия и закрытия соединений

При включённом keepalive на стороне backend соединения возвращаются в пул по завершении запроса. Следующий запрос подхватывает готовое соединение вместо открытия нового. Это значительно снижает стоимость установки соединений для коротких запросов и даёт backend более стабильный и предсказуемый профиль соединений.

HTTP/2 ALPN поддерживает современные клиентские потоки на frontend

TR7 поддерживает HTTP/2 ALPN на стороне клиента, передавая несколько потоков через одно соединение. Это снижает количество соединений, которые должны открывать браузеры и мобильные клиенты. Задержка и потребление ресурсов становятся более предсказуемыми. Поддержка HTTP/2 — базовый слой производительности для современного web- и API-трафика.

Backend HTTP/2 включается per-service переключателем

HTTP/2 на стороне backend включается опционально на уровне сервиса. Когда backend поддерживает HTTP/2, ALPN согласовывает h2 или http/1.1 соответственно. Сервисы без поддержки HTTP/2 автоматически возвращаются к HTTP/1.1. Это позволяет современным backend выигрывать от HTTP/2, не ломая legacy-сервисы.

HTTP/3 на frontend улучшает поведение соединений в сетях с потерями

TR7 передаёт современный клиентский трафик через HTTP/3/QUIC на frontend. В мобильных и ненадёжных сетях улучшается установка соединений и непрерывность потоков. HTTP/2 fallback сохраняет обратную совместимость. Сторона backend управляется независимо на основе собственных возможностей протокола.

Safe mode сохраняет целостность данных для неидемпотентных операций

Режим safe повторного использования применяет более консервативное поведение для рискованных или неидемпотентных операций. В банковских, платёжных или write-интенсивных API оптимизация производительности не должна обходиться ценой целостности данных. Этот режим удерживает повторное использование в безопасных границах. Операторы могут выбрать safe вместо aggressive для высокочувствительных сервисов.

TLS session resumption снижает нагрузку на CPU для возвращающихся клиентов

TLS session reuse позволяет одному клиенту переподключиться без повторения полного handshake. Механизмы TLS 1.2 session tickets и TLS 1.3 PSK оба поддерживают это поведение. При интенсивном HTTPS-трафике использование CPU ADC значительно снижается. Особенно ценно в мобильных и API-сценариях с множеством кратковременных соединений.

Профили таймаутов точно настраивают поведение пула

Значения таймаутов HTTP keepalive, client-fin, server-fin, tunnel, connect, server, client и queue — все определяют поведение connection pool. Слишком короткие таймауты истощают пул и снижают повторное использование. Слишком длинные увеличивают число простаивающих соединений и потребление памяти. TR7 делает этот баланс управляемым для каждого профиля сервиса.

Лимиты maxconn устанавливают верхний предел размера пула

Лимиты соединений могут быть определены на уровне пула и backend. Эти лимиты помогают защищать backend-сервисы от внезапных всплесков соединений. Особенно важны для приложений с меньшей или лицензированной ёмкостью соединений. В сочетании с connection multiplexing лимиты maxconn обеспечивают более предсказуемое поведение ёмкости.

Ограничение скорости соединений контролирует burst новых соединений

Скорость новых соединений в секунду может быть ограничена верхним пределом. Это предотвращает захлёстывание backend-сервисов волнами ботов, storm повторных подключений мобильных клиентов или внезапными всплесками трафика. Keepalive-пул управляет повторным использованием, тогда как скорость новых соединений управляется отдельно. Операционные команды могут ограничивать поведение соединений не только по общему количеству, но и по скорости.

TCP keepalive снижает риск таймаутов NAT и firewall

Сигналы TCP keepalive на сторонах клиента и backend могут предотвращать молчаливое закрытие промежуточными сетевыми устройствами простаивающих соединений. Долгоживущие соединения уязвимы для таймаутов firewall и NAT. Keepalive помогает поддерживать эти соединения. Это наиболее важно для сервисов с длинными сессиями или низкочастотным трафиком.

Soft reload применяет новую конфигурацию без сброса соединений

При изменении конфигурации существующие соединения drainятся, тогда как новый worker принимает новые соединения под обновлённой конфигурацией. Это предотвращает резкое нарушение работы connection pool. Операторы могут изменять значения таймаутов, режимы повторного использования или настройки ALPN, сохраняя непрерывность сервиса. Production-изменения несут меньший операционный риск.

Операционная глубина

Connection multiplexing эксплуатируется совместно с балансом keepalive-таймаута, поведением drain, размером TLS-кэша, параллелизмом потоков, мостовым протоколом и метриками мониторинга.

Баланс keepalive-таймаута

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

Drain соединений при reload

Во время soft reload старый worker контролируемо дрейнирует существующие соединения, тогда как новый worker принимает соединения под новой конфигурацией. Это критично для нулевых нарушений в сервисах, полагающихся на connection multiplexing. Продолжительность drain должна планироваться отдельно для долгоживущих соединений.

Кэш TLS-сессий

Размер кэша TLS-сессий важен для клиентов, часто переподключающихся при интенсивном HTTPS-трафике. Слишком маленький кэш снижает частоту resumption. Очень большой кэш должен учитываться в планировании памяти.

Поведение TCP keepalive

TCP keepalive на уровне ОС сигнализирует промежуточным слоям, что соединение всё ещё живо. Это снижает вероятность того, что NAT-устройства, firewall или stateful security appliance преждевременно закроют простаивающие соединения. Настройка наиболее ценна для долгоживущих соединений.

Параллелизм HTTP/2-потоков

Количество параллельных потоков через одно HTTP/2-соединение может быть ограничено. Слишком низкое значение снижает эффект мультиплексирования; слишком высокое рискует перегрузить одно соединение. Правильная настройка зависит от состава трафика.

HTTP/2 frontend, HTTP/1.1 backend

Когда на стороне клиента используется HTTP/2, но backend работает на HTTP/1.1, поведение потоков на стороне backend не зеркалирует тот же параллелизм. Некоторые запросы могут быть сериализованы в соответствии с моделью backend-соединений. Если backend поддерживает HTTP/2, стоит рассмотреть включение соответствующего переключателя.

Влияние TLS-терминации на CPU

Когда TLS терминируется TR7, а не backend, нагрузка TLS-handshake с backend исчезает. ADC принимает на себя стоимость обработки TLS. TLS session resumption и connection pool вместе помогают компенсировать эту стоимость.

Метрики мониторинга

Итоги запросов, глубина очереди, количество соединений, поведение повторного использования и метрики ошибок отражают состояние connection pool. Низкое повторное использование — повод пересмотреть настройки таймаутов или поведение backend. Растущая очередь сигнализирует о необходимости скорректировать ёмкость backend-соединений или лимиты maxconn.

Когда применять

Экономия соединений на высоконагруженном API-шлюзе

SaaS API генерируют короткие плотные объёмы запросов. Connection multiplexing снижает количество backend-соединений и устраняет повторные затраты на TCP/TLS установку.

Снижение задержки повторного подключения для мобильного API-трафика

Мобильные клиенты часто открывают и закрывают соединения. Keepalive, HTTP/2 и TLS resumption снижают стоимость переподключения на стороне клиента.

Использование backend HTTP/2 в среде микросервисов

Для backend с поддержкой HTTP/2 можно включить переключатель ALPN для оценки мультиплексирования потоков. Это даёт более эффективное использование соединений при высокочастотных межсервисных вызовах.

Persistent connection pool для трафика медиа-origin

Edge или плотный клиентский трафик может использовать пул существующих соединений к origin-backend вместо постоянного открытия новых. Это снижает CPU и нагрузку на сокеты origin.

Safe режим повторного использования для банковских транзакций

Для неидемпотентных финансовых операций safe mode предпочтительнее aggressive повторного использования. Это позволяет добиваться прироста производительности, сохраняя целостность транзакций.

Снижение TLS-накладных расходов для B2B API-вызовов

B2B-сервисы часто несут высокоценные низкочастотные запросы, тем не менее несущие значительную стоимость TLS. Connection pool и session resumption снижают накладные расходы установки защищённых соединений.

Часто задаваемые вопросы

В чём разница между режимами http-reuse?

TR7 предлагает четыре режима повторного использования. never ведёт себя близко к модели нового соединения на каждый запрос. safe применяет повторное использование только к идемпотентным операциям, таким как GET и HEAD — это предпочтительный выбор для банковских и платёжных API. aggressive распространяет повторное использование на методы такие как POST и PUT для более значительной экономии. always выбирает наиболее агрессивное поведение и подходит для высоконагруженных, низкорискованных сервисов. Операторы выбирают режим, отражающий профиль производительности и безопасности каждого сервиса.

Как включить HTTP/2 на стороне backend?

Backend HTTP/2 включается per-service переключателем. Когда backend поддерживает HTTP/2, ALPN автоматически согласовывает h2 или http/1.1. Сервисы без поддержки HTTP/2 возвращаются к HTTP/1.1 без каких-либо изменений в их конфигурации. Это позволяет современным backend выигрывать от HTTP/2, оставляя legacy-сервисы незатронутыми.

Как работает TLS session resumption и насколько CPU она экономит?

TLS session resumption позволяет возвращающемуся клиенту переподключиться, используя кэшированный материал сессии из предыдущего handshake, пропуская полные TLS-переговоры. TLS 1.2 session tickets и TLS 1.3 PSK механизмы оба это поддерживают. При интенсивном HTTPS-трафике использование CPU ADC, приходящееся на TLS, может быть снижено на 95% и более; реальная цифра зависит от профиля трафика и частоты переподключений.

Является ли поддержка HTTP/3 frontend production-ready?

Да, и дело не ограничивается краем сети. HTTP/3/QUIC активен в продуктиве на фронтенде — более быстрая установка соединения для мобильных клиентов, лучшая непрерывность потоков в сетях с потерями, откат на HTTP/2 для тех клиентов, кому он нужен. TR7 говорит на QUIC и с бэкендом, и это один переключатель: анонс alt-svc, правило UDP и H3/H2/H1 на одном адресе делаются за вас. Терминировать HTTP/3 на краю и идти дальше по HTTP/1.1 — значит отдать половину выигрыша.

Как следует устанавливать значение keepalive-таймаута?

Слишком короткий keepalive-таймаут приводит к закрытию соединений до их переиспользования, снижая эффективность пула. Слишком длинный увеличивает число простаивающих соединений и потребление памяти. Правильное значение зависит от плотности трафика и ёмкости backend; начальный диапазон 60–120 секунд является распространённым. TR7 позволяет управлять профилями таймаутов независимо per-service.

Сбрасываются ли существующие соединения при изменении конфигурации?

Нет. Во время soft reload старый worker контролируемо дрейнирует существующие соединения, тогда как новый worker принимает входящие соединения под обновлённой конфигурацией. Connection pool не нарушается резко. Операторы могут изменять значения таймаутов, режимы повторного использования или настройки ALPN, сохраняя непрерывность сервиса, что снижает операционный риск production-изменений.

Освободите backend от накладных расходов соединений

Keepalive-пул, режимы http-reuse, HTTP/2, HTTP/3 и TLS session resumption — вся оптимизация соединений в единой политике ADC. Давайте разберём живую настройку на ваших собственных сервисах.