nginx ssl оптимизация

Оптимизация в моем понятия - это улучшения процесса, что бы быстрее грузилось, меньше ресурсов было потрачено.

Ну и А++ получить, сеошники говорят что это помогает для сео сайта.

Всё, что вы говорите, это сводиться к: "Мне нехрена больше делать".

Быстрее грузится на сколько?! Замеры как проводить?

Ресурсов меньше каких? Как замеры проводиться будут?

SEO и https в техническом смысле вообще разные берега. Никакие A++ не ставят ваш сайт в топ. Возможно какие-то псевдосеошные отчёты и содержат какие-то там проверки https, но это из-за того, что людям писать больше чего, а отчёт хочется клиенту показать объёмный.

То-есть вы советуете не лезть и пусть все как есть работает?!

Понимаете, если бы вы хотели внедрить http/3 и его бы тестировали. Вот бы спрашивали как его запустить т.к. это РЕАЛЬНАЯ цель для которой нужен tsl 1.3 и без него http/3 не работает. 

Вот тут бы никаких вопросов, конечно это экспериментальная вещь, но она действительно даёт прирост скорости.

Больше ЯВНЫХ метрик, по которым можно было бы мерить какую-то оптимизацию я не вижу.

Хмм, а чем поможет  dnsmasq если он просто перенаправляет запросы на указанный днс.

Если указать днс гугла или cloudflare, или провайдеровский днс в конфиге  dnsmasq , то они также если упадут, запросу долго ждать ответа придется, или я ошибаюсь?

кэш. вся суть в кэшировании.

да, dnsmasq просто форвардит на те же 8.8.8.8 и 1.1.1.1, но при этом кэширует.

да, по времени там вроде разница мизер, но если помножить это на количество запросов, то получается уже заметно на глаз.

вот реальный пример. только что проверил:

видим что кэшированный запрос от локалхоста в 3 раза быстрее cloudflare и в 4 раза быстрее гугла.

ну это частный случай конкретно этого сервера. у других могут быть другие цифры.

днс сервера такие стоят:

т.е. первым локальный dnsmasq (который эту строку игнорирует при своей работе и обращается лишь к двум оставшимся)

и сейчас я делаю reload nginx'а с двумя сотнями сайтов за вот столько:

но как только в resolv.conf комментирую первую строчку с 127.0.0.1 и это же самое действие проходит уже за вот столько:

а когда подтупливали те внешние dns сервера все было еще сильно хуже и даже просто открывались https сайты с тормозами заметными на глаз.

стоило мне закомментировать ssl_stapling - все приходило в норму.

поставил dnsmasq - тоже порядок.

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

возможно многие такие моменты не замечают т.к. проблема проявляется лишь при большом числе сайтов. если их там 3-5 шт. то конечно без разницы.

согласен, что это больше плацебо и ни на что особо не влияет, можно смело оставлять по-умолчанию. но вопрос же был про "оптимизацию". собственно вот она и есть. добавляем/правим фичи, понимая какие будут последствия, плюсы/минусы.

переход обратно с https на http обычно никому и не нужен, потому и говорю - да, ставим заголовок HSTS.

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

 TLS 1.3 0-RTT (early_data) - и работает и "убыстряет" :)

А вот что насчет тикетов?

ssl_session_ticket_key current.key;
ssl_session_ticket_key prev.key;
ssl_session_ticket_key prevprev.key;

Как то мутно описано, толи это нужно для когда используется при балансировке трафика, толи я не понял.

Заметил что на бесплатном сертификате Let’s Encrypt не работает OCSP stapling = Yes.

Получаю OCSP response: no response sent и проверки сертификата OCSP stapling = No.

В конфиге виртуал хоста указываю. 

ssl_stapling on;
ssl_stapling_verify on;
resolver 127.0.1.1;
resolver_timeout 5s;

ssl_certificate /usr/local/etc/letsencrypt/live/site.ru/fullchain.pem;
ssl_certificate_key /usr/local/etc/letsencrypt/live/site.ru/privkey.pem;
ssl_trusted_certificate /usr/local/etc/letsencrypt/live/site.ru/chain.pem;

Приветствую. "Обновил" openssl  # openssl version OpenSSL 1.1.1g  21 Apr 2020, затем обновил nginx посредством yum, но nginx обновился со старым openssl - built with OpenSSL 1.0.1e-fips 11 Feb 2013  #nginx/1.19.0 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013, вручную собирать nginx или можно как то сделать так, что бы в будущем не заниматься ручной сборкой nginx?