Илл. 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, поскольку видят в ней расширение возможностей обычного пользователя. Причина не только в том, что для запуска CDN нужны усилия большой организации, в то время как любой обладатель компьютера может присоединиться к сети P2P. Сети P2P имеют колоссальную емкость для распространения контента, что может сравниться с крупнейшими веб-сайтами.
Первые одноранговые сети: Napster
Как упоминалось ранее, в первых одноранговых сетях (таких, как Napster) использовалась централизованная служба каталогов. Пользователи устанавливали клиентское ПО для поиска в своем локальном хранилище тех файлов, к которым предоставлялся общий доступ. Затем программа передавала централизованной службе каталогов метаданные, описывающие эти файлы (имя и размер файла, идентификатор пользователя, предоставляющего общий доступ к контенту, и т.д.). Пользователи, желающие загрузить файлы из сети Napster, производили поиск по централизованному серверу каталогов и выясняли, у каких пользователей находился нужный им файл. Сервер сообщал им IP-адрес пира, предоставляющего общий доступ к нужному файлу, после чего клиентское ПО пользователя соединялось с этим хостом напрямую и скачивало файл.
Однако у схемы с централизованным сервером каталогов Napster был побочный эффект. Посторонние пользователи могли достаточно легко узнать, кем были размещены конкретные файлы (то есть фактически сканировать всю сеть). В определенный момент стало очевидно, что значительная часть контента была защищена авторским правом. Это привело к судебному запрету и закрытию сервиса. Также было обнаружено еще одно следствие применения централизованного сервера каталогов: чтобы вывести из строя весь сервис, достаточно было лишь отключить сервер. Без него Napster стал практически непригодным для использования. В качестве ответной меры разработчики новых одноранговых сетей стали проектировать более устойчивые к отключению или сбою системы. Обычно это достигалось путем децентрализации каталога или процесса поиска. Этот подход был взят на вооружение в одноранговых системах следующего поколения, таких как Gnutella.
Децентрализация каталога: Gnutella
Созданная в 2000 году, сеть Gnutella была призвана решить некоторые проблемы, свойственные централизованной службе каталогов Napster, с помощью полностью распределенной функции поиска. В сети Gnutella присоединившийся к сети пир ищет другие подключенные пиры с помощью специального процесса обнаружения. Сначала он связывается с несколькими общеизвестными пирами сети, которые он должен был обнаружить на этапе начальной загрузки. Один из механизмов здесь сводится к тому, чтобы само ПО предоставляло некоторый набор IP-адресов пиров сети Gnutella. Обнаружив этот набор, пир может отправить поисковые запросы этим соседним пирам, те, в свою очередь, передадут их своим соседям, и т.д. Этот общий метод поиска в одноранговой сети часто называют сплетнями (gossip).
Хотя метод сплетен решил некоторые проблемы полуцентрализованных сервисов (таких, как Napster), он быстро столкнулся с рядом других трудностей. Во-первых, в сети Gnutella пиры постоянно присоединялись к сети и покидали ее, ведь это были просто компьютеры других пользователей, которые то и дело подключались и отключались от сети. По сути, у пользователей не было особых причин для того, чтобы оставаться в сети после получения нужных файлов. Такое поведение, фрирайдинг (free-riding), было довольно распространено: около 70 % пользователей не предоставляли никакого собственного контента (Адар и Губерман; Adar and Huberman, 2000). Вторая проблема состояла в том, что лавинообразные методы, и в особенности протокол сплетен, трудно поддаются масштабированию. Это остро проявилось, когда Gnutella стала популярной: увеличение числа участников сети сопровождалось экспоненциальным ростом количества сообщений-сплетен. В результате для пользователей с ограниченной пропускной способностью сеть была практически непригодна. Введение так называемых ультрапиров (ultra-peers) в какой-то мере смягчило проблему, но в целом Gnutella отличалась весьма нерациональным использованием доступных сетевых ресурсов. Трудности с масштабируемостью процесса поиска в сети Gnutella подтолкнули исследователей к использованию распределенных хеш-таблиц (Distributed Hash Tables, DHT). Они направляют процесс поиска в соответствующую одноранговую сеть в зависимости от его хеш-значения. При этом каждый узел этой сети отвечает за предоставление информации, охватывающей лишь некоторое подмножество всего пространства поиска, а DHT-таблица должна направлять запрос к пиру, способному предоставить нужный результат. DHT-таблицы применяются во многих современных одноранговых сетях, включая eDonkey (где DHT-таблица используется для поиска) и BitTorrent (где DHT-таблица нужна для масштабирования процесса отслеживания пиров в сети, о котором мы поговорим в следующем разделе).
Наконец, еще одна проблема заключалась в том, что Gnutella не производила автоматическую проверку содержимого скачиваемых пользователями файлов; в результате в ней появилось много поддельного контента. Почему же так произошло?
Это можно объяснить целым рядом причин. Например, как и любой интернет-сервис, Gnutella может подвергнуться атаке типа «отказ в обслуживании», что и произошло. Одна из самых простых DDoS-атак против сети — атака загрязнения (pollution attack). Такие атаки заполонили Gnutella поддельным контентом. В том, чтобы эти сети стали бесполезными, были крайне заинтересованы представители звукозаписывающей индустрии (в первую очередь Американская ассоциация компаний звукозаписи). Оказалось, что они засоряли подобные сети огромным количеством поддельных материалов, чтобы заставить пользователей отказаться от использования сетей для обмена авторским контентом.