Лучшие CDN для работы в России и в мире: сравнительный обзор
Введение
Сети доставки контента (CDN) в наши дни получили широкое распространение. Это вполне понятно: растёт число интернет-сервисов с глобальной аудиторией, и почти все такие сервисы так или иначе связаны с доставкой тяжелого (фото-, аудио-, видео- и не только) контента.
Число пользователей Интернета, в особенности — мобильного, растёт с каждым днём, и создатели сайтов и приложений вполне закономерно задумываются об обеспечении быстрой работы в любой точке мира. Спрос рождает предложение — и количество компаний, предлагающих услуги CDN, тоже постоянно растёт. Достаточно набрать в Гугле соответствующий запрос — и в поисковой выдаче будет представлено огромное количество рекламных объявлений.
Как выбрать действительно качественного провайдера CDN? На что обратить внимание в первую очередь?
Эти вопросы мы подробно разберём ниже. План нашего изложения будет таким: сначала мы попытаемся сформулировать критерии выбора, а затем на основе этих критериев сравним наиболее популярных провайдеров.
Критерии выбора
Попробуем вывести какие-то более или менее универсальные критерии выбора CDN.
Первый и наиболее очевидный критерий — это число точек присутствия в разных регионах. Чем больше точек присутствия в разных регионах мира, тем выше скорость и шире возможности для доставки контента.
Второй критерий — это количество стыков с операторами связи. Чем больше стыков, тем меньше время отклика. Обычно такую информацию провайдеры CDN не публикуют, и всё можно узнать только с помощью тестирования. Здесь же обратим внимание на количество партнёров по пирингу — чем их больше, тем выше скорость доставки контента.
Третий критерий — это поддержка технологий и протоколов (HTTP/2, IPv6, сертификаты SSL и другие). Обычно современные CDN всё это поддерживают, но возможны нюансы, особенно если речь идёт о небольших провайдерах.
Четвёртый критерий — это наличие дополнительных услуг и функций (наличие REST API, плагинов для сайтов и мобильных решений, предоставление «сырых» логов, анализ статистики потребления и др.).
Пятый критерий — это наличие техподдержки (в том числе и на русском языке), а также качество документации и обучающих материалов (на разных языках, включая русский).
Кого мы будем сравнивать, или Мини-рейтинг провайдеров CDN
Выбор провайдеров для сравнения — тоже не самая простая задача: предложение, как уже было сказано выше, очень большое. При выборе мы обращали внимание на следующее:
В первую четвёрку у нас вошли провайдеры, которые уже прочно заняли место на глобальном рынке:
В следующую группу мы выделили российских провайдеров CDN, которые достаточно успешны на российском рынке и имеют шансы на дальнейший рост, в том числе и в международном масштабе:
Точки присутствия
Сравнительный анализ операторов CDN мы начнём с самого очевидного и важного критерия: количества и расположения точек присутствия. Результаты анализа мы оформили в виде таблицы (под Россию и СНГ выделены отдельные графы):
| Провайдер | Россия | Страны СНГ | Европа | Азия | Африка | Северная Америка | Южная Америка | Австралия и Океания |
|---|---|---|---|---|---|---|---|---|
| Akamai | >20 | >20 | 40 | 58 | 24 | 46 | 39 | 15 |
| G-Core Labs | 22 | >20 | 31 | 23 | 5 | 14 | 9 | 2 |
| CloudFront | нет | >20 | 63 | 57 | 7 | 37 | 3 | 9 |
| Cloudflare | 2 | >20 | 46 | 65 | 15 | 46 | 23 | 8 |
| Ngenix | 24 | 3 | 1 | нет | нет | нет | нет | нет |
| CDNVideo | 18 | 10 | 16 | 33 | 5 | 11 | нет | 4 |
| KeyCDN | нет | нет | 16 | 9 | 2 | 10 | 4 | 5 |
| Fastly | нет | нет | 14 | >20 | 2 | >20 | 6 | 6 |
| CDN77 | нет | нет | 10 | 14 | нет | 6 | 3 | 1 |
Вся информация взята в с официальных сайтов компаний и карт точек присутствия, опубликованных в открытом доступе.
Все цифры актуальны на момент написания статьи (начало мая 2021 года); следует учитывать, что все операторы CDN редко публикуют списки абсолютно всех точек присутствия во всех городах и постоянно вводят в эксплуатацию новые точки присутствия. Информация о планируемых точках присутствия, которую предоставляют некоторые провайдеры на официальных сайтах, в таблицу включалась.
На основе простого количественного анализа даже этой информации можно сделать интересные выводы.
Вывод первый: далеко не все крупные международные операторы СDN имеют точки присутствия в России; почти никто на официальных сайтах не публикует информации даже о планах открытия новых точек. Конечно, владельцам проектов, ориентированных на конкретные страны и континенты, услуги Akamai или CloudFront могут быть очень полезными и нужными. Но проектам, у которых значительная часть аудитории находится в России и СНГ, эти компании помогут далеко не всегда.
Вывод второй: даже поверхностного взгляда на карты и таблицы достаточно, чтобы убедиться: в современном мире одним из самых перспективных и растущих рынков являются страны Азии. Проектам, планирующим крупную международную экспансию, явно не будет лишним оценить степень покрытия в азиатском и тихоокеанском регионе.
Вывод третий: существуют CDN, ориентированные сугубо на российскую аудиторию (и это неплохо). При выборе CDN, однако, следует учитывать одно важное обстоятельство: Россия большая, и новые пользователи интернет-сервисов приходят в первую очередь из регионов. Поэтому при выборе CDN нужно внимательно смотреть на географическую карту и обращать внимание на точки присутствия не только в столицах, но и в других городах (в особенности за Уралом).
Из всех этих выводов вытекает ещё один: для проектов, ориентированных одновременно на российскую и зарубежную аудиторию, наибольший интерес представляют G-Core Labs и Akamai: точки присутствия имеются на всех континентах, а в России оба провайдера представлены не только в столицах, но и в регионах.
Количество стыков с операторами связи
Этот параметр очень важен (выше уже было сказано, почему). Одновременно этот параметр оказался чуть ли не самым сложным для анализа: очень сложно найти подходящую информацию. Но при желании найти её можно. Во-первых, можно (и нужно) обращаться к официальным сайтам компаний: там, например, опубликована информация о количестве партнёров по пирингу.
По количеству партнёров лидируют Akamai, CloudFlare, Cloudfront и G-Core Labs. У каждой из этих компаний — более 5000 партнёров. У остальных участников обзора — от 1000 до 2000.
Во-вторых, все компании, отобранные нами для обзора, вполне можно «пробить» с помощью сервиса PeeringDB. Там можно найти, к каким точкам обмена трафиком подключена та или иная компания и где установлено её пиринговое оборудование.
Информация о количестве точек обмена трафиком, к которым подключены участники нашего обзора, приведена в следующей таблице:
| Провайдер | Число IXP | Число партнёров по пирингу |
|---|---|---|
| Akamai | 333 | 1700 |
| G-Core Labs | 157 | >5000 |
| CloudFront | 343 | нет данных |
| Cloudflare | 411 | >5000 |
| Ngenix | 25 | >1000 |
| CDNVideo | 40 | >1000 |
| KeyCDN | не найдено | нет данных |
| Fastly | 245 | >1000 |
| CDN77 | 56 | нет |
Тесты на скорость
Попробуем теперь сравнить время отклика по России для всех участников нашего обзора. Для оценки времени отклика мы пользовались аналитическим сервисом Citrix. Он собирает данные от пользователей со всего мира и на их основе высчитывает усреднённое время отклика. На основе этих данных, собранных за определённый период времени, он составляет графики. Вот так выглядит график за последние 30 дней (при оценке ориентируемся на медианное значение, т.е. 50-ю перцентиль):
Посмотрим теперь по графикам время отклика не только в России, но и в других странах и на других континентах.
Что такое CDN, и как это вообще работает
Сайт Texas Internet Consulting. Жив с 1987 года, страница — 7 Килобайт.
Помните время, когда главная больше 90 Килобайт считалась расточительством? С тех пор Интернет стал жирным. И понадобились инструменты, чтобы правильно раздавать трафик сразу с нескольких узлов. Например, во время очередного обновления Fortnite CDN от Akamai сумел переварить трафик мощностью в 106 Терабит в секунду. Давайте пробежимся по основным принципам этой технологии и потенциальным проблемам.
И о том, почему Minecraft в Казани тормозит, если не развернуть сервер в черте города.
Вот современный сайт, который соблюдает разумные рамки: 1,7 Мегабайта.
Пример относительно тяжёлого сайта с видеоконтентом и анимацией: 39,5 Мегабайта радости и шевеления.
Сейчас, когда 100 Мегабит домашнего Интернета воспринимаются вполне привычно, всё меньше дизайнеров заморачивается с кропотливым сжатием каждого изображения и экономии на мелочах. Ситуации, когда кто-то умный положил на главную картинку в PNG весом в 30 Мегабайт, бывают чаще, чем хотелось бы.
Исторические данные взяты здесь.
А если посмотреть на статистику, то тенденция к росту объёмов становится ещё более очевидной. Например, за 10 лет размеры средней страницы, рассчитанной на мобильные устройства, выросли в семь раз (с 233 до 1 864 Килобайт).
Проблема ширины канала
У вас есть много иллюстраций и видео, которые надо доставить клиенту. Передать однократно несколько Мегабайт не очень трудно: современные каналы связи позволяют делать это за секунды. Всё становится гораздо хуже, когда к вам на сайт одновременно заходят вначале несколько десятков, а потом — тысяч посетителей.
Давайте считать. Допустим, у вас один-единственный сервер и у вас типичная страница весом в 1,8 Мегабайта. Клиенты приходят к вам впервые и с «холодным» кэшем, то есть в браузере нет ранее загруженных материалов с вашего ресурса.
Чтобы отдать за приемлемые три секунды страницу, нам потребуется ширина канала в 4,8 Мегабита на одного посетителя. Если их придет 100, то это уже 480 Мегабит. А если вдруг потребуется отдать тем же людям небольшой видеофайл размером 10 Мегабайт, то нам потребуется канал в 2,7 Гигабита.
Таким образом, у вас появляется два основных типа контента: динамический и статический.
Статический контент, как следует из названия, не изменяется или меняется крайне редко. Например, это логотип веб-сайта. Или залитые образы с дистрибутивами ПО.
Динамический контент отличается тем, что он генерируется сервером «на лету». Обычно это происходит в момент самого запроса. Например, при клике на кнопку формируется плей-лист, уникальный для конкретного пользователя.
Именно для решения проблемы кэширования статического контента и были созданы CDN. Но, как мы увидим дальше, и с динамическим контентом CDN тоже могут помочь.
Почему не взлетел чистый multicast?
Схема работы multicast.
Мультикаст очень хорош. В отличие от юникаста он позволяет исходному серверу бросить в сторону клиентов только один пакет, который будет ретранслирован строго тем, кто его ожидает. В отличие от броадкаста не будет слать пакеты всем кому надо и не надо, засоряя Сеть мусором.
Одна проблема — поддержка оборудованием. Для того чтобы гарантировать, что multicast-пакет доедет до каждого клиента, нам нужно убедиться, что каждый промежуточный узел правильно сконфигурирован и готов доставить его дальше. В противном случае пакет «угаснет» где-то по дороге на тупом маршрутизаторе, а клиент не дождётся своей вечерней трансляции на YouTube. Именно поэтому вместо более продвинутого мультикаста взлетела географически распределённая сеть CDN, которая работает на более простом unicast.
Вторая проблема — 4K и грядущий 8K. Провайдеры уже нервно вздрагивают от объёмов трафика, а будет только хуже. В варианте чистого мультикаста вы не можете регулировать качество вещания. В случае того же Google Global Cache в качестве CDN вы можете отдавать локальным клиентам картинку в адаптивном битрейте. GGC закэшировал некоторый кусок видео и кормит своих клиентов в 4K. В этот момент у одного из клиентов возникают проблемы из-за перегрузки локальной сети. GGC автоматически снизит битрейт с учётом изменившейся ширины канала клиента и продолжит раздавать ролик.
Тем не менее технология очень привлекательна для IPTV, поэтому некоторые компании предлагают такие интересные решения, как nanoCDN Multicast ABR. Концепция строится на добавлении в сеть провайдера дополнительного узла-транскастера, который преобразует unicast от источника видео за пределами сети в multicast до конечного потребителя.
Мир без CDN
Итак, мы определились с тем, что нам потребуется очень много ресурсов для того, чтобы обслуживать всех посетителей из единой точки. Давайте попробуем представить, как выглядел бы современный веб без CDN. Каждая компания строит себе один огромный дата-центр и собирает все ресурсы в одной-единственной точке мира.
Централизованная раздача контента и распределённая схема через CDN.
Небольшие веб-ресурсы
Почти не пострадают. Даже сейчас есть множество местечковых форумов, посвящённых узкой тематике разведения, ну, например, алтайских перепелов. Там почти никогда не бывает огромного наплыва посетителей, почти нет тяжёлого контента. Они как жили в начале нулевых, так и продолжают в 2020 году, принося ценность своему небольшому сообществу.
Видеохостинг
Забудьте. Никакого YouTube, Vimeo и других ресурсов без CDN не будет (важно: торрент-сеть, по сути, тоже можно считать подвидом CDN в такой ситуации, но работающей по совершенно иным принципам).
Без CDN можете смело возвращаться в начало нулевых, когда видео было доступно по прямым ссылкам и его нужно было качать. Никакого стриминга, FlashGet и прочих хардкорных менеджеров загрузки. Причём речи о скачивании в реальном времени даже и близко не было бы. Уже сейчас, если верить статистике, один только YouTube генерирует 37 % всего мобильного трафика в мире. Это миллиард часов видео в сутки. Без географического распределения нагрузки подобные сервисы просто не родились бы.
Именно поэтому тот же 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-сервер, отвечающий за адаптацию контента:
5. Правильно отдаём картинки, Image CDN
CDN — это намного больше, чем просто тупой кэш для файлов. Хороший пример — правильная работа с изображениями. Обычный CDN общего назначения не обращает внимания на особенности клиента, который к нему обратился. Попросили отдать картинку — он её отдаст, неважно, запросил её Samsung Galaxy, iPad или PC с 8К-дисплеем. Правильный Image CDN отдаст картинку в нужном формате, сжав её под размеры дисплея клиента. Тем самым экономится большое количество трафика и ускоряется загрузка страниц на тех устройствах, которым не нужна графика в огромном разрешении.
6. Делаем ещё кучу нужных вещей
Помимо доставки контента, узлы CDN могут обеспечивать терминирование HTTPS-трафика, WAF (Web Application Firewall), защиту от DDoS и кучу других задач.
Что нужно для подключения к 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 — несомненно, очень крутая технология. Проблема в том, что она требует больших капитальных затрат и закладывает потенциальную мину под будущее Всемирной паутины. По сути, если вы достаточно крупная компания, то вам почти неизбежно надо идти к кому-то из небольшого списка компаний. Крупнейшие сети:
Или можно вспомнить массовое падение кучи сервисов в России во время блокировок 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, если:
На что обратить внимание при переходе на CDN:
