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

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

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

Видеоверсия

Для вашего удобства подготовлена видеоверсия этой статьи, доступна на 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 -DNGX_DEBUG_PALLOC -DNGX_DEBUG_MALLOC -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
6929,8	3888,2	4268,8

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

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

AWS-LC 5.0.0	OpenSSL 3.5.5	OpenSSL 4.0.1
7019,4	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
6984,8	8640,6	9083,8

Еще одна явная тенденция: OpenSSL резко выходит вперёд с использованием старой версии TLS 1.2. Производительность AWS‑LC остаётся примерной той же.

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

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

Здесь AWS‑LC почти догоняет OpenSSL, но всё ещё проигрывает обоим версиям.

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

Тестирование малых запросов (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
68111,2	73769,2	72126,4

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

Осталось протестировать пропускную способность сервера с различными библиотеками. Для этого потребуется ресурс большого размера (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,508	1,484	1,472

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

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

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

AES-128	AES-256	CHA-CHA20
0,978	1,47	0,764

Ещё один неожиданный результат. Тотальное превосходство AES-256 и значительное отставание CHA‑CHA20. Такую разницу (более чем в два раза) сложно объяснить, особенно если сравнить эти результаты с бенчмарком 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 и CHA‑CHA20. При этом разница между первым и третьим укладывается в 20%.

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

Выводы

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

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

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