✖


Jump to content

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

(Перенаправлено из сети доставки контента )
(Слева) Распределение на одном сервере
(Справа) Схема распространения 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). Другие строят глобальную сеть и имеют небольшое количество географических точек присутствия. [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

[ редактировать ]

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

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

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

[ редактировать ]

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

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

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

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

[ редактировать ]

В июне 2011 года StreamingMedia.com сообщил, что группа TSP основала операторскую биржу операторов связи (OCX). [31] чтобы соединить свои сети и более напрямую конкурировать с крупными традиционными CDN, такими как Akamai и Limelight Networks , которые имеют обширные точки доступа по всему миру. Таким образом, телекоммуникационные компании создают предложение 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]

Оптимизация и доставка изображений (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), либо предлагая функциональность CDN изначально (ImageEngine). [40] или интеграция с одной из существующих CDN (Cloudinary/Akamai, Imgix/Fastly).

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

  • Сеть доставки контента (CDN) для быстрой доставки изображений.
  • Манипулирование и оптимизация изображений либо «на лету» с помощью директив URL , либо в пакетном режиме (посредством ручной загрузки изображений), либо полностью автоматически (или в их комбинации).
  • Обнаружение устройства (также известное как интеллект устройства), т. е. возможность определять свойства запрашивающего браузера и/или устройства посредством анализа строки User-Agent , заголовков HTTP Accept, Client-Hints или JavaScript . [41]

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

Главное изображение CDN на рынке
Имя CDN Оптимизация изображения Обнаружение устройства
Менеджер изображений Акамай И Пакетный режим на основе заголовка HTTP Accept
Cloudflare польский И полностью автоматический на основе заголовка HTTP Accept
Облачно Через Акамай Пакетная обработка, директивы URL Принять заголовок, Client-Hints
Быстро ввод-вывод И URL-директивы на основе заголовка HTTP Accept
ImageEngine И полностью автоматический WURFL , Client-Hints, заголовок Accept
Имгикс Быстро полностью автоматический Принять заголовок/клиентские подсказки
ПейджКДН И URL-директивы на основе заголовка HTTP Accept
Уменьшить CDN Несколько полностью автоматический на основе заголовка HTTP Accept

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

[ редактировать ]

Бесплатные CDN

[ редактировать ]

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

[ редактировать ]

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

[ редактировать ]

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

[ редактировать ]

Мульти CDN

[ редактировать ]

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

[ редактировать ]

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ «Глобально распределенная доставка контента», Дж. Дилли, Б. Мэггс, Дж. Парих, Х. Прокоп, Р. Ситараман и Б. Вейл, IEEE Internet Computing, том 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 . OCLC   1005898086 .
  4. ^ «Как работают сети доставки контента» . CDNetworks . Архивировано из оригинала 5 сентября 2015 года . Проверено 22 сентября 2015 г.
  5. ^ «Как работают сети доставки контента (CDN)» . NCZOnline . 29 ноября 2011 года. Архивировано из оригинала 1 декабря 2011 года . Проверено 22 сентября 2015 г.
  6. ^ Безопасность, Сеть помощи (27 августа 2014 г.). «470 миллионов сайтов существуют 24 часа, 22% являются вредоносными» . Помогите Net Security . Архивировано из оригинала 1 июля 2019 г. Проверено 1 июля 2019 г.
  7. ^ «Decentraleyes: блокировать отслеживание CDN» . Коллин М. Барретт . 03.02.2016. Архивировано из оригинала 1 июля 2019 г. Проверено 1 июля 2019 г.
  8. ^ «VG Wiesbaden запрещает использование сетей доставки контента» . 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. ^ Перейти обратно: а б «Как создать собственную CDN с использованием BIND, GeoIP, Nginx, Varnish — UNIXy» . 18 июля 2010 г. Архивировано из оригинала 21 июля 2010 г. Проверено 15 октября 2014 г.
  21. ^ «Как создать сеть доставки контента с помощью aiScaler» . Архивировано из оригинала 6 октября 2014 г. Проверено 15 октября 2014 г.
  22. ^ «Netflix переводит трафик на собственную CDN; Akamai, хит Limelight Shrs» . Форбс . 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. ^ Перейти обратно: а б с д и «Сопоставление конечных пользователей: маршрутизация запросов следующего поколения для доставки контента, Ф. Чен, Р. Ситараман и М. Торрес, конференция ACM SIGCOMM, август 2015 г.» (PDF) . Архивировано (PDF) из оригинала 12 августа 2017 г. Проверено 31 октября 2019 г.
  33. ^ «Клиентская подсеть в DNS-запросах» .
  34. ^ «Где сейчас находятся ваши серверы?» . Архивировано из оригинала 15 января 2013 г.
  35. ^ Филелис-Пападопулос, Христос К.; Яннутакис, Константинос М.; Гравванис, Джордж А.; Эндо, Патрисия Такако; Цоварас, Димитриос; Своробей, Сергей; Линн, Тео (01 апреля 2019 г.). «Моделирование больших сетей vCDN: параллельный подход». Практика и теория имитационного моделирования . 92 : 100–114. дои : 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. ^ Перейти обратно: а б с д «Как CDN и международные сети серверов способствуют глобализации» . Хаффингтон Пост . Деларно Дельвикс. 06.09.2016. Архивировано из оригинала 19 сентября 2016 года . Проверено 9 сентября 2016 г.
  46. ^ «Отчет об исследовании рынка сети доставки облачного контента (CDN)» . 05.10.2019. Архивировано из оригинала 07.10.2019 . Проверено 7 октября 2019 г.
  47. ^ «CDN: что нужно знать о сетях доставки контента» . www.computerwoche.de . Архивировано из оригинала 21 марта 2019 г. Проверено 21 марта 2019 г.
  48. ^ Уильямс 2017-08-22T18:00:09.233ZUtilities, Майк (22 августа 2017 г.). «Обзор Warpcache» . ТехРадар . Архивировано из оригинала 21 марта 2019 г. Проверено 21 марта 2019 г. {{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )
  49. ^ Как работает Netflix: (чрезвычайно упрощенные) сложные вещи, которые происходят каждый раз, когда вы нажимаете «Play».

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

[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Content_delivery_network&oldid=1239258357"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: ba9fed225b2b36c53655154892dac908__1723090980
URL1:https://arc.ask3.ru/arc/aa/ba/08/ba9fed225b2b36c53655154892dac908.html
Заголовок, (Title) документа по адресу, URL1:
Content delivery network - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)