Параллельно с разработкой криптопровайдера 4.0 мы также работали над улучшением IPsec API. Долгое время наш интерфейс не позволял работать параллельно в рамках одной сессии ESP, что плохо сказывалось на производительности, так как практически никогда не удавалось задействовать более одного ядра процессора при работе туннеля. В наше оправдание, нам не известна ни одна реализация IPsec с российскими алгоритмами обеспечивающая распараллеливание в рамках одной сессии IPsec ESP. Теперь же — ни одна, кроме нашей.
Введение
IPsec — набор протоколов защиты сетевого трафика. ESP — протокол защиты конечных пакетов. Наше IPsec API полностью соответствует техническим спецификациям ТК26 по использованию отечественной криптографии, которые определяют обеспечение ESP конфиденциальности, целостности и аутентичности данных при использовании алгоритмов ГОСТ. Существует два режима работы ESP ГОСТ: режим 4M, который соответствует классам защиты с КС1 по КС3, и режим 1K, соответствующий классу KB2. В основе работы данных режимов лежит дерево ключей, в корне которого находится базовый ключ полученный в процессе согласования ключей, ветви — ключи диверсификации основного ключа, ведущие к ключам, которые будут использованы для конкретного пакета в зависимости от его номера. Для режима 4M определено использование одного ключа на 64 пакета (произведение 64 пакетов на максимальный размер пакета в 64 килобайта даёт 4 мегабайта, отсюда название режима). Для режима 1K определено использование одного ключа на один пакет в сочетании с усложнением ключа каждые 1024 байта (отсюда название 1K).
Проясним, какой же всё-таки практический смысл от работы одной сессии в многопоточном режиме. В настоящий момент наш сертифицированный вариант IPsec API позволяет работать каждой сессии ESP в своём потоке. На практике, имея большое количество клиентских сессий, мы можем равномерно загрузить все ядра процессора, так что каждая сессия будет обрабатываться на своём ядре — в итоге мы получим хорошую суммарную производительность и, в идеальных условиях, можем загрузить все ядра по максимуму. Всё меняется, когда задача заключается в соединении небольшого количества точек высокопроизводительными туннелями: в этом случае принципиальным моментом будет максимальная скорость каждого конкретного туннеля. Как уже было сказано выше, при отсутствии возможности распараллеливания сессии ESP мы не сможем загрузить более одного ядра процессора для каждого туннеля, и поэтому наша максимальная производительность туннеля всегда будет упираться в производительность одного логического процессора. А остальные ядра при этом будут простаивать без работы.
Распараллеливание сессии ESP — сложная задача, которая решается исключением ожидающих блокировок на всех этапах обработки пакета. В частности, должны быть решены следующие подзадачи: алгоритм проверки повторных пакетов не должен иметь блокировок, получение случайных чисел должно быть доступно во всех потоках одновременно, дерево ключей должно уметь строиться в любых условиях, как в хороших — когда ключи уже рассчитаны заранее, так и в условиях многопоточной гонки — когда генерация ключей может происходить параллельно, и, конечно, шифрование с расчётом имитовставки на одном и том же ключе в разных потоках должно быть доступно без блокировок на уровне криптопровайдера.
На стороне криптопровайдера задача была решена внедрением поддержки дочернего контекста провайдера для работы в нити (PP_CREATE_THREAD_CSP): он аналогичен родителю, но живёт в своей независимой памяти, что позволяет ему выполнять некоторые операции с ключом, не блокируя ключ на запись (CP_CRYPT_NOKEYWLOCK).
Эта разработка была использована для реализации возможности распараллеливания ESP. При инициализации нашего IPsec API пользователь может задать максимальное количество потоков, на которые он рассчитывает распараллеливать сессии. Как правило, это число соответствует количеству доступных логических процессоров. Также мы добавили в IPsec API возможность работы с мультипакетами, что позволило обрабатывать в одном вызове IPsec API до 64 пакетов одновременно.
Масштабируемость: потоки
Продемонстрируем текущие возможности масштабирования IPsec API. Ключевым моментом масштабирования является изменение эффективности работы потоков при добавлении нового потока. За «эффективный поток» примем производительность IPsec API в однопоточном режиме и измерим производительность в многопоточных режимах.
Как видно из графиков, при многопоточной работе в режиме 4M вплоть до 16 потоков сохраняется прирост производительности, пусть и ослабевающий, но для малых пакетов дальнейшее увеличение количества потоков приводит к деградации производительности, что связано с возрастающей долей накладных расходов. Для больших пакетов рост производительности сохраняется вплоть до 32 потоков. Также рост производительности сохраняется для малых пакетов при использовании мультипакетного режима в режиме 4M.
Масштабируемость: мультипакеты
Мультипакет — это специальным образом сформированная структура данных, предназначенная для обработки более одного пакета за одну операцию. За 100% примем производительность обработки пакета в привычном режиме (один пакет за операцию) и оценим эффективность мультипакетного режима как соотношение производительности между вариантом с обработкой нескольких пакетов в мультипакете и привычной работы «по одному пакету за операцию».
Как видно из графиков, во всех режимах работы 4M, кроме случая малых пакетов, наблюдается заметное снижение производительности при использовании менее 4 пакетов в мультипакете. Это объясняется тем, что скорость шифрования уступает скорости расчёта имитовставки, которая не распараллеливается операциями в SSSE3 и AVX в рамках одного пакета, тем самым снижая общую производительность. Также можно заметить, что оптимальным числом пакетов в мультипакете является 16: время расчёта имитовставки в 16 пакетах в среднем близко с шифрованием этих пакетов. Дальнейшее увеличение пакетов в мультипакетном режиме приводит, в зависимости от параметров, к незначительному росту или падению производительности. Также отметим великолепную масштабируемость работы с малыми пакетами при любом количестве пакетов в мультипакете, что является свидетельством уменьшения влияния накладных расходов, которое мы наблюдали в работе с малыми пакетами в многопоточном режиме.
Масштабируемость с использованием мультипакетного режима в режиме 1К соответствует ожиданию того, что данный режим работы ESP принципиально не ускоряется при использовании мультипакета, по причине обработки каждого пакета на своём ключе. Наблюдается незначительный рост производительности во всех режимах, что свидетельствует о снижении накладных расходов на вызов при отсутствии каких-либо других преимуществ.
Оценка производительности одного потока
Для оценки производительности мы собрали данные о работе нашего IPsec API в однопоточном режиме на разных процессорах. На основе приведённой выше информации о масштабируемости потоков и мультипакетов можно получить приблизительную оценку максимальных возможностей процессоров (для точной оценки производительности своей конфигурации можно воспользоваться дополнительными материалами в конце статьи).
По полученным результатам можно сделать несколько замечаний. Даже самый слабый из представленных процессоров, Intel Atom N450, при оптимальной нагрузке способен выдать скорость более 100 Мбит/с. С другой стороны, даже тривиальная реализация в один поток без использования мультипакета на хорошем процессоре способна выдать скорость более 500 Мбит/с, а оптимальная загрузка всех возможностей процессора позволяет достичь скоростей порядка 1 Гбит/с, даже на таких процессорах как Intel Celeron J1900.
Оценка максимальной производительности
Чтобы оценить максимально возможные скорости работы, мы измерили работу IPsec API только при оптимальных параметрах тестов (согласно полученным ранее результатам), которыми являются 16 пакетов в мультипакете и, ограниченное числом 32, максимально доступное количество реальных потоков.
Хорошо заметно, что текущим пределом являются скорости порядка 12.5 Гбит/с для режима 4M. В режиме 1К скорость растёт пропорционально размеру пакета и для больших пакетов (более 60000 байт) достигает значений более 8 Гбит/с.
Дополнительные материалы
Если вы хотите оценить производительность IPsec API самостоятельно, то для вас доступен наш самодостаточный IPsecPerfTest (для ОС Windows). Все текущие замеры были приведены с его помощью на основе скриптов которые также доступны в архиве.
Для ознакомления с версией КриптоПро IPsec API версии 4.0 мы подготовили файл chm с документацией нашего API для разработчиков.
* — пакетов в мультипакете
Пичулин Дмитрий
ведущий инженер-программист
ООО «КРИПТО-ПРО»