как сократить время ssl веб-сайта

многие вещи влияют на время SSL, включая:

инфраструктура (это не повлияет только на SSL, но все сетевой трафик):

• стандартные сетевые проблемы (как далеко ваш сервер от клиента, как быстро сеть между ними... etc), поскольку рукопожатие SSL/TLS занимает несколько поездок туда и обратно. У вас мало контроля над ними, кроме изменения хостинг-провайдера и/или использования CDN. AWS, по моему опыту, быстро, и вы только просите улучшить SSL, а не Общее время доступа, поэтому, возможно, пропустите этот.
• время отклика сервера. Работает ли сервер на CPU, Ram или диске? Вы делитесь этим хостом? Опять же общая проблема, поэтому, возможно, пропустите это, но SSL / TLS действительно занимает некоторую вычислительную мощность, хотя с современными серверами это едва заметно в настоящее время.
• серверной ОС. Новее-лучше. Поэтому, например, если работает Red Hat Linux 4, ожидайте, что он будет значительно медленнее, чем последний Red Hat Linux 7, с улучшенный сетевой стек и более новые версии ключевых программ, таких как OpenSSL.

настройка SSL (Запустите свой сайт через https://www.ssllabs.com/ssltest и вы должны получить состояние здоровья этого):

• шифры использовать. Есть более старые и более медленные шифры, более быстрые и новые. Может усложняться здесь очень быстро, но обычно вы должны искать шифры ECDHE для большинства клиентов (и предпочтительнее ECDHE...GCM ones) и хотите указать этот порядок сервера должен использоваться, чтобы вы могли выбрать используемый шифр, а не клиент.
• сертификат. Вы хотите ОГА 2048 экзамен. Все остальное слишком медленно. Некоторые сайты (и некоторые инструменты сканирования) выбирают сертификаты RSA 4096, но они оказывают заметное влияние на скорость без реального повышения безопасности (в настоящее время - это может измениться). Есть новые сертификаты ECDSA (обычно показанные как сертификат 256 EC в отчете ssllabs), но эти более быстрые сертификаты ECDSA не поставляются все CAs и не поддерживаются всеми клиентами, поэтому посетители старого оборудования и программного обеспечения могут не иметь возможности подключиться к ним. Apache (и совсем недавно Nginx от v 1.11.0) поддерживает двойные сертификаты, чтобы иметь лучшее из обоих миров, но за счет наличия двух сертификатов и некоторой сложности их настройки.
• Цепочки Сертификатов. Вам понадобится короткая цепочка сертификатов (ideal 3 cert long: ваш сервер, посредник и корневой сертификат CAs). Ваш сервер должен вернуть все, кроме последнего сертификата (который уже находится в хранилище сертификатов браузеров). Если какая-либо из цепочек отсутствует, некоторые браузеры попытаются посмотреть задумчивые, но это займет время.
• надежный поставщик сертификата. Помимо более коротких цепочек сертификатов, лучших ответчиков OCSP, их посредники также обычно кэшируются в браузерах пользователей, поскольку они могут использоваться другими сайтами.
• OCSP сшивание сохраняет сетевую поездку, чтобы проверить сертификат действителен, используя OCSP или CRL. Включение его не будет иметь значения для Chrome, поскольку они не проверяют отзыв (в основном, но сертификаты EV проверяются). Это может иметь заметное значение для IE, поэтому его следует включить, если ваш сервер поддерживает их, но знает о некоторых вопросы реализации - особенно первый запрос nginx после перезагрузки всегда терпит неудачу, когда OCSP сшивание включено.
• в протоколе TLSv1.2 следует использовать и, возможно, в протоколе TLSv1 .0 для старых клиентов, но без SSLv2 и SSLv3. В протоколе TLSv1.1 это вид бессмысленный (почти все, кто поддерживает, что также поддерживает более новые и лучшие TLSv1.2). TLSv1.3 в настоящее время разрабатывается и имеет некоторые хорошие улучшения производительности, но еще не полностью стандартизирован, поскольку есть некоторые известные проблемы совместимости. Надеюсь, они будут разрешены в ближайшее время, чтобы его можно было использовать. Примечание. соответствие PCI (при приеме кредитных карт на вашем сайте) требует TLSv1.2 или выше на новых сайтах и на всех сайтах до 30 июня 2018 года.

повторить посещения - в то время как выше поможет с первоначальным подключением, большинство сайтов требуют несколько ресурсов для загрузки и с плохой настройкой может пройти через все рукопожатие каждый раз (это должно быть очевидно, если вы видите повторные настройки SSL-соединения для каждого запроса при запуске таких вещей, как webpagetest.org):

• HTTP Keep-Alives должен быть включен, чтобы соединение не удалялось после каждого HTTP-запроса (это должно быть по умолчанию для HTTP / 1.1 реализации.)
• кэширование SSL и билеты должны быть на мой взгляд. Некоторые не согласны для некоторые неясные причины безопасности, которые должны быть исправлены в TLSv1.3 но по соображениям производительности они должны быть включены. Сайты с высокочувствительной информацией могут выбрать более полную безопасность по сравнению с производительностью, но, на мой взгляд, проблемы безопасности довольно сложны для использования, и прирост производительности заметен.
• HTTP / 2 следует учитывать, так как он открывается только одно соединение (и, следовательно, только одна настройка SSL/TLS) и имеет другие улучшения производительности.

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

Я веду личный блог, объясняя некоторые из этих концепций более подробно, если это помогает: https://www.tunetheweb.com/security/https/