Автор: Кирилл Бодров, технический аккаунт-менеджер EdgeCenter.

Собрал для вас справочник из 40 терминов с короткими определениями понятий, связанных с CDN, видеостримингом, защитой от кибератак, DNS, объектным хранением, облачной инфраструктурой и метриками надёжности.

При составлении определений опирался на стандарты IETF (RFC), ISO/IEC и публикации NIST.

Сначала приведу короткие определения. Ниже — разверну понятия подробнее.

CDN

Стриминг

Безопасность

DNS

Хранение

Облако и инфраструктура

Метрики и надёжность

Origin (origin-сервер)

Origin (origin-сервер, сервер-источник) — это сервер, который хранит исходную версию контента и формирует ответы, которые CDN кеширует и раздаёт пользователям.

Это роль сервера в схеме доставки контента. RFC 9110 определяет origin-сервер как программу, способную формировать авторитетные ответы для целевого ресурса. Роль origin выполняет веб-сервер, балансировщик, бакет объектного хранилища или медиасервер. Заголовки Cache-Control, ETag и Last-Modified в ответах origin определяют, сколько копия живёт на edge-серверах. Edge-сервер обращается к origin только при отсутствии данных в кеше или проверке устаревшей копии, поэтому нагрузка на origin падает с ростом cache hit ratio. Прямой доступ к origin из интернета рекомендуется ограничивать.

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

Не путать с edge-сервером, который хранит копию и отвечает пользователю, HTTP-заголовком Origin из CORS-запросов.

Связанные термины: Edge-сервер, шилдинг источника, Cache hit ratio, TTL.

Подробнее в статье: «Что такое CDN».

Edge-сервер (граничный узел)

Edge-сервер (граничный узел, edge node) — это кеширующий сервер CDN, который расположен близко к пользователям и отдаёт им копии контента без обращения к origin.

Это элемент инфраструктуры CDN и общий кеш (shared cache) в терминах RFC 9111. Edge-серверы сгруппированы в точки присутствия (PoP). Edge-сервер ищет копию по ключу кеша и если находит, отвечает сразу, а если нет, запрашивает контент у origin или шилдинга, сохраняет и отдаёт. Кроме кеширования, edge-серверы завершают TLS-соединения, сжимают ответы, применяют правила CDN и фильтры безопасности. Время жизни копии задаёт TTL. Близость edge-сервера к пользователю сокращает задержку и TTFB: путь до origin проходится только при отсутствии данных в кеше.

Пример. Пользователь из Новосибирска получает изображение товара с edge-сервера в ближайшей точке присутствия, а не с origin в Москве.

Не путать с origin — источником оригинала, периферийными вычислениями (edge computing), где на узлах выполняется код приложения.

Связанные термины: origin, PoP, Cache hit ratio, задержка.

PoP (точка присутствия)

PoP (point of presence, точка присутствия) — это площадка в городе или дата-центре, на которой провайдер размещает серверы и сетевое оборудование и подключает их к сетям операторов связи.

Это физический элемент сетевой инфраструктуры. В CDN точка присутствия объединяет edge-серверы, маршрутизаторы и каналы к операторам и точкам обмена трафиком (IX). Атрибуты PoP: география, ёмкость каналов в гигабитах в секунду, число подключённых операторов, пиринг. Запросы распределяются между точками присутствия через anycast или через DNS, который выдаёт адрес ближайшей точки. Число точек присутствия — не единственная характеристика CDN: значение имеют расположение PoP относительно аудитории и связность с её операторами. У CDN EdgeCenter более 70 точек присутствия.

Пример. Онлайн-кинотеатр с аудиторией в Сибири выбирает CDN с точками присутствия в Новосибирске и Красноярске.

Не путать с дата-центром (PoP может занимать несколько стоек в чужом дата-центре, но не весь ЦОД), почтовым протоколом POP3.

Связанные термины: Edge-сервер, Anycast, BGP, задержка.

Cache hit ratio (процент попаданий в кеш)

Cache hit ratio (процент попаданий в кеш) — это метрика, которая показывает долю запросов, обслуженных из кеша CDN без обращения к origin: попадания / (попадания + промахи).

Это метрика эффективности кеширования в процентах. Различают cache hit ratio по запросам и по байтам (byte hit ratio): первый показывает нагрузку на origin, второй — долю исходящего трафика из кеша. Метрики расходятся, если на ресурсе много мелких некешируемых запросов и крупных кешируемых файлов. Для статических файлов ориентир — 90–95% и выше, значение ниже 80% обычно указывает на ошибку в Cache-Control, лишний заголовок Vary или рекламные метки в ключе кеша. Cache hit ratio повышают явные TTL, белый список query-параметров, версионирование статики и шилдинг источника.

Пример. После исключения меток utm_* и yclid из ключа кеша cache hit ratio каталога растёт, а запросов к origin становится меньше.

Не путать с доступностью сервиса (uptime), hit ratio кеша процессора.

Связанные термины: TTL, purge, шилдинг источника, origin.

Подробнее в статье: «Cache-Control, TTL и Vary: как правильно настроить кеширование на CDN».

TTL (Time To Live)

TTL (Time To Live, время жизни) — это время в секундах, в течение которого копия ответа в кеше считается свежей и отдаётся без обращения к origin.

Это параметр кеширования, RFC 9111 называет его сроком свежести (freshness lifetime). В HTTP TTL задаётся директивой max-age заголовка Cache-Control. Для общего кеша (CDN, прокси) директива s-maxage переопределяет max-age, а CDN с поддержкой RFC 9213 использует заголовок CDN-Cache-Control. Порядок приоритета: s-maxage, max-age, Expires, эвристика. Без явного TTL кеш вправе вычислить эвристический TTL от даты Last-Modified. Возраст копии общий кеш сообщает в заголовке Age. Для версионированной статики типичен TTL в год: max-age=31536000.

Пример. Ответ с Cache-Control: max-age=60, s-maxage=600 хранится в браузере минуту, на CDN — десять минут.

Не путать с TTL DNS-записи (сроком хранения записи в резолвере), TTL в IP-пакете (счётчиком, который уменьшает каждый маршрутизатор).

Связанные термины: Cache hit ratio, purge, DNS-резолвер, origin.

Подробнее в статье: «Cache-Control, TTL и Vary: как правильно настроить кеширование на CDN».

Шилдинг источника (origin shield)

Шилдинг источника (origin shield) — это промежуточный уровень кеширования между edge-серверами CDN и origin, который собирает запросы со всех точек присутствия и обращается к origin от их имени.

Это одна из функций CDN, вариант многоуровневого кеширования. Без шилдинга каждая точка присутствия при отсутствии данных в кеше запрашивает origin сама, и один файл origin отдаёт столько раз, сколько точек его запросили. С шилдингом edge-сервер обращается к shield-узлу, и при наличии там копии origin не задействуется. Shield-узел выбирают ближе к origin. Шилдинг повышает итоговый cache hit ratio, снижает трафик и нагрузку на origin, сглаживает всплеск запросов после очистки кеша. Цена — дополнительный сетевой участок при запросах.

Пример. Видеосервис включает шилдинг источника в Москве, и новый эпизод сериала origin отдаёт один раз, а не в каждый регион.

Не путать с защитой от DDoS-атак (шилдинг не фильтрует атакующий трафик), обычным edge-сервером.

Связанные термины: origin, edge-сервер, cache hit ratio, purge.

Purge (инвалидация кэша)

Purge (инвалидация кеша, очистка кеша) — это операция, которая принудительно удаляет копии контента из кеша CDN до истечения их TTL.

Это операция управления кешем CDN через панель или API провайдера. Способы: по URL (одна копия), по префиксу или маске (каталог), по тегу (копии, помеченные тегом в заголовке ответа) и полная очистка ресурса. Purge действует только на узлах CDN и не затрагивает кеш браузера: браузер, получивший ответ с длинным max-age, продолжит использовать свою копию. Полная очистка опасна под нагрузкой: каждый следующий запрос идёт на на origin. Надёжная схема — версионировать статику, а HTML сбрасывать по URL или тегу при публикации.

Пример. После изменения цены CMS через API CDN сбрасывает кеш по тегу товара на всех страницах с этим товаром.

Не путать с истечением TTL (естественным устареванием копии) прогревом кеша (заблаговременной загрузкой копий).
Связанные термины: TTL, Cache hit ratio, шилдинг источника, Origin.

Подробнее в статье: «Cache-Control, TTL и Vary: как правильно настроить кеширование на CDN».

TTFB (Time To First Byte)

TTFB (Time To First Byte, время до первого байта) — это метрика, которая измеряет время от начала запроса страницы до момента, когда начинает поступать первый байт ответа.

Это метрика веб-производительности в миллисекундах или секундах. По определению web.dev, TTFB складывается из редиректов, запуска service worker, DNS-запроса, установки соединения и TLS, и ожидания ответа сервера. Ориентир web.dev — 0,8 с и меньше для 75-го перцентиля пользователей, больше 1,8 с — плохое значение. TTFB не входит в Core Web Vitals, но задерживает все последующие метрики загрузки, включая LCP. CDN сокращает TTFB близостью edge-сервера и кешированием HTML. Без кеша TTFB определяется задержкой до origin и временем генерации страницы.

Пример. После кеширования HTML на CDN повторные запросы каталога не ждут генерации страницы на origin.

Не путать с задержкой (она входит в TTFB как слагаемое), временем полной загрузки страницы.

Связанные термины: задержка, edge-сервер, origin, пропускная способность.

Задержка (latency)

Задержка (latency, сетевая задержка) — это время, которое требуется пакету данных, чтобы пройти от отправителя до получателя, а в варианте RTT — туда и обратно.

Это метрика производительности сети в миллисекундах. Сетевая задержка складывается из задержек распространения сигнала, передачи, обработки на маршрутизаторах и ожидания в очередях. Задержку распространения ограничивает физика: в оптоволокне сигнал проходит около 200 км за 1 мс. На практике измеряют RTT (round-trip time), например утилитой ping. Для HTTP-запроса задержка умножается на число обменов: DNS, TCP, TLS, сам запрос. CDN снижает задержку, сокращая расстояние до пользователя. RFC 1242 определяет задержку сетевого устройства как интервал между приёмом и отправкой кадра.

Пример. После подключения CDN с точкой присутствия на Дальнем Востоке RTT для пользователей Владивостока сокращается.

Не путать с пропускной способностью (широкий канал может иметь большую задержку) джиттером  (разбросом задержки).

Связанные термины: пропускная способность, джиттер, TTFB, PoP.

Подробнее в статье: «Что такое CDN».

Пропускная способность (throughput)

Пропускная способность (throughput, фактическая скорость передачи) — это показатель, который выражает объём данных, реально переданный или обработанный системой за единицу времени.

Это метрика производительности: для сетей измеряется в битах в секунду, для серверов в запросах в секунду (RPS). RFC 1242 определяет пропускную способность сетевого устройства как максимальную скорость, при которой не отбрасывается ни один поступивший кадр. Пропускная способность не превышает ширину канала (bandwidth): часть ёмкости уходит на заголовки протоколов, повторные передачи и перегрузку. Пропускная способность одного TCP-соединения ограничен окном и RTT, поэтому на дальних маршрутах скорость падает даже при широком канале. Для видео нужна устойчивая пропускная способность, выше битрейта потока.

Пример. Поток с битрейтом 6 Мбит/с идёт без буферизации, только если пропускная способность до зрителя стабильно выше 6 Мбит/с.

Не путать с шириной канала (bandwidth), полезной пропускной способностью (goodput, скоростью без служебных данных).

Связанные термины: задержка, адаптивный битрейт, PoP, джиттер.

Подробнее в статье: «Что такое CDN».

Ingest

Ingest (приём потока) — это этап видеоконвейера, на котором исходный поток или файл поступает от источника на медиасервер или стриминговую платформу для обработки.

Это этап обработки видео. Для прямых трансляций ingest идёт по протоколам доставки от источника: RTMP, SRT, реже WebRTC или RTSP. Точка ingest задаётся адресом сервера и ключом потока (stream key). Атрибуты ingest: протокол, кодек и битрейт входящего потока, разрешение, интервал ключевых кадров. Для видео по запросу ingest — загрузка файла через веб-интерфейс, API или из объектного хранилища. После ingest поток идёт на транскодинг, упаковку в сегменты и раздачу через CDN. Для важных эфиров настраивают резервный ingest на второй сервер.

Пример. Организатор конференции указывает в OBS Studio адрес RTMP-сервера и ключ потока.

Не путать с доставкой зрителям по HLS или MPEG-DASH через CDN, транскодингом (следующим этапом).

Связанные термины: транскодинг, playout, сегмент, джиттер.

Подробнее в статье: «Протоколы видеостриминга».

Адаптивный битрейт(ABR)

Адаптивный битрейт (ABR, adaptive bitrate streaming) — это технология потоковой передачи, которая позволяет плееру переключаться между версиями видео разного качества в зависимости от скорости соединения.

Это метод доставки видео по HTTP. Видео заранее кодируется в несколько версий с разным разрешением и битрейтом — лестницу битрейтов (bitrate ladder). Каждая версия разбита на сегменты, манифест перечисляет все версии. Перед загрузкой каждого сегмента плеер оценивает пропускную способность и заполненность буфера и выбирает версию. ABR реализован в протоколах HLS (RFC 8216) и MPEG-DASH. Атрибуты: число ступеней лестницы, битрейты, длительность сегмента, алгоритм плеера. Переключение происходит на границе сегментов, поэтому сегменты всех версий выравниваются по ключевым кадрам.

Пример. При падении скорости в метро плеер переходит с 1080p на 480p вместо остановки на буферизацию.

Не путать с переменным битрейтом кодирования (VBR), который меняет битрейт внутри одного файла.

Связанные термины: транскодинг, манифест, сегмент, пропускная способность.

Транскодинг

Транскодинг (transcoding) — это процесс, который декодирует видео или аудио и заново кодирует его в другой кодек, битрейт или разрешение.

Это операция обработки медиа: декодирование исходного потока, необязательные преобразования (масштабирование, смена частоты кадров) и повторное кодирование, например из H.264 в H.265 или из 4K в версии 1080p, 720p и 480p для адаптивного битрейта. Нагрузка транскодинга растёт с разрешением, числом версий и сложностью кодека, поэтому транскодинг выполняют на GPU или специализированных серверах. Каждое кодирование с потерями снижает качество, поэтому транскодируют из исходника максимального качества. Для прямых трансляций транскодинг идёт в реальном времени после ingest.

Пример. Автор загружает исходник в 4K, а платформа транскодирует его в пять версий для адаптивного битрейта.

Не путать с трансмуксингом — сменой контейнера без перекодирования, например из RTMP в HLS.

Связанные термины: Ingest, ABR, CMAF, сегмент.

Манифест (плейлист)

Манифест (плейлист, manifest) — это текстовый файл, который описывает версии видеопотока и перечисляет адреса сегментов, чтобы плеер загружал их по порядку.

Это служебный файл протоколов адаптивной доставки по HTTP. В HLS манифест — файл .m3u8. RFC 8216 различает Media Playlist со списком сегментов и Master Playlist со списком Media Playlist разных версий качества. В MPEG-DASH манифест называется MPD (Media Presentation Description) и записывается в XML. Манифест содержит информацию о длине сегментов, битрейты, разрешения, кодеки, сведения о шифровании. Обязательный тег EXT-X-TARGETDURATION задаёт максимальную длительность сегмента. Манифест прямого эфира обновляется с каждым сегментом, поэтому кешируется на CDN на секунды.

Пример. Плеер загружает master.m3u8, выбирает версию 720p и периодически перечитывает её Media Playlist.

Не путать с сегментом (манифест не содержит видеоданных), эфирным плейлистом в playout.

Связанные термины: сегмент, ABR, CMAF, DRM.

Сегмент

Сегмент (медиасегмент) — это фрагмент видео- или аудиопотока ограниченной длительности, который плеер загружает отдельным HTTP-запросом по адресу из манифеста.

Это единица хранения и доставки в HLS и MPEG-DASH. В RFC 8216 медиасегмент задаётся URI и необязательным диапазоном байтов. Длительность сегмента не должна превышать target duration, типичное значение которой стандарт называет равным 10 секундам. Контейнер сегмента — MPEG-TS или фрагментированный MP4, в том числе CMAF. Короткие сегменты уменьшают задержку эфира и ускоряют переключение качества, но увеличивают число запросов к CDN. Каждый сегмент начинается с ключевого кадра. Сегменты записанного видео неизменны и кешируются на CDN с долгим TTL.

Пример. Двухчасовой фильм при длительности сегмента 6 секунд разбивается на 1200 сегментов в каждой версии.

Не путать с манифестом, частичными сегментами (CMAF chunks) в режимах низкой задержки.

Связанные термины: манифест, ABR, CMAF, TTL.

DRM

DRM (digital rights management, управление цифровыми правами) — это система, которая шифрует контент и выдаёт ключи расшифровки только авторизованным устройствам и пользователям по заданным правилам.

Это класс систем защиты контента: шифрование сегментов, сервер лицензий и модуль расшифровки (CDM) на устройстве. Для видео в вебе распространены Google Widevine, Microsoft PlayReady и Apple FairPlay. Браузер подключает DRM через спецификацию W3C Encrypted Media Extensions. Лицензия задаёт правила: срок действия, число устройств, запрет вывода на внешний экран, офлайн-просмотр. Чтобы не хранить контент в нескольких вариантах шифрования, используют общую схему шифрования (Common Encryption) и CMAF. Уровень защиты зависит от того, идёт ли расшифровка в аппаратном доверенном окружении.

Пример. Онлайн-кинотеатр выдаёт лицензию Widevine браузеру Chrome, FairPlay — устройствам Apple.

Не путать с шифрованием HLS ключом AES-128 без лицензий, водяными знаками.

Связанные термины: CMAF, сегмент, манифест, presigned URL.

CMAF

CMAF (Common Media Application Format) — это стандарт формата медиасегментов, который позволяет использовать одни и те же видеофайлы для доставки по HLS и MPEG-DASH.

Это международный стандарт ISO/IEC 23000-19, действующая редакция выпущена в 2024 году. CMAF основан на фрагментированном MP4 (ISO Base Media File Format) и определяет структуру треков, сегментов и фрагментов, профили кодеков и правила шифрования. До CMAF провайдер хранил и кешировал два комплекта сегментов: MPEG-TS для HLS и фрагментированный MP4 для DASH. С CMAF хранится один комплект, различаются только манифесты, а значит, объём хранения сокращается и cache hit ratio растёт. Сегмент CMAF делится на фрагменты (chunks), которые отдаются до завершения сегмента, на этом построены режимы низкой задержки.

Пример. Сервис отдаёт эфир плеерам Apple по HLS, а Smart TV — по DASH из одних и тех же CMAF-сегментов.

Не путать с протоколом доставки (HLS и DASH описывают манифесты и логику плеера), кодеком.

Связанные термины: сегмент, манифест, ABR, DRM.

Подробнее в статье: «Протоколы видеостриминга».

Playout

Playout (плейаут, вещание по расписанию) — это процесс, который формирует непрерывный линейный видеоканал из записей, прямых включений и рекламы по заданному расписанию.

Это функция вещательной инфраструктуры. Playout-система по эфирному плейлисту воспроизводит файлы, переключается на живые источники, накладывает графику, логотип и титры, вставляет рекламные блоки. Выход playout — непрерывный поток, который кодируется и доставляется через спутник, кабельные сети или интернет по HLS. Облачный playout работает на виртуальных машинах без собственной эфирной аппаратной. Атрибуты: точность расписания до кадра, резервирование, поддержка маркеров рекламных вставок SCTE-35. Облачный playout используют корпоративные и FAST-каналы — бесплатные линейные каналы с рекламой.

Пример. Круглосуточный канал из архива: playout чередует выпуски и рекламу и отдаёт поток в CDN.

Не путать с видео по запросу, прямой трансляцией одного события без расписания.

Связанные термины: Ingest, транскодинг, манифест, джиттер.

Джиттер (Jitter)

Джиттер (Jitter, вариация задержки пакетов) — это метрика, которая показывает, насколько задержка доставки меняется от пакета к пакету в одном потоке.

Это метрика качества сети в миллисекундах. RFC 3393 называет метрику IP Packet Delay Variation (IPDV) и вычисляет её как разницу односторонней задержки выбранных пакетов. Авторы RFC 3393 избегают слова «джиттер», поскольку разные сообщества понимают его по-разному. Причины джиттера: очереди на маршрутизаторах, перегрузка, смена маршрута, Wi-Fi. Для живого видео и звонков джиттер критичнее средней задержки: приёмник компенсирует джиттер буфером, а буфер добавляет задержку. Протокол SRT использует буфер задержки для компенсации джиттера и потерь пакетов.

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

Не путать с задержкой, потерями пакетов.

Связанные термины: задержка, пропускная способность, Ingest, ABR.

Подробнее в статье: «Протоколы видеостриминга».

DDoS-атака

DDoS-атака (distributed denial of service, распределённая атака типа «отказ в обслуживании») — это атака, при которой множество устройств одновременно отправляют трафик или запросы на цель, чтобы исчерпать её ресурсы и сделать сервис недоступным.

Это отдельный класс кибератак на доступность. Различают объёмные атаки на каналы (UDP-флуд, амплификация через DNS, NTP, memcached), атаки на протоколы и сетевой стек (SYN-флуд) и атаки уровня приложений (HTTP-флуд, cache-busting, медленные запросы). Атрибуты: объём в гигибатах в секунду, интенсивность в пакетах или запросах в секунду, длительность, число источников. Источники атаки — ботнеты из заражённых устройств и серверов. Защита строится слоями: фильтрация на уровне сети, центры фильтрации, anycast, ограничение запросов и WAF.

Пример. HTTP-флуд на магазин уходит в систему очистки, и покупатели продолжают оформлять заказы.

Не путать с DoS-атакой с одного источника, легитимным всплеском трафика.

Связанные термины: очистка трафика, WAF, лимитирование запросов, anycast.

Подробнее в статье: «DDoS-атаки: полный разбор».

WAF

WAF (web application firewall, межсетевой экран для веб-приложений) — это средство защиты, которое анализирует HTTP-запросы к веб-приложению и блокирует запросы с признаками атак.

Это средство защиты уровня 7 модели OSI, работает как обратный прокси или модуль веб-сервера. WAF разбирает URL, заголовки, cookie и тело запроса и сверяет их с сигнатурами и правилами: SQL-инъекции, XSS, обход путей, внедрение команд — классы уязвимостей из перечня OWASP Top 10. Режимы: обнаружение (только журнал) и блокировка. Негативная модель блокирует известные атаки, позитивная пропускает только описанные запросы, например по схеме API. Ключевые атрибуты WAF — доля ложных срабатываний, задержка обработки, виртуальный патчинг уязвимости до исправления кода.

Пример. Магазин на устаревшей CMS закрывает известную уязвимость правилом WAF, пока готовится обновление.

Не путать с сетевым файрволом, который фильтрует по IP-адресам и портам и не видит содержимое HTTP.

Связанные термины: DDoS-атака, лимитирование запросов, очистка трафика, origin.

Очистка трафика (scrubbing)

Очистка трафика (scrubbing) — это метод защиты от DDoS-атак, при котором трафик ресурса направляется через центр очистки, который отбрасывает вредоносные пакеты и передаёт ресурсу только легитимный трафик.

Это метод противодействия DDoS-атакам в центрах очистки (scrubbing centers) провайдера защиты. Трафик перенаправляют BGP-анонсом защищаемой сети, через DNS (адрес ресурса меняется на адрес защиты) или постоянным проксированием. Фильтры отбрасывают трафик по сигнатурам, аномалиям, репутации адресов, лимитам скорости и проверкам клиента. Очищенный трафик возвращается клиенту через GRE-туннель или выделенное соединение. Атрибуты: ёмкость центров очистки в гигабитах в секунду, задержка от перенаправления, режим — постоянный (always-on) или по требованию.

Пример. Сеть клиента анонсируется по BGP из центров очистки, и атака отфильтровывается до серверов клиента.

Не путать с RTBH — отбрасыванием всего трафика на атакуемый адрес.

Связанные термины: DDoS-атака, BGP, anycast, лимитирование запросов.

Подробнее в статье: «DDoS-атаки: полный разбор».

Лимитирование запросов (rate limiting)

Лимитирование запросов (rate limiting) — это механизм, который ограничивает число запросов от одного клиента за интервал времени и отклоняет или задерживает запросы сверх лимита.

Это механизм управления нагрузкой и защиты приложений. Клиента идентифицируют по IP-адресу, API-ключу, токену или cookie. Распространённые алгоритмы: token bucket, leaky bucket, фиксированное и скользящее окно. Атрибуты: лимит, длина окна, допустимый всплеск (burst), действие при превышении. Стандартный HTTP-ответ при превышении — код 429 Too Many Requests из RFC 6585, ответ может содержать заголовок Retry-After. RFC 6585 не определяет, как сервер идентифицирует пользователя и считает запросы. Ограничение запросов защищает от перебора паролей, парсинга и слабого HTTP-флуда.

Пример. API разрешает 100 запросов в минуту на ключ и на 101-й запрос отвечает кодом 429 с Retry-After.

Не путать с ограничением полосы (bandwidth throttling) — скорости передачи данных.

Связанные термины: WAF, DDoS-атака, очистка трафика, edge-сервер.

Anycast

Anycast — это способ адресации и маршрутизации, при котором один IP-адрес анонсируется из нескольких точек, а сеть доставляет пакет в ближайшую по маршрутизации точку.

Это метод адресации и маршрутизации IP. RFC 4786 (BCP 126) определяет anycast как практику, при которой сервисный адрес доступен в нескольких независимых местах, и датаграммы маршрутизируются в одно из них. Каждая точка анонсирует один и тот же префикс по BGP, и выбор точки определяется маршрутизацией, а не географией напрямую. Anycast применяется в DNS (корневые и авторитативные серверы), в CDN и в защите от DDoS: атакующий трафик распределяется по всем точкам. Ограничение — при смене маршрута TCP-сессия может попасть в другую точку.

Пример. DNS-хостинг отвечает с одного адреса из многих городов, и резолвер получает ответ ближайшего узла.

Не путать с unicast, multicast (доставкой пакета группе получателей), геобалансировкой через DNS.

Связанные термины: unicast, BGP, PoP, DNS-резолвер.

Подробнее в статье: «Как работает DNS».

Unicast

Unicast (юникаст, одноадресная передача) — это способ адресации, при котором IP-адрес принадлежит одному сетевому интерфейсу, а пакет доставляется ровно одному получателю.

Это базовый метод адресации IP; наряду с unicast существуют broadcast, multicast и anycast. Большая часть интернет-трафика — unicast: HTTP-запросы, загрузка файлов, OTT-видео. В CDN и DNS unicast означает, что сервер доступен по уникальному адресу в одном месте, а распределение пользователей между точками присутствия выполняет DNS, который возвращает разным пользователям адреса разных серверов. Unicast проще в отладке и сохраняет стабильность TCP-сессий, но хуже распределяет атакующий трафик. В видеодоставке unicast — отдельный поток каждому зрителю.

Пример. Стриминговая платформа отдаёт каждому зрителю отдельный unicast-поток HLS с ближайшего edge-сервера.

Не путать с anycast (один адрес из многих точек) multicast (групповой рассылкой потока).

Связанные термины: anycast, BGP, DNS-резолвер, PoP.

Подробнее в статье: «Как работает DNS».

BGP (Border Gateway Protocol)

BGP (Border Gateway Protocol) — это протокол маршрутизации, который передаёт информацию о достижимости сетей между автономными системами и определяет пути трафика в интернете.

Это протокол междоменной маршрутизации (inter-AS), версия BGP-4 определена в RFC 4271 (январь 2006). BGP работает поверх TCP, порт 179. Автономная система (AS) — сеть под единым управлением с номером ASN. BGP передаёт соседям префиксы с атрибутами, включая путь из номеров автономных систем (AS_PATH), который позволяет обнаруживать петли маршрутизации. Выбор маршрута определяется политиками оператора, а не только длиной пути. BGP — основа anycast, перенаправления трафика в центры очистки и подключения к точкам обмена трафиком. Ошибочные анонсы способны сделать недоступными крупные сервисы.

Пример. Анонс сети клиента по BGP из центров очистки направляет трафик через фильтры.

Не путать с DNS, OSPF и IS-IS, которые работают внутри одной автономной системы.

Связанные термины: anycast, unicast, очистка трафика, PoP.

Подробнее в статье: «DDoS-атаки: полный разбор».

DNS-резолвер

DNS-резолвер (DNS resolver) — это программа или сервер, который получает от клиента запрос имени и находит соответствующие DNS-записи, обращаясь к серверам доменных имён.

Это компонент системы DNS. RFC 9499 (BCP 219, март 2024) описывает резолвер как программу, которая извлекает информацию из серверов имён в ответ на запросы клиентов. Заглушка (stub resolver) не выполняет разрешение сама и передаёт запрос рекурсивному резолверу. Рекурсивный резолвер проходит путь от корневого DNS-сервера через домен верхнего уровня до авторитативного сервера зоны и, как правило, кеширует ответы. Срок хранения ответа задаёт TTL записи. Рекурсивный резолвер предоставляет оператор связи или публичный сервис. Резолвер, проверяющий подписи DNSSEC, называют валидирующим.

Пример. Заглушка в ОС передаёт запрос резолверу оператора, а резолвер находит ответ у авторитативного сервера.

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

Связанные термины: DNS-зона, DNSSEC, TTL, anycast.

Подробнее в статье: «Как работает DNS».

DNSSEC

DNSSEC (DNS Security Extensions) — это набор расширений DNS, который добавляет к DNS-записям криптографические подписи и позволяет резолверу проверить подлинность источника и целостность ответа.

Это набор протоколов безопасности DNS. RFC 9364 (BCP 237, февраль 2023) называет использование DNSSEC лучшей текущей практикой. Базовые спецификации — RFC 4033, 4034 и 4035. По RFC 4033 DNSSEC обеспечивает аутентификацию источника данных, целостность и аутентифицированное отрицание существования записи, но не конфиденциальность и не защиту от DDoS-атак. Записи зоны подписываются (RRSIG), ключи публикуются в DNSKEY, хэш ключа передаётся в родительскую зону записью DS — так строится цепочка доверия. DNS-хостинг EdgeCenter поддерживает DNSSEC.

Пример. Валидирующий резолвер отклоняет подменённый ответ, потому что подпись RRSIG не сходится с ключом из цепочки доверия.

Не путать с DNS over HTTPS и DNS over TLS — шифрование скрывает запросы, но не подтверждает подлинность данных зоны.

Связанные термины: DNS-зона, DNS-резолвер, TTL, BGP.

Подробнее в статье: «Как работает DNS».

DNS-зона

DNS-зона (DNS zone) — это часть пространства доменных имён, за которую отвечает определённый набор авторитативных серверов и которая управляется как единое целое.

Это административная единица DNS. RFC 1034, на который ссылается RFC 9499, описывает зону как единицу организации авторитативной информации. Граница между родительской и дочерней зоной называется точкой делегирования (zone cut). Зона — набор ресурсных записей: SOA с параметрами зоны, NS со списком авторитативных серверов, A, AAAA, CNAME, MX, TXT и другие. У каждой записи есть TTL. Зона может совпадать с доменом или быть уже домена: поддомен можно делегировать в отдельную зону на других серверах. Изменения передаются на вторичные серверы через передачу зоны (AXFR, IXFR).

Пример. Зона example.ru размещена у DNS-хостинга, а поддомен video.example.ru делегирован записями NS стриминговому провайдеру.

Не путать с доменом — домен является узлом в дереве имён, а зона — областью ответственности серверов.

Связанные термины: DNS-резолвер, DNSSEC, TTL, anycast.

Бакет

Бакет (bucket) — это контейнер в объектном хранилище, который объединяет объекты под одним именем и задаёт для них общие настройки доступа, хранения и жизненного цикла.

Это базовая сущность объектного хранилища. Пространство имён в бакете плоское: «папки» — общие префиксы ключей объектов, а не каталоги. Атрибуты бакета: имя, регион, политика доступа, версионирование, lifecycle-политики, CORS и шифрование. Адрес объекта строится из имени бакета и ключа объекта. S3 допускает любое число объектов в бакете, поэтому бакеты делят по назначению и правам доступа.

Пример. Исходники видео лежат в закрытом бакете, превью — в публичном, подключённом к CDN как origin.

Не путать с каталогом файловой системы, томом блочного хранилища.

Связанные термины: объект, presigned URL, lifecycle-политика, origin.

Объект (в объектном хранилище)

Объект (в объектном хранилище) — это единица хранения, которая состоит из данных, метаданных и ключа, уникального в пределах бакета.

Это элемент модели объектного хранилища. Он состоит из данных и метаданных — пар «имя — значение», системных данных (дата изменения, Content-Type) и пользовательских. Ключ — уникальный идентификатор объекта внутри бакета. Объект записывается и читается целиком через HTTP-API (PUT, GET): изменить часть объекта на месте нельзя, новая версия загружается заново. Крупные файлы загружаются по частям (multipart upload). При версионировании бакет хранит предыдущие версии объекта. Доступ к объекту бывает публичным, приватным или временным по presigned URL.

Пример. Файл с ключом photos/2026/11/item-1542.jpg и метаданными Content-Type: image/jpeg — объект в бакете магазина.

Не путать с файлом (у объекта нет иерархии каталогов и частичной перезаписи), блоком блочного хранилища.

Связанные термины: бакет, presigned URL, lifecycle-политика, origin.

Presigned URL

Presigned URL (предподписанная ссылка) — это URL объекта, который содержит криптографическую подпись и срок действия и даёт временный доступ к объекту без передачи ключей доступа.

Это механизм временной авторизации в API S3. Приложение подписывает параметры запроса (метод, бакет, ключ, срок действия) секретным ключом и добавляет подпись в строку запроса. Хранилище проверяет подпись и время и выполняет операцию с правами автора ссылки. Presigned URL позволяет скачать (GET) или загрузить (PUT) объект напрямую, минуя сервер приложения. Срок действия может быть разным, лимит задаёт провайдер. Любой владелец ссылки получает доступ до истечения срока.

Пример. Онлайн-школа выдаёт ученику ссылку на PDF, действующую один час, вместо публичного доступа к бакету.

Не путать с публичной ссылкой, защищёнными ссылками CDN, которые проверяет edge-сервер.

Связанные термины: объект, бакет, DRM, edge-сервер.

Lifecycle-политика

Lifecycle-политика (политика жизненного цикла) — это набор правил бакета, который автоматически переводит объекты в другой класс хранения или удаляет их по возрасту и другим условиям.

Это конфигурация бакета, набор правил, определяющих действия над группой объектов. Действия могут быть двух типов: переход (transition) в другой класс хранения и истечение (expiration), то есть удаление. Правило применяется по префиксу ключа или тегам, условие — число дней с создания объекта или дата. Отдельные правила управляют предыдущими версиями объектов и незавершёнными составными загрузками. Lifecycle-политика сокращает расходы: редко запрашиваемые данные уходят в холодный класс, временные удаляются без участия людей.

Пример. Правило переводит записи трансляций в холодный класс через 30 дней и удаляет через 365 дней.

Не путать с TTL кеша — TTL управляет копией, а lifecycle-политика — оригиналом.

Связанные термины: бакет, объект, RPO, TTL.

IaaS (инфраструктура как услуга)

IaaS (Infrastructure as a Service, инфраструктура как услуга) — это модель облачных услуг, в которой провайдер предоставляет вычислительные ресурсы, хранилище и сеть, а клиент сам администрирует операционные системы и приложения.

Это одна из трёх моделей облачных услуг по NIST SP 800-145 (сентябрь 2011), наряду с PaaS и SaaS. По NIST, потребитель IaaS разворачивает произвольное ПО, включая ОС, не управляет базовой облачной инфраструктурой, но контролирует ОС, хранилище, приложения и частично сетевые компоненты, например host-файрволы. Типовые услуги IaaS: виртуальные машины, Bare metal, блочные диски, объектное хранилище, балансировщики, частные сети. NIST называет пять характеристик облака: самообслуживание по требованию, широкий сетевой доступ, пул ресурсов, быстрая эластичность, измеряемый сервис.

Пример. Команда арендует виртуальные машины, сама обновляет ОС и платит за выделенные ресурсы.

Не путать с PaaS, где провайдер управляет ОС и средой выполнения.

Связанные термины: Bare metal, гипервизор, оркестрация контейнеров, SLA.

Bare metal

Bare metal (выделенный физический сервер в облаке) — это физический сервер, который провайдер целиком предоставляет одному клиенту без слоя виртуализации и с облачной моделью заказа и оплаты.

Это вид вычислительного ресурса в модели IaaS. Клиент получает все ресурсы машины — процессоры, память, диски, сетевые интерфейсы — без соседей и без накладных расходов гипервизора. Bare metal выбирают для нагрузок, чувствительных к производительности: баз данных с интенсивной работой с дисками, транскодинга видео, игровых серверов, обучения ML-моделей, а также для лицензий, привязанных к физическим ядрам. Клиент может установить на Bare metal собственный гипервизор. Отличие от классической аренды выделенного сервера — заказ через панель или API, автоматическая установка ОС и подключение к сети облака.

Пример. Стриминговый сервис выносит транскодинг на Bare metal серверы с GPU.

Не путать с колокацией и виртуальной машиной на выделенном хосте, где гипервизор остаётся.

Связанные термины: IaaS, гипервизор, транскодинг, SLA.

Гипервизор

Гипервизор (hypervisor, монитор виртуальных машин) — это программный слой, который создаёт виртуальные машины, распределяет между ними ресурсы физического сервера и изолирует их друг от друга.

Это системное ПО виртуализации. Гипервизоры первого типа работают непосредственно на оборудовании: KVM в ядре Linux, Xen, VMware ESXi, Microsoft Hyper-V. Гипервизоры второго типа запускаются поверх операционной системы, например VirtualBox, и применяются в основном на рабочих станциях. Гипервизор выделяет виртуальной машине виртуальные процессоры, память, диски и сетевые интерфейсы, используя аппаратные расширения процессора (Intel VT-x, AMD-V). Облачные платформы IaaS строятся на гипервизорах первого типа. Накладные расходы гипервизора — причина выбирать Bare metal для чувствительных нагрузок.

Пример. Сервер с гипервизором KVM обслуживает виртуальные машины разных клиентов облака.

Не путать с контейнерами — контейнеры разделяют ядро одной ОС, а у каждой виртуальной машины своё ядро.

Связанные термины: IaaS, Bare metal, оркестрация контейнеров, RTO.

Оркестрация контейнеров

Оркестрация контейнеров — это автоматизированное управление контейнерами на кластере серверов, которое обеспечивает их развёртывание, масштабирование, восстановление и сетевое взаимодействие.

Это класс систем управления инфраструктурой, стандарт де-факто — Kubernetes, проект Cloud Native Computing Foundation. Оркестратор получает декларативное описание желаемого состояния (число реплик, ресурсы, сетевые правила) и непрерывно приводит кластер к нему: размещает контейнеры по узлам, перезапускает упавшие, перераспределяет нагрузку, выкатывает версии без простоя. Атрибуты: число узлов, политики автомасштабирования, стратегии развёртывания, сетевая модель. Managed Kubernetes снимает с команды обслуживание управляющего слоя (control plane), рабочие нагрузки остаются за клиентом.

Пример. В распродажу оркестратор увеличивает число реплик сервиса корзины, а после спада сокращает.

Не путать с контейнеризацией — упаковкой приложения в образ.

Связанные термины: IaaS, гипервизор, Bare metal, RTO.

RTO (Recovery Time Objective)

RTO (recovery time objective, целевое время восстановления) — это показатель, который задаёт максимально допустимое время недоступности системы после сбоя.

Это целевой показатель непрерывности бизнеса и аварийного восстановления. NIST SP 800-34 Rev. 1 (май 2010) определяет RTO как максимальное время, в течение которого системный ресурс может быть недоступен до наступления неприемлемых последствий для других ресурсов, бизнес-процессов и максимально допустимого простоя (MTD). RTO должно быть короче MTD. RTO измеряется в минутах или часах и устанавливается по итогам анализа влияния на бизнес. Часы допускают восстановление из резервной копии, минуты требуют горячего резерва и автоматического переключения. Достижимость RTO подтверждают учения по восстановлению.

Пример. RTO 15 минут для платёжного сервиса требует репликации базы с автоматическим переключением.

Не путать с RPO (допустимой потерей данных), MTTR (фактическим средним временем восстановления).

Связанные термины: RPO, SLA, IaaS, оркестрация контейнеров.

RPO (Recovery Point Objective)

RPO (recovery point objective, целевая точка восстановления) — это показатель, который задаёт момент до сбоя, на который должны быть восстановлены данные, и тем самым определяет допустимую потерю последних изменений.

Это целевой показатель аварийного восстановления. NIST SP 800-34 Rev. 1 определяет RPO как момент времени до сбоя, на который данные бизнес-процесса могут быть восстановлены с учётом последней резервной копии; в отличие от RTO, RPO не входит в расчёт MTD. RPO выражается во времени и определяет частоту резервного копирования или способ репликации: копия раз в сутки даёт RPO до 24 часов, асинхронная репликация — от секунд до минут, синхронная — близко к нулю ценой задержки записи. Резервные копии хранят отдельно от основных данных.

Пример. Снимки базы каждые 4 часа означают RPO в 4 часа: изменения за этот интервал при сбое теряются.

Не путать с RTO (допустимым временем простоя), сроком хранения резервных копий (retention).

Связанные термины: RTO, SLA, lifecycle-политика, бакет.

SLA (соглашение об уровне обслуживания)

SLA (service-level agreement, соглашение об уровне обслуживания) — это часть договора, которая фиксирует измеримые показатели качества услуги, порядок их измерения и ответственность провайдера при невыполнении.

Это договорной документ. Основные показатели SLA облачных и сетевых услуг: доступность в процентах за расчётный период, время реакции и решения обращений, иногда задержка и потери пакетов. Процент доступности переводится в допустимый простой арифметически: 99,9% за 30-дневный месяц — 43,2 минуты, 99,99% — 4,32 минуты. Существенны детали: что считается недоступностью, исключаются ли плановые работы, кто измеряет, какая положена компенсация — как правило, скидка на следующий счёт, а не возмещение убытков. Внутренние цели называют SLO, измеряемые метрики — SLI.

Пример. При выборе провайдера компания сравнивает в SLA не только процент доступности, но и размер компенсации.

Не путать с SLO — внутренней целью без договорных обязательств.

Связанные термины: RTO, RPO, IaaS, задержка.