Влияние TLS-библиотек и настроек на производительность / Хабр

Тонкая настройка TLS необходима для современного веб‑сервера, обратного прокси или балансировщика с терминацией TLS. При этом тема достаточно запутанная для изучения, в сети можно найти множество устаревших материалов и откровенных мифов. В этой статье будем тестировать влияние важных настроек и вариантов TLS‑библиотек на примере веб‑сервера Angie.

Update 13.07.2026: обновлены измерения для AWS-LC без флагов отладки и нескольких других тестов.

Навигация по циклу

Видеоверсия

Для вашего удобства подготовлена видеоверсия этой статьи, доступна на Rutube, VKVideo и YouTube.

Взаимодействие Angie с TLS-библиотеками

Сервер Angie делегирует большинство операций для работы с TLS библиотеке. По умолчанию пакеты для Linux‑систем собираются с системной версией библиотеки. Например, для Ubuntu 26.04 и AlmaLinux 10.1 это OpenSSL 3.5.5, а в Ubuntu 24.04 это OpenSSL 3.0.13. Вероятность значительного обновления версии библиотеки в течение жизненного цикла дистрибутива довольно низкая. Таким образом, чтобы использовать другую версию OpenSSL проще поменять Linux‑дистрибутив. Другим решением будет использование Angie в виде docker‑контейнера.

Помимо OpenSSL существует несколько альтернативных проектов библиотек, которые направлены на оптимизацию производительности и сокращение избыточного для веба кода. Например, Google разрабатывает BoringSSL, форк OpenSSL, заточенный под задачи компании. Также есть LibreSSL, WolfSSL и другие. На данный момент одна из популярных библиотек называется AWS‑LC, она основана на коде BoringSSL и OpenSSL. Для Angie заявлена совместимость с AWS‑LC с версии 1.11.0, поэтому мы будем использовать её как «альтернативную версию» библиотеки в нашем тесте. Некоторые форки OpenSSL значительно усложняют поддержку пакетов, так как у них отсутствуют стабильные релизы. Важно понимать, что версии и варианты библиотек также могут различаться по функциональности (поддержке тех или иных технологий). Например, для LibreSSL не поддерживаются переменные в директивах настройки сертификата и ключа.

Методика проведения теста

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

виртуальная машина (ВМ) KVM;
операционная система (ВМ): Ubuntu 26.04, OpenSSL 3.5.5;
веб-сервер Angie 1.11.7;
процессор: AMD Ryzen 7 5800x (4 CPU в ВМ);
оперативная память ВМ: 4096 МБ;
хостовая ОС: Ubuntu 24.04, OpenSSL 3.0.13;
утилита нагрузочного тестирования wrkx.

Возможности процессора могут оказывать значительное влияние на результаты тестов, например наличие инструкций AES‑NI или векторных расширений AVX.

Базовым вариантом будет Angie, установленный из пакетов, работающий с системной версией OpenSSL 3.5.5. Второй вариант будет статическая сборка Angie с OpenSSL 4.0.1. Сравнение с системной библиотекой позволит увидеть разницу в версиях одной и той же библиотеки. Третий вариант будет использовать статическую сборку Angie с AWS‑LC 5.0.0. Так как альтернативные версии были собраны статически, переключение между ними проводились с помощью редактирования символической ссылки /usr/sbin/angie на исполняемый файл веб‑сервера и последующей перезагрузки сервиса.

Для исключения влияния побочных факторов во всех тестах использовался один рабочий процесс Angie. При тестировании во всех сценариях достигалась полная утилизация процессора работой процесса Angie (100%). Тесты запускались на хостовой машине в сторону ВМ, параметры wrkx подбирались для полноценной утилизации рабочего процесса.

Конфигурация веб‑сервера минимально изменена относительно комплектных файлов настроек. Основные изменения в /etc/angie/angie.conf:

http {
    access_log      off;
    sendfile        on;
    tcp_nopush      on;
    tcp_nodelay			on;
    reset_timedout_connection 	on;
    etag            off;

    keepalive_timeout  120;
    keepalive_requests 10000;

    open_file_cache          max=10000 inactive=60s;
    open_file_cache_valid    30s;
    open_file_cache_min_uses 2;

    #ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256;
    #ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384;
    #ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  28h;
    ssl_protocols TLSv1.2 TLSv1.3;
}

Значения некоторых директив изменялись, чтобы обеспечить условия теста (версии ssl_protocols, шифры в ssl_conf_command). В качестве тестового сайта был настроен статический сервер такой конфигурации:

server {
    listen       80;
    listen	443 ssl;

    #ssl_certificate      /etc/angie/ssl/rsa.pem;
    #ssl_certificate_key  /etc/angie/ssl/rsa.key;
    ssl_certificate      /etc/angie/ssl/ecdsa.pem;
    ssl_certificate_key  /etc/angie/ssl/ecdsa.key;

    server_name  localhost;

    location / {
        root   /usr/share/angie/html;
    }

    location /zero/ {
	return 200 'OK';
    }

    location /status/ {
        api     /status/;
        allow   127.0.0.1;
        deny    all;
    }
}

Сайт имеет два сертификата: RSA 2048 бит и EC 256 бит. Переключение между ними производилось для сравнения в нескольких тестах. Это реальные действующие сертификаты, выданные удостоверяющим центром Let’s Encrypt.

Локация /zero/ предназначена для быстрого ответа минимальной длины и используется при измерении скорости TLS‑рукопожатий. В корневой директории сайта расположены текстовые файлы различной длины (1 КБ, 10 МБ, 100 МБ). Они используются для сценариев загрузки малых ресурсов (1 КБ) и тестирования пропускной способности (100 МБ). Файлы отдаются в неизменном виде, текстовая компрессия не применяется.

Параметры сборки версии из пакета:

--prefix=/etc/angie --conf-path=/etc/angie/angie.conf --error-log-path=/var/log/angie/error.log --http-log-path=/var/log/angie/access.log --lock-path=/run/angie.lock --modules-path=/usr/lib/angie/modules --pid-path=/run/angie.pid --sbin-path=/usr/sbin/angie --http-acme-client-path=/var/lib/angie/acme --http-client-body-temp-path=/var/cache/angie/client_temp --http-fastcgi-temp-path=/var/cache/angie/fastcgi_temp --http-proxy-temp-path=/var/cache/angie/proxy_temp --http-scgi-temp-path=/var/cache/angie/scgi_temp --http-uwsgi-temp-path=/var/cache/angie/uwsgi_temp --user=angie --group=angie --with-file-aio --with-http_acme_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_v3_module --with-mail --with-mail_ssl_module --with-stream --with-stream_acme_module --with-stream_mqtt_preread_module --with-stream_rdp_preread_module --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --feature-cache=../angie-feature-cache --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,--package-metadata=%7B%22type%22:%22deb%22%2C%22os%22:%22ubuntu%22%2C%22name%22:%22angie%22%2C%22version%22:%221.11.8-1~resolute%22%2C%22architecture%22:%22amd64%22%7D -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now'

Версия с OpenSSL 4.0.1:

--prefix=/etc/angie --conf-path=/etc/angie/angie.conf --error-log-path=/var/log/angie/error.log --http-log-path=/var/log/angie/access.log --lock-path=/run/angie.lock --modules-path=/usr/lib/angie/modules --pid-path=/run/angie.pid --sbin-path=/usr/sbin/angie --http-acme-client-path=/var/lib/angie/acme --http-client-body-temp-path=/var/cache/angie/client_temp --http-fastcgi-temp-path=/var/cache/angie/fastcgi_temp --http-proxy-temp-path=/var/cache/angie/proxy_temp --http-scgi-temp-path=/var/cache/angie/scgi_temp --http-uwsgi-temp-path=/var/cache/angie/uwsgi_temp --user=angie --group=angie --with-file-aio --with-http_acme_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_v3_module --with-mail --with-mail_ssl_module --with-stream --with-stream_acme_module --with-stream_mqtt_preread_module --with-stream_rdp_preread_module --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --feature-cache=../angie-feature-cache --with-ld-opt='-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now' --with-openssl=/root/openssl-4.0.1

Версия с AWS-LC 5.0.0:

--prefix=/etc/angie --conf-path=/etc/angie/angie.conf --error-log-path=/var/log/angie/error.log --http-log-path=/var/log/angie/access.log --lock-path=/run/angie.lock --modules-path=/usr/lib/angie/modules --pid-path=/run/angie.pid --sbin-path=/usr/sbin/angie --http-acme-client-path=/var/lib/angie/acme --http-client-body-temp-path=/var/cache/angie/client_temp --http-fastcgi-temp-path=/var/cache/angie/fastcgi_temp --http-proxy-temp-path=/var/cache/angie/proxy_temp --http-scgi-temp-path=/var/cache/angie/scgi_temp --http-uwsgi-temp-path=/var/cache/angie/uwsgi_temp --user=angie --group=angie --with-file-aio --with-http_acme_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_v3_module --with-mail --with-mail_ssl_module --with-stream --with-stream_acme_module --with-stream_mqtt_preread_module --with-stream_rdp_preread_module --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --feature-cache=../angie-feature-cache --with-ld-opt=‘-Wl,-z,relro -Wl,-z,now -Wl,-rpath -L /root/aws-lc-5.0.0/build/ssl -L/root/aws-lc-5.0.0/build/crypto -lssl -lcrypto -lstdc++’ --with-cc-opt=‘-fPIC -I /root/aws-lc-5.0.0/include’

С тестовым стендом разобрались, можно переходить к самим тестам. Начнём с тестирования скорости TLS-рукопожатий.

Тестирование прозводительности ТLS-рукопожатий

Первая стадия взаимодействия клиента и сервера по HTTPS использует асимметричное шифрование и довольно затратна для сервера. Во время рукопожатия происходит согласование сессионного ключа для симметричной (основой) фазы работы соединения. На скорость процесса рукопожатия может оказывать влияние тип ключа (сертификата), версия протокола TLS, а также используемая библиотека. Эта метрика также обозначается как CPS (connections per second).

Для тестирования рукопожатий использовалась следующая команда:

./wrk -t 4 -c 100 -d 20s -R 10000 -H 'Connection: close' https://192.168.122.38/zero/

Начнём с результатов различных библиотек для актуальной версии TLS 1.3 и ECDSA‑сертификатами. Здесь и далее приведены средние значения результатов многократных запусков тестов. Единица измерения: подключения в секунду (CPS).

AWS-LC 5.0.0	OpenSSL 3.5.5	OpenSSL 4.0.1
7201	3888,2	4268,8

Первый сюрприз: влияние TLS‑библиотеки значительно, в явных лидерах AWS‑LC, версии OpenSSL также различаются в пользу более свежей версии, но отрыв между ними гораздо меньше, чем от AWS‑LC.

Переключимся на использование RSA‑сертификатов:

AWS-LC 5.0.0	OpenSSL 3.5.5	OpenSSL 4.0.1
7099	3920,6	4200,4

Расстановка по местам остаётся ровно такой же, но абсолютные значения немного подросли для двух участников. При этом ожидание было противоположным: ECDSA‑сертификаты принято считать более производительной заменой RSA для сервера.

А что, если перейти на TLS 1.2? Проводим те же измерения.

ECDSA‑сертификаты, TLS 1.2:

AWS-LC 5.0.0	OpenSSL 3.5.5	OpenSSL 4.0.1
12845,4	8640,6	9083,8

Здесь преимущество AWS-LC сохраняется, при этом абсолютная производительность для всех библиотек значительно возросла.

Проверяем RSA‑сертификаты с TLS 1.2:

AWS-LC 5.0.0	OpenSSL 3.5.5	OpenSSL 4.0.1
13133,6	8966,2	9520,4

При использовании RSA соотношение сохраняется, для всех библиотек есть небольшой прирост относительно ECDSA.

Переходим к тестированию небольших запросов.

Тестирование малых запросов (RPS)

В этом тесте используется TLS 1.3 с keep‑alive, ECDSA‑сертификат, шифры: TLS_AES_256_GCM_SHA384. Для объекта запроса используется статический текстовый файл размером 1 КБ, команда запуска теста:

./wrk -t 4 -c 100 -d 20s -R 100000 https://192.168.122.39/1kb.txt

Результаты в RPS (запросов в секунду) для различных версий библиотек:

AWS-LC 5.0.0	OpenSSL 3.5.5	OpenSSL 4.0.1
74368	73769,2	72126,4

Прежний лидер AWS-LC на этот раз практически сравнялся с двумя версиями OpenSSL, при этом сохранил небольшое преимущество. Попутно можно заметить высокую абсолютную производительность веб‑сервера со всеми вариантами библиотек. Напоминаю, что все приведённые данные получены с одним рабочим процессом, то есть на одном ядре процессора.

Осталось протестировать пропускную способность сервера с различными библиотеками. Для этого потребуется ресурс большого размера (100 МБ) и быстрая виртуальная сеть.

Пропускная способность (Throughput)

В этом тесте используется режим TLS 1.3, сертификат ECDSA (хотя он не должен оказывать здесь влияния), шифры: TLS_AES_256_GCM_SHA384.

Команда запуска теста:

./wrk -t 4 -c 16 -d 20s -R 32 https://192.168.122.39/100mb.txt

Результаты теста пропускной способности (ГБ/сек):

AWS-LC 5.0.0	OpenSSL 3.5.5	OpenSSL 4.0.1
1,612	1,508	1,498

Основной вклад в результат теста должна оказывать реализация алгоритма симметричного шифрования (AES-256). По результатам можно констатировать победу AWS-LC, но различие между всеми вариантами укладывается в 10%. Отрыв слишком мал, чтобы из-за него заниматься кастомной сборкой Angie.

Разницы между библиотеками практически нет, но мы можем выбирать сам алгоритм шифрования, проверим три основных шифра в TLS 1.3: AES-128, AES-256 и CHACHA20.

Результаты теста пропускной способности для OpenSSL 3.5.5 (ГБ/сек):

AES-128	AES-256	CHACHA20
1,554	1,524	1,18

В этом тесте побеждает AES-128, за ним с небольшим отрывом следует AES-256, на последнем месте CHACHA20. Различие (около 30%) несколько больше, чем во встроенном бенчмарке openssl:

openssl speed -elapsed -evp chacha20
openssl speed -elapsed -evp aes-128-gcm
openssl speed -elapsed -evp aes-256-gcm

Внутренний бенчмарк openssl показывает лучшие результаты для AES-128, далее AES-256 и CHACHA20. При этом разница между первым и третьим укладывается в 20%.

Подведём итоги теста.

Выводы

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

Наиболее важные для практики результаты с использованием TLS 1.3 и ECDSA‑сертификатов, так как эти режимы будут использоваться современными клиентами для взаимодействия по HTTPS. Однако, для тонкой настройки подключений внутри инфраструктуры можно использовать полный спектр режимов для максимальной производительности.

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

Следующая статья цикла: Сборка Angie из исходных кодов.