Я видел в посте что завершение SSL на уровне Cloudflare и трафик только HTTP от Cloudflare до источника дает повышение производительности, поскольку SSL согласовывается только на границе.
Я запускаю веб-сайт (в основном статический), где безопасность не вызывает параноидальных опасений.
Стоит ли отключать мой сертификат letsencrypt, чтобы использовать предоставленный Cloudflare «гибкий сертификат», чтобы избежать дорогостоящих обходов между краем и источником?
Редактировать:
Меня беспокоит не столько процессор (исходная машина). Это больше о том, могу ли я ускориться от края до начала.
Cloudflare предлагает не только завершение SSL, но и HTTP / 2, работающий в сочетании с SSL. Это то, что обеспечивает ускорение, особенно если вы можете кэшировать большую часть контента сайта (статические файлы, файлы изображений и т. Д.). Я несколько удивлен, что другие комментаторы здесь даже не упомянули HTTP / 2, поскольку он вносит различные улучшения в протокол HTTP.
Поэтому я бы сказал, что - если вы можете обновить свой веб-сервер для поддержки HTTPS + HTTP / 2 (последние версии Nginx поддерживают, я думаю, что Apache может справиться с соответствующим надстройкой модуля), это на самом деле будет основным улучшением, которое будет помощь любому ускориться. Если вы не можете поддерживать HTTP / 2, следующим вариантом будет завершение SSL-соединения Cloudflare с их поддержкой HTTP / 2. И если вы хотите / можете бежать обе, это Cloudflare HTTPS + HTTP / 2 termination и HTTPS + HTTP / 2 между ними и вашим источником, сайт будет чрезвычайно быстрый и отзывчивый. Я сам заметил это после переключения одного из моих сайтов на весь конвейер HTTPS + HTTP / 2, и он заметно быстрее загружается, в первую очередь из-за улучшений, которые HTTP / 2 вносит в таблицу.
Несомненно, есть улучшения в согласовании TLS, если его согласовать ближе к пользователю. Согласование TLS по-прежнему представляет собой набор пакетов, которые происходят до того, как будет отправлен первый байт фактических данных, поэтому его приближение к пользователю ускоряет установление сеанса. Это просто базовая скорость света - чем меньше физическое расстояние должны пройти пакеты, при прочих равных, тем быстрее они будут.
Вопрос в том, действительно ли это важно? Вам должно быть все равно? В случае Stack Overflow мы устанавливаем тысячи пользовательских TLS-подключений в минуту, поэтому, когда вы складываете миллионы TLS-сеансов за 24 часа, на счету каждая миллисекунда.
Однако, если вы получаете всего несколько обращений в час, вы не получите огромного кумулятивного выигрыша для установления сеанса, если переместите SSL на ваш CDN.
Что касается подключений из CDN обратно к источнику, CloudFlare должен использовать те же несколько сеансов (от каждого PoP), чтобы он не устанавливался повторно от имени клиентов. У CloudFlare раньше (может быть, они все еще есть?) Есть ускоритель WAN под названием "Рейлган", что делает завершение TLS в CDN еще более рискованным.
Однако я бы дважды подумал, прежде чем отключить Lets Encrypt на вашем источнике. Вероятно, вы все еще хотите использовать шифрование между CloudFlare и вашим локальным веб-сервером. Это не повлияет на производительность, и, таким образом, вы по-прежнему останетесь без отслеживания от Cloudflare к своему источнику.
Если вы говорите на сетевом уровне, очевидно, что это не достойный выигрыш, как уже отмечалось в других комментариях.
Но в случае, когда ЦП является проблемой на исходном сервере, это может быть идеей, потому что SSL-реализация контента требует дополнительных затрат ЦП (скажем, около 20%). Но если у вас нет проблем с процессором в источнике, это не сильно сэкономит и, следовательно, не стоит того.
Учитывая, что вы говорите о статическом контенте, я не думаю, что имеет смысл снижать безопасность для случаев холодного кеширования только для удаления подтверждения SSL. Очевидно, у вас будут правильные заголовки для управления кешем, и вы некоторое время будете кэшировать этот контент.
Я бы также предостерегал от любой микрооптимизации, которая пытается уничтожить шифрование между краем и источником для динамического контента, чтобы удалить RTT или 2. Cloudflare уже может оптимизировать это довольно много и поддерживать соединение с источником в течение определенного периода времени. отключение SSL-рукопожатий, увеличение размера окна перегрузки и т. д.