Comments 47
Так и делаю.
Согласен с тем, что статья очень спорная. Никаких конкретных рекомендаций для конкретных случаев не увидел.
Кратко — при прочих равных я вообще не делал бы свой хостинг для статики, а пользовался готовыми решениями. Риск компрометации — вообще смешно, т.к. в этом случае вообще опасно говорить о "чужом" хостинге — нужно вообще поднимать полностью свою инфраструктуру вплоть до каналов до точек обмена трафиком. Даже большой бизнес не может себе это позволить, что говорить тогда о сайтах-визитках? В общем, поэтому читая такие статьи внутри мне становится смешно.
Единственный интересный факт, который я почерпнул — это про неработоспособность кросс-доменного кэширования. Вот про него можно было целое отдельное исследование забубенить
Риск компрометации — вообще смешно
Не настолько смешно. Компрометация CDN ставит под угозу десятки или даже сотни тысяч разных сайтов, причём одновременно, в то время как риск компрометации отдельно взятого сайта (особенно визитки) сравнительно низок.
Даже на shared hosting (не говоря уже о VPS и DS) можно принять ряд мер чтобы снизить риск компрометации, или, как минимум, оперативно мониторить целостность, в то время как компрометация CDN с высокой вероятностью останется незамеченной владельцем сайта, по крайней мере какое-то время (до поступления жалоб от клиентов).
Да, хостер имеет возможности сравнительно тайно вмешиваться в работу того что хостит (в определенных пределах), но если это вскроется (а это только вопрос времени) — это чудовищные репутационные потери, да и шанс что этим занимается кто-то крупный очень невысок. Максимум чего реально стоит опасаться — это блокирования доступа к хостингу, отказа в обслуживании, но уж точно не MitM.
Если же говорить про РФ, то возможен вообще нездоровый вариант типа блокировки CDN известной организацией (по ошибке или любой другой причине), и всё, приплыли — сразу целая пачка сайтов разрушена (пусть даже временно).
Ещё можно понять CDN когда нужно быть поближе к источнику запроса, при очень высокой нагрузке (как по траффику так и по rps), но если это не жутко загруженный сайт — то какой вообще смысл использовать CDN для bootstrap/jquery/etc? Потому что модно и «правильно», или потому что «все так делают»?
И наконец, никогда не стоит забывать в случае бесплатных CDN — если вы не покупатель, то вы — товар, в том или ином виде. Если же CDN платный, то всё равно остаётся вопрос, что дешевле — свой хостинг или свой хостинг плюс CDN.
Понимаете, почему я написал, что риск компрометации смешно? Потому что есть куча провайдеров, которые могут Вас как клиента нагнуть.
Предположим, что Вы клиент виртуального хостинга — тогда Вы полностью доверяете свои сертификаты ССЛ и приватные ключи владельцам этого ВХ. Боязно, да? Но в случае сайта-визитки действительно риски не такие высокие. В случае, если Вы хоститесь на виртуальных машинах — очевидно, что при прочих равных, провайдер имеет доступ к самим виртуальным машинам, вплоть до того, что может оттуда вытаскивать дампы памяти и файлы с дисков. Причем, что хуже по сравнению с ВХ — Вы об этом никогда не узнаете. Ну, и т.д. Все эти риски нужно учитывать. И если так подходить к вопросу то не то, что CDN, то вообще всю инфраструктуру нужно держать у себя, обвешать камерами и посадить безопасника. Дорого? Да. Безопасно? На самом деле даже в этом случае человеческий фактор никто не отменял. Вот дадут этому цепному псу денег конкуренты… и все… приплыли.
Поэтому я скорее поверю зарубежному CDN с хорошей репутацией, чем местным провайдерам (которые при любом удобном случае сдадут ключики от моей инфры силовикам).
И наконец, никогда не стоит забывать в случае бесплатных CDN — если вы не покупатель, то вы — товар, в том или ином виде.
соглашусь. Но здесь больше вопрос для клиента в том, какой уровень сервиса этот CDN будет предоставлять. Скорее всего на бесплатном тарифе жесткие ограничения по трафику, по защите от DDoS атак и пр. Т.е. в случае ЧП — действительно, что доступность "защищаемого" пострадает. Но, как и везде — нужно включать голову. Допустимо это или нет. Какие риски и убытки могут быть. И т.п.
Если же CDN платный, то всё равно остаётся вопрос, что дешевле — свой хостинг или свой хостинг плюс CDN.
Тенденция такова, что при прочих равных выгоднее что-либо отдать профессионалам. Ибо делать самому дорого (нужны специально обученные люди, их ФОТ, специальное оборудование), а риски можно покрыть договорными отношениями.
Ещё можно понять CDN когда нужно быть поближе к источнику запроса, при очень высокой нагрузке (как по траффику так и по rps), но если это не жутко загруженный сайт — то какой вообще смысл использовать CDN для bootstrap/jquery/etc? Потому что модно и «правильно», или потому что «все так делают»?
И да, и нет. Как и обычно — есть три категории игроков. Маленькие, средние и большие. И для них будут разные правила игры. Например, мелкие могут страдать от того, что на них большой трафик и они будут биться за каждую копейку. Тогда действительно — почему бы не прикрыться cloudflare, закэшировать все что можно, а bootstrap & jquery отдавать с внешнего ресурса? Средние — уже почти наверняка сидят на каком-нибудь амазоне, где свои нюансы… А крупные… Ну, у них счет на трафик может исчисляться тысячами $ и любая микро-оптимизация может сэкономить круглую сумму.
Если же говорить про РФ, то возможен вообще нездоровый вариант типа блокировки CDN известной организацией (по ошибке или любой другой причине), и всё, приплыли — сразу целая пачка сайтов разрушена (пусть даже временно).
Это российская специфика — это раз. Два — пострадать может не только CDN, а вообще любой внешний по отношению к РФ хостер (scaleway & digitalocean до сих пор в бане). В третьих, есть CDN, у которых есть региональные филиалы в России, и провайдеры, у которых тоже есть точки присутствия в РФ.
Предположим, что Вы клиент виртуального хостинга — тогда Вы полностью доверяете свои сертификаты ССЛ и приватные ключи владельцам этого ВХ.
Что мне мешает использовать свои сертификаты и приватные ключи к ним? Только тот факт что «всё включено» (не всегда, кстати)? Если провайдер виртуального хостинга не даёт даже это сделать самостоятельно — то я бы сильно подумал перед тем как у него хостится.
И если уж мы говорим про виртуальный хостинг — то скорее всего это всё же очень небольшие нагрузки (причём без гарантий по доступности и ресурсам), а раз так — то снова вопрос в том, нужно ли ему вообще CDN?
Поэтому я скорее поверю зарубежному CDN с хорошей репутацией, чем местным провайдерам
Видимо, всё дело в том что для меня «местные» это для вас «зарубежные», у нас (в Германии, в частности) все эти ужасы (типа доступа к VM клиента) хоть и возможны, но серьезно караются, если вдруг чего. Да и выбор есть среди тех кто с хорошей репутацией.
Но как дополнительную линию обороны можно использовать VPS/DS с шифрованным диском и своим загрузчиком, хотя он и перестанет быть reboot-safe. Да, провайдер, имея прямой доступ памяти и прочему, может конечно и в этом случае получить доступ (хотя и не всегда), но это случится только если вы станете конкретной целью, просто ради любопытства этим вряд-ли будут заниматься.
Ибо делать самому дорого (нужны специально обученные люди, их ФОТ, специальное оборудование), а риски можно покрыть договорными отношениями.
Честно говоря я не совсем понимаю — если человек (фирма) в состоянии настроить хостинг, что ещё ему нужно знать для того чтобы выложить статику у себя вместо CDN? Что в этом такого что нужно специальное оборудование и специально обученные люди?
Основной смысл CDN — в разгрузке своего сайта, если сайт настолько загруженный или к нему высокие требования по доступности и времени отклика из любой точки мира — то да, потребуется и специальная инфраструктура, и специально обученные люди, дабы всё работало как часы, но для большинства сайтов это всё же не так. С другой стороны, доверять CDN (даже с хорошей репутацией) отдавать статические скрипты для сайта финтеха, банка, страховой etc — это в высшей степени неразумно, ибо от необхомости мониторить и защищать своё хозяйство не избавляет, но становится менее надёжным и менее безопасным (даже у Cloudflare бывают проблемы).
Что ещё важно — посколько, с вероятностью 99.99%, бизнес-логика любого сайта (кроме визиток, пожалуй) строится не на том что распостраняется посредством CDN, то мониторить сайт и его бесперебойную работу всё равно придётся, ибо если он «ляжет», то CDN всё равно не спасёт — все jquery и прочие плюшки в момент станут бесполезными.
Впрочем, исходя из ваших объяснений, я начинаю подозревать что скорее это актуально для РФ (или даже СНГ) — борьба за сокращение траффика и всё такое, ибо в Западной Европе или США это не так актуально, да и хостеры намного более адекватные.
Что мне мешает использовать свои сертификаты и приватные ключи к ним? Только тот факт что «всё включено» (не всегда, кстати)? Если провайдер виртуального хостинга не даёт даже это сделать самостоятельно — то я бы сильно подумал перед тем как у него хостится.
Хотя бы два соображения:
- Если ВХ предоставляет веб-панель для установки сертификатов, то Вы их закачаете туда как в черный ящик. Соответственно, содержимое сертификата и публичного ключа будет раскрыто для ВХ. В худшем случае — по дороге — кому-то ещё.
- В любом случае приватный ключ и сертификат будут лежать в конфигурации веб-сервера и зачастую на ВХ для экономии он общий на всех клиентов. Бывают тарифные планы с индивидуальным обслуживанием (да и вообще при прочих равных лучше заказать виртуалку и настроить ее самому, но когда речь идёт о низкой цене без каких-либо компромиссов, то ВХ все ещё вне конкуренции), но это не столь принципиально. В общем, защита такого сервера скорее всего подхрамывает. Пользователи регулярно заражают его php-скриптами или попросту оставляют уязвимости и туда скрипт-киддиз закидывают свои скрипты. Теоретически спасает система прав юзеров и модули типа селинукс… Но не всегда.
Дальше продолжать?
Понятно, что я именно в вопросе ИБ не привязываюсь к ВХ, но это самый яркий пример такой… Дырявой услуги. Вот, ей-Богу, лучше уж тогда конструкторы сайтов типа.
Впрочем, исходя из ваших объяснений, я начинаю подозревать что скорее это актуально для РФ (или даже СНГ) — борьба за сокращение траффика и всё такое, ибо в Западной Европе или США это не так актуально, да и хостеры намного более адекватные.
Да, действительно в СНГ своя специфика. Но и зарубежом точно так же соображения экономии трафика имеют место быть.
другой стороны, доверять CDN (даже с хорошей репутацией) отдавать статические скрипты для сайта финтеха, банка, страховой etc — это в высшей степени неразумно, ибо от необхомости мониторить и защищать своё хозяйство не избавляет, но становится менее надёжным и менее безопасным (даже у Cloudflare бывают проблемы).
Согласен, что для финтех, банков и пр. нужен свой подход. У них свои требования к используемым информационным системам.
У блокировок есть и обратная строона: например, некоторые страны блокируют некоторые российские ресурсы, которые можно отнести к CDN в данном контексте. И подключая скрипты с них для своих сайтов бездумно, вы рискуете если не полной неработоспособностью сайта, то уходом пользователей до сетевого таймаута.
Странная экономия на задержке в милисекундах. А если у хостера плата за исходящий трафик? Еще минус хранить у себя, это если ресурсов довольно много и есть наплыв пользователей, к примеру онлайн трансляция, то ваш хостинг будет будет ощущать довольно сильную нагрузку по полосе. В свое время освободил кучу полосы перенеся как раз таки сайт за Cloudflare.
Подробное описание инцидента: blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today
Абсолютно верная статья. У меня такое ощущение, что миф про выгоду CDN запускали сами владельцы CDN для привлечения клиентов. Мне эта идея всегда казалась бредовой, отдавать пару файлов через CDN, а все остальное (HTML, пользовательские картинки) — со своего сервера. Вот еще недостатки CDN:
- нарушение сетевой связности. РКН в любой момент может забанить иностранные IP адреса CDN и ваш сайт из-за этого упадет. Глупо нести убытки из-за того, что кто-то разместил на Амазоне призыв выйти на митинг, телеграм-прокси или фразу про сказочного Путина.
- политические риски. Из России постепенно прогоняют и будут прогонять западные сервисы, ухудшая к ним доступ.
- ваш сайт скорее всего ближе к пользователям. Допустим, у вас магазин, ориентированный на жителей Гадюкинской области. Скорее всего сервер в Гадюкино будет ближе и каналы к нему будут толще, чем до западных CDN.
- расходы времени разработчиков на настройку и подкючение CDN. Это будет стоить вам денег.
- чем больше серверов вы используете, тем больше точек отказа и его вероятность
- с CDN невозможно использовать проверку актуальности файла с помощью If-Modified-Since и надо включать "вечное кеширование" ресурсов, и схемы сброса этого кеша, на что, опять же, надо тратить небесплатное время разработчиков.
Также, я думаю, что идея про кеширование не работает. Сейчас каждый сайт ставит кеширующие заголовки на все свои ресурсы, кеш постоянно переполняется и старые файлы вытесняются из него.
Я помню историю, много лет назад, я сдал сайт и на нем jQuery был синхронно подключен через CDN. И надо же, этот CDN умудрился упасть как раз в тот момент, когда директор заказчика решил проверить сайт. С тех пор я всегда рекомендую не использовать CDN. Nginx на вашем сервере будет отдавать файлы так же хорошо, как и Nginx на сервере CDN. А вы думали, они какой-то специальный сервер используют?
Естественно, могут быть ситуации, когда использование CDN выгоднее. Но если у вас обычный Интернет-магазин, рассчитанный на Россию и прежде всего на Москву, то вам не нужны точки раздачи файлов в Сигнапуре и Лондоне. Да и даже если бы были нужны — они вам не помогут ускорить загрузку для лондонца, так как CDN кеширует лишь маленькую часть файлов. а большинство все равно будет грузиться с вашего далекого сервера.
Мне эта идея всегда казалась бредовой, отдавать пару файлов через CDN, а все остальное (HTML, пользовательские картинки) — со своего сервера
Согласен, что имеет смысл отдавать через cdn всю статику, но, как говорится, дьявол в деталях и надо смотреть по каждому конкретному случаю. Может вообще у всех пользователей сайта общих ресурсов только 1% и смысл тогда кэшировать остальные 99%
Если мы говорим о CloudFront, Fastly или CloudFlare, то выгода от использования таких сервисов для средних и больщих проектов очевидна.
— вы всегда можете выявить начало атаки т.к. у вас на сервер поступают только запросы к приложению и они не теряются в общем потоке запросов статики.
— для простых видов атак вы можете поставить фильтр по количеству запросов с одного адреса. Если идёт статика то вы не сможете установить ограничение по фильтров и.к. на один запрос к приложению буде приходить 50-100 запросов на статику
— после установки защиты может оказаться что на ваш сайт есть ссылки на статику в почтовых сообщениях. Если эти ссылки открываются не через браузер а через почтовый клиент то защиту почтовый клиент не проходит и картинка будет недоступной. Аналогично например gmai подменяет ссылку в почтовом сообщении на свою с ылау и пытается забрать картинку ботом. Бот конечно тоже защиту не проходит
С cdn таких проблем у Вас не будет
Уже не говоря о том что cdn как правило ещё устраивают так чтобы приблизить доступ к контенту по сети.
Запросы к приложению и статике легко раздели на уровне конфига веб-сервера. Даже, если у них один домен. И логи писать отдельно и настроить фильтрацию по к-ву запросов (хотя, смысла в этом немного. Лучше с кэшированием на уровне веб-сервиса поиграться).
В статье описывается подключение библиотек с CDN которые хостят эти библиотеки. А вы описываете вариант с кастомной настройкой cdn под конкретный сайт. Не смотря на то, что вы описали странный кейс, он все же совсем не о том, что пишут в самой статье.
В 2019 http2+nginx позволяют очень просто настроить систему так, что быстрее будет работать на одном сервере, если он не перегружен. Выносить статику смысл есть только если это часть контента и регулярно наполняется (картинки в статьях, аватарки пользователей и т.д.).
Для css, js, интерфейсных картинок и прочего, что является частью самого сайта, в этом давно нет смысла.
Если у вас статика будет отдаваться с другого домена (3-го уровня например), то у вас будет 12 одновременных коннектов. Если мелкой статики очень много, то это дает ощутимый выигрыш. Даже можете тот же самый сервер использовать если так уж хочется. Отдавать весь контент с 1 домена — это самый медленный путь.
Извините, а где хранить статические пассивы?
Открываю страницу с NoScript, вижу 10-20 отсылок на другие сайты. Ну рекламные режутся сразу, а что касается cloudflare, не очевидно — это cdn ресурса или же это как-то пролезший зловред пытается загрузить payload.
Поэтому тоже поддерживаю идею «хранить статику у себя»
В итоге иногда возникают совершенно мистические проблемы, которые невозможно воспроизвести, а получить адекватную поддержку от провайдера CDN не всегда возможно (если, конечно, вы не очень ценный клиент), чаще всего всё заканчивается чем-то вроде «вам нужно обновить приложение/сервер до версии X.Y».
Размещая статические ассеты у себя или на CDN нужно учитывать плюсы и минусы каждого варианта. И принимать решение исходя из баланса плюсов и минусов для конкрентного проекта.
А не так, что «все побежали держать все на CDN и я побежал»(с).
Что-то в последнее время на хабре зачастили упоминания jQuery :)
CDN, ну хорошо, отличный CDN это десятки, сотни, тысячи и даже десятки тысяч серверов по всему миру, который готовы отослать статику или не очень с ближайшего хопа до конечного клиента в кратчайщий путь.
Всегда должен быть ориджин (для валидации и фуллбэка) + CDN, для более менее большого и международного проекта. Иначе пользователя из Австралии заходящие на сайт в ЮК будет чувствовать себя ущербными на скоростях диалапа. Провайдерский раутинг с 400-1000мс на АДЛС все еще реальность, про мобильный интернет можно даже не упоминать, там уже секунды. Без CDN файсбучик и любимый онлайн магазин были бы совсем убоги.
Провайдерский раутинг с 400-1000мс на АДЛС все еще реальность, про мобильный интернет можно даже не упоминать, там уже секунды.
Причем, что интересно — это так в цивилизованных странах вроде стран Европы, Uk, США, Австралии и Новой Зеландии. И только в России в каждый дом заходит проводной интернет (*)
(*) по крайней мере в мегаполисах
В цивилизованных странах только недавно появился смысл в широких каналах. Тогда как у нас даже 15 лет назад вполне было чем забить 100мбит.
опять же пинг. Сервер в ЮСА, клиент в Японии, пинги от 300мс и выше. Канал до США не резиновый, выдаст ну 1-10мбит. Подключаем клоудфрант/флайр/акамай и получаем пинги от 1мс до статических ресурсов. И канал до локальных ресурсов от 10мбит
К большому сожалению я не знаю как в России :( Но думаю имеется Российский CDN с кучей хопов для максимальной быстрой доставки контента.
Как по мне, то решение размещать часть статики на сторонних ресурсах — это оптимизация. И как часто бывает — преждевременная. По умолчанию в нынешних реалиях должно быть "всё своё ношу с собой".
Храните статические ресурсы на своём хостинге