- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
подбросьте, плз, ссылочек на CNAME vs A в плане кеширования.
Все просто: CNAME не кешируются, а для записей которые кэшируются, некоторые провайдеры игнорируют TTL (с целью снижения нагоузки на свои NSы). Но также нужно помнить, что в соответствии с RFC, создавать CNAME для самого домена нельзя (можно только для субдоменов, но кого-то это останавливает?).
Все просто: CNAME не кешируются, а для записей которые кэшируются, некоторые провайдеры игнорируют TTL (с целью снижения нагоузки на свои NSы). Но также нужно помнить, что в соответствии с RFC, создавать CNAME для самого домена нельзя (можно только для субдоменов, но кого-то это останавливает?).
www.site.ru разве не субдомен к site.ru :)
www.site.ru разве не субдомен к site.ru :)
Субдомен, разумеется, а к чему вопрос?
Субдомен, разумеется, а к чему вопрос?
К тому, что можно создавать каноническое имя не обходя правила RFC
К тому, что можно создавать каноническое имя не обходя правила RFC
И в чем же тут "обход"?
Или с самого домена редирект на www предлагаете сделать, и снова получить единую точку отказа?
И в чем же тут "обход"?
Или с самого домена редирект на www предлагаете сделать, и снова получить единую точку отказа?
Эмм. И правда. Толку от этого ))
Домен направлен на Ір адрес к хостеру, но бывает хостер имеет тех проблемы, и собственно сайт перестает быть доступным.
Лучшее из решений это взять выделенный сервер и мониторить за ним самому с помощью соответствующего ПО, и решать все проблемы, когда они пояляются, оперативно.
размещение сайта на различных серверах, постоянно проверяя их доступность и переписывая DNS записи , это я считаю не рентабильно, ни один из популярных сайтов в интернете такого не использует.
перед тем, как строить что-то нужно четко понимать, как работает то, на чем основан строящийся проект.
ИМХО DNS должен быть один и стандартный, никаких переписываний и замен, это глупость - возлагать основную функцию всей затеи на ресурсы, которые от тебя не зависят (кто хочет - кэширует, кто хочет обновляет)..
DNS указывает на некий сервер, отслеживающий загрузку и доступность нескольких http серверов-зеркал с контентом. Возможно этот же сервер выполняет функцию зеркалирования (изменения на любом сервере подтягиваются на другие). В случае отказа 1 http сервера - на него перестают направляться посетители. Все попадают на ресурс, никто не теряется, но вырастает время пинга и скорость отдачи контента до момента, пока количество серверов не станет первоначальным.
Плюсы такой системы:
- Масштабируемость. Потребовались еще ресурсы - подкинул еще серверов. Не нужны сервера в таком количестве - отключил, сократил расходы или задействовал ресурсы для других целей.
- Простой и понятный алгоритм работы
- Система зависит только от владельца. Что построил, то и получил. Хочешь, отслеживай расположение - направляй на ближайший сервер и т.п. функционал полностью в твоих руках.
Лучшее из решений это взять выделенный сервер и мониторить за ним самому с помощью соответствующего ПО, и решать все проблемы, когда они пояляются, оперативно.
размещение сайта на различных серверах, постоянно проверяя их доступность и переписывая DNS записи , это я считаю не рентабильно, ни один из популярных сайтов в интернете такого не использует.
Ну-ну, например, Википедия, конечно же, непопулярный сайт (на Викимедии, кстати, даже геораспределение таким образом работает). А Гугл видимо на одном сервере без всякого резервирования работает.
---------- Добавлено 31.05.2013 в 11:31 ----------
никаких переписываний и замен
...
В случае отказа 1 http сервера - на него перестают направляться посетители.
Чем? Балансером? И снова получаем единую точку отказа (и не забываем, что баленсеры, тем более? те которые реально HA - не дешевое удовольствие).
Тогда уж лучше на уровне BGP резервировать.
Чем? Балансером? И снова получаем единую точку отказа (и не забываем, что баленсеры, тем более? те которые реально HA - не дешевое удовольствие).
Тогда уж лучше на уровне BGP резервировать.
ну расшифруйте, как работает BGP, что это такое для таких, как я тупых, если это оптимальный вариант.