Сегодня HTTPS — не рекомендация, а де‑факто стандарт. Это защищённая версия HTTP, построенная на базе протокола TLS. Она оберегает пользователей от перехвата данных, атак типа «человек посередине» и множества других угроз.

Это огромный шаг вперёд в безопасности интернета — но за него приходится платить. Инфраструктурные издержки выросли: backend-серверам всё труднее справляться с объёмом и сложностью шифрованного трафика. Основные причины — это:

• Взрывной рост HTTPS. Если раньше TLS применяли только на страницах входа или оплаты, то теперь шифруется буквально всё. По данным Google Transparency Report, в 2024 году доля HTTPS в большинстве браузеров и регионов превысила 90%.

• Усложнение криптографии. Если TLS 1.0 и 1.1 были относительно лёгкими для CPU, то начиная с TLS 1.2, а особенно с TLS 1.3, в игру вступили более ресурсоёмкие механизмы: обязательный обмен ключами через ECDHE или X25519, отказ от сессионного RSA в пользу алгоритмов с forward secrecy, и широкое применение AEAD-шифров (например, AES-GCM и ChaCha20-Poly1305), которые одновременно шифруют и проверяют целостность данных.

• Больше соединений на одного пользователя. Современные веб-приложения постоянно обмениваются данными с сервером: используют фоновые обновления, push-уведомления, WebSocket-каналы. Это увеличивает количество TLS-сессий и HTTPS-запросов от одного клиента.

Что это значит на практике?

Переход с HTTP на HTTPS может увеличить нагрузку на CPU backend-серверов на 40–80% — особенно при тысячах одновременных соединений, коротких сессиях и использовании RSA-сертификатов. Эта нагрузка масштабируется вместе с ростом трафика и может превратиться в узкое место.

Ответом стал SSL-офлоадинг на внешних устройства

Чтобы разгрузить backend, криптографическую обработку начали выносить на внешние узлы, такие как L7-балансировщики. Именно там происходит TLS-терминация: HTTPS-трафик расшифровывается, и в backend-сервисы он поступает уже как обычный HTTP.

Технически корректно называть это TLS-офлоадингом — современные протоколы давно ушли от устаревшего SSL. Но термин «SSL-офлоадинг» закрепился в индустрии и до сих пор используется по привычке.

В аппаратных L7-балансировщиках, таких как F5 BIG-IP, Citrix Netscaler или Kemp LoadMaster, для обработки HTTPS-трафика применяются специализированные ASIC-ускорители — отдельные от CPU чипы, разработанные специально для быстрой криптографической обработки и снижения нагрузки на основной процессор.

С развитием технологий Intel обработка HTTPS-трафика становится эффективной прямо на CPU

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

С выходом процессоров Intel Xeon 4-го поколения (Sapphire Rapids) криптографическое ускорение стало доступно прямо внутри CPU. Теперь шифрованный трафик можно обрабатывать непосредственно на процессоре — аппаратно, быстро и без компромиссов по производительности.

Intel QAT: от внешнего ускорителя к встроенной функции CPU

Intel QuickAssist Technology (Intel QAT) — это аппаратный ускоритель, предназначенный для выполнения ресурсоёмких криптографических операций: от обработки HTTPS и IPsec до VPN и других защищённых соединений. Он снижает нагрузку на ядра CPU и существенно повышает пропускную способность системы.

Свою историю QAT начала ещё в 2007 году как отдельные PCIe-карты (например, Intel 8950), которые использовались как внешние SSL-ускорители в высоконагруженных системах. Позже технология переехала в чипсеты (например, Intel C62x), а с приходом Xeon 4-го поколения окончательно интегрировалась прямо в процессор.

Преимущества Intel QAT

• Широкая совместимость. Поддержка всех основных ОС (Linux, Windows Server, FreeBSD), гипервизоров (KVM, VMware, Hyper-V) и популярных фреймворков: OpenSSL, NGINX, HAProxy и других.

• Прозрачная интеграция. QAT подключается через стандартные интерфейсы OpenSSL — без необходимости вносить серьёзные изменения в код приложений.

• Современная криптография. Поддерживаются актуальные алгоритмы: AES-GCM, ChaCha20, RSA, ECC, ECDSA и другие. Полный список доступен в официальной документации на GitHub.

Примеры улучшения производительности с Intel QAT на практике

Эффективность Intel QAT в реальных сценариях подтверждена официальными тестами и отраслевыми бенчмарками. Полный перечень доступен на странице Intel Performance Benchmarks.

Один из самых наглядных кейсов — прирост производительности веб-сервера NGINX при обработке TLS handshakes. Это этап установления защищённого соединения между клиентом и сервером, во время которого происходит обмен ключами, выбор шифров и аутентификация. Все эти операции — ресурсоёмкие и заметно нагружают CPU.

Конфигурация теста:

• Процессор: Intel® Xeon® Platinum 8470N (Sapphire Rapids, 4-е поколение Xeon)

• Криптонабор: TLS 1.3, ECDHE-X25519, RSA-2048

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

В тесте использовался современный и широко применяемый криптонабор на базе TLS 1.3:

• ECDHE-X25519 — алгоритм обмена ключами на основе эллиптических кривых. Он обеспечивает forward secrecy: даже если закрытый ключ сервера станет доступен, трафик прошлых сессий останется защищённым.

• RSA-2048 применялся для цифровой подписи, подтверждающей подлинность сервера при установке соединения.

Результаты с включённым Intel QAT:

Подробности — в документе Intel QuickAssist Technology (QAT) – NGINX Performance white paper.

Сравнение с классическими оффлоадерами

Intel также провела совместные тесты с L7-балансировщиками F5 и Citrix NetScaler. Результаты показали, что использование Intel QAT даже в программных версиях этих решений обеспечивает уровень производительности, сопоставимый с аппаратными ускорителями, встроенными в специализированные устройства.

Заключение

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

В архитектурах с L7-балансировщиками отпадает необходимость в дорогостоящих ASIC-ускорителях — SSL-офлоадинг можно выполнять на уровне CPU, снижая стоимость и упрощая инфраструктуру.

С переходом на современные серверные процессоры в архитектурах с L4-балансировщиками снова становится актуальной модель распределённой TLS-терминации — когда расшифровка HTTPS-трафика происходит непосредственно на сервере. Такой подход даёт ряд важных преимуществ:

• Соответствие принципам Zero Trust. Трафик передаётся в зашифрованном виде от клиента до приложения, что исключает централизованные точки доверия и минимизирует риски перехвата.

• Гибкая настройка безопасности. Сервер получает полную информацию о параметрах клиента — включая используемый криптонабор и TLS-опции, что позволяет адаптировать политику шифрования под конкретные запросы.

• Повышение отказоустойчивости. TLS-сессии устанавливаются напрямую между клиентом и сервером, поэтому при переключении на резервный балансировщик соединение сохраняется — без обрывов.

Таким образом, Intel QAT делает распределённую модель не только возможной, но и эффективной: теперь выбор архитектуры зависит не от технических ограничений, а исключительно от задач бизнеса.

А как у вас?

Поделитесь в комментариях, как вы обрабатываете зашифрованный трафик в своей инфраструктуре. Используете ли внешние устройства, централизуете TLS-терминацию или распределяете её ближе к приложениям?

Если вам близка тема производительной балансировки и хочется больше практики и разборов — присоединяйтесь к нашему Telegram-каналу (t.me/dsproxima). Там мы делимся опытом, архитектурными решениями и реальными кейсами по работе с L4-балансировщиками.