преимущества CDN в плане производительности. Решение обычно представляет собой компромисс: CDN генерирует сертификат от имени контент-провайдера и доставляет контент из CDN с помощью этого сертификата, выступая в роли организации. Это позволяет достичь основных целей: шифрования контента, идущего от CDN к пользователю, и его аутентификации для пользователя. Более сложные решения, которые требуют развертывания сертификатов на исходном сервере, также позволяют шифровать трафик между клиентом и узлами кэша. Компания Cloudflare предлагает хороший обзор таких решений на своем сайте по адресу https://cloudflare.com/ssl/.

Переадресация DNS и сопоставление клиентов

Идея использования дерева распределения проста. Гораздо сложнее понять, как сопоставлять клиентов с нужными узлами кэша в этом дереве. Как представляется, эту проблему можно решить с помощью прокси-серверов. Если бы каждый клиент на илл. 7.45 был настроен на использование одного из узлов CDN — в Сиднее, Бостоне или Амстердаме — в качестве кэширующего веб-прокси, распределение было бы древовидным.

Как упоминалось выше, самым распространенным способом сопоставления или направления клиентов к ближайшим узлам кэша CDN является переадресация DNS (DNS redirection). Рассмотрим этот подход более подробно. Предположим, клиент хочет попасть на страницу с URL-адресом http://www.cdn.com/page.html. Чтобы ее загрузить, браузер использует DNS для получения IP-адреса, соответствующего имени www.cdn.com. Этот DNS-поиск осуществляется как обычно. Используя протокол DNS, браузер узнает IP-адрес сервера имен для домена cdn.com, после чего связывается с сервером имен и просит его разрешить имя www.cdn.com. Но поскольку сервер имен запускается CDN-сетью, вместо выдачи одного IP-адреса на все запросы он выясняет IP-адрес клиента и возвращает ответ в зависимости от его местоположения. Ответом будет IP-адрес ближайшего к клиенту узла CDN. Так, если клиент в Сиднее обращается к серверу имен CDN с запросом IP-адреса www.cdn.com, он получит IP-адрес сиднейского узла CDN, а на тот же запрос от клиента в Амстердаме будет выдан IP-адрес амстердамского узла.

Это вполне допустимая стратегия согласно семантике DNS. Мы уже видели, что серверы имен могут возвращать меняющиеся списки IP-адресов. После анализа имени клиент в Сиднее получает страницу от сиднейского узла CDN. Дальнейшие страницы с того же «сервера» будут также взяты непосредственно от этого узла благодаря кэшированию DNS. Весь процесс показан на илл. 7.46.

Сложный вопрос в этом процессе — что значит ближайший узел CDN и как его найти. Это задача сопоставления клиентов (client mapping), которую мы уже упоминали выше. Здесь нужно принять во внимание минимум два фактора. Первый — сетевое расстояние. Сетевой путь клиента к узлу CDN должен быть коротким и иметь высокую пропускную способность (таким образом, загрузка ускоряется). Чтобы определить сетевое местоположение клиента по его IP-адресу, CDN используют заранее вычисленное соответствие. Расстояние до выбранного узла может не быть кратчайшим — значение имеет комбинация длины сетевого пути и его максимальной емкости.

Илл. 7.46. Направление клиентов к ближайшим узлам CDN с использованием DNS

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

Способность авторитетного DNS-сервера CDN сопоставлять клиента с ближайшим узлом кэша CDN зависит от того, может ли он определить местоположение клиента. Как уже упоминалось в разделе, посвященном DNS, современные расширения протокола DNS (например, механизм клиентской подсети EDNS) позволяют авторитетному серверу имен выяснить IP-адрес клиента. Возможный переход на протокол DoH порождает новые сложности, поскольку IP-адрес локального рекурсивного распознавателя может находиться очень далеко от клиента. Если локальный рекурсивный DNS-распознаватель не передает IP-адрес клиента (что обычно и происходит, поскольку весь смысл состоит в защите его личных данных), то CDN-сетям, не выполняющим DNS-разрешение для своих клиентов, очень сложно осуществить сопоставление. С другой стороны, CDN, также использующие DoH-совместимый распознаватель (например, CloudFlare и Google), могут получить значительные преимущества, так как они смогут напрямую выяснять IP-адреса клиентов, отправивших DNS-запросы. При этом запрашиваемый контент зачастую будет находиться непосредственно в данной CDN. Такая централизация службы DNS может произвести еще одно коренное изменение в распределении контента в течение ближайших нескольких лет.

В данном разделе представлено упрощенное описание работы CDN. На практике этот процесс включает в себя множество других важных деталей. К примеру, рано или поздно диски узлов CDN полностью заполняются, поэтому их нужно регулярно очищать. Была проделана большая работа по определению того, когда и какие файлы следует удалять; например, см. книгу Баcу и др. (Basu et al., 2018).

7.5.4. Одноранговые сети

Не каждый может установить CDN из 1000 узлов, расположенных в разных уголках планеты, чтобы распространять свой контент. (На самом деле арендовать 1000 виртуальных машин по всему миру не трудно — индустрия хостинга хорошо развита и конкурентна. Но это лишь первый шаг в установке CDN.) К счастью, имеется доступная альтернатива: она проста в использовании и может распространять огромное количество контента. Это одноранговая, или пиринговая, сеть (Peer-to-Peer network, P2P).

P2P-сети внезапно обрели популярность в 1999 году. Поначалу они массово применялись для нарушения закона: 50 млн пользователей сети Nаpster обменивались защищенными авторским правом песнями без разрешения правообладателей. Позже Nаpster был закрыт в судебном порядке, что вызвало большой общественный резонанс. Однако технология равноправных узлов открывает множество полезных возможностей и для законного использования. Другие системы продолжали развиваться с таким большим интересом со стороны пользователей, что P2P-трафик быстро превзошел веб-трафик. На сегодняшний день самым популярным P2P-протоколом остается BitTorrent. Он широко применяется для распространения видео (лицензионного и общедоступного), а также другого объемного контента (например, дисковые образы дистрибутивов операционных систем), что составляет значительную долю общего интернет-трафика. Мы рассмотрим этот протокол чуть позже.

Общие сведения

Основная идея файлообменных P2P-сетей состоит в том, что множество компьютеров объединяют свои ресурсы, формируя систему распределения контента. Часто это обычные домашние компьютеры; нет никакой необходимости в том, чтобы они располагались в интернет-центрах обработки данных. Эти отдельные компьютеры называются пирами (peer — «равный»); каждый из них может выступать и в роли клиента другого пира, получая его контент, и в роли сервера, предоставляя контент другим пирам. Одноранговые системы интересны отсутствием специализированной инфраструктуры в отличие от CDN. В распространении контента участвуют все узлы, часто без централизованного контроля. У этой технологии существует много областей применения (Карагианнис и др.; Karagiannis et al., 2019).

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