для чего нужен cdn
Что такое CDN и нужен ли он вашему сайту
Скорость загрузки контента — показатель, который влияет на лояльность пользователей и позицию сайта в поисковых системах. Согласно информации Google, медленная скорость загрузки увеличивает число отказов (уходов пользователей). Так, если страница загружается 6 секунд, оно достигает 106%.
Чтобы сайты с большим количеством данных открывались быстрее, используют технологию CDN. В статье расскажем, в каких ситуациях нужен CDN-хостинг и какие проблемы он помогает решить.
Что такое CDN и как это работает
Как устроена передача данных на обычном хостинге:
CDN-хостинг (Content Delivery Network) добавляет в это простое уравнение ещё один компонент — серверы, на которых кешируется часть контента или страница целиком. Они находятся между сервером и конечным пользователем, хранят информацию разных сайтов для быстрой загрузки и передают её друг другу.
CDN-хостинг предоставляют провайдеры. Они размещают сеть взаимосвязанных кеширующих CDN-серверов в разных точках мира. За счёт этого расстояние между клиентами и основным сервером не влияет на скорость передачи данных. Сайты, которые используют CDN-хостинг, загружаются быстрее.
Рассмотрим, в решении каких задач помогает CDN-хостинг.
1. Увеличивает скорость загрузки сайта
Предположим, у вашего проекта большая аудитория, и на сайт заходят люди из разных стран. Если все файлы хранятся на одном сервере, который расположен, например, в Польше, скорость загрузки сайта будет отличаться по мере удалённости от сервера. Те, кто живут поблизости (жители Белоруссии, Украины), будут получать контент с хорошей скоростью.
Но если посетитель живёт на Дальнем Востоке: в Хабаровске (7 202 км от Польши), на Камчатке (7 459 км от Польши) или на Сахалине (7 521 км от Польши), он будет долго ждать загрузки контента.
Чтобы скорость загрузки не зависела от географии пользователей, выбирают CDN-хостинг. В этом случае запросы пользователей, удалённых от основного сервера, будут автоматически переадресованы к ближайшему CDN-серверу (например, в Магадане), и проблем со скоростью не возникнет.
2. Разгружает основной сервер
Сейчас сайты состоят из статического и динамического контента. К статическому относится содержимое страницы, которое не меняется: тексты, картинки, видео- и аудиофайлы, скрипты. Это «тяжёлый» контент, который должен быстро загружаться у пользователей. К динамическому относятся файлы, которые отображаются по-разному у разных пользователей. Например, местоположение, пол, блок рекомендаций, история просмотра.
Динамический и статический контент создают разную нагрузку на сервер. Первый задействует оперативную память, а второй зависит от скорости сети. Если оба типа контента хранятся на одном сервере, это создаёт на него двойную нагрузку, поэтому страницы могут загружаться дольше.
Решить эту проблему помогает CDN-хостинг. Часть сайта (статический контент) передаётся на серверы из CDN-сетей, а динамический контент остаётся на основном сервере. Таким образом, нагрузка распределяется, и страницы загружаются быстрее.
3. Повышает безопасность
Если вы храните данные только на одном сервере, это делает ваш сайт менее устойчивым к кибератакам, например, к DDoS (Distributed Denial of Service). В этом случае злоумышленники будут бомбардировать сервер массой запросов/обращений, чтобы вызвать перебои в его работе. Когда сервер «ляжет», сайт будет недоступен.
При использовании CDN-хостинга запросы к вашему сайту будут обрабатывать сразу несколько серверов в зависимости от месторасположения «клиентов». Это значит, что нагрузка распределится равномерно, и сайт продолжит работу, несмотря на попытки снизить производительность ресурса.
Каким сайтам нужен CDN
Разумеется, далеко не всем сайтам требуется CDN-хостинг. В частности, проблем со скоростью загрузки контента может не быть на сайтах с небольшим количеством статического содержимого или интернет-магазинах, которые ориентируются на локальную аудиторию (город или область).
Если проблемы со скоростью загрузки сайта всё-таки есть, попробуйте решить их с помощью программистов:
Грамотно настроив код и сервер, вы сократите время загрузки сайта. Это решение не требует регулярных затрат, в отличие от CDN-хостинга.
Если вы уверены, что проблема со скоростью загрузки вызвана большим спросом, а не проблемами с кодом сайта, обратитесь к CDN-провайдерам.
Кому не обойтись без CDN:
Как используют CDN
Рассмотрим, как используют CDN-хостинг реальные компании. Например, интернет-магазин Ozon хранит на CDN-серверах статический контент (все изображения, шрифты, js-скрипты), поэтому в URL-адресах этих объектов фигурирует аббревиатура сервера:
Магазин техники «М.Видео» также использует CDN-хостинг. В отличие от Ozon, его файлы содержатся на нескольких серверах, поэтому один и тот же контент доступен по разным адресам. Например:
Популярные CDN-провайдеры
На CDN-хостинге специализируются многие компании. Мы расскажем о четырёх наиболее популярных.
CDNvideo — провайдер услуг в России и СНГ. Узлы сети (CDN-серверы) установлены в 20 городах РФ, на Украине, в Казахстане, Молдавии, Германии, Нидерландах, США и других странах. Согласно исследованию iKS-Consulting «Облачный провайдинг 2018–2022: экономика, стратегия, бизнес-модели» от 2019 года, компания заняла первое место на рынке CDN-провайдеров с долей 38,6%.
Cloudflare CDN — сеть, которая охватывает 200 городов в 100 странах. Другой важный момент: серверы обрабатывают не только статический, но и динамический контент. Ещё и базовые функции предоставляются бесплатно.
selectel.ru — российский CDN-провайдер. Вы платите за количество ТБ: чем больше трафик на серверы, тем меньше стоимость одного Гб. Компания предоставляет свои серверы и CDN зарубежного партнёра, Akamai. Вторые стоят дороже, отличаются высокой пропускной способностью и большим количеством точек присутствия.
Amazon Cloudfront — 216 точек присутствия. Подходит для кеширования статических и динамических файлов, прямой трансляции видео. Сервис бесплатный первый год и за счёт медийности компании сотрудничает с известными брендами (Canon, Slack и др.).
Клиенты RU-CENTER, которые приобрели или собираются купить лицензию 1C-Битрикс, могут подключить CDN-модуль автоматически и пользоваться им бесплатно. Подробности вы можете узнать из описания 1С-Битрикс.
Подытожим
Если ваш сайт рассчитан на широкую аудиторию и/или содержит большое количество контента (много товаров, видео, аудио и т. п.), то пользователи могут ждать загрузки дольше обычного. Чтобы сократить скорость загрузки, попробуйте исправить ошибки в коде и настройках сервера. Если это не решило проблему, воспользуйтесь CDN-хостингом.
CDN-хостинг позволяет кешировать часть контента (или страницы целиком) и быстрее загружать её для пользователей вне зависимости от их географического положения. Используя CDN-сеть, вы повысите скорость загрузки сайта, а значит — угодите пользователям и поднимитесь в поисковой выдаче.
Как выбрать CDN для доставки динамического контента и не облажаться: 8 условий и must-have технологий
Обычно с помощью CDN ускоряют доставку статического контента. Спрашивается, почему бы не использовать сеть и для динамических приложений? Проблема в том, что для этого подходит далеко не каждая CDN. Как выбрать среди них правильную и на какие технологии обращать внимание — в нашем обзоре.
CDN заставляет веб-ресурсы работать быстрее главным образом за счёт кеширования. Со статическим контентом всё просто: он сохраняется на ближайших к пользователям кеш-серверах, и следующие запросы уже не идут к источнику, а забирают информацию с ближайших точек присутствия.
С динамическим контентом всё сложней, так как он уникален для каждого пользователя и его нельзя кешировать. Значит, и ускорить доставку не получится? Получится: если CDN отвечает ряду критериев, то она справится и с ускорением динамики.
1. Отличная связность
Быстрая доставка контента во многом зависит от связности сети. Чем больше у CDN пиринг-партнёров, тем лучше связность и тем более короткий маршрут от источника до пользователя может быть построен. А чем короче маршрут, тем быстрее данные будут доставлены. На это обязательно нужно обращать внимание при выборе сети доставки контента, идёт речь о статике или динамике.
2. Поддержка HTTP/2
HTTP/2 — это последняя версия протокола HTTP. Использование этой версии во многом помогает ускорить отдачу контента — главным образом за счёт мультиплексирования, то есть передачи нескольких потоков данных по одному каналу.
Чтобы отправить информацию, HTTP сначала должен установить TCP-соединение. Для этого требуется «тройное рукопожатие»:
Отправитель посылает запрос на установку соединения — сообщение SYN и порядковый номер переданного байта.
Получатель в ответ посылает сообщение SYN, подтверждает получение данных сообщением ACK и отправляет номер байта, который должен быть получен следующим.
Отправитель тоже подтверждает, что получил информацию, и посылает номер следующего ожидаемого байта.
После этих трёх шагов соединение считается установленным.
В предыдущих версиях HTTP для передачи каждого элемента (JаvaScript, CSS, изображений и других данных) открывалось отдельное TCP-соединение. «Тройное рукопожатие» нужно было проводить каждый раз, и это сильно замедляло доставку.
В HTTP/2 для всех этих данных устанавливается единое TCP-соединение. При этом разные типы информации могут отдаваться параллельно. Это значительно экономит время на передачу контента.
HTTP/2 помогает ускорить доставку и по другим причинам:
Это бинарный протокол. Использование бинарного формата вместо текстового значительно облегчает выполнение команд. В таких протоколах меньше ошибок, меньше нагрузка на сеть и, как следствие, меньше задержек.
Умеет сжимать заголовки. Заголовок — это тоже данные. А чем больше данных передаётся, тем медленнее они доходят до пользователя. HTTP/2 сжимает заголовки по алгоритму Хаффмана и опускает повторяющиеся.
Доступна приоритезация запросов. Определённую информацию можно назначить приоритетной — тогда она будут отдаваться в самом начале и загружаться быстрее. В первом приоритете можно отдавать самые важные элементы страницы, которые должны отобразиться у пользователя в первую очередь.
Есть функция Server Push. Она позволяет предугадывать, какие данные понадобятся клиенту, и отправлять их ещё до того, как поступил запрос. Это ускоряет загрузку, снижает количество запросов, а значит, уменьшает нагрузку на источник.
Мы заботимся не только о скорости доставки, но и о безопасности. Поэтому в G-Core Labs CDN есть функция принудительного редиректа на HTTPS. Это значит, что даже если передача по HTTPS не настроена на источнике, вы всё равно можете доставлять контент безопасно. Благодаря использованию HTTP/2 и TLS 1.3 безопасное подключение не будет замедлять отдачу контента, а то есть приложение будет работать быстро и безопасно.
3. Поддержка WebSocket
WebSocket — это независимый протокол на основе TCP. Он даёт возможность обмениваться сообщениями между клиентом и сервером в режиме реального времени.
Его принципиальное отличие от HTTP в том, что для получения информации клиенту не нужно каждый раз посылать запрос на сервер.
Возьмём для примера чат. Чтобы клиент узнал, что ему пришло новое сообщение, браузер должен периодически отправлять запросы на сервер и узнавать, нет ли новой информации.
Минусы такого подхода:
Увеличивается количество запросов к серверу. Из-за этого растёт нагрузка и падает скорость обработки запросов.
Данные обновляются медленнее. Так как браузер посылает запросы с определённой периодичностью, передать новое сообщение клиенту он может не сразу. Это создаёт задержки при доставке контента.
WebSocket же устанавливает постоянное соединение. И когда появится новое сообщение, сервер сразу отправит его клиенту.
Это сокращает количество запросов и увеличивает скорость отдачи данных.
Если вы хотите быстро доставлять часто меняющийся динамический контент (сообщения в чатах, push-уведомления и любые другие данные, которые постоянно обновляются на сайте), без WebSocket не обойтись.
4. Использование IPV6
IPv6 — более современная версия протокола IP. Он был разработан главным образом для того, чтобы решить проблему нехватки IP-адресов. Если в IPv4 для создания адреса используется 32-битная система, то в IPv6 — 128-битная.
Адрес IPv6 — это восемь 16-битных блоков, разделённых двоеточием. И общее количество IP-адресов, которые можно создать, составляет 2128 — это более 300 млн адресов на каждого жителя планеты. Такого количества должно хватить каждому устройству.
Но, кроме записи IP-адресов, в обновлённую версию протокола внесли и другие изменения, сделав его более эффективным для передачи информации.
Меньшая нагрузка на сетевое оборудование. Эта версия протокола не использует NAT — технологию для преобразования приватных адресов в публичные.
NAT был нужен в IPv4, так как там существовала проблема нехватки адресов. Внутри локальной сети у каждого устройства был приватный IP-адрес, который использовался для локальной передачи данных, например между устройствами внутри одной компании. Но для взаимодействия с другими ресурсами через глобальный интернет нужен был публичный, общедоступный адрес.
NAT преобразовывал приватный адрес в публичный — этот процесс называется трансляцией. При этом нужно было не только преобразовывать адреса, но и хранить информацию об установленных соединениях. Это увеличивало нагрузку на оборудование, и во время пиковых скачков трафика скорость падала. В IPv6 нет необходимости в трансляции, не нужно хранить информацию о соединениях, а значит, нагрузка на оборудование меньше и скорость остаётся стабильной.
Более простые заголовки пакетов. В новой версии из них убрали несущественные элементы. Это упростило обработку, снизило нагрузку на маршрутизаторы и в целом сократило объём передаваемых данных.
Более быстрая маршрутизация. Структура адреса IPv6 устроена так, что маршрутизаторы на каждом уровне сети (крупные провайдеры, подсети, сети организаций) обрабатывают не весь адрес, а его часть. Это уменьшает размер таблицы маршрутизации, а значит, сокращает время на обработку.
Определяет чувствительные к задержкам пакеты и передаёт их в первую очередь. Такую возможность даёт функция QoS (Quality of Service). Это специальная технология, которая умеет определять тип трафика и приоритизировать его на основании этого.
Получается, IPv6 во многом более эффективен, чем IPv4, и передаёт данные быстрее. Чтобы перейти на него, нужно серьёзно модернизировать свою инфраструктуру. Но если вы подключены к нашей CDN, то в этом нет необходимости. Мы используем IPv6 при доставке, даже если ваше оборудование ещё не обновлено до этого протокола. Таким образом, динамический контент доставляется быстро, а вы не тратите ресурсы на апгрейд.
5. Сжатие на лету
Чем меньше весит контент, тем быстрее он будет доставлен пользователям. Но жертвовать важными элементами в угоду размеру — не лучшая идея. Эту проблему решает использование современных алгоритмов сжатия: Gzip, Brotli и WebP.
Gzip предназначен для сжатия текстового контента. Он находит в файлах одинаковые строки и объединяет их. За счёт этого размер данных уменьшается на 60–70%.
Brotli уменьшает размер любого контента. Для сжатия он использует уже встроенный в браузеры пользователей словарь из более чем 100 000 самых часто встречающихся в интернете элементов. Алгоритм находит эти элементы в передаваемых данных, вычисляет уникальные фрагменты и передаёт только их, а неуникальные добавляет из словаря. Brotli на 20–25% эффективнее Gzip.
WebP — новый алгоритм для сжатия изображений. Он на 26% лучше PNG сжимает изображения без потерь и на 25–34% эффективнее JPG при сжатии изображений с потерями.
Главное преимущество этих алгоритмов в том, что они умеют сжимать файлы на лету, то есть прямо в процессе доставки пользователям.
6. Гибкие настройки кеширования
Не весь динамический контент нельзя кешировать. Некоторые данные можно сохранять на короткий срок, и они не потеряют свою актуальность для пользователей. Однако, для этого важно настроить кеширование точно в соответствии с особенностями вашего веб-ресурса. Поэтому выбирать нужно ту CDN, которая позволяет установить любое время кеширования либо отключить его совсем. Не лишней будет и опция очистки кеша — полная или выборочная, для одного файла или для группы.
7. Функции аутентификации на стороне провайдера
Если вам нужно предоставлять ограниченный доступ к контенту, вы можете перенести функции аутентификации на CDN. Это позволит избавить сервер от дополнительной нагрузки, а значит, и увеличить скорость. В нашей CDN для этого доступна опция Secure Token. Она позволяет создавать временные ссылки, которые содержат специальный хеш-ключ, и контент получается загрузить только по запросам, содержащим этот ключ.
Это защищает данные от нежелательных загрузок, помогает исключить нелегальные подключения и копирование. Доступ к ресурсу получают только те, кто имеет на это право, а проверка личности осуществляется с помощью CDN, что избавляет сервер от лишней нагрузки.
8. Облачное объектное хранилище
Контент важно не только эффективно доставлять, но и хранить. Возьмём, например, интернет-магазин. Чтобы отобразить покупателю индивидуальную подборку рекомендуемых товаров, вместе с остальными данными нужно загрузить и фото товаров. Для хранения такого контента требуются большие объёмы памяти. А при запросе клиента нужно быстро извлечь нужные файлы, сформировать ответ и отдать в нужном виде.
Хранение контента — это большая нагрузка и крупные затраты на вычислительные мощности. Поэтому эффективнее будет не размещать файлы на своих серверах, а арендовать облачное объектное хранилище.
В отличие от других типов, в объектных хранилищах нет иерархии — файлы извлекаются напрямую, за счёт чего сокращается время на их отдачу.
Как это относится к CDN? У G-Core Labs есть объектное хранилище, в которое можно поместить данные практически любого объёма, максимально быстро извлекать и доставлять их. Хранилище оптимизировано под работу с динамическими веб-ресурсами. Подключить его можно вместе с CDN и управлять ими через единую панель.
Подведём итоги
Есть мнение, что CDN может ускорить доставку только статического контента и плохо работает с динамикой. Но на самом деле, если сеть поддерживает определённые функции, она отлично справится и с ускорением динамики.
Чтобы CDN могла построить лучший маршрут для доставки данных, у неё должно быть отличная связность. У G-Core Labs CDN больше 6 000 пиринг-партнёров, поэтому она позволяет передавать данные максимально быстро.
CDN должна поддерживать HTTP/2, так как он намного эффективнее предыдущих версий HTTP. Его главный плюс в том, что для передачи любых типов файлов он устанавливает только одно TCP-соединение.
В CDN должна быть поддержка WebSocket — этот протокол для передачи данных в реальном времени упрощает доставку часто меняющегося динамического контента, поэтому без него не обойтись.
Чтобы быстрее доставлять контент, CDN важно поддерживать протокол IPv6. Желательно, чтобы сеть позволяла использовать эту версию протокола, даже если её ещё не поддерживает оборудование пользователя.
Важно, чтобы провайдер умел сжимать контент на лету прямо на стороне CDN, в процессе доставки с помощью алгоритмов Brotli, Gzip и WebP.
У CDN должны быть гибкие настройки кеширования. Желательно, чтобы провайдер мог взять функции аутентификации пользователей на себя, чтобы снизить нагрузку на ваши ресурсы.
Вместе с CDN можно подключить объектное хранилище, чтобы эффективно доставлять и хранить данные.
G-Core Labs CDN отвечает всем этим критериям, поэтому доставляет динамику так же быстро, как и статику. За производительность сети отвечают технологии Intel: в апреле 2021 мы одними из первых в мире начали интеграцию процессоров Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих сервисов. Убедиться в высокой скорости доставки динамического контента с помощью нашей CDN вы можете бесплатно — для этого у нас предусмотрен бесплатный тариф, а также бесплатный пробный период на любом тарифном плане.
Что такое 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: