stringtranslate.com

Сеть доставки контента

(Слева) Распространение на одном сервере
(Справа) Схема распространения CDN

Сеть доставки контента , или сеть распространения контента ( CDN ), представляет собой географически распределенную сеть прокси-серверов и их центров обработки данных . Целью является обеспечение высокой доступности и производительности за счет пространственного распределения службы относительно конечных пользователей . CDN появились в конце 1990-х годов как средство устранения узких мест в производительности Интернета [1] [2] , когда Интернет начал становиться критически важной средой для людей и предприятий. С тех пор CDN выросли и сегодня обслуживают большую часть интернет-контента, включая веб-объекты (текст, графику и сценарии), загружаемые объекты (медиа-файлы, программное обеспечение, документы), приложения ( электронная коммерция , порталы ), потоковую передачу в реальном времени. СМИ, потоковые медиа по запросу и сайты социальных сетей . [3]

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

CDN — это общий термин, охватывающий различные типы служб доставки контента: потоковое видео , загрузка программного обеспечения, ускорение веб- и мобильного контента, лицензированная/управляемая CDN, прозрачное кэширование и услуги для измерения производительности CDN, балансировка нагрузки , переключение нескольких CDN, аналитика и облако. интеллект. Поставщики CDN могут перейти в другие отрасли, такие как безопасность, защита от DDoS и брандмауэры веб-приложений (WAF), а также оптимизация WAN.

Технологии

Узлы CDN обычно развертываются в нескольких местах, часто на нескольких магистральных сетях Интернета . Преимущества включают снижение затрат на пропускную способность, сокращение времени загрузки страниц и повышение глобальной доступности контента. Количество узлов и серверов, составляющих CDN, варьируется в зависимости от архитектуры, некоторые из них достигают тысяч узлов с десятками тысяч серверов во многих удаленных точках присутствия (PoP). Другие строят глобальную сеть и имеют небольшое количество географических точек присутствия. [4]

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

Большинство провайдеров CDN будут предоставлять свои услуги через различные определенные наборы PoP, в зависимости от желаемого покрытия, например, Соединенные Штаты, международный или глобальный, Азиатско-Тихоокеанский регион и т. д. Эти наборы PoP можно назвать «границами». пограничные узлы», «пограничные серверы» или «пограничные сети», поскольку они будут ближайшей к конечному пользователю границей ресурсов CDN. [5]

Безопасность и конфиденциальность

Поставщики CDN получают прибыль либо от прямых комиссий, выплачиваемых поставщиками контента , использующими их сеть, либо от пользовательской аналитики и данных отслеживания, собранных при загрузке их сценариев на веб-сайты клиентов внутри их браузера . Таким образом, эти сервисы рассматриваются как потенциальные вторжения в конфиденциальность с целью поведенческого таргетинга [6] , и создаются решения для восстановления обслуживания и кэширования ресурсов с одним источником. [7]

В частности, веб-сайт, использующий CDN, может нарушать Общий регламент ЕС по защите данных (GDPR). Например, в 2021 году немецкий суд запретил использование CDN на сайте университета, поскольку это приводило к передаче IP-адреса пользователя в CDN, что нарушало GDPR. [8]

CDN, обслуживающие JavaScript, также рассматривались как способ внедрения вредоносного контента на использующие их страницы. Механизм целостности подресурса был создан для того, чтобы гарантировать, что страница загружает скрипт, содержимое которого известно и ограничено хешем, на который ссылается автор веб-сайта. [9]

Методы создания контентных сетей

Интернет спроектирован по сквозному принципу . [10] Этот принцип сохраняет базовую сеть относительно простой и максимально переносит интеллектуальные функции на конечные точки сети: хосты и клиенты. В результате базовая сеть специализирована, упрощена и оптимизирована только для пересылки пакетов данных.

Сети доставки контента дополняют сквозную транспортную сеть, распределяя по ней множество интеллектуальных приложений, использующих методы, предназначенные для оптимизации доставки контента. Получающееся в результате тесно интегрированное наложение использует веб-кэширование, балансировку нагрузки на сервер, маршрутизацию запросов и службы контента. [11]

Веб-кэши хранят популярный контент на серверах, которые имеют наибольший спрос на запрошенный контент. Эти общие сетевые устройства снижают требования к пропускной способности, снижают нагрузку на сервер и сокращают время ответа клиента для содержимого, хранящегося в кэше. Веб-кэши заполняются на основе запросов пользователей (кэширование по запросу) или на основе предварительно загруженного контента, распространяемого с серверов контента (кэширование по запросу). [12]

Балансировка нагрузки на сервер использует один или несколько методов, включая сервисные (глобальная балансировка нагрузки) или аппаратные (т. е. коммутаторы уровней 4–7 , также известные как веб-коммутатор, коммутатор контента или многоуровневый коммутатор) для распределения трафика между несколькими серверами. серверов или веб-кэшей. Здесь коммутатору назначается один виртуальный IP-адрес . Трафик, поступающий на коммутатор, затем направляется на один из реальных веб-серверов , подключенных к коммутатору. Преимущество этого подхода заключается в балансировке нагрузки, увеличении общей емкости, улучшении масштабируемости и повышении надежности за счет перераспределения нагрузки вышедшего из строя веб-сервера и проверки работоспособности сервера.

Кластер контента или узел обслуживания можно сформировать с помощью коммутатора уровней 4–7 для балансировки нагрузки между несколькими серверами или несколькими веб-кэшами в сети.

Маршрутизация запросов направляет клиентские запросы к источнику контента, который лучше всего может обслужить запрос. Это может включать в себя направление клиентского запроса на ближайший к клиенту сервисный узел или на узел с наибольшей пропускной способностью. Для маршрутизации запроса используются различные алгоритмы. К ним относятся глобальная балансировка нагрузки сервера, маршрутизация запросов на основе DNS, динамическая генерация метафайлов, перезапись HTML [13] и произвольная рассылка . [14] Близость — выбор ближайшего узла обслуживания — оценивается с использованием различных методов, включая реактивное зондирование, упреждающее зондирование и мониторинг соединения. [11]

CDN используют различные методы доставки контента, включая, помимо прочего, копирование ресурсов вручную, активные веб-кэши и глобальные аппаратные балансировщики нагрузки.

Протоколы контент-сервиса

Несколько наборов протоколов предназначены для обеспечения доступа к широкому спектру услуг контента, распределенных по сети контента. Протокол адаптации интернет-контента (ICAP) был разработан в конце 1990-х годов [15] [16] как открытый стандарт для подключения серверов приложений. Недавно разработанное и надежное решение обеспечивается протоколом Open Pluggable Edge Services (OPES). [17] Эта архитектура определяет сервисные приложения OPES, которые могут находиться на самом процессоре OPES или выполняться удаленно на сервере Callout. Edge SideIncludes или ESI — это небольшой язык разметки для сборки динамического веб-контента на пограничном уровне. Веб-сайты довольно часто создают контент. Это может быть связано с изменением контента, такого как каталоги или форумы, или из-за персонализации. Это создает проблему для систем кэширования. Чтобы решить эту проблему, группа компаний создала ESI.

Одноранговые CDN

В одноранговых (P2P) сетях доставки контента клиенты предоставляют ресурсы, а также используют их. Это означает, что, в отличие от клиент-серверных систем, контент-ориентированные сети могут работать лучше, когда все больше пользователей начинают получать доступ к контенту (особенно с такими протоколами, как Bittorrent , которые требуют от пользователей совместного использования). Это свойство является одним из основных преимуществ использования P2P-сетей, поскольку оно делает затраты на установку и эксплуатацию очень низкими для оригинального дистрибьютора контента. [18] [19]

Частные CDN

Если владельцев контента не устраивают возможности или стоимость коммерческой услуги CDN, они могут создать собственную CDN. Это называется частным CDN. Частный CDN состоит из PoP (точек присутствия), которые предоставляют контент только своему владельцу. Этими PoP могут быть кэширующие серверы, [20] обратные прокси-серверы или контроллеры доставки приложений. [21] Это может быть просто два сервера кэширования, [20] или достаточно большой, чтобы обслуживать петабайты контента. [22]

Крупные сети распространения контента могут даже построить и настроить свою собственную частную сеть для распространения копий контента по местам кэша. [23] [24] Такие частные сети обычно используются вместе с сетями общего пользования в качестве резервного варианта в случае, если пропускной способности частной сети недостаточно или произошел сбой, который приводит к снижению пропускной способности. Поскольку один и тот же контент приходится распределять по множеству мест, для снижения потребления полосы пропускания можно использовать различные методы многоадресной рассылки . В частных сетях также было предложено выбирать деревья многоадресной рассылки в соответствии с условиями загрузки сети, чтобы более эффективно использовать доступную пропускную способность сети. [25] [26]

Тенденции CDN

Появление телекоммуникационных CDN

Быстрый рост потокового видеотрафика [ 27] требует крупных капитальных затрат со стороны провайдеров широкополосного доступа [28] для удовлетворения этого спроса и удержания абонентов путем предоставления достаточно хорошего качества обслуживания .

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

Преимущества телекоммуникационной сети CDN

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

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

Напротив, развертывание телекоммуникационных CDN позволяет операторам реализовывать свои собственные операции по управлению контентом, [29] [30] , что позволяет им лучше контролировать использование своих ресурсов и, как таковое, обеспечивать лучшее качество обслуживания и опыт своим конечным пользователям.

Федеративные CDN и открытое кэширование

В июне 2011 года StreamingMedia.com сообщил, что группа TSP основала операторскую биржу операторов связи (OCX) [31] для объединения своих сетей и более прямой конкуренции с крупными традиционными CDN, такими как Akamai и Limelight Networks , которые имеют обширные PoP по всему миру. Таким образом, телекоммуникационные компании создают предложение Federated CDN, которое более интересно для контент-провайдера , желающего доставлять свой контент совокупной аудитории этой федерации.

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

Спецификация Open Caching от Streaming Media Alliance определяет набор API-интерфейсов , которые позволяют поставщику контента доставлять свой контент с использованием нескольких CDN согласованным способом, одинаково видя каждого поставщика CDN через эти API.

Улучшение производительности CDN с помощью механизмов расширения для DNS

Задержка (RTT), с которой сталкиваются клиенты с нелокальными преобразователями («высокая»), резко сократилась, когда CDN развернула расширение EDNS0 в апреле 2014 года, в то время как задержка клиентов с локальными преобразователями не затронута этим изменением («низкая» ). [32]

Традиционно CDN использовали IP-адрес рекурсивного преобразователя DNS клиента для географического определения местоположения клиента. Хотя во многих ситуациях это разумный подход, он приводит к снижению производительности клиента, если клиент использует нелокальный рекурсивный преобразователь DNS, который находится далеко. Например, CDN может перенаправлять запросы от клиента в Индии на свой пограничный сервер в Сингапуре, если этот клиент использует общедоступный преобразователь DNS в Сингапуре, что приводит к снижению производительности этого клиента. Действительно, недавнее исследование [32] показало, что во многих странах, где общедоступные преобразователи DNS широко используются, среднее расстояние между клиентами и их рекурсивными преобразователями DNS может достигать тысячи миль. В августе 2011 года глобальный консорциум ведущих интернет-провайдеров во главе с Google объявил об официальной реализации проекта IETF Internet Draft edns-client-subnet [33] , который предназначен для точной локализации ответов разрешения DNS. В инициативе участвует ограниченное число ведущих поставщиков услуг DNS, таких как Google Public DNS [ 34] и поставщиков услуг CDN. Благодаря опции EDNS0 edns-client-subnet сети CDN теперь могут использовать IP-адрес подсети запрашивающего клиента при разрешении DNS-запросов. Этот подход, называемый сопоставлением конечных пользователей, [32] был принят в CDN, и было показано, что он радикально снижает задержки в обоих направлениях и повышает производительность для клиентов, которые используют общедоступный DNS или другие нелокальные преобразователи. Однако использование EDNS0 также имеет недостатки, поскольку оно снижает эффективность кэширования разрешений на рекурсивных преобразователях, [32] увеличивает общий трафик разрешения DNS, [32] и поднимает проблему конфиденциальности, связанную с раскрытием подсети клиента.

Виртуальный CDN (vCDN)

Технологии виртуализации используются для развертывания виртуальных CDN (vCDN) с целью снизить затраты поставщиков контента и в то же время повысить эластичность и уменьшить задержки обслуживания. С помощью vCDN можно избежать традиционных ограничений CDN, таких как производительность, надежность и доступность, поскольку виртуальные кэши развертываются динамически (в виде виртуальных машин или контейнеров) на физических серверах, распределенных по географическому охвату провайдера. Поскольку размещение виртуального кэша зависит как от типа контента, так и от географического местоположения сервера или конечного пользователя, vCDN оказывают значительное влияние на предоставление услуг и перегрузку сети. [35] [36] [37] [38]

Оптимизация и доставка изображений (CDN изображений)

В 2017 году Адди Османи из Google начал называть программные решения, которые могут естественным образом интегрироваться с парадигмой адаптивного веб-дизайна (с особым упором на элемент <picture>), как Image CDN . [39] Это выражение относится к способности веб-архитектуры обслуживать несколько версий одного и того же изображения через HTTP, в зависимости от свойств браузера, запрашивающего его, что определяется либо браузером, либо логикой на стороне сервера. Целью CDN изображений, по замыслу Google, было предоставление высококачественных изображений (или, лучше, изображений, воспринимаемых человеческим глазом как высококачественные), сохраняя при этом скорость загрузки, тем самым способствуя улучшению пользовательского опыта (UX). [ нужна цитата ]

Возможно, термин Image CDN изначально был неправильным, поскольку ни Cloudinary , ни Imgix (примеры, приведенные Google в руководстве Адди Османи за 2017 год) в то время не были CDN в классическом смысле этого термина. [39] Однако вскоре после этого несколько компаний предложили решения, которые позволили разработчикам обслуживать разные версии своих графических ресурсов в соответствии с несколькими стратегиями. Многие из этих решений были построены на основе традиционных CDN, таких как Akamai , CloudFront , Fastly , Edgecast и Cloudflare . В то же время другие решения, которые уже предоставляли сервис мульти-сервирования изображений, присоединились к определению Image CDN, либо предлагая функциональность CDN изначально (ImageEngine) [40] , либо интегрируясь с одной из существующих CDN (Cloudinary/Akamai, Imgix/Fastly). .

Хотя дать общепринятое определение того, что такое Image CDN, может оказаться невозможным, вообще говоря, Image CDN поддерживает следующие три компонента: [41]

В следующей таблице обобщена текущая ситуация с основными программными CDN в этой области: [42]

Известные поставщики услуг доставки контента

Бесплатные CDN

Традиционные коммерческие CDN

CDN телекоммуникационных компаний

Коммерческие CDN, использующие P2P для доставки

Мульти CDN

Собственный CDN

Смотрите также

Рекомендации

  1. ^ «Глобально распределенная доставка контента, Дж. Дилли, Б. Мэггс, Дж. Парих, Х. Прокоп, Р. Ситараман и Б. Вейл, Интернет-вычисления IEEE, том 6, выпуск 5, ноябрь 2002 г.» ( PDF) . Архивировано (PDF) из оригинала 9 августа 2017 г. Проверено 25 октября 2019 г.
  2. ^ Нигрен, Э.; Ситараман Р.К.; Сан, Дж. (2010). «Сеть Akamai: платформа для высокопроизводительных интернет-приложений» (PDF) . Обзор операционных систем ACM SIGOPS . 44 (3): 2–19. дои : 10.1145/1842733.1842736. S2CID  207181702. Архивировано (PDF) из оригинала 13 сентября 2012 г. . Проверено 19 ноября 2012 г.
  3. ^ Эви, Немет (2018). «Глава 19, Веб-хостинг, Сети доставки контента». Руководство по системному администрированию UNIX и Linux (Пятое изд.). Бостон: Pearson Education. п. 690. ИСБН 9780134277554. ОКЛК  1005898086.
  4. ^ «Как работают сети доставки контента» . CDNetworks . Архивировано из оригинала 5 сентября 2015 года . Проверено 22 сентября 2015 г.
  5. ^ «Как работают сети доставки контента (CDN)» . NCZOnline . 29 ноября 2011 г. Архивировано из оригинала 1 декабря 2011 г. Проверено 22 сентября 2015 г.
  6. ^ Безопасность, Help Net (27 августа 2014 г.). «470 миллионов сайтов существуют 24 часа, 22% являются вредоносными». Помогите Net Security . Архивировано из оригинала 1 июля 2019 г. Проверено 1 июля 2019 г.
  7. ^ «Decentraleyes: заблокировать отслеживание CDN» . Коллин М. Барретт . 03.02.2016. Архивировано из оригинала 1 июля 2019 г. Проверено 1 июля 2019 г.
  8. ^ "VG Wiesbaden verbietet die Nutzung von Content Delivery Networks" . www.taylorwessing.com (на немецком языке). 14 декабря 2021 г. Проверено 2 марта 2023 г.
  9. ^ «Целостность субресурса». Веб-документы MDN . Архивировано из оригинала 26 июня 2019 г. Проверено 1 июля 2019 г.
  10. ^ Дж. Х. Зальцер ; Д. П. Рид ; Д. Д. Кларк (1 ноября 1984 г.). «Сквозные аргументы в проектировании систем» (PDF) . Транзакции ACM в компьютерных системах . 2 (4): 277–288. дои : 10.1145/357401.357402. ISSN  0734-2071. S2CID  215746877. Викиданные  Q56503280 . Проверено 11 ноября 2006 г.
  11. ^ Аб Хофманн, Маркус; Бомонт, Леланд Р. (2005). Контент-сеть: архитектура, протоколы и практика . Издательство Морган Кауфманн. ISBN 1-55860-834-6.
  12. ^ Беставрос, Азер (март 1996 г.). «Спекулятивное распространение данных и обслуживание для снижения нагрузки на сервер, сетевого трафика и времени обслуживания распределенных информационных систем» (PDF) . Материалы ICDE'96: Международная конференция по инженерии данных 1996 года . 1996 : 180–189. Архивировано (PDF) из оригинала 3 июля 2010 г. Проверено 28 мая 2017 г.
  13. ^ RFC  3568 Барбир, А., Каин, Б., Наир, Р., Спатчек, О.: «Известные механизмы маршрутизации запросов контентной сети (CN),» июль 2003 г.
  14. ^ RFC  1546 Партридж, К., Мендес, Т., Милликен, В.: «Host Anycasting Services», ноябрь 1993 г.
  15. ^ RFC  3507 Элсон Дж., Серпа А.: «Протокол адаптации интернет-контента (ICAP)», апрель 2003 г.
  16. ^ Форум ICAP
  17. ^ RFC  3835 Барбир А., Пенно Р., Чен Р., Хофманн М. и Орман Х.: «Архитектура открытых подключаемых пограничных служб (OPES)», август 2004 г.
  18. ^ Ли, Джин (2008). «О доставке контента по одноранговой сети (P2P)» (PDF) . Одноранговые сети и приложения . 1 (1): 45–63. дои : 10.1007/s12083-007-0003-1. S2CID  16438304. Архивировано (PDF) из оригинала 4 октября 2013 г. Проверено 11 августа 2013 г.
  19. ^ Штуцбах, Дэниел; и другие. (2005). «Масштабируемость массовой одноранговой доставки контента» (PDF) . В Бутабе Рауф; и другие. (ред.). СЕТИ 2005 -- Сетевые технологии, услуги и протоколы; Производительность компьютерных и коммуникационных сетей; Системы мобильной и беспроводной связи . Спрингер. стр. 15–26. ISBN 978-3-540-25809-4.
  20. ^ ab «Как создать собственную CDN, используя BIND, GeoIP, Nginx, Varnish — UNIXy». 18 июля 2010 г. Архивировано из оригинала 21 июля 2010 г. Проверено 15 октября 2014 г.
  21. ^ «Как создать сеть доставки контента с помощью aiScaler» . Архивировано из оригинала 6 октября 2014 г. Проверено 15 октября 2014 г.
  22. ^ «Netflix переводит трафик на собственную CDN; Akamai, Limelight Shrs Hit» . Форбс . 5 июня 2012 года. Архивировано из оригинала 19 октября 2017 года . Проверено 26 августа 2017 г.
  23. ^ Микель Хименес; и другие. (1 мая 2017 г.). «Создание Express Backbone: новая сеть дальней связи Facebook». Архивировано из оригинала 24 октября 2017 года . Проверено 27 октября 2017 г.
  24. ^ «Глобальная сеть между центрами обработки данных с централизованным TE с использованием SDN и OpenFlow» (PDF) . 2012. Архивировано (PDF) из оригинала 28 октября 2017 года . Проверено 27 октября 2017 г.
  25. ^ М. Нурмохаммадпур; и другие. (10 июля 2017 г.). «DCCast: эффективная передача данных из одной точки в другую между центрами обработки данных». УСЕНИКС . Проверено 26 июля 2017 г.
  26. ^ М. Нурмохаммадпур; и другие. (2018). «QuickCast: быстрая и эффективная передача данных между центрами обработки данных с использованием когорт дерева пересылки» . Проверено 23 января 2018 г.
  27. ^ «Онлайн-видео демонстрирует огромный рост, что стимулирует некоторые серьезные обновления» . КремниевыйУГОЛ . 03.03.2011. Архивировано из оригинала 30 августа 2011 г. Проверено 22 июля 2011 г.
  28. ^ «Общие капитальные затраты в телекоммуникациях вырастут в 2011 году за счет инвестиций в видео, 3G, LTE» . сотовые новости . Архивировано из оригинала 25 марта 2011 г. Проверено 22 июля 2011 г.
  29. ^ Д. Тансер, М. Хараламбидес, Р. Ланда, Г. Павлу, «Больше контроля над сетевыми ресурсами: перспектива кэширования интернет-провайдера», материалы конференции IEEE / IFIP по управлению сетями и услугами (CNSM), Цюрих, Швейцария, октябрь. 2013.
  30. ^ М. Клейс, Д. Тансер, Дж. Фамай, М. Хараламбидес, С. Латр, Ф. Де Турк, Г. Павлу, «Проактивное многопользовательское управление кэшем для виртуализированных сетей интернет-провайдеров», материалы конференции IEEE / IFIP на Управление сетями и услугами (CNSM), Рио-де-Жанейро, Бразилия, ноябрь 2014 г.
  31. ^ «Телекомпании и операторы связи формируют новую федеративную группу CDN под названием OCX (операторская биржа операторов связи)» . Дэн Рэйберн – StreamingMediaBlog.com . 13 декабря 2017 г. Архивировано из оригинала 20 июля 2011 г. Проверено 22 июля 2011 г.
  32. ^ abcde «Сопоставление конечных пользователей: маршрутизация запросов следующего поколения для доставки контента, Ф. Чен, Р. Ситараман и М. Торрес, конференция ACM SIGCOMM, август 2015 г.» (PDF) . Архивировано (PDF) из оригинала 12 августа 2017 г. Проверено 31 октября 2019 г.
  33. ^ «Клиентская подсеть в DNS-запросах» .
  34. ^ «Где сейчас находятся ваши серверы?». Архивировано из оригинала 15 января 2013 г.
  35. ^ Филелис-Пападопулос, Христос К.; Яннутакис, Константинос М.; Гравванис, Джордж А.; Эндо, Патрисия Такако; Цоварас, Димитриос; Своробей, Сергей; Линн, Тео (01 апреля 2019 г.). «Моделирование больших сетей vCDN: параллельный подход». Практика и теория имитационного моделирования . 92 : 100–114. doi :10.1016/j.simpat.2019.01.001. ISSN  1569-190Х. S2CID  67752426.
  36. ^ Филелис-Пападопулос, Христос К.; Эндо, Патрисия Такако; Бендешаш, Малика; Своробей, Сергей; Яннутакис, Константинос М.; Гравванис, Джордж А.; Цоварас, Димитриос; Бирн, Джеймс; Линн, Тео (01 января 2020 г.). «К моделированию и оптимизации размещения кэша в крупных сетях распространения виртуального контента». Журнал вычислительной науки . 39 : 101052. doi : 10.1016/j.jocs.2019.101052 . ISSN  1877-7503.
  37. ^ Ибн-Хедер, Хатем; Абд-Эльрахман, Эмад; Камаль, Ахмед Э.; Афифи, Хоссам (19 июня 2017 г.). «OPAC: оптимальный алгоритм размещения виртуальной CDN». Компьютерная сеть . 120 : 12–27. дои : 10.1016/j.comnet.2017.04.009. ISSN  1389-1286.
  38. ^ Хедер, Хатем; Абд-Эльрахман, Эмад; Афифи, Хосам; Маро, Мишель (октябрь 2017 г.). «Оптимальный и экономически эффективный алгоритм виртуальной оркестровки CDN». 42-я конференция IEEE по локальным компьютерным сетям (LCN), 2017 г. Сингапур: IEEE. стр. 61–69. дои : 10.1109/LCN.2017.115. ISBN 978-1-5090-6523-3. S2CID  44243386.
  39. ^ аб Адди Османи. «Основная оптимизация изображения» . Проверено 13 мая 2020 г.
  40. ↑ Джон Арне Сетерос (26 апреля 2017 г.). «Позвольте сети доставки контента оптимизировать ваши изображения» . Проверено 13 мая 2020 г.
  41. ^ аб Кэти Хемпениус. «Используйте CDN изображений для оптимизации изображений» . Проверено 13 мая 2020 г.
  42. ↑ Максимилиано Фиртман (18 сентября 2019 г.). «Ускоренная отрисовка показателей с помощью адаптивных CDN для оптимизации изображений» . Проверено 13 мая 2020 г.
  43. ^ «4 лучших CDN-сервиса для размещения библиотек с открытым исходным кодом | opensource.com» . opensource.com. Архивировано из оригинала 18 апреля 2019 года . Проверено 18 апреля 2019 г.
  44. ^ «Статистика использования и рыночная доля сетей доставки контента JavaScript для веб-сайтов» . W3Techs. Архивировано из оригинала 12 апреля 2019 года . Проверено 17 апреля 2019 г.
  45. ^ abcd «Как CDN и международные сети серверов способствуют глобализации» . Хаффингтон Пост . Деларно Дельвикс. 06.09.2016. Архивировано из оригинала 19 сентября 2016 года . Проверено 9 сентября 2016 г.
  46. ^ «Последний список поставщиков CDN, продающих вещательным компаниям, операторам связи и MSO» . 13 февраля 2017 г.
  47. ^ «Отчет об исследовании рынка сети доставки облачного контента (CDN)» . 05.10.2019. Архивировано из оригинала 07.10.2019 . Проверено 7 октября 2019 г.
  48. ^ "CDN: Были ли сети доставки контента более доступными" . www.computerwoche.de . Архивировано из оригинала 21 марта 2019 г. Проверено 21 марта 2019 г.
  49. ^ Уильямс 2017-08-22T18:00:09.233ZUtilities, Майк (22 августа 2017 г.). «Обзор Warpcache». ТехРадар . Архивировано из оригинала 21 марта 2019 г. Проверено 21 марта 2019 г.{{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )
  50. ^ Как работает Netflix: (чрезвычайно упрощенные) сложные вещи, которые происходят каждый раз, когда вы нажимаете «Play».

дальнейшее чтение