Сделайте SSL быстрее в Linux CentOS с Apache 2.4 OpenSSL 1.0

коллеги!

Что ж, у меня огромная проблема со скоростью SSL-аутентификации. Поскольку я перевожу свой веб-сайт на SSL, робот GoogleBot снижает индексирование моего веб-сайта, потому что SSL-согласование имеет значение ниже, которое я получил с помощью WebPageTest.org:

URL: https://www.musiconline.com.br/jorge-e-mateus/alcapao/

Хост: www.musiconline.com.br

Код ошибки / состояния: 200

Клиентский порт: 0

Начальное смещение: 0,735 с

Поиск DNS: 34 мс

Первоначальное подключение: 170 мс

Согласование SSL: 531 мс

Время до первого байта: 311 мс

Загрузка контента: 178 мс

Байт в (загружено): 13,2 КБ

Байт Out (загружено): 0,4 КБ

Послушайте, «SSL-согласование» составляет 531 мс, большое значение.

Кто-нибудь знает, как я могу решить эту проблему?

Я проверил mod_spdy, однако я не могу установить, потому что следующее сообщение в моем Linux CentOS 6, Apache 2.4:

root @ server1 [/ home / login / src] # rpm -U mod-spdy - *. rpm

предупреждение: mod-spdy-beta_current_x86_64.rpm: Заголовок V4 Подпись DSA / SHA1, идентификатор ключа 7fac5991: NOKEY

ошибка: Неудачные зависимости:

    httpd >= 2.2.4 is needed by mod-spdy-beta-0.9.4.3-420.x86_64

    mod_ssl >= 2.2 is needed by mod-spdy-beta-0.9.4.3-420.x86_64

root @ server1 [/ home / login / src] # httpd -v

Версия сервера: Apache / 2.4.12 (Unix)

Сервер построен: 21 марта 2015 г., 10:58:04

Cpanel :: Easy :: Apache v3.28.4 rev9999

root @ server1 [/ home / molbr / src] # uname -a

Linux server1.musiconline.com.br 2.6.32-431.20.3.el6.x86_64 # 1 SMP Чт 19 июня 21:14:45 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux

Спасибо за помощь.


openssl centos6 apache2.4 mod-ssl mod-spdy
person Andre Luis de Andrade    schedule 21.03.2015    source источник
comment
Этот вопрос кажется не по теме, потому что он не о программировании или разработке. См. Какие темы можно задать здесь в Справочном центре. Возможно, суперпользователь, обмен стеками веб-приложений, Обмен стеками для веб-мастеров или Обмен стеками Unix и Linux было бы лучше спросить.   -  person jww    schedule 23.03.2015
comment
Также см. Сделайте ChaCha: повышение производительности мобильных устройств с помощью криптографии за патч. Согласно ускорение и усиление HTTPS-соединений для Chrome на Android, наборы шифров в 2–4 раза быстрее, чем AES / GCM. К сожалению, его все еще недоступен в OpenSSL (см. ChaCha20 / Poly1305 в OpenSSL?).   -  person jww    schedule 23.03.2015
comment
@jww: поскольку проблема с производительностью возникает во время установления связи SSL, не имеет большого значения, какой симметричный шифр выбран.   -  person Steffen Ullrich    schedule 23.03.2015
comment
@Steffen - согласен с тем, что согласование / обмен ключами обычно является проблемой. Но мне не ясно, что является преобладающим среди [предполагаемых] проблем с производительностью, поскольку в этом вопросе мало деталей. Он также мог запустить 64-битную машину и настроить OpenSSL с enable-ec_nistp_64_gcc_128, потому что он в 2–4 раза быстрее для EC. Ему также следует ограничить свой список шифров, вызывая SSL_CTX_set_cipher_list (это может сэкономить дополнительный сегмент TCP в ClientHello). Он также мог обеспечить высокопроизводительные шифры на сервере, вызвав SSL_CTX_set_cipher_list только с EC ....   -  person jww    schedule 23.03.2015
comment
@jww: см. мой ответ, в чем проблема, на мой взгляд: (бесполезно) слишком большая цепочка сертификатов, вызывающая плохое взаимодействие с Медленный запуск TCP.   -  person Steffen Ullrich    schedule 23.03.2015

Ответы (1)


arrow_upward
4
arrow_downward

Первоначальное подключение: 170 мс

Согласование SSL: 531 мс

Глядя на захват пакетов, я вижу, что после первоначального установления связи TCP клиент запускает рукопожатие, и затем серверу требуется много времени, чтобы отправить обратно все необходимые данные (ServerHello, Certificates ...). Для этих данных требуется 5 пакетов, и из-за различных настроек TCP и ОС последний пакет будет отправлен только после того, как он получит подтверждения для предыдущих пакетов. В деталях, эта магия TCP, вероятно, может заключаться в медленном запуске TCP с фиксированными начальными окнами перегрузки, равными 4, с версией CentOS, которую вы используете (см. https://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-start/ ).

Что поделаешь: исправить цепочку сертификатов. Если вы посмотрите на отчет SSLLabs, вы увидите Проблемы с цепочкой: содержит привязку, что означает, что вы отправляете корневой сертификат, даже если корневой сертификат будет игнорироваться клиентом, и вместо этого используется доверенный ЦС, встроенный в клиент (цепочка доверия должна быть построена на основе локального доверия!). Если вы исправите конфигурацию, удалив этот корневой сертификат, данные, отправленные сервером, будут короче, и вы не столкнетесь с проблемой медленного запуска.

person Steffen Ullrich    schedule 22.03.2015