Comments 30
Правильно говорить не «жирным», а трафик-позитивным!
Интересная статья, спасибо!
Сайт с японской кухней — мои глаза!!! за что??? зачем я кликнул на эту ссылку?)))
Спасибо за интересную статью! Как всегда очень познавательно!
Спасибо за интересную статью! Как всегда очень познавательно!
Например, всем известный 8.8.8.8 от Google будет вести на ближайший узел, который чаще всего расположен во внутренней сети вашего провайдера. Это возможно благодаря правильному анонсированию сетей, по которому роутеры провайдера выбирают наиболее короткий маршрут.
— такое делается еще и для фильтрации по DNS… (знаю несколько провайдеров, которые просто запросы к любым адресам по 53-порту заворачивают к себе и фильтруют)
Это в принципе негодяи, на мой взгляд. Поэтому, от моей сети во внешнюю сеть никогда нет пакетов на 53 порту.
Сейчас любой проект вынужден платить за услуги CDN немалые суммы сложившейся олигополии CDN-провайдеров, либо строить собственный CDN, договариваясь с каждым провайдером в мире.
Интересно, почему до сих пор не додумались договориться и создать некий open source софт для создания открытого CDN, который любой интернет-провайдер мог поставить на своем железе, а любой сервис — использовать для отправки своего контента пользователям?
Сервису достаточно было бы поднять несколько origin-серверов в разных точках мира, и интернет-провайдеры сами бы забирали с них контент посредством этого софта. Абоненты получали бы контент максимально близко к себе. По мере роста количества участвующих сервисов и провайдеров последние могли бы ставить такие сервера чуть ли не на районных и домовых узлах, существенно экономя трафик. А не как сейчас — на центральном узле сети стоит куча серверов разных CDN-провайдеров, а также гугл, и т.п.
Также CDN-провайдеры стали бы практически не нужны. Неужели ни у кого нет заинтересованности в этом?
Интересно, почему до сих пор не додумались договориться и создать некий open source софт для создания открытого CDN, который любой интернет-провайдер мог поставить на своем железе, а любой сервис — использовать для отправки своего контента пользователям?
Сервису достаточно было бы поднять несколько origin-серверов в разных точках мира, и интернет-провайдеры сами бы забирали с них контент посредством этого софта. Абоненты получали бы контент максимально близко к себе. По мере роста количества участвующих сервисов и провайдеров последние могли бы ставить такие сервера чуть ли не на районных и домовых узлах, существенно экономя трафик. А не как сейчас — на центральном узле сети стоит куча серверов разных CDN-провайдеров, а также гугл, и т.п.
Также CDN-провайдеры стали бы практически не нужны. Неужели ни у кого нет заинтересованности в этом?
Не будет гарантий что этот софт работает как надо а не как кривые ручки провайдера его настроили (или возможно ручки не кривые а работающие в своих интересах)(например адаптировать картинки для уменьшения размера… по запросу пользователя или БЕЗ запроса пользователя или добавлять к картинкам полезную для пользователя информацию — например в habr.com/ru/post/489528 а если у нас видео тоже будет кэшироваться — это ж можно продавать и видеорекламу на чужих сайтах будет).
Ну и — просто шикарная возможность делать MITM, ключи ж надо отдавать либо отказываться от https, если cloudflare доверить можно то всем провайдерам всех стран… а зачем тогда https?
Cloudflare — доверяют потому что быть CDN это их основной бизнес и они заинтересованы эту работу делать качественно а зачем провайдеру это качественно делать?
Ну и — просто шикарная возможность делать MITM, ключи ж надо отдавать либо отказываться от https, если cloudflare доверить можно то всем провайдерам всех стран… а зачем тогда https?
Cloudflare — доверяют потому что быть CDN это их основной бизнес и они заинтересованы эту работу делать качественно а зачем провайдеру это качественно делать?
Провайдеры увидят только кучу непонятных файлов с длинными именами в виде хешей. Поди разбери что там внутри за картинки и другие медиа ресурсы, и с какого они сайта/сервиса/ресурса. А случае со стримингом аудио и видео всё это еще закриптовано DRM — и расшифровывается ключом, получаемым клиентом непосредственно от головного сервера.
Провайдер заинтересован это качественно делать по той же причине, по которой заинтересован качественно настраивать свои роутеры, сети и прочее оборудование. Ради удовлетворения потребностей пользователей, качественного доступа в интернет и снижения нагрузки на аплинки.
Провайдер заинтересован это качественно делать по той же причине, по которой заинтересован качественно настраивать свои роутеры, сети и прочее оборудование. Ради удовлетворения потребностей пользователей, качественного доступа в интернет и снижения нагрузки на аплинки.
А разве CDN провайдеры не этим занимаются? Ну то есть договариваются с крупными провайдерами и ставят свои edge сервера по ближе к пользователям. С софтом проблем как раз нет, например взять nginx и salt (ansible, puppet, chef, ...) для управления nginx'ом на серверах не сложно. Мы же как раз и платим CDN провайдеру, за то, что у него есть куча серверов у крупных провайдеров, + автономные системы, и он этим всем управляет, мониторит, поддерживает, и т.д.
А кому будет принадлежать автономная система с блоками ip адресов и эти железки у провайдеров? Кто будет поддерживать их работу и управлять ими?
open source софт для создания открытого CDN, который любой интернет-провайдер мог поставить на своем железе
А кому будет принадлежать автономная система с блоками ip адресов и эти железки у провайдеров? Кто будет поддерживать их работу и управлять ими?
Nginx, salt, и прочее — конечно было бы в основе всей системы. Плюс управляющая некая управляющая обвязка (первая часть софта, менее сложная). Главное чтобы провайдеру было это очень просто ставить, например как готовый образ.
Провайдеры ставили бы железки на своих собственных IP, в этом и суть. Так как внутри своей сети у них наилучшая связь со своими пользователями. И отдавали бы наружу список своих подсетей, которые они готовы обслужить. А вторая часть софта, работающая на ресурсах имеет у себя полную базу этих железок и их сетей, и умеет направлять своих пользователей непосредственно на ближайшую из них.
Провайдеры ставили бы железки на своих собственных IP, в этом и суть. Так как внутри своей сети у них наилучшая связь со своими пользователями. И отдавали бы наружу список своих подсетей, которые они готовы обслужить. А вторая часть софта, работающая на ресурсах имеет у себя полную базу этих железок и их сетей, и умеет направлять своих пользователей непосредственно на ближайшую из них.
Вообще говоря, тут и придумывать ничего не надо — достаточно простого, незащищенного HTTP и какого-нибудь прозрачного прокси.
Проблема подобной схемы в том, что интернет-провайдеры не хотят повышать качество своих услуг, они хотят вставлять на чужие сайты свои следилки и баннеры.
Наверное по тому что «провайдеры» уже сейчас стремятся влезть в трафик между сервером и клиентом напихав в него свою рекламу.
Что будет когда они получат доступ непосредственно к контенту?
Что будет когда они получат доступ непосредственно к контенту?
UFO just landed and posted this here
Стартовая страница Apple занимает всего 1.8 мегабайта, из которых 800 Кб — высококачественные картинки, грузится за 1.2 сек без всяких облаков, я в Николаеве, юг Украины, сервер в Купертино, Калифорния, США, в среднем 10000 км.
А кэш попробовали почистить перед тем, как перейти на страницу?
Ну это явно не 1.8 мегабайта, первая загрузка после очистки кэша:
Пятая загрузка после очистки кэша:
с кучей неоптимизированных SQL-запросов
А каким боком тут неоптимизированные SQL-запросы?
динамических JS
Ну JS это как проблема для сети, так и для клиента.
что даже на локалхосте стартовая страница генерится 5 сек
Ну генерируя страница 5 сек, и что? Не пересылается же все это время.
используя GET-запрос с timestamp
Никогда такого не видел, но за такое руки явно нужно отрубить.
Статья рассказывает о проблемах с трафиком, а вы про генерацию контента.
По существу.
Но только тот же www.apple.com живет в akamai. Потому и грузится мгновенно
Такие вот дела.
Но только тот же www.apple.com живет в akamai. Потому и грузится мгновенно
host www.apple.com
www.apple.com is an alias for www.apple.com.edgekey.net.
www.apple.com.edgekey.net is an alias for www.apple.com.edgekey.net.globalredir.akadns.net.
www.apple.com.edgekey.net.globalredir.akadns.net is an alias for e6858.dsce9.akamaiedge.net.
Такие вот дела.
Мелкая компания обращается к Wordpress главным образом потому, что не имеет денег на покупку контента, покупку движка, покупку индуса и покупку сервера.
Кешируется все прекрасно на стороне клиента. Ну да, диск кушается, за то второй раз взлетает моментально.
Кешируются и запросы в sql, а еще можно в памяти кешировать. Только это а) нужно уметь готовить и сочетать и б) стандартный WP хостинг такое не умеет и в) даже после этого сайты еще нудно оптимизировать перегенерацией css и js, выкорчевыванием лишнего с мест где ему не место и т.д. и т.п.
В целом мне удается сократить объемы на столько, что даже в фиговых условиях (джитеры, потери, малый канал) страницу можно прогрузить за 3 секунды. На хороших каналах она отдается что-то за 0,9.
И все это без CDN, на дохлой vps.
Но в целом идея CDN хороша, если у вас не часто обновляется контент. Тогда можно за вменяемые деньги получить результат "почти как у Apple", но на WP
Использую CDN от Cloudflare на своём самописном сайте (движку уже лет 10), так он снимает 80% трафика от моего сервера, кэшируя стили, картинки и, вероятно, страницы.
Хорошая статья. +1.
Конечно в разделе «Кому выгоден CDN» можно было бы побольше про интересы рекламодателей написать, про отслеживание пользователей. Даже упомянуть браузерные решения типа decentraleyes…
Конечно в разделе «Кому выгоден CDN» можно было бы побольше про интересы рекламодателей написать, про отслеживание пользователей. Даже упомянуть браузерные решения типа decentraleyes…
Почему не взлетел чистый multicast?
Но мультикаст не отвечает современным требованиям к видео, он как прямой эфир, включил канал и получаешь то что получаешь, ни запаузить, ни отмотать назад.
В то время как большниство видео смотрятся в записи
К CPU тоже предъявляются высокие требования. Из-за архитектуры игры вы сможете задействовать только одно ядро для вычислений, поэтому предпочтительнее высокая частота, нежели число ядер.
Немного офтоп, но все же спрошу. Майнкрафт до сих пор не поддерживает многоядерность? Играл 10 лет тому и конечно вопросы про производительность в основном сводились к шуткам про Java. В то время еще как-то не думалось про большое количество ядер в CPU.
Но за это время и наличие таких денег можно было полностью переписать архитектуру, чтобы улучшить производительность и все такое.
1. в начале статьи Вы написали что причина существования CDN — не настроенный мультикаст на промежуточных серверах. А если мультикаст нормально настроен на пути от сервера допустим vk.com к клиенту + vk.com — заплатил за CDN — то трафик как пойдет? Через мультикаст или CDN?
2. допустим компания не хочет давать CDN провайдерам свои ключи от HTTPS. Может ли она сама арендовать 5 VPS в США, КНР, Сингапуре, ЕС, Австралии и РФ (или просто по РФ если только российская компания) и сама сделать свой маленький CDN на squid, ngnix или чем то подобном
3. А если требуется CDN только по РФ — отечественные поставщики услуг CDN имеются корме мегафона или Селектела? или крупные российские провайдеры обеспечивают CDN по России сами?
2. допустим компания не хочет давать CDN провайдерам свои ключи от HTTPS. Может ли она сама арендовать 5 VPS в США, КНР, Сингапуре, ЕС, Австралии и РФ (или просто по РФ если только российская компания) и сама сделать свой маленький CDN на squid, ngnix или чем то подобном
3. А если требуется CDN только по РФ — отечественные поставщики услуг CDN имеются корме мегафона или Селектела? или крупные российские провайдеры обеспечивают CDN по России сами?
1. Через CDN. Потому что все URL уже нацелены на адреса провайдера CDN — см. краткий мануал выше. Плюс, как уже заметили, multicast — это по сути телевизор. Он применим тогда, когда многим пользователям одновременно нужно одно и то же. Например, трансляция матча в реальном времени. Если же у вас 794 пользователя смотрят одну и ту же серию Altered Carbon, но на разных моментах, то multicast тут бесполезен. Браузеру пользователя, который только что включил серию, не нужен пакет от середины, которую запросил другой.
Хотя, если присмотреться, то вариант доставки разных кусков одного и того же фильма сильно напоминает механизм работы торрента. Только в данном случае пир будет только один — источник контента с multicast. К сожалению, обычный браузер так не умеет, хотя, насколько я помню, Firefox что-то подобное тестировал.
2. Да, может. Я упоминал об этом, когда говорил о частных CDN. Но обычно это делают только крупные компании. Сложно и недешево.
3. А что касается российских CDN-провайдеров, то тут мы почти не пересекаемся. У нас часто берут железо в ЦОДах в конкретном городе, да. Но чтобы обеспечивать сеть — тут не проконсультируем.
Хотя, если присмотреться, то вариант доставки разных кусков одного и того же фильма сильно напоминает механизм работы торрента. Только в данном случае пир будет только один — источник контента с multicast. К сожалению, обычный браузер так не умеет, хотя, насколько я помню, Firefox что-то подобное тестировал.
2. Да, может. Я упоминал об этом, когда говорил о частных CDN. Но обычно это делают только крупные компании. Сложно и недешево.
3. А что касается российских CDN-провайдеров, то тут мы почти не пересекаемся. У нас часто берут железо в ЦОДах в конкретном городе, да. Но чтобы обеспечивать сеть — тут не проконсультируем.
Интересно как это саиту Texas Internet Consulting удалось стать онлаин до появления веба (1989)…
Sign up to leave a comment.
Что такое CDN, и как это вообще работает