company_banner

Что такое CDN, и как это вообще работает


    Сайт Texas Internet Consulting. Жив с 1987 года, страница — 7 Килобайт.

    Помните время, когда главная больше 90 Килобайт считалась расточительством? С тех пор Интернет стал жирным. И понадобились инструменты, чтобы правильно раздавать трафик сразу с нескольких узлов. Например, во время очередного обновления Fortnite CDN от Akamai сумел переварить трафик мощностью в 106 Терабит в секунду. Давайте пробежимся по основным принципам этой технологии и потенциальным проблемам.

    И о том, почему Minecraft в Казани тормозит, если не развернуть сервер в черте города.

    image
    Вот современный сайт, который соблюдает разумные рамки: 1,7 Мегабайта.

    image
    Пример относительно тяжёлого сайта с видеоконтентом и анимацией: 39,5 Мегабайта радости и шевеления.

    Сейчас, когда 100 Мегабит домашнего Интернета воспринимаются вполне привычно, всё меньше дизайнеров заморачивается с кропотливым сжатием каждого изображения и экономии на мелочах. Ситуации, когда кто-то умный положил на главную картинку в PNG весом в 30 Мегабайт, бывают чаще, чем хотелось бы.

    image
    Исторические данные взяты здесь.

    А если посмотреть на статистику, то тенденция к росту объёмов становится ещё более очевидной. Например, за 10 лет размеры средней страницы, рассчитанной на мобильные устройства, выросли в семь раз (с 233 до 1 864 Килобайт).

    Проблема ширины канала


    У вас есть много иллюстраций и видео, которые надо доставить клиенту. Передать однократно несколько Мегабайт не очень трудно: современные каналы связи позволяют делать это за секунды. Всё становится гораздо хуже, когда к вам на сайт одновременно заходят вначале несколько десятков, а потом — тысяч посетителей.

    Давайте считать. Допустим, у вас один-единственный сервер и у вас типичная страница весом в 1,8 Мегабайта. Клиенты приходят к вам впервые и с «холодным» кэшем, то есть в браузере нет ранее загруженных материалов с вашего ресурса.

    Чтобы отдать за приемлемые три секунды страницу, нам потребуется ширина канала в 4,8 Мегабита на одного посетителя. Если их придет 100, то это уже 480 Мегабит. А если вдруг потребуется отдать тем же людям небольшой видеофайл размером 10 Мегабайт, то нам потребуется канал в 2,7 Гигабита.

    Таким образом, у вас появляется два основных типа контента: динамический и статический.
    Статический контент, как следует из названия, не изменяется или меняется крайне редко. Например, это логотип веб-сайта. Или залитые образы с дистрибутивами ПО.

    Динамический контент отличается тем, что он генерируется сервером «на лету». Обычно это происходит в момент самого запроса. Например, при клике на кнопку формируется плей-лист, уникальный для конкретного пользователя.

    Именно для решения проблемы кэширования статического контента и были созданы CDN. Но, как мы увидим дальше, и с динамическим контентом CDN тоже могут помочь.

    Почему не взлетел чистый multicast?


    image
    Схема работы multicast.

    Мультикаст очень хорош. В отличие от юникаста он позволяет исходному серверу бросить в сторону клиентов только один пакет, который будет ретранслирован строго тем, кто его ожидает. В отличие от броадкаста не будет слать пакеты всем кому надо и не надо, засоряя Сеть мусором.

    Одна проблема — поддержка оборудованием. Для того чтобы гарантировать, что multicast-пакет доедет до каждого клиента, нам нужно убедиться, что каждый промежуточный узел правильно сконфигурирован и готов доставить его дальше. В противном случае пакет «угаснет» где-то по дороге на тупом маршрутизаторе, а клиент не дождётся своей вечерней трансляции на YouTube. Именно поэтому вместо более продвинутого мультикаста взлетела географически распределённая сеть CDN, которая работает на более простом unicast.

    Вторая проблема — 4K и грядущий 8K. Провайдеры уже нервно вздрагивают от объёмов трафика, а будет только хуже. В варианте чистого мультикаста вы не можете регулировать качество вещания. В случае того же Google Global Cache в качестве CDN вы можете отдавать локальным клиентам картинку в адаптивном битрейте. GGC закэшировал некоторый кусок видео и кормит своих клиентов в 4K. В этот момент у одного из клиентов возникают проблемы из-за перегрузки локальной сети. GGC автоматически снизит битрейт с учётом изменившейся ширины канала клиента и продолжит раздавать ролик.

    Тем не менее технология очень привлекательна для IPTV, поэтому некоторые компании предлагают такие интересные решения, как nanoCDN Multicast ABR. Концепция строится на добавлении в сеть провайдера дополнительного узла-транскастера, который преобразует unicast от источника видео за пределами сети в multicast до конечного потребителя.

    Мир без CDN


    Итак, мы определились с тем, что нам потребуется очень много ресурсов для того, чтобы обслуживать всех посетителей из единой точки. Давайте попробуем представить, как выглядел бы современный веб без CDN. Каждая компания строит себе один огромный дата-центр и собирает все ресурсы в одной-единственной точке мира.

    image
    Централизованная раздача контента и распределённая схема через CDN.

    Небольшие веб-ресурсы


    Почти не пострадают. Даже сейчас есть множество местечковых форумов, посвящённых узкой тематике разведения, ну, например, алтайских перепелов. Там почти никогда не бывает огромного наплыва посетителей, почти нет тяжёлого контента. Они как жили в начале нулевых, так и продолжают в 2020 году, принося ценность своему небольшому сообществу.

    Видеохостинг


    Забудьте. Никакого YouTube, Vimeo и других ресурсов без CDN не будет (важно: торрент-сеть, по сути, тоже можно считать подвидом CDN в такой ситуации, но работающей по совершенно иным принципам).

    Без CDN можете смело возвращаться в начало нулевых, когда видео было доступно по прямым ссылкам и его нужно было качать. Никакого стриминга, FlashGet и прочих хардкорных менеджеров загрузки. Причём речи о скачивании в реальном времени даже и близко не было бы. Уже сейчас, если верить статистике, один только YouTube генерирует 37 % всего мобильного трафика в мире. Это миллиард часов видео в сутки. Без географического распределения нагрузки подобные сервисы просто не родились бы.

    image

    Именно поэтому тот же Google предлагает установку в дата-центры крупных провайдеров своего оборудования, которое обеспечивает так называемый GGC — Google Global Cache. Когда вы тычете в популярный ролик на YouTube, то данные тащатся не из дата-центра в Калифорнии, а из ближайшего крупного узла связи вашего провайдера. Если ролик малопопулярен, то трафик уже прилетит из-за пределов внутренней сети провайдера, но будет закэширован.

    Раньше провайдеры существенно экономили на трафике тем, что делали кэши и локальные файлшары. Тогда первый скачавший новую песню «Металлики» пользователь давал возможность провайдеру не платить за магистральный трафик для ещё 50 возжелавших, но выставить счёт пользователям как за обычный трафик. Можно сказать, что это был ещё один подвид CDN. Отсюда же растут уши идеи с retracker.local. В 2010 году nag.ru предложил оригинальную идею организации локальных ретрекеров под этим адресом у всех провайдеров для облегчения поиска локальных пиров и снижения внешнего трафика. Идею поддержал rutracker.org, начав добавлять этот адрес в дополнение к своим ретрекерам.

    Мессенджеры


    Выживут, но без всяких модных стикеров, трансляции геопозиции и прочих радостей. А ещё вы, скорее всего, можете забыть про пуши со стороны Google Services. То есть в Сети вы будете только тогда, когда запущено приложение, что означает непрерывное потребление батарейки. Можете вспоминать про ностальгические времена ICQ и Jabber. Он со своей федеративной системой был не так плох, кстати. Кое-где его до сих пор используют.

    Магазины


    Остались бы исключительно в формате странички локального мясного магазина с картой проезда и телефоном. А ещё придётся вспомнить старые добрые бумажные распечатки прайсов в магазинах компьютерных комплектующих. Amazon и Aliexpress просто не смогли бы существовать. У них и сейчас со всеми современными технологиями запредельные пиковые нагрузки в моменты распродаж, которые требуют сложнейшей балансировки и непростой облачной архитектуры. Тем не менее в парадигме «один дата-центр на магазин» можно было бы устраивать распродажи. Просто они шли бы медленнее. В случае отказоустойчивости в виде двух площадок часть проблем резервирования решилась бы, но каждый запрос пользователя ходил бы через всю страну именно до них без локального кэша. А если уж делать локальный кэш, то почему сразу же не сделать там же на узле и серверные приложения?

    Отдалённые регионы


    Если вы живёте в отдалённых регионах, куда не ведут широкие кабельные магистрали, то вам было бы совсем грустно. В начале нулевых вполне типичной была ситуация, когда жители Сахалина могли по пять минут ждать загрузки обычной веб-страницы. С современным вебом всё было бы ещё хуже: много ресурсов просто было бы сброшено по тайм-ауту, не загрузившись.

    Проблема долгого пинга


    Вторая проблема, которую решает CDN, — это ускорение запросов. Около вас есть локальный сервер, который кэширует статический контент и иногда сам умеет выдавать динамический. Если вам знакомы тормоза 1С при забегах из Владивостока в Москву или особенности работы с SAP через какой-нибудь корпоративный VPN в Европе из Новосибирска, то вы понимаете всю глубину боли. Сотни запросов незаметны при обычных сетевых задержках внутри города, но, когда расстояния увеличиваются, неиллюзорно тормозить начинает всё. Россия в этом плане выделяется тем, что у нас страна такого размера, где от случайного города до столицы может оказаться дальше, чем от этого же города до столицы другой страны. Это рождает интересные особенности туннелирования трафика серверных приложений той же MS.

    Так что внутри современной CDN?


    CDN — это общее название множества различных технологий, призванных доставлять статический контент как можно ближе и быстрее по отношению к клиенту. Например, torrent-раздача новой версии Ubuntu — это тоже CDN. А вы становитесь одним из узлов раздачи, помогая другим пользователям быстрее получить новую версию дистрибутива и не положить основной сайт под нагрузкой.

    В случае классического понимания речь идёт о специально созданных и предназначенных только для решения подобных задач сетях. Часто проприетарных. Если вам нужен CDN общего назначения, то вы обращаетесь к кому-то из крупных вендоров, имеющих серверы по всему миру и достаточные каналы связи. Крупнейшие из них, такие, как Amazon и Google, тянут свои собственные кабели связи для обеспечения нужной пропускной способности и снижения задержек.

    1. Выбираем ближайший узел


    Для начала пользователю при DNS-запросе отдаётся адрес ближайшего к нему узла. Это нужно для того, чтобы ваш браузер не полез качать фотографию откуда-то из Ванкувера, когда ближайшая к вам копия файла есть в кэше на сервере в вашем городе. Обычно это делается с помощью GeoDNS, но иногда используется специально сконфигурированный Anycast. Например, всем известный 8.8.8.8 от Google будет вести на ближайший узел, который чаще всего расположен во внутренней сети вашего провайдера. Это возможно благодаря правильному анонсированию сетей, по которому роутеры провайдера выбирают наиболее короткий маршрут.

    2. Кэшируем


    Это ключевой момент в работе CDN. Кэширование очень важно для снижения трансграничного трафика, каналы для которого совсем не резиновые. Более того, очень важно, чтобы кэширование происходило строго в соответствии с географией пользователей. Например, локальный Google Global Cache не должен хранить YouTube-видео с рекламой российского сотового провайдера на серверах в Нью-Йорке. Маловероятно, что она будет кому-то там нужна. Аналогично нет смысла кэшировать рецепты приготовления лягушачьих лапок на французском языке где-то в Перми. Поэтому основной принцип довольно прост. Первый пользователь, который запросил контент, ждёт дольше всех, пока он не подтянется откуда-то из франкфуртского дата-центра. Зато все последующие обращения будут происходить с минимальными задержками и нагрузками на сеть провайдера.

    Причём у крупных вендоров схема очень похожа на работу классического DNS. Мы вначале спрашиваем ближайший к нам узел, нет ли у него нужной картинки. Потом он идёт не к корневому узлу, а к географически ближайшим. И если он и там не сможет найти нужное, то только тогда пойдёт к первоисточнику на другом континенте. Таким образом, мы получаем максимально эффективное хранение тяжёлых файлов как можно ближе к локальным клиентам с учётом их потребностей.

    3. Доставляем динамику


    Динамический контент генерируется на стороне вашего origin-сервера. Например, создаётся страница с новостями, отсортированными под конкретного клиента. Кэшировать всё это очень сложно, так как контент, по сути, уникальный. В большинстве случаев динамическое содержимое вроде текста «В Лондоне +23 градуса» доставляется от origin-сервера, а статическое вроде картинки с Биг-Беном прилетает от CDN.

    Чтобы ещё больше повысить скорость загрузки страницы, некоторые компании предлагают кэширование динамического контента за счёт переноса выполнения скриптов на сторону их инфраструктуры. Например, такой вариант предлагает сервис Cloudflare Workers. При этом код кэшируется и выполняется быстро и в географически нужных локациях. При этом тот же Cloudflare использует свою проприетарную технологию маршрутизации трафика Argo Smart Routing, что позволяет оптимизировать доставку запросов пользователей по наиболее быстрым маршрутам внутри своих сетей.

    4. Реализуем OPES-протокол


    OPES (Open Pluggable Edge Services) — это протокол, предназначенный для адаптации одного и того же контента под нужды конкретного клиента. Работает это примерно так.

    В Сети есть куча клиентов, origin-сервер с исходным контентом, кэширующий сервер CDN и специальный callout-сервер, отвечающий за адаптацию контента:

    1. Клиент с PC запрашивает контент у CDN.
    2. CDN забирает его у origin-сервера, кэширует и отдаёт клиенту.
    3. Клиент с мобильного телефона запрашивает тот же ресурс у CDN.
    4. CDN не беспокоит origin-сервер, отправляет на переработку свой кэш в сторону callout-сервера.
    5. Callout-сервер адаптирует контент под мобильного клиента и отдаёт его CDN.
    6. CDN кэширует новый вариант ресурса и отдаёт его мобильному клиенту.

    5. Правильно отдаём картинки, Image CDN


    CDN — это намного больше, чем просто тупой кэш для файлов. Хороший пример — правильная работа с изображениями. Обычный CDN общего назначения не обращает внимания на особенности клиента, который к нему обратился. Попросили отдать картинку — он её отдаст, неважно, запросил её Samsung Galaxy, iPad или PC с 8К-дисплеем. Правильный Image CDN отдаст картинку в нужном формате, сжав её под размеры дисплея клиента. Тем самым экономится большое количество трафика и ускоряется загрузка страниц на тех устройствах, которым не нужна графика в огромном разрешении.

    6. Делаем ещё кучу нужных вещей


    Помимо доставки контента, узлы CDN могут обеспечивать терминирование HTTPS-трафика, WAF (Web Application Firewall), защиту от DDoS и кучу других задач.

    Что нужно для подключения к CDN?


    Каждый проект уникален. Но в целом в минималистичном варианте задача сводится к нескольким этапам:

    1. Отделите статический контент и перенесите его на отдельный домен, например, на static.mydomain.com.
    2. Создайте отдельный домен для раздачи контента с CDN, например, cdn.mydomain.com.
    3. Заключите договор с CDN-провайдером и сообщите ему, откуда он будет забирать origin-контент (static.mydomain.com) и откуда отдавать клиентам (cdn.mydomain.com).
    4. Настройте в своём DNS cdn.mydomain.com на IP-адреса вашего провайдера.

    Теперь, когда на странице будут попадаться ресурсы с cdn.mydomain.com, они будут раздаваться с географически ближайшего сервера вашего CDN-провайдера.

    Управление кэшированием


    CDN — это сложный интеллектуальный кэш. Кроме того, каждый браузер на стороне клиента также старается запрашивать только тот контент, который изменился, чтобы снизить нагрузку на интернет-канал.

    Проблема любого кэша в том, что мало отрегулировать скорость его протухания. Нужно убедиться, что ни промежуточные узлы, ни браузер не додумаются закэшировать особо чувствительные данные. Например, реквизиты банковской карты. Замечали, что их каждый раз приходится вводить заново? Вот это оно и работает.

    Для этого необходимо использовать специальные валидаторы в заголовках веб-страниц.

    cache-control: private


    Заголовок говорит о том, что контент может быть закэширован только конечным клиентом, но не промежуточным узлом, таким, как прокси или CDN.

    cache-control: public


    Контент может быть кэширован кем угодно.

    cache-control: no-store


    Контент не должен быть кэширован никем и никогда. Чаще всего используется для страниц с особо чувствительной информацией, например, форме ввода реквизитов банковской карты.

    cache-control: no-cache


    Контент не должен использоваться до тех пор, пока клиент не убедится, что он просматривает последнюю версию. Это реализуется за счёт хедера ETag, который представляет собой идентификатор, уникальный для конкретного ресурса. По сути, это хэш.

    Клиент при запросе посмотрит, что у него лежит в кэше, и отдаст ETag в заголовке If-None-Match. Если ETag от клиента соответствует актуальной версии у сервера, то он ответит клиенту, что можно пользоваться кэшем. Иначе пришлёт новую версию.

    cache-control: max-age


    В этом заголовке указывается срок жизни ресурса в секундах с момента первого получения.
    Помимо управления кэшированием через заголовки, владелец ресурса всегда может внести дополнительные изменения через панель управления или сбросить кэш, ткнув CDN через API.

    Кому выгоден CDN


    Практически всем. Клиент получает самые низкие пинги при обращении к ресурсу и отсутствие ожидания при массовой нагрузке на сервис, например, при выходе очередного дистрибутива ОС или игры.

    Источник контента получает конкурентное преимущество. Современный веб приучил людей, что страница, которая не грузится больше нескольких секунд, скорее всего, сломана и можно просто перейти к следующей ссылке. Тот же Google заинтересован, чтобы его поиск работал как минимум не медленнее, чем у его конкурентов, а видео и реклама воспроизводились без задержек. Иначе клиентура быстро перебежит к кому-то ещё. По сути, монополия таких крупных гигантов во многом строится именно на очень широких каналах связи и множестве CDN по всему миру. Вы можете быть очень крутой компанией с точки зрения технологии, но вам не запустить второй YouTube без многомиллиардных вложений в дата-центры.

    Ну и, наконец, провайдер. Он будет только рад максимально замкнуть трафик пользователей внутри своей сети и минимизировать свои затраты на пиринг с другими провайдерами на точках обмена трафиком. Это особенно актуально с учётом того, что видеоконтент сейчас является одним из основных потребителей мобильного и стационарного трафиков. Не зря тот же Netflix и другие компании согласились принудительно снизить качество своего видео с 4К до 1080p, чтобы разгрузить сети европейских провайдеров на время пандемии коронавируса. Множество людей ушло в вынужденный простой, перегрузив сети потоковым видео, не давая возможности нормально работать удалённо всем остальным.

    Жутковатая олигополия


    CDN — несомненно, очень крутая технология. Проблема в том, что она требует больших капитальных затрат и закладывает потенциальную мину под будущее Всемирной паутины. По сути, если вы достаточно крупная компания, то вам почти неизбежно надо идти к кому-то из небольшого списка компаний. Крупнейшие сети:

    1. Cloudflare.
    2. Azure CDN.
    3. Amazon CloudFront.
    4. Akamai Technologies.
    5. Google Cloud CDN.

    В результате в случае программной ошибки на любом из них у вас попросту отвалится множество сервисов, которые хостятся на их мощностях, например, отказ Cloudflare в 2019 году. Они тогда залили кривое правило на Cloudflare Web Application Firewall и распространили его глобально. В итоге они получили стопроцентную нагрузку на свои ноды по CPU. Клиенты по всему миру на сотнях ресурсов в это время массово получали 502 ошибки (Bad Gateway). Из крупных ресурсов пострадали Discord, Reddit, Twitch и другие.

    Или можно вспомнить массовое падение кучи сервисов в России во время блокировок IP-адресов Amazon по распоряжению Роскомнадзора (перебои в работе Viber, некоторых платёжных систем, сервисов регистрации на авиарейсы, системы продажи электронных полисов ОСАГО, сети научных контактов ResearchGate, центрального репозитория библиотек Java, сайтов СколТеха, МГУ, Высшей школы экономики и других вузов, научных архивов, системы подачи заявок в РФФИ и других).

    Таким образом, теряется основное преимущество, сделавшее Интернет глобальным, — децентрализованность. Более того, есть ещё одна очень важная проблема. Зашифрованный мусор нельзя нормально кэшировать. Поэтому в большинстве реализаций вам придётся отдать CDN-провайдеру самое ценное — шифрование трафика между вами и клиентом. По сути, вы соглашаетесь на классический Man-in-the-middle с целью оптимизации доставки контента. Это создаёт дополнительные риски концентрации приватной информации пользователей в одних и тех же руках. Более подробно проблему олигополии мы раскрывали тут.

    Можно ли обойтись без CDN?


    Да, можно. Если ваша потенциальная аудитория находится в одном регионе и не будет страдать от большого пинга, то CDN вам не нужен. Что делать, если я хочу просто играть локально или обеспечить высокий пинг людям не в Москве?

    Можно ограничиться локальным сервером. Собственно, у нас часто берут VDS в Екатеринбурге, Новосибирске, Казани и Петербурге как раз для игровых серверов либо для проектов для локальных офисов. А VDS во Франкфурте, Лондоне или Амстердаме нужны тем, кто использует тех же трейдинговых ботов или что-то парсит: там ближе к биржам и источникам данных.

    Услуга игровых серверов локально для города настолько востребованная, что у нас уже есть возможность создавать тот же серверный клиент Майнкрафта сразу вместе с заказом нового сервера, уже предустановленный на свежую VPS-машину.

    Если на вашем сервере Minecraft стоит лимит в 30 игроков, то вы получите вполне прогнозируемый трафик между вами и клиентами. Более того, статическими данными в данном случае будут разве что кастомные текстуры, наборы плагинов со стороны сервера или что-то подобное. Всё остальное будет обрабатываться на стороне клиента.

    В зависимости от выбранного типа сервера вам потребуется развернуть на виртуальной машине либо полностью ванильную версию игры, либо, что более вероятно, использовать платформу, поддерживающую сторонние моды, например, Bukkit. На 30–50 игроков вам потребуется порядка 6 Гб оперативной памяти в зависимости от числа модов, которые вы навесите на свой сервер, и размеров карты. К CPU тоже предъявляются высокие требования. Из-за архитектуры игры вы сможете задействовать только одно ядро для вычислений, поэтому предпочтительнее высокая частота, нежели число ядер.

    И самое интересное — сеть. В целом довольно скромного канала в 10–20 Мегабит/с будет вполне достаточно. Гораздо критичнее сразу предусмотреть размещение игровых серверов как можно ближе к игрокам. Поверьте, крипер, который вас убивает через секунду после того, как вы успешно от него убежали, или проваливание сквозь блок из-за большой задержки гарантированно вызовет много нецензурной лексики со стороны игроков. Поэтому близкие к вашей аудитории сервера с низкими пингами — вполне себе альтернатива CDN в некоторых случаях. У нас, например, есть свободные мощности в Новосибирске и Казани с хорошей сетевой связностью.

    Итого


    Вам, скорее всего, не нужен CDN, если:

    1. У вас очень лёгкие данные и нет тяжёлого фото-/видеоконтента.
    2. Для ваших клиентов некритичны задержки в несколько дополнительных секунд при первом подключении.
    3. У вас не планируется резких пиковых нагрузок во время обновлений или распродаж.
    4. У вас ценные приватные данные, и вы не можете делегировать HTTPS-шифрование сторонним компаниям.

    Если же клиенты размазаны по всему миру, а контент тяжёлый, то придётся идти к кому-то вроде Cloudflare. Если вы очень крупная компания, а требования к безопасности высокие, то, возможно, вы так или иначе придёте к собственной частной сети CDN, чтобы не доверять сторонним компаниям своих данных.

    На что обратить внимание при переходе на CDN:

    1. География присутствия. У вашего вендора должны быть ноды в точках наибольшей концентрации ваших клиентов. Проанализируйте логи и свою аудиторию. Вы должны покрыть региональными узлами максимальный процент посетителей.
    2. Связность. Если провайдер CDN имеет узел в Москве, но гонит туда трафик странными петлями через Австралию, то это не решит ваших бизнес-проблем.
    3. Технологический стек. Убедитесь, что провайдер обеспечивает все нужные вам технологии работы с трафиком: HTTP/2, TLS 1.3, IPv6 и другие детали.
    4. Всегда выполняйте тщательное тестирование перед переводом промышленного трафика на новую инфраструктуру. Идеально, если у вас останется резервная схема для отката обратно на первое время: так вы сможете избежать неприятных сюрпризов.

    А если будет нужен мануал для организации CDN под Windows Server 2019 Core и IIS, то мы его уже подготовили.



    RUVDS.com
    RUVDS – хостинг VDS/VPS серверов

    Комментарии 30

      +21
      Правильно говорить не «жирным», а трафик-позитивным!
        +2
        Интересная статья, спасибо!
          +5
          Сайт с японской кухней — мои глаза!!! за что??? зачем я кликнул на эту ссылку?)))

          Спасибо за интересную статью! Как всегда очень познавательно!
            +1
            Зачем я кликнул на эту ссылку после прочтение вашего сообщения?)
              +1
              АААААААААААА!!! Да вы угараете??????!!!
            0
            Например, всем известный 8.8.8.8 от Google будет вести на ближайший узел, который чаще всего расположен во внутренней сети вашего провайдера. Это возможно благодаря правильному анонсированию сетей, по которому роутеры провайдера выбирают наиболее короткий маршрут.

            — такое делается еще и для фильтрации по DNS… (знаю несколько провайдеров, которые просто запросы к любым адресам по 53-порту заворачивают к себе и фильтруют)
              +1

              Это в принципе негодяи, на мой взгляд. Поэтому, от моей сети во внешнюю сеть никогда нет пакетов на 53 порту.

                0
                Необязательно. Я настроил все устройства ребенку на работу через OpenDNS с фильтрацией всего взрослого и токсичного трафика. Сам бы я ни за что не справился с безумным количеством black-листов.
                  0

                  Для этого у меня дома стоит pi-hole в качестве DNS. Режется вся телеметрия, трекеры, реклама и тому подобное. Все запросы от pi-hole уходят в туннель и приземляются за пределами провайдера, чтобы он не мог подменить запрос.

              +2
              Сейчас любой проект вынужден платить за услуги CDN немалые суммы сложившейся олигополии CDN-провайдеров, либо строить собственный CDN, договариваясь с каждым провайдером в мире.

              Интересно, почему до сих пор не додумались договориться и создать некий open source софт для создания открытого CDN, который любой интернет-провайдер мог поставить на своем железе, а любой сервис — использовать для отправки своего контента пользователям?

              Сервису достаточно было бы поднять несколько origin-серверов в разных точках мира, и интернет-провайдеры сами бы забирали с них контент посредством этого софта. Абоненты получали бы контент максимально близко к себе. По мере роста количества участвующих сервисов и провайдеров последние могли бы ставить такие сервера чуть ли не на районных и домовых узлах, существенно экономя трафик. А не как сейчас — на центральном узле сети стоит куча серверов разных CDN-провайдеров, а также гугл, и т.п.

              Также CDN-провайдеры стали бы практически не нужны. Неужели ни у кого нет заинтересованности в этом?
                0
                Не будет гарантий что этот софт работает как надо а не как кривые ручки провайдера его настроили (или возможно ручки не кривые а работающие в своих интересах)(например адаптировать картинки для уменьшения размера… по запросу пользователя или БЕЗ запроса пользователя или добавлять к картинкам полезную для пользователя информацию — например в habr.com/ru/post/489528 а если у нас видео тоже будет кэшироваться — это ж можно продавать и видеорекламу на чужих сайтах будет).
                Ну и — просто шикарная возможность делать MITM, ключи ж надо отдавать либо отказываться от https, если cloudflare доверить можно то всем провайдерам всех стран… а зачем тогда https?

                Cloudflare — доверяют потому что быть CDN это их основной бизнес и они заинтересованы эту работу делать качественно а зачем провайдеру это качественно делать?
                  –1
                  Провайдеры увидят только кучу непонятных файлов с длинными именами в виде хешей. Поди разбери что там внутри за картинки и другие медиа ресурсы, и с какого они сайта/сервиса/ресурса. А случае со стримингом аудио и видео всё это еще закриптовано DRM — и расшифровывается ключом, получаемым клиентом непосредственно от головного сервера.

                  Провайдер заинтересован это качественно делать по той же причине, по которой заинтересован качественно настраивать свои роутеры, сети и прочее оборудование. Ради удовлетворения потребностей пользователей, качественного доступа в интернет и снижения нагрузки на аплинки.
                  0
                  А разве CDN провайдеры не этим занимаются? Ну то есть договариваются с крупными провайдерами и ставят свои edge сервера по ближе к пользователям. С софтом проблем как раз нет, например взять nginx и salt (ansible, puppet, chef, ...) для управления nginx'ом на серверах не сложно. Мы же как раз и платим CDN провайдеру, за то, что у него есть куча серверов у крупных провайдеров, + автономные системы, и он этим всем управляет, мониторит, поддерживает, и т.д.

                  open source софт для создания открытого CDN, который любой интернет-провайдер мог поставить на своем железе


                  А кому будет принадлежать автономная система с блоками ip адресов и эти железки у провайдеров? Кто будет поддерживать их работу и управлять ими?
                    +1
                    Nginx, salt, и прочее — конечно было бы в основе всей системы. Плюс управляющая некая управляющая обвязка (первая часть софта, менее сложная). Главное чтобы провайдеру было это очень просто ставить, например как готовый образ.

                    Провайдеры ставили бы железки на своих собственных IP, в этом и суть. Так как внутри своей сети у них наилучшая связь со своими пользователями. И отдавали бы наружу список своих подсетей, которые они готовы обслужить. А вторая часть софта, работающая на ресурсах имеет у себя полную базу этих железок и их сетей, и умеет направлять своих пользователей непосредственно на ближайшую из них.
                    +1

                    Вообще говоря, тут и придумывать ничего не надо — достаточно простого, незащищенного HTTP и какого-нибудь прозрачного прокси.


                    Проблема подобной схемы в том, что интернет-провайдеры не хотят повышать качество своих услуг, они хотят вставлять на чужие сайты свои следилки и баннеры.

                      +1
                      Наверное по тому что «провайдеры» уже сейчас стремятся влезть в трафик между сервером и клиентом напихав в него свою рекламу.
                      Что будет когда они получат доступ непосредственно к контенту?
                      –1

                      Статья интересная, но для всех почти бесполезная. Крупные компании просто могут себе позволить изначально писать небольшие оптимизированные сайты, и раскошелиться на серверы, их загрузка не пострадает. Стартовая страница Apple занимает всего 1.8 мегабайта, из которых 800 Кб — высококачественные картинки, грузится за 1.2 сек без всяких облаков, я в Николаеве, юг Украины, сервер в Купертино, Калифорния, США, в среднем 10000 км.


                      Мелкие компании создают сайты на всяких Wordpress c Джумлами с кучей неоптимизированных SQL-запросов и динамических JS так, что даже на локалхосте стартовая страница генерится 5 сек. Учитывая любовь этих CMS-ок к генерации контента используя GET-запрос с timestamp — кэшированию это не подлежит, а значит без толку: без CDN клиент ждал 5 сек пока PHP-Wordpress сгенерит страницу, 1 сек пока это перешлется в браузер; с CDN клиент ждет 5 сек пока сгенерится контент, и пол-секунды пока это перешлется в браузер.


                      А самое интересное, что несведущие в этом постеры своих домашних котиков на Вордпрессе, читают такие статьи, и потом прибегают на фриланс, или еще хуже к своему штатному админу, рассказывая за 100%тную панацею от всего что только можно включая пузомерки GTmetrix и Google, и мы бедняги не знаем как сказать "мужик, выкинь свой бесплатный вордпресс и найми индуса, заодно на сервере сэкономишь".


                      Такие дела.

                        +3
                        Стартовая страница Apple занимает всего 1.8 мегабайта, из которых 800 Кб — высококачественные картинки, грузится за 1.2 сек без всяких облаков, я в Николаеве, юг Украины, сервер в Купертино, Калифорния, США, в среднем 10000 км.

                        А кэш попробовали почистить перед тем, как перейти на страницу?
                        Ну это явно не 1.8 мегабайта, первая загрузка после очистки кэша:

                        Пятая загрузка после очистки кэша:


                        с кучей неоптимизированных SQL-запросов

                        А каким боком тут неоптимизированные SQL-запросы?


                        динамических JS

                        Ну JS это как проблема для сети, так и для клиента.


                        что даже на локалхосте стартовая страница генерится 5 сек

                        Ну генерируя страница 5 сек, и что? Не пересылается же все это время.


                        используя GET-запрос с timestamp

                        Никогда такого не видел, но за такое руки явно нужно отрубить.


                        Статья рассказывает о проблемах с трафиком, а вы про генерацию контента.

                          +3
                          По существу.
                          Но только тот же 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.

                          Такие вот дела.
                            0
                            Мелкая компания обращается к Wordpress главным образом потому, что не имеет денег на покупку контента, покупку движка, покупку индуса и покупку сервера.
                              +2

                              Кешируется все прекрасно на стороне клиента. Ну да, диск кушается, за то второй раз взлетает моментально.
                              Кешируются и запросы в sql, а еще можно в памяти кешировать. Только это а) нужно уметь готовить и сочетать и б) стандартный WP хостинг такое не умеет и в) даже после этого сайты еще нудно оптимизировать перегенерацией css и js, выкорчевыванием лишнего с мест где ему не место и т.д. и т.п.
                              В целом мне удается сократить объемы на столько, что даже в фиговых условиях (джитеры, потери, малый канал) страницу можно прогрузить за 3 секунды. На хороших каналах она отдается что-то за 0,9.


                              И все это без CDN, на дохлой vps.


                              Но в целом идея CDN хороша, если у вас не часто обновляется контент. Тогда можно за вменяемые деньги получить результат "почти как у Apple", но на WP

                                +1
                                Использую CDN от Cloudflare на своём самописном сайте (движку уже лет 10), так он снимает 80% трафика от моего сервера, кэшируя стили, картинки и, вероятно, страницы.
                                0
                                Хорошая статья. +1.
                                Конечно в разделе «Кому выгоден CDN» можно было бы побольше про интересы рекламодателей написать, про отслеживание пользователей. Даже упомянуть браузерные решения типа decentraleyes…
                                  +1
                                  Почему не взлетел чистый multicast?

                                  Но мультикаст не отвечает современным требованиям к видео, он как прямой эфир, включил канал и получаешь то что получаешь, ни запаузить, ни отмотать назад.
                                  В то время как большниство видео смотрятся в записи
                                    0
                                    К CPU тоже предъявляются высокие требования. Из-за архитектуры игры вы сможете задействовать только одно ядро для вычислений, поэтому предпочтительнее высокая частота, нежели число ядер.

                                    Немного офтоп, но все же спрошу. Майнкрафт до сих пор не поддерживает многоядерность? Играл 10 лет тому и конечно вопросы про производительность в основном сводились к шуткам про Java. В то время еще как-то не думалось про большое количество ядер в CPU.
                                    Но за это время и наличие таких денег можно было полностью переписать архитектуру, чтобы улучшить производительность и все такое.
                                      0

                                      Там все без изменений)

                                      +1
                                      1. в начале статьи Вы написали что причина существования CDN — не настроенный мультикаст на промежуточных серверах. А если мультикаст нормально настроен на пути от сервера допустим vk.com к клиенту + vk.com — заплатил за CDN — то трафик как пойдет? Через мультикаст или CDN?
                                      2. допустим компания не хочет давать CDN провайдерам свои ключи от HTTPS. Может ли она сама арендовать 5 VPS в США, КНР, Сингапуре, ЕС, Австралии и РФ (или просто по РФ если только российская компания) и сама сделать свой маленький CDN на squid, ngnix или чем то подобном
                                      3. А если требуется CDN только по РФ — отечественные поставщики услуг CDN имеются корме мегафона или Селектела? или крупные российские провайдеры обеспечивают CDN по России сами?
                                        +1
                                        1. Через CDN. Потому что все URL уже нацелены на адреса провайдера CDN — см. краткий мануал выше. Плюс, как уже заметили, multicast — это по сути телевизор. Он применим тогда, когда многим пользователям одновременно нужно одно и то же. Например, трансляция матча в реальном времени. Если же у вас 794 пользователя смотрят одну и ту же серию Altered Carbon, но на разных моментах, то multicast тут бесполезен. Браузеру пользователя, который только что включил серию, не нужен пакет от середины, которую запросил другой.

                                        Хотя, если присмотреться, то вариант доставки разных кусков одного и того же фильма сильно напоминает механизм работы торрента. Только в данном случае пир будет только один — источник контента с multicast. К сожалению, обычный браузер так не умеет, хотя, насколько я помню, Firefox что-то подобное тестировал.

                                        2. Да, может. Я упоминал об этом, когда говорил о частных CDN. Но обычно это делают только крупные компании. Сложно и недешево.

                                        3. А что касается российских CDN-провайдеров, то тут мы почти не пересекаемся. У нас часто берут железо в ЦОДах в конкретном городе, да. Но чтобы обеспечивать сеть — тут не проконсультируем.
                                          –1
                                          Голосовать не могу поэтому просто Спасибо!
                                        0

                                        Интересно как это саиту Texas Internet Consulting удалось стать онлаин до появления веба (1989)…

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое