CDN, serverless и edge: сайт ближе к посетителю

CDN — сеть серверов в разных городах, отдающая копии файлов сайта с узла рядом с посетителем. Serverless — функции на платформе, edge — функции на узлах CDN.

Свет не бесконечно быстр

Вы выбрали хостинг в Москве, и в Москве сайт открывается мгновенно. Из Владивостока картина другая. Сигнал по оптоволокну идёт примерно двести километров за миллисекунду, а путь от Москвы до Владивостока в прямой линии около шести тысяч километров. К этому добавляются пересадки по дороге. Чтобы показать одну страницу, браузер и сервер обмениваются сообщениями несколько раз (соединение, шифрование, сам запрос), и каждый обмен это «туда и обратно». Получается задержка, которую не исправит ни быстрая вёрстка, ни мощный сервер: виновато расстояние.

Решение простое по идее: положить копии файлов поближе к людям. Это и делает CDN (content delivery network, сеть доставки содержимого).

Как работает CDN

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

1. Адрес сайта в DNS ведёт на CDN, а не прямо на ваш сервер.
2. Посетитель приходит на ближайший узел.
3. Если копия нужного файла на узле есть, это попадание (hit): узел отвечает сам, ваш сервер не тревожат.
4. Если копии нет, это промах (miss): узел идёт на исходный сервер, получает файл, отдаёт посетителю и запоминает его на указанный срок.

Выигрыши получаются сразу три: быстрее отвечает ближайший узел, ваш сервер переживает наплыв посетителей, а ещё CDN обычно берёт на себя HTTPS, сжатие, протоколы HTTP/2 и HTTP/3 и защиту от части атак. Поэтому статический хостинг, который вы выбирали в первом уроке, почти всегда уже стоит за CDN.

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

Посетитель в городе КалининградСанкт-ПетербургМоскваКраснодарЕкатеринбургНовосибирскВладивосток Сервер сайта МоскваФранкфурт

Без CDN С CDN (Москва, Санкт-Петербург, Екатеринбург, Новосибирск)

Копия уже в кэше (попадание) Первый запрос (промах)

Ближайший узел: Новосибирск, около 3715 км. Копия лежит на узле: сервер сайта вообще не участвует. Начало загрузки страницы (соединение, шифрование, первый ответ): примерно 171 мс.

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

Опубликовали новую версию

Что кэшируем HTML на суткиHTML на 5 минутHTML с перепроверкойCSS с хешем в имени, на годСтраница с личными данными Сбросили кэш при публикации

Через сколько минут после публикации: 10 мин

Cache-Control: public, max-age=86400

Новую версию уже видят 1% посетителей. Итог: быстро, но правку увидят только завтра.

Проверьте себя: что происходит при промахе кэша?

Узел идёт на исходный сервер, получает файл, отдаёт его посетителю и запоминает на указанный срок. Следующий посетитель получит копию уже с узла.

Что кэшировать и на сколько

Кэш помнит ответ столько, сколько вы ему разрешили. Разрешение даёт заголовок ответа Cache-Control (вы встречали заголовки в уроке про HTTP):

• max-age=N: хранить N секунд;
• no-cache: хранить можно, но перед каждым показом спрашивать у сервера, не изменилось ли (если нет, сервер отвечает коротким 304 без тела);
• no-store: не хранить вообще;
• private: хранить можно только в браузере самого человека, общим кэшам и CDN нельзя;
• immutable: этот файл по этому адресу никогда не изменится, не перепроверяйте.

Три правила, которых достаточно большинству сайтов.

1. Файлы с хешем в имени: на год. Картинки, шрифты, CSS и скрипты, которые собирает сборщик, получают в имени отпечаток содержимого (app.3f9a1c.css). Правка файла меняет имя, и старая копия никому не мешает. Поэтому для них годится public, max-age=31536000, immutable.
2. HTML: коротко или с перепроверкой. Страница это то, что вы правите чаще всего, и ссылается на файлы с хешами. Если HTML закэшировать надолго, посетители не увидят ни правки, ни новых файлов. Поэтому no-cache или несколько минут.
3. Личное: никогда в общий кэш. Страница с именем вошедшего человека, ответ формы, корзина: private, no-store. Известная неприятность, когда кэш показал одному человеку страницу другого, начинается с забытого заголовка на персональной странице.

Если нужно, чтобы новая версия появилась у всех сразу, остаётся сброс кэша (purge): команда CDN «забудь это». Хорошая выкладка сбрасывает кэш сама (об этом урок про CI/CD).

Проверьте себя: почему файл с хешем в имени можно кэшировать на год?

Потому что при изменении содержимого меняется имя, и браузер просто не найдёт старую копию под новым именем. Старая копия безвредна.

Функция без сервера

Допустим, на статическом сайте нужна форма заявки (главное действие вашего проекта). Принять данные должна программа, а сервера у вас нет. Вот тут помогает serverless: «вычисления без сервера».

Название не значит, что серверов нет. Они есть, но обслуживает их платформа, а вы загружаете маленькую функцию. Платформа запускает её, когда приходит запрос, поднимает столько копий, сколько нужно, и берёт плату за вызовы. Если запросов нет, функция «спит» и ничего не стоит. Такие платформы есть у крупных облаков (первой стала AWS Lambda в 2014 году), у Cloudflare (Workers), у Vercel и Netlify, в России это, например, Yandex Cloud Functions.

Взамен есть ограничения, которые надо знать заранее.

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

Код на границе сети

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

Платой служат жёсткие ограничения (мало памяти и времени) и расстояние до ваших данных: если база лежит в Москве, то функция на узле в Новосибирске всё равно идёт за ней в Москву, и выигрыш пропадает. Поэтому «на краю» держат решения, не нуждающиеся в данных, а работу с данными оставляют рядом с ними.

Вот как выглядит такая функция для формы заявки (в стиле Cloudflare Workers, но суть одна на любой платформе):

export default {
  async fetch(request, env) {
    if (request.method !== 'POST') {
      return new Response('Только POST', { status: 405 });
    }
    const data = await request.formData();
    const name = String(data.get('name') ?? '').trim();
    const phone = String(data.get('phone') ?? '').trim();
    if (!name || !/^[+0-9 ()-]{6,20}$/.test(phone)) {
      return new Response('Проверьте поля', { status: 400 });
    }
    await fetch(env.WEBHOOK_URL, {
      method: 'POST',
      headers: { 'content-type': 'application/json' },
      body: JSON.stringify({ name, phone })
    });
    return new Response('Принято', { status: 200 });
  }
};

Что в ней важно. Она проверяет то, что пришло (данные от посетителя нельзя считать честными: об этом вы читали в уроке про формы). Она не хранит секреты в коде: адрес приёмника берётся из env, настроек сервиса, а не вписан в страницу, которую видит каждый. И она отвечает понятными статусами: 405, 400, 200.

И ещё одно соображение, нетехническое. Форма принимает имя и телефон, а это персональные данные. Если проект работает с гражданами России, то выбирая платформу для функции, вы выбираете и страну, в которой эти данные впервые окажутся (об этом последний урок части). Поэтому функцию для такой формы разумнее держать в российском дата-центре, а не на зарубежной платформе: удобство границы сети здесь не стоит риска.

Честно: когда всё это не нужно

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

Практика

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

Проверка читает текст страницы. Саму функцию в этой песочнице не запустить: сети здесь нет, так что чтение кода глазами остаётся вашей работой.

Что было не так раньше

В 2010 году в Рунете распространённым решением было поставить сервер «посильнее» и надеяться, что хватит. Кэш настраивали в одном месте на сервере, и после правки CSS половина посетителей видела старый вид, пока не сбросишь кэш браузера. Принять форму без сервера было невозможно: нужен был хостинг с PHP, даже если форма одна. Сейчас статический сайт с функцией вместо сервера дешевле и надёжнее, но тот же вопрос остался: где лежит копия данных человека и кто к ней имеет доступ.