Назад | Перейти на главную страницу

Долгое согласование TTFB / SSL при настройке HTTP / 2, apache и Nginx в качестве обратного прокси

Как и в заголовке, я частично осознаю очень длинный TTFB, вызванный согласованием SSL дольше одной секунды при настройке HTTP / 2, Apache и Nginx в качестве обратного прокси.

Какие могут быть установочные винты и наиболее вероятные причины этого? Вот пример.

пс: Найти аналогичный вопрос, но без конкретной рекомендации, где найти решение проблемы.

Я бы не сказал, что это действительно так долго, когда вы ограничиваете подключение к Fast-3G.

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

Кроме того, TLSv1.3 имеет некоторые улучшения производительности, поэтому он может завершить квитирование за 1 цикл туда и обратно (или даже за 0 в некоторых случаях). HTTP / 3, который должен выйти в этом году (или, возможно, в следующем), также основан на QUIC, а не на TCP, и имеет некоторые улучшения производительности настройки подключения.

Самый простой способ получить такого рода технологические улучшения - использовать CDN перед вашим сайтом для обработки пользовательского соединения, а затем они могут направлять запросы обратно на ваш сайт и кэшировать контент на своих пограничных узлах. Многие CDN уже поддерживают TLSv1.3, а некоторые даже поддерживают HTTP / 3. Они также, вероятно, будут базироваться рядом с вашими пользователями, поэтому время приема-передачи (RTT) будет короче, и они также обычно имеют высокооптимизированные сетевые стекы.

Возвращаясь к вашему сайту, я заметил одну вещь: вы используете сертификат расширенной проверки и для этого требуется проверка отзыва во всех браузерах (это первые два запроса, и они должны быть выполнены до того, как будет завершено рукопожатие на ваш сайт). Вот хороший пост об этом: https://nooshu.github.io/blog/2020/01/26/the-impact-of-ssl-certificate-revocation-on-web-performance/. Для сертификатов, не относящихся к EV, Chrome не выполняет проверку отзыва (и вместо этого полагается на загруженный список отозванных сертификатов, который периодически загружается), хотя я вижу, что вы тестировали с Firefox, и в настоящее время он всегда будет выполнять проверку отзыва для EV и не- EV. Сертификаты EV потеряли свою полезность, так как браузеры перестали выделять для них дополнительный зеленый цвет в строке URL, поэтому может быть лучше вернуться к стандартному сертификату DV или OV при следующем обновлении сертификата для повышения производительности в Chrome.

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

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