Так; Реализация SSL в Java в большинстве случаев не очень быстрая. Я видел блоги демонстрируя заметное ускорение, когда приложение Java перемещается в Solaris, чтобы воспользоваться преимуществами SSL на основе ядра.
Все это хорошо и хорошо для оборудования Sun / Oracle (особенно на основе SPARC), которое предоставляет встроенные ускорители, но есть ли какие-либо материалы о том, как приложение Java будет работать, когда установка Solaris находится на обычном компьютере Intel (или даже на VPS ) без аппаратного ускорения?
То есть насколько KSSL ускоряет работу Java-приложения с поддержкой SSL в системе x86 Solaris?
SSL-прокси ядра Solaris обеспечивает повышение производительности за счет: 1. объединения данных, так что требуется меньше системных вызовов read () прокси-приложения 2. разгрузки операций шифрования поставщикам аппаратного шифрования
Улучшение первого пункта, вероятно, намного меньше по сравнению с разгрузкой криптографических операций. Второй момент зависит от количества сеансов SSL, обрабатываемых KSSL, объема трафика, базового оборудования и наборов шифров, используемых клиентами и поддерживаемых KSSL.
На x86 в Solaris вторая точка в настоящее время видна только для наборов шифров SSL / TLS на основе AES на машинах, которые поддерживают набор инструкций Intel AES-NI. Это в основном Intel Westmere и новее. Никакой другой шифр в настоящее время не ускоряется на архитектурах Intel / AMD, поэтому это справедливо только для двух наборов шифров, поддерживаемых KSSL: rsa_aes_256_cbc_sha и rsa_aes_128_cbc_sha. Учитывая, что это только симметричное ускорение шифрования, оно больше платит за передачу больших объемов данных, чем за краткосрочные соединения с небольшими объемами данных.
Что касается количественной оценки улучшения производительности, тестирование на скорости openssl (1) даст некоторые подсказки, но следует проявлять осторожность, поскольку движок OpenSSL PKCS # 11 должен проходить через несколько уровней (движок OpenSSL, метаслот PKCS # 11, ядро PKCS # 11 / dev / crypto API к ядру), поэтому накладные расходы слоев могут очень сильно исказить измерения, особенно для небольших размеров данных. У KSSL есть только один очень тонкий слой (Kernel Crypto Framework API) для прохождения, и нет накладных расходов на переход системных вызовов для фактической обработки записей SSL.
Обратите внимание, что x86 может получить некоторое ускорение для SSL от CPU. Вы можете получить список ускорителей, запустив cryptoadm list -mv. Даже у поставщика программного обеспечения ядра есть некоторые оптимизации. Это те же провайдеры, которые используют KSSL.
Чтобы измерить разницу, запустите, например, следующее:
/usr/sfw/bin/openssl speed rsa2048
/usr/sfw/bin/openssl speed rsa2048 -engine pkcs11
Первый - это чистое программное обеспечение, а второй - провайдер с ускоренным ядром, доступный как токен PKCS11. Именно эти двое на моем старом T1 Niagara показывают 8,4 знака / с против 19740,0 знака / с. Это определенно огромная разница. Современные процессоры x86 могут, например, ускорять AES, и, насколько мне известно, он используется поставщиком программного ядра. Проверьте сами, в чем разница. Более важно иметь быстрые асимметричные шифры, потому что они используются во время установления соединения и более требовательны к процессору ... веб-приложения часто закрывают соединение.
Кстати, KSSL на самом деле просто в прокси-сервере SSL для шифрования ядра ... факт, что это происходит в ядре, тоже влияет на скорость.
Просто для сравнения ... на другой машине ~ того же возраста, что и T1, отмеченный выше, но x86 в VMware у меня показывает 42,1 знака / с по сравнению с 98,6 знака / с для rsa2048. Так что скорость увеличилась более чем вдвое.