- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как, очень надеюсь, всё таки успешно стало очевидным, - недостатки только в расширениях, и их несложно компенсировать небольшой админской работой.
Недавняя проблема с CAA записями в DNS - это чей недостаток? Зачем использовать технологию, которую не поддерживает большинство хостингов и регистраторов?
Хотя немного сложно представить проект, где сочетаются одновременно оба таких условия.
Это элементарно - для любого коммерческого проекта отваливание сертификата выливается в убытки, которые гораздо выше 15 баксов за три года. И дело тут в не в надежности сервиса, а в ограничении 90 дней. Покупая сертификат на 3 года я снижаю вероятность отказа в 12 раз.
Да и не все админами родились - придется либо тратить свое время, либо платить за работу по настройке. Вот вы за сколько готовы настроить автопродление LE с гарантией?
Недавняя проблема с CAA записями в DNS - это чей недостаток? Зачем использовать технологию, которую не поддерживает большинство хостингов и регистраторов?
Если детализировать, 99.99+% пользователей это не заметили. Потому что проблема в некоторых версиях резолверов, которые сами работали некорректно и вместо ответа ошибкой просто не подавали признаков жизни.
А так, конечно, LE мог бы получше проработать эту ситуацию и можете смело считать такое его недостатком.
Там вообще много недостатков.
Которые всё также не являются препятствием для 100% надёжности конечного результата.
Это элементарно - для любого коммерческого проекта отваливание сертификата выливается в убытки, которые гораздо выше 15 баксов за три года. И дело тут в не в надежности сервиса, а в ограничении 90 дней. Покупая сертификат на 3 года я снижаю вероятность отказа в 12 раз
А просто контролируя такой жизненно важный показатель, как сертификат, вероятность снижается не в 12 раз, а насколько это в принципе возможно.
Да и не все админами родились - придется либо тратить свое время, либо платить за работу по настройке.
Разумеется, самостоятельная реализация это - затраты.
Потому только что с вами полностью соглашались в том, что 15$-вариант может быть рациональным в некоторых случаях.
Но самое основное в виде контроля с уведомлениями - вполне тривиально, чтобы быть доступным любому коммерческому проекту или владельцу нескольких доменов.
В то же время, низковероятно, но всё же разрешение каких-то частных случаев изредка может продолжать увеличивать издержки.
Вот вы за сколько готовы настроить автопродление LE с гарантией?
Бесплатно. Правда, не на вашем сервере, что редко является объективной необходимостью.
Во множестве сервисов, включая и наш, и другие CDN, и множество хостингов - надёжно работающий Let's Encrypt является бонусом к основным возможностям.
Разумеется, самостоятельная реализация это - затраты.
Резюмируя - либо трать свое время, либо заплати другому, либо купи готовое.
Вернемся к вопросам производительности. Немного потестировал ssl на разных конфигурациях.
На DigitalOcean включение HTTPS весьма заметно. Хендшейк 80мс плюс время коннекта возрастает вдвое. Итого: HTTP 75мс, HTTPS 240мс до начала скачивания страницы.
На DigitalOcean включение HTTPS весьма заметно. Хендшейк 80мс плюс время коннекта возрастает вдвое. Итого: HTTP 75мс, HTTPS 240мс до начала скачивания страницы.
А какой тип ключа и какую длину ключа вы использовали? Разница между 2048 RSA и 4096 RSA очень заметна. Пробовали сертификат с ECDSA ключом? Он вроде как ещё в 2 раза быстрее чем RSA должен быть.
Использовали ли OCSP stapling? Можете показать конфигурации тестового стенда?
А какой тип ключа и какую длину ключа вы использовали? Разница между 2048 RSA и 4096 RSA очень заметна. Пробовали сертификат с ECDSA ключом? Он вроде как ещё в 2 раза быстрее чем RSA должен быть.
Использовали ли OCSP stapling? Можете показать конфигурации тестового стенда?
Сертификат Let's Encrypt, ключ RSA 2048, OCSP еще не пробовал.
Тестовый стенд DigitalOcean VPS за $10, Nginx+php_fpm.
Пробовал статические страницы и голый Wordpess - разницы нет.
Вернемся к вопросам производительности. Немного потестировал ssl на разных конфигурациях.
На DigitalOcean включение HTTPS весьма заметно. Хендшейк 80мс плюс время коннекта возрастает вдвое. Итого: HTTP 75мс, HTTPS 240мс до начала скачивания страницы.
Основной вопрос всегда просто в физическом расстоянии.
Протестировав ситуацию по РФ, увидите цифры и намного больше из многих регионов (например, попробуйте ping-admin.ru - он удобно показывает отдельно SSL-этап; host-tracker.com тоже хорошо подойдёт, но только для суммарного сравнения HTTP vs HTTPS)
Как ни оптимизируй, в любом случае из-за HTTPS появляются дополнительные пакеты, которые должны не раз пролететь весь путь от сервера до посетителя.
Это неустранимая и основная задержка.
Поэтому, если вся аудитория сайта сосредоточена в 1 городе, то можно разместить хостинг там. И, помимо улучшения общих скоростей, HTTPS тоже станет почти не заметен.
А во всех других случаях, т.е. при широкой географии аудитории, чисто технически нет решений, кроме CDN или создания собственной мультисерверной системы.
Возможные вторичные оптимизации вам уже очень хорошо рассказал Оптимизайка.
1. Действительно существенен OCSP stapling. Его несложно активировать в любом веб-сервере.
Он экономит лишнее обращение к центру сертификации на первом запросе.
Во многих крупных городах реальная выгода невелика и находится на уровне 20мс (поскольку у самого LE, как и у большинства других центров, это работает через Akamai).
По РФ\СНГ полноценно охвачены Москва, Санкт-Петербур и Киев, поэтому в других регионах выгода может быть намного значимее.
Также это даже потенциально повышает аптайм, поскольку убирает дополнительную "точку отказа" в лице OCSP серверов центра сертификации.
Но, в то же время, и добавляет другую "точку отказа" на уровне вашего сервера, если реализуете самостоятельно.
Поскольку, вы сами должны будете постоянно обновлять OCSP данные (они валидны на ~неделю).
И, как и с самим LE, нужно мониторить и обрабатывать сопутствующие проблемы. Иначе есть шансы начать отправлять истёкшие или некорректные данные, и в браузерах будут ошибки.
2. Производительность, связанная с ключами, имеет место, но на практике редко заметна.
Она касается CPU-затрат, поэтому значима, например, для маломощных телефонов.
3. При глубокой настройке SSL на уровне своего сервера поможет такой чекер
Безопасность тоже не на А-уровне без дополнительных настроек.
Включение OCSP stapling никакого эффекта не дало.
Как было SSL - 86мс, Connect - 160мс так и осталось.
Включение OCSP stapling на nginx для LE, может кому пригодится:
скачиваем сертификаты
cd /etc/ssl
wget -O - https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem | tee -a ca-certs.pem> /dev/null
в конфиг nginx добавляем
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ca-certs.pem;
проверяем https://www.ssllabs.com/ssltest/index.html
Protocol Details -> OCSP stapling Yes
http://ping-admin.ru/free_test/result/1499692232o3fo04xj3q6zc10zrk6f70.html
Ну занимает некоторое время ssl-соединение, но ИМХО не критично.
Кроме настройки OCSP stapling на сервере можно ещё и Header set Expect-Staple "max-age=31536000; includeSubDomains; preload" добавить в htaccess
Включение OCSP stapling никакого эффекта не дало.
Как было SSL - 86мс, Connect - 160мс так и осталось.
Вполне вероятно, что, то, чем тестируете, либо кеширует и не учитывает этот фактор при повторных тестах, либо находится прямо в ~1мс от одной из точек доступа CDN'а, который использует LE.
Это фактор, который точно полезен, но с основными времязатратами не связан.
http://ping-admin.ru/free_test/resul...10zrk6f70.html
Ну занимает некоторое время ssl-соединение, но ИМХО не критично.
Так у вас хостинг в Москве, и тесты вы сделали тоже из Москвы. Тут HTTPS и должен быть незаметным.
В дополнение к этому, ваш сайт сам по себе и лёгкий по контенту, и технически близок к возможному идеалу да работает быстрее абсолютного большинства существующих.
Поэтому ему, в целом, сложно помешать. Но всё же ваш проект предназначен для всего русскоязычного населения планеты )
Вполне вероятно, что, то, чем тестируете, либо кеширует и не учитывает этот фактор при повторных тестах, либо находится прямо в ~1мс от одной из точек доступа CDN'а, который использует LE.
Это фактор, который точно полезен, но с основными времязатратами не связан.
Ок. Пробую через Pingdom из разных локаций - Стокгольм, Мельбурн. Во всех случаях общее время увеличивается на 0.2 секунды по сравнению с HTTP.
Интересен и эффект от CDN, у Google и AddThis коннект моментальный, в пределах 30мс из любой локации, а вот у BootstrapCDN (они используют MaxCDN) время коннекта каждый раз хуже, чем у моего VPS.