CDN

Происхождение и история термина

В феврале 2003 года RFC 3466 уже описывал CDN как сложившуюся архитектуру. Его исторический раздел называет ранним важным применением раздачу популярных графических файлов, например изображений на главных страницах сайтов. Далее область применения расширялась: документ рассматривает доставку других цифровых материалов, включая потоковое медиа. Это свидетельство развития технологии, а не дата её изобретения. ^[1]

В августе 2014 года вышел RFC 7336 о взаимодействии нескольких CDN: маршрутизации запросов, обмене сведениями о контенте и журналами доставки. Вместе с RFC 6707 он заменил RFC 3466. Оба рассматриваемых документа — информационные описания архитектуры, а не обязательные стандарты настройки любого сервиса. В старом документе CDN раскрывается и как Content Delivery Network, и как Content Distribution Network. ^{[1, 6]}

Суть и механизм

Исходный сервер, или origin, содержит исходные версии файлов. В CloudFront им может быть веб-сервер владельца сайта или объектное хранилище — сервис хранения файлов. В настройках владелец указывает источник и правила доставки. Узлы CDN получают данные оттуда; подключение сети само по себе не переносит в неё редактирование сайта. ^[3]

Представим читателя, открывающего фотографию. Если пригодная копия уже находится на обслуживающем его узле, файл можно выдать из кеша. Если копии нет, узел обращается к источнику. Для CloudFront выбор узла связан с задержкой доставки, поэтому «ближайший» не следует понимать только как кратчайшее расстояние на карте. ^[3]

HTTP — протокол обмена запросами и ответами в вебе. Его кеш хранит ответы, которые можно использовать повторно. Общий кеш обслуживает разных пользователей, частный предназначен для одного; браузерный кеш относится ко второму типу. По RFC 9111 свежесть означает возможность использовать ответ без проверки на источнике, а не достоверность написанного в нём текста. ^[2]

Условия повторного использования передаются, в частности, в заголовке ответа Cache-Control. Например, max-age задаёт срок в секундах. Когда ответ перестаёт быть свежим, может потребоваться проверка на источнике: изменилась ли сохранённая версия. Время пригодности ответа и время его фактического хранения не стоит считать одним показателем. ^[2]

Виды и классификации

Для практической работы полезно разделять роли, а не искать один «кеш сайта». Ниже редакционная схема, основанная на различиях источника, общего и частного кешей. Она не задаёт обязательное число серверов. ^{[2, 3]}

В учебной задаче редакции это три отдельных вопроса. Сообщение «мы исправили файл на сервере» отвечает только на первый. Чтобы подтвердить результат для читателя, нужно проверить и путь доставки, и содержимое полученного файла. Это предлагаемый порядок приёмки, а не требование конкретного провайдера.

Как применяется на практике

Amazon CloudFront показывает международный вариант: владелец создаёт конфигурацию доставки, указывает источники и использует адреса CDN для своих материалов. Российский Yandex Cloud CDN отдельно описывает кеширование на узлах и в браузерах, сроки использования копий и очистку серверного кеша. Настройки одного продукта нельзя автоматически переносить в другой. ^{[3, 4]}

Yandex Cloud предупреждает, что определённая доля попаданий в кеш не гарантируется. Если нужных копий нет, сеть обращается к источнику; объём этих обращений зависит от настроек, обновлений и запросов. Поэтому для проекта следует проверять исходный сервер под ожидаемой нагрузкой, а не считать его работу законченной после подключения CDN. ^[4]

Рассмотрим учебный пример регионального издания. В 10:00 узел получил страницу с расписанием мероприятия. Для примера срок её пригодности равен пяти минутам; другими ограничениями и сетевыми задержками пренебрегаем, очистка не выполняется. В 10:02 редактор исправил время начала на исходном сервере. Запрос в 10:03 ещё может получить прежнюю копию: в выбранной модели она пригодна до 10:05. Модель следует правилу свежести HTTP, а все времена здесь условные. ^[2]

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

Как измерить или проверить

Сначала определите, какие запросы входят в отчёт. Например, отчёт Cache Statistics в CloudFront показывает попадания, промахи и ошибки как доли всех запросов выбранной конфигурации. Объём переданных байтов в нём учитывается отдельно. Попадание означает выдачу объекта из кеша узла, промах — отсутствие объекта в этом кеше и обращение к источнику. Это основания для подсчёта, а не оценка качества публикации. ^[7]

Для нашей учебной выборки доля попаданий по запросам рассчитывается так:

Доля попаданий = запросы с ответом из кеша / все учитываемые запросы × 100%.

Пусть за час пришла тысяча запросов без ошибок. Восемьсот запросов получили из кеша небольшие изображения по 0,1 МБ. Остальные двести получили файлы по 1 МБ, загруженные с источника. Для простоты считаем полные передачи без сжатия, повторных попыток и служебных данных. Это условная модель одного слоя кеширования, а не описание всех сетевых операций CDN.

Доля попаданий равна 800 / 1000 × 100% = 80%. Но из кеша передано 800 × 0,1 = 80 МБ, а после промахов — 200 × 1 = 200 МБ. Всего читатели получили 280 МБ; доля байтов из кеша составляет 80 / 280 × 100% ≈ 28,57%. Один показатель отвечает на вопрос «сколько запросов», другой — «сколько данных». Ни один сам по себе не измеряет ускорение сайта или экономию денег.

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

Ошибки, ограничения и спорные вопросы

Нельзя предполагать, что CDN сохранит любой ответ. Например, Cloudflare по умолчанию не кеширует HTML и JSON — форматы страниц и структурированных данных. Его правила также учитывают заголовки источника; в стандартном поведении предусмотрены исключения для ряда Cache-Control и ответа с Set-Cookie, который устанавливает cookie в браузере. Дополнительные настройки могут менять поведение. ^[5]

Особого внимания требуют ответы, различающиеся для разных пользователей. Сохранить страницу личного кабинета как общую копию — не то же самое, что сохранить публичную фотографию. RFC 9111 различает ограничения хранения и повторного использования; одна директива кеширования не является достаточной гарантией конфиденциальности. Поэтому учебный пример выше относится к общедоступным материалам, а не к настройке доступа к аккаунтам. ^[2]

Очистку серверного кеша также не следует приравнивать к удалению всех копий у читателей. В Yandex Cloud операции очистки относятся к копиям на CDN-серверах, а браузерное кеширование настраивается отдельно. При проверке старой версии сначала выясняют, откуда она пришла. ^[4]

Частые вопросы

Связанные термины

• skorost-zagruzki-sayta
• core-web-vitals
• https-i-ssl-sertifikat
• kody-otveta-servera
• seo dlya smi
• mobilnaya-adaptatsiya