Итак; реализация SSL в Java не особенно быстра в большинстве случаев. Япросмотренные блогидемонстрирует заметное ускорение при переносе Java-приложения в Solaris для использования преимуществ SSL на основе ядра.
Все это прекрасно работает на оборудовании Sun/Oracle (особенно на базе SPARC), которое оснащено встроенными ускорителями, но есть ли какие-либо материалы о том, как будет работать приложение Java, если Solaris установлен на стандартном компьютере Intel (или даже VPS) без аппаратного ускорения?
т. е. Насколько KSSL ускоряет работу Java-приложения с поддержкой SSL на компьютере Solaris x86?
решение1
Обратите внимание, что 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. То есть скорость более чем удвоилась.
решение2
Прокси-сервер SSL на базе ядра Solaris обеспечивает повышение производительности за счет: 1. объединения данных, что позволяет сократить количество системных вызовов read() прокси-приложения; 2. передачи криптоопераций поставщикам аппаратного криптообеспечения.
Улучшение первого пункта, вероятно, намного меньше по сравнению с разгрузкой криптографических операций. Второй пункт зависит от количества сеансов SSL, обрабатываемых KSSL, объема трафика, базового оборудования и наборов шифров, используемых клиентами и поддерживаемых KSSL.
На x86 в Solaris вторая точка в настоящее время видна только для наборов шифров SSL/TLS на основе AES на машинах, которые поддерживают набор инструкций Intel AES-NI. Это в основном Intel Westmere и более поздние версии. В настоящее время ни один другой шифр не ускоряется на архитектурах Intel/AMD, поэтому это справедливо только для 2 наборов шифров, поддерживаемых KSSL: rsa_aes_256_cbc_sha и rsa_aes_128_cbc_sha. Учитывая, что это только симметричное ускорение шифра, оно больше окупается для объемной передачи данных, чем для кратковременных соединений с небольшими объемами данных.
Что касается количественной оценки улучшения производительности, тестирование с openssl(1) speed даст некоторые подсказки, но следует проявлять осторожность, поскольку движок OpenSSL PKCS#11 должен проходить через несколько слоев (движок OpenSSL, метаслот PKCS#11, API ядра PKCS#11 /dev/crypto для ядра), поэтому накладные расходы слоев могут довольно сильно исказить измерения, особенно для небольших размеров данных. KSSL имеет только один очень тонкий слой (API Kernel Crypto Framework), через который нужно пройти, и для фактической обработки записей SSL нет накладных расходов на переход системных вызовов.