Представьте, что вы построили идеальный сайт. Всё оптимизировано, но стоит тысяче пользователей из разных концов света одновременно захотеть посмотреть, как пушистик прыгает в коробку — и ваш сервер падает. Чтобы этого не случилось, в игру вступает CDN (Content delivery network). О том, как она работает, объясню на примере доставки котиков. 

Что такое CDN, и при чём тут котики

Когда пользователь заходит на сайт, браузеру нужно загрузить не только HTML, но и всё, что идёт в комплекте: картинки, скрипты, видео, стили, шрифты. Эти ресурсы тянутся с сервера. И если сервер находится в условной Калифорнии, а пользователь в Екатеринбурге — каждый байт проходит через десятки маршрутизаторов, пирингов, межконтинентальных каналов. 

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

Вот тут и вступает в игру CDN — Content Delivery Network. Это распределённая сеть узлов, которые кэшируют статику (а иногда и динамику) и отдают её пользователю с ближайшей точки.

Вот тут и подходит метафора с котиками — представьте, что вы запустили глобальный сервис по доставке котиков, которые аккуратно хранятся в дата-центре в Токио. Вечером тысячи пользователей из Перми, Хабаровска и Новосибирска решили одновременно заказать себе пушистого друга, но есть одно но. Если всех котиков везти из Токио, получится длинный маршрут через полмира, а у пользователей — бесконечная буферизация.

А теперь подключаем CDN: копии популярных котиков заранее лежат на узлах поближе — в Новосибирске, Екатеринбурге, Владивостоке. Когда пользователь открывает коробку с подарком, он получает данные не из Японии, а с ближайшего узла. И да, DNS подскажет, куда именно идти. 

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

Коты, как и типы контента, бывают разные

CDN не просто отдаёт котов. На практике кото-контент бывает разный — по структуре, по изменчивости, по требованиям к доставке, и CDN приходится учитывать эти особенности. 

Статические коты — это как спокойные домашние хвостики. Один раз сфотографировали, сохранили в .jpg или .mp4 — и можно раздавать всем желающим. Они не меняются, не требуют внимания, идеально подходят для кэширования. Вы один раз кладёте такого кота в локальный узел CDN — и больше центральный сервер про него не вспоминает. 

А вот динамические коты гораздо более нервные. Сегодня он в капюшоне, завтра — в коробке, послезавтра — требует ласки только по IP-адресу из Новосибирска. Это HTML, который формируется под пользователя с учётом авторизации, предпочтений, языка интерфейса, истории заказов. Такой кот не любит кэш, но даже тут есть подходы: частичное кэширование (например, только хедер и футер), Edge Side Includes, кэширование блоков по географии или cookie. 

Теперь представим кота в прямом эфире. Это уже стрим — условно, HLS или DASH. Такого кота нельзя просто выложить целиком. Он появляется по кусочкам от 2 до 10 секунд, которые надо отдавать строго в порядке, с правильной буферизацией, адаптацией битрейта и постоянным контролем задержек. CDN в этом случае — как режиссёр трансляции: принимает потоки с центрального сервера, кеширует часть, распределяет ближе к пользователям, следит, чтобы не было провисаний и потерь.

Есть ещё тип котов, которые не особенно разговорчивы, но критически важны — это коты-телеграммы. Или, если без метафор, — это real-time API, WebSocket-соединения, пуши. Кэшировать тут нечего, зато важны быстрая маршрутизация, минимальная латентность, поддержка любых протоколов, Anycast и TCP-тюнинг. В этом режиме CDN работает почти как сетевой ускоритель, а не как кеш.

Ну и наконец, тяжеловесные коты размером с .iso, .zip или многогигабайтный .mp4. Их нельзя тащить в одну трубу — слишком долго и больно. Тут в дело вступают оптимизации на уровне TCP-окон, Range-запросов, многопоточной загрузки и резюме. Такой контент требует не только пропускной способности, но и умной дедупликации, чтобы не гонять один и тот же архив через океан сто раз подряд.

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

Архитектура CDN: из чего построена кото-империя

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

Origin-сервер — сердце кото-империи

Итак, в центре — origin. Это не обязательно физический сервер в ЦОД с ковёр-бетоном, чаще всего это облачное хранилище или бэкенд-приложение. Его задача — быть источником истины. Он генерирует, хранит и отдаёт оригинальные версии контента: от .jpg и .mp4 до API-ответов и стримов.

Origin, по сути, стоит в бункере. Он не связывается с пользователями напрямую — и слава богу, иначе он быстро стал бы заложником DDoS, капризов с географией и сотен тысяч повторяющихся запросов. Поэтому весь трафик идёт через прокси, edge-узлы и кеши. Origin вступает в игру только тогда, когда пушистик запрашивается впервые или когда срок его локального хранения уже истёк.

PoP — кото-распределители

Point of Presence (PoP) — это как логистический центр ближнего радиуса. В каждом PoP могут быть десятки серверов, которые занимаются приёмом и обработкой трафика, — в том числе DNS, TLS-терминаторы, балансировщики и логгеры. Это настоящие перевалочные базы котиков, построенные ближе к пользователю: в Москве, Новосибирске, Франкфурте, Сингапуре.

Чем больше таких PoP по миру, тем меньше путь от браузера до ближайшего закэшированного контента. Это, кстати, один из главных бенчмарков при выборе CDN.

Edge-серверы — приёмные кото-дома

Внутри PoP'а находятся edge-серверы — те, кто непосредственно обслуживает пользователей. Это те самые кото-няни: принимают запрос, проверяют, есть ли нужный котик в локальном кэше, и если он там — отдают сразу, без звонка домой. 

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

Межузловая логистика: кото-хабы и дедупликация

В крупных CDN между edge-серверами и origin-центром может существовать дополнительная прослойка — mid-tier кэши. Они нужны, когда в одном регионе запросили редкого, но тяжёлого кота. Вместо того чтобы каждый edge шёл за ним на origin, они тянут его из среднего кеша — котохаба.

Работает это через tiered caching: иерархия кешей, где запросы «перетекают» вверх по цепочке только в случае промаха. Это снижает нагрузку на центральный сервер, уменьшает латентность при повторных запросах и экономит межрегиональный трафик.

DNS и маршрутизация: как выбрать ближайшего кота

Когда вы кликаете на ссылку с котиком, происходит нечто незаметное, но важное — CDN решает, откуда именно этого котика доставить. Сколько бы серверов ни было по миру, задача одна: выбрать ближайший, свободный и бодрый. 

Всё начинается с DNS. Когда браузер запрашивает cdn.cats.example.com, CDN выступает как авторитативный DNS-сервер — и отвечает разными IP в зависимости от того, откуда пришёл запрос. Если вы в Екатеринбурге — получите адрес ближайшего PoP в том же регионе. Если вы на Бали — подгрузка кота пойдёт откуда-то из Юго-Восточной Азии. Это называется GeoDNS, и оно работает как навигатор в мире распределённых пушистиков. 

Чтобы всё это работало быстро и устойчиво, многие CDN используют Anycast. Это когда один и тот же IP-адрес анонсируется с десятков площадок по всему миру. Ваш запрос уходит туда, куда интернет считает ближе. 

Однако не всё идеально. Иногда маршруты идут в обход, особенно если пользователь сидит за корпоративным прокси, а DNS-запрос приходит от публичного резолвера вроде 8.8.8.8. Тогда система видит не пользователя, а Google, и направляет котика… куда-нибудь в Калифорнию. 

Чтобы этого избежать, CDN подглядывают в IP-адреса клиентов через EDNS Client Subnet — расширение, позволяющее узнавать реальное местоположение пользователя даже через посредников. А в крайних случаях просто редиректят на нужный PoP вручную.

Как долго котик живёт в кэше

Кэширование — сердце CDN. Без него каждый запрос за котиком уносился бы к origin-серверу, но когда котики заранее рассажены по локальным PoP-узлам, всё работает иначе: пользователь кликает — и ближайший edge-сервер мгновенно раздаёт нужный контент.

Правда, в отличие от настоящих котов, кэшированные не живут вечно. У каждого объекта есть срок годности — TTL (Time To Live). Он задаётся через HTTP-заголовки вроде Cache-Control: max-age=3600, что означает: «держать этого кота в кэше ровно час». Когда время истекает, CDN либо проверяет, не устарел ли контент, либо просто идёт за новым.

TTL зависит от типа кота. Если это статический пушистик — изображение, JS или CSS — его можно смело держать в кэше подольше, а вот если речь о HTML-странице, персонализированном API или данных, зависящих от сессии — TTL будет коротким. 

Но TTL — не единственный механизм, влияющий на жизнь кота в кэше. Когда на edge-сервере заканчивается место, старых обитателей приходится выгонять. Тут вступают в игру алгоритмы вытеснения. Самый распространённый — LRU, который удаляет тех, к кому давно не заходили. Более продвинутый TLRU учитывает не только популярность, но и срок годности: если котик хоть и модный, но уже тухловат, он покинет кэш в числе первых.

Бывает, что котик на origin обновился, а в кэше всё ещё живёт старая версия. Тогда в ход идёт принудительная зачистка — invalidation. Через API можно сказать: «Уберите этого мейн-куна с коробкой из всех точек!» — и CDN очистит кеш по заданным URL. 

HTTP/2 и HTTP/3: как котики летают по новым дорогам

Когда вы кликаете на сайт с котиками, скорость их доставки зависит не только от того, где именно хранятся изображения — на PoP-узле рядом с вами или где-то далеко за морем. Важную роль играет и то, по каким протоколам эти котики к вам летят. 

Если HTTP/1.1 — это старая однополосная дорога с постоянными заторами, то HTTP/2 и HTTP/3 — это современные автомагистрали и даже воздушные трассы, где котики мчатся параллельно, не мешая друг другу. Именно на этих протоколах работают современные CDN.

HTTP/2 можно представить как широкую многоуровневую развязку, по которой котики едут одновременно в разных потоках. Он разбивает котика на небольшие фреймы и позволяет пересылать множество таких «разобранных» котов параллельно по одному TCP-соединению. В результате CSS, JS, HTML и изображения загружаются одновременно, не мешая друг другу. 

Но настоящий прорыв случился с появлением HTTP/3. Здесь транспортный уровень вовсе ушёл от TCP и перешёл на QUIC — это как если бы котики вместо машин пересели на реактивные ранцы. QUIC построен поверх UDP, а значит, не требует длительной установки соединения. Если в TCP один потерянный фрейм тормозил всю колонну, то здесь каждый котик летит сам по себе. Пропал один — остальные не ждут. 

Безопасность: коты прячутся в TLS

Когда котики мчатся по интернету, они уязвимы. Любой, кто перехватит поток данных, может их подглядеть, подменить или украсть. Поэтому каждое путешествие — строго в бронированном фургоне. Таким фургоном становится TLS — Transport Layer Security. 

Обычно терминацией TLS занимается CDN-узел — ближайший к пользователю PoP. Именно он устанавливает защищённое соединение с браузером. Это в разы быстрее, чем тянуть шифрованный канал с origin-сервера где-нибудь в Токио. При RTT в 50 мс TLS-рукопожатие займёт минимум 150 мс, а если edge-сервер в 20 мс от клиента, то тот же процесс займёт 60–90 мс. 

После установки TLS-соединения edge-сервер не закрывает его, а держит открытым — ждёт новых запросов. Это как если бы бронированный фургон после доставки не уехал обратно, а остался ждать следующего котика на том же маршруте. Такая схема — Keep-Alive — резко ускоряет повторные загрузки. 

Когда в дело вступает HTTP/3, всё становится ещё быстрее. QUIC, лежащий в его основе, шифрует трафик сразу. А для повторных визитов используется 0-RTT — механизм, при котором данные начинают передаваться ещё до завершения рукопожатия.

Кроме того, на входе в каждый приют стоит серьёзный кото-охранник. Это WAF — Web Application Firewall. Он знает, что SQL-инъекция — это не блюдо, а попытка взлома, что XSS — не болезнь, а крик «дайте я тут скрипт вставлю», и что нормальный пользователь не делает 200 POST-запросов за секунду. Всё подозрительное — блокируется ещё на границе, чтобы не тревожить сервер и не перегревать хвосты.

Стоит отметить, что некоторые котики приватные. За платной подпиской, по токену, с реферером или географией. Не каждый может войти в VIP-кото-зал, где хранятся особо пушистые видео и закрытые API. CDN в таких случаях работает как строгий консьерж: проверяет подпись запроса и страну, сверяется с ACL. 

Так к чему же тут котики? 

Метафора с котиками — не ради забавы. Она про то, как сложно устроена вроде бы простая вещь: открыть сайт, нажать «Play», получить API-ответ за 60 миллисекунд. За этими микромоментами стоит настоящая кото-логистика: от геораспределённых кэшей до протоколов низкого уровня, от продвинутой маршрутизации до фильтрации мусора. 

CDN — это как сеть приютов, через которые котики путешествуют быстро, надёжно и под охраной, независимо от того, где ты сидишь — в Воронеже, в Осаке или на вершине AWS Availability Zone.

© 2025 ООО «МТ ФИНАНС»