stringtranslate.com

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

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

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

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

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

Известные поставщики услуг доставки контента включают Akamai Technologies , Edgio , Cloudflare , Amazon CloudFront , Fastly и Google Cloud CDN .

Технологии

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

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

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

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

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

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

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

Методы контент-сетинга

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

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

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

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

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

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

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

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

Несколько наборов протоколов предназначены для предоставления доступа к широкому спектру контент-сервисов, распределенных по всей контентной сети. Протокол адаптации интернет-контента (ICAP) был разработан в конце 1990-х годов [15] [16] для предоставления открытого стандарта для подключения серверов приложений. Более недавно определенное и надежное решение предоставляется протоколом Open Pluggable Edge Services (OPES). [17] Эта архитектура определяет приложения-сервисы OPES, которые могут находиться на самом процессоре OPES или выполняться удаленно на сервере вызовов. Edge Side includes или 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 основала Operator Carrier Exchange (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. С опцией edns-client-subnet EDNS0 CDN теперь могут использовать IP-адрес подсети запрашивающего клиента при разрешении DNS-запросов. Этот подход, называемый сопоставлением конечного пользователя [32] , был принят CDN, и было показано, что он радикально сокращает задержки в обоих направлениях и повышает производительность для клиентов, которые используют публичные DNS или другие нелокальные резолверы. Однако использование EDNS0 также имеет недостатки, поскольку оно снижает эффективность кэширования разрешений на рекурсивных резолверах [32] , увеличивает общий трафик разрешения DNS [32] и поднимает проблему конфиденциальности раскрытия подсети клиента.

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

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

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

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

Коммерческое использование P2P для доставки

Мульти

В доме

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

Ссылки

  1. ^ "Глобально распределенная доставка контента, J. ​​Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman и B. Weihl, IEEE Internet Computing, том 6, выпуск 5, ноябрь 2002 г." (PDF) . Архивировано (PDF) из оригинала 2017-08-09 . Получено 2019-10-25 .
  2. ^ Nygren., E.; Sitaraman RK; Sun, J. (2010). "The Akamai Network: A Platform for High-Performance Internet Applications" (PDF) . Обзор операционных систем ACM SIGOPS . 44 (3): 2–19. doi :10.1145/1842733.1842736. S2CID  207181702. Архивировано (PDF) из оригинала 13 сентября 2012 г. . Получено 19 ноября 2012 г. .
  3. ^ Эви, Немет (2018). «Глава 19, Веб-хостинг, Сети доставки контента». Справочник по системному администрированию UNIX и Linux (Пятое изд.). Бостон: Pearson Education. стр. 690. ISBN 9780134277554. OCLC  1005898086.
  4. ^ "Как работают сети доставки контента". CDNetworks . Архивировано из оригинала 5 сентября 2015 г. Получено 22 сентября 2015 г.
  5. ^ "Как работают сети доставки контента (CDN)". NCZOnline . 29 ноября 2011 г. Архивировано из оригинала 1 декабря 2011 г. Получено 22 сентября 2015 г.
  6. ^ Безопасность, Help Net (2014-08-27). "470 миллионов сайтов существуют в течение 24 часов, 22% из них вредоносны". Help Net Security . Архивировано из оригинала 2019-07-01 . Получено 2019-07-01 .
  7. ^ "Decentraleyes: Block CDN Tracking". Колин М. Барретт . 2016-02-03. Архивировано из оригинала 2019-07-01 . Получено 2019-07-01 .
  8. ^ "VG Wiesbaden verbietet die Nutzung von Content Delivery Networks" . www.taylorwessing.com (на немецком языке). 14 декабря 2021 г. Проверено 2 марта 2023 г.
  9. ^ "Целостность подресурса". MDN Web Docs . Архивировано из оригинала 2019-06-26 . Получено 2019-07-01 .
  10. ^ JH Saltzer ; DP Reed ; DD Clark (1 ноября 1984 г.). «Сквозные аргументы в проектировании систем» (PDF) . ACM Transactions on Computer Systems . 2 (4): 277–288. doi :10.1145/357401.357402. ISSN  0734-2071. S2CID  215746877. Wikidata  Q56503280 . Получено 11 ноября 2006 г. .
  11. ^ ab Хофманн, Маркус; Бомонт, Леланд Р. (2005). Контент-сети: архитектура, протоколы и практика . Издательство Morgan Kaufmann. ISBN 1-55860-834-6.
  12. ^ Bestavros, Azer (март 1996 г.). "Speculative Data Dissemination and Service to Reduce Server Load, Network Traffic and Service Time for Distributed Information Systems" (PDF) . Труды ICDE'96: Международная конференция по инжинирингу данных 1996 г. . 1996 : 180–189. Архивировано (PDF) из оригинала 2010-07-03 . Получено 2017-05-28 .
  13. ^ RFC  3568 Барбир, А., Кейн, Б., Наир, Р., Шпатчек, О.: «Известные механизмы маршрутизации запросов в сети контента (CN)», июль 2003 г.
  14. ↑ RFC  1546 Партридж, К., Мендес, Т., Милликен, У.: «Услуги вещания через Anycasting», ноябрь 1993 г.
  15. ^ RFC  3507 Элсон, Дж., Серпа, А.: «Протокол адаптации интернет-контента (ICAP)», апрель 2003 г.
  16. ^ Форум ICAP
  17. ^ RFC  3835 Барбир, А., Пенно, Р., Чен, Р., Хофманн, М. и Орман, Х.: «Архитектура для открытых подключаемых пограничных служб (OPES)», август 2004 г.
  18. ^ Ли, Цзинь (2008). «О доставке контента по пиринговой сети (P2P)» (PDF) . Peer-to-Peer Networking and Applications . 1 (1): 45–63. doi :10.1007/s12083-007-0003-1. S2CID  16438304. Архивировано (PDF) из оригинала 2013-10-04 . Получено 2013-08-11 .
  19. ^ Штутцбах, Даниэль; и др. (2005). «Масштабируемость доставки контента роем одноранговых сетей» (PDF) . В Бутабе, Рауф; и др. (ред.). СЕТИ 2005 — Сетевые технологии, службы и протоколы; Производительность компьютерных и коммуникационных сетей; Мобильные и беспроводные коммуникационные системы . Springer. стр. 15–26. ISBN 978-3-540-25809-4.
  20. ^ ab "Как построить собственную CDN с помощью BIND, GeoIP, Nginx, Varnish - UNIXy". 2010-07-18. Архивировано из оригинала 2010-07-21 . Получено 2014-10-15 .
  21. ^ "Как создать свою сеть доставки контента с помощью aiScaler". Архивировано из оригинала 2014-10-06 . Получено 2014-10-15 .
  22. ^ "Netflix переводит трафик на собственную сеть CDN; Akamai, Limelight Shrs Hit". Forbes . 5 июня 2012 г. Архивировано из оригинала 19 октября 2017 г. Получено 26 августа 2017 г.
  23. ^ Микель Хименес и др. (1 мая 2017 г.). «Создание магистральной линии связи Express: новая дальняя сеть Facebook». Архивировано из оригинала 24 октября 2017 г. Получено 27 октября 2017 г.
  24. ^ «Inter-Datacenter WAN с централизованным TE с использованием SDN и OpenFlow» (PDF) . 2012. Архивировано (PDF) из оригинала 28 октября 2017 г. . Получено 27 октября 2017 г. .
  25. ^ M. Noormohammadpour; et al. (10 июля 2017 г.). "DCCast: Эффективные передачи данных из точки в многоточку через центры обработки данных". USENIX . Получено 26 июля 2017 г. .
  26. ^ M. Noormohammadpour; et al. (2018). "QuickCast: Быстрые и эффективные передачи между центрами обработки данных с использованием когорт дерева пересылки" . Получено 23 января 2018 г.
  27. ^ "Онлайн-видео демонстрирует колоссальный рост, что приводит к некоторым крупным обновлениям". SiliconANGLE . 2011-03-03. Архивировано из оригинала 2011-08-30 . Получено 2011-07-22 .
  28. ^ "Общие капитальные затраты на телекоммуникации вырастут в 2011 году из-за инвестиций в видео, 3G и LTE". cellular-news . Архивировано из оригинала 25.03.2011 . Получено 22.07.2011 .
  29. ^ Д. Тунцер, М. Хараламбидес, Р. Ланда, Г. Павлоу, «Больше контроля над сетевыми ресурсами: перспектива кэширования интернет-провайдера», труды конференции IEEE/IFIP по управлению сетями и услугами (CNSM), Цюрих, Швейцария, октябрь 2013 г.
  30. ^ M. Claeys, D. Tuncer, J. Famaey, M. Charalambides, S. Latre, F. De Turck, G. Pavlou, «Проактивное многопользовательское управление кэшем для виртуализированных сетей интернет-провайдеров», труды конференции IEEE/IFIP по управлению сетями и услугами (CNSM), Рио-де-Жанейро, Бразилия, ноябрь 2014 г.
  31. ^ "Телекоммуникационные компании и операторы формируют новую федеративную группу CDN под названием OCX (Operator Carrier Exchange)". Дэн Рэйберн – StreamingMediaBlog.com . 2017-12-13. Архивировано из оригинала 20-07-2011 . Получено 22-07-2011 .
  32. ^ abcde "End-User Mapping: Next Generation Request Routing for Content Delivery, авторы F. Chen, R. Sitaraman и M. Torres, конференция ACM SIGCOMM, август 2015 г." (PDF) . Архивировано (PDF) из оригинала 2017-08-12 . Получено 2019-10-31 .
  33. ^ «Клиентская подсеть в DNS-запросах».
  34. ^ «Где в настоящее время находятся ваши серверы?». Архивировано из оригинала 2013-01-15.
  35. ^ Filelis-Papadopoulos, Christos K.; Giannoutakis, Konstantinos M.; Gravvanis, George A.; Endo, Patricia Takako; Tzovaras, Dimitrios; Svorobej, Sergej; Lynn, Theo (2019-04-01). "Моделирование больших сетей vCDN: параллельный подход". Simulation Modelling Practice and Theory . 92 : 100–114. doi :10.1016/j.simpat.2019.01.001. ISSN  1569-190X. S2CID  67752426.
  36. ^ Filelis-Papadopoulos, Christos K.; Endo, Patricia Takako; Bendechache, Malika; Svorobej, Sergej; Giannoutakis, Konstantinos M.; Gravvanis, George A.; Tzovaras, Dimitrios; Byrne, James; Lynn, Theo (2020-01-01). "К моделированию и оптимизации размещения кэша в больших сетях распространения виртуального контента". Journal of Computational Science . 39 : 101052. doi : 10.1016/j.jocs.2019.101052 . ISSN  1877-7503.
  37. ^ Ибн-Хедер, Хатем; Абд-Эльрахман, Эмад; Камаль, Ахмед Э.; Афифи, Хоссам (19.06.2017). «OPAC: оптимальный алгоритм размещения для виртуальной CDN». Компьютерные сети . 120 : 12–27. doi :10.1016/j.comnet.2017.04.009. ISSN  1389-1286.
  38. ^ Khedher, Hatem; Abd-Elrahman, Emad; Afifi, Hossam; Marot, Michel (октябрь 2017 г.). «Оптимальный и экономичный алгоритм для оркестровки виртуальных CDN». IEEE 42-я конференция по локальным компьютерным сетям (LCN) 2017 г. Сингапур: IEEE. стр. 61–69. doi :10.1109/LCN.2017.115. ISBN 978-1-5090-6523-3. S2CID  44243386.
  39. ^ ab Эдди Османи. "Essential Image Optimization" . Получено 13 мая 2020 г. .
  40. ^ Jon Arne Sæterås (26 апреля 2017 г.). «Пусть сеть доставки контента оптимизирует ваши изображения» . Получено 13 мая 2020 г.
  41. ^ ab Кэти Хемпениус. "Используйте 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 и международные серверные сети способствуют глобализации". The Huffington Post . Delarno Delvix. 2016-09-06. Архивировано из оригинала 19 сентября 2016 года . Получено 9 сентября 2016 года .
  46. ^ "Отчет об исследовании рынка облачной сети доставки контента (CDN)". 2019-10-05. Архивировано из оригинала 2019-10-07 . Получено 2019-10-07 .
  47. ^ "CDN: Были ли сети доставки контента более доступными" . www.computerwoche.de . Архивировано из оригинала 21 марта 2019 г. Проверено 21 марта 2019 г.
  48. ^ Williams 2017-08-22T18:00:09.233ZUtilities, Майк (22 августа 2017 г.). "Обзор Warpcache". TechRadar . Архивировано из оригинала 2019-03-21 . Получено 2019-03-21 .{{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )
  49. ^ Как работает Netflix: (крайне упрощенно) сложные вещи, которые происходят каждый раз, когда вы нажимаете «Воспроизвести»

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