Комментарии 55
Во-первых, выбирая CDN, вы получаете дополнительную точку задержки, ведь теперь система усложняется за счет подключения еще одного узла, а это влечет новые траты ресурсов и задержки.
Во-первых, браузер к одному домену может делать только примерно 8 параллельных запросов, остальные будут в очереди. Если у вас много мелких картинок, которые не склеены в одну большую по той или иной причине, они могут забить канал (например, много превьюшек продуктов), то CDN может помочь освободить канал для загрузки других данных .
Ну и ещё многие CDN оптимизируют изображения на лету, в том числе могут автоматом генерировать превьюшки. Да, это делается простыми плагинами для nginx, но опять же, это отъедает ресурсы, которые можно потратить с большей пользой.
Ну и для международных компаний может быть польза в том, что контент физически хранится ближе к пользователю, от чего меньшие задержки.
Но риски и точки отказа CDN добавляет, этого не отнять. Как и необходимость его хоть минимальной настройки
P.s. о каком именно старом мифе идёт речь в заголовке?
P.s. о каком именно старом мифе идёт речь в заголовке?
о том, что без кликбейта жизнь не мила
Во-первых, браузер к одному домену может делать только примерно 8 параллельных запросов, остальные будут в очереди.Это справедливо только для http/1.1. В http/2, которые уже ну практически везде, соединение ровно одно и запросы различных ресурсов сайта не требуют создания отдельных соединений.
imagekit.io/demo/http2-vs-http1
Стоп, я спрашивал про кейс "один сервер с хттп/2 vs два сервера с хттп/2"
Так что не понятно что именно вы хотите мерять. В http/1.1 бутылочное горлышко на стороне клиента. http/2 его устраняет. Может ли http/2 сервер в одиночку раздать статику и динамику как два отдельных сервера на статики и динамику? Дам, может*|**.
* Если узким местом не станет канал от сервера до клиента.
** Если узким местом не станет дисковая подсистема.
Существование балансировки нагрузки намекает, что при достаточно большой нагрузке любой сервер перестанет вытягивать.
Уж извините, что как кэп отвечаю, но какой вопрос, такой ответ.
Вариант сервер/канал перегружен запросами/трафиком нет смысла рассматривать, мы же другую метрику измеряем.
Я не мерял, но косвенно это подтверждается многочисленными профилями загрузки ресурсов через http/2, которые находятся в интернете, где видно, что начало загрузки статики для браузера выглядит одновременным.
Т.е. для одного соединения:
1. Скачиваем html.
2. Парсим.
3. Запрашиваем статику.
4. Качаем всю одновременно.
Для двух:
1. Скачиваем html.
2. Парсим.
3. Запрашиваем статику.
4. dns-запрос на ip второго сервера.
5. Установилось tcp со вторым сервером.
6. tls.
7. Качаем всю одновременно.
Теоретически на одном соединению вы можете даже попробовать обогнать два соединения. Пока браузер клиента парсит html и вычленяет оттуда url ресурсов, вы можете запушить часть из них по инициативе сервера.
Если эти два сервера физически один (виртуальные хосты, ВМ, контейнеры и т. п.), то особой разницы не заметите, один быстрее, но на уровне погрешности — сутками не гонял
Если у вас много мелких картинок, которые не склеены в одну большую по той или иной причине, они могут забить канал (например, много превьюшек продуктов), то CDN может помочь освободить канал для загрузки других данных
http2? нативный @lazyloading? не решают эту проблему?
Ну и для международных компаний может быть польза в том, что контент физически хранится ближе к пользователю, от чего меньшие задерж
Единственный плюс, пинги из США от 300мс и выше на каждый ресурс.
А как HTTP2 помогает с картинками? Честно, не знаю, но очень интересно. Вот только на прошлой неделе занимался производительностью страниц и в том числе картинками.
По памяти:
1) один хендшейк
2) мультиплексирование соединения, асинхронность ответов
3) сжатие заголовков
Извините, что вторгаюсь в вашу дискуссию. Но есть вопрос (праздное любопытство) — а кто-нибудь сравнивал HTTPS 2+ с HTTP 1+? Да, я имею ввиду https:// 2-й версии vs http:// 1-й. Т.е. для 1-й версии без TLS. Старый протокол не пожимает заголовки, сложности с количеством одновременных запросов… Это понятно. Но у TLS версии есть накладные расходы на шифрование. Что в итоге превалирует? Разница только в скорости "старта", а затем HTTPS 2 уже не проигрывает ни в чём?
P.S. я понимаю, что сравниваю "мягкое" и "тёплое"
P.S.S. я тоже за HTTPS everywhere, просто интересно
Кстати, есть плагин для FF под названием HTTPS everywhere, он запрещает загрузку ассетов по HTTP как раз для приватности. Может и для Хрома есть такой же.
Большое спасибо, пойду читать!
Что мешает сделать несколько поддоменов, чтобы одновременно было примерно 8*количество поддоменов соединений?
Это уже не так с приходом http 2
Всё перенёс на локальный сервер. Патамучто:
1) Если наш сервер работает, то и статика работает. Отдадут статику.
2) СDN падают постоянно. Было прекручено Sentry, я видел как они падают постоянно.
Вывод для себя сделал — всё хранить на своём сервере.
Во-первых, браузер к одному домену может делать только примерно 8 параллельных запросов, остальные будут в очереди. Если у вас много мелких картинок, которые не склеены в одну большую по той или иной причине, они могут забить канал (например, много превьюшек продуктов), то CDN может помочь освободить канал для загрузки других данных .
Типично CDN — предоставляет конкретному пользователю один свой конкретный сервер, пусть даже в сети CDN серверов тысяча.
Ну будет у вас вместо 8 потоков этих потоков 16. Вы что же скажите, что разработчик криворукий не сможет эти потоки перенагрузить? Смог 8, и сможет 16.
Правильная оптимизация ваших HTML/CSS/JS даст лучший эффект.
Ну и ещё многие CDN оптимизируют изображения на лету, в том числе могут автоматом генерировать превьюшки. Да, это делается простыми плагинами для nginx, но опять же, это отъедает ресурсы, которые можно потратить с большей пользой.
Это вообще для кого? Для совсем неграмотных? Для совсем ленивых?
Сжатие/превьюшки реализуется в современных веб-системах с полпинка.
Где-то нужно всего то галку включить, где то десяток строк кода написать. И — вуаля — после первого получения пользователем картинки она уже сжата и в дальнейшем отдается из подготовленной превьюшки/из предварительно сжатых закэшированных, не отнимая ресурсов.
Причем, что важно, что эти превьюшки и закэшированные сжатые картинки вы контролируйте сами. Обновилась картинка оригинала — и обновление кэша/превьюшки будет мгновенным.
Ну и для международных компаний может быть польза в том, что контент физически хранится ближе к пользователю, от чего меньшие задержки.
А какой смысл быстро отдавать картинки, если сам ваш сайт при этом тормозит у удаленного пользователя.
То о чем вы пишете имеет смысл только для тяжелого контента.
Если вы специализируетесь на видеохостинге — тогда да, безусловно, CDN нужен.
А какой смысл быстро отдавать картинки, если сам ваш сайт при этом тормозит у удаленного пользователя.
Тормоза складываются, разница между 900 мс (300 мс пинг для html + 300 мс сервер думает для html + 300 мс пинг для статики) и 602 мс (пинга для статики 2мс) заметна пользователю и влияет на конверсию
Аналогично, forms.gle уже пару месяцев не работает. При этом, хоть из под мобильного мегафона всё работает и выдаётся другой ip, они оба заблокированы по одним и тем же 3 разным решениям 3 разных судов.
<///>
<///>
<///>
Прошу прощения за оффтоп, просто накипело.
Сам сайт можно спрятать за cdn, и ддос не так зацепит и уязвимости сложнее будет эксплуатировать. Надо только не пропалить родной ИП отправляя почту и так далее. А мощный ддос напрямую на сервак размещенный в ДЦ ни одному ДЦ не понравится, или отключат или заставят заплатить или вообще попросят на выход.
С расстояниями интересно. Несмотря на 2020. В каком-нибудь кукуйске до москвы трасса может идти через австралию. Поэтому cdn находящийся в сша может быть быстрее.
Йотуб упоминающийся в статья по большому счету является подвидом cdn. Как и всякие другие сторонние ресурсы для размещения информации.
При грамотной настройке — даже если упадет основной сайт, CDN может помочь сделать это менее заметным. И перекинуть на новую локацию проще (не ждать пока днс обновятся). И закэшированную статику показывать может пока всё не восстановится. Отказоустойчивость в определённом смысле лучше будет.
Поэтому на самом деле на определённом этапе развития сайта cdn фактически обязательный этап. Просто надо понимать, что это тоже инструмент с которым тоже надо работать, а не так что зашел в интерфейс — две кнопки нажал и вуаля.
Версию в имя файла — и даже через CDN весь контроль у вас в руках
+1, версию в имя или в параметр после имени вроде https://example.com/css/main.css?asdfasdf. Лучше не версию, а хеш-сумму файла и автоматически. И тогда можно выставлять бесконечный TTL кеширования. Подробности гуглятся по слову "cachebusting"
CDN как таковой, без допцслуг типа антидос и т. п. может иметь мало смысла только если клиенты рядо, по меркам сети, с сервером. Если узлы CDN ближе чем сервер, то он ускорит загрузку статики для клиентов. В последний, когда оценивал летом, ускорение на порядок было на https 1.1 за счёт пинга 1-2 мс к ноде CDN, на площадке, куда мой провайдер подключён, против 29-31 мс к ДЦ амазона и гугла во Франкфурте. Ну и скорость загрузки в мегабитах повыше — CDN мог упереться в 400 мбит/с вайфая, а Франкфурт нет
В статье путают сетевую связность и географическое расстояние (не мудрено, тк маркетологи CDN часто тоже подменяют эти понятия). Обычное дело когда пинги от пользователя в городе А до сервера в городе А больше чем пинги до сервера в городе Б. Хороший CDN следит за хорошей сетевой связностью своих серверов и взаимодействует с провайдерами (нередко ставит сервера в их инфраструктуре), чтобы исправить проблемы.
Теоритически вы тоже можете с ними договориться, на практике только при очень большом трафике (у CDN он есть, тк клиентов у него много).
Достаточно посмотреть на долю статики в современных сайтах и станет понятно, что CDN нужен для практически любого популярного сайта. Сайту школы с полтора пользователями в день он конечно не нужен.
Практически весь смысл коммерческих CDN исходит из двух пунктов:
- Специализация на доставке
- Коллективное использование
Вы конечно можете взять вашу географию пользователей, запросить сотни виртуалок в разных ДЦ, промерить метрики до ваших клиентов, выбрать оптимальные (конечно придется посчитать), разместить там оптимальное оборудование с оптимальным софтом, через неделю повторить. В лучшем случае у вас будет несколько отделов которые будут заниматься только тем что вы делаете свой CDN и при этом все равно ваш CDN (при наличии высококлассных специалистов съевших собаку в этом деле) будет менее эффективен, тк ваши расходы делятся только на вас, а не на всех клиентов CDN. И конечно каждое решение вам придется разрабатывать заново (а не получить бесплатно для клиента Б потому что это уже делалось для клиента А).
Вопреки расхожему мнению традиционный CDN от DDoS'а не защищает. Но большинство крупных CDN предоставляют защиту как доп.плюшку.
Выбрать CDN вы можете и сами (без rapidweb.me), большинство предоставляют тестовый период, выберите несколько CDN из вашего региона (часто на сайтах CDN особенно подчеркивается география), соберите метрики, прикиньте кто лучше и насколько оно вам вообще нужно.
А почему именно Google? Что CDN эту информацию получает, это понятно.
Ну и, кстати, эти же блокировщики допускают загрузку с CDN'ов популярных библиотек вроде jQuery.
Ага, спасибо, это полезное уточнение. Не задумывался как-то, что bootstrapcdn принадлежит Google.
За «старый миф» не в курсе, что за такой.
Но CDN и не помешает. Да, всех проблем не решит, но без него может быть и ещё хуже.
Плюсы CDN наверно все же преобладают перед возможными минусами.
При всем этом за услуги сети доставки контента нужно платить. А плата чаще всего зависит от объема передаваемого трафика.
За трафик в любом случае придётся платить. А трафик с CDN'а может быть сильно дешевле, чем трафик с обычного хостера, на котором у вас сайт.
Уже лет 10 хостеры не берут денег за трафик.
Вкупе с тем, что автор не был даже в курсе о существовании http/2, то обсуждать его опус даже странно.
Уже лет 10 хостеры не берут денег за трафик.Если Вы потребляете мало или если купили гарантированную ширину канала или если порт у Вас на серваке небольшой. В противном случае очень даже возьмут.
Что бы в этом убедиться — достаточно сравнить тарифы на «анлим шаред» и на «гарантированную полосу» в одном и том же ДЦ, даже сноски («при превышении оплата блабла») искать не надо.
Некрасиво воровать контент.
Действительно, очень похоже. Структура повествования та же, совпадают характерные фразы вроде "Географическая распределённость обычно ограничивается одним федеральным округом в России" → "А география передачи данных часто ограничивается одним федеральным округом".
Пойду сохраню полезные ссылки из комментариев, пока статью не удалили за плагиат.
— защита от DDoS (и хабраэффекта) (собственно отличия что во втором случае пользователю надо бы что-то все же показать) который может внезапно случится.
— CDN запросто может быть дешевле на старте и подключить ее — проще (хотя бы потому что не надо вешать на это фронтэнд разработчика, еще и со знанием конкретной CMS на которой сайт). Хотя да — в долгосрочной перспективе — наверно дешевле оптимизировать.
Какие проблемы CDN не решают
<...>
неоптимизированные изображения;
тяжелый и лишний код;
неправильное подключение JS и CSS;
ошибки в настройке базы данных;
недостаточная мощность сервера.
Эм, все кроме БД здесь — и есть прямая задача CDN. Тяжелый код, картинки, скрипты с разметкой — все это кэшируется на любой срок. По сути микросайты-визитки и тому подобные можно почти целиком загрузить на edge сервера, многократно ускоряя загрузку данных и распределяя нагрузку географически. Вплоть до того, что в нагрузку со всякой скрипто-статикой можно целые артефакты на netstorage закидывать и отдавать с них по запросу. Если деньги позволяют, конечно.
Осталось впечатление, что автор так и не понял, о чем писал.
Если что СДН снижаем примерно 80% нагрузки.
Почему CDN не нужны: развенчиваем старый миф