SSL медленный.Установление безопасного соединения занимает слишком много времени

Question

У меня есть выделенный сервер с 256GB RAM 6 CPUs (12 Threads) на Hetzner, и он расположен в Германии.У меня CENTOS 7.5 . EA4 .

Моя проблема с SSL.Каждый день в течение примерно 2 часов мы имеем 40 запросов в секунду , а выполнение запросов занимает около 20 секунд .Non-SSL занимает 0,5 или меньше. Здесь является примером.

С 13: 00 до 15:30 (UTC + 4) , запросы SSL занимают больше всего времени.Проблема очевидна, когда вы открываете эту ссылку с SSL и без.

У меня доступен WHM.Я заметил ModSecurity и задаюсь вопросом, может ли это быть проблемой.Я применил большинство предоставленных настроек здесь , но в отношении SSL не так много.

В случае, если сертификатыпричина всего этого:

Answer 1

Modsecurity может быть проблемой, если он занимает много ЦП и конкурирует с TLS (хотя вероятность невелика).

Ключ " Каждый день в течение около 2 часов мыиметь 40 запросов в секунду, и в этот момент завершение запросов иногда занимает около 20 секунд."В этот момент на этом сервере происходит что-то, что (вероятно) приводит к загрузке ЦП (поскольку создание HTTPS-соединения требует значительных ресурсов ЦП),Поэтому, пожалуйста, проверьте ваш сервер в тот момент, когда это произойдет.Это будет вашим узким местом в производительности.

Еще один момент - учтите, что, возможно, что-то происходит в сети от Pingdom до вашего сервера, так что сравните с curl, когда проблема происходит следующим образом:

x@517713:~$ curl -w "TC:%{time_connect} TST:%{time_starttransfer} TT:%{time_total}\n" https://blog.x.cf -D /dev/null -o /dev/null -s
TC:0.005 TST:0.336 TT:0.377

Это все варианты:

    time_namelookup:  %{time_namelookup}\n
       time_connect:  %{time_connect}\n
    time_appconnect:  %{time_appconnect}\n
   time_pretransfer:  %{time_pretransfer}\n
      time_redirect:  %{time_redirect}\n
 time_starttransfer:  %{time_starttransfer}\n
                    ----------\n
         time_total:  %{time_total}\n

Существует так много вариантов того, что может быть не так, что вы должны начать с определения места проблемы: Pingdom, Network, You server.

Как только это будет сделано, погрузитесь глубже.Допустим, ваш сервер плохо себя ведет: - проверьте журналы сервера - они должны иметь что-то в течение этого времени;- Рассмотрите возможность выключения modsecurity (который сильно загружает процессор);- включить кеширование на сервере;- Рассмотрим балансировку нагрузки между 2 серверами;- Возможно, диск работает медленно - проверьте это.

PS Решение, которое решает проблему на 100%, сложно, поскольку для этого не предоставлено много деталей.

Answer 2

Спасибо за ваши ответы, ребята.

В конце концов, это был не OCSP.Там были некоторые проблемы с сертификатами и некоторые настройки Apache.Мы наняли серверного парня, и он исправил это.

Поэтому, если у кого-то есть такая проблема, следует проверить конфигурацию сервера и найти способы ее оптимизации, а также проверить наличие сертификатов.Это фиксировало 3-4 секунды времени ожидания для каждого ответа.

Более серьезной проблемой было использование geoplugin для определения страны / города по IP-адресу.Я не знал, что Керл может замедлить время отклика так низко.Я не виню geoplugin конечно.Когда я профилировал свой Код, он сказал 127 миллисекунд от начала до конца, но оказалось, что профилировщик просто пропустил время ожидания этого геоглубина или что-то в этом роде.

В заключение, изменение Кодекса, касающееся сертификатов и конфигурации сервера, сделало это возможным.

PS Я не знаю, как справиться с этой наградой.Я не хочу, чтобы это пропало даром, поэтому я передам его кому-то, кто ответил, даже если ответ не решил мою проблему, и на вопрос был дан ответ за день до истечения срока действия награды, и проблема уже была решена.

Answer 3

Пока я не могу воспроизвести вашу проблему. Отчеты WebPageTest все хорошие и симпатичные. Согласование SSL в течение ожидаемых 100-200 мс, учитывая, что у вас включено сшивание OCSP.В противном случае это заняло бы больше времени под IE.Достаточно сказать, что сначала HTTPS всегда медленнее, чем простой HTTP, вы не можете их реально сравнить.Все это заставляет меня думать, что ...

Одним из возможных виновников является упомянутое OCSP сшивание .Сшивание OCSP на вашем сервере время от времени приводит к тому, что ваш сервер связывается с вашим CA для получения подписанного ответа OCSP.В этой ситуации ваше CA может стать узким местом.Если он не может обеспечить ожидаемый ответ вовремя, ваше соединение также прерывается, и это произойдет именно тогда, когда вы его увидите: во время согласования SSL.

Вы можете проверить срок действия кэшированного ответа OCSP с помощью следующей команды:

openssl s_client -connect banners.analyticson.com:443 -status -servername banners.analyticson.com

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Produced At: Jun 17 21:47:34 2018 GMT
    Cert Status: good
    This Update: Jun 17 21:47:34 2018 GMT
    Next Update: Jun 24 21:47:34 2018 GMT

В настоящее время сообщается, что ответ OCSP действителен до 24 июня 21:47:34По крайней мере, 2018 по Гринвичу, , но Apache настроен на их истечение по умолчанию .В частности, после всего лишь одного часа.Вы должны попытаться увеличить это время до более значимого значения, например, до недели:

SSLStaplingStandardCacheTimeout 604800

Другой возможный совет - противоположный: попробуйте отключить сшивание OCSP на некоторое время.

Если это действительно поможет устранить проблему, то вам следует либо обратиться за помощью в свой ЦС, либо перейти на использование другого ЦС, о котором известно, что таких проблем нет (например, давайте зашифруем), или использовать другой веб-сервер, который может обрабатывать сшивания OCSP.асинхронно и кэшируйте их в течение более длительного времени (например, nginx).

Дальнейшие исследования показывают, что Apache можно заставить работать с медленными или ненадежными OCSP-респондентами , хотя я не уверен, что эти обходные путипринесет пользу в вашем случае.