Безусловно, такое бывает.
Но у столь глобальной и фаталистичной формулировки этой проблемы очень почтенный возраст.
Раньше подобных "исключений" было на порядки больше. А сейчас ситуация вполне хорошая и продолжает улучшаться:
1. Меньше потребности в экономии ресурсов.
Никто не держится осознанно за нелепые "принудительные" настройки.
2. Снижается распространённость старого некорректного софта и сопутствующего наследства настроек.
Это постоянный процесс везде, но в сфере ДНС популярность DDOS-атак через резолверы в ряде случаев мотивировала и тех, кто очень хотел ничего не менять.
3. Даже в этой консервативной сфере были не очень известные, но очень полезные технологические новшества.
В частности, EDNS-CLIENT-SUBNET (ECS) расширение появилось только 6 лет назад.
И, например, любимые многими Google DNS всего 3 года как дошли до его совсем полноценной поддержки.
А с ECS кеширование идёт с разделением по подсетям.
Поэтому посетители сайтов со средней посещаемостью - вообще очень редко попадают в какой-либо кеш, кроме собственного.
Т.е. новые посетители перенаправляются даже не с TTL, а с нулевой задержкой.
Проблема же с игнорированием TTL - всё же есть. Это не идеал.
Но на практике речь не о "массе", а об очень незначительной части аудитории (преимущественно, региональной).
Не о неделях задержек, а, в большинстве, о минимумах в 5-20 минут TTL у этой незначительной части аудитории.
Более серьёзные проблемы - у совсем исчезающе малого количества.
Да из него большинство роботы (не ПС) и мобильные.---------- Добавлено 05.07.2017 в 09:55 ----------
Это действительно простой и рабочий метод, если есть технические возможности у самого сайта. Но исключительно для дополнительной "полировки" стандартного ДНС-способа.
На деле и требуется, чтобы нерабочий адрес совсем не откликался, и браузер достаточно долго ждёт (ХХ секунд) перед новой попыткой.
Первейший вопрос в том, точно ли вам нужно именно это и насколько критичны задержки в синхронизации.
1. Сайт стандартного типа и размера; данные приемлемы с многодневной давностью; и при проблемах достаточен доступ только на чтение?
Делать не нужно вообще ничего.
Вам уже подсказали вариант с AlwaysOnline.
Из основных минусов:
- "снимок" может оказаться недельной давности;
- будет содержать далеко не всё (если сайт больше стандартной визитки);
- рассказывает посетителям о проблемах сайта, когда полезнее промолчать;
- может не сработать при некоторых ошибках (например, при проблемах БД).
Сходный модуль WSR сочетает "архивный снимок" с всегда свежим дополняющим "рабочим кешем" и интегрирован с гибко настраиваемым мониторингом, который принимает решения при подтверждении из 3 разных ДЦ.
2. Нужен работающий функционал и\или повышенная, но всё же не очень критичная актуальность данных уровня 6-24ч?
Берёте уже описанные здесь методы по самостоятельному построению ДНС-отказоустойчивости и мониторинга.
Добавляете простой, неэффективный, но более чем достаточный баш-скрипт:
- rsync для файлов, не забыв исключить кеши WP;
- бэкап+рестор для БД.
Можно аккуратнее, но это сложнее, а при таких объёмах полная обработка БД не проблема. С удалённым доступом к БД всё реализуется со стороны одного из серверов и правда очень лаконично. Ну разве что, кроме контроля успешности.
Либо с несколько более интересной надёжностью и трудоёмкостью:
- Настраиваете ресторы по расписанию в бэкап-модуле WSR.
- А в CDN указываете резервный сервер, и, вместо использования "снимка", запросы будут перекидываться на него.
А если и он умрёт, то тогда уже "снимок".
3. Актуальность критична на уровне секунд\минут?
Тут уж точно репликация БД, что достаточно просто для такого случая.
Для файлов аналогичным уровнем была бы, например, GlusterFS.
Но в отличие от БД столь частые и действительно нужные изменения на уровне файлов бывают редко у большинства проектов.
И, скорее всего, реальным требованием будет вполне соответствовать куда более простое решение - тот же rsync, только с небольшими поправками в характере применения.
- Сравнительно редкая общая синхронизация.
- Очень частый или событийный запуск для папок с часто меняющимися файлами (вероятно, только картинки).
А в остальном тоже самое.
Наблюдаем немалое количество клиентов, переходящих на HTTPS "прямо оптом".
Данных по индексации, к сожалению, не имеем. Но поскольку вопросы о последствиях и правильности перехода встречаются ежедневно, собрали у практиков ряд эмпирических, но действительно актуальных мнений:
1. В срезе Яндекса - важна HTTP+HTTPS доступность для robots.txt первое время.
Обоснование: нередко Яндекс.Вебмастер после смены протокола временно сообщает о недоступности Роботса. А и директиву Host желательно, чтобы читал; и даже временное попадание лишних страниц в индекс может быть ущербом.
2. Немного более «гладко» проходит переезд, при котором сайт оставляют временно доступным одновременно по обоим протоколам. Около недели с момента того, как настроили HTTPS и указали его в личных кабинетах у поисковиков и в robots (обязательно, везде).
Обоснование: пока своей очереди ждёт считывание настроек и обход роботами HTTPS-версии, старая HTTP-версия в поиске менялась бы чуть менее оперативно, чем в случае редиректов.
3. Самые осторожные вебмастера, имеющие сайты, для которых нет жесткой необходимости (некоммерческие и без взаимодействия с личными данными), пользуются очень удачной политикой «переходить на HTTPS сразу в момент появления любых SEO-проблем».
Обоснование: это не только минимизация пусть и небольших, но возможных потерь, а ещё и некоторый шанс ускорить переиндексацию и восстановление от негатива.
4. И в завершении простой факт, есть очень распространённая ошибка – «смешанный контент». В базе страниц и форумных постов бывает множество картинок, в том числе и со сторонних сайтов, такое иногда непросто не только исправить, но и найти. А это нарушение требований HTTPS.
Для Вордпресса это исправляется, например, с «SSL Insecure Content Fixer». Для многих CMS есть аналоги. Но не для всех, да это в любом случае небольшой лишний ущерб производительности. Специально из-за такой ситуации сейчас запускаем модуль, который проводит смену напрямую в любых файлах и БД.
Жаль, что нет возможности посмотреть на сайт. Пока действительно значимого негатива про смену протокола на практике не встречали в случаях, при которых выполнялись хотя бы базовые правила перехода.
По возможным причинам.
- Действительно, есть множество неизвестных алгоритмов ПС, с которыми ничего не гарантировать и переживать стоит за любое большое действие.
- Но есть и общая положительная статистика. И точно объективный фактор, который может влиять. И который концептуально отличает «просто HTTPS» от описанных нами случаев.
--- С HTTPS сайт медленнее везде, а особенно ощутимо это для отдалённых от хостинга регионов.
1. Если хостинг в Санкт-Петербурге, то где-нибудь во Владивостоке ваш сайт стал медленнее на 0.5сек, а в США на 0.8сек.
И это для пользователей с хорошими каналами. И в условиях, если у вас не перегруженный сервер.
-> комфорт посетителей снизился -> ПФ ухудшились -> поисковикам не нравится
2. Робот Гугла проверил сайт – тоже ухудшение засчиталось (особенно, если вдруг не из российского ДЦ обратился, что бывает).
* см. исследование MOZ про связь позиций с Time to First Byte в Гугле
3. На сайте много страниц – ситуация не обязана возвращаться к первоначальной, пока не обойдёт все и соответствующим образом не пересчитает характеристики по перелинковке и прочему. Причём обход нередко может потребоваться не однократный.
А чем медленнее сам сайт, тем меньше и скорость индексации.
Если ваша проблема вдруг окажется связана исключительно с №3, то всё ещё наладится и само по себе.
Не имея статистики по хостингам не могу поручиться, но не думаю, что все хостинги поголовно используют DNS-CAA-метод.
Как минимум, точно никто не заставляет его использовать при самостоятельной реализации на своём сервере.
Нам изначально показался более надёжным метод с подтверждением сертификатов с помощью проверочных файлов, вместо DNS (файлы, разумеется, "виртуально" генерируются на уровне CDN, а не грузятся на сайты).
Проблем с ним не встречалось в принципе. Даже, когда у LetsEncrypt было ещё немало багов.
Рекомендуем.
HTTP/2 это, безусловно, хорошо. Но, к сожалению, даже, если не учитывать текущую распространённость, не настолько, чтобы быть хоть сколько-то ощутимо большинством сайтов, да, тем более, значимо компенсировать HTTPS.
Не просто так сейчас HTTP/2 не поддерживают даже Яндекс, Amazon, Ebay.
Он действительно улучшает ситуацию с повторными хэндшейками, но
- и самый первый хэндшэйк не исчезает (а скорость загрузки на первом просмотре - наиболее значима в срезе шансов получения "отказа" от посетителя)
- и для некоторых сайтов, если не оптимизировать персонально под особенности HTTP/2 иногда даже возможны случаи небольшого замедления начала загрузки
На офблоге Nginx есть хорошая статья по теме, а вот здесь можете протестировать в сравнении результаты HTTP 1\2 для реальных сайтов.
К примеру, facebook имеет ощутимое ускорение, а miniclip.com как и большинство средних сайтов отличий с HTTP/2 фактически не имеет
LetsEncrypt сам создаётся при поддержке не просто множества крупнейших компаний, а в том числе и непосредственно владельцев 80% браузерного рынка в лице Гугл-Хрома и Мозиллы.
И он на практике вообще никак не отличается от платных сертификатов. Не считая EV-разновидностей (со стоимостью порядка 12т.р.\год).---------- Добавлено 03.07.2017 в 18:59 ----------
Множество хостингов сейчас выдают LE-сертификаты в пару кликов и обеспечивают их продление.
И есть немало статей о реализации на своих серверах.
Но для большинства сайтов нет прикладного смысла этим заниматься в принципе.
Единственный реальный минус от подключения HTTPS это, - скорость.
Она замедляется на время установки соединения (SSL Handshake) + ещё немного дополнительно. Если хостинг в Москве, а посетитель в Хабаровске - handshake будет занимать около 0.5сек. С европейских хостингов - цифры могут быть побольше и значимы уже по всей территории РФ\СНГ.
А с CDN можно решить, одновременно, и эти проблемы, и совсем не заниматься самостоятельно вопросами сертификатов.
