[Не] используйте CDN

Практически в любой статье или инструменте для оптимизации скорости сайтов есть скромный пункт «используйте CDN». Вообще, CDN – это content delivery network или сеть доставки контента. Мы в компании «Метод Лаб» часто встречаемся с вопросами клиентов по этой теме, некоторые самостоятельно включают себе CDN. Цель этой статьи разобраться, что может дать CDN с точки зрения скорости загрузки сайта, какие проблемы могут возникать и в каких случаях использование CDN оправдано.

Обведённые на картинке задержки вызваны использованием CDN.

Немного истории

Как и многие технологии, CDN появились по необходимости. При развитии интернет-каналов у пользователей Сети, появились сервисы онлайн-видео. Естественно, что видео-контент требует на порядки большей пропускной способности по сравнению с обычным контентом сайтов (картинки, текст, и CSS или JS-код).

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

Проблему ограничения канала отдельного сервера отлично решает CDN. Клиенты подключаются не к серверу напрямую, а к узлам сети CDN. В идеальной ситуации, сервер отдаёт один поток узлу CDN, а дальше сеть использует собственные ресурсы для доставки этого потока множеству пользователей. С точки зрения экономики мы платим только за фактически потреблённые ресурсы (это может быть пропускная способность или трафик) и получаем отличную масштабируемость нашего сервиса. Использование CDN для доставки тяжелого контента полностью оправдано и логично. Хотя стоит заметить, что крупнейшие игроки в этой области (например, Netflix) строят свои CDN вместо использования крупных коммерческих CDN (Akamai, Cloudflare, Fastly и т.д.)

По мере развития веба, сами веб-приложения стали сложнее и тяжелее. На первый план вышла проблема скорости загрузки. Энтузиасты скорости сайтов достаточно быстро вывели несколько основных проблем, которые приводили к медленной загрузке сайтов. Одной из них были задержки в сети (RTT — round trip time или время ping). Задержки влияют на множество процессов в загрузке сайта: установку TCP-соединения, запуск TLS-сессии, загрузку каждого отдельно ресурса (картинки, JS-файла, HTML-документа и т. д.)

Проблема усугублялась тем, что при использовании прокола HTTP/1.1 (до появления SPDY, QUIC и HTTP/2 это был единственный вариант) браузеры открывают не более 6 TCP-соединений к одному хосту. Всё это приводило к простою соединения и неэффективному использованию пропускной способности канала. Проблема частично решалась доменным шардингом – созданием дополнительных хостов для преодоления лимита на количество соединений.

Тут появляется вторая способность CDN – сокращение задержек (RTT) за счет большого количества точек и близости узлов к пользователю. Расстояние здесь играет решающую роль: скорость света ограничена (около 200 000 км/сек в оптоволокне). Значит, каждая 1000 км пути добавляет 5 мс задержек или 10 мс в RTT. Это минимальные расходы времени на передачу, так как есть еще задержки на промежуточном оборудовании. Так как CDN обычно умеет кэшировать объекты на своих серверах, мы можем выиграть от загрузки таких объектов через CDN. Необходимые условия для этого: наличие объекта в кэше близость точки CDN к пользователю в сравнении с сервером веб-приложения (origin server). Важно понимать: географическая близость узла CDN не гарантирует низкие задержки. Маршрутизация между клиентом и CDN может быть построена таким образом, что клиент будет подключаться к хосту в другой стране, а возможно и на другом континенте. Здесь вступают в действие взаимоотношения операторов связи и сервиса CDN (пиринг, наличие стыков, участие в IX и т. д.) и политика маршрутизации трафика самой CDN. Например, Cloudflare при использовании двух начальных планов (бесплатного и дешевого) не гарантирует отдачу контента с ближайшего узла – выбор хоста будет производиться для достижения минимальной стоимости.

Многие ведущие интернет-компании привлекают интерес общественности (веб-разработчиков и владельцев сервисов) к теме скорости загрузки и работы сайтов. Среди этих компаний Yahoo (инструмент Yslow), AOL (WebPageTest) и Google (сервис Page Speed Insights), которые разрабатывают свои рекомендации по ускорению сайтов (прежде всего они касаются клиентской оптимизации). Позднее появляются новые средства тестирования скорости сайтов, которые также дают советы по увеличению скорости сайтов. В каждом из этих сервисов или плагинов присутствует неизменная рекомендация «Используйте CDN». В качестве объяснения эффекта CDN как правило указывается сокращение сетевых задержек. К сожалению, не все готовы разбираться в том, как именно достигается эффект ускорения от CDN и как его можно измерить, поэтому рекомендация принимается на веру и используется как постулат. На самом деле, далеко не все CDN одинаково полезны.

Использование CDN сегодня

Для оценки полезности применения CDN их нужно классифицировать. Что можно встретить сейчас на практике (примеры в скобках конечно же не исчерпывающие):

1. Бесплатные CDN для раздачи JS-библиотек (MaxCDN, Google. Yandex).
2. CDN сервисов по клиентской оптимизации (например Google Fonts для шрифтов, Cloudinary, Cloudimage для картинок).
3. CDN для статики и оптимизации ресурсов в CMS (есть в Битриксе, WordPress и других).
4. CDN общего назначения (StackPath, CDNVideo, NGENIX, Мегафон).
5. СDN для ускорения сайтов (Cloudflare, Imperva, Айри).

Ключевое различие этих типов состоит с следующем: какая часть трафика проходит через CDN. Типы 1-3 это доставка только части контента: от одного запроса до нескольких десятков (обычно картинок). Типы 4 и 5 это полное проксирование трафика через CDN.

На практике это означает количество подключений, которые используются для загрузки сайта. При использовании HTTP/2 мы используем одно TCP-подключение к хосту для обработки любого количества запросов. Если мы разделяем ресурсы на основной хост (origin) и CDN, то необходимо разводить запросы по нескольким доменам и создавать несколько ТСP-соединений. В худшем случае это: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. В этой формуле не учитываются задержки в мобильных сетях на активацию радио-канала устройства (если он не был активен) и задержки на сотовой вышке.

Вот как это выглядит на водопаде загрузки сайта (выделены задержки для подключения к CDN при RTT 150 мс):

Если CDN покрывает весь трафик сайта (кроме сторонних сервисов), то мы можем использовать единственное TCP-соединение, экономя задержки на подключении к дополнительным хостам. Конечно, это касается HTTP/2-соединений.

Дальнейшие различия определяются функциональностью конкретной CDN – для первого типа это всего лишь хостинг статического файла, для пятого это изменение нескольких типов контента сайта с целью оптимизации.

Возможности CDN по ускорению сайта

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

1. Сжатие текстовых ресурсов

Самая базовая возможность и понятная возможность, тем не менее часто реализована плохо. Наличие сжатия декларируют все CDN в качестве своей фичи по ускорению. Но если посмотреть подробнее, то выясняются недоработки:

• могут использоваться низкие степени для динамического сжатия – 5-6 (например, для gzip максимум — 9);
• в статическом сжатии (файлы в кэше) не используются дополнительные возможности (например, zopfi или brotli со степенью 11)
• нет поддержки эффективного сжатия brotli (экономия примерно 20% по сравнению с gzip).

Если вы используете CDN, стоит проверить эти несколько пунктов: взять файл, который пришёл с CDN, зафиксировать его размер в сжатом виде и пережать вручную для сравнения (можно использовать какой-нибудь онлайн-сервис с поддержкой brotli, например всёсжать.рф).

2. Установка заголовков клиентского кэширования

Также простая фича по ускорению: поставить заголовки для кэширования контента клиентом (браузером). Наиболее актуальный заголовок cache-control, устаревший – expires. Дополнительно может использоваться Etag. Главное, чтобы max-age у cache-control был достаточно большим (от месяца и более), если вы готовы закэшировать ресурс максимально жестко, можно добавить опцию immutable.

CDN могут занижать значение max-age, вынуждая пользователя чаще загружать статику повторно. С чем это связано: с желанием увеличить трафик в сети или повышением совместимости с сайтами, которые не умеют сбрасывать кэш – не понятно. Например, значение времени кэширования в заголовках Cloudflare по умолчанию составляет 1 час, что очень мало для неизменяемой статики.

3. Оптимизация картинок

Так как CDN берёт на себя функции кэширования и отдачи картинок, логично будет оптимизировать их на стороне CDN и в таком виде отдавать пользователям. Сразу оговоримся, эта возможность доступна только для CDN типов 2, 3 и 5.

Оптимизировать изображения можно различными путями: использованием продвинутых форматов сжатия (например, WebP), более эффективными кодировщиками (MozJPEG) или просто очисткой лишних метаданных.

В целом есть два типа таких оптимизаций: с потерей качества и без потери качества. CDN обычно стремятся использовать оптимизацию без потерь – для того, чтобы избежать возможных жалоб клиентов на изменение качества картинок. В таких условиях выигрыш будет минимальным. В реальности часто уровень качества JPEG значительно превышает необходимый и можно смело проводить рекомпрессию с более низким показателем качества, без ущерба для восприятия пользователями. С другой стороны, определить уровень качества и настройки универсально для всех возможных веб-приложений сложно, поэтому CDN используют более консервативные настройки по сравнению с теми, которые можно применить с учетом контекста (назначение картинок, тип веб-приложения и т.д.)

4. Оптимизация TLS-соединения

Большинство трафика сегодня передаётся по TLS-соединениям, а это значит, что мы тратим дополнительное время на TLS-согласование. За последнее время разработаны новые технологии ускорения этого процесса. Например, это EC-криптография, TLS 1.3, кэш сессий и тикеты (session tickets), аппаратное ускорение шифрования (AES-NI) и т. д. Правильная настройка TLS позволяет сократить время соеднинения до 0-1 RTT (не считая DNS и TCP).

При наличии современного софта внедрить такие практики не сложно на собственных мощностях.

Далеко не все CDN внедряют лучшие практики по TLS, проверить это можно путём замера времени TLS-соединения (например в Webpagetest). Идеально для нового соединения — 1RTT, 2RTT — средний уровень, 3RTT и больше – плохо.

Также нужно заметить, что даже при использовании TLS на уровне CDN, сервер c нашим веб-приложением также должен обрабатывать TLS, но со стороны CDN, потому что трафик между сервером и CDN проходит в публичной сети. В худшем случае мы получим двойные задержки TLS-подключения (первая к хосту CDN, вторая между ним и нашим сервером).

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

5. Сокращение задержек подключения

Главное преимущество CDN, о котором все говорят: низкие задержки (меньшее расстояние) между хостом CDN и пользователем. Достигается путём создания географически распределённой архитектуры сети, в которой хосты располагаются в точках концентрации пользователей (городах, точках обмена трафиком и т. д.)

На практике, приоритеты для разных сетей могут находится в конкретных регионах. Например, российские CDN будут иметь больше точек присутствия в России. Американские прежде всего будут развивать сеть в США. Например, один из крупнейших CDN Cloudflare имеет только 2 точки в России — Москва и Санкт-Петербург. То есть, максимально мы можем сэкономить около 10 мс задержки по сравнению с прямым размещением в Москве.

Большинство западных CDN вообще не имеют точек в России. Подключившись к ним вы можете только увеличить задержки для вашей российской аудитории.

6. Оптимизация контента (минификация, структурные изменения)

Самый сложный и технологичный пункт. Изменение контента при доставке может быть очень рискованным. Даже если взять минификацию: сокращение исходного кода (за счет лишних пробелов, неважных конструкций и т. д.) может повлиять на его работоспособность. Если говорить о более серьёзных изменениях – переносе JS-кода в конец HTML, объединение файлов и подобных – риск нарушить функциональность сайта еще выше.

Поэтому лишь некоторые CDN из типа 5 занимаются этим. Конечно, автоматизировать все нужные для ускорения изменения не получится – требуется ручной анализ и оптимизация. Например, удаление неиспользуемого или дублирующего кода относится как раз к ручным задачам.

Как правило, все подобные оптимизации управляются настройками и самые опасные отключены по умолчанию.

Поддержка ускоряющих возможностей по типам CDN

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

Для удобства, повторим классификацию.

1. Бесплатные CDN для раздачи JS-библиотек (MaxCDN, Google. Yandex).
2. CDN сервисов по клиентской оптимизации (например Google Fonts для шрифтов, Cloudinary, Cloudimage для картинок).
3. CDN для статики и оптимизации ресурсов в CMS (есть в Битриксе, WordPress и других).
4. CDN общего назначения (StackPath, CDNVideo, NGENIX, Мегафон).
5. СDN для ускорения сайтов (Cloudflare, Imperva, Айри).

Теперь сопоставим фичи и типы CDN.

Возможность
Тип 1
Тип 2
Тип 3
Тип 4
Тип 5

Сжатие текста
+–
–
+–
+–
+

Заголовки кэша
+
+
+
+
+

Картинки
–
+–
+–
–
+

TLS
–
–
–
+–
+

Задержки
–
–
–
+
+

Контент
–
–
–
–
+

В этой таблице «+» используется для индикации полной поддержки, «–» — отсутствие, «+–» – частичная поддержка. Конечно, возможны отклонения от этой таблицы в реальности (например, какой-нибудь CDN общего назначения внедрит фичи по оптимизации картинок), но для общего представления она полезна.

Итоги

Надеюсь, прочитав эту статью у вас появится более ясная картина относительно рекомендации «используйте CDN» для ускорения сайтов.

Как и в любом деле, нельзя верить маркетинговым обещаниям какого-либо сервиса. Эффект нужно измерять и проверять в реальных условиях. Если вы уже используете какой-то CDN, проверьте его на предмет эффективности по критериям, описанным в статье.

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

В качестве общей рекомендации можно остановиться на следующем: изучите свою аудиторию, определите её географические рамки. Если ваша основная аудитория сосредоточена в радиусе 1-2 тысяч километров, вам не требуется CDN по основному назначению – снижению задержек. Вместо этого, вы можете разместить свой сервер ближе к пользователям и настроить его должным образом, получая большинство оптимизаций, описанных в статье (бесплатно и постоянно).

В случае, если ваша аудитория действительно географически распределена (радиус более 3000 километров), использование качественной CDN действительно будет полезно. Однако, нужно заранее понимать, что именно сможет ускорить ваша CDN (см. таблицу возможностей и их описание). Ускорение сайта при этом всё равно остаётся комплексной задачей, которая не решается подключением CDN. Помимо указанных оптимизаций за бортом CDN остаются самые эффективные средства ускорения: оптимизация серверной части, продвинутые изменения клиентской части (удаление неиспользуемого кода, оптимизация процесса рендеринга, работа с контентом, шрифтами, адаптивностью и т.д.)

Источник: habr.com