x86 KSSL сравнивает для поддерживающего SSL приложения Java
Вероятно, самая простая и самая быстрая опция состоит в том, чтобы использовать DNAT. Вы настроили бы дополнительный Интернет routable IP и NAT трафик в стандартных портах к Вашему дополнительному экземпляру. Это было бы сделано на Вашем маршрутизаторе.
Если Вам связали единственный сервер с Интернетом routable дюйм/с, Вы могли бы поднять тот дополнительный IP на сервере и связать Tomcat, к который, который позволил бы ему слушать на стандартных портах, если бы они не использовались чем-то еще.
Если у Вас есть прокси или подсистема балансировки нагрузки, можно потенциально настроить VIP или интерфейсы на них также.
Примечание что 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. Таким образом, скорость увеличилась более чем вдвое.
1 знак / с по сравнению с 98,6 знака / с для rsa2048. Таким образом, скорость увеличилась более чем вдвое. 1 знак / с по сравнению с 98,6 знака / с для rsa2048. Таким образом, скорость увеличилась более чем вдвое.SSL-прокси ядра Solaris обеспечивает повышение производительности на основе: 1. объединение данных так, чтобы требовалось меньше системных вызовов read () прокси-приложения. 2. Разгрузка криптографических операций поставщикам аппаратных средств шифрования
Улучшение первого пункта, вероятно, намного меньше по сравнению с разгрузкой криптоопераций. Второй момент зависит от количества сеансов SSL, обрабатываемых KSSL, объема трафика, базового оборудования и комплектов шифров, используемых клиентами и поддерживаемых KSSL.
В x86 на Solaris второй пункт в настоящее время виден только для SSL на основе AES. Наборы шифров / TLS на машинах, поддерживающих набор инструкций 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 kernel / dev / crypto API для ядра), поэтому накладные расходы на уровни могут очень сильно исказить измерения, особенно для небольших размеров данных. KSSL имеет только один очень тонкий слой (Kernel Crypto Framework API) для прохождения, и нет накладных расходов на переход системных вызовов для фактической обработки записей SSL.
тестирование скорости openssl (1) даст некоторые подсказки, но следует проявлять осторожность, поскольку движок OpenSSL PKCS # 11 должен проходить через несколько уровней (движок OpenSSL, метаслот PKCS # 11, ядро PKCS # 11 / dev / crypto API для ядра) поэтому накладные расходы слоев могут очень сильно исказить измерения, особенно для данных небольшого размера. У KSSL есть только один очень тонкий слой (Kernel Crypto Framework API) для прохождения, и нет накладных расходов при переходе системных вызовов для фактической обработки записей SSL. тестирование скорости openssl (1) даст некоторые подсказки, но следует проявлять осторожность, поскольку движок OpenSSL PKCS # 11 должен проходить через несколько уровней (движок OpenSSL, метаслот PKCS # 11, ядро PKCS # 11 / dev / crypto API для ядра) поэтому накладные расходы слоев могут очень сильно исказить измерения, особенно для данных небольшого размера. У KSSL есть только один очень тонкий слой (Kernel Crypto Framework API) для прохождения, и нет накладных расходов при переходе системных вызовов для фактической обработки записей SSL.