Чтение онлайн

Использование древовидной структуры имеет три преимущества. Во-первых, распространение контента может масштабироваться до любого необходимого числа клиентов при увеличении количества узлов CDN (и уровней дерева, когда распределение среди узлов CDN станет узким местом). Древовидная структура эффективна независимо от количества клиентов. Исходный сервер не перегружен, ведь он взаимодействует с клиентами через дерево узлов CDN; ему не придется самому отвечать на каждый запрос страницы. Во-вторых, каждый клиент получает хорошую производительность за счет доставки страницы с ближайшего, а не отдаленного сервера. Это связано с тем, что соединение устанавливается быстрее, из-за чего медленный старт TCP ускоряется, при этом более короткий сетевой путь с меньшей вероятностью проходит через области перегрузки в интернете. Наконец, общая загруженность сети также сведена к минимуму. Если узлы CDN удачно расположены, то любая страница передается в каждом участке сети только один раз. Это важно, поскольку в конечном счете кто-то платит за полосу пропускания.

Илл. 7.45. Дерево распределения CDN

С ростом применения шифрования в интернете, в частности, использования протокола HTTPS для распространения веб-контента, доставка контента из CDN приобрела более сложный характер. Допустим, вам нужно загрузить главную страницу сайтаDNS-поиск для этого домена выдает ссылку на сервер имен компании Dyn, например ns1.p24.dynect.net, который, в свою очередь, перенаправляет вас на IP-адрес, размещенный в CDN этой компании. Но теперь этот сервер должен доставить вам контент, аутентифицированный New York Times. Для этого он, вероятно, должен располагать закрытыми ключами шифрования для сайта New York Times или сертификатом для сайта nytimes.com (или и тем и другим). Таким образом, CDN придется доверить конфиденциальную информацию провайдера контента, а сервер потребуется настроить так, чтобы он фактически выступал в роли агента сайта nytimes.com. Альтернативный подход состоит в том, чтобы направлять все запросы клиента обратно на исходный сервер, который сможет доставлять сертификаты и контент по протоколу HTTPS, но это сведет на нет практически все преимущества CDN в плане производительности. Решение обычно представляет собой компромисс: CDN генерирует сертификат от имени контент-провайдера и доставляет контент из CDN с помощью этого сертификата, выступая в роли организации. Это позволяет достичь основных целей: шифрования контента, идущего от CDN к пользователю, и его аутентификации для пользователя. Более сложные решения, которые требуют развертывания сертификатов на исходном сервере, также позволяют шифровать трафик между клиентом и узлами кэша. Компания Cloudflare предлагает хороший обзор таких решений на своем сайте по адресу https://cloudflare.com/ssl/.

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

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

Как упоминалось выше, самым распространенным способом сопоставления или направления клиентов к ближайшим узлам кэша CDN является переадресация DNS (DNS redirection). Рассмотрим этот подход более подробно. Предположим, клиент хочет попасть на страницу с URL-адресомЧтобы ее загрузить, браузер использует 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, поскольку видят в ней расширение возможностей обычного пользователя. Причина не только в том, что для запуска CDN нужны усилия большой организации, в то время как любой обладатель компьютера может присоединиться к сети P2P. Сети P2P имеют колоссальную емкость для распространения контента, что может сравниться с крупнейшими веб-сайтами.

Первые одноранговые сети: Napster

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

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

Децентрализация каталога: Gnutella

Созданная в 2000 году, сеть Gnutella была призвана решить некоторые проблемы, свойственные централизованной службе каталогов Napster, с помощью полностью распределенной функции поиска. В сети Gnutella присоединившийся к сети пир ищет другие подключенные пиры с помощью специального процесса обнаружения. Сначала он связывается с несколькими общеизвестными пирами сети, которые он должен был обнаружить на этапе начальной загрузки. Один из механизмов здесь сводится к тому, чтобы само ПО предоставляло некоторый набор IP-адресов пиров сети Gnutella. Обнаружив этот набор, пир может отправить поисковые запросы этим соседним пирам, те, в свою очередь, передадут их своим соседям, и т.д. Этот общий метод поиска в одноранговой сети часто называют сплетнями (gossip).